上下文工程：长上下文窗口下的代码检索与压缩策略

上下文工程长上下文窗口下的代码检索与压缩策略一、长上下文不是万灵药模型上下文窗口越来越长从 8K 到 128K 甚至更多。有人觉得把整个仓库塞进去问题全解决。现实很快打脸窗口越长噪声越多注意力越散。模型不是读得越多越懂。无关代码挤占了关键信息的权重。长上下文反而带来找不到重点的新问题。上下文工程因此成为独立课题。不是往窗口里塞多少而是塞什么、怎么压。让有限的注意力落在最有价值的内容上。本文探讨长上下文下的检索与压缩策略。二、上下文构造的机制上下文工程分两步检索与压缩。检索决定取哪些压缩决定怎么放。两者配合把大仓库凝练成模型够用的小窗口。检索按任务相关性召回函数、调用链、配置。压缩则去掉冗余、折叠稳定代码、保留接口契约。目标是信息密度最大化。上下文构造的关键在压缩不丢接口。实现细节可折叠但函数签名、类型、约束必须留。模型要的是怎么调不是怎么实现。三、生产级压缩实现下面用代码描述基于重要度的上下文裁剪。from dataclasses import dataclass from typing import Callable dataclass class ContextItem: 上下文中的一个候选片段 text: str score: float keep_signature: bool True def compress(items: list[ContextItem], budget: int) - list[str]: 按预算截断优先保留高分项签名项强制保留 kept: list[str] [] used 0 # 先保签名类再按分数补普通项 signatures [i for i in items if i.keep_signature] for i in signatures: if used len(i.text) budget: kept.append(i.text) used len(i.text) rest sorted( (i for i in items if not i.keep_signature), keylambda x: x.score, reverseTrue, ) for i in rest: if used len(i.text) budget: # 预算耗尽则停止保证不超窗 break kept.append(i.text) used len(i.text) return kept if __name__ __main__: items [ ContextItem(def login(): ..., 0.9), ContextItem(class Repo: ..., 0.8, keep_signatureTrue), ContextItem(verbose log block, 0.2), ] out compress(items, budget200) print(f上下文保留 {len(out)} 段)真实系统会用分层上下文始终保留接口层按需展开实现。并对长文件做摘要替代避免占满窗口。四、边界分析与架构权衡长上下文策略有效但边界清晰。检索质量决定上限。压缩救不了取错东西。检索不准再会压也白搭。应先把检索做准再谈压缩。压缩的信息损失。折叠实现可能漏掉关键细节。安全相关、边界处理的代码不宜过度压缩。应对这类块设禁止压缩标记。窗口≠理解。模型对超长内容的后部记忆下降。关键指令应放在上下文首尾而非中段。这是注意力分布的客观规律。成本随窗口线性增长。塞得越多token 越贵。压缩省下的不只是注意力还有钱。应以最小够用为准则。上下文工程的成本可视容易被忘记。检索与压缩每步都吃 token长链路累积下来不便宜。建议在拼接上下文时记录各块的 token 占用超标即告警避免无意识地把窗口填满。另一个实践是分层注入始终保留接口契约层在窗口内实现细节按需展开关键指令固定放在首尾。最后不同任务类型应配不同预算简单改 bug 用小上下文复杂跨模块设计用大上下文按任务动态调而非一刀切既保质量又控成本。五、总结长上下文窗口下上下文工程比堆量更重要。机制上靠相关性检索取准、靠压缩提密度。工程上守住签名必留、安全不压的底线。落地路线先建任务相关检索再对召回项按重要度压缩强制保留接口契约关键指令置首尾。窗口再长装对东西才有用。