Spotify LLM 評估漏斗法：eval 作為 A/B 測試的上游篩選層，而非替代品
Spotify Engineering · 2026-05-18
Spotify 工程團隊發表文章，說明他們在 LLM 功能開發中採用的評估方法論——「漏斗（funnel）」而非「叉路（fork）」。核心主張是：LLM eval 應位於 A/B 測試的上游，扮演篩選淘汰劣質候選的角色，而非取代傳統的線上實驗。
原本的問題
LLM 功能的評估面臨雙重困難：傳統 A/B 測試昂貴且週期長，但光靠 eval 無法捕捉使用者的真實行為反應。早期 Spotify 的做法是直接用 A/B 測試所有 LLM 變體，導致實驗頻寬被不成熟的候選方案消耗，降低整體命中率。
採用的方法
漏斗架構將評估分為三個階段：
- Verification（驗證）：LLM judge 評估輸出是否符合相關性、連貫性、語氣等品質標準，淘汰明顯不合格的候選
- Validation（確認）：A/B 實驗衡量通過 eval 的候選在真實使用者行為上的效果
- Calibration（校準）：線上實驗結果回饋改善未來的 eval 設計
如文中所述：「Evals discard the non-promising candidates before they consume experiment bandwidth. They raise the hit rate of the experiments that follow.」Spotify 使用自家的 Confidence 實驗平台執行 A/B 測試部分，並監控守護指標（crash rate、留存率）補充 LLM judge 無法捕捉的長期效果。
核心限制
文章坦承 eval 的根本侷限：「without offline-online signal calibration, our evals are opinions, not evidence.」 在長時間運行的任務或需要衡量長期使用者行為改變的場景，eval 無法提供足夠的信號，實驗仍是不可或缺的工具。漏斗方法的價值在於「正確分工」，而非「以 eval 取代實驗」。
影響範圍
Spotify 的漏斗方法為在大規模 LLM 功能開發中兼顧評估速度與實驗嚴謹性提供了一個可參考的架構。適用條件是：既有成熟的 A/B 實驗基礎設施，且 LLM 輸出品質有可定義的維度可供自動評估。
Redis Iris：為 AI Agent 設計的即時上下文引擎，五層元件架構
Redis · 2026-05-18
Redis 於 2026 年 5 月 18 日宣布 Redis Iris，定位為 AI agent 的上下文與記憶體解決方案。核心主張是：agent 失敗的根因通常不是推理能力不足，而是上下文層的問題——資料分散、過時、存取緩慢，或整合困難。
核心改動
Redis Iris 的五個元件構成一個完整的 agent 上下文堆疊：
- Context Retriever（預覽版）：定義企業資料的語義模型（實體、欄位、關係、存取規則），並自動生成 agent 可用的 MCP 工具。以範圍金鑰（scoped key）處理驗證，並在伺服器端執行列級過濾（row-level filtering）
- Agent Memory（預覽版）：儲存短期對話狀態與長期持久記憶，跨輪次與跨工作階段維護狀態
- Redis Data Integration（RDI）：從關聯式資料庫、資料倉儲、文件存儲持續同步資料，建立持續更新的操作資料平面
- LangCache：語義快取層，透過向量相似度判斷是否可重用先前的回應，聲稱可降低 token 成本最多 90%
- Redis Search：向量、結構化、非結構化與即時資料的統一快速查詢
架構設計
Context Retriever 的 MCP 整合是最具技術新意的部分：它將語義資料模型的定義轉換為 MCP 工具，讓 agent 可以用自然語言查詢複雜的企業資料關係（如「帳戶 → 商機 → 支援互動 → 客戶狀態」），而不需要為每個資料來源撰寫客製化整合程式碼。整個架構建立在 Redis 基礎設施上，支援多雲與 BYOC 部署。
影響範圍
Redis Iris 填補了 LLM 推理能力（由模型提供商處理）與實際企業資料整合之間的空缺。Context Retriever 和 Agent Memory 目前仍處於預覽狀態，整體架構的可靠性和規模化表現尚待生產環境驗證。對於已在使用 Redis 的組織，這個堆疊的整合成本較低；對於從頭建立 agent 基礎設施的團隊，它提供了一個有結構的起點。
原始來源：Redis Blog