KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
08. 怎样证明 Context 策略真的更好？ — keel 龙骨
新策略把支付事故输入从 6120 tokens 压到 3810，节省了 38%。这只能证明字符串更短，不能证明 Agent 更好。如果摘要漏掉“订单仍然失败”，模型可能错误宣布服务恢复；如果保留了结论却丢掉 INC-42，回答看似正确却无法审计。
新策略把支付事故输入从 6120 tokens 压到 3810，节省了 38%。这只能证明字符串更短，不能证明 Agent 更好。如果摘要漏掉“订单仍然失败”，模型可能错误宣布服务恢复；如果保留了结论却丢掉 INC-42，回答看似正确却无法审计。
Context Engineering 的评估必须同时覆盖任务质量、信息保留、结构合法、成本时延和安全风险。单看压缩率会奖励最激进、最危险的策略。
1. 先建立可比较基线
至少比较四组：
| 组 | 策略 | 目的 |
|---|---|---|
| A | 能放下时的完整历史 | 质量上界与成本基线 |
| B | 只保留最近 N 条 | 最便宜的确定性基线 |
| C | 结构化摘要 + 最近消息 | 检查摘要是否值得额外调用 |
| D | 证据索引 + 按需回查 | 检查复杂检索是否改善可审计性 |
所有组使用同一模型版本、工具快照、最大调用次数、输出 schema 和评估集。否则“更好”可能只是使用了更多 token、更多重试或更新的数据。
2. 评估样本要记录哪些事实
支付事故样本可以写成：
{
"case_id": "payment-timeout-01",
"task": "判断服务是否恢复，并说明是否与 INC-42 有关",
"must_keep": [
"error_rate 已降至 0.1%",
"订单仍然失败",
"INC-42 只是历史相似事故，不是当前根因事实"
],
"must_cite": ["monitor:10:20", "incident:INC-42"],
"must_not_claim": ["服务已经恢复", "INC-42 已证明是根因"],
"tool_invariants": ["call c1 has exactly one result"],
"sensitive_markers": ["tenant-secret"]
}
must_keep 测信息保留，must_not_claim 测摘要是否把不确定性变成事实，must_cite 测证据回查，tool invariants 测协议合法，sensitive markers 测泄露。
3. 指标必须形成一组
任务质量
- 最终结论是否正确；
- 未决问题是否保留；
- 当前事实与历史记忆是否区分；
- 结构化输出是否通过 schema。
信息与证据
- must-keep fact recall；
- must-not-claim violation rate；
- evidence ID recall 与引用正确率；
- 原始证据按 ID 回查成功率。
结构与恢复
- tool trace schema failure rate，目标应为 0；
- checkpoint replay divergence；
- orphan/duplicate tool result 数量；
- 重复 compaction 事件数量。
资源成本
- input/output/summary tokens；
- 端到端延迟与摘要额外延迟；
- 模型和检索调用次数；
- 每个成功任务成本，而不是单轮成本。
安全风险
- 跨租户候选进入率，目标必须是 0；
- 敏感标记泄露率；
- 被删除数据是否仍出现在摘要；
- 提示注入是否从外部资料升级为系统指令。
4. 把 usage 估算纳入观测
UsageReconciler 接收发送前估算和供应商实际 usage：
report = UsageReconciler.reconcile(
estimated_input=100,
actual_input=120,
output_tokens=20,
window_limit=128,
)
此时 total_actual=140，within_window=False。即使请求被某个宽松服务端接受，应用仍应记录预算违约；否则 safety margin 永远不会得到校准。
运行：
python -m unittest courses.foundation.context-engineering.course.project.tests.test_usage -v
测试覆盖正常对账、实际超限和负数 usage 拒绝。生产指标要按模型版本、语言、工具数量和请求类型分组，不要用一个平均误差掩盖某类长 JSON 的系统性低估。
5. Lost in the Middle 要变成实验
不要只在文档里引用论文。构造三组相同长度的上下文，把关键事实分别放在开头、中间和末尾；比较：
- 全量原始历史；
- 把关键事实置前的 selector；
- 结构化摘要；
- 证据 ID + 工具回查。
记录模型能否找到事实、能否引用证据、延迟和 token。这样才知道你的模型和任务是否真的受到位置影响，以及新策略是否改善问题。
6. 可观测事件应该回答因果
一轮装配至少产生：
context.measured
context.selected
context.compaction_requested
context.compacted | context.compaction_failed
context.validated
provider.usage_reconciled
checkpoint.saved
事件共享 run_id、history version、policy version 和 counter version。context.selected 记录 dropped IDs 与原因；compaction_failed 记录降级路径；usage 事件记录估算误差。日志不必复制全部原文，来源 ID 和指标通常更安全、更便于聚合。
7. 摘要评估不能只用另一个模型打分
LLM judge 可以辅助判断语义完整性，但不能独自验证：
- call/result 是否配对；
- tenant 是否正确；
- evidence ID 是否真实存在；
- 删除请求是否生效；
- checkpoint 是否幂等；
- token 是否超预算。
这些必须由确定性验证器、数据查询和测试完成。模型评审适合处理“解释是否清楚”“未决问题是否被保留”等语义维度，并需要抽样人工校准。
8. 决策门槛
一个策略进入生产前，应满足类似条件：
任务正确率不低于完整历史基线的可接受区间
关键事实召回 >= 目标
错误确定性陈述 <= 上限
工具 schema 失败 = 0
跨租户与敏感泄露 = 0
token/延迟收益覆盖摘要与检索新增成本
checkpoint 重放结果一致
具体阈值由业务风险决定。客服草稿和自动执行生产变更不能使用同一容忍度。
9. 本章验收
建立至少 10 条小型评估集，其中包含工具超时、新旧事实冲突、历史记忆相似但不等于当前事实、敏感字符串和中部关键信息。比较 full/trim/summary/evidence 四组，输出一份同时包含质量、token、延迟、结构错误和泄露的表。只报告“节省 38% token”不算完成。