基于工作流归纳的多轮智能体科学文献搜索（PaperPilot）

  • 关联论文：2607.00597
  • 作者：flyP
  • 更新：2026-07-23

一句话结论

PaperPilot 把科学文献搜索建模成「工作流归纳」——给定一篇锚定论文与用户查询，Agent 自动构造一个由 keyword search、citation expansion、filtering、scoring、reranking、evidence extraction 等算子组成的有向无环图（DAG），通过监督式工作流模仿 + 对受控扰动的偏好优化训练，最终在多轮交互中相对基座 Qwen3.5-9B 工具 Agent 把 Hit@5 从 58.0 提到 77.0、MRR 从 47.5 提到 59.4、nDCG@10 从 26.8 提到 32.5，并把工作流执行错误率从 9.5% 降到 0%。

解决的真问题

科学文献搜索远不是"提一个问题 → 跑一次检索 → 看答案"那么直白。三件事让现有搜索 Agent 在科研场景下疲态尽显：

  1. 意图欠明确：用户提的查询往往是"找出 X 方向上类似 Y 的近 3 年工作"这种偏好依赖、需要多次澄清的请求，单轮检索天然不够；
  2. 检索策略不透明：现有 Agent 大多依赖固定 pipeline 或纯语言推理决定下一步搜索什么，研究者既无法审计它的策略、也无法在自己的领域里"改"它；
  3. 多轮交互缺位：用户的偏好会在多轮中漂移（"其实我更关心……"），但很多 Agent 没有把"对工作流本身的反馈"和"对查询内容的反馈"区分开。

PaperPilot 的切入点就是把"搜索策略"显式化、可编辑化、可被 Agent 与用户共同精化。

核心方法

1) 搜索作为可执行 DAG

给定一篇锚定论文 a 与用户查询 q，PaperPilot 不是直接调一次检索 API，而是先生成一个 DAG 形式的搜索工作流：

nodes:
  - keyword_search(seed=a.title + q, source=arxiv+s2+openalex)
  - citation_expansion(seed=anchor, depth=2, direction=both)
  - filter(year>=2023, venue∈{top-IR}, language∈{en})
  - scoring(embedding=anchor, weight=[novelty:.3, recency:.2, relevance:.5])
  - rerank(model=cross-encoder, top_n=50)
  - extract_evidence(field="abstract+method", schema=...)
edges:
  keyword_search → scoring
  citation_expansion → filter → scoring
  scoring → rerank → extract_evidence

每条边声明数据依赖（"需要先有关键词结果才能打分"），每个节点声明算子类型与参数。这套 DAG 既可以由用户编辑（拖拽节点、改参数），也可以在多轮交互中被 Agent 重写。

2) 多轮反馈的双轨设计

用户反馈被显式分成两条：

  • 查询反馈（"换关键词"、"换时间窗"）——修改节点参数；
  • 工作流反馈（"其实应该先按引用网络扩张，再打分"）——修改 DAG 结构本身。

这种区分很关键：它让"用户教 Agent 怎么搜"和"用户给 Agent 更具体的输入"不再混在一个 prompt 里。

3) 训练：监督模仿 + 偏好优化

训练分两阶段：

  • 监督式工作流模仿：用人工标注或更强模型回放出来的"好工作流"作为正例，训练 PaperPilot 在新 (a, q) 上生成结构与节点参数都接近示范的工作流；
  • 受控扰动的偏好优化：人为对示范工作流做可控扰动——删一个节点、加一个冗余节点、把算子参数改坏——让模型在"好 vs 坏"工作流对上做偏好学习。这种扰动相当于合成的负样本，比纯靠自然失败要干净得多。

最终模型 PaperPilot-9B 基于 Qwen3.5-9B 继续训练。

4) 推理：执行 + 错误率收敛到 0

论文特别强调"工作流执行错误率从 9.5% 降到 0%"，指的是 DAG 节点在真实工具调用中失败（参数缺失、依赖未满足、API 异常）的比率。基座 Qwen3.5-9B 工具 Agent 在多轮里很容易写出"语法对、语义错"的工具调用（比如忘了传某个必要参数），而 PaperPilot 训练目标里就包含工作流结构完整性，所以这条指标直接被打到接近 0。

关键实验与数据

实验在多轮文献搜索场景下，对比 PaperPilot-9B 与 Qwen3.5-9B 工具 Agent：

