文献调研系统的构建与演进
引言
文献调研通常包括三项工作:检索文献、提取关键信息以及开展综述。随着大语言模型和AI智能助手的发展,文献调研已经成为科研工作者使用AI的主要场景之一。
过去几年,相关工具经历了从单篇文献解析、多来源知识管理到自动化深度研究的演进。与此同时,编码智能体(Coding Agent)逐渐进入科研工作流,也对文献调研系统提出了新的要求:系统不仅需要阅读和总结文献,还应该结合研究者自己所研究的科学问题、设计的实验方法和采集到的实验数据,为具体研究任务提供支持。
基于这一目标,我构建了一套文献调研系统,并先后经历了三个主要版本。本文将回顾这套系统的构建过程,列举开发过程中遇到的一些问题,并分享我对系统稳定性、检索效果优化和结果“接地”的一些思考。
文献调研工具的发展与新需求
从单篇文献解析到多来源调研
2022 年底 ChatGPT 发布之后的一年多时间里,模型的上下文窗口和处理能力十分有限。早期具有代表性的文献调研工具是 ChatPDF 一类的应用。用户需要手动上传 PDF,系统随后解析文献内容,并提供不同风格的总结,例如面向专业读者的总结,或便于领域外读者理解的通俗介绍。
这类工具通常还提供对话功能。系统以当前文献为上下文,根据用户的问题和文献的具体内容生成回答,并给出来源(标识出每句回复对应到文献的具体句子)。受当时模型上下文长度和整体能力的限制,这类工具一般只能处理一至两篇文献;而且,文献需要用户手动上传,系统本身并不承担文献检索和下载任务。
随后出现的 NotebookLM 进一步扩展了信息来源。用户可以上传 PPT、PDF 等文档资料,也可通过提示词让系统从互联网搜索并抓取内容。除对话功能外,它还提供思维导图、一键 PPT 等预设工具。由此,文献调研系统可处理的上下文规模和信息来源的广度都得到了显著提升,NotebookLM 也因此成为部分用户学习和科研工作的得力助手。
此后,各家 AI 助手陆续推出”深度研究“功能,可围绕特定专题或领域开展自动化研究并生成带引用的报告。至此,通用文献调研/深度研究工具已经相对成熟。
接入科研工作流
但与此同时,科研工作者开始将编码智能体接入自身工作流,文献调研系统也因此面临新的要求。
对于科研工作而言,文献并不是唯一的信息来源。 系统还需要结合研究者正在探索的科学问题、亲自设计的实验范式和实际采集的数据,围绕具体研究任务开展针对性的、具有实践性质的调研。在这样的应用场景下,文献调研就不能只是对公开文献的检索与汇总,而是应当成为整个科研工作流的一部分。
目前,各家厂商提供的深度研究功能大多是相对封闭的系统,难以按照研究者的需要组合本地文献库、实验数据和自定义工具;并且 ChatGPT/Codex 类的智能体虽然能够结合本地项目和深度研究功能,但其数据接口不开放,无法进行原文级别的信息核实和溯源。这是我希望自行构建文献调研系统的两个主要原因。
核心目标:接地
我希望文献调研系统能够生成言之有据的、可溯源的调研报告。这里涉及一个我称为“接地”(grounding)的概念,主要包括两个层面。
- 第一是 文献与元数据的真实性 。报告中引用的文献必须真实存在,且其标题、作者、期刊名称、发表年份、页码等元数据必须准确;
- 第二是 引用与原文之间的语义对应 。报告中的所有引用都应当与文献原文建立明确的对应关系,不能引用无关的文献。理想情况下,报告中的每一句话都能够追溯到原文中的某个段落或句子。
设计良好的接地策略,能够有效避免模型的幻觉输出进入最终报告。幻觉是不可避免的,我们需要的是在报告生成后的自动化核验步骤中发现它的存在,并进行修正。
构建系统的技术基础
目前,构建这样一套系统所需的基础工具以及较为完备,主要包括以下三类。
- PDF解析工具。
原始 PDF 通常不能作为大模型的输入,因此需要先转换为结构化的文本和图片。MinerU 等解析引擎可以将 PDF 转换为便于大模型读取的 Markdown 格式,并提取其中的图片。它不仅能够截取论文中的插图,还可以解释插图的内容。例如,对于一幅折线图,系统可以解析出横纵坐标轴的含义和曲线变化的趋势,并将这些信息转换为文本。 - 语义检索工具。
Semantic Scholar 、 Sciverse 等工具提供语义化检索服务。用户用自然语言描述检索方向后,系统即可返回相关论文的元数据与摘要。 - 元数据反查工具。
CrossRef、OpenAlex、PubMed 等文献资源服务商可以根据 DOI、标题反查论文元数据并获取摘要,这为 PDF 解析后的原文-元数据交叉验证提供了精准的数据源。比如,可以比对 PDF 提取出的论文摘要部分与元数据反查得到的摘要确定原文-元数据是否匹配。
有了这三类工具,从头构建一套文献调研系统就具备了基本条件。
1.0:基于 Agent+Skill 的流程
在 1.0 阶段,我主要通过 Hermes Agent 建立和迭代 Skill,将一篇文献的导入流程划分为四个步骤。
- 第一步是上传 PDF(大部分 PDF 需要手动下载以通过付费墙);
- 第二步是调用 PDF 解析服务(如 MinerU),将 PDF 解析为 Markdown 文档和插图图集;
- 第三步是进行元数据反查。系统从解析后的文本中提取标题和 DOI,再调用 OpenAlex 等接口获取并校验元数据,将标题、作者、关键词等写入SQLite数据库,再将上一步的结果存放至结构化的目录中,如
{year}/{first_author}_{title}/{first_author}_{title}.md; - 第四步是文献翻译和总结。系统会调用大模型接口分块翻译文献段落并拼接,并生成中文总结文档。
完成导入流程后,在智能体会话中输入需要调研的内容。理论上,智能体可以读取解析后的文本,并据此回答问题。但是实际上,当时的查询工具只对作者、标题、关键词等位于数据库中的数据进行字符串匹配,无法按照论文摘要或正文内容查找文献,检索能力十分有限。
除此之外,这一版本还暴露了三个影响可用性的问题。
元数据匹配不可靠
PDF 解析后的文本中可能包含多个 DOI,并且 DOI 的字符组合具有较强随机性,模型在提取过程中容易给出不匹配或根本不存在的 DOI。由于当时的交叉验证机制尚不完备(比如缺少根据摘要进行匹配的环节),系统有时会将论文正文与错误的元数据关联起来,直接影响后续调研质量。
人工修订依赖外部知识库
在 1.0 阶段,我还为系统增加了 PDF 解析结果的微调修改功能。论其原因,部分调研任务的最终目标是复现原文中的算法,或者将算法迁移到自己的研究中。这类任务要求解析结果中的数学公式与原文中的公式严格对应,不能出错。但 MinerU 等解析引擎的结果并非始终准确,因此需要保留人工检查和修改的通道。
当时,这一功能通过连接外部知识库软件(如 Notion)实现。完成导入流程后,系统会通过 Notion API 将解析后的文档发布到 Notion,人工检查和修改完毕后,再通过 API 下载修改后的文档并覆盖原始结果。Notion 提供了较完善的人机交互体验,但接口时常出现限频(尤其在批量解析多篇论文的场景下),从而增加整个系统发生单点故障的概率。
流程稳定性不足
Agent 与 Skill 的组合存在一个根本问题:整个流程高度依赖模型对 Skill 的理解和遵守程度。 当时,系统缺少任务状态的可靠监控,Skill 中设置的规则是否执行取决于智能体是否读到且遵循它。因此,流程经常出现崩溃或卡死。以文献全文翻译为例,系统会将整篇论文按照章节进行拆分,再逐块调用大模型接口。翻译过程中,后台进程有时会无响应;遇到超时情况时,Hermes Agent 的任务管理机制也无法可靠地恢复流程。此外,会话记录中杂乱的、结果不一的工具调用记录也会让大模型容易弄混各任务的进度和状态。
实际使用中,文献上传后经常卡在中间步骤,最终可能出现文献没有完成解析、解析结果没有迁移至结构化目录,或者没有自动生成总结等情况。此时,系统基本处于不可用状态。
2.0:持久化任务队列与流水线状态跟踪
针对 1.0 依赖智能体临场执行、任务状态难以追踪的问题,2.0 将文献处理任务相关信息(比如每个步骤的状态)保存至到 SQLite 数据库中,并使用 Flask 框架进行任务调度。运行在 Flask 进程内的调度线程负责领取任务, Worker 线程池则负责执行任务。在一个任务内,Worker 顺序执行各处理步骤:已经完成的步骤自动跳过,失败时可以根据配置指定的策略终止或重试。由此,流程管理改由程序与数据库负责,不再完全依赖大模型对 Skill 的理解和遵守能力,以及对任务状态的记忆能力。
除此之外,在 2.0 版本中,全文解析结果在保存到磁盘之后也录入数据库,实现全文检索。在 3.0 版本中,我还取消了对外部知识库的依赖,改为自建解析结果查看与编辑界面;以上改进显著提高了系统的可靠性和可用性。
3.0:从完整应用转变为数据提供方
系统内调研功能的取舍
之后,我便想着让系统也负责完整的调研流程,因此参照了 BrainPilot 项目的单智能体调研模式实现了两阶段调研智能体:第一阶段调用搜索接口搜索文献并下载入库,第二阶段根据本地文献库内容撰写报告。然而,这套流程实际使用中阻塞在了下载文献这步,因为很多文献并非开放获取,需要通过付费墙和浏览器真人验证,而这两个需求恰恰是使用自动化程序难以搞定的。因此,简单起见,我直接放弃了自动化获取文献这条路线,改为手动逐篇下载智能体第一阶段给出的文献清单中的文献,再手动入库,等待解析流程全部完成后再开启第二阶段。
后续使用中,我逐渐意识到现有的编码智能体已经具备相当程度的自主调研能力。只要为其提供数据接口,使其能够访问论文全文,它就可以在不依赖专门编写的一套 RAG (检索增强生成)流程或明确指定多轮迭代逻辑的情况下拆解问题、围绕任务检索和阅读文献。具体表现是主智能体只调用文献调研系统的搜索文献和读取正文功能,而不调用其内置的调研智能体。
有鉴于此,我得出结论:智能体缺少的主要是文献证据源,尤其是文献原文的访问接口,而这实际上已经在此前的版本中实现了。
基于这一认识,3.0 版本对系统的职责进行了调整:文献调研系统不再直接负责报告撰写,而是作为数据提供方,为编码智能体提供服务。
具体而言,我将调研和报告撰写功能从系统内部移除,其余功能则封装为 MCP 服务,供编码智能体调用。由此,系统从一个包含完整调研流程的应用,转变为面向智能体的数据基础设施。
向量化检索使系统真正可用
系统真正达到可用状态,是在引入向量化检索之后。这一部分借鉴了 BrainPilot 项目中知识库的实现思路。
从前,系统主要依赖精确的关键词匹配,然而:
- 同一概念在不同论文中可能采用不同表述,仅依赖关键词往往无法检索到足够多的相关文献;
- 在不清楚论文中与问题相关的具体段落时,智能体需要从头到尾线性阅读整篇论文。
这严重影响了文献检索的覆盖范围和效率。
引入向量化检索后,系统会在 PDF 解析完成后,按照章节对文本进行分块,再对各文本块进行向量化嵌入(将文本块转化为统一维度的向量)并导入数据库。检索时,系统通过计算搜索词嵌入后的向量与数据库中的向量的余弦夹角开展语义匹配,返回与检索内容最相关的几篇论文并精确到具体段落。这种按语义进行检索并返回精确位置的改进显著提高了检索效率。至此,系统不仅具备了 PDF 解析能力,也具备了较为可靠的语义检索能力,文献调研流程真正进入了可用阶段。
实际使用与持续优化
系统可用后,我开始将其用于实际工作中,包括复现论文中的算法,以及将相关方法迁移到现有数据中。在此过程中,系统又经历了多轮迭代,下举两个例子。
- 批量查询。 系统提供根据DOI返回论文摘要的功能,但只能逐个 DOI 查询,每次返回一条结果;现在可以在一次请求中批量查询多个DOI并统一返回结果。这减少了智能体发送请求的轮次,进而节省了 token 消耗;
- 混排论文处理。 一些早期论文可能与上一篇论文混排在一页中,导致原始解析结果中保留了上一篇论文的末尾内容,这些内容可能污染后续总结流程。系统现在可以识别这种情况,并自动剔除与本篇论文无关的段落。
尚未解决的问题
尽管系统已经可用,但幻觉问题仍十分突出,以下举两个代表性例子说明之(这些例子是对编码智能体的会话历史,包括每一次输入、输出和工具调用结果进行分析得到的)。
- 在一次调研中,智能体在未核实原文的情况下,将一篇论文描述为“采用了某类分析方法”,并把这句话写进后续子智能体的任务说明中。子智能体因此把它当成已经确认的事实,错误信息进一步扩散到下游调研工作。这个错误是在我后续追问报告中的细节时才发现的。智能体经核查发现所述的方法名在文献当中并未出现;进一步核对原文的方法部分后,发现该论文实际采用的是另一种方法,故整个调研工作需要推倒重来;
- 另一次调研中,智能体并没有读到论文的实验设计部分,却把报告中的相关说法标记为“已核实”。精读原文后,系统发现此前写入报告的实验条件和参数均有错误,后大幅修订了报告。
这两个问题代表了两类失误: 把幻觉出的说法当成事实,以及在没有阅读原文获取证据时将论断标记为“已核实”。 后续我在与文献调研系统配套的 Skill 中增加了几条可执行的规则,以尽可能避免以上错误再次发生,或在发生之后能够自动纠正:
- 声称“某篇论文使用了某种方法”必须要求该方法名称出现在全文中并阅读相关段落;
- 每条关于文献的论断必须标注证据等级。[原文] = 读到支撑该条目的原文段落并附原句和原句在全文中的位置,[摘要] = 只核对过摘要或元数据,未读原文或未在原文中找到支撑证据;[推导] = 智能体思考出的内容,无凭无据
- 复核报告时,只有原文中具有支撑论断的段落时才能标记该论断为“已复核”
- 子智能体的任务说明中必须逐条注明事实来源
进行这项调整后,系统幻觉率进一步下降,但是智能体的行为仍主要依靠软性的 Skill 进行约束,完整的证据链尚未被转化为确定性的规则。因此,如何将报告中的论述和原文证据系统性地连接起来,实现完全的接地,仍是后续开发的重点。
结语
尽管仍有改进空间,这套系统已经基本实现了最初的目标:智能体能够开展灵活的语义检索,读取到本地文献库的原文,综合多篇文献的内容给出具备一定可溯源性的报告,并将这些能力融入现有科研工作流中。
从 1.0 到 3.0,系统的演进不仅是能力的不断提升,还包括对自身职责边界的思考与调整:文献调研系统目前只负责提供可靠的、可检索的文献证据,编码智能体则负责围绕具体任务开展调研和撰写报告。对于现阶段的使用需求而言,所设定的目标已经得到了较好的实现。



