為什麼你的 RAG 應用程式在回答雙重問題時，會用充滿自信的一段話，卻兩個部分都沒答到？假設使用者問：「哪一家供應商最近最常未達 SLA？而且該供應商在那一季是否也曾被標記有法遵問題？」最後得到的回答讀起來很順，卻沒有解決任何問題，而問題並不在模型。這個問題需要兩個事實，而這兩個事實分散在彼此毫無關聯的不同文件中，因此單次搜尋無法從第一個事實找到第二個事實。要取得第二個事實，需要再進行一次搜尋，而且這次搜尋必須根據第一次搜尋找到的內容來建立。這就是多跳檢索（multi-hop retrieval）：依序執行多次搜尋的策略，每次查詢都根據上一輪的結果來調整。

向量搜尋在 AI 答案生成方面有哪些不足？

單次向量搜尋會將整個問題嵌入成一個向量，再依照段落與該向量的相似程度進行排序。當一個問題需要連結兩個事實時，產生的嵌入向量可能會接近談論這兩個主題的段落，卻不一定能接近包含兩者關聯性的內容。承載第二個事實的文件，通常幾乎不會使用問題原本的措辭，因此在還不知道第一個答案之前，你根本無法搜尋第二個事實，而這正是單次搜尋無法做到的事。

MultiHop-RAG 的建立目的，就是衡量單次檢索處理這類問題時的不足程度：它在新聞語料庫上測試了 2,556 個查詢，其中大多數查詢的證據分散在兩到四份不同的文件中。標準嵌入模型與商用 LLM 在這項測試中的表現都不佳，而這個結果的意義在於：問題不只是調校不足。

這些失敗通常會呈現出幾種值得你在自己的查詢紀錄中辨識的形式：

• 比較。 兩個實體加上一個判斷：哪家供應商未達標的次數較多、哪個地區落後。
• 排序。 只有從不同紀錄中分別取得各事件日期後，才能判斷事件發生的先後順序。
• 推論。 沒有人直接寫下這個事實，它只能由兩個已被記錄的事實推導出來。

這三種形式都不是提示詞問題：如果證據根本沒有傳遞給模型，再怎麼改寫指令，也無法改善答案。

多跳檢索如何運作？

多跳系統不會只將問題嵌入一次，而是先把問題拆成子問題，針對第一個子問題進行檢索，再將取得的內容納入第二次查詢。DSPy 的多跳教學清楚呈現了在各跳之間傳遞的狀態，方法是搭配兩個模組：其中一個負責產生下一個搜尋查詢，另一個則將從剛才檢索段落中擷取的筆記附加上去。如此一來，第二跳就能搜尋原始問題中從未出現的詞彙，因為第一跳已經提供了該詞彙。

Self-ask prompting 在模型層級將相同的做法形式化。在回答收到的問題之前，模型會先自行提出一個後續問題、回答該問題，再利用這個答案完成原始問題。

每一跳都會擴大搜尋範圍，因此整個鏈結需要停止條件，否則它會不斷搜尋下去。這代表你需要設定跳數上限，並在每次搜尋後檢查目前的證據是否已足以回答問題，或答案是否已不再改善。跳數是由你控制的參數，而不是系統會自行找出的數字。

為什麼天真的鏈結方式會失效？如何改善？

如果只是用最直覺的方式串接各跳，錯誤會逐步累積。每一輪都會把累積的內容重新整理成新的查詢，再次進行搜尋，並且每次都將目前狀態壓縮回單一向量。凡是被這個向量遺漏的資訊，就不會再回來。假設第一跳撈到一個干擾項：它在嵌入空間中很接近，卻與實際事實無關，那麼後續的每個查詢都會繼承這個錯誤方向。

Baleen 處理的是壓縮問題。每次跳轉後，它會將檢索到的段落濃縮成一份精簡摘要，並將摘要帶到下一跳，因此下一個查詢是根據已陳述的事實，而不是一段越來越長、也越來越模糊的輸入來建立。在需要針對兩份支援文件進行推理的 HotpotQA 上，Baleen 在檢索 20 個段落時，達到 96.3% 的答案召回率。

