你花了好幾週調校一個 AI 聊天機器人。答案很準確。利害關係人簽核通過，於是你把它上線。三個月後，系統對使用者提出的約三分之一問題都自信滿滿地答錯。沒有人更改模型，也沒有人動過提示詞。世界已經變了，價格調整了，政策更新了，產品規格推出了新版本，但底層知識庫沒有跟著變動。

這不是假設情境。這是目前企業 AI 在生產環境中最常見的失效模式之一，而且無論 AI 系統如何檢索資料，多數資料工程團隊都沒有合適的工具來捕捉它。隨著企業從 AI 試點走向大規模生產部署——Gartner 一直將資料品質列為 AI 採用的主要障礙之一——這類失效正從偶發困擾轉變為系統性風險。

看起來不像失效的失效

AI 應用程式並不在意自己是從向量儲存、文件索引還是 API 呼叫中檢索資料。無論機制為何，標準檢索管線中都沒有任何環節會檢查它所提供的內容是否仍然正確。過時的定價文件會和最新文件一樣被自信地檢索出來，因為系統評分的是相關性或可用性，而不是正確性。基於同樣原因，一筆悄悄缺少欄位的紀錄也會像完整紀錄一樣順利通過。

因此，這種失效在設計上就是隱形的。過時或不完整的資料仍會在相關性上獲得高分，或通過資料管線原本被設計來執行的所有檢查。模型之所以充滿信心地作答，是因為檢索到的情境看起來具有權威性。你監看的每個儀表板都維持綠燈。系統看起來運作正常。只是它錯了。

我曾在 AI 情境之外看到類似情況發生於金融科技管線中。上游系統在未通知下游使用者的情況下更改了一個欄位。管線沒有失敗；它只是把錯誤值傳播到儀表板，因為系統只檢查作業是否完成，而不是資料是否仍然正確。問題直到一位客戶注意到不一致之處才浮現。到那時，錯誤資料已經向下游流動。

無論是文件變得過時，還是欄位悄悄遺失，失效的形態都相同：沒有錯誤並不代表存在正確性；若沒有建立適當的驗證層，管線中的任何環節都無法識別問題。隨著 AI 代理從回答問題轉向採取行動，風險也正在升高——代理若依據過時定價或已停用政策行動，可能執行錯誤交易，而不只是回傳錯誤答案。

為什麼這是資料工程問題

遇到這種失效的團隊往往會誤診，而且通常會誤診兩次。

歸咎於模型： 第一個直覺是怪罪模型、嘗試不同的 LLM、調整提示詞。真正的問題位於更上游的資料工程層——這與上述金融科技失效背後的直覺相同：監控是為管線而建，不是為資料而建。

歸咎於檢索層： 一旦排除模型，下一個直覺就是轉而責怪檢索層或情境層，然後購買更好的方案。時機並非巧合。隨著企業把這些系統推進真實生產環境，這個缺口正開始浮現，而供應商的回應也到處可見。AWS 剛剛加入「情境層」競賽，推出可從代理使用情況學習的知識圖譜。Snowflake 新推出的 Horizon Context 和 Cortex Sense瞄準的正是本文開頭所描述的症狀：代理自信地給出錯誤答案，因為其底層商業邏輯沒有受到治理。

兩者都是對真實問題的真實回應，但它們位於問題上方一層；知識圖譜仍然依賴餵給它的資料。真正的問題位於更上游的資料工程層。團隊檢查的是作業是否執行，而不是它搬移的資料是否仍然為真——這種直覺早在 AI 之前多年就已存在。監控是為管線而建，不是為資料而建。

真正缺少的是什麼：資料可觀測性

資料可觀測性是一個眾所周知的概念，但在實際實作方式上並未獲得足夠重視。這個類別本身在過去幾年已經成熟——Monte Carlo Data 等公司已為其建立專用平台，IBM 也在 2022 年收購 Databand 以強化自身資料可觀測性能力——但採用情況仍不均衡，尤其是在那些最近才開始把 AI 應用建構於既有資料基礎設施之上的團隊中。