指标 Qwen3.5-9B（基座） PaperPilot-9B 增量
Hit@5 58.0 77.0 +19.0
MRR 47.5 59.4 +11.9
nDCG@10 26.8 32.5 +5.7
工作流执行错误率 9.5% ~0% -9.5pp

论文 17 页、12 张图，篇幅足够展开 ablation 与案例研究。

亮点与局限

亮点

  • DAG 而非线性 pipeline：让搜索策略可编辑、可审计、可复用，研究者真能"打开看"它在搜什么；
  • 查询反馈 vs 工作流反馈的双轨：精准切中科研搜索「偏好随轮次漂移」的痛点；
  • 扰动式偏好优化：用受控坏例替代自然失败样本，训练信号干净；
  • 执行错误率压到 0：工程上可观测的可靠性提升，比纯学术指标更说服生产团队；
  • 基座 +9B 量级：不是只有百亿参数大模型才能做，落地门槛低。

局限

  • 算子集合封闭：当前 DAG 节点类型是预定义的（keyword、citation expansion、filter、scoring、rerank、extract_evidence），新场景需要重新设计算子；
  • 依赖闭源检索源：citation expansion 等节点假设可访问 Semantic Scholar / OpenAlex / arxiv 的稳定 API，私有知识库需要替换；
  • 多轮评价的真实性：实验是合成的多轮交互，对真实科研用户"飘忽不定"的偏好是否同样鲁棒，论文未给出长程田野数据；
  • 可编辑 = 用户负担：让用户改 DAG 是把一部分责任转嫁给用户，对非工程背景的研究者不一定友好；
  • 未公开训练数据规模与算力成本：原文未明确标注（待补充）。

对工程落地的启发

  • 搜索 Agent 的"白盒化"：与其写一团 ReAct 提示词让模型自己推理下一步，不如像 PaperPilot 一样把策略显式化为可审计的 DAG；
  • 双轨反馈 UI：在面向研究者的产品里，把"修改查询"和"修改搜索流程"做成两个独立入口，能极大降低多轮交互的认知负担；
  • 工具调用错误率做 SLO：把"工作流执行错误率"作为 Agent 系统的可观测指标，比只看任务完成率更早发现回归；
  • 扰动式偏好数据合成：比自然失败更可控的训练信号来源，迁移到其它工具调用场景（如 SQL Agent、浏览器 Agent）有通用价值；
  • 小模型也能赢：9B 量级 + 显式结构，能在垂直任务上打败自家基座 +19 Hit@5，结构红利比参数红利便宜得多。

与同方向工作的关系

  • 传统文献搜索工具（Semantic Scholar、Google Scholar）：PaperPilot 是 Agent 化的、可多轮交互的下一代；
  • OpenScholar / LitSearch：平行的 LLM 文献检索工作，PaperPilot 的差异在 DAG 显式化与双轨反馈；
  • ReAct / Toolformer / WebGPT：通用工具调用范式，PaperPilot 把它们特化为「搜索工作流」一种垂直形式，并加上了结构约束；
  • WorkflowLLM / Auto-GPT 系列：自动 Agent 范式，PaperPilot 把"自动"控制在结构化工作流边界内，避免漂移；
  • DSPy / OpenPipe：把 LLM 流程结构化的代表，PaperPilot 与之精神一致，但更聚焦于"用户可编辑的搜索工作流"。

适合谁读

  • 做学术搜索 / 文献综述工具的团队，会对 DAG 设计直接借鉴；
  • 想把 LLM Agent 部署到生产工具调用场景的工程师，关心可靠性与可观测性；
  • 多轮对话 / 偏好学习方向的研究者，对扰动式偏好优化的训练技巧感兴趣；
  • 任何想把"模糊意图 → 复杂动作序列"产品化的产品经理，DAG 思维可迁移。

工程落地与核查（Jay）

事实核查笔记

  • Qwen3.5-9B 与 Qwen3：文中"基座 Qwen3.5-9B"与"PaperPilot-9B"均指同一 9B 量级模型；需注意阿里通义千问的正式模型名为 Qwen2.5-9B-Instruct 或 Qwen2.5-9B-Chat，Qwen3 系列同期是否有 9B 截至于 2026-07 需核实。若实际为 Qwen2.5-9B，在引用时应更正为准确名称。存疑：建议对照原论文 Sec.3 确认基座模型确切名称与版本。
  • 工作流执行错误率 = 9.5% → ~0%："~0%"是工程实现零错误（节点执行不崩溃）还是任务级零错误（最终结果正确）？原文区分了"DAG 节点执行失败"与"任务结果正确"，两者不可混淆。当前解读（节点执行层）已标注，但需注意任务级正确率不一定达到 0%。
  • "17 页、12 张图"：这是原文篇幅声明，未经独立核实，且论文评审版本与最终版本可能存在差异，引用时应加"据原文"限定。
  • 闭源检索源依赖：Semantic Scholar API 有日调用量限制，OpenAlex 相对宽松但数据完整度有差异；实际生产部署前需评估 API 稳定性与成本。

