Context Mode
评估 Context Mode 性能与成本：响应字节、事实召回、延迟和存储
设计受控评估，不把宣传中的上下文缩减混同于 token 账单、检索质量或端到端任务提速。
你将学会
- 统计完成答案的所有调用，不只挑一条响应。
- token 与 UTF-8 字节分别测量。
- 同时报告召回、冷暖延迟与数据库大小。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- 统计完成答案的所有调用，不只挑一条响应。
- token 与 UTF-8 字节分别测量。
- 同时报告召回、冷暖延迟与数据库大小。
定义与问题对应的分母
比较字节时，应保留原始工具输出字节，以及为完成答案所需全部 Context Mode 调用返回的字节，包含索引元数据、搜索、重试和追加检索。如果任务实际需要多次调用，却只拿一次很小的搜索响应与大文件相比，这个缩减比例就不是端到端任务度量。
模型 token 和计费需要独立观测方法。英文、中文、代码与 JSON 的 UTF-8 字节数并不按固定比例对应 token，宿主缓存或其他提示还会影响计费输入。应分别记录这些变量，未测字段保留 null。项目宣传比例应标为上游样例，不能预填成自己的报告结果。
效率必须与证据召回一起看
固定语料应包含常见事实、罕见标识符、否定陈述，以及靠近块边界的值。提问前先定义预期事实，再测量有多少必要事实得到检索段落支持，单位和条件也要纳入。简短答案如果悄悄反转否定或丢失回滚阈值，无论节省多少字节都算任务失败。
所查存储层默认块上限为 4096 字节，回归测试覆盖密集单行、空行分段、中日韩文字和 emoji。这些是已阅读的上游测试源码，不是本次新运行的性能结果。评估应加入相同形态，因为按字符估算大小可能低估多字节存储，并改变参与搜索的块数。
首次工作与重复问题分开计时
分别测量首次索引、首次查询和重复查询延迟，同时记录数据库大小与工具往返总数。拿已索引样例对比必须重新加载全部材料的基线，可以帮助判断重复工作，但不能包装成公平的首次使用对比。重复索引本身会改变存储状态，也需要受控的重置流程。
实验矩阵还应包含来源编辑和检索失败。文件刷新工作可能把成本转移到后续搜索，而恢复调用会增加延迟与上下文。最终应结合任务完成、证据召回和运维投入决策。本章提供测量设计，不宣称普遍提速、价格节省或生产延迟结果。
实施步骤
- 1
固定语料、问题与预期事实。
- 2
测量直接输出基线及全新索引路径。
- 3
在热索引、编辑文件和缺失事实下重复。
- 4
拒绝省略错误或无依据答案的节省主张。
可复制示例
{
"scenario": "首次索引",
"rawBytes": null,
"allReturnedBytes": null,
"modelInputTokens": null,
"requiredFacts": 4,
"supportedFacts": null,
"indexMs": null,
"queryMs": null,
"databaseBytes": null
}常见问题
字节缩减能直接当作 token 账单缩减吗？
不能。应测量实际 tokenizer 或供应商用量，并计入所有必要调用和宿主行为。
本章运行过上游分块测试吗？
没有。本次阅读了测试源码以设计相关样例，没有执行完整上游测试套件。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07