你的RAG系統(tǒng)正在用一把錘子砸所有釘子。標(biāo)準(zhǔn)流程是：語(yǔ)義搜索→取Top-K→塞進(jìn)上下文。簡(jiǎn)單查詢能糊弄過(guò)去，遇到多跳問(wèn)題直接崩盤——那種需要跨文檔串聯(lián)、追蹤引用鏈、區(qū)分相似概念的復(fù)雜請(qǐng)求，單一路徑檢索根本扛不住。

Multi-hop查詢的失敗率，本質(zhì)是工具箱太薄。 用戶問(wèn)"特斯拉2023年電池供應(yīng)商的CEO之前在哪任職"， naive RAG要么漏掉供應(yīng)商名單，要么抓錯(cuò)CEO履歷。信息散落在不同文檔層級(jí)，單一檢索策略只能摸到皮毛。

三層檢索：把選擇權(quán)還給模型

A-RAG（代理式分層檢索架構(gòu)）的核心改動(dòng)：給LLM配了三把專用工具。關(guān)鍵詞搜索鎖死精確匹配，語(yǔ)義搜索兜住概念關(guān)聯(lián)，塊級(jí)閱讀（chunk read）深挖上下文。代理按子查詢特征動(dòng)態(tài)調(diào)度，不再一條路走到黑。

這套架構(gòu)的聰明之處在分工顆粒度。關(guān)鍵詞搜索對(duì)付實(shí)體名、日期、專有術(shù)語(yǔ)；語(yǔ)義搜索處理"類似""相關(guān)"這類模糊需求；塊級(jí)閱讀專門啃長(zhǎng)文檔里的隱蔽關(guān)聯(lián)。三者互補(bǔ)，而非互相替代。

檢索 token 消耗反而下降了。 聽(tīng)起來(lái)反直覺(jué)——工具多了，開(kāi)銷少了。原因是精準(zhǔn)命中減少了無(wú)效上下文堆砌。標(biāo)準(zhǔn)RAG為了覆蓋盲區(qū)，往往盲目擴(kuò)大Top-K，結(jié)果噪聲淹沒(méi)信號(hào)。分層檢索用對(duì)工具，一次到位。

多跳場(chǎng)景：從"猜答案"到"拼拼圖"

測(cè)試中最刁鉆的案例：用戶問(wèn)某論文方法在后續(xù)研究中的改進(jìn)版本。這需要先定位原論文，再追蹤引用網(wǎng)絡(luò)，最后比對(duì)方法差異。naive RAG卡在第一步，語(yǔ)義搜索把"改進(jìn)"和"批評(píng)"混為一談；A-RAG用關(guān)鍵詞鎖死論文ID，塊級(jí)閱讀掃引用段落，語(yǔ)義搜索兜住概念變體，三步拆解決策鏈。

代理的調(diào)度邏輯也值得一提。它不是預(yù)設(shè)規(guī)則，而是讓模型自己判斷"現(xiàn)在該用哪把錘子"。這種設(shè)計(jì)把檢索策略從工程硬編碼解放出來(lái)，交給上下文感知能力更強(qiáng)的LLM臨場(chǎng)決策。

代價(jià)：延遲與復(fù)雜度的 trade-off

三層架構(gòu)不是免費(fèi)午餐。工具調(diào)用次數(shù)上升，端到端延遲必然增加。論文沒(méi)給具體數(shù)字，但代理決策本身需要推理時(shí)間，這是架構(gòu)性成本。適合答案質(zhì)量?jī)?yōu)先、延遲容忍度高的場(chǎng)景——比如法律研究、醫(yī)學(xué)文獻(xiàn)綜述，而非實(shí)時(shí)客服。

另一個(gè)隱性成本是調(diào)試難度。單一路徑出問(wèn)題容易定位，三工具交叉調(diào)度，失敗歸因復(fù)雜得多。團(tuán)隊(duì)得準(zhǔn)備好追蹤代理的決策日志，否則"為什么這次用了語(yǔ)義而非關(guān)鍵詞"會(huì)成為黑盒。

Google Research 把這套方案開(kāi)源了。GitHub 倉(cāng)庫(kù)里有個(gè)細(xì)節(jié)：chunk read 工具的實(shí)現(xiàn)用了滑動(dòng)窗口重排，而非簡(jiǎn)單截?cái)唷＿@解釋了為什么它能抓到跨段落引用——窗口邊界重疊，信息不丟。

你的RAG pipeline現(xiàn)在幾把工具？如果還是"語(yǔ)義搜索+祈禱"，多跳查詢就是定時(shí)炸彈。