Table of Contents

索引 17,000 篇研究 PDF 之前，先测试资料集

300 篇论文可以整理成很好用的本地资料库。17,000 篇论文也可能变成一个外表壮观、却总把你带到错误论文的系统。

差别通常不在向量数据库，而在于你是否真正知道资料里有什么：扫描件与文字 PDF、预印本与出版社版本、重复下载、缺页、错乱的阅读顺序、多语言标题，以及被误当成正文的参考文献。

在搭建大型本地 RAG 之前，先从代表性样本做一次资料集完整性测试。它应当回答三个问题：资料是否适合索引、引用会在哪里断裂、哪些问题真的值得投入工程时间。

先确定资料库要支持哪些判断

选技术栈之前，先写下真实问题。科研资料库面对的任务可能完全不同：

找到最早提出某种方法的论文；
比较两个定义，同时避免把它们混为一谈；
把一项主张追溯到确切版本和页码；
从一篇论文沿着引用找到另一篇；
用中文或日文检索英文资料；
分清原始实验与只是引用该实验的综述。

给每个问题写下一个或几个应当找到的文档，保留 20–50 个作为小型评测集。它不需要看起来像一项宏大的统计研究，只要能代表你平时真正要做的工作。

没有这套问题，每个架构选择都只能靠演示是否流畅来判断。有了它，问题就会变得实际：新组件有没有找回简单系统漏掉的证据？

分块之前，先建来源账本

给每个输入文件一个稳定的本地编号，并记录足以再次辨认它的信息：

{
  "document_id": "doc_004281",
  "original_path": "papers/attention-is-all-you-need.pdf",
  "sha256": "…",
  "bytes": 2201700,
  "page_count": 15,
  "source_url": "…",
  "retrieved_at": "2026-09-04",
  "declared_language": "en",
  "rights_note": "research copy supplied by collection owner"
}

哈希值可以发现文件名不同的完全重复项；原始路径和获取记录则保留文件的来处。原件保持只读，提取文本、OCR 结果、向量和图数据放在独立的派生数据目录。

科研资料中还经常存在一组组“版本家族”。预印本、作者接受稿和出版社 PDF 可能属于同一项研究，但分页、图表、勘误和补充材料并不相同。不要悄悄把它们合并成一个文档。应当把它们标为相关版本，并让引用指向读者真正能够打开的那一版。

DOI 很有用，但不能代替完整的来源记录。Crossref REST API 可以用 JSON 返回已登记的学术元数据；在资料存在时，其中还会包括资助、许可、更新、ORCID 和 ROR 等字段。把返回内容连同获取时间保存在来源账本旁边，不要用它覆盖 PDF 自己写明的信息。

按文档类型检查提取质量

一个“文字提取成功”的布尔值远远不够。PDF 即使导出了几万字，也可能已经丢失分栏顺序、图注、公式，或者表格与标题之间的关系。

先按资料中真正存在的情况划分代表性样本：

原生文字 PDF；
扫描页；
双栏论文；
公式密集的论文；
表格密集的报告；
多语言或非拉丁文字文档；
学位论文、会议录、补充材料和特别长的文件。

每份样本文档都检查标题、作者、章节顺序、分页、参考文献、一条图注、一张表，以及对检索重要的公式。记录具体失败类型，不要把问题平均成一个看似漂亮的总分。

PyMuPDF 的文字提取说明列出了纯文本、文本块、单词、HTML 和结构化字典等形式；当阅读顺序重要时，文本块与单词坐标很有帮助。处理科研结构时，GROBID 专门把技术与科学 PDF 转为结构化 TEI 文档。这些工具都不能替代对自身资料类型的抽样检查。

OCR 应当是经过测量的例外。如果只有一部分资料是扫描件，只让这一部分经过 OCR，比把所有 PDF 都当成图片更容易测试和维护。

先规定引用必须包含什么

决定分块大小之前，先确定每条搜索结果必须能够展示哪些信息。一个实用的最低要求是：

文档编号 + 确切版本 + 页码或章节 + 原文片段 + 提取方式

