在此页面上
简短的回答
上下文窗口是模型可以在请求中考虑的标记化信息量，具体取决于其 API 规则。这是容量限制，而不是完美召回的承诺。分别预算指令、文档、对话历史记录、工具结果和输出，然后测试模型是否使用正确的证据。
拿走什么
- 令牌不是固定数量的单词。
- 最大上下文和可用证据是不同的衡量标准。
- 为答案和工具活动预留空间。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
计算实际负载
用户输入的文本只是许多 AI 请求的一部分。指令、工具定义、检索到的段落、之前的消息和生成的工具响应都可能占用空间。标记化因模型、语言和输入类型而异。我们的建议是记录提供商报告的代表性请求的使用情况，而不是对每个工作负载使用英语字数估计。为简短的支持问题、较长的合同以及使用多个工具轮换的对话保留单独的记录。
将限制读取为API合约
模型规范可以列出不同的输入和输出限制。例如，Google 记录了 Gemini 3.8 Flash 的 1,048,576 个输入标记和 65,536 个输出标记。这并不能保证每个长度都有相同的性能。在填充窗口之前检查端点如何考虑指令、推理和多模式输入。合适的请求仍然可能会省略必要的来源或包含矛盾的材料，从而使答案难以验证。
衡量不同长度的证据使用
创建任务版本，增加不相关材料的数量，同时保持所需答案和证据不变。在输入的开头、中间和结尾之间移动支持段落。与请求是否被接受分开跟踪正确性和来源支持。这些是建议的诊断测试，而不是有关提供商基准的声明。在每个版本中使用相同的源权限，这样较长的上下文就不会意外泄露用户不应看到的信息。
| 公制 | 如何计算或检查 | 它支持的决定 |
|---|---|---|
| 输入利用率 | 报告的输入令牌/记录的输入限制 | 请求与容量的接近程度如何？ |
| 有证据支持的准确性 | 由提供的证据/评估问题支持的正确答案 | 额外的上下文有用吗？ |
| 截断率 | 请求丢失所需信息/观察到的请求 | 历史管理是否删除了一些重要的内容？ |
| 每个经过验证的答案的成本 | 总请求成本/已验证的答案 | 更长的上下文值得付出代价吗？ |
选择显式历史策略
决定系统随着对话的发展保留、总结、再次检索或删除哪些信息。以可检查和更正的形式保留重要的用户决策。测试在几个不相关的回合后引用较早指令的任务。如果系统无法恢复所需的细节，它应该要求澄清，而不是发明记忆。更改模型时重新审视策略，因为更大的窗口可能会改变成本，而不会解决潜在的信息选择问题。
证据的局限性
令牌记账和限制因端点而异，并且可能会发生变化。双子座数字是一个过时的供应商规范，而不是最大长度的可靠回忆的证据；建议的测试需要您自己的文件和判断。
常见问题
百万个令牌的上下文是否会取代检索？
不一定。检索仍然可以帮助选择相关的、当前的、经过许可的证据并控制成本。比较您的任务的两种方法。
我们应该始终包含整个对话吗？
使用显式策略并对其进行测试。不必要的历史记录会消耗预算，并可能引入陈旧或相互冲突的指令。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- Gemini 3.8 Flash型号规格 谷歌 · 生活参考 · 维护文档已审核： 模型ID、输入/输出限制、模式和推理设置.已访问 2026年9月25日.