Pinecone 工程副總裁 Jörg Schad 在 11 月 4 日的一場網路研討會上，完整梳理了檢索技術從關鍵詞搜尋到 RAG 的演進路徑，並重點討論了當 AI 代理而不是人類來消費檢索結果時，整個系統需要補上哪一層能力。這場分享由 Pinecone 官方部落格整理成文，以下為核心內容的重述。
研討會上給出的第一個例子頗具代表性：讓代理預測第四季度移動業務的增長，代理生成 SQL、執行查詢，然後返回 +16% 的結果。問題在於，9 月 8 日當天有一次僅持續一天的合作伙伴促銷活動，代理把這個流量尖峰當成了真實需求。如果按正確口徑處理——把促銷從預測中剔除、但仍保留在已報告的總量裡——同樣的趨勢得到的結論是 +6%。資料本身都在，SQL 也完全合法，錯的只是判斷。
Schad 用這個案例說明，檢索的每一代技術都在修補上一代的短板，但每一代也都有自己的天花板。關鍵詞搜尋依賴倒排索引，用 IDF（可追溯到 1972 年）和 BM25（1994 年）等相關性指標排序，能夠在大規模資料上實現精確匹配，可它永遠匹配不到“取消”和“終止訂閱”之間的語義聯絡。語義搜尋藉助 word2vec（2013 年）、用於近似最近鄰搜尋的 HNSW（2016 年）以及 BERT（2018 年），跨越詞彙差異找到語義相關的內容，其侷限則變成了“設計文件問題”：兩篇文件可能都與查詢高度相似，但只有一篇描述的是今天真正執行的程式碼，而相似度分數無法告訴你哪一篇才算數。
2020 年 Lewis 等人提出的 RAG，讓模型可以在查詢時把答案錨定在知識庫上，此後幾乎每一個聊天演示都離不開它。但 Schad 強調，這種錨定是不受校驗的：模型拿到檢索返回的一切，卻沒有任何步驟去檢查它是不是正確結果，也沒有人去核對模型是否真的使用了它。
檢索質量通常用 Recall@K 衡量，例如 Recall@10 表示相關文件出現在前十條結果中的比例。它是一個衡量“資訊在不在”的好指標，卻無法衡量“資訊對不對”。假設某條政策已被新版本取代，檢索會把兩個版本都返回，召回率把兩條都算作相關；一個基於舊版本做出的、看似合理的回答，實際得分是零，而 Recall@K 依然好看。同樣的問題也出現在許可權上：某份文件與查詢高度相關，但呼叫方根本沒有許可權檢視它，召回率不會因此扣分。
那麼，如何讓語義搜尋更準確？Schad 的答案是：很多時候搜尋本身已經完成了它的工作，缺的是搜尋之外的資訊。他舉了一個併購場景：兩家公司合併後，一家財年從 1 月到 12 月，另一家從 2 月到次年 1 月，同一個“季度”在兩側對應著不同的月份。對於任何跨越兩家公司的問題，語義搜尋都能找到全部相關文件，卻無法說明這些文件該如何組合。再調檢索器也無濟於事，因為沒有任何相似度分數能承載“兩套財年日曆如何對齊”這樣的規則。
研討會上用一組對比表格把問題講得很清楚：預測第四季度增長時，檢索返回了包含 9 月 8 日尖峰的完整資料，真正做決定的是“那天是一次性促銷、應從預測中剔除”這條規則；詢問某個功能如何工作時，檢索同時返回三年前的設計文件和當天早晨的程式碼掃描結果，決定答案的是“哪份材料描述的是當前執行的程式碼”；併購後的跨公司數字，需要“1 月至 12 月如何對齊 2 月至 1 月”的規則；而“政策允許什麼”，則取決於新舊兩個版本中哪一個正在生效。換句話說，檢索按 Recall@K 評分，上下文則按基於它做出的決策來評分。
當答案由人閱讀時，這種缺失尚可彌補：一個人看到明顯偏高的預測，或者在不應下滑時出現下滑，會皺起眉頭重新核對。但當自主代理來讀答案時，它可能直接把結果發出去，而且代理呼叫檢索的規模是任何人類搜尋都無法比擬的。高併發下的代理未必能察覺結果不合理或已過期，也未必會主動為答案尋找依據——它缺的正是能告訴它這些的上下文。
那麼為什麼不乾脆把全部資訊都交給模型，讓它自己判斷相關性？Schad 引用了 Chroma 的“上下文衰減”報告：該研究評估了 18 個大語言模型，發現在輸入長度增加時，模型表現會越來越不可靠，即便任務被刻意設計得很簡單。在 LongMemEval 上，平均約 300 個 token 的聚焦提示優於平均約 113,000 個 token 的完整提示。對代理同樣如此：把與任務無關的資訊灌進去，結果只會更差。於是問題從“正確的文件有沒有被召回”變成了“代理還需要知道哪些內容是有效、可信、被允許且適合當前任務的”。
在架構上，Pinecone 的做法是把檢索保留下來，並在其上疊加一層“決策層”。檢索側，Pinecone 在同一個索引中同時提供稠密向量、稀疏向量和基於 BM25 排序的全文檢索，三種能力都內建於資料庫而無需外掛。Schad 表示，不同任務需要不同的檢索工具，很多工需要不止一種，而關鍵詞搜尋在需要精確匹配的場景中依然不可替代。
決策層為每個任務維護一份“任務上下文”，其中包含摘要、實體、策略與規則，以及在查詢到來之前就在後臺整理好的知識製品。上下文負責判斷哪些製品與當前任務相關，再根據需要向索引發起詞法、向量或混合查詢。回到併購的例子：搜尋已經找齊了所有文件，缺失的是“一套財年日曆如何對映到另一套”這種語義資訊，它被放在任務上下文中，與策略和規則並列。被取代的政策、以及資料機器人遇到的一次性促銷，處理方式如出一轍——索引提供資料，上下文中的規則決定如何對待它。
這也是 Pinecone Nexus（面向代理的知識引擎）的定位。Nexus 的整理流程會維護一份已處理來源的賬本，以內容雜湊追蹤，因此一次執行只觸碰發生變化的內容。答案會附帶引用，標明每個結論背後的檔案、頁碼和原文片段。優先順序同樣被明確寫下來：上下文的預設指令相當於針對該上下文每次查詢的系統提示，可以規定模型如何處理相互衝突的來源，例如哪一版政策勝出。
Schad 也坦率地劃出了邊界：Nexus 並非適合所有工作負載。如果檢索模式簡單、你有把握前十條結果裡就有答案、沒有複雜的規則或政策來決定哪個來源勝出，並且你願意自己負責錨定環節，那麼 RAG 已經夠用。像大型線上商店裡每一筆購買這樣每秒都在變化的運營資料，更適合即時動態檢視，全天被就地編輯的即時流和記錄目前也不適合 Nexus；它最適合資料變化節奏較慢的場景，例如合同和研究資料。
他給出的最後建議是：在花一個迭代週期去調嵌入或重排之前，先檢查檢索是否其實已經找到了文件。如果答案是肯定的，那麼真正需要修補的，是那個負責做決定的上層。完整回放已釋出在 YouTube 上，想動手搭建這一層的讀者可以從 Nexus 文件或申請試用開始。