context-optimization

上下文优化

上下文优化是指精炼为 AI 模型整理的原始上下文，让每个 token 都能为任务提供有意义的信息。在典型的 RAG 或 Agent 工作流中，检索到的上下文往往包含冗余段落、相关性不高的片段，以及排序不佳的信息。优化会将这些原始材料转化为精简、高信号的上下文块，从而提升回答质量、降低推理成本，并充分利用模型的注意力预算。

工作流

1. 审查原始上下文：盘点已收集的每一项上下文——检索到的文档、对话历史、工具输出和元数据。计算 token 总数，并与可用的上下文预算进行比较。如果原始上下文超出预算，则确定所需的压缩比例。

2. 去除重叠内容：扫描上下文，查找传达相同信息的近似重复段落。在 RAG 工作流中，这种情况很常见：分块时设置重叠会导致多个片段覆盖同一段落，或者多个源文档重复相同的事实。使用语义相似度（余弦距离 > 0.92）或精确的 n 元语法重叠检测来识别重复项，然后只保留每条信息最完整的版本。

3. 评估相关性和信息密度：为每个上下文片段分配两个分数：相关性分数（与当前查询的关联程度）和信息密度分数（每个 token 所传达的有用事实数量）。相关性可以通过检索分数或轻量级交叉编码器处理来衡量。信息密度可以通过统计命名实体、代码标识符、数值数据和关键词相对于片段长度的比例来估算。将两个分数相乘，得到综合效用分数。

4. 过滤低价值内容：移除综合效用分数低于阈值的片段。一个不错的起点是保留效用分数排名前 60-70% 的片段。同时移除不提供任何信息的模板文本（版权声明、导航菜单、重复的标题）。采取保守策略——保留相关性一般的片段，也好过遗漏关键信息。

5. 按优先级重新排序：对剩余片段排序，最大限度地利用模型的注意力。将效用最高的片段放在最前面（模型对上下文开头的关注度最高），并将第二高的片段放在接近末尾的位置（模型也会关注较新的信息）。避免将关键信息埋在较长上下文块的中间——这是模型注意力最弱的“中间遗失”区域。

6. 验证覆盖范围：过滤并重新排序后，确认优化后的上下文仍涵盖查询的所有方面。如果查询包含多个子问题，请确保至少有一个片段涉及每个子问题。如果发现覆盖缺口，则有选择地重新加入此前过滤掉、能填补缺口的片段，即使它们的效用分数低于阈值也不例外。

技术

• 去重：通过语义相似度阈值或 n-gram 重叠检测，识别并移除冗余段落。在 RAG 流水线中至关重要，因为重叠的分块往往会重复相同的句子。保留内容最完整或得分最高的版本。
• 相关性过滤：移除相关性低于阈值的分块。以原始检索得分、重排得分或与查询的关键词重叠度作为判断信号。应调整过滤力度——过滤过严会造成覆盖缺口。
• 信息密度评分：估算每个分块包含的有用信息量与 token 数的比值。优先选择信息密集的分块（包含大量事实、代码或数据），而不是冗长、密度低的文本。当两个分块的相关性得分相近时，可据此决定保留哪一个。
• 基于优先级排序：排列分块，让模型先看到最重要的信息，并在末尾再次看到重要信息，以避免“中间遗失”效应。对于较长的上下文窗口（32K+ tokens），这一点尤为重要，因为注意力衰减会更加明显。
• 上下文窗口策略：不同的模型上下文窗口需要采用不同的优化方法。对于较小的窗口（4K tokens），必须积极过滤和压缩。对于中等大小的窗口（32K），应侧重去重和排序。对于较大的窗口（128K+），排序和密度评分最为重要，因为虽然可以容纳更多内容，但“中间遗失”效应也会加剧。

用法

提供原始上下文（由文本分块组成的列表，可附带元数据和得分）、用户查询以及目标 token 预算。该技能会返回优化后的上下文块——完成去重、过滤、评分和重新排序，可直接用于组装提示词。也可以提供覆盖检查清单（列出上下文必须涵盖的关键主题），以防重要信息被过滤掉。

示例

示例 1：为多文件代码编辑任务优化上下文

任务：“将身份验证模块重构为使用 async/await，而不是回调。”

原始上下文（7 个分块，约 4,200 tokens）：

#	来源	相关性	密度	内容摘要
1	src/auth/login.js:1-45	0.93	高	使用基于回调的 db.findUser() 的登录函数
2	src/auth/login.js:20-55	0.90	高	重叠分块——与分块 1 重复第 20-45 行，并添加了令牌刷新逻辑
3	src/auth/middleware.js:1-30	0.88	高	使用基于回调的令牌验证的身份验证中间件
4	README.md:100-130	0.45	低	项目设置说明——没有代码，也没有身份验证细节
5	src/auth/register.js:1-40	0.82	高	使用回调的注册函数
6	package.json:1-25	0.35	低	依赖项列表——没有与身份验证相关的逻辑
7	src/auth/login.js:40-70	0.91	高	使用回调进行令牌生成和会话创建