相關指標不是百分比，而是覆蓋率：有多少關鍵資料集具備實際可查詢的血緣，而不是只存在於某個人的腦中。

Uber 早在檢索增強生成出現之前，就建立了專門的資料品質與可觀測性平台。其 Unified Data Quality 平台支援超過 2,000 個關鍵資料集，並可在資料品質事件到達下游消費者之前偵測到約 90% 的事件。

Netflix 則解決了同一問題的另一部分，建立全公司資料血緣系統，讓任何人都能回答某個資料集從何而來，以及沿途經過了哪些處理。它映射的不只是資料倉儲表格，還包括 Kafka 主題、ML 模型與實驗之間的相依關係。與 Uber 類似，該平台原本是為人類而建，而現在隨著 AI/LLM 應用興起，變得更加重要。

Uber 和 Netflix 加在一起，涵蓋了值得建構的四件事中的兩件。在實務上，我會把它視為四個面向，每個面向都能以自身方式衡量。

正確性： 每筆紀錄是否符合其應有的形狀與規則——欄位型別正確、沒有非預期的 null、數值落在範圍內。Great Expectations 和 Soda 等工具很擅長處理這件事：在列與欄位層級進行自動化驗證，而不是等事情出錯後再手動檢查。追蹤每次執行中通過驗證的紀錄百分比。

鮮度： 資料相對於其來源是否仍為最新，而不只是相對於上次檢查時間為最新。追蹤每個來源距離上次成功更新的時間，並為每個資料集設定 SLA，而不是使用單一門檻，因為有些來源需要每小時更新，有些則不需要。

一致性： 同一個事實在所有儲存或索引的位置是否讀起來都相同。這會悄悄失效——只有當兩個由同一來源供給的系統開始出現分歧時才會顯現。定期在下游目的地之間進行交叉檢查，並在不一致率高於門檻時標記，已足以提早捕捉問題。

血緣： 你是否能把任何輸出追溯回其來源，以及它經過的每一次轉換——這正是 Netflix 建立其系統要回答的問題。

這些都不需要大多數資料團隊尚未擁有的基礎設施。我知道，因為我不只是主張過，也實際建置過。

在 Socure，客戶資料會以客戶想送來的任何形式抵達，而且偶爾會悄悄出錯。挑戰在於建立一套系統，能在錯誤資料向下游傳播之前識別它。相同原則適用：驗證收到的資料、了解它從何而來，並防止壞資料變成別人的問題。

Great Expectations 成為該基礎的一部分：在攝取時進行結構描述與範圍驗證、為鮮度設定每來源 SLA、跨系統檢查一致性，以及建立檔案層級血緣。所有這些都位於寫入—稽核—發布模式之後；資料先進入暫存區，經過驗證，只有在通過必要檢查後才會向下游移動。

結果在下游顯現出來：整體準確度提高，無論是在報表、ML 模型，還是建立於同一資料之上的 AI 檢索中都是如此。

週一早上該做什麼

如果你在生產環境中運行基於檢索的 AI 系統，診斷問題不在於下一步要嘗試哪個模型，或要遷移到哪種檢索架構。它是四個更具體的問題：

1. 底層資料是否依照其消費者所要求的標準進行驗證？
2. 目前以高信心提供的最舊內容是什麼？
3. 同一來源的兩個片段是否可能在同一檢索結果中彼此矛盾？
4. 如果結果被證明是錯的，你能追溯它從何而來嗎？

如果你無法回答這些問題，那麼缺口就在你的來源系統與代理讀取內容之間的管線中。這是資料工程修復，不是更換模型或遷移供應商。

無論你是在建構報表管線、ML 系統還是 AI 代理，正確性、鮮度、一致性與血緣，才是讓資料值得信任的要素。AI 只是暴露出資料工程中一直存在的弱點。