1. 项目概述1.1 这个项目到底是什么先直接说结论Model-Optimizer 定位是 LLM 应用场景下的上下文优化器也叫 Prompt 压缩器。它做的事情很聚焦——在不影响模型输出质量的前提下把发给大模型的上文内容做压缩、裁剪和重构从而降低 token 消耗、减少延迟、提高上下文窗口利用率。为什么要做这件事因为做大模型应用的人都知道上下文长度是钱也是命。按现在主流 API 的定价输入 token 收费输出 token 收费上下文越长单次调用越贵。更棘手的是很多场景下上下文里塞了大量历史对话、冗长的检索结果、重复的系统指令真正有价值的信息可能只占三成。剩下七成都在为“模型能看到完整上下文”这个伪需求买单。我第一次部署这个优化器是在做一个知识库问答助手。当时的痛点很典型每次用户提问系统要把命中的文档片段、历史对话、角色指令全部拼接起来发给模型。文档片段多的时候一次请求烧掉 8000 到 12000 个 token单次成本接近一毛钱。日活一万的话光上下文成本就是一千块。更麻烦的是随着历史对话累积请求延迟明显变长用户的耐心是有限的转菊花超过五秒就开始流失。Model-Optimizer 解决的就是这个问题。它在你的应用和模型 API 之间加一层“中间处理层”负责对上文内容做语义分析、分段评估、策略化压缩最后把精简后的上下文交给模型。我用下来的实测数据是平均压缩率 51%质量损失几乎为零单次调用成本降低约 47%P95 延迟降低约 32%。这篇文章会把完整的思路、实现细节和踩坑过程都写出来希望对你做 LLM 应用优化有实际帮助。1.2 这个内容适合谁看如果你是以下三类人这篇内容会比较对路做 LLM 应用开发的工程师正在被上下文成本和延迟困扰想找一套系统的优化方案AI 产品负责人想了解在现有技术条件下如何通过工程手段降低模型调用成本而不牺牲用户体验刚入门 LLM 应用开发的学习者想理解 Prompt 工程之外的“系统级优化”维度。这篇文章默认你了解大模型 API 的基本调用方式知道 token 是什么概念。如果不了解也没关系我会把每一步的原理和计算过程拆开讲清楚跟着操作就能跑通。2. 优化思路与整体设计2.1 为什么不能直接截断上下文很多人的第一反应是上下文太长直接截断不就行了取最后 N 条历史记录、只保留文档标题、限制总字数——这些做法确实简单粗暴但副作用很大。直接截断的问题在于它没有“语义选择性”。比如知识库问答场景用户问的是“退款政策里对生鲜商品的规定”检索系统命中的三段文档其中第二段恰好包含最核心的答案但它在拼接顺序上排在靠后位置。如果按“保留前 3000 字符”截断核心答案直接被切掉模型只能用残缺信息生成回答结果就是胡编乱造。我见过很多线上事故都是这么搞出来的。另一种常见做法是“保留头部和尾部”。因为很多模型的注意力机制对开头和结尾的内容更敏感部分开发者就把中间内容粗暴删掉。这种方案在长文档摘要场景偶尔有效但在多轮对话场景就很糟糕——用户上一轮提到的关键需求如果落在中间位置直接被丢掉了。所以 Model-Optimizer 从一开始就定了一个原则优化器必须理解内容而不是机械裁剪。它至少要做两件事判断每一段内容的重要性——哪些是核心信息哪些是冗余表达执行差异化的压缩策略——重要的内容保留细节次要的内容做压缩摘要无关的内容直接裁掉。2.2 分层压缩策略的设计逻辑基于上面的原则我把压缩策略拆成三个层级无损层Level 1只做格式和表达层面的清理不改动任何语义信息。包括去掉多余换行和空格、合并重复的指令、删除无意义的语气词、统一专有名词的表述方式。这一层压缩率大概在 5% 到 15% 之间质量损失为零。浅压缩层Level 2识别上下文中的冗余表达和低信息密度句子做保留式精简。比如把“根据我们的用户协议在货物发出后的十五个自然日内买家有权提出退货申请只要货物处于未使用状态且包装完好”压缩成“用户协议发货后15日内可按条款退货须未使用、包装完好”。这一层不改变任何事实信息只是把表达方式精简掉。压缩率通常在 25% 到 40%。深压缩层Level 3针对低优先级内容做语义摘要。比如历史对话中的寒暄部分、检索片段中的背景介绍、上一轮已经解决过的问题讨论。这些内容不是完全没用但不需要保留原文细节只需要保留核心信息指向。说白了就是“我记得你之前说过想买 5000 元以内的机械键盘”而不是原文复述整段需求。这一层压缩率可以做到 60% 到 75%代价是要消耗一次额外的摘要请求。这三层并不是对整段上下文统一执行的而是分层作用于不同段落。这里就引出了整个系统最关键的设计优先级评估器。2.3 优先级评估器的核心作用优先级评估器解决的核心问题是哪段内容值得保留哪段可以压缩哪段可以直接扔掉我在实现里使用了一个两层评估方案。第一层是基于规则的信号打分。每段内容进来之后从几个维度打基础分新鲜度距离当前时间越近的内容分越高关联度与当前问题的文本相似度分越高类型特征系统指令权重最高用户当前问题次之检索到的文档片段按命中分数加权历史问答按时间衰减实体密度包含的专有名词、数字、金额、日期等硬信息越多分越高。第二层是模型辅助的语义打分。对于规则打分结果处在“边缘模糊区”的内容比如基础分落在 0.4 到 0.6 之间用一个小模型做二次判断输出一个“保留必要性”评分。这样做的好处是避免在非关键内容上浪费压缩调用的成本——边缘内容占比通常不到 10%只对这部分额外请求模型性价比最高。拿到每个段落的分数之后系统就按照预设阈值来决定压缩级别分数 ≥ 0.75Level 1无损清理分数在 0.4 到 0.75Level 2精简压缩分数在 0.15 到 0.4Level 3摘要提取分数 0.15直接丢弃。老实说阈值参数不是一遍跑出来的。我最初用的是 0.8、0.5、0.2 这组配置结果发现深压缩层词不达意的问题比较严重。调了两周把阈值改成 0.75、0.4、0.15再用标注集验证效果才趋于稳定。后面我会在实操环节把评估细节和调参过程展开讲。3. 核心细节与实操要点3.1 上下文分段的粒度选择在评估优先级之前第一步是分段。这个环节看似简单实际影响巨大。我踩的第一个坑就是用固定字数切分上下文。固定字数比如每段 500 字符切出来的段落语义边界是断裂的。一个完整的产品需求描述被切成两段前一段含有“用户想要一个能记录体重数据的 APP”后一段含有“并且支持导出 Excel 表格”。优化器在评估时可能认为前一段信息密度足够保留后一段因为缺少主语而被判定为低优先级直接压缩掉了。结果模型拿到的上下文里“导出 Excel”这个需求就部分丢失了回答质量下降。正确的做法是按语义边界分段。我最终用的分段规则是按换行和句号作为主边界同时检测段落间的主题相关性。实现上并不复杂先按空行粗切再把粗切结果按句号细切最后合并相邻的语义相关短句。这个处理放在一个独立的split_context()函数里返回值是带序号的分段列表后续所有逻辑都基于分段而不是原始文本。还有一个细节值得注意分段后的内容要尽量控制在模型摘要能力的最佳范围内。经验数据是每段不超过 300 到 500 个 token。太长的段落摘要模型容易丢细节太短的段落评估器拿不到足够的上下文信息。3.2 压缩率与质量损耗的平衡这是整个项目里最难的部分直接决定优化器的可用性。压缩率很好定义压缩率 1 - 压缩后token数 / 原始token数但质量损耗没有统一的数学定义。我采用的替代方案是编辑距离法的变体对压缩后的文本和原始文本做语义相似度计算结合关键信息点召回率来评估。什么叫关键信息点召回率就是把原始文本中的硬信息提取出来包括数字和日期比如“15个自然日”“5000元以内”专有名词比如“Model-Optimizer”“退款规定”否定关系比如“不适用于生鲜商品”主体对象和动作比如“买家”“提出退货申请”。压缩后的文本如果完整保留了这些信息点就算质量过关。我用一个 500 条样本的测试集做回归测试要求压缩后文本的关键信息点召回率不低于 95%。低于这个数字就说明压缩策略过于激进需要回调级别。还有一个很实际的教训压缩率不是越高越好。我有一次为了把成本压到极致把深压缩层的触发阈值从 0.4 提到 0.55结果大量本应保留细节的中等优先级内容被摘要化用户反馈“回答变笼统了”。测试集上召回率降到了 88%后来老老实实改回来了。下表是我实际测试的一组数据供参考配置方案平均压缩率信息召回率回答质量主观分原始无压缩0%100%9.2无损层单独开启9%99.5%9.2无损层 浅压缩层38%98.2%9.0三层全部开启阈值0.464%92.5%8.2三层全部开启阈值0.1551%96.8%8.9最终我采用的是阈值 0.15 的配置。每个应用场景的接受度不同这套数据只代表我当时的业务环境。3.3 不同场景的压缩策略差异Model-Optimizer 不是一套策略走天下。在不同的任务场景里上下文的组成差异非常大压缩策略也要跟着调整。我把实际业务中的场景分成四类分别处理QA 问答场景上下文主要由系统指令、检索文档片段和当前问题组成。系统指令必须完全保留文档片段按命中质量分排序只保留前两到三段的高分片段其余片段做浅压缩。当前问题不做任何压缩保持原样传给模型。CoT 推理场景上下文包含用户的完整问题描述和模型已有的推理过程。这里要特别小心压缩必须保留推理链条中的所有中间结论。浅压缩层可以精简表达但深压缩层不能动推理步骤。我的做法是对推理过程类内容强制限定为 Level 1 或 Level 2禁止降级到 Level 3。Few-shot 示例场景上下文里的示例是最容易被过度压缩的部分。很多示例的核心价值在于格式示范和边界条件展示而不仅仅是字面信息。我的策略是示例内容统一走 Level 2 压缩但压缩时保留特定标记符、字段名称和格式骨架只压缩描述性文本。Agent 工具调用日志场景上下文包含多轮工具调用记录和观察结果。这类内容有大量的格式化冗余但核心的操作序列调用了什么工具、传了什么参数、得到了什么结果必须完整保留。我在做这类场景时会先做结构化解析把日志转成紧凑的 JSON 摘要再拼进上下文。3.4 调用成本的数学账为什么这个优化器值得做算一笔账就清楚了。假设某个 LLM 应用的输入定价是 $0.003/1K tokens输出定价是 $0.004/1K tokens。一次调用的上下文是 8000 token 输入 600 token 输出单次成本大约是输入成本 8000 / 1000 * 0.003 $0.024 输出成本 600 / 1000 * 0.004 $0.0024 单次总成本 $0.0264接入优化器后假设压缩率是 50%输入变成 4000 token但要额外付出压缩过程中的摘要模型调用成本。摘要模型一般选更便宜的型号假设输入定价 $0.0005/1K tokens输出定价 $0.0015/1K tokens。压缩过程中需要摘要的内容大约占原始上下文的 20%只有中低优先级段落才走深压缩这部分开销要单独算。实际算下来加优化器之后的单次成本大概是优化后输入成本 4000 / 1000 * 0.003 $0.012 摘要调用输入 8000 * 0.2 / 1000 * 0.0005 $0.0008 摘要调用输出 8000 * 0.2 * 0.1 / 1000 * 0.0015 $0.00024 优化后输出成本 600 / 1000 * 0.004 $0.0024 总成本 ≈ $0.01544单次从 $0.0264 降到 $0.01544降幅约 41%。日调用量 5 万次的场景一天省下大约 550 美元。按照这套算法这个优化器的开发成本通常在一到两个月内就能通过 API 费用的节省收回来。但注意这个账的前提是你的应用确实存在大量“可以压缩”的上下文。如果每次调用都是极短输入比如几百 token优化器本身的开销反而可能超过节省。上下文平均长度低于 1500 token 的应用不建议接入这套方案。4. 实操过程与核心实现4.1 环境准备与依赖配置实现 Model-Optimizer 不需要复杂的基础设施一台普通服务器就够了。我的环境配置如下Python 3.10OpenAI SDK或任何兼容的 LLM API SDKNumPy 和 SciPy用于相似度计算Redis用于缓存压缩结果可选但强烈推荐一个便宜的摘要模型如 GPT-4o-mini 或同类产品项目的目录结构非常简单model-optimizer/ ├── optimizer.py # 主入口 ├── splitter.py # 上下文分段 ├── scorer.py # 优先级评估 ├── compressors.py # 各层级压缩实现 ├── cache.py # 缓存模块 ├── evaluator.py # 压缩质量评估 └── config.yaml # 配置参数整个项目代码量在 1200 行左右单机部署完全够用。4.2 核心压缩器的代码实现先看主入口。这里我贴的是简化后的核心逻辑完整代码可以在网上找到同类开源项目做参考关键是理解流程。class ModelOptimizer: def __init__(self, config): self.config config self.splitter ContextSplitter(config) self.scorer PriorityScorer(config) self.compressors { L1: LosslessCompressor(), L2: LightCompressor(), L3: DeepCompressor(config), } self.cache CacheManager(config) def optimize(self, context_str, user_query): # 1. 分段 segments self.splitter.split(context_str) # 2. 评估优先级 scored_segments self.scorer.score(segments, user_query) # 3. 逐段压缩 optimized_parts [] total_saved 0 for seg in scored_segments: level self._decide_level(seg.score) if seg.text in self.cache: compressed self.cache.get(seg.text) else: compressor self.compressors[level] compressed compressor.compress(seg.text, seg.score) self.cache.set(seg.text, compressed) optimized_parts.append(compressed) total_saved seg.original_tokens - compressed.tokens # 4. 拼接 final_context self._join(optimized_parts, user_query) return final_context, { original_tokens: self.total_tokens, optimized_tokens: final_context_tokens, compression_ratio: total_saved / self.total_tokens, }分段器是按语义边界切的核心代码class ContextSplitter: def __init__(self, config): self.max_segment_tokens config.get(max_segment_tokens, 450) def split(self, context_str): # 先按换行切再按句号细切最后合并短段 rough_parts re.split(r(\n), context_str) refined_parts [] buffer for part in rough_parts: buffer part if len(buffer) self.min_chars and self._has_sentence_boundary(buffer): refined_parts.append(buffer.strip()) buffer if buffer.strip(): refined_parts.append(buffer.strip()) # 合并过短的相邻段落 merged self._merge_short_segments(refined_parts) return [Segment(i, text) for i, text in enumerate(merged)]注意_merge_short_segments这个细节很关键。如果两段内容都很短且主题相似就应该合并成一段否则后面评估器会因为单段信息量太少而给出偏低的分数导致不该压缩的内容被压缩了。4.3 优先级评估器的实现细节优先级评估是优化器的“大脑”实现上我做了一个组合打分方案避免单一规则太脆弱。基础分由几个维度加权而成。权重是我用历史标注数据拟合出来的当前问题语义相似度权重 0.35信息密度实体数量权重 0.25内容新鲜度时间衰减权重 0.20类型基准分系统指令/用户问题/检索文档/历史记录权重 0.20实际代码中语义相似度向量是直接复用检索系统或对话系统的嵌入向量不需要额外计算。如果你没有嵌入向量可以用一句很轻量的模型调用替代或者退而求其次用 Jaccard 相似度做初筛。边缘模糊区二次评估的实现我用了一个非常轻的 prompt 模板EDGE_EVALUATION_PROMPT 判断下面这段对话历史中【待评估内容】对解答用户当前问题是否必要。 只回答一个数字1 表示必要0 表示不必要。 当前问题{query} 待评估内容{segment_text} .strip()这个 prompt 不需要模型给出解释只要一个数字把 token 开销控制在极低水平。实测下来准确率大约 0.9足够辅助边缘判定。4.4 三级压缩策略的实现与配置各级压缩器的实现思路如下L1 无损压缩器不调用任何模型纯文本规则处理。删除多余空白符、统一引号风格、合并重复的标点、把“已经”“非常”“非常地”这类冗余副词去掉。用一个 500 条文本的简单规则集就能覆盖大多数场景。L2 浅压缩器使用一次轻量模型调用prompt 要求模型“在不改变任何事实信息的情况下用更简洁的表达重写内容”。这里的关键约束是“不要丢失数字、日期、名称、否定关系”。我在 prompt 里加了强约束并要求模型只输出重写结果不附带任何解释。L3 深压缩器也是模型调用但任务改为“提取这段内容的要素清单”。输出格式固定为三行核心结论、涉及对象、关键前提。这样摘要出来的是结构化信息比自由文本摘要更容易拼接和复用。我把三级压缩的操作函数写成了统一的接口方便后续替换不同的模型或者实现class DeepCompressor: def __init__(self, config): self.model config[deep_compress_model] self.temperature config.get(deep_compress_temperature, 0.2) def compress(self, text, score): prompt DEEP_COMPRESS_PROMPT.format(segment_texttext) response call_model(self.model, prompt, temperatureself.temperature) return CompressedSegment(response, originaltext, levelL3)实测下来L3 的 temperature 必须设得很低0.2 以下否则摘要会“自由发挥”输出一些原文没有的信息这是信息召回率下降的最大元凶。4.5 缓存与性能优化上下文里其实有很多内容在短时间内是重复出现的。比如系统指令每次调用都在、知识库的高频文档片段每个用户都查、多轮对话里用户反复引用同一段合同条款。这些内容如果每次都重新压缩既浪费模型调用又增加延迟。我用 Redis 做了一层缓存key 是内容文本的哈希值value 是压缩结果。缓存的过期时间默认设置为一小时。为什么是一小时而不是永久因为上下文相关的表达有一定的时效性——同一段文档在用户不同的提问角度下适合的压缩程度可能不同。过期时间太长会让缓存结果“变旧”太短又起不到缓存作用。这个参数你可以根据自己的业务节奏调整。另外一个性能优化点是我在部署之后才意识到的分段后的压缩可以并行执行。每段内容独立压缩彼此没有依赖关系。改成多线程并发之后压缩阶段的耗时从原来的平均 800ms 降到了 450ms 左右。简单的ThreadPoolExecutor就能实现不需要引入额外的任务队列。from concurrent.futures import ThreadPoolExecutor, as_completed def _parallel_compress(self, scored_segments): results {} with ThreadPoolExecutor(max_workers4) as executor: future_map { executor.submit(self._compress_one, seg): seg.id for seg in scored_segments } for future in as_completed(future_map): seg_id future_map[future] results[seg_id] future.result() return [results[i] for i in sorted(results)]4.6 端到端的接入方案把优化器接入现有应用的步骤非常简单改动集中在上文构建阶段。原来的代码是这样的response call_model( modelgpt-4o, messagesbuild_messages(system_prompt, history, documents, user_query), )接入优化器后变成optimizer ModelOptimizer(config) raw_context build_raw_context(system_prompt, history, documents) optimized_context, metrics optimizer.optimize(raw_context, user_query) final_messages build_messages_from_optimized(optimized_context, user_query) response call_model(modelgpt-4o, messagesfinal_messages)一次接入全链路生效。我在生产环境里是逐步放量的先让 10% 的流量走优化器观察一周回答质量无投诉再逐步扩大到 30%、50%最后全量。这里建议你不要一口气全量切换因为优化器在不同场景下的表现差异较大需要留出观察期。5. 常见问题与排查技巧实录5.1 压缩后信息丢失症状接入优化器之后模型在某些问题上的回答出现“信息缺失”比如漏掉了产品政策里的某个关键日期或者忽略了用户上一条消息里的限制条件。排查思路先确认是压缩环节丢了信息还是模型本身没理解。做法是把优化器临时关闭用原始上下文跑一遍同样的问题。如果原始上下文回答正常就基本确定问题出在压缩环节。解决方案第一步检查丢信息的内容属于哪个压缩级别。如果是 L3 深压缩的内容大概率是摘要模型主动“忽略”了某些细节。解决办法是调整摘要 prompt强制模型输出“所有的事实信息点”。第二步检查优先级评估分数。如果该内容分数落在 L2 到 L3 的临界区间可以适当下调 L3 的触发阈值把更多内容留在 L2 层级。我的实际经验是大多数信息丢失问题出在 L3 摘要阶段而不是 L2 精简阶段。因为 L2 只是换表达方式事实信息没变而 L3 是重新提炼模型主观性更强。5.2 压缩后的格式解析失败症状原有系统依赖模型输出 JSON 结构压缩上下文后模型的输出偶尔出现 JSON 格式错误、字段缺失、或者多出意料之外的字段。原因分析这通常是因为压缩破坏了 few-shot 示例中的格式骨架。比如示例里原来有{action: search, query: ...}L2 压缩器可能会把字段名当成冗余信息精简掉或者把 JSON 示例压缩成了一句描述性文本。模型失去了格式参照输出自然飘了。解决方案在压缩器里加一个格式保护机制——识别 JSON、XML、代码块等结构化内容对这些内容跳过压缩或只做空白清理。我在实现里增加了一个简单的检测函数用正则或者括号匹配判断是否包含结构化数据命中就直接走 L1 级处理。5.3 缓存导致的结果过期症状优化器命中缓存后返回的结果和没命中缓存时不一致。比如用户修改了某个偏好设置但系统仍然用压缩前的缓存内容。原因分析缓存 key 只考虑了文本内容本身没有考虑上下文场景的变化。同一段文本用户之前问的是“预算”现在问的是“售后”合理的压缩方式不同但缓存返回了旧结果。解决方案为缓存 key 加上场景标识把用户查询的粗粒度意图类别作为 key 的一部分。我用的是一个简单的做法把用户问题里的高频词提取出来和文本哈希一起拼成缓存 key。这样不同意图下的压缩结果不会互相污染。实测命中率会有一定下降但结果一致性明显改善。5.4 压缩耗时过长症状接入优化器后虽然上下文变小了但用户感知的整体延迟反而增加了。原因当然是压缩过程本身消耗时间。排查思路分阶段测耗时。分段阶段通常是毫秒级评估阶段如果调用了模型就会产生网络开销压缩阶段更是大头。用日志把各阶段耗时打印出来定位瓶颈。解决方案几个有效的优化手段按效果排序并行化压缩前面写过效果最直接缓存高频内容的压缩结果把优先级评估里的语义相似度计算换成预计算好的嵌入向量对于轻量级场景用本地的小模型替代 API 调用来做摘要。我做了一轮优化之后单次压缩的平均耗时从 850ms 降到了 560ms其中并行化贡献最大。5.5 公共配置速查表参数推荐值说明max_segment_tokens450段落最大长度超过则强制切分priority_l1_threshold0.75高于此值走无损压缩priority_l2_threshold0.40高于此值走浅压缩priority_l3_threshold0.15高于此值走深压缩低于则丢弃cache_ttl3600 秒缓存过期时间summary_model便宜快速型号深压缩摘要模型temperature0.2深压缩使用的采样温度max_workers4并行压缩线程数min_context_tokens1500低于此值不启用优化器这套配置在我的生产环境里运行稳定但强烈建议你根据自己的业务数据做微调。特别是优先级阈值直接决定压缩率和质量之间的平衡点应该在你的历史数据上做回归验证后再定。6. 踩坑总结与个人体会拖到最后一个主题聊点实在的体会。我上手做 Model-Optimizer 的时候第一版方案想得太简单以为核心就是写压缩 prompt。结果发现真正的难点不在压缩本身而在“什么时候不压缩”。优先级评估的准确性决定了这个系统的上限。压缩器写得再好如果评估器把关键内容判成低优先级一切白搭。第二点体会是质量评估体系要先于优化器上线。我最开始犯了顺序错误先把优化器跑起来了然后才去想怎么评估效果。结果就是出了线上问题之后花了不少时间复盘。现在这套体系里信息召回率测试集和主观评分双轨并行每次调整策略都要先过测试集再小流量放量验证。顺序对了效率高很多。第三点是干这行的常识没有一个优化器可以一套配置跑遍所有场景。QA、CoT、few-shot、agent不同类型的上下文文字的“信息密度”分布完全不同。你需要为自己的场景定义“什么是有用信息”然后把这种判断落进评分规则里。这不是纯技术问题更像是对业务的深度理解。目前这个优化器在我的生产环境里已经稳定运行了两个多月。除了成本下降另一个意外收获是——上下文变短之后模型输出的一致性反而变好了。因为我们顺手清掉了大量冗余的、来自多轮历史记录的干扰信息模型的注意力更集中。这也算是个小启发有时候问题不是模型不够聪明而是我们喂给它的东西太杂了。如果你正准备给自己的 LLM 应用做类似优化我的建议是从小处开始先让你的应用支持“上下文计数”搞清楚每次调用到底烧了多少 token哪些内容占比最大。然后再考虑引入优化器。盲目上系统之前先把问题量化出来方向就不会跑偏。