AI-Wiki

定义

RAG文档摄取 是指把 PDF、DOCX、PPTX、XLSX、CSV 等原始资料，处理成可进入 RAG 流水线的知识对象的前置过程。它不只是“把文件读出来”，而是要把文档转成后续可检索、可嵌入、可审查、可问答的结构化结果，通常覆盖解析、清洗、分块、脱敏、OCR 质量过滤、摘要、引用关系保留、向量化与入库等步骤。

在本文语境里，这一环节不是辅助步骤，而是整个 RAG 效果的源头能力。作者明确把很多 RAG 项目失败的根因，定位在摄取前处理质量不足，而不是仅仅归咎于向量数据库选型、检索参数调优或大模型参数优化。

在本文中的语境

本文围绕 LongParser v0.1.5 的升级展开，核心论点是：很多团队花了几周优化向量数据库和大模型参数，最后检索精度仍然很差，问题其实出在更早的文档导入与解析阶段。

文中列出的典型失败表现包括：

多格式文档解析错乱，导致原文结构在入库前就已经失真。
固定长度或“一刀切”分块把完整语义切断，造成召回失败。
敏感信息未经处理直接进入知识库，触发合规风险。
低质量 OCR 产生乱码并写入向量库，持续污染后续检索。

因此，本文把 RAG文档摄取 视为“源头活水”：如果源头环节质量差，后续检索、生成、问答和参数优化都只能建立在错误或残缺的数据基础上。

关键链路组成

本文涉及的摄取链路关键环节包括：

多格式解析
分块
PII 脱敏
OCR 质量过滤
摘要
交叉引用保留
嵌入
对话调用

这些环节共同构成了从原始文件到 RAG 交互闭环的完整路径，而不是彼此独立的零散功能。

关键机制

多格式解析

本文把多格式解析作为摄取起点。LongParser 被描述为可处理 PDF、DOCX、PPTX、XLSX、CSV 等格式，目标是减少企业在异构资料导入时出现的结构混乱、内容错位和信息丢失问题。

这一步的重要性在于：如果解析阶段已经把标题层级、表格结构、页面内容顺序或字段关系弄乱，那么后续再做摘要、嵌入或检索优化，都很难完全补救。

分块

分块是本文最强调的关键机制之一。文中批评传统 RAG 分块过度依赖固定词元上限，经常把一句话拆成两段，或把一个完整主题硬切开，直接破坏上下文连续性。

LongParser v0.1.5 在此引入语义分块：使用 all-MiniLM-L6-v2 模型跟踪文本块之间的余弦相似度，只在主题真正变化时才创建分块边界，以尽量保留完整语义单元。

此外，文中还提到混合分块模式会同时考虑：

词元限制
标题层级
表格结构

这意味着它不是只靠单一相似度阈值切分，而是把语义与文档结构结合起来，以适应多栏论文、跨页表格、嵌套标题等复杂材料。这里与既有条目数据库文档分块、文档边界标记、结构化文档标注的关注点相通：都强调切分后的块必须保持知识完整性，而不是只满足长度约束。

PII 脱敏

本文把 PII 脱敏视为生产级摄取链路中不可省略的一环。LongParser v0.1.5 采用双层脱敏引擎：

正则表达式 + Luhn 验证，用于处理银行卡号、社保号等结构化敏感数据
spaCy 命名实体识别（NER），用于识别上下文中的个人信息

文中给出的判断是，这种组合既覆盖格式明确的敏感字段，也覆盖自然语言中的身份信息，从而降低企业在金融、医疗等高合规行业中构建 RAG 时的数据泄露风险。

同时，文中还提到一个工程细节：未脱敏原始数据不会直接暴露给外部流程，而是安全存储在隐藏元数据中，以兼顾合规与后续数据复用。

OCR 质量过滤

OCR 质量过滤在本文中被用来解决“乱码污染向量库”的问题。作者强调，低质量 OCR 的危害不只是识别错误，而是这些错误文本一旦进入嵌入和索引阶段，就会成为长期污染源。

LongParser 在这一环节采用“零 ML OCR 过滤”，具体是启发式评分器组合以下信号：

OCR 置信度
词典验证
fastText 语言识别

根据文中说法，这套机制的目标是在不依赖复杂机器学习模型的前提下，自动识别并过滤低质量乱码内容，以轻量方式阻止劣质文本进入知识库。

摘要

摘要在本文里不是单纯的结果展示功能，而是摄取链路中的增益步骤。它用于为后续检索、浏览和理解提供更高层的压缩表示，但作者也明确意识到摘要调用会带来额外的 LLM 开销。

因此本文记录的工程化做法是：将摘要异步化，借助 ARQ/Redis 后台任务队列处理，避免主解析管道被长耗时的 LLM 请求阻塞。这样做的重点不在“能不能做摘要”，而在“如何在批处理和生产环境里不拖垮主流程”。

交叉引用保留

本文把交叉引用解析视为保持文档理解完整性的重要能力。示例包括“参见图3”“下表”等内部引用。

LongParser 在这一环节使用 O(N) 单遍算法，把这类引用直接关联到对应数据块，以保留文档内部关系结构。作者认为，如果摄取阶段丢失了这些引用关系，即使文本本身被成功切分和索引，问答系统对上下文的理解仍会变得残缺。

嵌入与入库

摄取链路并不在解析结束时停止，而是继续进入嵌入与索引阶段。文中的 REST 调用示例展示了先 finalize，再 embed 的流程，其中嵌入请求示例使用了：

provider: huggingface
model: BAAI/bge-base-en-v1.5
vector_db: chroma

配置层面，文中还说明向量数据库可支持 Chroma、FAISS、Qdrant。这里说明本文理解的 RAG文档摄取 并不是狭义“抽文本”，而是包含把结果正式送入向量检索系统的入库阶段。

对话调用

本文进一步把对话调用纳入摄取链路闭环：文档上传、解析、审核完成、嵌入后，可继续创建 chat session 并发起基于文档的问答请求。

这意味着本文把摄取看作从“文件进入系统”一直延伸到“可被问题调用”的准备过程，而非孤立的离线预处理。

为什么摄取环节重要

本文给出的重要性判断非常具体，不是抽象地说“前处理很重要”，而是明确指出不同环节失误会如何破坏整个 RAG 系统：

低质量 OCR 乱码会污染向量库，使错误文本被嵌入并长期影响召回。
错误分块会破坏语义完整性，让本该一起召回的信息被拆散。
缺少脱敏会直接带来合规风险，尤其在金融、医疗等场景更敏感。
丢失交叉引用与内部关系，会损害对文档整体结构和上下文的理解完整性。

换言之，摄取阶段决定了知识对象的“可用性上限”。后面的检索器、向量数据库和生成模型只能处理已经进入系统的数据质量，无法凭空修复源头结构错误。

工程化设计

本文并不只谈概念，还给出了生产化链路设计。核心工程点包括：