介紹
提示快取 并不是要让每个提示都变得更短。它是為了使提示中昂貴的、重複的部分足夠穩定，以便模型提供者可以重用它，而不是一遍又一遍地對相同的上下文進行計費。
對於 AI 建構者、SaaS 營運商和技術創辦人來說，最困難的部分是決定哪些內容屬於可快取前綴以及哪些內容必須保持動態。快取友善的工作流程將指令、模式和範例與使用者特定的上下文分開。
使用穩定的前綴映射開始提示緩存
在重寫提示之前，將工作流程分為穩定區塊和可變區塊。穩定區塊可以在多次運行中重複使用；每個任務的變數區塊都會改變。
| 提示阻止 | 緩存適配 | 原因 |
|---|---|---|
| System instructions | High | Usually reused across tasks |
| Output schema | High | Should not change per user |
| Few-shot examples | Medium to high | 當範例被重複使用時很有用 |
| Retrieved documents | Low | Usually task-specific |
| Timestamps and run IDs | Bad | They break prefix stability |
透過稍後移動動態上下文來改進提示緩存
當團隊將使用者特定資料放在可重複使用指令之前時，就會發生常見的快取未命中。即使是靠近開頭的時間戳記或任務 ID 也可以更改前綴並減少快取命中。
提示快取前綴規則
- 首先放置角色、策略、模式和範例。
- 將使用者請求、檢索到的片段和工具輸出放在穩定區塊之後。
- 在運行之間保持格式一致。
- 避免在第一個提示區塊中使用隨機 ID。
透過快取命中率而不是希望來衡量即時緩存
提示快取應在工作流程層級進行測量。追蹤快取命中率、快取的輸入令牌、未快取的輸入令牌、延遲和最終任務成功率。
| 公制 | 好兆頭 | Bad 標誌 |
|---|---|---|
| Cache hit rate | Rises as similar tasks repeat | Drops after prompt edits |
| Cached tokens | Large stable block reused | Only tiny prefix cached |
| Retry rate | Flat or lower | Higher after prompt restructuring |
| Output acceptance | Quality unchanged | Editors rewrite more output |
避免提示快取失敗模式
最大的風險是節省代幣的同時降低代理的可靠性。保留代表性任務的迴歸集並比較快取變更之前和之後的輸出。
提示快取失效檢查表
- 版本您的系統提示。
- 記錄範例何時發生變化。
- 記錄特定於提供者的快取行為。
- 當架構或工具描述發生變化時重新測試。
將提示快取與模型路由結合使用
提示快取和模型路由可以很好地協同工作。快取穩定的計畫或指令區塊，然後將常規子任務路由到更便宜的模型，並為判斷繁重的步驟保留更強的模型。
按快取穩定性劃分的路由規則
- 穩定的模式提取可以使用更便宜的模型。
- 模糊推理應該使用更強的模型。
- 格式化修復不應使用高級型號。
- High-風險最終建議需要更嚴格的審查。
在生產中應用提示緩存
在生產中，即時快取需要所有權。指定一個人或工作流程擁有者來批准對快取前綴的更改，因為對模式、範例或工具描述的少量編輯可以在多次運行中重置快取行為。為每個提示版本保留前後成本日誌：輸入令牌、快取令牌、輸出令牌、延遲、重試率和接受的輸出率。這可以防止團隊看到較低的輸入成本但錯過下游較高的編輯負擔的常見故障。
範例：檢視類似拉取請求的 Claude Code 工作流程可以將審查規則、輸出模式和安全性規則保留在穩定前綴中。更改的文件和用戶請求保留在該前綴之後。如果在數十次運行中重複使用該標題，則提示快取可以減少重複的上下文成本，而不會削弱審查標準。
啟動後，每週檢查快取效能。尋找提示編輯後快取命中率突然下降、模式變更後延遲更長、範例刪除後重試率更高的情況。最好的訊號是每個接受的輸出的成本，因為它捕獲了令牌節省和編輯返工。在每次提示修訂之前保持這些數字可見，並使用導致更改的提示版本註釋每個實驗。如果快取實驗降低了成本但增加了人工編輯，則回滾並檢查哪些穩定指令被削弱。
提示快取啟動前檢查表
- 映射穩定和動態的提示區塊。
- 將動態上下文移到可重複使用前綴之後。
- 追蹤緩存命中率和緩存的令牌量。
- 保留輸出品質的回歸集。
- 當架構或範例發生變更時，版本會提示。
- 比較每個成功任務的成本，而不僅僅是每個請求的成本。
常見問題：提示緩存
什麼時候值得進行即時快取？ 當一個大的提示前綴在許多類似的請求中重複使用並且在運行之間不會改變時。
什麼最常破壞提示快取？ 動態元資料、檢索的內容和使用者特定的上下文放置在穩定指令區塊之前。
Should I shorten the cached prefix? 未必。當避免重複計費並保持品質時，較大的穩定前綴可能會很經濟。
底線：提示快取是一個前綴設計問題
提示快取 當工作流程是圍繞穩定的可重複使用情境設計時才有效。分離前綴、測量快取命中並透過回歸測試保護品質。
