上下文窗口规划是什么
上下文窗口不是「塞得越满越好」。内容越多，关键指令被稀释的概率越高：长输入中段的信息容易被忽略，这一点在长上下文研究中反复被验证。可行的做法是按优先级排序并动态取舍——指令与输出契约最优先，其次必要示例、高相关检索内容，历史对话排在后面；同时始终为输出预留空间，超限时按既定顺序降级，而不是随机丢弃。
基本信息
| 适用平台 | 所有有上下文长度上限的模型与推理服务；长文档问答、多轮对话、RAG 应用 |
|---|---|
| 取舍顺序 | 指令与契约 > 必要示例 > 高相关检索片段 > 对话历史 |
| 长文处理 | 分段加检索，或先分层摘要再组装，不整篇塞入 |
| 度量要求 | 记录各段实际占用与引用情况，用于校准取舍策略 |
典型使用场景
- RAG 应用：检索片段过多时按相关度截断，保留来源标记
- 多轮对话：把历史压缩成摘要，同时保留最近若干轮原文
- 长文档分析：按章节切分后逐段处理，最后汇总，避免一次塞满
- 代码助手：只带相关文件片段与接口签名，不带整个仓库
- 批处理任务：同一模板不同输入时，控制单条样本的上下文预算
动态组装伪代码
动态组装伪代码
# ctx = system + contract # 指令与输出契约，最先固定
# ctx += top_examples(k=3) # 必要示例，可按预算调整条数
# ctx += retrieve(query, top_k=8) # 检索片段，按相关度排序加入
# ctx += summarize(history) # 历史压缩为摘要，保留最近若干轮原文
# 校验：占用 + 输出预留 <= 窗口上限，否则按顺序降级
# 降级顺序：先减示例 → 再降 top_k → 后压缩历史 → 最后精简指令（慎用）
# 记录：各段实际占用与最终被引用的片段 ID，用于事后校准降级顺序与代价
| 降级动作 | 代价 | 适用时机 |
|---|---|---|
| 减少示例条数 | 格式与风格稳定性下降 | 示例冗余度较高时首选 |
| 降低检索 top_k | 召回下降，可能漏关键事实 | 片段之间有重叠时较安全 |
| 压缩对话历史 | 早期约定被遗忘 | 任务已进入稳定执行阶段 |
| 截断单片段长度 | 语义被切断，产生残句误读 | 需同时标注截断位置 |
| 精简指令 | 约束丢失，行为不可预期 | 最后手段，需回归验证 |
关键信息放在开头或结尾比放在中部更容易被用到。若任务要求引用长输入中的细节，宁可拆成多轮处理，也不要把全部内容塞进一次请求。
截断检索片段时要在文本中标注截断位置（如省略号加提示），否则模型会把残句当成完整陈述，产出看似有据的错误结论。