多格式文档 RAG：构建跨 PDF、Word、Excel 和音频的检索管道

大多数 RAG 教程从单一文件类型开始。加载一个 PDF，将其分成块，生成嵌入，然后查询。演示可以运行。然后有人问："它也能搜索我们的 Excel 定价表、录制的客户电话和上个季度的 PowerPoint 演示文稿吗？"答案通常是沉默。

企业知识不存在于单一格式中。它分散在 PDF、Word 文档、电子表格、演示文稿、HTML 导出、白板图片和会议音频录音中。一个通过单一检索路径处理所有这些来源的多格式文档 RAG 管道不是锦上添花——它是任何声称代表组织实际知识的系统的先决条件。

为什么单格式管道在实践中会失败

单格式管道的吸引力在于简单性。仅 PDF 的摄取是被充分理解的、有良好文档记录的，且相对容易构建。但一旦部署，其局限性就变得显而易见。

考虑一个典型的企业场景。产品团队将规格存储在 Word 文档中。财务部门在 Excel 中维护定价模型。法务部门将合同保存为扫描的 PDF。销售团队录制客户电话。市场部门发布 HTML 通讯。一个只摄取 PDF 的单格式 RAG 管道将完全错过规格、定价、通话记录和营销内容。检索系统从知识库的一小部分中回答问题，用户学会不再信任它。

问题随着时间的推移而加剧。知道自己的内容被排除在外的团队停止向知识系统贡献。管道变成了一个 PDF 搜索引擎而不是组织记忆。从一开始就构建处理所有格式的文档到 RAG 管道可以避免这种失败模式。

特定格式的挑战

每种文档格式都提出了不同的提取挑战。在设计统一管道之前，理解这些挑战至关重要。

PDF：具有欺骗性的标准

PDF 看起来简单，但架构上很复杂。数字原生的 PDF 包含可提取的文本层，但扫描的 PDF 本质上是包装在容器中的图像。从 PDF 中提取表格仍然是文档 AI 中最困难的问题之一——列错位、标题跨多行、脚注中断数据区域。多列布局、嵌入式图表和混合方向页面增加了更多复杂性。一个健壮的 PDF 解析器必须处理所有这些变体，而无需针对每个文档进行手动配置。

Word 文档：没有一致性的结构

DOCX 文件携带丰富的结构化元数据——标题、列表、表格、脚注、评论、修订跟踪。挑战在于作者使用这些功能的方式不一致。一个团队使用标题 2 作为章节标题。另一个使用粗体正文文本。第三个使用手动换行而不是段落样式。解析器必须即使在格式不规范时也能提取语义结构，并且必须决定修订跟踪和评论是规范内容的一部分还是噪音。

电子表格：伪装成文档的数据

Excel 和 CSV 文件处于结构化和非结构化数据的边界。一个带有列标题和类型化值的干净电子表格本质上是一个数据库表。但企业电子表格很少看起来是那样的。它们包含合并的单元格、嵌入的备注、多工作表工作簿（其中工作表 3 引用工作表 1）、数据透视表以及某人在单个单元格中输入了三个段落的自由文本列。用于 Word、Excel、PDF 和电子表格内容的 RAG 管道必须处理这些文件的表格和叙事两个方面。

演示文稿：视觉知识

PowerPoint 演示文稿以视觉方式编码知识——在幻灯片标题、要点、演讲者备注和嵌入式图表中。文本在设计上是碎片化的。一个概念可能跨越三张幻灯片，每张有五个要点。适用于散文文档的分块策略在这里会失败，因为演示文稿中的意义单位是幻灯片或幻灯片组，而不是段落。

音频：未被索引的档案

会议录音、客户电话和会议演讲包含大量从未被书面记录的机构知识。摄取音频需要转录作为第一步，但挑战超出了语音转文本的准确性。说话人分离（识别谁说了什么）、时间戳对齐以及处理特定领域术语都会影响检索质量。多格式文档 RAG 管道必须将音频视为一等来源，而不是事后考虑。

