企业官网建设流程全解析

多模态 RAG 不是把 PDF 扫描成纯文本再丢给大模型那么简单的，这句话说出来可能会让很多刚上手的人不太服气：我明明做了 OCR，图片里的文字不也能查到了吗？问题是，当用户问的问题需要“看图”才能回答时，纯文本检索体系完全没有可用线索，比如“这张表格第 3 列展示的是哪几个区域的销量趋势”“这张宣传海报的主视觉表达了什么”，如果检索阶段把图片丢掉了，后面生成阶段再强大也无济于事。

这篇文章想聊的，是我在实际做“多模态 RAG”——也就是让检索增强生成系统真正能吃下图片、PDF、PPT、扫描件、报表、甚至音视频——时的完整思路和踩坑过程。目标很明确：搭建一套能处理多种文件类型、并且在回答问题时真正利用视觉信息的检索引擎，而不只是在文档上套一层好看的壳。

无论你是刚接触 RAG 的初学者，还是已经搭过一套基础检索服务、想升级多模态能力的从业者，这篇内容都会尽量避开教科书式的空洞理论，把解析、分块、嵌入、检索、重排这些环节拆开说清楚，包括代码层面的骨架、工具选择的取舍，以及我在实测中反复调整过的细节。

1. 先把“模态”这件事掰开揉碎看透

很多团队做一个文件问答系统，往往第一版长这样：上传 PDF，调用现成的解析工具转出文字，按固定长度切片，用文本嵌入模型向量化，存进向量库，用户提问后走相似度过检索引擎。这个方案跑通后，大家会发现两个很明显的问题：一是带版式的资料体验很差，摘要、表格、图表信息经常答错；二是如果文档里直接存在“截图类答案”，系统基本无解。

问题的根源不在检索链路，而在大家对“多模态”三个字的理解。咱们先把概念说清楚再谈实现。

1.1 模态的粒度跨越了文件类型本身

我一开始也以为多模态就是给每个文件类型准备一个解析插件，然后把得到的一堆文本混合进同一个索引里去。后来发现这个想法很粗糙。一套真正合理的多模态系统，拿到手里的文件类型其实都会归一化到三种模态层次上：

• 文字信息模态：包括文本段落、表格的描述文字、图片解读后的自然语言、转写后的语音内容。它最终以 token 或向量形式被检索。
• 视觉信息模态：包括图片本身、PDF 中的插图元素、扫描件的版面结构、PPT 里的图形关系。它不能简单压缩成一段描述文字，因为很多信息在细节像素里。
• 结构化信息模态：表格的行列关系、键值对、文档层级（标题/子标题）、代码块等。它不能被当成普通散文切片，一旦切成碎片就丢掉了结构语义。

如果只把“模态”理解成文件后缀，就会陷入一种错误做法：图片走 OCR 得到文字，PDF 走文本提取得到文字，音频走语音识别得到文字。到头来索引里全是文字，视觉信息和结构信息全部蒸发。这种系统在演示时能把文字段落问题答得不错，但碰到答案藏在一张数据折线图里，或者需要对比两张图的差异时，就只能开始一本正经地胡说八道。

1.2 两类典型流程的对比：文本盲区与视觉通路

我可以用一个具体的小实验来说明这种差异。同样一份市场调研报告，里面有一页是“竞品分析矩阵”，本质是一张二维散点图，散点上面标注了产品名和关键方向。传统流程会把这页用 OCR 转出全部文字，然后存进检索库。用户问“哪个竞品在性价比维度上最有优势”，系统检索到的文本里没有这句话，嵌入相似度可能匹配到“竞品分析”几个词，于是把整段文字交给模型，模型只能根据转出来的零散描述硬猜。

