介绍
提示缓存 并不是要让每个提示都变得更短。它是为了使提示中昂贵的、重复的部分足够稳定，以便模型提供者可以重用它，而不是一遍又一遍地对相同的上下文进行计费。
对于 AI 构建者、SaaS 运营商和技术创始人来说，最困难的部分是决定哪些内容属于可缓存前缀以及哪些内容必须保持动态。缓存友好的工作流程将指令、模式和示例与用户特定的上下文分开。
使用稳定的前缀映射开始提示缓存
在重写提示之前，将工作流程分为稳定块和可变块。稳定块可以在多次运行中重复使用；每个任务的变量块都会改变。
| 提示阻止 | 缓存适配 | 原因 |
|---|---|---|
| System instructions | 高的 | 通常跨任务重用 |
| 输出模式 | 高的 | 不应针对每个用户进行更改 |
| 少数例子 | 中到高 | 当示例被重用时很有用 |
| 检索到的文件 | 低的 | 通常针对特定任务 |
| 时间戳和运行 ID | 坏的 | 它们破坏了前缀稳定性 |
通过稍后移动动态上下文来改进提示缓存
当团队将用户特定数据放在可重用指令之前时，就会发生常见的缓存未命中情况。即使是靠近开头的时间戳或任务 ID 也可以更改前缀并减少缓存命中。
提示缓存前缀规则
- 首先放置角色、策略、模式和示例。
- 将用户请求、检索到的片段和工具输出放在稳定块之后。
- 在运行之间保持格式一致。
- 避免在第一个提示块中使用随机 ID。
通过缓存命中率而不是希望来衡量即时缓存
提示缓存应在工作流程级别进行测量。跟踪缓存命中率、缓存的输入令牌、未缓存的输入令牌、延迟和最终任务成功率。
| 公制 | 好兆头 | 坏兆头 |
|---|---|---|
| 缓存命中率 | 随着类似任务的重复而上升 | 提示编辑后掉落 |
| 缓存的令牌 | 大型稳定块重复使用 | 仅缓存很小的前缀 |
| 重试率 | 平坦或更低 | 迅速重组后更高 |
| 输出验收 | 品质不变 | 编辑重写更多输出 |
避免提示缓存失败模式
最大的风险是节省代币的同时降低代理的可靠性。保留代表性任务的回归集并比较缓存更改之前和之后的输出。
提示缓存失效检查表
- 版本您的系统提示。
- 记录示例何时发生变化。
- 记录特定于提供者的缓存行为。
- 当架构或工具描述发生变化时重新测试。
将提示缓存与模型路由结合使用
提示缓存和模型路由可以很好地协同工作。缓存稳定的计划或指令块，然后将常规子任务路由到更便宜的模型，并为判断繁重的步骤保留更强的模型。
按缓存稳定性划分的路由规则
- 稳定的模式提取可以使用更便宜的模型。
- 模糊推理应该使用更强的模型。
- 格式化修复不应使用高级型号。
- 高风险的最终建议需要更严格的审查。
在生产中应用提示缓存
在生产中，即时缓存需要所有权。指定一个人或工作流程所有者来批准对缓存前缀的更改，因为对模式、示例或工具描述的少量编辑可以在多次运行中重置缓存行为。为每个提示版本保留前后成本日志：输入令牌、缓存令牌、输出令牌、延迟、重试率和接受的输出率。这可以防止团队看到较低的输入成本但错过下游较高的编辑负担的常见故障。
示例：审查类似拉取请求的 Claude Code 工作流程可以将审查细则、输出模式和安全规则保留在稳定前缀中。更改的文件和用户请求保留在该前缀之后。如果在数十次运行中重复使用该标题，则提示缓存可以减少重复的上下文成本，而不会削弱审查标准。
启动后，每周检查缓存性能。查找提示编辑后缓存命中率突然下降、模式更改后延迟更长以及示例删除后重试率更高的情况。最好的信号是每个接受的输出的成本，因为它捕获了令牌节省和编辑返工。在每次提示修订之前保持这些数字可见，并使用导致更改的提示版本注释每个实验。如果缓存实验降低了成本但增加了人工编辑，则回滚并检查哪些稳定指令被削弱。
提示缓存启动前检查表
- 映射稳定和动态的提示块。
- 将动态上下文移到可重用前缀之后。
- 跟踪缓存命中率和缓存的令牌量。
- 保留输出质量的回归集。
- 当架构或示例发生更改时，版本会提示。
- 比较每个成功任务的成本，而不仅仅是每个请求的成本。
常见问题解答：提示缓存
什么时候值得进行即时缓存？ 当一个大的提示前缀在许多类似的请求中重复使用并且在运行之间不会改变时。
什么最常破坏提示缓存？ 动态元数据、检索的内容和用户特定的上下文放置在稳定指令块之前。
我应该缩短缓存的前缀吗？ 未必。当避免重复计费并保持质量时，较大的稳定前缀可能会很经济。
底线：提示缓存是一个前缀设计问题
提示缓存 当工作流程是围绕稳定的可重用上下文设计时才有效。分离前缀、测量缓存命中并通过回归测试保护质量。
