企业官网建设流程全解析

能处理任意文件类型的RAG系统，这个需求听起来很诱人，但实际上手跟纯文本RAG完全是两码事。我最近刚好把一个文档问答系统从纯文本升级成了多模态RAG，过程中踩了无数坑，也总结出了一套可以复现的流程。这篇就来聊聊怎么落地，以及哪些地方容易翻车。

先说清楚这套系统的目标：输入可以是PDF、Word、PPT、扫描件、图片、甚至音视频转录文本，输出是带依据的自然语言答案。它不是简单地把OCR结果拼到一起，而是要让AI真正“看懂”文件里的版面、表格、图表和图片，再基于这些内容做检索和问答。

提示：文中的实现思路以企业知识库问答为背景，如果你只是做个人笔记检索，方案可以更轻量。所有实际项目名称和机构均做脱敏处理。

1. 问题拆解：为什么纯文本RAG救不了“任意文件”

1.1 纯文本RAG的隐藏天花板

很多团队一上来就拍脑袋说“我们用RAG”，结果上线后发现，用户上传的文件一多，检索质量就崩了。原因很简单：纯文本RAG只在“文字的世界”里工作，一旦遇到扫描件、图片、表格、流程图，信息就丢了。

我接手过一个企业合同问答项目，客户丢过来一批几十年前的扫描版合同，纯文本提取出来全是乱码，别说问答，连搜索都搜不到。还有一类文件更隐蔽：PPT里的信息经常是“图表+少量文字”的组合，文字提取出来了，图表里的结论却被丢弃了，答案自然不完整。

问题本质在于：非文本信息在传统RAG流程中被粗暴地“截断”了。纯文本RAG假设一切知识都可以用线性文本表达，但现实世界的文档是二维的、结构化的、多模态的。表格的列对齐、图表的坐标轴、流程图的关系、照片里的物体——这些都不该在检索前被扔掉。

1.2 多模态RAG的两条实现路线

业内说的多模态RAG，其实有两条完全不同的路线：

• 路线一：先文本化，再做标准RAG。也就是用OCR、版面分析、表格结构识别等手段，把图片、扫描件、复杂版面“翻译”成结构化的文本Markdown/HTML，然后再走经典的切块—嵌入—召回—生成流程。这条路技术成熟、效果可控、对推理成本友好。

• 路线二：原生多模态检索。文件不强行文本化，而是把图片切片、图文块、甚至音视频片段，统一嵌入到向量空间。查询时用多模态向量召回图片块，最后把图像和文本一起喂给多模态大模型。这条路更“重”，但对公式、草图、工程图这种无法完好文本化的内容非常有效。

两条路不是对立的，实际系统中通常混用。我的建议是：能用文本化的尽量用文本化，因为文本检索的精度、可控性和引用溯源都更成熟；文本化救不了的那部分，再走原生多模态检索。

1.3 多模态RAG适用的典型场景

并不是所有项目都需要多模态RAG。我总结了几个适用信号：

• 知识库里有大量扫描件、老照片、手写批注，OCR是刚需。
• 文档里表格密度高，表格的结构信息在问答中必须保留。
• 需要对“图里的信息”做问答，比如设备故障照片、数据图表、设计图纸。
• 文件类型杂，有PDF、Word、PPT、邮件、录音转写稿，来源无法统一。

如果只是处理干净的文字版PDF和Markdown，老老实实做纯文本RAG就行，没必要加多模态，成本和复杂度都会上去。这个判断往往比技术选型本身更重要。

2. 整体架构设计：从“解析—切块—检索—生成”到“5层流水线”

2.1 标准流水线的五层设计

我的多模态RAG整体架构，是在经典RAG四层流水线基础上塞了一层“版面理解”，变成了五层：

1. 文件解析层：拆解成文本、图、表、版式结构。
2. 内容结构层：把解析结果重排成带层级结构的数据单元。
3. 索引构建层：文本切块向量化，图片做图文描述/视觉切块，混合索引。
4. 检索层：多路召回加粗排加精排，必要时跨模态检索。
5. 生成层：上下文填充原始图文块，交由大模型生成有依据的答案。

2.2 一个贯穿全文的具体项目背景

为了聊起来不飘，我后面都用同一个例子：一个售后服务知识库问答系统。语料包含设备说明书PDF、维修工单截图、故障照片、老师傅口述整理出的录音转写稿。用户问的问题包括“这台设备的第三块板卡故障代码E02是什么意思”“图里这个磨损程度需要换件吗”。这套系统是最典型的“任意文件类型”场景，每一步决策都直接关系到答案质量。

2.3 架构落地的关键取舍

架构设计里最关键的取舍是：到底要不要做一个统一的文件解析中间层。我的答案是必须要。如果没有统一中间层，来一种文件就写一种解析代码，最后代码会变成一堆if-else，维护成本极高。

我用一个统一的数据结构来表达所有文件解析结果，类似这样：

每个文件最终被解析成一个结构化文档对象，包含：

