RAG 文档清理器

清理器移除什么，以及为什么重要

每一份长 PDF 都带着版面杂讯：带报告标题的页眉、带保密声明的页脚、在角落里递增的页码。对人类读者来说，这些是定位参照。对嵌入模型来说，它们是以完整强度在每一页上重复的噪声：同一行页眉被分块、嵌入、存储几十次，稀释了本应描述实际内容的向量，并在检索结果中像信息一样冒出来。本清理器把杂讯当作一个检测问题处理，规则简单且可检验：一行较短的文本如果出现在至少百分之六十的页面上（且至少两页），就会被列为移除候选，并由你决定是否去掉。没有任何东西会被悄悄移除——每个候选都会连同它的文本、页码和次数一起展示，然后才由你勾选或取消。

页码有自己单独的候选，因为它们从来不会字面重复：第一页写 1，第二页写 2，重复规则永远抓不到它们，然而一个以孤立数字或一行“第 7 页，共 40 页”结尾的分块，对嵌入毫无帮助，还可能让把这行字当作事实引用回来的模型产生混乱。清理器匹配常见模式——等于其所在页码的孤立数字，以及“N of M”和“N / M”形式——并把所有匹配汇总为一个候选。第三类是重复段落：样板免责声明、重复的摘要，或在同一文档中出现两次的复制粘贴章节。重复段落默认从不勾选，因为重复的段落有时是刻意的——例如必须在两个章节中出现的警告——因此清理器只标记它们，把决定留给你；当你确实移除时，它会保留第一次出现的那一份。

提取如何工作，以及它的近似之处

提取是近似的，本页面不会假装不是这样。清理器在本地解码 PDF 内容流，读取显示文本的操作，并把每一组显示的文本当作一行。这种模型速度快，对普通文字处理软件和导出工具生成的报告、手册和论文足够好，但它有诚实的局限：多栏布局可能会按存储顺序而不是阅读顺序输出，合字和自定义字体编码可能使个别字符乱码，而扫描版 PDF——其页面是照片而不是文本——根本不会产生任何行。发生这种情况时，工具会直言不讳，而不是编造输出：零行的结果意味着该文档需要先做 OCR，任何清理器才能帮上忙。本第一版的杂讯检测也不考虑位置：一行短文本是按它在多少页上重复来判断的，而不是按它在页面上的位置，因此正文中真正重复的短标题也可能被列出——这正是每个候选都由你取消勾选的原因。

输出是为 RAG 流水线的下一步而构建的。清理后的文本下载会把存留下来的行逐页拼接，页与页之间以空行分隔，这样你就可以阅读、对比，或把它喂给你自己的分块器。JSONL 下载更进一步：它把清理后的文本打包成大约八百个字符的分块，尽可能在段落边界而不是句子中间切分，并以 {"text": "..."} 的形式每行写一个 JSON 对象——这是大多数嵌入脚本和向量库加载器直接接受的形状。分块大小是一种折衷，而不是定律：八百个字符小到一个分块通常只涵盖一个想法，又大到这个想法仍然带着它的上下文。配套文章更深入地解释了大小、重叠和边界。

隐私与范围刻意保持狭窄。文件在本页面、你的设备上解析；分析它不会发出任何网络请求，因此内部报告、合同草稿和个人文档都留在原地。第一版只接受 PDF，因为 PDF 是杂讯问题最严重的地方，也是浏览器本地解析器仍能可靠恢复文本的地方；文字处理和 HTML 来源最好在生成它们的工具中清理，或先转换为 PDF。清理器也不判断质量：它不会总结、改写或纠正它保留的文本，也不会决定一份文档是否值得嵌入。它只做一件机械的工作——剥掉重复的，保留唯一的，把分块交给你——并在每一步展示它的工作过程，让判断留给了解这份文档的人。

三类候选一览