先说一个让人挠头的场景。

你问AI："III专辑的演唱者出生地发生的那场战役是什么时候打响的？"

这句话看着绕,但拆开看很简单。III是一张专辑,得先找到谁唱的,再找这个人出生在哪儿,最后查这个地方发生过什么战役,战役哪天开打。三步走,环环相扣。

(相关资料图)

但AI一头栽进语料库里搜索"III""战役"这些词的时候,麻烦就来了。因为搜索引擎认字面意思,你问的是一整句复杂问题,但语料库里存的是一篇篇独立的文章,讲专辑的文章不会提战役,讲战役的文章不会提专辑。这就好比你拿着一张写满线索的藏宝图去问路人,路人只认识地图上的某一个地标,拼不出完整路线。

这类需要多步推理才能回答的问题,学术圈管它叫多跳问答

多跳问答*：需要综合多个信息来源、经过好几步推理才能得到答案的问答任务,和"直接查字典"式的单跳问答相对。

这个领域折腾了好些年,方法换了一茬又一茬,但一个根本性的麻烦始终没被真正解决。这篇来自POSTECH研究团队的论文,给这个麻烦起了一个精准的名字,叫检索粒度不匹配,并且提出了一套叫Hi-Q的解法。今天就把这套东西掰开揉碎讲清楚。

问题到底卡在哪儿

先说清楚这个"粒度不匹配"到底是什么意思。

一个问题可以用一句话说完,但支撑这个答案的证据往往零零散散地分布在语料库的好几篇文档里,而且每篇文档谈的话题都比较窄。换句话说,提问的"颗粒度"是粗的,证据存在的"颗粒度"是细的。这两者对不上号。

论文里举了三种失败的应对方式,每一种都有具体的代价。

第一种是最直接的做法:把整句问题扔进检索系统,搜出排名靠前的几篇文档,让AI直接读完回答。这个办法在问题和证据颗粒度差不多时管用,但遇到多跳问题就抓瞎。因为检索系统只会按字面相似度打分,一句包含"III""战役""出生地"的复杂问题,检索到的文档可能只是单纯提到"战役"两个字,却压根没提专辑或演唱者,证据链条根本对不上。

第二种是图检索增强生成,也就是提前把整个语料库构建成一张知识图谱,把实体和关系都连接起来。

图检索增强生成*(Graph RAG)：一类提前对语料库做结构化处理,构建成知识图谱或分层摘要,再在图上做检索的方法,代表工作包括GraphRAG、RAPTOR、HippoRAG、PropRAG等。

这个办法听着挺美,提前把关系理清楚了,检索的时候顺着图走就行。但问题是,这张图是在看到问题之前就建好的,它的颗粒度是固定的,不会因为你问的问题不同而调整。而且构建这张图本身要花不少钱,论文里提到,如果对HotpotQA的523万篇文档做基于大模型的图构建,光API调用费用就得超过2500美元,这已经超出了研究团队的预算。

第三种是迭代检索,像IRCoT、ReAct、Self-Ask这些方法,它们会一步步地根据已经检索到的内容重新生成下一步的查询。这个思路听着更接近人的思考方式,但漏洞在于,它从不检查自己刚刚发出去的这一步查询到底靠不靠谱。论文里的例子很扎心:系统先问"III的演唱者出生在哪儿",搜到的文档提到了一个叫"Philip III"的人,是西班牙和葡萄牙的国王,出生在马德里,系统就顺着这条错误线索往下走,去查"马德里发生的战役是什么时候",最后答出1936年,完全跑偏了。真正的答案应该是1814年12月14日,演唱者是Stanton Moore,出生在新奥尔良。

这就是典型的一步错、步步错。前面选错了桥接实体,后面的查询全部建立在错误的基础上,而且没有任何机制去检查这个中间结果到底对不对。

三种方法各有各的死角,共同点是它们都没有回答一个最基本的问题:当前这个查询,到底应不应该被拆开?