另一种做法是预处理阶段检测出这张图片，把它作为视觉块单独保留，并且生成一段高质量的图像描述（caption），同时对图片本身做视觉嵌入。查询时，问题文本和图像描述都在同一向量空间里，相似度能直接把它们对到一起，随后回答阶段可以真正让视觉模型去看原图，回答“最有优势的竞品”时就有依据了，甚至可以贴出原图框出对应区域。

这两种流程的区别，看起来只是多存了一张图，但检索的语义覆盖范围完全不同。所谓“处理任何文件类型”，核心不是解析文件的后缀，而是确保文件里任何有信息量的区块，都至少有一条可检索的路径，最好是有文本、视觉两条路径互为备份。

2. 从任意文件到统一语义块：解析和分块的细节设计

确定了“要保留视觉与结构”的方向之后，下一步就是设计管线。我的建议是不要为每个文件类型单写一套从解析到嵌入的流程，而是设计一个统一的文档中间结构，再针对不同类型的文件写各自的解析器，统一输出中间结构。

这个中间结构我起名叫“语义块”，它比普通文本切片更复杂，但也没到对象存储级别那么重。它有统一的字段：块 ID、块类型、文本内容、原始媒体引用路径、所属页面、版面位置框、上下文父级 ID、元数据字典。有了这个结构，后面无论是做向量索引、过滤检索、还是给大模型拼上下文，都有了统一的操作对象。

2.1 文件解析器设计：让每个文件类型都“说实话”

对不同的文件类型，解析策略要做区分，不能一把 OCR 走天下。我实测下来比较稳定的划分方式如下：

这里特别要说明一种常见误解：OCR 只是从图像里找文字，并不是万能的。现在许多开源 OCR 工具对印刷体的识别度已经不错，但遇到手写、公式、倾斜拍摄、复杂表格线都会出错。即便识别对了，也会丢失文本在版面中的相对位置关系，尤其双栏论文，OCR 会把左右两栏的文字按阅读顺序交错输出，这是回答错误的重灾区。所以如今只要预算和时间允许，更好的选择是用视觉语言模型直接让模型看整页图像，输出结构化的 Markdown 表示。它能同时感知版面结构、表格行列关系、图像位置，相当于把“看懂版面”这个任务直接交给模型处理。

2.2 分块策略：版面感知永远大于固定字数

很多教程还在教“每 512 个 token 切一块”，这种固定切法会让表格被拦腰截断，也会让一个标题和它的正文被分到不同块里。我用下来比较靠谱的是按语义边界分，再配合“父子块”机制。具体来说：

• 对文本块，按照标题层级切分：一级标题下的所有段落作为一个超块，二级标题下的内容作为一个子块。如果一段文字特别长，再按句子边界或段落边界细分，保证单块不超过 1000 token。
• 对表格块，绝不切碎行列，而是把整个表格转化成一种紧凑的统一中间格式，比如 CSV 或 Markdown 表格，作为一个独立块。行数特别多的表，按业务维度拆分，比如按季度、按品类拆成几个逻辑子表，保持每个块仍是一个完整表格。
• 对图片块，不直接嵌入原始图像的像素级向量作为唯一载体的同时，我会生成一段结构化描述字段，描述内容包含图片类型、主视觉元素、文字呈现、数据趋势、结论判断。这一步可以由视觉模型完成，但要注意为图片描述生成先设计提示词模板：先描述客观呈现，再描述可能含义，最后写相关业务结论。避免模型直接输出“这是一张很有价值的信息图”这种废话。

2.3 多媒体数据：音视频要按时间窗口切，而不是整段转写

音视频文件中，语音转写是整个检索的基础。这里最典型的问题是，有些实现把一段一小时会议的全部转写文本塞进一个块，然后去做向量化。结果用户问“这件事是谁在什么时候决定的”，向量检索可能匹配到大段完全无关的讨论，因为整段文本语义过于混杂。

