> 建检索系统之前先数一遍语料——8,539 条引用去重后只剩 2,200，而七成连 DOI 都没有

结论先行¶

给自己的论文库建本地 RAG 之前，我先花了一天把语料数了一遍。 四个数字全都和我的直觉差很远，而且每一个都会改变架构：

最贵的发现是第四行。 原本的计划直接从"部署向量库 + 跑 embedding"开始。 审计之后插进去一整周的 Phase 0：扫 .bib、跨项目去重、 用开放元数据 API 补 DOI/arXiv ID、再批量下载。 预计把 PDF 覆盖率从 1.5% 拉到 ~61%。

没有这一天，我会给一个不存在的语料库建一套很漂亮的检索系统。

为什么¶

三个反直觉的地方，都只有数过才知道。

跨项目重复是最大的一笔。 8,539 → 2,200 是 3.9 倍的缩减， 而且不需要任何技术手段，只需要一次去重。 原因很直白：41 个项目，相邻方向的项目引同一批基础文献。 如果不先去重，后面每一步（下载、解析、embedding、存储）都要多付 3.9 倍。 这是整个项目里性价比最高的一步，而它在原计划里根本没有。

"有引用"和"能拿到"是两回事。 70–75% 的条目没有任何可以直接下载的句柄—— 没有 DOI、没有 arXiv ID、没有 URL，只有标题和作者。 它们不是"难下载"，是下载流程根本无从开始。 所以必须先有一个 enrichment 环节（按 title+author 去开放学术数据库反查标识符）， 那个环节在原架构图上不存在。

覆盖率的分布极不均匀。 按项目看，有的能到 86–97%，有的是零。 零覆盖的那些恰好是写得最早、.bib 手敲的项目。 这个分布很有用：它让"先处理哪一批"有了依据—— 先跑高覆盖率的拿到立即可用的结果，再回头啃零覆盖的。 只看总体的 25% 会得出"均匀地有点难"，那是错的画像。

怎么用¶

任何"给已有资料建检索/索引系统"的项目，动工前先出这四个数：

1. 总量 vs 去重后的量。 比值就是你能白拿的那个系数。 文献用 DOI/标题归一；文档用内容哈希。
2. 可获取比例。 有多少条带着能自动拿到正文的句柄？ 没有句柄的那部分需要一个独立的补齐环节——它通常不在初版架构图里。
3. 当前已落盘的比例。 这个数决定第一版是"检索"还是"采集"。 1.5% 的时候，做检索是在做演示。
4. 按来源/子项目拆开看分布。 总体均值会掩盖掉"一半全有、一半全无"， 而那个形状直接决定了实施顺序。

两条通用的：

• 审计的产出是路线图的一个新阶段，不是一张报告。 如果数完之后计划没变，那多半是没数对地方。
• 数之前先写下你的猜测。 上面四行的"我以为"列是我动手前写的。 猜错本身不重要，重要的是错的方向——我系统性地高估了自己手上有的东西， 这个偏差在下一个项目里还会出现。

出处¶

自己的本地文献 RAG 系统，2026-03 的设计期审计： 扫描 ~41 个研究项目下的 183 个 .bib（~8,539 条）、1,012 个 .tex、 ~350–520 个 PDF。审计报告直接导致路线图新增 Phase 0（引用审计与补齐）。 相关：KV 每 token 多少字节,要从引擎自己报的池子量,别从 config 推——我推错了 1.75 倍（同一类错误的运行时版本： 该测的别推）、检索工具说"没有相关工作"之前，先让它找一篇你已经知道存在的论文、扩大实验、造 benchmark、造术语、写投稿之前的四道门。