上下文优化

要解决的问题

在 RAG 或 Agent 流水线里，送入模型的原始上下文通常是检索到的文档片段、对话历史、工具输出和元数据的混合体。常见问题包括：重叠分块（overlap chunking）产生的近重复段落、与当前查询仅边际相关的碎片，以及信息顺序混乱。这些内容挤占有限的上下文预算，稀释模型注意力，关键事实还可能被埋在中段（"lost in the middle"），既影响回答质量，也推高推理成本。

工作方式

该技能把优化拆成六个可验证的步骤：

• 审计原始上下文：清点所有来源的 token 数，与可用预算对比，估算压缩比例。
• 去重：用语义相似度（cosine distance > 0.92）或 n-gram 重叠检测识别近重复片段，保留信息最完整的版本。
• 双维评分：对每个 chunk 同时计算相关性分数（检索分或轻量 cross-encoder 打分）和信息密度分数（命名实体、代码标识符、数值数据相对长度的占比），相乘得到综合效用分。
• 过滤低价值内容：剔除低于阈值的 chunk 和零信息的模板文本（版权声明、导航栏），建议保留 top 60–70%，但宁可保守。
• 按优先级重排：效用最高的 chunk 放最前和最后，避开注意力最弱的中段。
• 验证覆盖率：确认查询的每个子问题都有 chunk 覆盖，必要时回补被过滤的内容。

策略随上下文窗口大小变化：4K 窗口需要激进的过滤与压缩，32K 侧重去重与重排，128K+ 则更依赖排序与密度评分。

适用边界与注意点

• 若所有 chunk 都高于阈值，不要为了凑压缩目标强行删除内容。
• 复杂查询涉及多个主题时，覆盖率检查必须逐主题核对，避免把某一主题的 chunk 全部滤掉。
• 阈值应按领域校准：代码生成任务的相关性门槛通常比通用问答更严格。
• 建议记录过滤日志，便于排查"模型回答不完整"这类问题。
• 多轮对话中用户意图变化时，应重新运行优化，而非复用上一轮结果。