我会把转写结果按固定时间窗口切块——比如每 30 秒到 60 秒一帧，并且保留时间戳、说话人标签。每个时间窗口独立构建一个文本块，同时窗口前后各加一部分重叠文本，保证句子跨边界时不会断。查询后如果能命中某段时间窗口，就能直接回答“这段内容出现在第几分几秒”，这在实际产品里比什么花哨功能都管用。

3. 嵌入、索引和检索：让图文表格都能被找到

解析和分块只是预处理，真正决定“能不能被找到”的是嵌入模型和检索策略。多模态 RAG 最容易翻车的地方就在这里：如果嵌入模型本身不具备跨模态对齐能力，即使你把图片保存下来了，检索时它还是不会被文本查询命中。

3.1 嵌入模型选型：文本要能对齐图片，表格要能对齐查询

当前比较成熟的选择思路，是使用双塔式的视觉-文本对齐模型，类似业界广泛讨论的 CLIP 思路。这类模型把图片和文本编码到同一高维空间，所以“这页 PPT 里的成本饼图”“这个柱状图展示了三年增长”这类文本查询，能直接和视觉块的向量在余弦相似度上对齐。对于纯文本块，我们可以继续用常规文本嵌入模型，但要注意两个模型向量维度不同，不能直接混在一个索引里做相似度计算。常见的解决方案是：图片和图片描述使用视觉文本对齐模型编码，普通文本块使用文本编码模型编码，两者分属两个向量子索引，检索时并行召回再融合排序，或者将文本块全部用跨模态模型编码，牺牲一点文本语义精度换取统一空间。

我更倾向于前一种“混合双索引”方案，因为它能让你在纯文本任务上继续用语义精度更高的文本嵌入模型，同时视觉任务用跨模态模型，两套检索结果通过融合排序合并。实际的融合方法我后面会讲。

3.2 索引结构设计：子索引 + 元数据过滤 + 父子块还原

多模态场景下，索引结构一定要比单一向量库多两层设计。第一层是“子索引隔离”，文本块、图片描述块、表格块、音视频时间窗口块各进各的集合，至少要在元数据里打上 type 标签。第二层是“层级还原”，也就是父子块机制：检索索引中存的是粒度更小的“子块”，比如一个表格里的某一行、或者一个长文本段落，但每次检索命中后，要把它对应的“父块”整体取出，作为上下文送给生成模型。

这个设计在实战中非常值得投入。举个例子，用户问题“M 系列产品的复购率在哪个季度出现拐点”，子块索引可能精准命中某个季度那一行的内容，但如果只返回这一行文本，生成模型缺少表头和上下文，没法正确解释。借助父块还原，我们取出整个表格，模型就能看到“2023 年 Q1 到 Q4 各产品复购率”的完整行列关系，回答的是整张表，而不只是一个被切碎的文本片段。

3.3 最小可复现的代码骨架

我一般会先用 Python 写一个很薄的索引服务骨架，把所有解析器统一接到这个骨架上。下面这一段只展示核心思路，不是完整生产代码，但它能帮你把上文提到的概念落到结构上。

from dataclasses import dataclass, field from typing import Any @dataclass class SemanticBlock: block_id: str block_type: str # "text" / "table" / "image" / "audio_segment" text_content: str # 文本内容或表格的CSV表示，或图片描述 media_path: str | None # 原图/原音视频的存储路径 page: int | None # 来源页 bbox: tuple | None # 版面坐标，方便定位 parent_id: str | None # 父块ID，用于检索后还原上下文 metadata: dict = field(default_factory=dict) def build_image_block(image_path, layout_box, page_num, vlm_caption, parent_id): return SemanticBlock( block_id=f"img_{image_path}_{page_num}", block_type="image", text_content=vlm_caption, # 用视觉模型生成的描述 media_path=image_path, page=page_num, bbox=layout_box, parent_id=parent_id, metadata={"caption_model": "vlm_caption"} )

