在搭建学术文献RAG系统的过程中，最令人头疼的难题恐怕并非模型选型，而是“幻觉”问题——系统可能凭空编造文献、伪造数据、张冠李戴结论，这在学术研究中堪称致命缺陷。RAG（检索增强生成）技术已被公认为缓解幻觉的有效手段，但学术文档的独特性使得通用方案往往效果不佳。本文从工程实践出发，梳理了构建学术文献RAG系统时各环节的关键决策与常见陷阱，希望能为同行提供参考。
一、PDF解析：学术文档的结构化提取是首要挑战
1.1 学术PDF的特殊性
通用PDF解析库（如PyMuPDF、pdfplumber）处理普通文档尚可，但学术论文面临几个棘手特征：
多栏排版。绝大多数期刊论文采用双栏排版，按页提取文本时左右栏内容会混杂，导致大量断句错误。必须按行提取后再依据坐标重新排列，这一步骤无法省略。
公式与图表。数学公式在PDF中可能以字体嵌入、图片或MathML标记等多种形式存在，通用解析器几乎无法正确提取。图表同样困难——标题与正文可能跨页，解析时容易断裂。
页眉页脚与脚注。这些内容混入正文后，按页提取时会被当作正文部分，干扰语义分块。
1.2 解析方案选型
轻量方案可采用PyMuPDF配合自定义后处理：提取文本块时记录坐标信息，按坐标排序恢复阅读顺序；利用正则表达式剔除页眉页脚的重复模式；通过上标标记识别脚注后单独处理。这套方案能覆盖约80%的场景，剩余20%（如公式、复杂表格）则需人工介入或更重的方案。
重量方案推荐GROBID，这是一款专为学术论文设计的解析工具，能识别标题、摘要、章节、参考文献、图表等结构化元素，输出TEI XML格式。虽然准确率高，但部署成本较高，适合大规模批量处理。
实际工程中常用的折中方案是：用GROBID进行结构化提取，用PyMuPDF补充提取GROBID未能识别的段落，然后将两套结果合并。
二、文本分块：学术文档不能简单按字数切割
2.1 通用分块方案在学术场景中的问题
RAG系统最常见的分块策略是按固定字数切分，例如每512个token一个chunk，重叠128个token。这种方案在通用文档上效果尚可，但应用于学术论文时会暴露出明显问题。
段落完整性被破坏。学术论文的段落内部存在严密的论证逻辑——论点→论据→分析→结论。按字数切分可能在论点与论据之间断开，导致检索到的chunk缺少论据，或论据缺失分析，模型拿到碎片化信息后自然生成质量下降。
章节层级信息丢失。论文中的“3.2.1 实验设计”与“3.2.2 结果分析”属于同一研究问题的两个环节，按字数切分后它们可能被分到不同chunk，检索时只召回其中一个，造成上下文断裂。
2.2 学术文档的分块策略
按章节层级分块是更合理的方案，具体做法如下：
第一层，依据章节标题切分。通过GROBID或正则表达式识别“第X章”“X.X”“X.X.X”等标题模式，以标题作为分界线。
第二层，在章节内部按段落切分。学术论文的段落通常是完整的论证单元，以缩进或换行为分隔标志。
第三层，对超长段落进行二次切分。若某个段落超过模型的上下文窗口，则按句子边界进一步切分，但保留段落的论点句（通常位于段首）作为每个子chunk的前缀。
每个chunk需附加元数据：所属章节编号、章节标题、文档标题。检索时这些元数据参与排序，同一章节的chunk优先级更高。
2.3 chunk大小的工程权衡
chunk过小（如128 token）会导致上下文不足，模型生成时缺乏全局信息；chunk过大（如2048 token）则检索精度下降，噪声信息淹没有效信号。
学术场景的推荐区间为256-512 token，并配合64-128 token的重叠区域。该区间大致覆盖1-2个完整段落，既能保障语义完整性，又不会引入过多噪声。
三、Embedding模型选择：学术文本的语义表达具有特殊性
3.1 通用Embedding模型在学术场景中的局限
M3E、BGE等中文通用Embedding模型在常规语义检索任务中表现不错，但学术文本面临几个独特挑战：
术语密度高。例如，一篇计算机视觉论文中，“注意力机制”可能指self-attention，也可能指人类的视觉注意力，具体含义取决于上下文。通用模型对这类术语歧义的处理能力较弱。
长距离依赖。论文第一章提出的研究问题，可能要到第四章才有结论。检索“本文的研究结论”时，需要模型能关联到前面章节的研究问题，而通用模型在chunk级别的检索中难以捕捉这种跨章节的语义关联。
3.2 学术领域微调方案
在通用模型基础上进行学术领域微调是最务实的路径。微调数据可从两个来源构建：
对比学习数据：从同一篇论文中抽取章节标题与对应摘要作为正样本对，从不同论文中抽取作为负样本对。此类数据使模型学会区分同一研究问题内的语义关联与跨研究之间的语义差异。
查询-文档对：若有条件，可收集学术搜索日志，将用户查询与点击的文献段落构建为正样本对。这能让模型学习用户在学术检索场景下的查询习惯。
如果缺乏训练数据，退而求其次的方案是在检索阶段进行领域适配：先对查询做术语扩展——利用同义词词典或大模型将查询中的学术术语扩展为该领域常用的等价表述，再用扩展后的查询进行检索。此方法成本较低，效果有限但聊胜于无。
3.3 模型选型参考
中文场景：BGE-M3是目前综合表现较好的开源选择，支持多语言与多粒度检索，在学术场景下比M3E更稳定。若资源允许，在其基础上进行领域微调效果更佳。
英文场景：SPECTER2是专为学术文献设计的Embedding模型，基于SciBERT，在论文相似度检索任务上优于通用模型。若系统需处理大量英文文献，值得接入。
四、向量数据库选型与部署
4.1 选型考量
学术文献RAG系统的数据规模通常在万到十万篇文献的量级，对应百万到千万级别的chunk数量。该量级对向量数据库的要求不算极端，选型时需重点关注几个维度：
检索性能：万级文献规模下，FAISS本地部署即可；十万级以上需要分布式方案，Milvus或Qdrant是主流选择。
混合检索能力：学术场景需要语义检索与关键词检索的结合——术语精准匹配依赖BM25，语义关联则依赖向量相似度。支持混合检索的数据库（如Elasticsearch + 向量插件、Milvus 2.4）能降低系统复杂度。
元数据过滤：按年份、学科、期刊等维度进行过滤是高频需求，向量数据库需支持在向量检索的同时进行元数据条件过滤。
4.2 索引参数调优
学术文献的chunk分布有一个特点：同一篇论文的chunk之间语义相似度偏高，不同论文之间差异较大。这导致在HNSW索引中，同一论文的chunk在向量空间中聚集成簇。
如果M值（HNSW的连接数）设置过小，检索时容易在某个簇内打转，无法跳转到其他论文的相关chunk；设置过大，索引体积和检索延迟都会上升。学术场景建议M值在32-64之间，比通用场景的默认值略高，以确保检索时能跨簇召回。
efSearch参数（检索时的搜索深度）也建议调高至128-256，牺牲少量延迟以换取更高的召回率。学术检索对召回率的敏感度高于延迟——漏掉一篇关键文献比慢50毫秒严重得多。
五、检索策略优化：混合检索与重排序
5.1 混合检索的实现
学术场景的检索需求可分解为两类：
术语精确匹配：查询“Transformer架构”时，必须召回包含“Transformer”这个词的文献，语义相似但不含该术语的chunk价值较低。这类需求用BM25关键词检索更精准。
语义关联匹配：查询“如何解决长序列建模的计算效率问题”时，需要召回讨论线性注意力、状态空间模型等具体方案的文献，即使这些chunk中未出现“长序列”或“计算效率”等词。这类需求用向量语义检索更有效。
混合检索的实现方式：分别运行BM25和向量检索，各取Top-K，合并后去重，按加权得分排序。权重比例根据查询类型动态调整——查询中包含明确术语时，BM25权重提高；查询偏泛化描述时，向量权重提高。
5.2 重排序模型
初检索的结果按向量相似度排序，但相似度高不代表与查询最相关——可能只是主题相近但讨论的问题不同。重排序模型利用更精细的交叉编码器（Cross-Encoder）对每个候选结果进行query-document对的相关性打分，重新排序。
bge-reranker-v2-m3是当前中文场景下开源重排序模型的首选，在学术文本上的表现优于通用重排序模型。其部署成本高于Bi-Encoder（每次检索需对每个候选进行一次完整的注意力计算），但检索质量的提升值得付出这一代价。
工程实践中的折中方案：初检索取Top-50，重排序取Top-10喂给生成模型。这样既能控制重排序的计算量，又能显著提升生成模型获取的上下文质量。
六、生成约束与幻觉防控
6.1 检索结果注入策略
检索到的chunk不能直接一股脑塞给生成模型，需注意以下几点：
注入顺序：按相关性从高到低排列，最相关的chunk放在最靠近生成指令的位置。大语言模型对上下文末尾的信息关注度更高（近因效应），将最关键的信息放在最后能提升生成质量。
注入格式：每个chunk前标注来源信息——论文名称、章节、发表年份。生成模型在输出时可引用这些来源，增强可信度。同时要求模型在无法从检索结果中找到答案时明确说明，而非编造。
注入量控制：总token数控制在模型上下文窗口的60%-70%以内，留出足够空间供生成使用。塞入过多检索结果反而会干扰模型的判断。
6.2 生成后校验
RAG无法完全消除幻觉，生成后需进行一轮校验：
引用校验：检查生成文本中引用的文献是否确实存在于检索结果中。若模型引用了检索结果之外的文献，则大概率是幻觉，需标记剔除。更彻底的做法是在校验阶段对接权威学术数据库进行二次验证——例如接入知网或Semantic Scholar的检索API进行交叉确认，思路相同，成本也不高。
事实校验：对生成文本中的关键论断进行事实核查——将论断提取为查询语句，反向检索文献数据库，确认是否有文献支撑。无文献支撑的论断需标注为“未验证”。
逻辑一致性校验：检查生成文本内部的逻辑是否自洽——结论是否与前提矛盾，数据引用是否前后一致。这部分可利用大模型自检：将生成文本作为输入，让模型检查逻辑一致性，输出问题清单。
6.3 一个完整的RAG调用链路
总结一下完整的调用流程：
- 用户输入查询
- 查询预处理：术语扩展、意图识别（精确匹配 vs 语义关联）
- 混合检索：BM25 + 向量检索，各取Top-50，合并去重
- 重排序：Cross-Encoder对Top-100候选打分，取Top-10
- 上下文组装：按相关性排序注入检索结果，附加元数据和来源标注
- 生成：带约束的prompt调用大模型，要求基于检索结果生成，不确定时标注
- 后校验：引用校验 + 事实校验 + 逻辑一致性校验，输出问题清单
- 交付：生成文本 + 来源清单 + 校验结果
总结
搭建学术文献RAG系统时，每个环节都存在学术场景的特殊性需要处理：PDF解析需应对多栏与公式，文本分块需尊重章节和段落结构，Embedding需覆盖术语密度与长距离依赖，检索需混合关键词与语义双通道，生成则需加入来源约束与幻觉校验。
通用RAG框架拿来即用的方案在学术场景下效果大打折扣，根本原因正是这些领域特异性未被解决。只有理解了每个环节的问题与对策，才能根据自身场景进行针对性优化，而非在通用方案上调参调至怀疑人生。
