Tealium：為何 RAG 品質取決於即時資料

Tealium 應用人工智慧部門首席產品經理弗雷迪·貝蘭蒂（Freddy Berlanti）深入探討檢索增強生成（RAG）技術。圖片來源：Getty Images

Tealium 應用人工智慧部門首席產品經理弗雷迪·伯蘭蒂（Freddy Berlanti），剖析了能創造價值的 RAG 系統與那些悄然削弱用戶信任的系統之間關鍵差異

大多數企業級檢索增強生成（RAG）系統僅能檢索到客戶的瞬間快照：例如上週二建立索引的向量儲存庫、夜間同步的知識庫，或是反映用戶 12 小時前狀態的個人檔案。正是這道鴻溝，區分了真正有效的 RAG 系統與那些悄然侵蝕信任的系統。

週四晚上 8:47。一位顧客將另一件商品加入購物車，使總金額超過免運門檻，隨後開啟客服聊天視窗，詢問是否包含運費。

客服人員在數毫秒內便給予回覆。這段回應流暢、有禮、引用資料恰當——卻是錯誤的——因為系統調取的用戶檔案是在購物車內容變更之前彙整而成的。等到批次索引的資料來得及更新時，原本該提供資訊的時機早已錯過。

這段互動受兩個截然不同的指標所支配，但大多數生產系統僅測量其中一個。「回應延遲」是指提問與回答之間的時間間隔，團隊對此進行了近乎偏執的追蹤；而「資訊滯後度」——由 Kaul、Yates 和 Gruteser 正式提出的指標——則衡量系統根據某項事實採取行動時，該事實的陳舊程度。 簡單來說：當你使用該資訊時，其時效性有多低？

在此範例中，回應延遲雖不到一秒，但資訊卻已過時數小時。系統雖然快速，卻未能保持即時性。而儀表板上僅顯示其中一個數值。

這項區別至關重要，因為基於過時客戶資料得出的快速答案，終究仍是錯誤的答案。對於面向客戶的 RAG 系統而言，速度與資訊新鮮度是兩個不同的問題，優化其中一項並不能保證另一項的表現。

這兩者是相互獨立的，且在高負載下，它們甚至可能朝相反方向發展。更頻繁的更新並不總是意味著資訊更即時。超過某個臨界點後，更新會積壓在佇列中，導致可用的最新事實反而變得更舊，而非更新。夜間批次處理不過是極端案例：系統運作時所依據的，是前一天的世界觀。 解決之道並非在相同時程內傳輸更多資料，而是要在變動發生時即時傳輸重要的變更——這需要的是不同的架構，而不僅僅是更快的系統。

RAG 之所以能嶄露頭角，正是因為它解決了「閉書問題」。系統不再僅憑記憶回答問題，而是先查閱相關資料，再根據查到的內容作答。這些資料就是語料庫。只要語料庫設計得當，模型就不會再即興發揮。

對於內部知識助理而言，一個在夜間同步的語料庫已足夠。但客戶在互動過程中遇到問題則是另一回事。購物車金額剛突破門檻，客服人員必須當下決定是提供免運費，還是暫緩確認訂單。 黎明前擷取的快照並非日後可透過調校解決的限制；這根本是錯誤的架構，因為等到批次索引資料追上進度時，原本應藉此決策的時機早已錯過。

批次 RAG 檢索的是記憶；即時 RAG 檢索的是客戶

這些失敗雖微小、看似合理，卻具有侵蝕性。它們極少觸發警報或錯誤報告；使用者只會逐漸學會不信任系統，並停止使用它。等到這些問題出現在儀表板上時，看起來就像是沒有明顯原因的採用率問題。

解決方案的起點早於任何工具選型決策。這是一份根據使用案例撰寫的服務水準協議，旨在回答三個問題：情境資訊必須有多即時？答案必須多快送達？系統何時該停止運作並將對話交由人類接手？

購物車狀態需要以秒為單位更新。產品內容可容許以分鐘為單位更新。政策資訊則以每日更新即可。這些數字不再只是偏好設定，而是成為設計上的限制條件：它們決定了架構，也決定了成本。常見的錯誤是將資料新鮮度視為單一的全域設定，並將其均勻地套用至所有情境。 即時性是一項預算。將其投入能影響決策之處，並停止為無關決策的部分付費。

對於面對客戶的客服人員而言，其資料庫就是客戶本身。

這意味著身分識別需跨裝置與通路進行解析，使所有接觸點皆被視為同一位使用者。這也意味著同意權限與個人檔案本身綁定，因此每個下游查詢皆由系統結構預先授權，而非仰賴某人希望對方已閱讀的政策文件。

這也意味著放棄每晚的重建作業。透過「變更資料擷取」（Change Data Capture）——即僅串流傳輸變更內容而非重新載入所有資料——能在數秒內重新嵌入單一個人資料檔案，而非重新處理數百萬筆資料。 資料檢索則採用混合模式：透過密集向量搜尋解析語義，透過關鍵字搜尋如 SKU 和訂單編號等關鍵字串，兩者透過排序融合，並對入圍結果進行重新排序。 熱層與冷層的設計確保成本合理，因此您只需為少數真正會影響決策的屬性購買第二級即時性，其餘項目則維持每日更新頻率。

從左至右閱讀的「始終最新」技術堆疊，下方為測量迴圈

若手動將每個代理與每個資料來源連接，便會形成一個整合網路，每個整合點都有其專屬的驗證機制、資料結構變更及故障點。正是這種複雜性，導致許多前景看好的試點計畫難以擴展。

「模型上下文協定」（MCP）作為連接代理程式與工具及資料的開放標準，將這道接縫轉變為一個連接埠。 只需將資料來源連接一次，任何符合標準的代理程式都能自動發現它，並附帶資料結構與權限設定。其前方設有閘道器：驗證傳入呼叫、依據同意進行資料遮蔽，並記錄稽核軌跡。這看似不起眼的一半，正是讓您順利投入生產環境的關鍵。

若缺乏衡量標準，上述一切皆無法存續，而單一數值也遠遠不夠。一個滿意度分數能告訴你「有問題」，但需要三個獨立的儀表板才能指出具體問題所在。

檢索品質用以檢視是否確實取得正確的語境：語境精確度、語境召回率、過時延遲。回答這些問題無需任何模型。生成品質則檢視模型是否忠實運用所接收的資料：答案相關性與引用涵蓋率，由經人類審查校準的評審員進行評分。 商業成果則檢視這些是否真正產生影響：解決時間、問題控制率、成本、客戶滿意度（CSAT）。若將這些指標分開追蹤，任何指標的下滑都會直接指向需要改進的層級，無論是資料、模型還是工作流程。

三個儀表板：指標下滑會告訴你該修復哪一層

接著，採取「窄範圍部署」策略。針對實際流量模擬一個有限的用例，反覆調校直至其符合您所制定的服務水準協議（SLA），並在啟用升級處理機制後才進行部署，之後才逐步擴大範圍。停滯模式則完全相反，而這正是當前業界最常見的專案模式：先有工具、後有數據、永遠沒有指標。

模型的改進效果在同一天就會惠及所有人。無論本季度的前沿發布為您帶來了什麼優勢，您的競爭對手下季度就能以市價買到。但他們無法買到的，是您的代理程式在回應當下所調取的上下文所蘊含的「貨幣」、「治理」與「身份」。

模型是大腦。情境是記憶。這兩者之中，只有一項屬於你。請閱讀完整的電子書。