AI Engineering
Pinecone Nexus 的訊號：Agentic RAG 的瓶頸不是模型，而是知識基礎設施
Pinecone 發布 Nexus，把 Agentic RAG 的問題定義為知識檢索與脈絡組裝的基礎設施問題：agent 花太多時間找資料、拼資料，導致成本、延遲、可靠性與治理失控。真正重點不是「RAG 已死」，而是從 runtime retrieval 轉向 compile-time knowledge artifacts。
2026年5月12日2 分鐘閱讀👁 6
Agentic RAG / Knowledge Engine
Pinecone Nexus 的訊號：RAG 沒死，但「每次都現場拼知識」的做法正在失效
Threads 貼文抓到一個重要轉折：向量資料庫代表廠商 Pinecone 不是說檢索不重要，而是承認 agent 時代的檢索模式變了。當 agent 要完成任務，而不是人類點開搜尋結果時，單純丟 chunks 給模型會變成延遲、成本、幻覺與治理問題。
核心判讀：「RAG 已死」是過度標題。比較準確的說法是：傳統 RAG / Agentic RAG 不能只靠 runtime 多輪搜尋補洞，企業級 agent 需要先把資料編譯成可追溯、可治理、符合任務需求的 knowledge artifacts。
Pinecone 自己點出的痛點
官方文章提到，agent 在任務迴圈中約 85% effort 花在 knowledge retrieval，輸出仍需人工 review，任務完成率停在 50–60%，延遲與 token cost 變得不可預測。這不是單一模型能力不足，而是知識供應方式不適合 agent workload。
Nexus 的主張：Knowledge Engine
Pinecone 把 Nexus 定位為 knowledge engine，而不是 retrieval system。差異在於：retrieval system 找文件、交給模型即時讀；knowledge engine 先把資料結構化、脈絡化、組成 derived artifacts，再讓 agent 用更明確的格式查詢。
從 runtime reasoning 移到 compile time
傳統做法讓模型每次查詢都重新讀 chunks、判斷缺口、再查、再整合。Nexus 的方向是把一部分 orientation work 往前移：資料先經 context compiler 形成 task-optimized contexts，agent 查詢時拿到的是更接近答案的結構化知識。
治理也是產品核心
企業場景需要 RBAC、PII 標記、版本、provenance、token/spend visibility。這些東西如果只是事後補在 RAG pipeline 外面，會很難進 production。
| 做法 | 適合誰 | 主要風險 |
|---|---|---|
| 傳統 RAG | 人類查文件、簡單問答 | 跨文件推理弱、上下文碎片化 |
| Agentic RAG | agent 可多輪找資料 | 慢、貴、不可預測，容易 loop |
| Knowledge Engine | 企業級 agent 任務 | 需要前期資料治理、eval 與 domain artifact 設計 |
實務啟示
- 不要把所有 agent 失敗都怪模型；先檢查資料是不是以 agent 可用的方式供應。
- 高價值任務應建立固定 artifact：客戶脈絡、合約脈絡、專案脈絡、供應鏈脈絡，而不是每次臨時 grep / search。
- RAG pipeline 要有 eval；否則無法知道 context compiler / retrieval strategy 是否真的改善。
- 企業 agent 的知識層必須內建權限與出處，不然很難過合規與安全審查。