香港科技大学（广州）提出Ψ-RAG：让AI在海量文档中"顺藤摸瓜"，精准找到你要的答案

这项由香港科技大学（广州）研究团队完成的工作发表于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扩展方案，部署门槛对于有一定技术背景的用户来说是可接受的。