Hi-Q的核心思路：先测试,再决定要不要拆

Hi-Q这篇论文给出的答案是,别提前假设该怎么拆,让证据说了算。

具体来说,Hi-Q在每一个查询节点上都会先做一次尝试:拿当前这个问题去检索,看看能不能找到证据支撑的答案。如果找到了,这个节点就算解决了,直接停下来,不再往下拆。如果没找到,才会触发拆解,把这个问题劈成两半,先解决前置条件,再解决依赖前置条件的后续问题。

这个动作在论文里被称为解析算子

解析算子*(Resolution Operator)：Hi-Q里负责判断"当前这个查询能不能用检索到的证据回答"的模块,输出结果只有两种,已解决或未解决,如果已解决还会附带具体答案。

这里有一个特别值得琢磨的设计细节:判断"要不要拆"这件事,不是靠什么复杂的分类器打分,而是直接看阅读理解模型自己给不给得出答案。如果阅读模型说"我答不上来",这就是一个信号,说明当前的证据没能覆盖问题需要的所有信息,系统就把这个节点标记为需要拆解。

这个设计思路可以类比成一个负责任的中医大夫看病。病人一进门,大夫不会立刻开一堆检查单子,而是先问诊、把脉,看看凭现有的信息能不能判断病情。如果能判断,直接开方子走人,不折腾病人做没必要的检查。如果把不准,才会追加验血、拍片这些进一步的检查项目。如果反过来,大夫见谁都先开一整套检查单子,不管病情简不简单都走一遍流程,病人钱包受得了吗?医院资源耗得起吗?更麻烦的是,有些本来一句话能说清楚的小毛病,被拆解成十几个检查项目之后,反而容易在层层转诊里把病情的关键信息给冲淡、搞丢了。

论文里专门做了一个对照实验来验证这个直觉。他们设计了一个"无条件全部拆解"的版本,不管查询是否已经能被证据支撑,一律强制拆开。结果这个版本在100道抽样问题上的准确率从60.7降到57.3,足足掉了3.4个百分点。这说明不必要的拆解确实会伤害准确性,因为拆解过程中容易丢失原本问题里隐含的约束条件,或者引入一些多余的、干扰性的中间目标。

那这个"要不要拆"的判断到底有多准?研究团队专门做了人工核查,随机抽取100个被判定为"未解决"的案例,逐一分析触发原因。结果显示,真正属于误判的情况,也就是明明证据够用但系统却错误地判定为未解决的比例,只占7%,加上阅读模型自身推理失误导致的3%,总的误触发率大约是10%。换句话说,这个信号在九成情况下都是准的,证据确实不够,拆解确实有必要。

研究团队还做了一个更严苛的压力测试,专门检查这个信号会不会"该拒绝时不拒绝"或者"不该拒绝时乱拒绝"。他们用100道正常问题和50道刻意构造的无法回答的问题做测试,发现在正常问题上错误拒绝的比例是11%,而这11次拒绝里没有一次是毫无理由的空拒绝,全部标注为证据缺失或不完整;而在那些故意设计成无解的问题上,系统识别出49道确实无法回答,只有1道被误答,误接受率仅为2%。这说明这套判断机制在面对真假问题时都表现得相当克制,不会轻易自信满满地编造答案。

拆解不是随便拆,谁先谁后有讲究

判断完"要不要拆"之后,接下来的问题是怎么拆。

Hi-Q采用的是二元拆解,也就是每次只拆成两个子问题,而不是一口气拆成三个、四个甚至更多。这个选择乍一看有点保守,毕竟一个复杂问题理论上可以涉及好几个独立的信息点,为什么非要一次只拆两块?

论文给出的理由是,二元拆解能在每一步都留出足够的上下文,让系统可以针对拆出来的每一半重新判断"这一半现在够不够拆",而如果一次性拆成很多份,很容易出现过度碎片化的问题,一些必要的中间桥接事实反而会在拆分的过程中被跳过或丢失。

