提示缓存的顺序敏感度：为什么把错误的内容放前面会毁掉命中率

缓存如何工作：前缀匹配与顺序敏感

多数 LLM 提供商的提示缓存基于公共前缀识别可复用计算。如果你每次请求的前 N 个 token 完全相同，后续内容才发生变化，那么前缀部分的计算可以被缓存。

关键在于：缓存是从第一个 token 开始逐位比较的。一旦遇到不匹配的位置，其后的所有内容都无法复用缓存。因此，把不稳定的内容放在前面，会直接导致整个后缀无法命中缓存。

常见的失败模式

以下布局会破坏前缀稳定性：

• 把用户身份或时间戳放在最前面：每个请求的 token 都不同，前缀第一段就变了。
• 把检索到的文档片段放在 system 之前：文档每次不同，system 也失去缓存机会。
• 随机排序的工具定义或示例：即使集合相同，顺序变化也导致前缀不匹配。
• 把会话历史放在固定指令之前：历史越长，前缀越不稳定。

稳定前缀的布局原则

要让缓存持续命中，请遵循：

1. 把最不变的内容放在最前面：系统指令、固定格式说明、通用规则。
2. 把变化的内容放在最后：用户输入、当前问题、最新对话。
3. 不要在前缀区域插入任何动态值：时间、ID、随机数都不应出现在前部。
4. 保持多轮对话中历史顺序固定：追加新轮次时，旧轮次顺序不变。

改前改后：可照搬的布局示例

以下是一个假设的请求结构，不涉及具体模型或 API，仅展示顺序调整。

改前（缓存不友好）

[当前时间: 2025-04-05 10:23:45]
[用户ID: usr_9f2a1c]
[检索结果1]: ...
[检索结果2]: ...
[系统指令]: 你是一个助手，请根据以下文档回答。
[用户问题]: ...

问题：时间、ID 和检索结果每次都变，从第一个 token 起就不稳定，系统指令和用户问题都无法命中缓存。

改后（缓存友好）

[系统指令]: 你是一个助手，请根据以下文档回答。
[固定格式说明]: 回答需简洁，引用来源用方括号标注。
[检索结果1]: ...
[检索结果2]: ...
[当前时间]: 2025-04-05 10:23:45
[用户问题]: ...

改进点：系统指令和格式说明固定不变，成为稳定前缀。检索结果虽然变化，但放在固定指令之后，前缀匹配仍可覆盖前部分。时间和用户问题放在最后，不影响前缀。

多轮对话的追加方式

改前：每轮都把新问题插在 system 之后。

改后：保持 system 在最前，历史对话按时间顺序追加，新问题永远在最后。

验证与迭代

• 查看 API 返回的缓存命中 token 数（如果提供商提供）。
• 对比调整前后相同请求的计费差异。
• 注意：缓存通常有生存时间，过期后需重新计算。

不要凭感觉判断，用数据验证布局调整是否有效。

小结

提示缓存的顺序敏感度意味着：前缀决定命运。把错误的内容放前面，不仅浪费缓存机会，还可能增加延迟和成本。通过将不变内容前置、变化内容后置，并保持历史顺序稳定，你可以显著提升缓存命中率。