AI研究员为何会忘掉查过的信息？PANINI-DR重构多步调查流程

一道来自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：这个指标要分清两种情况——答案碰巧对了，和答案真有证据撑着。有些答案靠模型凭记忆蒙对，背后并没有真实可查的证据。观测支持度要求正确答案必须能从系统保存的证据记录里找回来，找不回来就不算数。