更关键的是拆解出来的两个子问题之间有严格的依赖顺序。左边的子问题被称为前置分支,专门解决那个"桥接事实",比如先确定"III的演唱者是谁";右边的子问题叫依赖分支,要等前置分支的答案确定之后才能启动,比如拿到"Stanton Moore"这个名字之后再去问"这个人出生在哪儿"。左边分支解决完之后,它的答案、检索到的证据、还有推理过程中积累的上下文信息,都会被写入一个叫历史记录的东西里,右边分支执行的时候会带着这份历史记录一起去检索。

历史记录*(History,论文中记为H)：贯穿整个推理过程的一份累积信息,记录了之前每一步解决过的子问题、检索到的证据以及得出的答案,后续的子问题在检索前会先参照这份记录把自己"翻译"清楚。

这个顺序执行的过程可以想象成盖房子打地基。你不能先把二楼的墙砌起来再回头浇一楼的地基,顺序反了,整栋楼都立不住。Hi-Q里"先解左边再解右边"就是同一个道理:如果不先确认演唱者是谁,直接去问"这个出生地发生了什么战役",这个问题里根本没有具体的地名,查询本身就是残缺不全、无法执行的。研究团队把这个依赖关系写进了执行流程本身,而不是仅仅停留在提议阶段,左边分支哪怕最终没能得出一个明确答案,它检索到的部分证据和上下文依然会被保留下来,用来支撑右边分支的推理,不会因为前置分支失败就彻底放弃整条线索。

拆完之后还有一道保险,叫语义覆盖校验

语义覆盖校验*(Semantic Coverage Verification)：在两个子问题正式进入求解流程之前,先检查"依次解决这两个子问题,合起来是否能完整还原原始问题的意图",如果发现遗漏、增添或者顺序颠倒,就对拆解方案进行修正,最多修正一次。

这道保险的意义在于防止局部的拆解失误滚雪球般演变成全局性的推理错误。论文里做了按推理深度分层的对比实验,结果显示这道校验的作用在推理链条越长的时候越明显:整体上去掉这道校验只让F1分数掉了0.7个百分点,但在四跳推理这种最深的场景下,差距扩大到1.0分,因为拆解阶段的一点点偏差,会在层层递推中被不断放大。

这三个部件加在一起,构成了一棵按照证据支持情况动态生长的查询树,而不是按照预先设定好的模板机械地展开。论文里配的示意图画得很直观:树的每一个节点先经过一次"能不能直接回答"的判定,能回答的节点就地终止,不能回答的节点才会分裂出两个带依赖关系的子节点,分裂之前还要经过校验这一关。

实验结果:证据说话,而且说得挺硬气

理论讲得再漂亮,最后还是要看跑分。

研究团队在三个多跳问答的经典测试集上做了评测,分别是MuSiQue、HotpotQA和2WikiMultiHopQA,而且特别强调了一个评测设置,叫全语料检索

全语料检索*(full-corpus retrieval)：不再局限于一个提前圈定好的、只包含标准答案支撑文档和少量干扰项的小范围语料池,而是让系统在整个基准数据集的完整语料库里大海捞针地找证据,MuSiQue的完整语料库有139416篇文档,2WikiMultiHopQA有430225篇,HotpotQA更是达到了5233235篇。

为什么要特别强调这个设置?因为这更贴近真实世界的部署场景。以往很多论文喜欢在一个只有几十篇文档的小池子里测试,那种环境下证据本来就集中,系统表现自然容易好看。而全语料检索意味着正确答案要淹没在成千上万篇干扰文档里去找,这才是真正的考验。

在这个更严苛的全语料设置下,Hi-Q平均达到了52.3的精确匹配得分和64.0的F1得分,比迭代检索代表方法IRCoT高出15.1个精确匹配点、18.2个F1点。具体拆开看,在MuSiQue上领先13.0个精确匹配点,在2WikiMultiHopQA上领先幅度最大,达到27.0个精确匹配点,在HotpotQA上领先5.4个精确匹配点。

