知识点思维导图
47 个知识节点
大模型基础(02) - 上下文窗口与长上下文:预算、裁剪和位置偏差
把上下文窗口从一个容量数字变成可解释的预算、装配和位置评测。
读完后,你应能:
- 根据上下文上限、预留输出和安全余量生成分项预算表,并输出超限样本的调用前阻断记录。
- 按权限、硬约束、当前问题、证据和历史的优先级装配上下文,输出裁剪对象、来源 ID 和原因记录。
- 固定同一事实只改变证据位置和干扰强度,运行长上下文位置评测并输出正确率、引用命中率和 TTFT 报告。
一、先建立主线:容量、装配、有效利用
上下文窗口是一次推理可处理的总 Token 容量,不是“用户 Prompt 能写多少字”。System 规则、历史消息、检索证据、工具 Schema、当前问题和预留输出共同竞争这块容量。
本文按三个问题推进:窗口到底怎样预算;超过预算时哪些内容可压缩;即使装得下,为什么证据仍可能被忽略。Token 计数方法见上一篇;自回归生成和采样参数见下一篇。
二、窗口预算的公式与分层
最小预算关系是:
输入预算 = 上下文上限 - 预留输出 - 安全余量
输入预算中的内容通常是 System + 历史 + 检索证据 + Tool Schema + 当前问题 + 模板开销。安全余量不能拍脑袋,应使用本地计数与 API usage 的差值分布校准。
| 层级 | 处理原则 | 失败后果 |
|---|---|---|
| 权限与安全规则 | 固定保留 | 低权限文本覆盖系统边界 |
| 任务硬约束 | 原文或结构化保存 | 金额、时间和输出格式被摘要改写 |
| 检索证据 | ACL、去重、排序后装配 | 引用错位或证据缺失 |
| 旧历史 | 提取事实和未完成状态 | 对话连续性被破坏 |
| 输出预算 | 提前预留 | JSON 或工具参数被截断 |
三、上下文装配不是从最旧消息开始删除
先给不可丢内容分配预算,再给当前问题和任务相关证据分配预算,最后才处理可压缩历史。删除一条旧消息前,要判断它是否保存用户确认的业务约束;压缩一段历史时,要把事实、推断和未完成动作分开。
检索 Top-K 只是候选数量。生产链路还要做权限过滤、重复检测、Rerank、单来源上限、语义边界裁剪和来源 ID 保留。
四、超限裁剪的可追溯实现
示例只负责证明“调用前预算和裁剪决策可审计”,不负责模拟具体供应商 Tokenizer。生产实现还要把 System、历史、工具和问题计数加入同一预算,并记录被跳过的证据及原因。
五、摘要与裁剪的安全边界
摘要不是无损压缩。每次摘要至少保存压缩前后 Token 数、消息范围、摘要器版本、原文引用 ID 和回归结果。对于权限、金额、时间、身份和未完成动作,应保留结构化字段,不要让摘要器自由改写。
证据裁剪按段落、表格行或句子边界完成;直接按字符切字符串容易截断表头、结论和引用位置。裁剪策略还应限制同一来源占比,避免单一文档垄断全部窗口。
六、容量够用不代表有效利用
长上下文模型允许更大的输入,但不保证各位置的信息被同等稳定地使用。证据位于中部时,模型可能比证据位于开头或结尾更容易漏答,这种位置偏差通常称为 Lost in the Middle。
位置评测必须固定问题、正确事实、模型参数和证据内容,只改变证据位置与干扰强度。不能只把证据放在开头就宣布长上下文可用。
| 维度 | 变量 | 指标 |
|---|---|---|
| 证据位置 | 开头、中部、结尾 | 正确率、引用命中率 |
| 上下文长度 | 2K、8K、32K 分桶 | TTFT、成本、召回 |
| 干扰强度 | 无关、同主题、冲突文本 | 误引率、拒答率 |
| 多证据组合 | 单证据、跨段、冲突证据 | 完整率、冲突处理 |
七、上下文 Trace 应记录什么
每次请求至少记录模型、Tokenizer、Prompt 版本,System、历史、工具、证据、问题的分项 Token,裁剪动作、证据位置、排队时间、TTFT、输出 Token 和结束原因。正文和日志应脱敏,证据 ID 仍要能回链到版本化数据集。
八、故障定位与发布步骤
| 现象 | 首个偏差 | 处理 |
|---|---|---|
| Prompt 没超限却返回截断 | 忽略输出预算或模板开销 | 提前扣除输出并校准模板 |
| 摘要后答案改变 | 硬约束被自然语言改写 | 结构化保存约束并保留原文引用 |
| 中部证据漏答 | 位置利用不稳定 | 缩短上下文、Rerank、位置回归 |
| 证据跨租户泄露 | ACL 在裁剪后才检查 | 装配前完成权限过滤 |
落地顺序:固定预算契约;实现分项计数;按优先级装配;记录裁剪;建立位置分桶回归;上线后监控超限率、证据引用率、TTFT 和成本。
九、验收清单
- 输入预算同时扣除预留输出和安全余量。
- System、硬约束、工具、历史和证据有明确优先级。
- 超限发生在模型调用前,并记录删减对象与原因。
- 摘要不会把推断写成用户确认事实。
- 证据裁剪保留段落边界、来源 ID 和租户权限。
- 长上下文回归覆盖开头、中部、结尾和干扰文本。
- Trace 能定位预算、裁剪、位置和延迟的首个偏差。
十、总结
上下文窗口是输入、输出和安全余量共同约束的预算,不是一个可以无限填满的 Prompt 容器。高质量装配需要先保护权限和硬约束,再压缩可恢复历史、去重证据并预留输出;长上下文还必须通过位置和干扰评测证明“装得下”之外的有效利用。
十、来自原稿的详细推导
上下文窗口要怎么做预算?
3.1 窗口同时容纳输入和输出
上下文上限不是“Prompt 最多能放多少”,而是当前推理可处理的总序列容量。简化预算关系如下:
输入预算 = 上下文上限 - 预留输出 - 安全余量
输入 Token 通常包含:
System + 历史消息 + 检索证据 + Tool Schema + 当前问题 + 消息模板开销
安全余量用于吸收估算误差、动态工具定义和供应商模板变化。余量不是固定行业数字,应根据“本地估算值与 API 实际用量的差值”持续校准。
3.2 预算要分给不同内容,而不是先到先得
推荐按优先级分配:
- System 中的权限、安全与输出契约不能被普通历史覆盖。
- 当前用户问题和完成任务必需的 Tool 定义优先保留。
- 检索证据先做权限过滤、去重和相关性排序,再按预算装配。
- 最近几轮对话保留原文,更早历史提取稳定事实和未完成状态。
- 输出空间提前预留,不能等输入装满后再挤。
这不是简单的“从最旧消息开始删除”。如果旧消息保存了用户已确认的业务约束,直接删除会改变任务;如果最近消息只是重复寒暄,它的优先级反而更低。
3.3 可运行的预算检查器
下面的 Python 3.10+ 示例不假装实现某个模型的 Tokenizer。它接收目标 Tokenizer 已经计算好的各部分数量,专门验证预算分配和超限处理;生产中应把 TOKEN_COUNTS 替换为真实计数结果。
超过预算时应该删什么?
4.1 先区分不可丢、可压缩与可重取
| 内容 | 处理策略 | 不能接受的结果 |
|---|---|---|
| 权限与安全规则 | 固定保留,并防止低权限文本覆盖 | 为省 Token 删除鉴权或拒绝边界 |
| 当前任务约束 | 原文保留或结构化保存 | 摘要改变金额、时间、格式等硬约束 |
| 旧对话 | 提取稳定事实与未完成状态 | 摘要把模型猜测写成用户确认事实 |
| 检索证据 | 权限过滤、去重、排序、按需重取 | 随机截断导致引用缺失或句子断裂 |
| Tool Schema | 只挂载当前任务可能使用的工具 | 保留大量无关工具挤占证据空间 |
4.2 摘要不是无损压缩
摘要会丢信息,也可能引入模型推断。应该把用户确认事实、业务实体、未完成动作和原文引用分开存储,而不是把整段历史压成一段无法追溯的自然语言。
每次压缩至少记录:
- 压缩前后 Token 数。
- 被删除或合并的消息范围。
- 使用的摘要器和 Prompt 版本。
- 仍需保留的原文引用 ID。
- 压缩后回归样本是否继续通过。
4.3 RAG 证据应该按预算装配
召回 Top-K 只是候选数量,不等于最终全部进入 Prompt。上线链路还要做 ACL、去重、Rerank、单来源限额和 Token 预算裁剪。
裁剪应沿段落或句子等语义边界完成,并保留来源 ID。直接对拼接字符串按字符截断,容易切掉结论、表格列或引用定位信息。
窗口装得下,为什么仍会漏掉证据?
9.1 容量不等于有效利用
模型宣称支持长上下文,只表示请求容量上允许输入,不保证每个位置的信息都被同等稳定地使用。相关证据位于长输入中部时,表现可能低于位于开头或结尾,这类现象常被称为 Lost in the Middle。
因此,不能用一个短问题证明长上下文可用,也不能只测试“证据放在开头”的理想情况。
9.2 位置评测要固定事实,只改变位置
准备一组答案唯一、能够引用原文的样本,把同一证据分别放在开头、中部和结尾,并逐步加入相似干扰段落。
| 评测维度 | 变量 | 保持不变的内容 | 观察指标 |
|---|---|---|---|
| 证据位置 | 开头、中部、结尾 | 问题、证据事实、模型参数 | 正确率、引用命中率 |
| 上下文长度 | 2K、8K、32K 等分桶 | 证据位置比例 | TTFT、正确率、成本 |
| 干扰强度 | 无干扰、同主题、冲突文本 | 正确证据 | 误引率、拒答率 |
| 多证据组合 | 单证据、跨段、冲突证据 | 任务说明 | 完整率、冲突处理 |
失败样本必须保存模型版本、Prompt 版本、证据 ID、位置、输入 Token 和原始输出,否则后续无法确认升级是否真正修复。
十一、发布前的证据记录
| 证据 | 记录内容 | 不满足时的动作 |
|---|---|---|
| 输入版本 | 模型、Tokenizer、Prompt 或样本版本 | 固定版本并重新运行 |
| 中间状态 | 计数、装配、生成阶段或解析状态 | 补齐 Trace 后再判断 |
| 失败现场 | 原始输入、输出、结束原因和首个偏差 | 禁止只保留成功截图 |
| 回归结果 | 正常、边界、失败、恢复四类样本 | 逐类记录通过条件 |
这篇文章的“通过”只表示当前版本、当前样本和当前环境满足预先写下的条件。一次成功运行不能推出生产可用;必须复测原始失败样本,并确认未引入权限、质量、延迟或成本回退。
十二、参考资料
学完自测
选择所有正确答案;提交后逐项核对判断依据。