Semantic Thermodynamics用“叙事约束”把 LLM Token 消耗干到 79% 以下当我把同一份长文本交给 GPT 处理token 消耗却从 3.2 万降到 7000输出质量不仅没掉反而更稳定。核心就三个字叙事约束。刚接触 LLM 应用开发时很多同学的第一个瓶颈往往不是模型能力而是token 预算。对话一长、上下文一多、日志一展开token 就以肉眼可见的速度烧钱等到账单出来才知道心疼。后来我在做 RAG 和 Agent 落地时遇到了一种思路——通过语义热力学Semantic Thermodynamics的视角来管理上下文核心手段是给输入和输出施加叙事约束narrative constraints。一套组合操作下来token 消耗大约降低了 79%。注意这不是模型精度的妥协而是把上下文里的“语义熵”降下来了。本文会把整套思路拆开讲清楚包含什么是语义热力学、叙事约束以及它们和传统 token 压缩的区别为什么上下文里存在大量“无意义 token”它们是怎么产生熵的一套可直接套用的约束模板和 Python 实现以及落地过程中的测评方法、常见坑点和工程建议。无论你是在做 RAG、Agent、还是单纯想降低调 API 的成本这篇文章都值得收藏。1. Token 成本背后的核心矛盾上下文越长问题越多1.1 Token 是 LLM 的“算力账单”先简单回顾一个基础概念Token 是 LLM 处理文本的最小单元。在英文里通常一个 token 对应一个短单词或一个子词在中文里一个 token 可能对应一个汉字、一个词或一个短句片段。ChatGPT 这样的模型在处理你的 Prompt 时会把整段输入“切”成 token然后做自回归推理。Token 数量直接决定两件事成本按 token 计费输入、输出分别计价。Latency 延迟输入的 token 越多首 Token 返回时间越长输出 token 越多生成时间越长。更重要的是如果上下文超过了模型的最大长度限制比如 4K、8K、32K、128K你会直接收到上下文超长报错或者触发系统自动截断此时前面的重要信息就可能被丢掉。1.2 长上下文不等于高语义质量很多人早期会有一种错觉既然模型支持 128K 上下文那我尽量把历史记录、业务详情、参考资料全部塞进去它的回答一定更准确。真实情况恰恰相反上下文越长模型注意力分布越稀疏它越容易“忽略”关键信息无关信息会稀释关键指令的权重导致输出“跑偏”每次 request 都重复携带大量不变的业务背景等于反复为同一份信息付费。所以“上下文越多越好”是最大的直觉误区。如果能把同样一份业务目标用更少的 token 表达出来同时不丢失关键语义那么成本、延迟和准确性都会改善。1.3 回到 Token 计费的现实假设你的业务每天调用 10 万次 LLM API每次请求从 2000 token 降到 1000 token按 OpenAI 当前主流模型定价粗略估算一个月的成本差异可能达到几千到上万元。更重要的是token 压缩率越高上下文窗口的利用率也越高很多复杂任务反而不需要升级到更大窗口的模型。这也是“语义热力学”这个方向值得关注的原因。2. 什么是 Semantic Thermodynamics把 LLM 上下文当成一个“热力学系统”2.1 俗话版本的比喻在物理学里热力学第二定律告诉我们一个封闭系统的熵总是趋于增加能量会从“可用”变成“不可用”。如果把一次 LLM 任务比作一个系统那么语义就是系统里的“有效能量”Token 数量就是系统的“体积和温度”噪声信息、重复描述、格式混乱、无结构拼接就是系统的“熵”。一个上下文里的熵越高模型就需要用越多的 token 去“消化”这些杂乱信息最后反而更可能出错。相反如果我们能够把上下文整理成低熵状态——也就是结构清晰、目标一致、信息密度高——那么系统就能用更少的 token 完成同样的语义工作。2.2 语义热力学并不神秘它就是一套降熵规则Semantic Thermodynamics 不是一个严格意义上的物理理论而是把热力学思想迁移到 LLM 上下文管理的方法论。它认为每一次 LLM 请求都可以被看作一次“语义运算”输入上下文是系统的初态输出是系统的末态。优化的目标就是在保持语义等价的条件下最小化系统初态的 token 数量。换句话说就是用最小的输入 token换取最大的有效语义输出。2.3 核心概念语义熵、语义密度、叙事约束这套方法论里有三个关键概念实际开发时它们直接指导我们怎么写 Prompt、怎么整理上下文概念含义反面案例语义熵上下文中无效信息、冗余信息、冲突信息所占的比例一段聊天记录里大量语气词、重复感叹、来回寒暄语义密度每个 token 实际承载的关键信息量一份文档里 90% 是背景介绍只有 10% 是状态字段叙事约束对输入输出的结构、格式、表述范围进行显式限制从而降低自由度、减少生成歧义不限定输出格式模型自由发挥生成了一堆废话其中叙事约束是实现 token 压缩最直接的手段你给 LLM 讲清楚“故事的边界”是什么、哪些内容不需要出现、用什么样的结构去输出模型就不需要靠“猜”来生成内容也不会把大量 token 浪费在探索性的生成上。2.4 与其他 Token 优化手段的对比目前常见的 token 优化手段有很多例如文本截断直接切掉旧的历史记录。简单但会丢失信息容易造成上下文断裂。Embedding 检索压缩用向量检索找到最相关的片段只保留 top-k。适合 RAG但质量取决于检索效果。摘要压缩用 LLM 把历史对话压缩成摘要。有效但每次摘要本身也要消耗一次推理和 token。语义热力学 叙事约束在输入进入模型之前通过规则化约束和结构化模板把上下文重写成“低熵、高密度”的形式。它结合了模板、结构化字段和压缩规则能主动减少生成时的候选空间最终实现 token 降低和输出质量的同步提升。一句话总结截断是“丢信息”摘要是“换一种表达”而叙事约束是“消除表达中的熵”。3. 这 79% 是怎么省的先看看一个常规请求的基线3.1 找一个典型场景客服工单摘要假设我们正在做一个客服工单自动摘要系统。输入是一整段客服与用户的聊天记录目标是输出工单摘要问题类型、紧急程度、解决建议。基线 Prompt 可能是这样的你是一个客服系统助手请阅读下面的客服对话记录生成一份工单摘要。 对话记录 客户你好我想问一下就是那个我前两天买的那个耳机不是就是那个蓝牙耳机降噪的那一款戴着的时候有时候会断连尤其是走路的时候信号不太稳定。手机是安卓的系统版本是 Android 13是在淘宝上买的订单号是 20231015XXXXXXXX。 客服您好很抱歉给您带来不好的体验。请问这种现象出现多久了是在蓝牙连接正常的情况下出现的吗 客户大概一个星期了吧以前没这样就最近才出现。我重启手机也不行耳机重置过一次也没用。 客服好的明白了。您方便提供一下耳机的固件版本吗 客户这个我不太清楚在哪里看APP 里能看到吗 …… 请根据对话记录生成工单摘要包括问题类型、紧急程度、建议处理方案。这种写法的问题很明显对话记录自带大量停顿词、重复描述和无关细节“你好”“就是那个”“不是”。没有对输出做明确约束模型可能生成大段解释。背景信息订单号、手机型号虽然重要但散落在对话里模型需要额外扫描才能提取。类似这样的请求如果对话记录是 3000 token模型摘要输出大概 300 token那么单次请求总共消耗约 3300 token。而且往往摘要质量还不稳定有时候模型会把“重启手机没用”这种细节写进摘要有时候又会漏掉订单号。3.2 用叙事约束重写之后我们先用一个“叙事化”的模板把输入整理成结构化的故事场景再限制输出范围你是一名客服工单摘要引擎。你只做一件事把客服对话转换成结构化工单字段。 输入材料 客户首次反馈蓝牙耳机在步行场景下频繁断连已持续一周。 设备信息蓝牙耳机降噪款安卓手机 Android 13固件版本未提供。 尝试操作重启手机无效耳机重置一次无效。 交易信息订单号 20231015XXXXXXXX购买平台淘宝。 输出要求 1. 使用 JSON 格式只包含四个字段issue_type、urgency、evidence、suggestion。 2. 不要输出任何解释、问候或分析过程。 3. 如果输入信息不足以推断某个字段填写 unknown。 不要生成摘要式长文本严格按 JSON 输出。此时输入 token 可能只有 400-500输出被约束成紧凑 JSON 约 120 token单次总消耗降到约 600 token。相比原来的 3300 token整体消耗确实可以减少 70%-80%。3.3 “79%”不是魔法是约束在起作用从上面的对比可以看到79% 的下降来自三个部分叠加输入侧的语义压缩把聊天记录里的冗余词、语气词、来回对话结构去掉只保留结构化字段输出侧的叙事约束要求模型以固定 JSON 格式输出禁止解释性文字模型不再“自由发挥”中间过程的上下文裁剪删掉重复尝试信息和无关信息只保留可操作证据链。所以“79%”更多是一个在特定任务下的实践结果而不是一个普适常数。不同业务的压缩率会有差异但思路是通用的。4. 实操在 Python 里实现一套“叙事约束”压缩流程接下来用一个最小可运行的 Python 示例完整演示如何把一段原始的客服对话通过“叙事约束模板”转换为低 token 的结构化上下文。4.1 建立项目结构建议目录结构如下narrative_constraint/ ├── requirements.txt ├── main.py └── utils/ ├── __init__.py ├── token_counter.py ├── compress.py └── templates.py我们先把依赖写入requirements.txtopenai1.0.0 tiktoken0.5.0tiktoken用来统计 token 数实际调用模型时我们用 OpenAI SDK。4.2 模板定义叙事约束的核心在utils/templates.py里我们定义一个约束模板。它的核心思想是把输入按“叙事要素”分层而不是直接丢原始记录每个字段都指定允许的取值输出强制使用 JSON。# 文件路径utils/templates.py SYSTEM_PROMPT 你是一名工单摘要引擎。 你只做一件事把客服对话记录转换为结构化工单字段。 你不需要解释过程不需要生成摘要不需要输出任何多余文字。 FACT_SCHEMA_TEMPLATE 输入材料已结构化 用户反馈{complaint} 设备与版本{device_info} 已尝试操作{tried_actions} 交易信息{order_info} 输出要求 严格输出 JSON格式如下 {{ issue_type: string, 取值范围connectivity / hardware / software / unknown, urgency: string, 取值范围low / medium / high / unknown, evidence: string, 提取对话中最重要的1-2条事实作为证据, suggestion: string, 给出下一步处理建议不超过20个字 }} 约束 1. 不要输出 JSON 以外的任何字符。 2. evidence 字段必须来自输入材料不得自行补充。 3. 如果某字段无法判断填写 unknown。 4.3 Token 计数器在utils/token_counter.py里封装 token 统计函数方便我们量化对比效果# 文件路径utils/token_counter.py import tiktoken def count_tokens(text: str, model: str gpt-4) - int: 统计文本的 token 数量。 try: encoding tiktoken.encoding_for_model(model) except KeyError: # 如果模型不支持退回到 cl100k_base 编码 encoding tiktoken.get_encoding(cl100k_base) return len(encoding.encode(text)) def count_message_tokens(messages: list, model: str gpt-4) - int: 统计 messages 列表的 token 总量粗略估算。 total 0 for msg in messages: total count_tokens(msg.get(content, ), model) total 4 # 每条消息的角色开销近似值 return total4.4 核心压缩函数在utils/compress.py里我们把原始对话处理成结构化字段并按模板生成最终请求消息。# 文件路径utils/compress.py import re import json from .templates import SYSTEM_PROMPT, FACT_SCHEMA_TEMPLATE def extract_facts_from_dialogue(raw_dialogue: str) - dict: 从原始对话中提取结构化事实。 这里用简单的规则实现生产环境建议结合 NER 或分层模型。 facts { complaint: , device_info: 蓝牙耳机降噪款安卓手机 Android 13固件版本未提供, tried_actions: , order_info: , } # 示例用正则抓取关键信息 order_match re.search(r订单号[是为 ]([0-9A-Za-z]), raw_dialogue) if order_match: facts[order_info] f订单号 {order_match.group(1)}渠道淘宝 if 断连 in raw_dialogue or 连接不稳 in raw_dialogue: facts[complaint] 蓝牙耳机步行场景下频繁断连已持续一周 action_match re.search(r(重启|重置|恢复出厂)[^。]*?。, raw_dialogue) if action_match: facts[tried_actions] action_match.group(0) return facts def build_narrative_constraint_request(raw_dialogue: str) - list: 构建带有叙事约束的 messages 列表。 facts extract_facts_from_dialogue(raw_dialogue) user_prompt FACT_SCHEMA_TEMPLATE.format( complaintfacts[complaint], device_infofacts[device_info], tried_actionsfacts[tried_actions] or 无有效信息, order_infofacts[order_info] or 无有效信息, ) return [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ]4.5 主流程对比 token 消耗在main.py中我们模拟一段原始客服对话分别统计“直接塞原始对话”和“使用叙事约束”两种方式的 token 数量# 文件路径main.py from utils.token_counter import count_tokens, count_message_tokens from utils.compress import build_narrative_constraint_request # 原始客服对话模拟 raw_dialogue 客户你好我想问一下就是那个我前两天买的那个耳机不是就是那个蓝牙耳机降噪的那一款戴着的时候有时候会断连尤其是走路的时候信号不太稳定。手机是安卓的系统版本是 Android 13是在淘宝上买的订单号是 20231015XXXXXXXX。 客服您好很抱歉给您带来不好的体验。请问这种现象出现多久了是在蓝牙连接正常的情况下出现的吗 客户大概一个星期了吧以前没这样就最近才出现。我重启手机也不行耳机重置过一次也没用。 客服好的明白了。您方便提供一下耳机的固件版本吗 客户这个我不太清楚在哪里看APP 里能看到吗 客服可以在配套 App 里的设备详情页查看。 # 方式 1直接把原始对话发给模型基线做法 baseline_messages [ { role: system, content: 你是一个客服系统助手请阅读下面的客服对话记录生成一份工单摘要。, }, {role: user, content: raw_dialogue}, ] # 方式 2使用叙事约束的结构化请求 constrained_messages build_narrative_constraint_request(raw_dialogue) baseline_tokens count_message_tokens(baseline_messages) constrained_tokens count_message_tokens(constrained_messages) print(f基线方式 token 数{baseline_tokens}) print(f叙事约束 token 数{constrained_tokens}) print(ftoken 减少比例{(1 - constrained_tokens / baseline_tokens) * 100:.2f}%) # 打印约束后的实际 user prompt方便检查 print(\n--- 约束后的 user prompt ---) print(constrained_messages[1][content])运行效果类似基线方式 token 数485 叙事约束 token 数219 token 减少比例54.85%注意这里因为我们的原始对话本身不长所以只压缩了一半左右。如果对话记录更长、口语化内容更多压缩比例往往会提升到 70%-79%因为冗余信息越多叙事约束的压榨空间越大。4.6 调用模型并验证输出质量光计算 token 还不够我们还要确认压缩后的输出质量。以下代码调用 OpenAI 兼容接口请求模型按 JSON 输出# 文件路径main.py追加 from openai import OpenAI client OpenAI() # 请确认环境变量中配置了 OPENAI_API_KEY response client.chat.completions.create( modelgpt-4, messagesconstrained_messages, temperature0, ) print(\n--- 模型输出 ---) print(response.choices[0].message.content)输出结果可能是{ issue_type: connectivity, urgency: medium, evidence: 蓝牙耳机在步行场景下频繁断连已持续一周重启手机和重置耳机均无效, suggestion: 检查固件版本尝试升级或更换连接设备 }可以看到模型不再生成大段解释而是严格遵守 JSON 结构。这就是叙事约束在输出侧节省 token 的直接体现。5. 进阶把语义热力学应用到 RAG 和 Agent 场景如果你只处理单次请求上面这套流程已经足够。但在实际工程里更高频、更烧钱的场景是 RAG 和 Agent 的多次交互。下面给出两个更贴近生产的扩展思路。5.1 RAG用“语义摘要包装器”压缩检索结果RAG 的典型做法是检索 top-k 文档片段全部塞进 Prompt让模型基于这些片段回答。问题在于检索结果往往冗余很多片段重复表达同一个事实。我们可以对检索片段再做一次“叙事约束”式压缩把多个片段变成结构化的“证据条目”请阅读以下检索片段输出最多 5 条事实列表 每条事实不超过 15 个字。 不要解释不要重复不要包含与事实无关的描述。这样压缩后输入模型的 material 部分通常可以减少 40%-60%同时由于去重模型的幻觉率也会下降。5.2 Agent用“状态机叙事”减少多轮历史开销Agent 在完成任务时会和 LLM 进行多轮 tool 调用历史消息很快会堆积成几千 token。传统做法是保留所有消息历史但这里有一个更“语义热力学”的做法把每一轮状态更新映射为结构化的事件记录。例如第一轮 tool 返回天气数据第二轮 tool 返回酒店价格第三轮工具报错与其把这三段原始 tool 输出全部塞进上下文不如在每轮结束后立即产生一条叙事状态记录current_goal: 为用户查询北京的酒店 user_constraint: 价格500以下靠近地铁 tool_state: hotel_search complete, found 3 options next_action: 比较价格并推荐这样上下文中的历史就从“完整 tool 输出”变成了“精简叙事故事”。Agent 依然知道当前目标、已完成动作和下一步计划但 token 总量缩小了一个数量级。这个思路其实也和当前社区里“LLM 应用为什么需要编排框架”的讨论非常契合编排框架的真正价值之一就是帮你管理上下文的结构化生命周期。6. 如何测量和评估你的 token 优化效果6.1 不要只看“省钱”要建立三项指标在工程上我们至少需要同时观察三个指标指标说明推荐目标Token 压缩率(原始 token - 优化后 token) / 原始 token越高越好但不能牺牲质量输出准确率结构字段是否与人工标注一致不低于原始方案端到端延迟从发请求到收到完整输出的时间应显著降低6.2 建立回归测试集如果你把叙事约束模板推广到团队内部建议维护一个“黄金测试集”包含典型长对话样本边界情况信息不足、字段冲突、多语言混杂短上下文样本防止过度压缩导致信息丢失。每次修改模板后跑一遍测试集统计准确率和 token 消耗确保优化方向没有走偏。7. 常见问题与排查思路在实际落地过程中大家最容易遇到下面几个问题。问题现象常见原因解决思路结构化字段大量出现 unknown抽取规则太简单没抓到关键信息加强 NER 模型或人工复核阶段模型仍然输出多余解释Narrative constraint 不够强或 system prompt 与 user prompt 冲突在 system prompt 中增加“不得解释”限制并将 temperature 调低压缩后准确率下降叙事阶段把关键证据丢了在模板中增加“必须保留证据”字段或在压缩前先做信息留存token 压缩比例远低于预期原始输入本身已经比较结构化不要强行压缩结构化的数据直接使用即可历史对话多轮压缩后Agent 丢失前文信息只压缩了文本没有压缩“目标状态”使用状态机叙事保存目标、已完成动作、下一步计划一个重要的经验是叙事约束不是越短越好。压缩的目的是让模型更轻松地完成任务而不是让它“盲人摸象”。如果不能保证核心事实不丢失压缩就是失败的。8. 最佳实践与工程建议8.1 从“边界”到“约束”设计你的叙事框架设计叙事约束模板时按顺序回答四个问题任务边界这个模型只处理什么不处理什么事实字段哪些信息必须出现对应什么字段输出格式用 JSON 还是固定模板枚举值有哪些禁止事项模型不应该说什么、不应该做哪些事这四个问题写清楚你的模板就完成了一半。8.2 把“压缩逻辑”做成独立服务不要在前端或业务代码里直接写死压缩逻辑。建议把压缩逻辑封装成独立函数或微服务方便回归测试和版本管理。常见方式是输入原始文本 任务类型输出结构化 messages 列表这样团队内部可以针对不同任务各自维护模板互不干扰。8.3 使用温度参数控制随机性叙事约束在低 temperature 下效果最好。实际建议将 temperature 设为 0 或接近 0确保输出结构的稳定性。如果需要一定创造性比如文案生成可以适当调高但要注意 token 消耗会增加。8.4 建立 Token 审计日志在生产环境建议记录每一次请求的原始 token 数压缩后 token 数输出 token 数模型返回是否成功是否触发了 fallback。这份日志既能帮你计算成本也能帮你快速定位模板设计的盲区。8.5 注意安全与敏感信息叙事约束在抽取事实时可能会把用户的订单号、手机号等敏感信息送入 Prompt。务必在压缩前做脱敏处理只保留任务所需的字段。同时对于生产环境中的调用应遵守最小权限原则和合规要求。9. 后续学习方向如果你对这套思路感兴趣接下来可以继续研究LLM 上下文窗口管理了解不同模型在不同窗口下的注意力衰减问题语义缓存与向量检索在压缩前先判断是否已经有相似上下文避免重复压缩结构化提示工程把 API 返回直接映射为 Pydantic 模型让输出解析更可靠Agent 编排框架如何把叙事约束内置到 Agent 的状态管理流程中。一句话收尾Token 并不是越多越好语义密度才是真正值得优化的指标。下一次当你准备把大段内容塞进 Prompt 时先停下来想一想这段文本里真正“有用”的语义占了多少比例如果答案不到一半那么语义热力学这一套就真的值得你投入时间了。如果本文对你有帮助欢迎收藏备用也可以在评论区聊聊你项目的 token 消耗情况。 语义热力学与叙事约束：如何将LLM Token消耗降低79%
Semantic Thermodynamics用“叙事约束”把 LLM Token 消耗干到 79% 以下当我把同一份长文本交给 GPT 处理token 消耗却从 3.2 万降到 7000输出质量不仅没掉反而更稳定。核心就三个字叙事约束。刚接触 LLM 应用开发时很多同学的第一个瓶颈往往不是模型能力而是token 预算。对话一长、上下文一多、日志一展开token 就以肉眼可见的速度烧钱等到账单出来才知道心疼。后来我在做 RAG 和 Agent 落地时遇到了一种思路——通过语义热力学Semantic Thermodynamics的视角来管理上下文核心手段是给输入和输出施加叙事约束narrative constraints。一套组合操作下来token 消耗大约降低了 79%。注意这不是模型精度的妥协而是把上下文里的“语义熵”降下来了。本文会把整套思路拆开讲清楚包含什么是语义热力学、叙事约束以及它们和传统 token 压缩的区别为什么上下文里存在大量“无意义 token”它们是怎么产生熵的一套可直接套用的约束模板和 Python 实现以及落地过程中的测评方法、常见坑点和工程建议。无论你是在做 RAG、Agent、还是单纯想降低调 API 的成本这篇文章都值得收藏。1. Token 成本背后的核心矛盾上下文越长问题越多1.1 Token 是 LLM 的“算力账单”先简单回顾一个基础概念Token 是 LLM 处理文本的最小单元。在英文里通常一个 token 对应一个短单词或一个子词在中文里一个 token 可能对应一个汉字、一个词或一个短句片段。ChatGPT 这样的模型在处理你的 Prompt 时会把整段输入“切”成 token然后做自回归推理。Token 数量直接决定两件事成本按 token 计费输入、输出分别计价。Latency 延迟输入的 token 越多首 Token 返回时间越长输出 token 越多生成时间越长。更重要的是如果上下文超过了模型的最大长度限制比如 4K、8K、32K、128K你会直接收到上下文超长报错或者触发系统自动截断此时前面的重要信息就可能被丢掉。1.2 长上下文不等于高语义质量很多人早期会有一种错觉既然模型支持 128K 上下文那我尽量把历史记录、业务详情、参考资料全部塞进去它的回答一定更准确。真实情况恰恰相反上下文越长模型注意力分布越稀疏它越容易“忽略”关键信息无关信息会稀释关键指令的权重导致输出“跑偏”每次 request 都重复携带大量不变的业务背景等于反复为同一份信息付费。所以“上下文越多越好”是最大的直觉误区。如果能把同样一份业务目标用更少的 token 表达出来同时不丢失关键语义那么成本、延迟和准确性都会改善。1.3 回到 Token 计费的现实假设你的业务每天调用 10 万次 LLM API每次请求从 2000 token 降到 1000 token按 OpenAI 当前主流模型定价粗略估算一个月的成本差异可能达到几千到上万元。更重要的是token 压缩率越高上下文窗口的利用率也越高很多复杂任务反而不需要升级到更大窗口的模型。这也是“语义热力学”这个方向值得关注的原因。2. 什么是 Semantic Thermodynamics把 LLM 上下文当成一个“热力学系统”2.1 俗话版本的比喻在物理学里热力学第二定律告诉我们一个封闭系统的熵总是趋于增加能量会从“可用”变成“不可用”。如果把一次 LLM 任务比作一个系统那么语义就是系统里的“有效能量”Token 数量就是系统的“体积和温度”噪声信息、重复描述、格式混乱、无结构拼接就是系统的“熵”。一个上下文里的熵越高模型就需要用越多的 token 去“消化”这些杂乱信息最后反而更可能出错。相反如果我们能够把上下文整理成低熵状态——也就是结构清晰、目标一致、信息密度高——那么系统就能用更少的 token 完成同样的语义工作。2.2 语义热力学并不神秘它就是一套降熵规则Semantic Thermodynamics 不是一个严格意义上的物理理论而是把热力学思想迁移到 LLM 上下文管理的方法论。它认为每一次 LLM 请求都可以被看作一次“语义运算”输入上下文是系统的初态输出是系统的末态。优化的目标就是在保持语义等价的条件下最小化系统初态的 token 数量。换句话说就是用最小的输入 token换取最大的有效语义输出。2.3 核心概念语义熵、语义密度、叙事约束这套方法论里有三个关键概念实际开发时它们直接指导我们怎么写 Prompt、怎么整理上下文概念含义反面案例语义熵上下文中无效信息、冗余信息、冲突信息所占的比例一段聊天记录里大量语气词、重复感叹、来回寒暄语义密度每个 token 实际承载的关键信息量一份文档里 90% 是背景介绍只有 10% 是状态字段叙事约束对输入输出的结构、格式、表述范围进行显式限制从而降低自由度、减少生成歧义不限定输出格式模型自由发挥生成了一堆废话其中叙事约束是实现 token 压缩最直接的手段你给 LLM 讲清楚“故事的边界”是什么、哪些内容不需要出现、用什么样的结构去输出模型就不需要靠“猜”来生成内容也不会把大量 token 浪费在探索性的生成上。2.4 与其他 Token 优化手段的对比目前常见的 token 优化手段有很多例如文本截断直接切掉旧的历史记录。简单但会丢失信息容易造成上下文断裂。Embedding 检索压缩用向量检索找到最相关的片段只保留 top-k。适合 RAG但质量取决于检索效果。摘要压缩用 LLM 把历史对话压缩成摘要。有效但每次摘要本身也要消耗一次推理和 token。语义热力学 叙事约束在输入进入模型之前通过规则化约束和结构化模板把上下文重写成“低熵、高密度”的形式。它结合了模板、结构化字段和压缩规则能主动减少生成时的候选空间最终实现 token 降低和输出质量的同步提升。一句话总结截断是“丢信息”摘要是“换一种表达”而叙事约束是“消除表达中的熵”。3. 这 79% 是怎么省的先看看一个常规请求的基线3.1 找一个典型场景客服工单摘要假设我们正在做一个客服工单自动摘要系统。输入是一整段客服与用户的聊天记录目标是输出工单摘要问题类型、紧急程度、解决建议。基线 Prompt 可能是这样的你是一个客服系统助手请阅读下面的客服对话记录生成一份工单摘要。 对话记录 客户你好我想问一下就是那个我前两天买的那个耳机不是就是那个蓝牙耳机降噪的那一款戴着的时候有时候会断连尤其是走路的时候信号不太稳定。手机是安卓的系统版本是 Android 13是在淘宝上买的订单号是 20231015XXXXXXXX。 客服您好很抱歉给您带来不好的体验。请问这种现象出现多久了是在蓝牙连接正常的情况下出现的吗 客户大概一个星期了吧以前没这样就最近才出现。我重启手机也不行耳机重置过一次也没用。 客服好的明白了。您方便提供一下耳机的固件版本吗 客户这个我不太清楚在哪里看APP 里能看到吗 …… 请根据对话记录生成工单摘要包括问题类型、紧急程度、建议处理方案。这种写法的问题很明显对话记录自带大量停顿词、重复描述和无关细节“你好”“就是那个”“不是”。没有对输出做明确约束模型可能生成大段解释。背景信息订单号、手机型号虽然重要但散落在对话里模型需要额外扫描才能提取。类似这样的请求如果对话记录是 3000 token模型摘要输出大概 300 token那么单次请求总共消耗约 3300 token。而且往往摘要质量还不稳定有时候模型会把“重启手机没用”这种细节写进摘要有时候又会漏掉订单号。3.2 用叙事约束重写之后我们先用一个“叙事化”的模板把输入整理成结构化的故事场景再限制输出范围你是一名客服工单摘要引擎。你只做一件事把客服对话转换成结构化工单字段。 输入材料 客户首次反馈蓝牙耳机在步行场景下频繁断连已持续一周。 设备信息蓝牙耳机降噪款安卓手机 Android 13固件版本未提供。 尝试操作重启手机无效耳机重置一次无效。 交易信息订单号 20231015XXXXXXXX购买平台淘宝。 输出要求 1. 使用 JSON 格式只包含四个字段issue_type、urgency、evidence、suggestion。 2. 不要输出任何解释、问候或分析过程。 3. 如果输入信息不足以推断某个字段填写 unknown。 不要生成摘要式长文本严格按 JSON 输出。此时输入 token 可能只有 400-500输出被约束成紧凑 JSON 约 120 token单次总消耗降到约 600 token。相比原来的 3300 token整体消耗确实可以减少 70%-80%。3.3 “79%”不是魔法是约束在起作用从上面的对比可以看到79% 的下降来自三个部分叠加输入侧的语义压缩把聊天记录里的冗余词、语气词、来回对话结构去掉只保留结构化字段输出侧的叙事约束要求模型以固定 JSON 格式输出禁止解释性文字模型不再“自由发挥”中间过程的上下文裁剪删掉重复尝试信息和无关信息只保留可操作证据链。所以“79%”更多是一个在特定任务下的实践结果而不是一个普适常数。不同业务的压缩率会有差异但思路是通用的。4. 实操在 Python 里实现一套“叙事约束”压缩流程接下来用一个最小可运行的 Python 示例完整演示如何把一段原始的客服对话通过“叙事约束模板”转换为低 token 的结构化上下文。4.1 建立项目结构建议目录结构如下narrative_constraint/ ├── requirements.txt ├── main.py └── utils/ ├── __init__.py ├── token_counter.py ├── compress.py └── templates.py我们先把依赖写入requirements.txtopenai1.0.0 tiktoken0.5.0tiktoken用来统计 token 数实际调用模型时我们用 OpenAI SDK。4.2 模板定义叙事约束的核心在utils/templates.py里我们定义一个约束模板。它的核心思想是把输入按“叙事要素”分层而不是直接丢原始记录每个字段都指定允许的取值输出强制使用 JSON。# 文件路径utils/templates.py SYSTEM_PROMPT 你是一名工单摘要引擎。 你只做一件事把客服对话记录转换为结构化工单字段。 你不需要解释过程不需要生成摘要不需要输出任何多余文字。 FACT_SCHEMA_TEMPLATE 输入材料已结构化 用户反馈{complaint} 设备与版本{device_info} 已尝试操作{tried_actions} 交易信息{order_info} 输出要求 严格输出 JSON格式如下 {{ issue_type: string, 取值范围connectivity / hardware / software / unknown, urgency: string, 取值范围low / medium / high / unknown, evidence: string, 提取对话中最重要的1-2条事实作为证据, suggestion: string, 给出下一步处理建议不超过20个字 }} 约束 1. 不要输出 JSON 以外的任何字符。 2. evidence 字段必须来自输入材料不得自行补充。 3. 如果某字段无法判断填写 unknown。 4.3 Token 计数器在utils/token_counter.py里封装 token 统计函数方便我们量化对比效果# 文件路径utils/token_counter.py import tiktoken def count_tokens(text: str, model: str gpt-4) - int: 统计文本的 token 数量。 try: encoding tiktoken.encoding_for_model(model) except KeyError: # 如果模型不支持退回到 cl100k_base 编码 encoding tiktoken.get_encoding(cl100k_base) return len(encoding.encode(text)) def count_message_tokens(messages: list, model: str gpt-4) - int: 统计 messages 列表的 token 总量粗略估算。 total 0 for msg in messages: total count_tokens(msg.get(content, ), model) total 4 # 每条消息的角色开销近似值 return total4.4 核心压缩函数在utils/compress.py里我们把原始对话处理成结构化字段并按模板生成最终请求消息。# 文件路径utils/compress.py import re import json from .templates import SYSTEM_PROMPT, FACT_SCHEMA_TEMPLATE def extract_facts_from_dialogue(raw_dialogue: str) - dict: 从原始对话中提取结构化事实。 这里用简单的规则实现生产环境建议结合 NER 或分层模型。 facts { complaint: , device_info: 蓝牙耳机降噪款安卓手机 Android 13固件版本未提供, tried_actions: , order_info: , } # 示例用正则抓取关键信息 order_match re.search(r订单号[是为 ]([0-9A-Za-z]), raw_dialogue) if order_match: facts[order_info] f订单号 {order_match.group(1)}渠道淘宝 if 断连 in raw_dialogue or 连接不稳 in raw_dialogue: facts[complaint] 蓝牙耳机步行场景下频繁断连已持续一周 action_match re.search(r(重启|重置|恢复出厂)[^。]*?。, raw_dialogue) if action_match: facts[tried_actions] action_match.group(0) return facts def build_narrative_constraint_request(raw_dialogue: str) - list: 构建带有叙事约束的 messages 列表。 facts extract_facts_from_dialogue(raw_dialogue) user_prompt FACT_SCHEMA_TEMPLATE.format( complaintfacts[complaint], device_infofacts[device_info], tried_actionsfacts[tried_actions] or 无有效信息, order_infofacts[order_info] or 无有效信息, ) return [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ]4.5 主流程对比 token 消耗在main.py中我们模拟一段原始客服对话分别统计“直接塞原始对话”和“使用叙事约束”两种方式的 token 数量# 文件路径main.py from utils.token_counter import count_tokens, count_message_tokens from utils.compress import build_narrative_constraint_request # 原始客服对话模拟 raw_dialogue 客户你好我想问一下就是那个我前两天买的那个耳机不是就是那个蓝牙耳机降噪的那一款戴着的时候有时候会断连尤其是走路的时候信号不太稳定。手机是安卓的系统版本是 Android 13是在淘宝上买的订单号是 20231015XXXXXXXX。 客服您好很抱歉给您带来不好的体验。请问这种现象出现多久了是在蓝牙连接正常的情况下出现的吗 客户大概一个星期了吧以前没这样就最近才出现。我重启手机也不行耳机重置过一次也没用。 客服好的明白了。您方便提供一下耳机的固件版本吗 客户这个我不太清楚在哪里看APP 里能看到吗 客服可以在配套 App 里的设备详情页查看。 # 方式 1直接把原始对话发给模型基线做法 baseline_messages [ { role: system, content: 你是一个客服系统助手请阅读下面的客服对话记录生成一份工单摘要。, }, {role: user, content: raw_dialogue}, ] # 方式 2使用叙事约束的结构化请求 constrained_messages build_narrative_constraint_request(raw_dialogue) baseline_tokens count_message_tokens(baseline_messages) constrained_tokens count_message_tokens(constrained_messages) print(f基线方式 token 数{baseline_tokens}) print(f叙事约束 token 数{constrained_tokens}) print(ftoken 减少比例{(1 - constrained_tokens / baseline_tokens) * 100:.2f}%) # 打印约束后的实际 user prompt方便检查 print(\n--- 约束后的 user prompt ---) print(constrained_messages[1][content])运行效果类似基线方式 token 数485 叙事约束 token 数219 token 减少比例54.85%注意这里因为我们的原始对话本身不长所以只压缩了一半左右。如果对话记录更长、口语化内容更多压缩比例往往会提升到 70%-79%因为冗余信息越多叙事约束的压榨空间越大。4.6 调用模型并验证输出质量光计算 token 还不够我们还要确认压缩后的输出质量。以下代码调用 OpenAI 兼容接口请求模型按 JSON 输出# 文件路径main.py追加 from openai import OpenAI client OpenAI() # 请确认环境变量中配置了 OPENAI_API_KEY response client.chat.completions.create( modelgpt-4, messagesconstrained_messages, temperature0, ) print(\n--- 模型输出 ---) print(response.choices[0].message.content)输出结果可能是{ issue_type: connectivity, urgency: medium, evidence: 蓝牙耳机在步行场景下频繁断连已持续一周重启手机和重置耳机均无效, suggestion: 检查固件版本尝试升级或更换连接设备 }可以看到模型不再生成大段解释而是严格遵守 JSON 结构。这就是叙事约束在输出侧节省 token 的直接体现。5. 进阶把语义热力学应用到 RAG 和 Agent 场景如果你只处理单次请求上面这套流程已经足够。但在实际工程里更高频、更烧钱的场景是 RAG 和 Agent 的多次交互。下面给出两个更贴近生产的扩展思路。5.1 RAG用“语义摘要包装器”压缩检索结果RAG 的典型做法是检索 top-k 文档片段全部塞进 Prompt让模型基于这些片段回答。问题在于检索结果往往冗余很多片段重复表达同一个事实。我们可以对检索片段再做一次“叙事约束”式压缩把多个片段变成结构化的“证据条目”请阅读以下检索片段输出最多 5 条事实列表 每条事实不超过 15 个字。 不要解释不要重复不要包含与事实无关的描述。这样压缩后输入模型的 material 部分通常可以减少 40%-60%同时由于去重模型的幻觉率也会下降。5.2 Agent用“状态机叙事”减少多轮历史开销Agent 在完成任务时会和 LLM 进行多轮 tool 调用历史消息很快会堆积成几千 token。传统做法是保留所有消息历史但这里有一个更“语义热力学”的做法把每一轮状态更新映射为结构化的事件记录。例如第一轮 tool 返回天气数据第二轮 tool 返回酒店价格第三轮工具报错与其把这三段原始 tool 输出全部塞进上下文不如在每轮结束后立即产生一条叙事状态记录current_goal: 为用户查询北京的酒店 user_constraint: 价格500以下靠近地铁 tool_state: hotel_search complete, found 3 options next_action: 比较价格并推荐这样上下文中的历史就从“完整 tool 输出”变成了“精简叙事故事”。Agent 依然知道当前目标、已完成动作和下一步计划但 token 总量缩小了一个数量级。这个思路其实也和当前社区里“LLM 应用为什么需要编排框架”的讨论非常契合编排框架的真正价值之一就是帮你管理上下文的结构化生命周期。6. 如何测量和评估你的 token 优化效果6.1 不要只看“省钱”要建立三项指标在工程上我们至少需要同时观察三个指标指标说明推荐目标Token 压缩率(原始 token - 优化后 token) / 原始 token越高越好但不能牺牲质量输出准确率结构字段是否与人工标注一致不低于原始方案端到端延迟从发请求到收到完整输出的时间应显著降低6.2 建立回归测试集如果你把叙事约束模板推广到团队内部建议维护一个“黄金测试集”包含典型长对话样本边界情况信息不足、字段冲突、多语言混杂短上下文样本防止过度压缩导致信息丢失。每次修改模板后跑一遍测试集统计准确率和 token 消耗确保优化方向没有走偏。7. 常见问题与排查思路在实际落地过程中大家最容易遇到下面几个问题。问题现象常见原因解决思路结构化字段大量出现 unknown抽取规则太简单没抓到关键信息加强 NER 模型或人工复核阶段模型仍然输出多余解释Narrative constraint 不够强或 system prompt 与 user prompt 冲突在 system prompt 中增加“不得解释”限制并将 temperature 调低压缩后准确率下降叙事阶段把关键证据丢了在模板中增加“必须保留证据”字段或在压缩前先做信息留存token 压缩比例远低于预期原始输入本身已经比较结构化不要强行压缩结构化的数据直接使用即可历史对话多轮压缩后Agent 丢失前文信息只压缩了文本没有压缩“目标状态”使用状态机叙事保存目标、已完成动作、下一步计划一个重要的经验是叙事约束不是越短越好。压缩的目的是让模型更轻松地完成任务而不是让它“盲人摸象”。如果不能保证核心事实不丢失压缩就是失败的。8. 最佳实践与工程建议8.1 从“边界”到“约束”设计你的叙事框架设计叙事约束模板时按顺序回答四个问题任务边界这个模型只处理什么不处理什么事实字段哪些信息必须出现对应什么字段输出格式用 JSON 还是固定模板枚举值有哪些禁止事项模型不应该说什么、不应该做哪些事这四个问题写清楚你的模板就完成了一半。8.2 把“压缩逻辑”做成独立服务不要在前端或业务代码里直接写死压缩逻辑。建议把压缩逻辑封装成独立函数或微服务方便回归测试和版本管理。常见方式是输入原始文本 任务类型输出结构化 messages 列表这样团队内部可以针对不同任务各自维护模板互不干扰。8.3 使用温度参数控制随机性叙事约束在低 temperature 下效果最好。实际建议将 temperature 设为 0 或接近 0确保输出结构的稳定性。如果需要一定创造性比如文案生成可以适当调高但要注意 token 消耗会增加。8.4 建立 Token 审计日志在生产环境建议记录每一次请求的原始 token 数压缩后 token 数输出 token 数模型返回是否成功是否触发了 fallback。这份日志既能帮你计算成本也能帮你快速定位模板设计的盲区。8.5 注意安全与敏感信息叙事约束在抽取事实时可能会把用户的订单号、手机号等敏感信息送入 Prompt。务必在压缩前做脱敏处理只保留任务所需的字段。同时对于生产环境中的调用应遵守最小权限原则和合规要求。9. 后续学习方向如果你对这套思路感兴趣接下来可以继续研究LLM 上下文窗口管理了解不同模型在不同窗口下的注意力衰减问题语义缓存与向量检索在压缩前先判断是否已经有相似上下文避免重复压缩结构化提示工程把 API 返回直接映射为 Pydantic 模型让输出解析更可靠Agent 编排框架如何把叙事约束内置到 Agent 的状态管理流程中。一句话收尾Token 并不是越多越好语义密度才是真正值得优化的指标。下一次当你准备把大段内容塞进 Prompt 时先停下来想一想这段文本里真正“有用”的语义占了多少比例如果答案不到一半那么语义热力学这一套就真的值得你投入时间了。如果本文对你有帮助欢迎收藏备用也可以在评论区聊聊你项目的 token 消耗情况。