• 页面元信息（页码、方向、版面坐标）
• 文本块（带层级结构：标题、正文、列表）
• 表格对象（行列结构，而非纯文本串）
• 图片对象（裁剪出的图片块，含坐标和上下文）
• 关系信息（图属于哪一节文字、表格的表头是什么）

这种结构的好处是：检索的时候可以精确到某个表格的第几行、某张图片的某个区域，而不是整篇文档的“模糊记忆”。后面所有模块都依赖这一层，它做得越扎实，检索质量上限就越高。

我在项目中把这个中间层称为“全息文档对象”，其实核心就是“保留一切可用的结构信息，不为了向量化提前丢失信息”。这一步想清楚了，多模态RAG才不会变成增强版OCR。

3. 文件解析层的落地细节：解析器的选型与翻车记录

3.1 不同文件类型的解析策略

文件解析这一步，没有银弹。我用的组合策略是：

• 原生文本型PDF（有文本层）：用PDF解析库直接提取文本块和位置信息，速度快，保留坐标。
• 扫描型PDF和图片：走OCR管道，文字识别之外还要做版面分析。
• Word/PPT：按文档结构做解包，优先拿段落层级和表格，而不是纯文本提取。
• 表格密集文档：用专门的表格结构识别模型或工具，输出HTML或Markdown表格。
• 音视频：先转录音文本，再按说话人和时间戳切块，音频里的语气词可以删掉，但停顿和主题转折要保留。

3.2 一张实战对比表：解析器选型参考

3.3 我踩过的三个解析大坑

坑一：双栏PDF的阅读顺序完全错乱。

一份学术论文PDF，双栏排版，直接文本提取后顺序是“左栏一段-右栏一段-左栏剩下-右栏剩下”。切块后语义全乱，检索到的片段文不对题。后来我加了版面分析模型来还原阅读顺序，问题才解决。

坑二：表格被切块切成碎片。

表头在第一块文本里，表体在第二块，问答时模型看不清表格的全貌，经常答错。解决思路是表格对象必须整体保留，不参与普通切块逻辑，而是作为独立结构单元进入索引。

坑三：手写批注盖在打印文字上。

有些老资料上有大量手写批注，OCR会把两者混在一起，识别结果惨不忍睹。后来用实例分割区分手写和印刷体，再分别识别，准确率提高了很多。

3.4 解析层的质量验收方法

解析做得好不好，不能等人提问后才发现。我固定做三步验收：

1. 可视化检查：把解析出的版面框画在原图上，肉眼比对是否有缺失或覆盖错误。
2. 文本顺序抽查：随机抽文档，人工核对阅读顺序是否正确。
3. 表格还原测试：对同一张表格跑多个解析器，对比结构与内容一致性。

4. 内容结构与索引构建：把“看懂”变成“可检索”

4.1 结构化后的数据单元设计

解析完成只是开始。接下来要把解析结果组织成RAG能用的单元。我的组织原则是“粒度比传统RAG更粗一点，层级更明确一点”。

传统的文本RAG倾向于小切块（200-500字），多模态RAG则倾向于结构化单元：一个章节、一个完整表格、一张带说明的图片。小块文本很容易丢失上下文，而结构化单元自带语义边界。当然，章节约等于一个超大文本块也会超出向量模型的上限，所以我按“语义完备性”来切，而不是按字数切。

4.2 多模态索引的三种实现路径

模型选择上，有三种常见路径：

• 路径A：文本描述代替图片嵌入。用多模态模型给图片生成详细描述（caption），然后只索引文本描述。成本最低，但对描述质量的依赖极高，描述漏了什么，检索就漏什么。
• 路径B：图片与文本统一嵌入空间。直接把图片块裁剪出来，喂给多模态嵌入模型，生成与文本对齐的向量。这样图片本身可被检索，不必依赖描述。效果好但模型成本高，且需要图文对齐训练。
• 路径C：混合索引。图片既做文本描述，又保留原图块做向量索引，同时实现按描述检索和按视觉相似度检索。

我的项目最后用路径C。代价是要维护两套索引，但召回效果明显好于单路索引。

实测数据：在同一批带公式的文档上，路径B的图文检索召回率比路径A高约20%，但单次嵌入成本也翻了一倍多。如果预算有限，可以先跑路径A，把图描述写详细，再用“描述+原图”双路召回弥补。

4.3 向量库和混合检索的选择

向量库只是工具，关键是检索策略。我用的方案是：

• 同时建两个索引：向量索引用于语义召回，关键词索引用于精确匹配。
• 召回阶段多路并行：向量召回TopK，关键词召回TopK，表格路径再单独召回TopK。
• 融合阶段用加权融合，结合文档类型标签做权重调整。比如用户问的是“图中”开头的，图片召回路线的权重自动提高。
• 最后接一个重排序模型，减小精排结果的数量，再交给大模型生成答案。

关键词召回在混合检索里经常被人忽视，但多模态场景里反而是救命的。比如设备型号“E02”这种精确代码，语义检索往往找不到，关键词检索一抓一个准。

4.4 表格和图片块的特殊处理