如果论文有稳定的印刷页码，同时保留 PDF 页序号与印刷页码。片段跨页时明确标出。文字来自 OCR 时也要让读者知道。如果提取时没有页面几何信息，就不要拿分块位置冒充页码。

后续的全文检索、向量检索、重排、生成和图遍历都应保留这份约定。最终回答是否可查证，取决于送进生成模型的证据对象是否可查证。

先建立全文检索基线

先用直观的全文检索系统索引样本，再运行评测问题。BM25、SQLite FTS5 或其他普通全文引擎，可以为标题、作者姓名、专业术语、标识符和精确短语提供容易理解的基线。

BEIR 基准研究在 18 个不同数据集上评估了检索系统，发现 BM25 是稳健的基线；重排和后期交互方法的平均效果更好，但计算成本也更高。这说明基线值得测量，并不表示某一种方法必然适合你的资料。

对每个问题记录：

预期文档是否出现在靠前位置；
正确段落是否能够打开；
显示的引用是否指向正确版本；
漏检属于哪一种失败类型。

只有在实测漏检确实来自语义差异时，才加入语义检索，例如提问和论文用不同词汇表达同一概念。保留精确检索，方便排查问题。混合检索应当通过改进这套问题集来证明价值，而不是靠让架构图变得更复杂。

标识符稳定后，再建知识图谱

当问题无法由一列排序后的段落清楚回答时，图谱才真正有价值，例如：哪些论文使用某种方法、哪一版加入了勘误、一个术语如何跨语言演变，或某项结论依赖哪个实验。

但是，论文 A —支持→ 主张 B 这条边本身并不能证明什么。边上也要保存来源：

来源文档 + 版本 + 页码或章节 + 支持片段 + 提取方式 + 审核状态

把观察到的事实与推断出的关系分开。标题页解析出的作者、GROBID 提取的参考文献、语言模型建议的关系，证据强度并不相同。如果它们最终都成为完全一样的边，图谱会显得很完整，却把最薄弱的假设藏了起来。

多语言资料应保留原始名称和文字。翻译、别名、拼音、假名、词根和规范化写法可以作为附加形式，但不应替换来源原文。这样既能跨语言发现内容，也不会抹去来历。

全量构建前，先测试更新流程

大型资料库不会静止不变。论文会增加、修订、改名和替换。在索引全部 17,000 个文件前，先证明样本流程可以：

增加新文档而不必重建全部内容；
识别没有变化的文件；
新版本到来时保留旧版本；
来源被撤回时删除对应派生数据；
根据账本和已记录的设置重建索引。

同时测试你打算承诺的离线边界。装好必要工具与模型后断开网络，重新构建样本。观察文字提取、嵌入、重排、遥测和模型加载的实际路径，不要因为界面运行在本机，就假定每个阶段都是本地的。

一份完整性报告应该说什么

报告应当短到足以帮助做决定，至少包括：

资料类型和代表性样本；
完全重复项与疑似版本家族；
按类型整理的提取问题；
引用覆盖范围与已知弱点；
真实问题集的测试结果；
隐私边界和派生数据位置；
满足验收条件的最小架构；
对 OCR、语义检索、生成和图谱工作的继续或停止建议。

这里没有通用的及格比例。追查一句争议引文的历史研究者，与浏览数千篇摘要的团队，容错要求不会相同。验收条件应由资料所有者决定，完整性测试负责把取舍讲清楚。

用一个有边界的方式测试资料集

我维护的 Local Knowledge Terminal 面向本地、多语言、可回到来源的资料集。示例报告展示了本文所说的来源地图、浏览器样例和继续或停止的判断。

如果你已经有资料集和一台现成电脑，可以先做免费适配检查。资料适合、双方确认书面范围后，可选的 250 美元小型项目会测试一个代表性样本，并交付来源与隐私地图、小型浏览器样例和建议；不包含硬件、运输、定制 OCR 或生产部署。

无论最后选什么技术栈，顺序都可以很简单：先弄清文件，再证明提取质量，保住引用，测量检索，最后才添加智能层。