與其每次現場翻資料，不如先把答案整理好：Pinecone 想把 RAG 的老毛病一次修掉
TL;DR
- RAG 有三個很少被講白的問題：每問一次就重做一次同樣的功課、同一個問題兩次答案不一樣、撈回來的東西常常不是真的相關
- Pinecone 的新產品 Nexus 把「上下文」當成資料庫裡的 materialized view（預先算好存起來的檢視表），事先整理一次，之後所有 agent 直接拿
- 這個做法順便解決了權限問題：個人層、部門層、公司層的知識可以各自打包，再依任務組起來
- 每份整理好的上下文都帶著自己的 schema、metadata、來源追溯，可以查「這份東西是幾點幾分從哪個資料集生出來的」
- 官方說法是 token 用量最多省九成，任務完成速度明顯變快
- 我的判斷：這本質上是把資料工程二十年的老東西搬過來，方向對，但賭的是「你猜得到使用者會問什麼」
這集在 2026 年 9 月 3 日播出的 Software Engineering Daily，是一檔跑了十幾年的軟體工程訪談節目，走的是硬派技術路線，不太聊融資和估值，就聊系統怎麼蓋。這集的主持人是 Kevin Ball（大家叫他 KBall），他是 Mento 的工程副總，也在 Latent Space 主持 AI in Action 討論組。
來賓是 Pinecone 的工程副總 Jörg Schad。Pinecone 是目前最多人用的向量資料庫（vector database，專門存「語意相似度」而不是傳統欄位的資料庫），大量的 RAG 系統底層跑的就是它。Jörg 的背景滿有意思，二十年前在研究所做分散式查詢最佳化，後來在 SAP 做 HANA，接著跳去做 Apache Mesos，也碰過早期的 Kubernetes，再後來當過圖資料庫 ArangoDB 的技術長。一個做了半輩子資料庫的人，現在來解 AI 的檢索問題，這個組合本身就說明了一件事：這個產業正在回頭找老答案。
先講清楚 RAG 到底哪裡不夠用
RAG 的邏輯很單純：使用者問問題，系統去向量資料庫裡撈相似的片段，塞給模型，模型再回答。
Jörg 沒有否定它，他說 RAG 對「把資訊攤出來」這件事做得很好。但問題出在攤出來之後。
模型拿到一堆碎片之後，還得自己做整理、篩選、彙總。這件事在資料工程界有個名字叫 ETL（Extract-Transform-Load，把資料抽出來、轉換、再載入）。差別在於，RAG 是把 ETL 放在每一次查詢的當下現做，而且每次都重做一遍。
更麻煩的是一致性。你問「去年的營收是多少」，agent 是機率性系統，這次可能撈到會計年度的版本，下次撈到日曆年度的版本，兩個數字都不算錯，但你得到兩個答案。在企業場景這是災難。
Jörg 講到一個很具體的痛：他以前熬夜重建 lineage（資料血緣，追查一筆資料是從哪裡來的）只為了 debug 生產環境的問題，要向人解釋「為什麼這個數字會出現在這個特徵裡」。RAG 這套流程基本上沒有這種東西可以查。
Materialized view 這個老招
Nexus 的核心概念，其實就是資料庫用了幾十年的 materialized view。
一般的 view 是你查的時候才即時算，materialized view 是先算好存起來，查的時候直接拿。犧牲一點即時性，換到速度跟一致性。
Nexus 把這招搬到上下文上：先把公司的文件跟資料整理成一份「已經編譯好」的知識資產，agent 要用的時候一次呼叫拿走，不用每次重組。
一旦上下文變成一個獨立的實體，很多東西就順著解決了。
權限。Jörg 舉的例子很清楚：財務的敏感資料不想給模型看，那就建一個只包含月度彙總、不含明細的上下文，agent 只能碰到這一層。企業裡可以有個人層（我這一小時做的事）、部門層（整個財務團隊共用）、公司層（全公司通用）三種上下文，執行特定任務時再把需要的幾份組起來。
可重現性。同一個問題，同一份上下文，答案就會一樣。
來源追溯。每份上下文都記得自己是「兩天前下午兩點從哪個資料集生出來的」，還帶著指回原始文件的指標。
之前在你按下 Enter 之後，那 20 萬個字背後有一整條產線在跑聊過推論這一側的快取路由，Nexus 做的是資料那一側的同一件事：把重複的工作提前做掉一次。
上下文不是一坨文字，它有 schema
這是我覺得整集最值得記的一段。
Nexus 裡的一份上下文，同時包含向量索引（可以做相似度搜尋）、結構化的 schema、抽出來的實體（日期、人名等等），還有實體之間的關係。Jörg 說這其實是一個「便宜版的知識圖譜」。
旁邊還掛著 metadata：這份東西多新、從哪來、以及對語意層（semantic layer）的引用。
語意層那段舉的例子很生活化：「年度營收」到底是什麼意思？是日曆年還是會計年？矽谷新創大多兩者相同，但傳統企業不一定。這種定義平常都存在人的腦袋裡，人類同事之間靠默契運作，但 agent 沒有默契，你得寫下來擺在旁邊。
主持人補了一句我很同意的話：「大家都在說 agent 需要更好的語意層，因為人類把這些東西放在自己腦子裡，agent 需要它就擺在手邊。」
整理這件事本身，也要版控
Nexus 的做法拆成兩步：先產生一份「怎麼整理」的程式（curation artifact），再執行它。
關鍵在於中間那份程式要版控。因為資料是會變的，這份整理邏輯要能重複套用、能回頭看舊版本。Jörg 說早期那就是一支 Python 程式，現在多半由 agent 從一份規格自動生成。
品質怎麼顧？他們的做法是：如果客戶手上有幾個實際想問的問題，就用這幾題長出一整組評測集，然後反覆迭代。有明確方向的整理，永遠比「什麼都可能被問到」的通用整理來得準。
他也丟了一個滿有畫面的想法：schema 本身就是一組約束條件。你知道「營收不會是負數」「會議出席人數不會是負的」，那就把它寫成規則。之後兩份資料對不起來的時候，系統可以主動舉手說這裡有衝突。甚至可以學到「這份資料源永遠慢兩天，所以最近兩天的先別信」，然後自動把那段跳過。
不過他自己也承認，這段是在做夢，目前還沒看到有系統真的做到。這種坦白我滿喜歡的。
「我只有五成把握」對 agent 來說是有用的資訊
有一段對話我聽了會心一笑。
主持人問，如果資料本身就沒有絕對正確答案（他日常處理的是人與人之間的關係資料），能不能給每筆資訊掛一個信心值？
Jörg 說當然可以，知識圖譜的邊本來就能帶信心分數，新資訊進來就更新。
但接下來這句才是重點：agent 跟人類消費資料的方式不一樣。
人類發一個查詢，期待拿到一個答案，然後就拿著這個答案往下走。agent 不是，它會迭代。所以當系統回「這個答案我只有五分之一的把握」，對 agent 來說反而是有價值的，它可以掉頭改問「那有哪些事實你的把握超過某個門檻？」，重新規劃下一步。人類要做這種轉向要花好幾秒思考，agent 幾乎不用成本。
當然反過來說，從治理角度你也可以設一條線：低於五成的東西根本別給 agent 看。這是兩種完全合理但相反的設計，取決於你有多信任那個 agent。
少一層迴圈，就少一分不可靠
主持人講了一個框架我覺得很好用：LLM 擅長處理可以線性描述的事情，抽象層數一多，它就同時變貴又變不可靠。
所以能把巢狀的迴圈拆掉，就拆。Nexus 做的事情本質上就是：把「探索並整理資料」這個內層迴圈提前做完一次，之後外層迴圈就只剩一層。
Jörg 用軟體工程來類比：這跟把共用邏輯抽成一個函式是同一回事。你看高階程式碼的時候只需要理解那個介面，需要細節再進去看實作。人跟模型在這件事上的限制居然是一樣的。
再往下推一層還有個好處：因為介面固定（他們用一套叫 NoQL 的查詢語言，可以在查詢裡指定「我要的答案單位是美金不是歐元」這種結構化要求），內部表示法就可以隨便換。上下文可以有 v2、v3、v4，schema 整個改掉，外面完全無感。這就是 Docker container 的思路，只是換到資料上。
我的幾個判斷
方向是對的，但這是一場賭注。 預先編譯的前提是你猜得到大家會問什麼。Jörg 自己也講了，有明確問題清單的整理效果最好，通用整理最難。所以這套東西在「問題範圍相對收斂」的場景（財務、法務、客服）會很有效，在「什麼都可能被問」的場景就會退化回 RAG。天下沒有白吃的快取。
全端整合這件事要留意。 Jörg 說他們刻意掌握整條技術棧，因為這樣才能把 lineage 跟權限做穿。他預估要再迭代兩年才可能長出通用標準，而且第一個會標準化的大概是查詢與回應格式。這個判斷我認同，但對採購方來說意思是：未來兩年你買的任何一套這類產品，都是深度綁定的。想清楚再簽。
這其實不是新東西，是老東西找到新工作。 materialized view、資料血緣、語意層、約束條件、版本控制，全部都是資料工程界躺了二十年的東西。之前在油價變成負的那天，壞掉的不是市場，是「價格一定是正的」這個假設聊過把真實世界塞進表格有多難，那些痛點跟這集講的幾乎是同一批。差別只在於，以前這些工夫是做給人看的儀表板，現在是做給 agent 吃的。
而 agent 比人挑剔多了。人看到一份怪怪的報表會皺眉頭然後去問同事，agent 不會，它會很有自信地把錯的東西講出來。
所以與其一直等更聰明的模型，不如先把自己家的資料整理乾淨。這句話講起來很無聊，但大概是這集最實用的一句。
想看更多這類把技術講到底層的產業筆記，歡迎訂閱 wilsonhuang.xyz。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件