检索时的理想路径其实是“三层漏斗”：先用关键词或向量粗召回得到候选块，然后用重排模型对候选块重新排序，最后再根据排序结果取父块上下文，拼装成送给大模型的提示词。粗召回的关键是召回率，宁可多召回也不要漏，重排阶段再精细过滤。如果不做重排，只靠向量相似度排序就直接拼上下文，你会发现检索跑出来的结果经常“看起来相关但不精确”，还要把解析错位的文本漏过去。

关于融合排序，我的做法是先把文本检索结果和视觉检索结果归一化为 0～1 的分数，然后按加权和合并。权重取决于当前查询的类型：如果问题包含“图、表、对比、趋势、界面、海报”这类视觉词，视觉子索引的权重加大；如果问题泛泛而谈，文本子索引权重加大。这个规则不用一开始就做复杂分类模型，手工配置关键词表就够第一版跑了。

4. 三种最典型的翻车场景与完整排查链路

再漂亮的设计，落到真实文档上都会有意外。这里分享三个我实测过程中一度很头疼的问题，以及我当时排查和修通的完整链路，比直接给你一个“完美答案”更有价值。

4.1 表格语义被“拍扁”：索引里有 CSV，但用户根本搜不到

第一次做带表格的文档时，我把表格解析成 CSV 后直接存成文本块，结果测试一个很基础的问题——“华东区第一季度销售额是多少”，向量检索命中的根本不是这个表格，而是一段普通文本里偶然提到华东区的句子。后来我在这个表格块所在页面做了单测，发现嵌入模型检索到表格块的概率其实偏低，尤其是表格里全是数字和产品名时，CSV 语义和自然语言查询之间有明显鸿沟。

排查链路从四步展开：第一步，确认表格块确实进了索引，没有因为格式解析失败被丢弃；第二步，单独用一些表格关键词去检索，比如“销售额”“华东区”，发现仍然召回不到；第三步，检查分块，怀疑是整张表太大，嵌入后被“稀释”了；第四步，尝试把表格块拆成“表级块 + 行级块”，行级块带有表头上下文，又把每行前面加一列“行内摘要描述”，然后用文本嵌入重新测试。

修通后，检索命中率明显上来了。关键点是：纯 CSV 的语义对通用嵌入模型来说太“冷”，数字和列名之间的关系模型看不出来。所以必须在每个子块里加入一段自然语言描述，比如“该行数据表示 2024 年华东区第一季度销售额为 500 万元”。这段描述来自解析后的“表头 + 行数据 + 业务字段名”拼接，而不是模型瞎编。

4.2 图文被割裂：图在左、描述在右，索引成了两张皮

另一个让我记忆深刻的案例是处理一版图文混排的培训教材。页面左侧是一张架构图，右侧是对应说明文字。旧的文本提取器把右侧文字全部抓出来，图片只是作为附件保存。用户问“图里这个模块的输入输出分别是什么”，检索系统找到右侧说明文字，但那段文字没提到“输入输出”，于是回答失败。更要命的是，视觉子索引里虽然存了架构图，但图像描述生成得很弱，只写了“这是一张系统架构图”，无法和提问对齐。

我当时的修复不是简单优化提示词，而是重构了“图文配对”逻辑。解析器在版面分析阶段先识别图片区域，然后向外扩展搜索邻近文本块，判断它们是否构成“图注上下文”。如果存在，就把这些文本块合并成图片的关联文本，和图像描述一起存入图片块。换句话说，图片块里再也不只有视觉模型生成的 caption，还包括它周围的原始文本。这样检索时，无论是文本命中还是视觉命中，都能回到同一块复合上下文。实测这种复合块在回答图文类问题时，要比“图片描述 + 全页文字混合切分”稳定得多。

4.3 解析成功、检索正常，但生成模型还在乱答：缺了“证据回看”

