代码语言

知识点思维导图

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 预算要分给不同内容,而不是先到先得

推荐按优先级分配:

  1. System 中的权限、安全与输出契约不能被普通历史覆盖。
  2. 当前用户问题和完成任务必需的 Tool 定义优先保留。
  3. 检索证据先做权限过滤、去重和相关性排序,再按预算装配。
  4. 最近几轮对话保留原文,更早历史提取稳定事实和未完成状态。
  5. 输出空间提前预留,不能等输入装满后再挤。

这不是简单的“从最旧消息开始删除”。如果旧消息保存了用户已确认的业务约束,直接删除会改变任务;如果最近消息只是重复寒暄,它的优先级反而更低。

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 后再判断
失败现场 原始输入、输出、结束原因和首个偏差 禁止只保留成功截图
回归结果 正常、边界、失败、恢复四类样本 逐类记录通过条件

这篇文章的“通过”只表示当前版本、当前样本和当前环境满足预先写下的条件。一次成功运行不能推出生产可用;必须复测原始失败样本,并确认未引入权限、质量、延迟或成本回退。

十二、参考资料

学完自测

选择所有正确答案;提交后逐项核对判断依据。

1在“上下文窗口与长上下文:预算、裁剪和位置偏差”中,需要同时满足“先建立主线:容量、装配、有效利用”与“窗口预算的公式与分层”。给定正文约束“上下文窗口是一次推理可处理的总 Token 容量,不是“用户 Prompt 能写多少字”。”,哪些判断保持了原有处理机制?多选
2“上下文窗口与长上下文:预算、裁剪和位置偏差”出现偏差:“在“上下文窗口与长上下文:预算、裁剪和位置偏差 / 上下文装配不是从最旧消息开始删除”中,即使不满足“删除一条旧消息前,要判断它是否保存用户确认的业务约束”,结果与副作用仍会保持不变。”已成为实际行为。围绕“上下文装配不是从最旧消息开始删除”与“超限裁剪的可追溯实现”,哪些判断能定位被改变的职责或边界?多选
3评审“上下文窗口与长上下文:预算、裁剪和位置偏差”方案时,验收条件包含“每次摘要至少保存压缩前后 Token 数、消息范围、摘要器版本、原文引用 ID 和回归结果。”。关于“摘要与裁剪的安全边界”与“容量够用不代表有效利用”的哪些决策符合正文机制?多选