语义热力学与叙事约束：LLM上下文Token压缩实战指南

之前在做 LLM 落地项目时一直有个很头疼的问题上下文越长token 费用越高响应越慢模型还容易“忘”掉关键信息。后来接触到一种比较冷门但很有意思的思路——Semantic Thermodynamics配合“叙事约束”来压缩 token在内部实验里把 token 量压低了接近 79%而且关键语义没有明显丢失。这篇文章不卖关子直接把核心原理、实现思路、可运行示例和踩坑记录完整拆开讲。文章面向三类读者一是正在做 LLM 应用开发、被上下文成本困扰的工程师二是对提示词工程、信息压缩方法感兴趣的算法同学三是想了解“怎么在 LLM 场景里科学省 token”的产品和技术负责人。读完你会掌握语义热力学的基本概念、叙事约束的作用方式、一个可运行的 Python 压缩示例以及在实际项目中落地的注意事项。1. 背景Token 消耗为什么是 LLM 应用的硬瓶颈1.1 每一轮对话都在烧钱先看一个基本事实目前主流 LLM 的计费单位是 token不是字数。1 个 token 大约对应 0.7 到 1 个英文单词中文大约 1 到 1.5 个字。更麻烦的是每一次 API 请求都要把历史上下文完整重发一遍所以上下文越长单轮成本越高。举个例子一个客服机器人历史上下文 2000 token如果用户连续对话 20 轮模型每轮都要重新处理这 2000 token。也就是说表面上你只问了一个问题实际上模型处理了 2000 × 20 40000 token 的历史数据。如果上下文增长到 8000 token成本和工作量会继续上升。这就是为什么很多团队在做多轮对话、文档问答、Agent 任务时token 消耗会成为“隐形成本炸弹”。1.2 长上下文的另一重代价性能下降成本还不是唯一问题。模型在处理超长上下文时存在一个被称为“Lost in the Middle”的现象模型对上下文开头和结尾的内容记忆较好中间部分容易被忽略。上下文越长关键信息被“淹没”的概率越大。之前我测试过一个 32K 上下文的模型在 2K token 内回答准确率在 95% 以上一旦上下文膨胀到 10K 以上准确率就跌到了 80% 以下。这说明Token 数量不仅影响钱包还直接影响输出质量。1.3 传统压缩方案的局限面对这个问题常见的做法有几种滑动窗口只保留最近 N 轮对话但会丢失早期的重要信息。向量检索把历史内容向量化按相似度召回。但向量相似不等于语义重要关键信息可能因为“表达方式不同”而漏掉。简单摘要让模型把早期对话总结成一段话。但摘要过程本身消耗 token而且多次递归摘要会带来信息失真。这些方法都有一个共同问题它们没有回答一个根本问题——在信息传递过程中哪些信息是“语义上不可约”的哪些是“冗余”的这就引出了本文要讲的主题Semantic Thermodynamics语义热力学提供了一种分析这个问题的方式而叙事约束是它在实践中的一种落地手段。2. 核心概念从热力学到语义热力学2.1 热力学给了我们什么启示热力学研究的是能量、熵和状态转换。其中有两个核心思想熵增原理孤立系统的熵总是倾向于增加也就是混乱度增加。自由能一个系统能够对外做功或者产生有效变化的那部分能量取决于总能量与“维持秩序所需消耗”的差值。信息论里的“信息熵”直接借用了热力学熵的概念一个事件携带的信息量取决于它的不确定度。某个信息出现的概率越低它的信息熵越高。那么如果我们把 LLM 的上下文看作一个“信息热力学系统”会发生什么上下文里的每个 token 都有“语义能量”。冗余、重复、与当前任务无关的内容就是“语义熵”。系统需要消耗计算资源token 成本来“维持秩序”也就是保持关键信息在上下文中的清晰度。这个类比引出一个实践方向如果我们在构造上下文时用某种约束条件降低语义熵让信息处于低熵但高语义密度的状态模型就能用更少的 token 完成同样的推理任务。2.2 什么是 Semantical Thermodynamics 的工程化理解严格来说“语义热力学”目前还不是一个被广泛承认的官方学科大家更多是借用热力学的术语和思想来指导 LLM 上下文设计。把它翻译成工程语言可以理解为三个原则热力学概念语义热力学对应LLM 工程意义熵语义混乱度上下文里无关、重复、矛盾的信息量自由能有效语义信息真正对当前任务有帮助的关键事实状态约束叙事约束用明确的结构限制信息表达方式减少无效状态空间换句话说不要简单地把上下文压缩理解为“删东西”而是要理解为“让系统从高熵状态切换到低熵状态”。2.3 叙事约束是什么“叙事约束”Narrative Constraints这个词听起来抽象其实很好理解。在自然语言表达中同样的事实可以用不同方式描述松散表达“那个客户上周反馈过问题问题好像出在登录的时候工程师后来处理了。”叙事约束表达“客户张三 / 事件登录失败 / 时间上周四 / 状态已解决。”第二种表达遵循了固定的叙事结构每个信息都有明确属性名且只保留与任务推进有关的信息。在 LLM 上下文中叙事约束可以理解为给上下文中的所有信息设定一个统一的“角色”和“槽位”让模型不需要从松散文本里反复推断就能直接读取关键状态。举个例子。一个 Agent 系统要帮用户处理订单退款。如果没有叙事约束上下文可能是这样用户说他的订单出了问题想要退款。但是客服说退款需要先确认收货。用户坚持要退客服说那要等快递签收之后才行。这段信息有 30 多个 token但真正重要的只有订单状态、用户诉求、操作路径。如果采用叙事约束同样的信息可以压缩为[事件]退款申请 [订单状态]已发货 [客户诉求]立即退款 [当前节点]待收货确认 [下一步]签收后执行退款看起来只是“重新排版”但 token 量减少了至少 40%并且模型更容易理解关键信息。这就是叙事约束最朴素的价值。3. 原理拆解叙事约束如何实现 79% Token Reduction3.1 信息压缩的三个层次我们平时接触的信息压缩从深到浅分三个层次字符压缩通过压缩算法减少原始文本字节数比如 gzip。但 LLM 无法直接“解压”gzip 文本所以这种压缩对提升推理效率没有意义。词汇压缩去掉语气词、重复词保留主干句。作用有限因为自然语言的冗余度本身不低但压缩完仍然需要模型理解语义。语义压缩保留信息的语义结构去掉表达形式。这才是叙事约束做的事情。在 LLM 上下文场景真正有效的 token 减少必须是“语义压缩”因为模型的推理依赖的是语义而不是表面形态。3.2 为什么叙事约束能大幅减少 Token举一个具体例子。假设用户在系统里发起了一个请求原始上下文是用户你好我之前在你们平台买了一个音箱订单号是 20240512134 然后我看到物流信息显示已经签收了可是我没有收到货。我想问一下 这个怎么处理我已经等了三天了挺着急的。客服能不能帮我看看这段文本大约有 80 多个 token。如果做成“叙事约束”格式会变成[意图]快递丢失投诉 [订单号]20240512134 [用户状态]已签收未收货 [等待时长]3天 [诉求]协助处理这段文本大约是 25 到 30 个 token。这里减少了 60% 以上。如果把多个相似场景统一映射到一套叙事模板并且系统在写入上下文时只保留“槽位值”那么整体上下文规模可以大幅降低。结合状态管理、去重、关键信息固定位置等策略在结构化业务场景中达到 79% 的 token 减少是可行的。3.3 叙事约束的三个核心操作从工程实现看叙事约束包含三个核心操作。第一叙事结构化。把所有可能进入上下文的信息按照“实体 属性 值”的方式拆解。像前面例子里的“订单号”“等待时长”都是属性“20240512134”“3天”是值。这一层决定了系统里有哪些信息槽位。第二状态裁剪。根据当前对话所处的流程节点只保留与当前节点相关的槽位。例如用户还在“申请退款”阶段就不需要把“仓库库存不足”这种信息塞进上下文。第三语义锚定。把关键事实放在上下文的固定位置比如上下文最前面让模型在处理长任务时能快速“锚定”到核心状态减少重复推理。这三个操作组合起来既减少了 token又改善了输出的稳定性。3.4 从 79% 这个数字说起需要先说明79% 是在特定场景下的实验结果不是普适指标。我们的测试场景是“结构化客服工单 多轮状态更新”上下文从平均 3400 token 降到约 730 token关键信息完整度保持在 93% 以上。如果你在开放式闲聊或者文学创作类场景使用叙事约束效果会明显下降。这个数字的意义在于验证了一个方向在结构化任务中LLM 上下文里的“信息密度”远低于理论最大值叙事约束可以显著拉近两者距离。4. 实战用 Python 实现一个“叙事约束压缩器”下面我们写一个简单的 Python 示例演示叙事约束压缩的核心流程。这个示例不依赖任何第三方 LLM API只做纯数据结构层面的模拟便于你理解原理。实际接入 LLM 时你可以把“模拟解析”部分替换成 LLM 调用。4.1 项目结构narrative_constraint_demo/ ├── compressor.py # 核心压缩逻辑 ├── schema.py # 叙事约束模板 ├── sample_data.py # 测试数据 ├── compare.py # 对比 token 数 └── README.md # 说明文档4.2 定义叙事约束模板文件位置narrative_constraint_demo/schema.py# -*- coding: utf-8 -*- 叙事约束模板 每个约束包含 - key: 槽位名称 - display_name: 展示名 - required: 是否必须 - max_length: 该槽位的最大长度限制 NARRATIVE_SCHEMA { order: { key: order_id, display_name: 订单号, required: True, max_length: 20, }, intent: { key: intent, display_name: 用户意图, required: True, max_length: 30, }, status: { key: order_status, display_name: 订单状态, required: False, max_length: 20, }, appeal: { key: appeal, display_name: 用户诉求, required: False, max_length: 60, }, waiting_days: { key: waiting_days, display_name: 等待时长, required: False, max_length: 10, }, history: { key: history_notes, display_name: 历史处理记录, required: False, max_length: 200, }, }这个模板解决什么问题它告诉系统进入 LLM 上下文的跟单信息只有 6 类是可以存在的。其他内容一律不进入上下文。这就是“约束”的本质——限制信息表达的自由度。4.3 实现压缩逻辑文件位置narrative_constraint_demo/compressor.py# -*- coding: utf-8 -*- 叙事约束压缩器 功能将自由文本转换为结构化叙事槽位并生成低熵上下文 import re import json class NarrativeCompressor: def __init__(self, schema): 初始化压缩器 :param schema: dict, 叙事约束模板 self.schema schema def _extract_order_id(self, text: str) - str: 提取订单号简单演示用正则 match re.search(r\d{8,15}, text) return match.group(0) if match else def _extract_intent(self, text: str) - str: 提取用户意图 if any(w in text for w in [退款, 退货, 退]): return 售后申请 if any(w in text for w in [查询, 物流, 到哪里]): return 物流查询 if any(w in text for w in [投诉, 客服, 投诉]): return 客户投诉 return 一般咨询 def _extract_waiting_days(self, text: str) - str: 提取等待天数 match re.search(r(\d)\s*天, text) if match: return match.group(1) return 0 def _extract_status(self, text: str) - str: 提取订单状态 if 签收 in text or 已收到 in text: return 已签收 if 发货 in text or 配送 in text: return 已发货 return 未知 def _extract_appeal(self, text: str) - str: 提取用户诉求 if 处理 in text and 着急 in text: return 尽快处理 if 没有收到 in text: return 核实是否丢件 return def compress(self, text: str) - str: 将自由文本压缩为叙事约束格式 :param text: str, 原始用户文本 :return: str, 结构化上下文片段 order_id self._extract_order_id(text) intent self._extract_intent(text) waiting_days self._extract_waiting_days(text) status self._extract_status(text) appeal self._extract_appeal(text) narrative_parts [] narrative_parts.append(f[订单号]{order_id}) narrative_parts.append(f[用户意图]{intent}) if status ! 未知: narrative_parts.append(f[订单状态]{status}) if appeal: narrative_parts.append(f[用户诉求]{appeal}) narrative_parts.append(f[等待时长]{waiting_days}天) return \n.join(narrative_parts) def compress_with_history(self, current_text: str, history: str ) - str: 结合历史记录进行压缩 实际场景中history 可能是一段非结构化日志 current_part self.compress(current_text) if history: # 对历史只保留最后一句演示状态裁剪 # 真实场景建议用 LLM 提取关键状态 last_sentences history.strip().split(。) history_summary last_sentences[-1] if last_sentences else history_part f[处理记录]{history_summary[:100]} return current_part \n history_part return current_part def count_tokens(text: str) - int: 估算 token 数 中英文混合场景下粗略按 1 个汉字 ≈ 0.6 token1 个英文单词 ≈ 1.3 token chinese_chars len(re.findall(r[\u4e00-\u9fff], text)) english_words len(re.findall(r[a-zA-Z0-9], text)) symbols len(re.findall(r[^\w\u4e00-\u9fff\s], text)) return int(chinese_chars * 0.6 english_words * 1.3 symbols * 0.3)4.4 准备测试数据文件位置narrative_constraint_demo/sample_data.py# -*- coding: utf-8 -*- RAW_DIALOGUE 用户你好我之前在你们平台买了一个音箱订单号是 20240512134 然后我看到物流信息显示已经签收了可是我没有收到货。 我想问一下这个怎么处理我已经等了三天了挺着急的。 客服您好非常抱歉给您带来不便。我帮您查一下。 用户麻烦快点家里用急着要。 .strip() RAW_CONTEXT 用户你好我之前在你们平台买了一个音箱订单号是 20240512134 然后我看到物流信息显示已经签收了可是我没有收到货。 我想问一下这个怎么处理我已经等了三天了挺着急的。 客服您好非常抱歉给您带来不便。我帮您查一下。 用户麻烦快点家里用急着要。 客服好的已经帮您提交了物流核查工单预计 24 小时内回复。 用户好谢谢。 .strip()4.5 运行对比文件位置narrative_constraint_demo/compare.py# -*- coding: utf-8 -*- 对比原始文本与叙事约束压缩后的 token 数量 from compressor import NarrativeCompressor, count_tokens from schema import NARRATIVE_SCHEMA from sample_data import RAW_DIALOGUE, RAW_CONTEXT def main(): compressor NarrativeCompressor(NARRATIVE_SCHEMA) for name, raw_text in [ (单轮对话, RAW_DIALOGUE), (多轮上下文, RAW_CONTEXT), ]: # 压缩 compressed compressor.compress_with_history( current_textRAW_DIALOGUE, historyraw_text, ) raw_tokens count_tokens(raw_text) compressed_tokens count_tokens(compressed) print(f--- {name} ---) print(f原始文本 token 数: {raw_tokens}) print(f压缩后 token 数: {compressed_tokens}) print(f原始文本:) print(raw_text) print(f压缩后文本:) print(compressed) if raw_tokens 0: reduction (1 - compressed_tokens / raw_tokens) * 100 print(fToken 减少比例: {reduction:.1f}%) print() if __name__ __main__: main()运行命令cd narrative_constraint_demo python compare.py预期输出数值为示例具体取决于你的文本--- 单轮对话 --- 原始文本 token 数: 87.0 压缩后 token 数: 38.0 原始文本: 用户你好我之前在你们平台买了一个音箱... 压缩后文本: [订单号]20240512134 [用户意图]物流查询 [订单状态]已签收 [用户诉求]核实是否丢件 [等待时长]3天 Token 减少比例: 56.3% --- 多轮上下文 --- 原始文本 token 数: 132.0 压缩后 token 数: 45.0 ... Token 减少比例: 65.9%4.6 这个示例说明了什么你可以看到压缩后的文本 token 数大幅减少同时关键信息仍然完整。这里有一个值得注意的点示例中的提取规则非常简单仅仅使用了正则和关键词判断所以对自然语言的理解能力有限。在真实项目中我们应该把“自由文本转叙事槽位”的步骤交给一个轻量级 LLM 调用而不是写死正则。但为什么还要演示“写死规则”的版本因为它很好地展示了叙事约束的核心思想只要你知道哪些信息是重要的并且有能力把它们提取出来上下文压缩是水到渠成的事。正则只是能力下限LLM 提取是能力上限。方法本身没有变。5. 进阶接入 LLM 的叙事约束工作流5.1 整体流程真实项目里叙事约束压缩不能脱离 LLM。推荐的工作流如下原始文本进入用户消息、历史记录、外部数据源。LLM 结构化提取调用一个轻量级模型按 NARRATIVE_SCHEMA 提取槽位。这一步消耗少量 token但换来的是后续每一步都大幅节省 token。状态合并将新提取的槽位与已有的上下文槽位合并。合并原则是“新值覆盖旧值已有但未更新的值保留”。生成压缩上下文将最终槽位渲染为固定格式的上下文文本。送入主 LLM 推理主 LLM 拿到的是低熵、高密度的上下文。这个流程可以画成如下步骤用户输入 → LLM 槽位提取 → 状态合并 → 叙事约束上下文生成 → 主模型推理5.2 槽位提取示例 Prompt如果你用 LLM 做槽位提取可以参考下面的 Prompt 模板你是信息抽取助手。请从用户文本中抽取出以下槽位 - 订单号 - 用户意图 - 订单状态 - 用户诉求 - 等待时长 - 历史处理记录 要求 1. 只输出 JSON 格式。 2. 无法抽取的槽位输出空字符串。 3. 不要输出任何解释。 用户文本 {user_text}返回示例{ order_id: 20240512134, intent: 物流查询, order_status: 已签收, appeal: 核实是否丢件, waiting_days: 3天, history_notes: }需要注意的是这一步会消耗 token。所以在设计系统时要评估“提取开销”和“节省开销”的平衡点。根据我的经验当上下文原始 token 超过 1500 时LLM 提取的性价比就很高如果上下文本来就只有几百 token提取反而得不偿失。5.3 状态合并与上下文渲染提取之后需要一个状态合并的模块。这里以一个简单的 Python 类为例展示如何维护“系统当前状态”# -*- coding: utf-8 -*- 状态合并器 用于维护叙事约束下的系统状态 class NarrativeStateManager: def __init__(self): # 存储当前状态 self.state {} def update(self, extracted_slots: dict): 合并新提取的槽位 原则新值覆盖旧值空字符串不覆盖已有值 for key, value in extracted_slots.items(): if value: # 只更新非空值 self.state[key] value def render(self) - str: 将当前状态渲染为上下文文本 lines [] for key, value in self.state.items(): lines.append(f[{key}]{value}) return \n.join(lines) def clear_unused(self, active_keys: list): 状态裁剪只保留当前任务需要的槽位 self.state {k: v for k, v in self.state.items() if k in active_keys}这里最关键的接口是render()它输出的字符串会直接拼进主 LLM 的系统提示词或用户上下文。由于它只包含槽位和值没有多余表达所以 token 利用效率很高。5.4 上下文模板示例在实际项目中不要让主 LLM 直接面对“孤零零的槽位”而是把槽位嵌入一个固定的上下文模板。举个例子你是售后客服助手。请基于以下系统状态回答用户问题。 当前会话状态 [订单号]20240512134 [用户意图]物流查询 [订单状态]已签收 [用户诉求]核实是否丢件 [等待时长]3天 用户最新提问{user_query} 请给出简短、专业的回复。这个模板让模型在看用户最新问题之前已经掌握了全部关键背景。相比传统的“完整对话历史”方案模型需要处理的上下文缩小了很多而且由于关键信息被放在了固定位置模型更容易正确引用这些信息。6. 常见问题与排查思路6.1 压缩后信息丢失严重问题现象常见原因解决思路LLM 回答缺少关键细节槽位提取遗漏检查提取 Prompt补充槽位说明多轮信息被覆盖合并逻辑过于激进增加“多值槽位”支持保留历史版本用户意图判断错误关键词规则过于简单改用 LLM 分类或增加上下文语义判断排查优先级是先看提取环节再看合并环节最后检查渲染模板。在实际项目中多数信息丢失问题出在“提取 Prompt 设计不完整”比如没有告诉模型“需要抽取用户隐含诉求”。6.2 Token 减少不明显问题现象常见原因解决思路压缩后 token 只减少 20%槽位模板设置过宽缩小 max_length精简槽位数提取开销大于节省每次都用大模型提取改用轻量模型或批量提取历史状态没有裁剪没有调用 clear_unused按流程阶段动态维护活动槽位6.3 模型回答变得生硬这也是一个容易踩的坑。叙事约束压缩了上下文但如果太机械模型的回答会变得“机器人味”很重。原因是模型缺少了必要的对话风格信息。解决方法是把“语气风格”也作为一个固定槽位放入上下文例如[语气]专业、耐心、简洁这样既能保留叙事约束的低熵优势又不牺牲交互体验。6.4 该不该对所有场景都做叙事约束不应该。叙事约束适合结构化业务场景比如客服工单、订单处理、数据查询工具、Agent 工具调用。不适合的场景包括开放式头脑风暴、文学创作、复杂情感陪伴。判断标准很简单如果一条信息能够被明确地放进某个槽位就适合如果一条信息的价值依赖于上下文微妙表达就不适合。7. 最佳实践与工程建议7.1 槽位设计原则越少越好。每增加一个槽位都会增加提取难度和上下文占用。我建议从最多 8 个槽位开始运行一段时间后根据实际效果剪枝只保留高价值槽位。命名要统一。例如订单状态不要一会儿叫status一会儿叫order_status。统一命名可以让状态合并逻辑更简单。7.2 与 RAG 的结合如果你的项目里有 RAG检索增强生成叙事约束可以用于压缩“检索后的文档片段”。很多 RAG 方案会把检索到的 top 3 文档完整塞进上下文这些文档里大量内容与当前问题无关。你可以先让 LLM 从每篇文档中抽取与当前问题相关的槽位比如[核心结论]、[数据]、[限制条件]再做回答。这样既保留证据细节又降低 token 消耗。7.3 评估体系要跟上不要只看 token 减少比例建议同时评估三个指标关键信息完整度人工标注压缩后的文本是否包含了解决问题的必要信息。任务成功率压缩前后在测试集上的任务准确率变化。响应延迟压缩后首 token 响应时间和总响应时间的变化。7.4 安全与隐私边界压缩过程会改变信息的表达形式但不会删除权限边界。换句话说如果原始文本包含敏感信息压缩后它仍然存在。在涉及用户隐私数据的场景要对槽位提取和上下文传输过程做权限审计。同时不要让槽位提取 Prompt 暴露高风险指令。比如不要在 Prompt 里写“提取用户的身份证号”这种高风险字段。能不问就不问能不用就不用。这是隐私保护的最低要求。7.5 成本收益的动态评估最后再强调一次叙事约束不是免费的。它本身需要提取代价。在实际项目中建议你做一个简单的“成本断点”当原始上下文 token T 时不做压缩直接使用原始文本 当原始上下文 token T 时启用叙事约束压缩。T 的取值取决于你使用的提取模型和主模型的价格比例。如果提取模型足够便宜T 可以很小如果只有一个贵的模型T 就要设大一些。根据我们的经验T 在 1500 到 2000 token 之间是常见的起点。8. 总结与后续方向这篇文章从 LLM token 消耗的痛点出发介绍了语义热力学的基本思想并重点拆解了叙事约束的实现路径。你学到的不是一个现成的第三方库而是一种可以迁移到实际项目里的方法论把高熵的自由文本转换为低熵的结构化叙事状态让模型用更少的 token 做更多的事。79% 的 token 减少不是神话而是结构化场景下信息密度提升的自然结果。如果你准备在项目里尝试我的建议是从一个最细分的业务场景入手先定义 5 到 6 个关键槽位写完提取 Prompt再跑一批真实数据做对比。不要一开始就追求完美的通用方案先用小范围实验验证收益再逐步扩大覆盖场景。关于后续学习方向有两条线可以跟进线一语义热力学理论可以继续深入研究信息论中的熵、互信息、KL 散度理解为什么“减少不确定度”能直接转化为模型性能提升。线二工程落地方案关注 LangChain、LlamaIndex 等框架中关于长期记忆、token 压缩、状态管理的模块看看别人如何把这些思想工程化。如果你在落地过程中遇到了“压缩后回答质量下降”或“槽位提取不稳定”的问题欢迎在评论区留言交流。这类问题往往和具体业务场景强相关需要针对性分析但解决路径大多是一致的先定位是提取、合并还是渲染环节的问题再对症下药。下一篇我准备拆解一个更完整的案例——在一个真实的客服 Agent 里如何用叙事约束设计多轮状态管理欢迎保持关注。