优化步骤：

1. **去重：**分块 1 和 2 在第 20-45 行重叠。将它们合并为一个分块，涵盖 login.js 的第 1-55 行。
2. **过滤：**移除分块 4（README 设置说明，相关性 0.45）和分块 6（package.json，相关性 0.35）——低于 0.50 的阈值。
3. **重新排序：**将合并后的 login.js 分块放在最前面（相关性最高），然后是令牌生成分块、middleware.js，最后是 register.js。

优化后的上下文（约 2,800 tokens，减少 33%）：

1. src/auth/login.js:1-55（已合并）——使用基于回调的数据库查询和令牌刷新的登录函数
2. src/auth/login.js:40-70——令牌生成和会话创建
3. src/auth/middleware.js:1-30——使用回调进行令牌验证的身份验证中间件
4. src/auth/register.js:1-40——使用回调的注册函数

示例 2：优化 RAG 检索到的上下文，消除冗余

查询：“公司的电子产品退货政策是什么？”

原始检索片段（6 个片段，约 3,000 个 token）：

1. returns-policy.md（得分 0.95）--“从本店购买的电子产品可在购买后 30 天内退货。商品必须保留原包装和所有配件。已拆封商品需支付 15% 的重新入库费。”
2. faq.md（得分 0.88）--“问：我可以退电子产品吗？答：可以，在 30 天内退货即可。商品必须保留原包装。已拆封商品需支付 15% 的重新入库费。详情请参阅我们的退货政策。”
3. holiday-policy.md（得分 0.72）--“在节日期间（11 月 15 日至 1 月 15 日），所有商品（包括电子产品）的退货期限延长至 60 天。其他条件不变。”
4. shipping-info.md（得分 0.40）--“我们通过投保的陆运方式运送电子产品。配送需要 3-7 个工作日。”
5. returns-policy.md（得分 0.85）--“退款将在 5-10 个工作日内退回至原支付方式。瑕疵商品免收重新入库费，可在 90 天内退货。”
6. store-locator.md（得分 0.30）--“欢迎前往我们在全国的 200 家零售门店。”

优化步骤：

1. **去重：**片段 1 和 2 传达的信息几乎相同（30 天退货期限、原包装、15% 费用）。保留片段 1（得分更高，来源更权威）。
2. **筛选：**移除片段 4（配送信息，与退货无关，得分 0.40）和片段 6（门店查询，无关，得分 0.30）。
3. **重新排序：**片段 1（核心政策），然后是片段 5（退款处理），最后是片段 3（节日延长期限）。

优化后的上下文（约 900 个 token，减少 70%）：

1. 核心政策：退货期限为 30 天，必须保留原包装，已拆封商品需支付 15% 的重新入库费。
2. 退款详情：将在 5-10 个工作日内退回至原支付方式；瑕疵商品免收重新入库费，退货期限为 90 天。
3. 节日延长期限：11 月 15 日至 1 月 15 日，退货期限延长至 60 天。

最佳实践

• 筛选前先去重 -- 首先移除重复段落，可以更清晰地了解可用的独特信息，从而做出更好的筛选决策。
• 根据领域调整阈值 -- 相关性和密度得分阈值因用例而异。代码生成任务可能需要比一般问答任务更严格的相关性筛选。请使用带标签的评估集进行校准。
• 保留来源多样性 -- 多个片段得分相近时，优先保留来自不同源文档的片段，以扩大覆盖范围并减少对单一来源的偏重。
• 考虑中间丢失效应 -- 对于超过 8K token 的上下文窗口，将最关键的片段放在上下文块的开头和结尾。请使用特定模型进行测试，因为这种效应因架构而异。
• 记录筛选内容 -- 记录移除了哪些片段以及移除原因。这样就能排查模型因所需片段被筛除而给出不完整答案的情况。
• 查询变化时重新优化 -- 对一个查询而言最优的上下文，可能不适用于后续问题。在多轮对话中，用户意图发生变化时，请重新运行优化。

边缘情况

• 所有分块都高度相关：如果每个分块的得分都高于阈值，则跳过过滤，重点进行去重和排序。不要为了达到任意设定的缩减目标而强行移除有用内容。
• 查询涵盖多个不同主题：像“比较退货政策和保修条款”这样的复杂查询需要同时涵盖两个主题的上下文。确保覆盖范围验证步骤会检查这两个主题，不要把某个主题的所有分块都过滤掉。
• 上下文窗口非常小（4K 个 token）：预算紧张时，优化后可能仍需要进行激进压缩。先进行优化以去除冗余，再压缩剩余内容（如果仍超出预算）。
• 源数据快速变化：在文档频繁更新的实时系统中，缓存的优化结果可能会过时。源文档发生变化时，应使缓存失效并重新优化。
• 包含混合内容类型的上下文：当上下文包含散文、代码、表格和 JSON 时，应按类型进行密度评分——10 行代码片段通常比 10 行散文段落的信息密度更高。