這項由香港科技大學（廣州）研究團隊完成的工作發表於2026年第43屆國際機器學習會議（ICML 2026），發表地點為韓國首爾，收錄於PMLR 306論文集，論文編號為arXiv:2605.00529。對希望深入了解技術細節的讀者，可通過該編號在arXiv上查閱完整論文，代碼也已在GitHub上公開。
**當AI需要"查資料"時，問題出在哪裡**
每天我們都在用搜尋引擎找資料，但你有沒有遇到過這樣的情況：你問的問題需要把好幾篇文章的資訊拼湊在一起才能回答，但搜索結果只給你一篇文章，看完這篇再找下一篇，找著找著就迷失了？對於現在的AI助手來說，這個問題更為棘手。
當一個AI大模型被要求回答問題時，它有兩種選擇：要麼靠自己"肚子裡"學來的知識回答，要麼去外部文檔庫里查找相關資料再回答。後者這種方式就叫做"檢索增強生成"，英文縮寫是RAG（Retrieval-Augmented Generation）。RAG的好處顯而易見——AI可以用最新的、最準確的外部資料來回答，而不是僅憑記憶。
然而，當文檔庫變得非常龐大，尤其是需要從多篇文章中"順藤摸瓜"地找到答案時，現有的RAG方法就開始力不從心了。比如這樣一個問題："影響碧昂絲的那位流行歌星，他參與製作的那部紀錄片，其製片人的妻子是誰？"要回答這個問題，AI必須先找到"影響碧昂絲的流行歌星是麥可·傑克森"，再找到"麥可·傑克森紀錄片的製片人是大衛·格斯特"，最後才能找到"大衛·格斯特的妻子是麗莎·明內利"。這種需要多步"接力"才能找到答案的問題，對現有AI系統構成了巨大挑戰。
香港科技大學（廣州）的研究團隊針對這一痛點，提出了一個新的框架，取名為Ψ-RAG（讀作"賽-RAG"，Ψ是希臘字母）。這個框架的核心思路是：像整理圖書館一樣，把大量文檔按照語義相似度組織成一棵有層次的"知識樹"，並配備一個能主動追問、逐步縮小範圍的智能檢索助手。在多項跨文檔多步推理基準測試中，Ψ-RAG比此前最流行的同類方法RAPTOR提升了25.9%的F1分數，也比當時最先進的圖譜型檢索方法HippoRAG 2高出了7.4%。
**一、為什麼已有的"樹狀索引"方法在大規模場景下會失靈**
要理解Ψ-RAG解決了什麼問題，先得知道它的前輩們是怎麼工作的，以及為什麼它們會遭遇困境。
在RAG領域，有一類方法叫做"樹狀RAG"（Tree-RAG）。它的思路非常直觀：把文檔里的段落按照內容相似性，像搭積木一樣層層疊加，底層是原始段落，往上是越來越抽象的摘要節點，最終形成一棵樹。查找資訊時，從樹頂往下走，逐層篩選，就像在圖書館裡先找大分類書架，再找小分類，最後找到具體那本書。
RAPTOR是這類方法裡最具代表性的框架。它的建樹方式是用一種叫做"高斯混合模型"（GMM）的聚類算法，把語義相近的段落歸為一組，這類算法本質上和我們熟知的K-means聚類是一家子。RAPTOR在單篇長文檔的場景下表現相當不錯，但當文檔庫擴展到成百上千篇文章時，問題就來了。
研究團隊發現了三個關鍵缺陷。第一個缺陷叫做"分布適應性差"。K-means類的聚類算法有一個隱藏的"壞習慣"：它天然傾向於把每個類別分配到大致相等的數量，也就是說，即使你的文檔庫里體育新聞占了90%、娛樂新聞只占10%，它也會硬生生地把一些體育文章塞進娛樂類的"堆"里，讓邊界變得模糊不清。這種現象被稱為"均勻效應"。一旦樹的節點被"污染"，檢索時就會混入大量無關資訊，就像你在找一本科幻小說，圖書管理員卻把它和歷史書放在了同一個書架上。
第二個缺陷叫做"結構孤立"。樹狀結構的本質是每個葉子節點（原始段落）只和它的直屬上級有連接，不同分支之間沒有橫向的關聯。這意味著，如果答案需要從兩棵不同"子樹"里各取一塊資訊拼合，樹狀檢索就很難捕捉到這種跨分支的關聯。
第三個缺陷叫做"抽象過粗"。樹的上層節點是摘要，摘要天然會丟失細節。當你在樹的高層搜索時，用來做匹配的是模糊的摘要，而不是包含具體人名、地名、數字的原文。就好像你在問"大衛·格斯特的妻子是誰"，但上層摘要只告訴你"這是一篇關於娛樂圈人物的文章"，根本抓不住"大衛·格斯特"這個具體人名。
**二、Ψ-RAG如何從零搭建一棵"更聰明的知識樹"**
針對上述三個缺陷，Ψ-RAG提出了兩項核心創新，分別解決建樹和檢索兩個階段的問題。先說建樹。
RAPTOR的建樹方式是"從上往下切割"——先定好要分幾組，再把所有段落往各組裡分配。Ψ-RAG的建樹方式則完全反過來，靈感來自一種叫做"層次聚合聚類"（AHC）的經典算法，是一種"從下往上合併"的策略。
整個過程可以用拼圖來理解。第一步，把所有文檔段落都變成一個數字向量（可以理解為每個段落在"語義空間"里的坐標），然後計算所有段落兩兩之間的相似度，按照從最相似到最不相似的順序排成一列。第二步，從最相似的那對段落開始，逐一處理。每次處理一對段落時，根據兩者當前的狀態，執行三種操作之一。
如果兩個段落都還是"孤家寡人"，那就給它們創建一個共同的父節點，就像把兩塊孤零零的拼圖片拼在一起，再給這個組合貼一個標籤。這叫做"合併"（Merging）。如果其中一個段落已經有了父節點，而另一個還沒有，那就把孤獨的那個段落也掛到同一個父節點下。這叫做"葉節點摺疊"（Leaf Node Collapse）。如果兩個段落都已經有了各自的"家族"（子樹），那就要看兩個子樹的深度是否一樣：深度相同，就給兩棵子樹再創建一個共同的祖先節點；深度不同，就把較淺的那棵子樹掛到較深那棵的對應層級上，確保整棵樹的深度保持一致。這叫做"抽象節點摺疊"（Abstract Node Collapse）。
這個過程恰好需要執行n-1次操作（n是段落總數），結束後所有段落都被連進了同一棵樹里。之後，系統會對"子節點過多"的節點進行再平衡分割，防止某個摘要節點需要同時概括太多內容，超出AI的處理上限。
建好樹的骨架之後，還需要為每個非葉節點生成一段摘要，作為檢索時的"導航標籤"。Ψ-RAG提供了兩種摘要風格：一種是段落式的概括性摘要，把子節點的關鍵資訊和邏輯關係用連貫的文字描述出來；另一種是關鍵詞式摘要，把子節點中出現的重要實體和主題詞提煉出來，形成一串關鍵詞，資訊密度更高。這棵由層次聚合方式構建的、每個節點都帶有摘要或關鍵詞標籤的樹，就是Ψ-RAG的"層次抽象樹"（Hierarchical Abstract Tree，簡稱HAT）。
**三、數學上的保證：為什麼這棵樹天然不會"偏心"**
光靠直覺說"這種方法更好"是不夠的，研究團隊用嚴格的數學推導證明了Ψ-RAG的建樹方式在理論上就具有更好的分布適應性。
他們引入了一個評估樹質量的標準，叫做"Dasgupta代價"。這個代價的核心思想是：語義上越相似的段落，應該在樹里越靠近（即它們的最近公共祖先節點應該越深）。一棵好的樹，應該讓語義相似的內容緊密聚合，語義差異大的內容分開存放。
研究團隊證明了兩件事。第一，如果給定一棵各個子樹大小完全均勻的樹，把其中一片葉子從一個子樹移到另一個子樹（打破均勻性），Ψ-RAG的優化目標會傾向於接受這種"非均勻"的調整，因為這樣能降低Dasgupta代價。這說明Ψ-RAG天然不偏愛均勻分布，不會像K-means那樣強行把所有類別弄成差不多大小。第二，如果樹里本來就存在一個"小眾"子樹（比如對應文檔庫里只有少量文章的那個話題），把一篇原本屬於"大眾"子樹的文章硬塞進小眾子樹，會顯著增加Dasgupta代價，也就是說Ψ-RAG會抵制這種操作。換句話說，Ψ-RAG的建樹邏輯會自然地保護少數話題的純粹性，不讓它們被多數話題的內容"稀釋"。
為了直觀驗證這個結論，研究團隊還做了一個可視化實驗。他們構造了幾個故意偏斜的數據集，比如50篇體育新聞混5篇商業新聞，然後分別用RAPTOR和Ψ-RAG建樹，把結果畫成圓形樹狀圖。RAPTOR的結果顯示，商業新聞的節點經常和體育新聞的摘要節點共享同一個父節點，也就是被"混搭"進了體育類的大家庭里；而Ψ-RAG建出的樹里，商業新聞的節點幾乎都老老實實待在自己的子樹里，沒有被體育內容干擾。
**四、不只是建好樹：如何讓檢索過程也變得更"聰明"**
即使有了一棵結構更合理的樹，如何在樹里找到答案依然是個難題，尤其是面對那種需要多步推理的問題。
Ψ-RAG的檢索機制有三個互相配合的組件。核心是一個叫做"檢索與回答代理"（R&A Agent）的智能體。這個代理就像一個有經驗的偵探，不是拿到線索就立刻下結論，而是會持續評估手頭資訊是否足夠，如果不夠就主動發出新的查詢請求。
具體來說，每次檢索後，代理會把返回的文檔段落讀完，然後做出判斷：如果已經能回答問題了，就給出答案；如果還不夠，就生成一個新的子問題，發出下一輪檢索請求，把新檢索到的文檔和之前的所有文檔一起再次分析。這個"檢索-推理-再檢索"的循環會一直持續，直到找到答案或者達到預設的最大檢索次數為止。
除了樹狀檢索之外，Ψ-RAG還同時維護了一個稀疏關鍵詞索引（基於經典的BM25算法）。這個關鍵詞索引擅長的事情恰好是樹狀索引的弱項：精確匹配特定人名、地名等專有名詞。回到那個"大衛·格斯特的妻子是誰"的例子，樹狀索引因為上層摘要太粗，可能找不到包含"大衛·格斯特"的具體段落；但關鍵詞索引直接搜索"David Gest"這個詞，立刻就能定位到相關文檔。
更聰明的是，代理被鼓勵在生成新的子查詢時，對問題進行"擴充重組"。比如，如果第一輪檢索後代理知道了"大衛·格斯特是一位美國電影製片人"，那麼它的第二個查詢就不會只是"大衛·格斯特的妻子是誰"，而是"美國電影製片人大衛·格斯特的妻子是誰"。加入描述性修飾詞，既幫助關鍵詞檢索排除了大量與"大衛"同名的不相關人物，也幫助樹狀檢索在上層摘要階段就抓住"電影製片人"這個高層語義特徵，從而更快鎖定到正確的子樹。
這種樹狀檢索和關鍵詞檢索的結果最終通過一個"重排序模型"（Reranker）融合，從所有檢索結果中選出最相關的若干段落送給代理。研究團隊發現，使用專門的重排序模型來融合兩種檢索結果，比簡單地把兩個排名列表取平均（互惠排名融合，RRF）效果更好。
**五、全面評測：Ψ-RAG在各類任務上表現如何**
研究團隊對Ψ-RAG進行了極為全面的測試，覆蓋了四類不同難度和粒度的任務。
第一類是單步和多步問答，也就是需要從大量文檔中找到一個具體詞語或短語作為答案的任務。測試用了六個數據集，包括專門考察單步問答的NQ和PopQA，以及專門考察多步推理的HotpotQA、2Wiki、MuSiQue和MultiHop-RAG，每個數據集各取1000個問題。結果顯示，在所有六個數據集的平均F1分數上，Ψ-RAG達到了62.77%（使用概括性摘要版本），而此前最好的樹狀RAG方法RAPTOR只有36.69%，差距接近26個百分點。更值得關注的是，Ψ-RAG也超過了此前被認為是多步問答領域頂尖水平的圖譜型方法HippoRAG 2（55.41%），尤其在2Wiki數據集上的優勢極為突出——HippoRAG 2得了71.35%，Ψ-RAG高達76.73%。在檢索召回率指標Recall@5上，Ψ-RAG平均達到78.98%，同樣優於所有基線方法。
進一步分析這些數字背後的規律，可以發現幾個有趣的現象。對於單步問答，傳統的混合檢索（BM25加DPR加重排序）表現其實也不錯，接近Ψ-RAG的水平，因為單步問題只需要匹配到一篇語義相關的文檔，不需要多步推理。但對於多步問答，Ψ-RAG的優勢就顯現出來了，尤其是在MuSiQue（最多需要4步推理）和MultiHop-RAG這兩個最難的數據集上，Ψ-RAG比簡單混合檢索高出了超過20個百分點。RAPTOR在單步問答上已經表現欠佳（大概率是抽象過粗的問題），在多步問答上就更是大幅落後。
第二類是敘事性問答，需要在一整本書或一篇超長文檔里理解因果關係，給出段落級別的回答。測試用了NarrativeQA（10本書，每本平均約6.3萬詞）和∞-LongBook（19篇文檔，每篇平均約21.5萬詞）兩個數據集。Ψ-RAG在NarrativeQA上的F1分數達到27.84%，比RAPTOR的21.36%高出近6.5個百分點；在更長的∞-LongBook上，概括性摘要版的Ψ-RAG得到25.52%，關鍵詞摘要版得到28.44%，均超過RAPTOR的13.90%。
第三類是文檔級摘要任務，需要對整個會議記錄或新聞事件做全面概括。測試用了QMSum（會議摘要）和WCEP（新聞摘要）。Ψ-RAG在WCEP上的ROUGE-L分數達到20.28%，高於專門為摘要任務設計的圖譜方法GoR（13.98%）和RAPTOR（18.33%）。
研究團隊還專門做了消融實驗，把Ψ-RAG的三個主要組件逐一去掉，看看對性能的影響。去掉R&A代理（直接單次檢索），多步問答的平均F1下降了約20個百分點；去掉稀疏關鍵詞索引，PopQA的F1下降了約22個百分點，2Wiki下降了約41個百分點；去掉重排序器，整體性能有所下降但影響相對較小。去掉查詢重組功能，MuSiQue的F1下降了2個百分點。這些數字清晰地說明了每個組件的貢獻：代理負責多步推理，關鍵詞索引負責精確命名實體匹配，而兩者缺一不可。
**六、跑得也快：效率對比**
除了效果，研究團隊還仔細對比了各種方法的運行效率。
建立索引的速度是Ψ-RAG的一大優勢。在HotpotQA數據集（約130萬詞）上，Ψ-RAG的樹結構建立只需124秒，RAPTOR需要1123秒（約19分鐘），而基於知識圖譜的HippoRAG 2則需要超過13.7萬秒（約38小時！）。當然，Ψ-RAG需要為每個抽象節點生成摘要，這部分用大語言模型調用比較耗時，加上摘要時間後Ψ-RAG總計約1.7萬秒，比RAPTOR的1.1萬秒略慢，但仍遠快於HippoRAG 2的14.9萬秒。檢索時，Ψ-RAG的樹狀自頂向下搜索本質上是對數時間複雜度，單次檢索的樹狀部分僅需約0.19秒，加上關鍵詞檢索和重排序後約1.26秒，也優於HippoRAG 2的約8-10秒。
至於靈活性，研究團隊驗證了Ψ-RAG可以自由替換各個組件中的底層模型。用更小的嵌入模型（參數量從8B降到0.6B）、更小的摘要模型（從70B降到1B或8B）、不同廠商的推理模型（Gemma-3-27B替代Llama-3.3-70B），以及不同的重排序器，都能保持接近完整版本的性能水平。研究團隊還測試了使用GPT-5-mini和Gemini-2.5-Flash作為R&A代理，兩者都能進一步提升性能，其中Gemini-2.5-Flash在MuSiQue上的F1達到了51.86%。
**七、面向真實世界的擴展：當文檔庫變得更大**
研究團隊也考慮到了實際應用中可能遇到的超大規模場景。當文檔庫包含數千萬甚至數億詞時，計算所有段落兩兩之間相似度的代價會變得非常高（時間和內存都是段落數量的平方級別）。
為此，他們提出了兩種擴展方案。第一種叫做"分桶"（Bucketing）：先用一個快速的球形K-means把文檔粗分成若干桶，在每個桶內部分別建樹，最後再在最高層把各個桶的樹根合併在一起。假設分成b個桶，平均索引時間就從O(n?)降到O(n?/b)，內存占用也同步下降。第二種是使用"層次導航小世界圖"（HNSW）這種近似最近鄰搜索結構：不計算所有段落兩兩的相似度，而是為每個段落找到它在HNSW圖中的近鄰，只對這些近鄰對排序建樹。這把相似度排序的時間複雜度從O(n? log n)降到了O(kn log kn)，內存從O(n?)降到O(kn)，k是近鄰數量。
在實際測試中，對於包含5080萬詞（約35萬個段落）的大型數據集，普通方式下相似度排序需要約168秒並占用88MB內存；僅用HNSW後降到約8秒和2.15MB；結合分桶後進一步降到約8秒和34MB（因分桶本身有開銷）。不過，大規模場景下LLM調用生成摘要的時間會非常可觀（估計約140萬秒），如何更高效地生成摘要，是後續工作的重要方向。
此外，研究團隊還實現了一個輕量級的"問題跳數判別器"（Query Hop Discriminator）——一個兩層的小神經網路，根據用戶問題自動預測需要幾步推理，從而自動設定代理的最大檢索次數，無需用戶手動指定。在HotpotQA和MuSiQue上的測試表明，使用這個判別器後性能幾乎沒有下降（HotpotQA從74.85%到74.27%，MuSiQue從47.83%到46.63%），實用性大幅提升。
**八、也有沒解決好的問題**
研究團隊在論文中誠實地分析了Ψ-RAG的失敗案例。他們統計了兩個指標：給出錯誤答案的比例（False Rate）和完全沒找到相關資訊的比例（Not Mentioned Rate）。有趣的是，在大多數數據集上，給錯答案的比例都高於找不到答案的比例。
手動分析了50個MuSiQue上的失敗案例後，他們發現主要原因包括：檢索不完整導致LLM亂猜（29個案例）、代理推理過程中出現邏輯錯誤（8個案例）、模型產生幻覺憑空編造資訊（6個案例），以及模型給出的答案格式與標準答案不一致（7個案例，比如一個說"麗莎·明內利"，另一個說"明內利"）。由此可見，最大的短板依然是檢索的覆蓋面——如果關鍵段落沒被找到，後續推理就會"無米之炊"。
另一個值得關注的失敗模式是：如果第一次改寫後的子查詢沒能檢索到有用資訊，後續幾次再檢索也往往沒用，因為改寫後的查詢詞在語義層面還是會引導檢索器回到相同的抽象節點，而關鍵詞檢索又容易被高頻詞幹擾（比如"大衛"這個名字出現在很多無關文檔里）。
還有索引規模的影響：對於∞-LongBook這個文檔非常長（平均約21.5萬詞）的數據集，未找到答案的比例明顯高於NarrativeQA（每篇約6.3萬詞），說明文檔越長、檢索難度越大。這也給未來優化指明了方向：在超長文檔場景下，如何讓樹的上層摘要既精煉又不失具體資訊，仍然是一個開放問題。
歸根結底，Ψ-RAG做的事情，就是給AI的"知識庫"建了一個更聰明的"圖書館"，並配備了一個不輕易放棄、會主動追問的"圖書管理員"。這套組合在處理需要跨越多篇文章、多步推理的複雜問題時，表現出了相當明顯的優勢，同時又保持了比知識圖譜方法快得多的建索引速度。
對於普通用戶而言，這項研究的實際意義在於：未來的AI助手在面對"這個作家的哪本書影響了哪位導演，那部電影的配樂是誰寫的，那位作曲家還為哪個品牌寫過廣告曲"這類需要串聯多個事實的問題時，有望給出更準確的答案，而不是東拉西扯或直接說"我不知道"。當然，大規模部署時的計算成本、對極長文檔的適應性，以及模型幻覺的控制，仍然是需要繼續打磨的方向。如果對這套方法感興趣，可以通過arXiv:2605.00529查閱完整論文，代碼也已在GitHub上的Newiz430/Psi-RAG倉庫公開，便於研究者復現和擴展。
---
Q&A
Q1：Ψ-RAG（賽-RAG）和RAPTOR的核心區別是什麼？
A：RAPTOR用K-means類聚類建樹，會強制讓各類別數量差不多大（"均勻效應"），在大規模文檔庫中容易把不同話題的內容混在一起，導致檢索結果不純。Ψ-RAG用"從下往上合併"的方式建樹，數學上可以證明它不會強制均勻分布，少數話題的內容不會被大量話題"污染"，建樹速度也比RAPTOR快約6.5倍。
Q2：Ψ-RAG是怎麼處理需要多步推理的問題的？
A：Ψ-RAG配備了一個"檢索與回答代理"（R&A Agent）。這個代理每次檢索後會判斷當前資訊是否足夠，不夠就生成一個更具體的子問題發起新一輪檢索，同時還會把已知資訊補充進查詢詞（比如"電影製片人大衛·格斯特的妻子"而非僅"大衛·格斯特的妻子"），這種主動追問的循環最多會重複到預設次數為止，大幅提升了多步推理的成功率。
Q3：Ψ-RAG的代碼可以在哪裡找到，對普通用戶來說部署難不難？
A：代碼已在GitHub上的Newiz430/Psi-RAG倉庫公開。Ψ-RAG完全基於開源大語言模型，不需要額外訓練或微調，理論上可以用在任何自定義文檔庫上。不過，為每個摘要節點調用大語言模型生成摘要的步驟比較耗時，對於非常大的文檔庫（數千萬詞以上）需要配合論文中提到的"分桶"或HNSW擴展方案，部署門檻對於有一定技術背景的用戶來說是可接受的。
