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 从一开始就定了一个原则：优化器必须理解内容，而不是机械裁剪。它至少要做两件事：

1. 判断每一段内容的重要性——哪些是核心信息，哪些是冗余表达；
2. 执行差异化的压缩策略——重要的内容保留细节，次要的内容做压缩摘要，无关的内容直接裁掉。

2.2 分层压缩策略的设计逻辑

基于上面的原则，我把压缩策略拆成三个层级：

无损层（Level 1）：只做格式和表达层面的清理，不改动任何语义信息。包括去掉多余换行和空格、合并重复的指令、删除无意义的语气词、统一专有名词的表述方式。这一层压缩率大概在 5% 到 15% 之间，质量损失为零。

浅压缩层（Level 2）：识别上下文中的冗余表达和低信息密度句子，做保留式精简。比如把“根据我们的用户协议，在货物发出后的十五个自然日内，买家有权提出退货申请，只要货物处于未使用状态且包装完好”压缩成“用户协议：发货后15日内可按条款退货（须未使用、包装完好）”。这一层不改变任何事实信息，只是把表达方式精简掉。压缩率通常在 25% 到 40%。

深压缩层（Level 3）：针对低优先级内容做语义摘要。比如历史对话中的寒暄部分、检索片段中的背景介绍、上一轮已经解决过的问题讨论。这些内容不是完全没用，但不需要保留原文细节，只需要保留核心信息指向。说白了就是“我记得你之前说过想买 5000 元以内的机械键盘”而不是原文复述整段需求。这一层压缩率可以做到 60% 到 75%，代价是要消耗一次额外的摘要请求。

这三层并不是对整段上下文统一执行的，而是分层作用于不同段落。这里就引出了整个系统最关键的设计：优先级评估器。

2.3 优先级评估器的核心作用

优先级评估器解决的核心问题是：哪段内容值得保留？哪段可以压缩？哪段可以直接扔掉？

我在实现里使用了一个两层评估方案。

第一层是基于规则的信号打分。每段内容进来之后，从几个维度打基础分：

• 新鲜度：距离当前时间越近的内容，分越高；
• 关联度：与当前问题的文本相似度，分越高；
• 类型特征：系统指令权重最高，用户当前问题次之，检索到的文档片段按命中分数加权，历史问答按时间衰减；
• 实体密度：包含的专有名词、数字、金额、日期等硬信息越多，分越高。

第二层是模型辅助的语义打分。对于规则打分结果处在“边缘模糊区”的内容（比如基础分落在 0.4 到 0.6 之间），用一个小模型做二次判断，输出一个“保留必要性”评分。这样做的好处是避免在非关键内容上浪费压缩调用的成本——边缘内容占比通常不到 10%，只对这部分额外请求模型，性价比最高。

拿到每个段落的分数之后，系统就按照预设阈值来决定压缩级别：

• 分数 ≥ 0.75：Level 1，无损清理；
• 分数在 0.4 到 0.75：Level 2，精简压缩；
• 分数在 0.15 到 0.4：Level 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.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.10+
• OpenAI SDK（或任何兼容的 LLM API SDK）
• NumPy 和 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_text=text) response = call_model(self.model, prompt, temperature=self.temperature) return CompressedSegment(response, original=text, level="L3")

实测下来，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_workers=4) 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( model="gpt-4o", messages=build_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(model="gpt-4o", messages=final_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 压缩耗时过长

症状：接入优化器后，虽然上下文变小了，但用户感知的整体延迟反而增加了。原因当然是压缩过程本身消耗时间。

排查思路：分阶段测耗时。分段阶段通常是毫秒级，评估阶段如果调用了模型就会产生网络开销，压缩阶段更是大头。用日志把各阶段耗时打印出来，定位瓶颈。

解决方案：几个有效的优化手段，按效果排序：

1. 并行化压缩（前面写过，效果最直接）；
2. 缓存高频内容的压缩结果；
3. 把优先级评估里的语义相似度计算换成预计算好的嵌入向量；
4. 对于轻量级场景，用本地的小模型替代 API 调用来做摘要。

我做了一轮优化之后，单次压缩的平均耗时从 850ms 降到了 560ms，其中并行化贡献最大。

5.5 公共配置速查表

这套配置在我的生产环境里运行稳定，但强烈建议你根据自己的业务数据做微调。特别是优先级阈值，直接决定压缩率和质量之间的平衡点，应该在你的历史数据上做回归验证后再定。

6. 踩坑总结与个人体会

拖到最后一个主题，聊点实在的体会。

我上手做 Model-Optimizer 的时候，第一版方案想得太简单：以为核心就是写压缩 prompt。结果发现，真正的难点不在压缩本身，而在“什么时候不压缩”。优先级评估的准确性，决定了这个系统的上限。压缩器写得再好，如果评估器把关键内容判成低优先级，一切白搭。

第二点体会是：质量评估体系要先于优化器上线。我最开始犯了顺序错误，先把优化器跑起来了，然后才去想怎么评估效果。结果就是出了线上问题之后，花了不少时间复盘。现在这套体系里，信息召回率测试集和主观评分双轨并行，每次调整策略都要先过测试集，再小流量放量验证。顺序对了，效率高很多。

第三点是干这行的常识：没有一个优化器可以一套配置跑遍所有场景。QA、CoT、few-shot、agent，不同类型的上下文，文字的“信息密度”分布完全不同。你需要为自己的场景定义“什么是有用信息”，然后把这种判断落进评分规则里。这不是纯技术问题，更像是对业务的深度理解。

目前这个优化器在我的生产环境里已经稳定运行了两个多月。除了成本下降，另一个意外收获是——上下文变短之后，模型输出的一致性反而变好了。因为我们顺手清掉了大量冗余的、来自多轮历史记录的干扰信息，模型的注意力更集中。这也算是个小启发：有时候问题不是模型不够聪明，而是我们喂给它的东西太杂了。

如果你正准备给自己的 LLM 应用做类似优化，我的建议是从小处开始：先让你的应用支持“上下文计数”，搞清楚每次调用到底烧了多少 token，哪些内容占比最大。然后再考虑引入优化器。盲目上系统之前，先把问题量化出来，方向就不会跑偏。