表格和图片在多模态RAG里是最特别的两类单元，传统文本切块根本处理不了。

• 表格：转换成HTML或Markdown后，整表作为一个索引单元。查询时会先走出一个“是否命中表头”的粗排判断，命中后再整表塞给大模型。这样做表格问答的准确率才过得去。
• 图片：围绕图片块写上下文描述，说清楚“这张图在文档的哪个位置、它解释了什么问题”。图片本身裁剪后进入图像向量库，描述进入文本索引。这样既能用图搜图，又能用问题搜图。

4.5 查询改写：多模态场景的隐藏环节

多模态RAG不能忽略查询改写。用户的原始问题常常是“这个怎么解决”“这坏了没”，而这种问题没有指代对象，检索器无法召回任何东西。

我会在检索前加一步查询解析：如果问题提到“图”“这个”“那台”等指代词，就自动向前补全对话上下文或文档标题，生成一个“带指代消解的检索查询”。这一步看起来小，但对多模态问答体验的提升非常明显。

5. 生成层的优化：把多模态证据喂给大模型的正确姿势

5.1 上下文拼装的三种策略

检索再准，如果生成层不会用这些多模态碎片，答案依然稀烂。我在生成层做了三件事：

• 文本上下文：以Markdown块的形式拼装，保留标题层级和列表，让模型理解文档结构。
• 表格上下文：直接把整张HTML表格塞进上下文，模型能看清行列对应关系。实测中Markdown表格的推理能力不如HTML，因为HTML保留了跨行跨列的信息。
• 图片上下文：如果检索命中了图片块，就把图片本身的图像token直接喂给多模态大模型，而不是只喂描述文本。

5.2 少放多放之间的平衡

多模态上下文很占Token，尤其是图片。一张高分辨率图片的视觉token可能高达上千，如果一次拼5张图，推理直接崩溃。我最后的妥协方案是：正文最多3张图，表格最多2张，超过的部分只放文本描述和坐标信息。宁可缩小候选集，也不要让上下文爆掉。

另外，检索回来的证据必须带来源。每个单元都带文档名、页码、段落坐标。生成时要求模型在答案末尾给出引用标记，我这边再校验引用证据是否真的包含在上下文中。这一步能过滤掉不少“编造”答案的情况。

5.3 生成层最容易犯的错：让模型读一堆无关图片

有一个反直觉的坑：把图片和文本一起塞给多模态模型时，模型会对无关图片“强行联想”。比如上下文里放了一张设备外观图，用户问的是电路板故障代码，模型会盯着外观图硬编出一个答案。解决方法是：

• 明确告诉模型优先使用表格和故障代码信息，图片仅作辅助判断。
• 给每张图配一句限制说明：“这张图展示的是外观，不包含故障代码信息。”让模型不必强行用图回答。

这个技巧来自一次很惨的A/B测试：不加限制时模型硬看图乱答，加了限制后正确率提升了将近十个百分点。上下文里给模型“哪些证据不要用”，跟“哪些证据要用”一样关键。

6. 常见问题与排查技巧实录

6.1 六个高频问题和解决套路

6.2 一个棘手的检修案例

有一套系统，上线后用户反馈“检索不到故障照片”。排查过程：

1. 先看解析层：发现维修工单截图被当成了普通图片，没有做文字识别，照片里的型号信息全丢了。
2. 查索引：图片描述是“维修工单截图”，完全没有型号和故障词。
3. 结论：问题出在描述生成策略，而不是检索模型。

最后调整了图片描述模板，要求描述里必须包含图片中的可见文字、型号、编号，问题瞬间消失。这个案例的启示是：多模态RAG的质量瓶颈往往不在模型，而在前处理流程里“丢了什么信息”。排查时优先看解析和索引，而不是先换模型调参。

6.3 几点经验总结

做完整套多模态RAG后，我个人的体会是：

• 多模态RAG成功的核心不是“多模态大模型选得多好”，而是“文件解析和结构化的工程质量”撑不撑得住。
• 切块粒度、索引方案、检索策略是一套系统工程，只换一个环节的模型解决不了整体问题。
• 用路线的选择要克制：能文本化的就文本化，原生多模态检索只救那些文本化救不了的部分。
• 预算有限时，先用文本描述方案跑通全流程，再逐步升级成原生多模态索引。不要一上来就上全套重方案。

6.4 后续还想继续做的扩展

这套流程跑通后，我还有两个想继续深挖的方向：

一是“版面感知的重排器”，让重排序阶段直接参考图片块的视觉特征，而不是只看文本相似度。这会进一步提升跨模态检索的精度。

二是“流式文档解析”，让RAG系统能处理持续追加的会议录音和实时视频流。这类场景对分块策略和增量索引要求更高，我的五层流水线框架应该能直接复用，但每个模块都需要重新打磨。

做这个项目的最大感受是：很多团队在讨论RAG时都把精力花在了向量模型和参数上，但真正的硬骨头是“文件理解和结构保留”。把这一层做扎实，后面的RAG才不是空中楼阁。