长上下文宣传常常只强调最大 token 数，但业务真正遇到的是：历史消息太长后哪些内容被丢掉，检索片段重复后模型是否忽略关键证据，超出限制时网关如何处理，以及长输入带来的成本和延迟是否还能接受。
先确认谁在截断
可能截断请求的地方有客户端、Agent 框架、网关、供应商 SDK 和模型服务。每一层的方向也不同：从最早消息开始删、从检索结果末尾删，或只保留摘要。测试时应记录发送前 token 数、网关改写后的 token 数、供应商返回的 usage 和最终保留的消息摘要。否则出现错误时，团队很容易把问题归咎于模型。
用位置测试发现“看见但没用上”
把同一个关键事实分别放在上下文开头、中间、结尾和工具结果中，再用相同问题询问。加入相似但错误的干扰内容，检查模型是否能按来源和优先级选择正确事实。对多轮对话，要测试旧指令、用户撤回和最新约束的冲突，避免单轮样本给出过于乐观的结果。
预算应该按任务管理
可以把上下文拆成系统规则、用户输入、历史摘要、检索证据和工具结果五个预算区。每个区有上限，超出后采用可解释策略：摘要、去重、降级为标题，或要求用户确认。比起把所有内容塞进最大窗口，明确预算更容易控制成本和延迟，也方便排查回答为什么发生变化。
如果请求经常需要在不同模型之间回退，统一网关可以在路由前计算 token 预算，选择能容纳当前上下文的模型，并保留“删掉了什么”的摘要记录。使用 top-api.cc 这类入口时，最好把上下文裁剪策略放在自己的业务层或显式配置中，不要依赖某家上游的隐式行为。
测评结果至少包含这些项
- 发送前、改写后和响应后的 token 数；
- 不同位置的关键信息准确率；
- 检索重复、冲突和过期信息下的表现；
- 截断后是否给出明确标记；
- 上下文长度增长带来的 P95 延迟和成本；
- 模型切换后摘要和指令优先级是否保持。
长上下文不是免费存储。它会增加隐私暴露面、提示注入入口和账单波动。对于高风险应用，应把信息最小化、来源标记和人工确认放在“扩大窗口”之前。
参考资料：各模型上下文窗口与 token 计费文档、OWASP 对提示注入和敏感信息暴露的风险说明。模型限制和价格变化很快，正式报告应记录版本和日期。
需要在多家上游之间比较相同上下文的保留和裁剪行为时，可以通过 top-api.cc 统一请求格式，再把每次裁剪摘要保存为回归证据。
Leave a Reply