和图检索方法PropRAG比较也很能说明问题。在MuSiQue全语料设置下,Hi-Q领先11.5个精确匹配点、12.0个F1点;在2WikiMultiHopQA上领先9.9个精确匹配点、12.1个F1点。而且Hi-Q根本不需要提前对整个语料库做图构建,这一点前面提到过,PropRAG光是在HotpotQA的523万篇文档上跑图构建就要烧掉2500多美元,而Hi-Q完全绕开了这一步。

在传统的受限语料设置下,也就是只在标准答案文档和少量干扰文档组成的小池子里测试,Hi-Q同样拿到了最好成绩,平均57.9的精确匹配和69.3的F1,领先PropRAG5.6个精确匹配点、领先IRCoT13.7个精确匹配点。论文里特别指出,这19组对比里有19组在统计学上高度显著,说明这不是运气好的偶然结果。

有一个细节值得单独说一说:检索到的文档数量多,不代表最后答得准。论文里对比了Self-Ask这个方法,它的Recall@5指标反而是所有方法里最高的,但因为它会发出更多次子查询,平均每道题多检索约33%的文档,相当于变相扩大了预算,把更多候选塞进了检索池子。可结果呢,Self-Ask的精确匹配得分只有35.7,远低于Hi-Q的57.9。这说明真正决定回答质量的不是捞回来多少证据,而是这些证据能不能被阅读模型真正用上、真正解读对。这就像一个人搬了满满一车书回家准备考试,但真正决定成绩的从来不是书搬得多不多,而是这些书里有没有恰好覆盖考点的那几页,以及自己有没有真的把那几页看懂了。

推理链条越长,差距拉得越开

论文还专门按照推理跳数分层做了对比,结果特别能说明问题。

随着跳数从两跳增加到四跳,所有方法的表现都在下滑,这没什么好意外的,推理链条越长,出错的机会自然越多。但下滑的速度差别很大。在三跳和四跳这两个更难的场景下,Hi-Q的F1分别是55.2和39.2,而IRCoT只有43.4和35.4,PropRAG更是掉到43.1和26.9。

四跳时的差距尤其扎眼:Hi-Q比PropRAG高出足足12.3个F1点。这个差距意味着什么?意味着在最考验多步推理能力的场景里,每处理约3道题,PropRAG就要比Hi-Q多答错1道左右。这背后的原因正是前面反复提到的依赖顺序执行机制,前置条件先落地、依赖分支后跟进的做法,有效遏制了错误在长链条推理中的累积和放大。

成本这笔账怎么算

准确率高固然好,但如果代价高到没法用,那也白搭。

论文对比了几种方法每道题消耗的API调用次数、输入输出的token数量以及耗时。一个很实在的发现是,Hi-Q提供了一个成本匹配版本,通过缩短中间推理文本、把递归深度限制为1层,让根节点最多只展开一次、子节点不再继续拆解,在这个设定下,Hi-Q使用的大模型调用次数和IRCoT基本持平,分别是2.93次和2.92次,但输入token数量只有IRCoT的约十分之一,运行速度快25%,按GPT-4o-mini当时的价格算,每道题的API开销只有IRCoT的约八分之一,而准确率反而平均高出10.4个精确匹配点、11.6个F1点。

这组数字放在一起看很有意思:同样的调用次数,花更少的钱,却拿到更好的结果。这背后的关键在于Hi-Q的开销是有条件触发的,不是每个节点都平等地消耗资源。一个查询要是当场就能被证据解决,它就地终止,根本不会触发后续的拆解、校验和递归求解这一整套流程。这就好比一个客服系统,大部分简单问题客服机器人自己就能答完,只有真正棘手、模糊的问题才会转接给需要更多沟通成本的人工客服,而不是不管问题简单复杂一律走一遍完整的转接流程。如果反过来,不管什么问题都强制走完整套复杂流程,那些本来一步就能解决的简单问题也要背负额外的时间和金钱成本,这就是"始终全力以赴"和"按需分配力气"之间的根本差别。