HTML 和图像

来自内部 wiki、知识库和导出邮件的 HTML 页面有其自身的特点——用于布局的嵌套表格、遮蔽语义含义的内联样式以及必须去除的模板导航。白板图片、图表和手写笔记需要 OCR 或视觉模型来提取任何文本。

在单一管道中统一格式

关键的架构洞察是，特定格式的解析是摄取层的关注点，而不是管道的关注点。每种格式需要自己的解析器，但一旦内容被提取，每个文档——无论其原始格式如何——都进入相同的处理路径。

一个设计良好的多格式管道遵循四个阶段：

清洗 — 原始提取输出被规范化。字符编码问题被解决，样板内容被移除，来自源格式的格式化伪影被去除。输出是保留了结构标记的干净文本。

转换 — 清洗后的内容被分块、用元数据丰富并生成嵌入。分块策略可能因源类型略有不同（演示文稿按幻灯片级别、电子表格按行组级别、文档按段落级别），但嵌入和索引过程是相同的。

集成 — 分块被加载到向量存储中，并链接回其源文档。元数据包括原始格式、源位置、提取时间戳以及任何结构上下文（页码、工作表名称、幻灯片索引、说话人标签）。

服务 — 单一检索接口跨所有来源进行查询。用户提出问题，获得从 PDF、电子表格、转录和演示文稿中提取的答案——按相关性而非格式排序。

这种四阶段架构——清洗、转换、集成、服务——意味着添加新格式只需要在摄取层编写新的解析器。管道的其余部分保持不变。

可视化管道的优势

在代码中配置多格式管道是可能的，但容易出错。每个解析器都有自己的参数（PDF 的 OCR 设置、Excel 的工作表选择、音频的转录模型），解析、分块和嵌入之间的交互在配置文件中难以推理。

管道阶段以节点表示的可视化画布提供了一种根本不同的工作流程。你可以看到多个摄取节点——每种格式一个——汇聚到共享的清洗、转换和索引节点。数据流是显式的。当出现问题时，你可以从特定的源格式追踪路径，通过每个处理阶段来了解故障发生在哪里。

Ertas 支持八种解析器——PDF、Word、PowerPoint、Excel/CSV、HTML、图像和音频——所有这些都通过可视化画布馈入同一管道。每个解析器作为一个独立的摄取节点出现，但下游处理是共享的。这意味着团队可以从 PDF 摄取开始，验证检索有效，然后在不重建任何内容的情况下添加 Excel 和音频来源。

实际考虑

为 Word、Excel、PDF 和其他格式构建 RAG 管道会提出几个值得尽早解决的实际问题。

分块大小一致性。 不同格式产生长度差异很大的分块。一个电子表格行可能是 20 个 token。一个 PDF 页面可能是 800 个。跨格式规范化分块大小可以提高嵌入质量和检索公平性——否则长文档格式仅仅因为每个分块产生更多文本就会主导搜索结果。

用于来源追溯的元数据。 用户需要知道答案来自哪里。"第三季度报告第 14 页"是有用的。"分块 847"则不是。在整个管道中保留特定格式的位置元数据（页面、工作表、幻灯片、时间戳）对于信任至关重要。

增量更新。 企业文档存储库不断变化。管道必须支持重新摄取更新的文档，而无需重新处理整个语料库。这需要跟踪文档版本，并且只处理增量部分。

访问控制。 并非每个用户都应该看到每个文档。格式感知的元数据使得在检索时应用源级别权限成为可能，确保 RAG 系统遵守与原始文档存储相同的访问规则。

结论

多格式文档 RAG 管道不是一个奢侈功能——它是企业检索的最小可行架构。从单格式管道开始的组织不可避免地面临同样的问题：系统了解 PDF 但对其他所有内容都视而不见。通过从一开始就为多种格式进行设计，让特定格式的解析器馈入共享的处理路径，团队构建的检索系统能够真正代表组织所知道的。替代方案是一个只能看到一小部分答案的搜索引擎。