建立一個能自我調整快取的 Agent

優化大型語言模型 (LLM) 應用程式的挑戰通常是一場試錯遊戲。開發者通常根據直覺設定 Time-to-Live (TTL) 值和快取策略，然後監控日誌以查看其是否有效。然而，手動配置與實際使用模式之間的差距往往很大，從而在成本和延遲方面造成效率低下。

在最近的一個專案中，BetterDB 的創作者為一個基於 Valkey/Redis/Dragonfly 文件構建的 RAG (Retrieval-Augmented Generation) 應用程式開發了一個代理式 (agentic) 快取系統。目標是透過讓 Agent 監控自身的性能並即時建議配置更改，來實際「吃自己的狗糧」(dogfood) 他們的快取函式庫。

一種多層級快取架構

為了最大化效率，該系統採用了兩層快取策略，旨在處理不同類型的用戶互動：

1. 精確匹配工具快取 (The Exact-Match Tool Cache)

此層位於 SDK 與工具之間。每一次呼叫都會經過正規化並檢查是否精確匹配。這對於預定義的問題、重複複製貼上的查詢，或用戶多次檢查相同的技術細節非常理想。如果發生命中 (hit)，系統會立即返回結果，完全繞過 LLM。

2. 語義快取 (The Semantic Cache)

由於人類很少會用完全相同的措辭來提問，系統利用了語義快取。此層會將提示詞 (prompt) 進行嵌入 (embedding)，並透過 valkey-search 執行 K-Nearest Neighbors (KNN) 搜尋。如果新提示詞與快取中的提示詞之間的餘弦距離 (cosine distance) 足夠接近，系統就會串流返回快取的響應。

當兩個層級都發生快取未命中 (cache miss) 時，系統會記錄提示詞嵌入、使用的模型，以及來自 OpenAI 使用量報告的輸入/輸出 token。這使得系統能夠追蹤透過後續命中所節省的確切美元金額。

閉環：自我調整與監控

這個專案真正的創新之處在於從靜態配置轉向代理式迴圈 (agentic loop)。系統將元數據 (metadata) 儲存在 Valkey/Redis 實例中，隨後由監控程序進行分析。

此監控迴圈運作如下：

• 分析： 監控工具讀取快取元數據並分析使用模式。
• 建議： 系統透過 MCP (Model Context Protocol) 伺服器建議改進措施（例如 TTL 更改）。
• 執行： 在此演示環境中，Agent 被允許核准並應用其自身的建議。由於函式庫直接從 Valkey 實例讀取配置，更改會立即生效，無需重新啟動伺服器。

經驗教訓：配置 vs. 程式碼

在測試期間，開發者觀察到一個有趣的趨勢。在三次運行中，工具呼叫次數從 15 次下降到 13 次，最後下降到 8 次。雖然 Agent 建議了幾次 TTL 更改，但開發者注意到一個關鍵限制：TTL 通常不是正確的控制點。

例如，用戶可能會問「How fast is XADD?」和「XADD performance」。這兩者在語義上是相同的，但在字串上是不同的。更改 TTL 無法解決這兩個查詢未命中精確匹配快取的事實。唯一的真正解決方案是架構上的變更——將這些特定的工具從精確匹配層移動到語義快取檢查中。

這個體悟突顯了 LLM 開發者的關鍵洞察：並非所有的優化都能透過配置來解決。 有些效率低下是由於路由邏輯本身造成的，需要進行程式碼更改而非僅僅是參數調整。

未來方向

為了進一步完善系統，開發者正在研究如何讓路由邏輯本身變得可配置。這將允許 Agent 在無需重新部署的情況下，在精確匹配層與語義快取層之間移動工具，從而實現更快的迭代迴圈與優化假設的驗證。