开发者教程 / 03
排查上下文超限：一个实用的 RAG 预算
拆解请求组成、预留生成空间，并优先处理导致上下文增长的最大来源。
从完整预算开始
请求不仅是最后一条用户消息。系统约束、历史对话、检索文档、用户文本，以及消息或工具的额外开销都应计入，并为生成输出预留空间。
下例在 8,192 的上限中分配了 8,096，只剩 96。再加入一份 500 Token 的文档，就会超出 404。这些是教学数值，不代表某个模型的真实上下文规格。
学习指南与本课目录
LEARNING CONTRACT理解 → 实现 → 研究
目标：解释本课机制、复现一个例子、测试一个失败案例。读完不自动代表掌握。
- 理解层：写明假设、形状/单位和一个反例。
- 实现层：复算数值例子并检查边界。
- 研究层：在匹配预算下比较一个替代方法。
找到最大占用
在上下文预算工具中分别输入各段，查看占比。载入超限案例，可以看到超出提示以及占用较大的 RAG 部分。
独立编码适合分析来源，但不能逐字节重建最终请求。分隔符、消息模板、工具 schema 和媒体会影响实际用量。保留明确的开销预算，并与 API 实测 usage 对照。
context_limit = 8192
system = 400
history = 1800
retrieval = 3600
user = 120
extra = 128 # estimate
output = 2048 # reserve
allocated = 400 + 1800 + 3600 + 120 + 128 + 2048
remaining = 8192 - allocated # 96 tokens减小输入，但不要破坏任务
检索过多时，先去重和重排，再保留相关段落与来源。对话过长时，摘要较早轮次并保留关键决定，最近的对话尽量保持原文。
每次修改后重新计数，并运行具有代表性的回答质量测试。不要静默截断系统约束。还应检查模型独立的输出上限：上下文很大，并不意味着输出也可以同样大。