Beam Retrieval 處理的是過早做出決定的問題。它不會在每一跳只押注一個段落，而是保留數條候選鏈結，並跨所有跳共同訓練檢索器，因此早期的錯誤猜測只會淘汰其中一個分支，不會摧毀整個檢索流程。摘要壓縮有助於降低延遲；而在第一跳確實存在歧義的查詢上，Beam Retrieval 則能提高召回率。

如何在不需人工持續看管的情況下，將鏈結導入正式環境？

先來看一個最直接的反對理由：現在的上下文視窗已經很大了，為什麼不跳過鏈結，直接把廣泛搜尋得到的所有內容交給模型？原因在於資訊所在的位置仍然很重要。針對長上下文模型的研究發現，當答案所依據的事實位於上下文中間，而不是靠近開頭或結尾時，準確率會明顯下降。更大的視窗無法解決這個問題，因此在將證據交給模型之前，應先將其排序。

停止條件也不應只是硬編碼的跳數。Self-RAG 會訓練模型評估自行檢索到的段落，並判斷是否需要再次檢索。如此一來，「現在的資訊夠了嗎？」就會變成一個學習得到的訊號，而不是你在設定檔中隨手指定、之後便再也沒有重新檢視的數字。

然而，當語料庫持續變動時，這些機制都可能失效，而真正的維護工作就在這裡。文件會新增、分塊策略會重新調整，原本在三月能順利找到答案的鏈結，到了六月可能已經開始產生超出證據範圍的回答。鏈結本身無法回報這種效能衰退，因此包括 Progress Agentic RAG 在內的正式環境平台，會直接將評估機制建置在流程中。

Progress Agentic RAG 如何將多跳檢索納入其架構？

Progress Agentic RAG 內的基本 RAG 流程只會執行一次搜尋：問題傳送至語意搜尋，搜尋結果經過擴充後，再由 LLM 撰寫答案。Retrieval Agents 以可設定的工作流程取代這種單次搜尋，而該架構由兩個部分組成。Drivers 會連接問題可能需要使用的資料來源，包括已建立索引的文件語料庫、SQL 資料庫、網路搜尋服務與 MCP 伺服器；工作流程則決定問題如何從送入系統一路流向答案。

多跳檢索就發生在工作流程中。需要連結兩個事實的問題會先拆解成子問題，再將每個子問題路由至真正能回答它的 Driver。針對每個子問題個別進行路由，比想像中更重要：第一跳可以查詢已建立索引的文件，第二跳則可以查詢 SQL Driver，因此兩個事實不必位於同一個資料儲存區，仍然能夠串接起來。自行開發的鏈結通常只會在單一索引中跳轉，所以當第二個事實位於其他位置時，流程就會中斷。

評估機制則負責完成整個閉環。平台自有的 RAG 評估模型 REMi 會定期執行，並隨時間繪製它產生的三項分數。其中兩項分數正好對應到鏈結失效的方式。Groundedness 能偵測答案是否超出鏈結所檢索到的證據；Context Relevance 則能偵測某一跳是否看似有信心地檢索，實際上卻取得了錯誤內容。先從這兩項分數開始：為現有紀錄中的查詢形式建立量測，觀察哪些分數發生變化，再根據證據顯示的需求增加跳數，而不是在所有地方一律加入多跳流程。

常見問題

多少跳才算太多？

已發表的多跳基準測試大多以兩到四跳為上限，這是一個合理的起始範圍。每增加一跳，通常就會多一次檢索往返與一次 LLM 呼叫，因此延遲與成本都會上升，而每一跳新增的證據量通常會逐漸減少。請設定硬性上限，再讓充分性檢查在只需一次搜尋即可解決的問題上提早結束鏈結。

執行多跳檢索一定需要知識圖譜嗎？

不需要。當你的網域具有穩定的實體關係時，圖譜能提供明確的關聯，縮小搜尋範圍。但即使沒有知識圖譜，多跳檢索仍然可以處理純文字，因為各跳之間的連結是由第一跳檢索到的內容傳遞，而不是依賴某人事先建立的邊。只有在這些關係本身值得長期維護時，才需要建立圖譜。

如何判斷我的流程是否真的需要多跳檢索？

找出目前流程回答不佳的問題，並檢查支援這些問題的證據位於何處。如果證據一再分散在多份文件中，單靠提示詞調整與重新排序就無法縮小差距。如果證據其實集中在同一份文件中，流程卻一直找不到，通常代表問題出在分塊或排序，多增加一跳也不會有幫助。