实际系统怎么用

三层核心工程模块：

  1. DAG 执行引擎（DAG Executor）：解析节点类型 → 调用对应工具 API → 处理异常 → 返回结构化结果。对每个节点类型封装独立 handler（keyword_search_handler、citation_expansion_handler 等），节点失败时记录类型并可单独重试。

  2. 偏好分类器（Preference Classifier）：接收用户反馈文本，判别是"查询反馈"还是"工作流反馈"。可用规则（关键词匹配）+ LLM 小模型双重路由，降低延迟。

  3. 工作流合成器（Workflow Synthesizer）：接收 (anchor_paper, query, feedback) 三元组，生成新的 DAG 节点/边。新 DAG 需通过有效性校验（无环、依赖完整）后再执行。

算子实现的注意事项： - citation_expansion：arXiv API 免费但限速，Semantic Scholar API 需要申请；建议加本地缓存（Redis，TTL=24h）应对重复查询。 - rerank(cross-encoder)：需加载专门的 rerank 模型（如 cross-encoder/ms-marco），延迟约 200-500ms/篇；建议限制 top_n=50 防止 rerank 成本爆炸。 - extract_evidence：使用 LLM 按 schema 抽取，schema 应与下游使用场景对齐（摘要提取、方法复现步骤、实验设置对比等）。

双轨反馈 UI 的工程实现：

用户输入 → 偏好分类器
  ├─ 查询反馈 → 修改对应节点参数 → 重执行受影响节点
  └─ 工作流反馈 → 修改 DAG 结构 → 重新生成 DAG → 校验 → 执行

两个分支完全解耦，状态互不污染。

坑与缓解

坑 描述 缓解方案
API 限速与数据缺失 citation expansion 依赖外部学术 API，免费层限速严重；OpenAlex 缺全文 多源冗余（arXiv + Semantic Scholar + OpenAlex 三选一）；无数据时降级为纯关键词搜索
DAG 可达性验证 用户或 Agent 修改 DAG 后，可能出现"依赖节点不存在"或循环依赖 每次 DAG 修改后强制走 DAG 校验（拓扑排序 + 依赖完整性检查），不通过则拒绝执行并回退
rerank 延迟 cross-encoder 对 50 篇做 rerank 约 10-25s（200-500ms/篇），超出实时交互容忍范围 两阶段：轻量向量相似度初筛（top 100 → top 50）→ cross-encoder 精排；或异步 rerank，先返回初筛结果
偏好漂移难捕捉 "其实我更关心 X"这类隐式工作流反馈容易被误判为查询反馈 对连续 2 次同类查询反馈后的结构性建议做强制升级，推送给用户确认"是否要改搜索流程"
闭源检索源不可用 私有知识库没有 Semantic Scholar / OpenAlex 替换为内部检索引擎（Elasticsearch / Meilisearch），调整算子参数；citation_expansion 改为"内部引用图扩展"
训练数据标注成本 受控扰动的偏好优化需要大量 (好 DAG, 坏 DAG) 对 初期用规则合成负样本（如随机删节点、随机改参数），中后期积累真实用户修正行为数据
用户改 DAG 的心理门槛 普通用户不会写 DAG，编辑节点/边 = 强行干预 提供"建议优化"按钮：Agent 自动给出 DAG 改写建议，用户一键确认而非手动编辑

工程自检清单（部署前）

  • [ ] DAG 校验（拓扑 + 依赖完整性）是否在每次执行前强制运行
  • [ ] 是否有工具调用 SLO 监控（节点执行错误率，目标 ≤1%，告警阈值 5%）
  • [ ] citation expansion 的多源降级策略是否已实现（arXiv → OpenAlex → 纯关键词）
  • [ ] rerank 是否已做两阶段（向量初筛 + cross-encoder 精排）以控制延迟
  • [ ] 偏好分类器在真实反馈数据上是否经过评测（建议抽取 100 条人工标注）
  • [ ] 基座模型名称是否已对照原论文 Sec.3 确认（避免 Qwen3/Qwen2.5 混淆）