当然,如果开启完整版本,不限制递归深度,Hi-Q的耗时会明显上升,比IRCoT慢2倍多,大模型调用次数接近IRCoT的两倍。但这笔多花的钱换来的是进一步的准确率提升,完整版比成本匹配版再多拿3.3个精确匹配点、4.2个F1点。这说明Hi-Q本身提供了一个可以按需调节的成本准确率旋钮,而不是一锤子买卖。

代码执行范式的对照:换个赛道,问题还在

论文里还测试了两类比较新潮的思路:一类是把语料库当作可编程访问的环境,让大模型写代码去操作检索工具,另一类是通过递归子调用来处理超长上下文的方法。

结果这两类方法的表现都明显落后,Hi-Q平均比它们分别高出30.8和24.4个精确匹配点。这个结果其实挺发人深省的。这类方法把"怎么组织检索这件事"从提示词层面转移到了代码执行层面,听起来是一次范式升级,但论文的结论是,颗粒度不匹配这个根本问题并没有因为换了个执行方式就消失,它只是从"提示词该怎么写"转移成了"代码该调用哪个检索接口、传什么参数",麻烦换了个地方藏起来,但没有真正解决。

那么Hi-Q之后呢

这篇论文最打动人的地方,其实不是它在跑分榜上的领先幅度,而是它提出的一个思考方式:把查询的颗粒度,当成一个可以被证据实时调节的变量,而不是提前定死的设计选择。

这个思路其实可以跳出多跳问答这个具体任务,推广到很多需要"分解复杂任务"的场景里去想。写代码的时候要不要把一个函数拆成更小的函数,做项目管理的时候要不要把一个大需求拆成几个子任务,甚至日常生活里遇到一个复杂问题要不要先分解再逐个击破,背后其实都是同一个决策:什么时候该拆,拆多细合适,谁先谁后。Hi-Q给出的答案是别靠经验或者模板硬性规定,让实际反馈来决定。

论文里附录部分做的高阶分支实验也挺有意思,他们专门构造了信息需求从两个逐渐增加到五个的测试集,结果发现二元拆解在整个区间里准确率都很稳定,而"一次性拆成多份"的做法在准确率上并没有明显优势,反而在最后的答案整合阶段表现明显更差,准确率直接掉了27.5个百分点。这说明成本不是出在"拆得细不细",而是出在"最后怎么把碎片重新拼回一个完整答案"这道工序上,这个细节论文里讲得比较克制,但其实很值得单独琢磨。

还有一个细节值得留意,论文承认了自己的边界。整套方法假设的推理结构是无环的,也就是各个子问题之间的依赖关系可以排出一条前后顺序,但现实中有些问题的几个前提条件是相互纠缠、需要联合求解的,这种情况目前的状态表示还处理不了。这算是一个诚实的局限,也留下了一个值得后续研究去啃的硬骨头。

Q&A

Q1：Hi-Q是什么？

A：Hi-Q是POSTECH研究团队提出的一种多跳问答框架,核心思路是把查询的拆解粒度当作证据驱动的动态决策,在每个查询节点先测试证据是否足够回答,不够才拆解成有依赖顺序的子问题。

Q2：Hi-Q相比IRCoT这类迭代检索方法优势在哪？

A：Hi-Q在全语料检索设置下平均精确匹配得分比IRCoT高15.1分、F1高18.2分,而且成本匹配版本用相近的调用次数就能实现更高准确率,同时避免了错误中间查询一路传导下去的问题。

Q3：Hi-Q需要提前构建知识图谱吗？

A：不需要。Hi-Q在线动态生成依赖有序的查询树,不像GraphRAG、PropRAG那样需要对整个语料库提前做图构建,这也让它在HotpotQA这种五百多万文档规模的语料库上依然可行,构建成本大幅降低。