有一道测试题,出自一个叫FRAMES的数据集:美国总统的夫人在戴维营协议签署时多大年纪？
你可能觉得这题简单,查一下不就知道了。但你仔细想想会发现,这题根本没法一步查完。你得先弄清楚戴维营协议是哪年签的,再搞清楚那年谁是总统,然后才能知道他老婆是谁,接着查她的生日,最后把两个日期拿来算岁数,还得注意生日是不是已经过了。五个步骤,每一步都依赖前一步的结果。
这类问题现在有个专门的名字,叫深度研究问题。
**深度研究问题*：指那些无法通过单次检索解决，需要先拆解成多个子问题、逐一查证、再把结果拼接起来才能回答的复杂问题。
AI要回答这种问题,靠的是一种叫ReAct的经典做法:让模型自己决定下一步查什么,调用搜索工具,再根据结果继续推理,所有的进展都塞在一段越滚越长的对话历史里。这个办法用了好几年,一直管用,直到问题变得足够长。
长到什么程度会出问题？研究显示,当输入文本变长之后,语言模型会出现一种叫"迷失在中间"的现象:放在上下文开头和结尾的信息它记得清楚,塞在中间的那部分反而容易被忽略。还有研究发现,随着输入长度增加,模型表现会持续下滑,这个现象被称为"上下文腐化"。
这就带来一个很现实的麻烦。调查做到第十步、第二十步的时候,前面查到的那个关键事实,比如"总统是卡特",还好好地待在对话记录的中间某处吗？模型还能准确地把它翻出来用吗？没人能保证。
这篇论文的作者们看到了这个麻烦,也看到了另一个麻烦:错误会顺着调查链条往下传。如果AI一开始把总统认错了,比如误认成里根,那它接下来查到的"里根夫人南希的生日"全是准确信息,算出来的岁数也完全正确,但答案照样是错的,因为起点就错了。
于是他们做了一件事:把"记笔记"这件事和"查资料、算答案"这件事彻底分开,交给不同的角色去做,还专门设了一个人负责挑错。这篇论文把这套系统叫做PANINI-DR。
**调查的骨架:先搭计划，再去跑腿**
PANINI-DR 的核心设计,是引入一个共享的"工作台",把整个调查过程中产生的子问题、子问题之间的依赖关系、查到的结论和支撑证据,全部记录在这个工作台上,而不是靠一段越滚越长的对话历史去硬撑。
这个工作台的底层表示方法,叫 GSW。
**GSW（生成式语义工作空间）*：一种用实体、角色、关系来描述一个场景的结构化表示方法，比起零散的事实列表，它能记录"谁和谁是什么关系""这个空白值需要满足什么条件"这类更丰富的上下文信息。
具体怎么运作？拿到一道题,系统先派出一个叫Planner(规划者)的角色,把问题拆解成一张图。节点是待解决的子问题,边表示依赖关系,比如"查到总统身份"这个节点连向"查他夫人是谁"这个节点。每个未知答案的位置叫一个"空白",空白上挂着检索提示(比如"[夫人]是什么时候出生的")和一条验证标准(比如"这个日期必须是[夫人]的生日")。
计划搭好之后,系统还会做一轮结构检查,看看有没有循环依赖、空白引用是否合法。这步做完,才真正开始派人去查资料。
这里要讲一下角色分工。整个系统里有一个叫Orchestrator(协调者)的主控角色,它看着这张依赖图,决定哪些子问题现在可以开始查(因为依赖的前置信息已经到位了),然后派出一个个叫Researcher(研究员)的子代理去分别负责。
**Researcher的查证流程:先快速试一下，不行再慢慢摸**
每个Researcher拿到一个具体的子问题后,不会立刻展开漫长的搜索循环。它先做一次"快速尝试":把已知信息填进检索提示里,搜一次,看能不能直接找到答案。比如"总统是谁"这个空白已经填上"卡特",检索提示就变成"卡特的夫人是什么时候出生的",直接搜一次。
如果这一步就能找到靠谱答案,而且通过了验证,就直接记录下来,不用再折腾。前面提到的签署日期,在Brazuca案例的调查里就是这样一次性查到的。
如果快速尝试不行呢？Researcher就会切换成更费劲的ReAct模式:反复搜索、阅读、推理,直到找到答案或者用完允许的尝试次数。为了不让搜来的大段原文把上下文塞满,系统专门设了一个Reader(阅读器)角色,负责从搜到的网页里只提取关键信息和引用句子,而不是把整篇文章都塞给Researcher。
这个设计让我想起一个很具体的场景。假设你要查一个冷门历史人物的生平,你肯定不会把维基百科那一整页从头读到尾再去记重点,你会先扫一眼有没有现成的"出生年月"字段,有就直接用,没有才会去翻正文段落细读。PANINI-DR 的"快速尝试加ReAct"这套组合,本质上就是把这种人类的查资料习惯搬进了系统里。如果没有这个分层设计,每道题的每个子问题都要走完整的多轮搜索流程,那整套系统的计算开销会直线飙升,实验里提到完整流程比精简版多花了近3倍的提示词token却只多拿到2.7个百分点的提升,代价和收益明显不成比例。
**验证机制:别让一个错误的答案悄悄溜进后续调查**
查到的答案不会直接采信,还要过一道关:Verifier(验证者)的审核。
Verifier干的事情很具体:拿着候选答案、它引用的证据段落、还有这个子问题本身的验证标准,去判断两件事。第一,这段证据真的支持这个答案吗？第二,这个答案能不能把真正正确的选项和其他看起来相似但错误的选项区分开？两条都要满足,才算通过。
拿前面那个假设场景举例:如果Researcher提交了"里根"作为签署当天的总统,Verifier会去对照里根的在任时间,发现他的任期跟1978年9月17日根本对不上,直接驳回这个答案。
驳回不是终点,是反馈的开始。Verifier会说明具体哪里不对,比如"证据不充分"或者"存在歧义"。拿到这个反馈,Researcher可以回去再搜,带着更明确的方向去补证据,系统给了最多五次重试机会。
这个设计解决的根本矛盾是什么？如果没有这道验证关卡,一个错误的中间结论会原封不动地流入后续调查,后面所有基于它展开的工作全都是在错误的地基上盖楼,盖得再精细也没用。消防演练里经常讲的一个原则是"宁可现在停下来确认,也不要事后排查整栋楼",验证机制干的就是这件事:在错误往下传之前把它拦住。
论文里有个很具体的例子。调查一部电影的剪辑师是谁,Researcher一开始提交了"Georgopoulos"这个姓氏,Verifier驳回,理由是这个姓氏不唯一,片方名单里还有一个人也姓这个。Researcher回去重新查,找到了完整的名字"Giorgos Georgopoulos",还找齐了两部电影里都挂着这个全名的剪辑credit,再次提交后才通过验证。消去歧义靠的不是运气,是反馈驱动的二次核实。
**计算结果和拼证据:当答案不是查出来而是算出来的**
戴维营协议这道题的最后一步,不是搜索,是计算。生日和签署日期都查到之后,系统用代码执行年龄计算,这一步不再额外经过一次语言模型的判断,因为计算本身是确定性的,不需要模型再"猜"一遍。
但光把答案算出来还不够,还要能把答案倒追回去,确认它真的是从可靠证据推出来的,而不是模型凭感觉编出来的巧合数字。
这就是论文里一个很有意思的补充指标,叫Obs-D。
**Obs-D（计算答案的可追溯核查）*：针对那些靠计算得出而非直接从文本摘录出来的答案，检查它所依赖的每个输入值是否都能在保存的证据里找到支撑，再重放一遍完整的计算流程，看是否能复现出同样的答案。
这个指标的意义在哪？论文里举了一个很直白的反例:戴维营这道题的最终答案"51岁"这个数字,根本不会直接出现在任何一篇被打开的网页原文里,因为"51"是计算出来的,不是摘抄出来的。如果只用最朴素的"答案文字能不能在证据里找到"这种检测方式,这题会被判定为"查无实据",尽管它事实上做得很扎实。Obs-D这类审计方式补上了这个盲区,结果显示在FRAMES数据集上补算之后答案质量从66.1%提升到72.3%,MoNaCo数据集上从0.458提升到0.498。
**整个系统放到擂台上会怎样**
说了这么多设计思路,接下来看实际表现。研究团队把PANINI-DR拿去跟七个同类系统对比,全部用同一个语言模型底座、同样的检索服务、同样的文档库,保证比的是"方法本身",不是"谁的底座更强"。
测试用了三个数据集。BrowseComp-Plus考验从细碎线索里锁定具体实体的能力,FRAMES考验跨多个来源拼接事实的能力,MoNaCo则包含需要列出一整批正确条目、还不能多列错列的集合型问题。
结果上,PANINI-DR在三个数据集的综合平均分里拿到最高分。最抓人眼球的是难题表现:在BrowseComp-Plus的困难题组里,PANINI-DR的准确率是52%,排名第二的系统只有28%,差距接近两倍。要知道,困难题恰恰是那种需要连续查多步、容易在中间环节出错的题目,这正好对应了论文开头提出的那个核心矛盾:调查链条越长，犯错和丢信息的风险越大。
| 方法 | BCP困难题 | BCP总体 | FRAMES准确率 | MoNaCo F1 |
|---|---|---|---|---|
| SLEUTH | 28 | 57.3 | 77.2 | 0.556 |
| IterResearch | 20 | 54.7 | 70.5 | 0.564 |
| Open Deep Search | 28 | 53.3 | 76.0 | 0.571 |
| **PANINI-DR** | **52** | **73.3** | **79.1** | 0.549 |
**不只是答对,还要答得有证可查**
研究团队没有满足于"答案对不对"这一个维度,他们又提出了一个叫"观测支持度"的指标。
**观测支持度（Obs.）*：只有当一个正确答案的内容，能从系统自己保存下来的证据记录里找回来，才算这个答案真正"有据可查"。否则即便答案碰巧对了，也不算数。
为什么要加这道关？因为语言模型本身见过海量文本,有时候即便检索到的证据根本不够,它凭着自己记忆里的知识也能蒙对答案。这种"蒙对"和"真的查证出来"看起来结果一样,但可靠性天差地别。打个比方,这就像考试时一道题你连蒙带猜写对了答案,和你真的推导出了解题过程,成绩单上看不出区别,但下次遇到类似的题,靠猜的那个人大概率要翻车。
这道关卡一加上去,排名发生了变化。PANINI-DR在这个指标上领先优势进一步放大,在BrowseComp-Plus上从原来16个百分点的领先扩大到接近17个百分点,在FRAMES上更是把第二名甩开超过10个百分点。研究团队还做了一个很扎实的交叉验证,找了独立的审核模型去检查每条证据是否真的支持所声称的内容,结果PANINI-DR依然领先,说明这个优势不是统计偶然,而是真实存在的证据质量差异。
**拆开来看:到底是哪个零件在起作用**
一个系统表现好,到底是哪个设计在真正起作用？研究团队做了拆解实验,把PANINI-DR拆成不同版本做对比。
第一组对比是"结构化计划加持久状态"这套机制本身的价值。他们保留了Researcher和Verifier,但去掉GSW那套结构化的工作台,换成普通的文字笔记形式。结果显示,加上结构化计划之后,BrowseComp-Plus准确率从41.3%跳到58.0%,涨了16.7个百分点,而且这个优势在换用相同的答案生成方式后依然存在。
更有意思的是另一组数据:研究团队去追踪那些"在问题本身里没出现、但后来被用作新一轮搜索关键词"的实体名称。用了结构化状态的版本里,77.4%的这类新发现实体会被后续搜索继续利用,而没有结构化状态的版本里,这个比例只有32.1%。换句话说,如果没有一个明确记录"我刚才查到了谁"的工作台,很多关键的中间发现会在系统继续往下走的时候被遗忘,根本没机会被用来指引下一步搜索。这正好印证了开头提到的"迷失在中间"问题,结构化记录就是对抗这个问题的方式。
第二组对比是验证机制本身的价值。研究团队保留整套工作台和搜索工具,只是把Verifier和证据核查环节整个关掉。结果显示,去掉验证之后,BrowseComp-Plus准确率和观测支持度都下降了16个百分点。而且这个下降在FRAMES和MoNaCo上的匹配子集里同样出现,不是单一数据集的偶然现象。
**算力账单:这套系统到底多烧钱**
好的效果往往伴随着代价,PANINI-DR也不例外。实验数据显示,这套系统发送的提示词token数量是基线系统SLEUTH的19.2倍。听起来很吓人,但研究团队指出了一个关键细节:由于服务端会缓存重复出现的上下文前缀,实际发送的token里有66.5%是直接命中缓存的,不需要重新计算。扣掉这部分重复劳动,真实的计算开销大约是SLEUTH的7.3倍。
这个倍数到底值不值？研究团队设计了一个很公道的对照实验:让SLEUTH针对同一个问题跑8次独立调查,取出现次数最多的那个答案作为最终结果。这样一来,SLEUTH消耗的计算量跟PANINI-DR基本持平,甚至略高一点,但准确率只有64.7%,还是比PANINI-DR的73.3%低了将近9个百分点。换句话说,给基础系统更多次重复尝试的机会,也追不上这套带着结构化记忆和验证机制的系统。这个结果让"多算几次就能弥补设计上的差距"这个想法基本破产了,说明真正起作用的不是算力堆砌,而是记忆和验证这两个机制本身。
研究团队还试过另一条路:不是跑多次独立调查,而是给单次调查更多的操作轮次,让它有更多机会去完善已经查到的发现。把每个Researcher的轮次上限从20轮提到50轮再提到80轮,BrowseComp-Plus的准确率从73.3%慢慢爬到74.7%再到76.0%,但代价是提示词消耗涨到了默认设置的2.8倍。考虑到性价比,研究团队最终选择保留20轮作为默认设置,没有一味追求更高的分数。
**写在后面**
这篇论文里最打动我的一个细节,是那个"8次重复采样也追不上一次结构化调查"的对照实验。它说明了一件直觉上容易被忽略的事:很多时候我们以为AI系统表现不好是因为算力或者尝试次数不够,但其实问题出在它根本没有一个靠谱的方式记住自己刚才查到了什么。多算几遍解决不了"忘事"这个毛病,就像一个人反复重做同一道题也不会突然记起上一步算错在哪,除非他真的停下来把过程写清楚。
另一个值得单独说的地方,是论文里那个"用标注好的正确文档直接喂给模型回答问题"的对照实验。研究团队发现,如果把正确答案所需要的全部参考资料提前准备好直接给模型看,困难题的准确率能从PANINI-DR的52%直接飙到90%。这个巨大的落差说明,现在深度研究系统的瓶颈,很大程度上根本不是模型本身的推理能力,而是它能不能在茫茫文档海里把对的那几篇真正找出来并正确使用。这个发现悄悄推翻了一个常见的假设,很多人以为提升AI回答复杂问题的能力需要更聪明的大模型,但这篇论文的数据提示我们,真正卡住系统的往往是查找和组织信息这个更基础的环节。
这篇论文也诚实地留下了没解决的问题。验证机制依赖的仍然是另一个语言模型的判断,这个判断本身可能出错,规划阶段生成的子问题也不保证真的覆盖了解题所需的全部内容。更多轮次的验证并不总是带来更好的结果,这中间的平衡点在哪里,目前还没有确定的答案。
如果一套系统能记住自己查过什么、验证过什么、还剩下什么没搞清楚,这跟一个真正在做研究的人,区别到底还有多远？
Q&A
Q1：PANINI-DR是什么？
A：PANINI-DR是一种多智能体深度研究系统，它通过一个共享的工作台记录调查过程中的子问题、依赖关系和证据，让负责搜索的研究员角色和负责审核的验证者角色协同工作，避免调查过程中信息丢失和错误传播。
Q2：PANINI-DR和传统的ReAct方法有什么区别？
A：ReAct把所有调查进展都塞进一段不断增长的对话历史里，容易出现"迷失在中间"的问题。PANINI-DR则用结构化的工作台单独记录每个子问题和它的查证结果，角色分工也更明确，搜索、验证、协调分别由不同的智能体完成。
Q3：观测支持度这个指标解决了什么问题？
A：它解决的是"答案碰巧对了"和"答案真的有证据支撑"之间的区别。有些答案是模型凭自己记忆蒙对的，并没有真实可查的证据，观测支持度要求正确答案必须能从系统保存的证据记录里找回来，否则不算数。
