AI Agent 的真正瓶頸不是模型，是你的資料系統還在服務人類

本文整理自《AI + a16z》2026 年 5 月播出的單集。

---

當 Agent 變成你的主要使用者

大約八、九個月前，Pinecone 的團隊發現了一件奇怪的事：他們系統上的「使用者」不再是人類了。查詢量暴增，但行為模式完全不像人類會做的事。這些查詢來自 AI Agent，它們正在用一種近乎暴力的方式，反覆敲打 Pinecone 的向量資料庫，試圖拼湊出完成任務所需的資訊。Pinecone 執行長阿什．阿舒托什（Ash Ashutosh）在 a16z 的 Podcast 中描述了這個轉折：一個為人類設計的介面，突然要服務完全不同物種的使用者。

這不是 Pinecone 獨有的問題。今天所有的資料庫、搜尋引擎、API 介面，都是圍繞一個假設建造的：使用者是人類，人類會看結果、判斷品質、決定下一步。但 Agent 沒有這些能力。它收到任務後，只能不斷發出查詢、取得資料片段、再發出更多查詢，直到它認為自己蒐集了足夠的資訊。一個簡單的「這個產品還在保固期嗎？」的問題，Agent 可能要對五、六個不同系統發出四十次查詢，才能拼湊出答案。

加州大學柏克萊分校的一項研究把這個問題量化了：AI Agent 有 85% 的工作負載花在知識檢索上，只有 15% 是真正的模型推理。這個數字徹底翻轉了我們對 Agent 效能瓶頸的認知。多數人以為模型不夠聰明是問題所在，但事實上，模型很聰明，它只是被困在一個不是為它設計的系統裡，花大量時間做一件它不擅長的事：在人類介面上笨拙地搜尋資料。

從圖書館到專家：知識引擎的概念

阿舒托什用了一個很有畫面感的比喻來解釋向量資料庫和知識引擎的差異。向量資料庫像一座圖書館：裡面有海量的資訊，你進去之後得自己找到對的書架、翻到對的頁面、跨多本書交叉比對，最後在腦中綜合出一個答案。人類做得到這件事，因為我們有背景知識、有判斷力、知道什麼資訊可以忽略。

Agent 做不到。它走進這座圖書館，沒有任何事先建立的背景知識，只能把所有看起來可能相關的書全部拿下來讀。讀完之後如果覺得資訊不夠，再去找更多。如果發現兩本書的內容衝突，還得再找第三本來仲裁。整個過程消耗大量的 token（也就是錢）、花費大量的時間，而且經常在反覆循環後仍然給出錯誤的答案。在 Pinecone 自己的內部測試中，Agent 在傳統架構上的任務完成率最好也只有約 68%，平均更低。

知識引擎的概念完全不同。它不是圖書館，而更像一位特定領域的專家。一個負責醫療帳單的知識引擎，知道帳單任務需要哪些資訊：病患身分、醫生資料、帳單金額。它不會去管醫學研究文獻、不會去管處方簽資料，因為那些跟帳單任務無關。它已經事先理解了任務脈絡，知道什麼該給、什麼該忽略。當 Agent 來查詢時，它直接提供結構化的、帶有引用來源的精確答案，而不是一堆原始資料片段讓 Agent 自己去拼。

這個差異帶來的效能提升是驚人的。在 Pinecone 的內部應用中，token 使用量從 40,000 降到 2,000，降幅高達 95%。回應時間從一到兩分鐘降到 500 毫秒以內。任務完成率從不到 50% 跳到 90% 以上。而且這還只是第一版。

Context Compiling：取代 ETL 的新思路

知識引擎的核心技術叫做「Context Compiling」（情境編譯），這個詞精確描述了它和傳統 ETL pipeline 的本質差異。傳統 ETL 做的事情是：從 A 點取出資料、轉換格式、載入 B 點。這是一次性的靜態搬運，搬完就結束了。Context Compiling 則完全不同，它是一個持續迭代的過程，更像是在「訓練」一個知識引擎。

具體來說，你給系統兩樣東西：原始資料，以及你期望得到的輸出格式和答案樣本。系統會自動找出如何將原始資料拆解、重組成全新的資料結構（Pinecone 稱之為 artifacts），使得這些結構能精確對應你定義的任務需求。這個過程通常需要三到五輪迭代，幾分鐘就能完成。阿舒托什形容這就像編譯器：你寫原始碼，編譯器產生機器碼。只不過這個編譯器會持續優化，直到產出的結果符合你的品質要求。

Pinecone 用自家的合約管理當作測試場景。他們把數百份合約丟進系統，標記哪些是成功的合約、哪些有紅燈，然後讓 Context Compiler 找出從原始合約到審核結論之間的轉換路徑。整個過程幾分鐘就完成，產出的 artifacts 完全不同於原始文件的結構，但精確包含了審核任務所需的一切資訊。

更重要的是，Context Compiling 是動態的。當新資料進來，它會即時轉換成對應的格式，不需要重跑整條 pipeline。這解決了傳統 ETL 最大的痛點：每次資料源更新，你都得手動觸發或排程整條流水線重跑一次。在 Agent 時代，資料更新的頻率和查詢的頻率都遠高於人類使用場景，靜態 pipeline 根本跟不上。

NoQL：Agent 時代的 SQL

有了知識引擎，下一個問題是：Agent 要怎麼跟它溝通？人類可以用自然語言描述需求，但機器對機器的溝通需要更精確的協定。Pinecone 為此設計了一個新的查詢語言叫 NoQL（Knowledge Query Language），定位類似 SQL 之於關聯式資料庫、GraphQL 之於 API。

NoQL 的設計圍繞三個核心維度。第一是意圖（Intent）：Agent 明確告訴知識引擎它要什麼資訊、資料範圍多大。第二是效能要求：Agent 可以指定「我需要在 45 毫秒內得到回應」，讓知識引擎根據時間預算決定搜尋深度。第三是治理（Governance）：控制資料存取範圍、要求可解釋性、確保引用來源可追溯。這三個維度用六個基本參數就能表達，簡潔但足以覆蓋企業級 Agent 的需求。

為什麼需要一個專門的查詢語言？因為目前 Agent 和資料系統之間的溝通方式太原始了。透過 MCP（Model Context Protocol）連接各種資料源的做法已經成為事實標準，但每個 MCP 介面都會吃掉大量 token，因為它們沒有針對機器溝通做優化。NoQL 的目標是成為開放標準，讓任何知識引擎（不只是 Pinecone 的 Nexus）都能用相同的協定與 Agent 交流。Pinecone 計畫先透過開發者社群推廣，再推動成為產業標準，走的是 SQL 和 GraphQL 相同的路徑。

我的觀察

這集 Podcast 最讓我在意的數字是 85% vs 15%。如果 Agent 真的把絕大多數時間花在資料檢索而非推理，那整個產業目前對「模型能力」的執著就有點搞錯方向了。我們花了大量資源讓模型更聰明，但真正的效能瓶頸可能在更底層的地方。

當然，Pinecone 作為資料基礎設施公司，有動機強調「資料層才是關鍵」。但他們提出的數據如果可以被獨立驗證（token 降 95%、完成率從 50% 到 90%），那這不只是產品行銷，而是整個 AI 應用架構的典範轉移訊號。開發者過去兩年在 RAG 上踩過的坑，多數都不是 prompt engineering 能解決的，而是底層資料供給的結構性問題。知識引擎是否就是答案，還需要更多實戰驗證，但方向值得關注。