最后一类翻车最隐蔽，系统各项指标看着都正常，回答还是错的。排查后发现不是嵌入问题，而是生成阶段没有让模型真正去看图片。RAG 链路的最后一步应该是把检索出来的图片原图传给一个具备视觉理解能力的模型，让它结合用户问题看图说话，而不是把图片描述文字转交给纯文本模型去编。

我之前见过不少实现，图片块只是存了描述文字，生成阶段并没有把 media_path 传给视觉模型，模型拿到的全是二次转述的信息。这类方案在描述不详细时必炸。修通的方法是让提示词变成结构化的指令包裹，把检索块拆成“文本块列表”和“图片块列表”，视觉模型同时接收问题、文本证据和图片路径，而不是把所有东西硬塞成一个 prompt。

5. 成本、性能与后续迭代方向

处理多模态文件的成本，很多人是低估的。我实测的过程里，最容易超预算的是两个地方：解析阶段对所有页面全部无差别调用视觉模型，以及检索阶段未做任何缓存导致重复计算嵌入向量。

在成本控制上，我有一个应急策略：先做“轻量解析”，用开源 OCR 和版面分析模型做第一轮，只有遇到重排模型觉得文本不足的页面（比如图表页、扫描不清的页面），才升级调用视觉语言模型做深度解析。这样大部分普通页成本很低，难点页面集中力量处理。如果预算更紧张，可以再做一个简单启发式规则：版面检测输出中图片区域面积超过页面的 30%，或者检测到数据图标记，就触发视觉模型描述，否则跳过。

性能方面的瓶颈往往不在向量检索，而在“父块还原”之后的上下文过长。一次检索经常召回 10 个候选，其中 5 个父块都很长，加上图像路径和表格 CSV，提示词可能塞进几千 token 甚至更多。我会在拼装前先做两件事：按重排分数截断到 3～5 个块，以及根据用户问题的主题关键词做一次简单的硬过滤，比如问题明显在问成本，就把类型为“table”的块优先保留，类型为“audio_segment”的画面块全部丢掉。

这套系统后续值得迭代的方向有两个。一是引入更重的“查询改写与假设生成”机制，先让模型根据问题生成一个假设答案或若干关键词，再用假设答案去检索，能显著提跨模态检索的效果，特别是问题描述得不够具体时。二是引入一个基于排序模型的评测集，把几十个典型图文检索问题固定下来，每次改解析器或嵌入模型都跑一遍回归，防止改了这边、漏了那边。我吃过这个亏——某一次升级嵌入模型后文本检索效果提升了，但视觉子索引因为向量维度不一致没有同步升级，无声无息地失效了一周，直到评测集跑出红色指标才发现。

6. 最后再分享两个很实用的工程经验

如果你现在正准备启动自己的多模态 RAG 项目，我建议先不要急着把所有文件类型一次性支持。挑一种你最常遇到的复杂格式，比如带图表的 PDF 或扫描版合同，把从解析到视觉回答的整个链路跑通，再横向扩展其他文件类型。先保证一条链路的每个环节都是闭环的，比铺一个庞大的功能矩阵可靠得多。

另外一个小细节可能很多人不会注意：图像描述生成时，会意外触发视觉模型把图片里没有的内容也写进描述里，比如默认补全了品牌名或数字。我后来在描述生成提示词里明确加了一条“只能描述图中客观可见的信息，禁止推测图中不存在的数据”，并且让描述分“客观可见字段”和“推测语义字段”两部分输出。这样一旦模型在猜测，至少检索时不会把臆造内容当成证据。这一步花不了多少时间，但对最终回答的准确性帮助极大。

多模态 RAG 做到最后，最大的体会是：它不是一个“模型”或“算法”层面的挑战，而是一个系统工程挑战。解析谁来做、检索怎么融合、上下文怎么拼、成本怎么控，每一环都需要根据你手里的真实文档反复调。只要把“保留原始视觉证据 + 建立跨模态检索通路 + 生成阶段回看原图”这条主线握住，文件类型再怎么变化，系统的地基都不会歪。