> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 多模态RAG：双VLM架构
- URL: https://www.hubwiz.com/blog/multimodal-rag-dual-vlm-architecture/
- Published: 2026-04-19T10:29:17.000Z
- Updated: 2026-04-19T10:29:17.000Z
- Description: 我最终构建的系统在流水线的两个不同阶段使用两个独立的视觉语言模型（VLM）。一个轻量级VLM在摄取期间生成摘要，用于索引和检索。
- Author: admin
- Tags: RAG, #Import 2026-10-14 14:41

构建多模态RAG系统的标准建议是：获取你的PDF，提取图像，通过视觉模型运行它们，将摘要存储为文本块，然后继续。每张图像只有一次被理解的机会，而这种理解发生在任何用户问题被提出之前。

这在大多数情况下可以正常工作，直到它不行了。在生产环境中，它恰恰在最关键的时候失效。

我花了几天时间构建一个用于大型金融文档分析的多模态RAG系统。数百页，密集的表格、组织架构图、流程图、趋势图。在这种文档中，一张图像可能包含15个完全不同问题的答案，而一个通用摘要最多只能捕捉到两个。

我最终构建的系统在流水线的两个不同阶段使用两个独立的视觉语言模型（VLM）。一个轻量级VLM在摄取期间生成摘要，用于索引和检索。一个更强大的VLM在检索时带着用户的问题重新阅读实际图像，精确提取重要的信息。VLM的输出随后作为文本注入到与所有文本和表格块相同的上下文窗口中，因此一个文本LLM可以在掌握完整信息的情况下做出最终答案。

本文将介绍为什么存在这种模式、它在架构上如何工作、权衡取舍是什么，以及它在哪里真正发挥作用。

## 1、摄取时图像摘要的问题

让我给你一个具体的例子。想象一家大公司的年报，第12页有一个组织架构图。CEO在最顶端，通过汇报线连接到各个部门负责人，每个负责人下面有团队和子团队。

在摄取过程中，VLM查看这张图并产生类似这样的内容：

> *"组织架构图显示CEO在最顶端，与几位部门负责人有汇报线，包括工程副总裁、销售副总裁、运营副总裁、首席财务官。每个部门下面有团队和子团队。"*

这是一个完全合理的摘要。它捕捉了视觉类型、主要实体和总体结构。如果有人问"公司有哪些部门？"或"第12页是什么类型的图表？"，它会很有帮助。

但现在考虑这些问题：

- "哪些团队直接向工程副总裁汇报？"
- "CFO是否对任何运营相关的团队有监督权？"
- "追踪数据平台团队到CEO的汇报路径。"

摄取摘要无法回答这些中的任何一个。它提到了工程副总裁的名字但没有列出其下属。它根本没有提到数据平台团队。摘要太高层了，因为在摄取时，无法知道哪些具体的连接和实体会重要。

这是根本问题：**摄取时摘要与问题无关，但好的答案需要针对具体问题。**

同样的问题出现在以图像形式渲染的金融表格、带有数据点的趋势图、流程图，以及基本上任何信息密度超过单个通用提示所能合理提取的视觉元素中。

## 2、标准方法及其不足之处

多模态RAG领域发展很快。ColPali、VisRAG和类似方法将文档页面视为图像，直接使用视觉语言模型嵌入它们，完全跳过文本提取。这些在检索方面令人兴奋，但它们仍然需要VLM从检索到的页面图像中生成最终答案。

对于文档密集型企业RAG系统，格局大致分为三种模式：

**模式一：摄取时文本化。** 在摄取期间将所有内容转换为文本。图像变成摘要，表格变成markdown，图表变成描述。整个索引都是文本。这是NVIDIA推荐的多模态RAG"架构骨架"方法，也是经过最多生产验证的模式。缺点是我上面描述的信息丢失。你把2D视觉结构压缩成1D文本描述，而且只有一次机会决定什么重要。

**模式二：多模态嵌入。** 使用`voyage-multimodal-3`或基于CLIP的嵌入等模型将图像和文本编码到相同的向量空间。在检索时，文本查询可以直接匹配图像嵌入。这解决了检索问题，但你仍然需要在生成时实际阅读图像，而且大多数实现只是将原始图像传递给生成器，而不进行问题感知的提取。

**模式三：页面级VLM生成。** 通过ColPali或类似方法检索相关页面图像，然后直接将页面图像提供给大型VLM生成答案。这保留了所有视觉信息，但在推理时很昂贵（你对每个问题都要将完整页面图像通过VLM），并且需要VLM能够同时推理多个页面。

我发现缺少的是一种将文本化的效率与问题感知图像阅读的准确性相结合的模式。这就是双VLM方法填补的空白。

## 3、双VLM架构

核心思想很简单：在两个不同阶段使用两个VLM，执行两个不同的工作。

### VLM #1：摄取摘要器

在摄取期间，一个更小、更快的VLM查看每张提取的图像并生成结构化摘要。此摘要服务于两个目的：

1. 它成为图像块的`content`字段，与文本和表格块一起被索引。
2. 它提供被嵌入到向量中用于检索的文本。

这个VLM的提示是通用且结构化的。它要求标题、视觉类型、相关性标签、上下文摘要以及所有可见文本、数字和标签的转录。指令是宽泛的：提取你能看到的一切。如果图像是空白的或无意义的，返回一个哨兵值以便过滤掉。

这个VLM不需要是最强大的可用模型。它需要快速（因为它处理文档中的每张图像）且足够好以生成能够匹配相关搜索查询的摘要。在我的系统中，这是一个90B参数的视觉指令模型。

这里的关键设计决策：摘要用于**检索**，而不是用于**回答**。它需要包含足够的关键词和语义信号，以便当有人询问"薪酬委员会汇报结构"时，带有组织架构图的图像块会出现在搜索结果中。它不需要包含精确的答案。

### VLM #2：检索时阅读器

当用户提出问题时，检索流水线运行：查询扩展、混合搜索、去重、排序。排名靠前的结果包含文本块、表格块和图像块的混合。

这就是有趣的地方。当上下文构建器在排序结果中遇到图像块时，它不仅仅包含摄取摘要。相反，它会：

1. 下载原始图像（从对象存储或本地磁盘）
2. 将其连同用户的实际问题发送给第二个更强大的VLM
3. 获取聚焦的、问题感知的提取结果
4. 将提取的文本与文本和表格块一起注入上下文

这个VLM的提示与摄取提示完全不同。它说："仔细查看这张图像并提取与问题相关的所有信息。"它对不同视觉类型有具体指令：对于组织架构图，从提到的实体追踪每条线并列出所有连接项；对于表格，提取所有行和列的精确数字；对于图表，描述数据点和趋势。

这个VLM需要比摄取VLM更强大，因为它的任务更难：它必须理解问题，理解视觉结构，并提取重要的特定信息子集。在我的系统中，这是一个17B参数的专家混合模型，表现远超其体量级别。

如果VLM确定图像与问题无关，结果会被丢弃，流水线继续。这很重要，因为摄取摘要可能是足够好的语义匹配使图像出现在搜索结果中，但实际视觉内容可能不包含用户需要的东西。

## 4、统一上下文

这是大多数人跳过的部分，但它可以说是最重要的架构决策。

检索时VLM输出**不**直接作为答案发送给用户。相反，它与文本块和表格块一起注入到统一上下文字符串中，带有元数据头标记为VLM提取内容：

```
[text | page 11 | section: Corporate Structure]
The company operates through four primary divisions, each led by a VP...
[table | page 45 | Table 3]
| Metric | 2024 | 2023 |
|--------|------|------|
| Total Revenue | $8,412M | $7,953M |
[image | page 12 | vlm-extracted]
The organizational chart shows the following reporting structure:
CEO → VP Engineering
  → Data Platform Team
  → Infrastructure Team
...

```

然后一个文本LLM读取整个组合上下文并生成最终答案。

为什么这很重要？因为它给文本LLM提供了对VLM输出的**第二意见**。VLM可能会幻觉出一个不存在的委员会名称。如果周围页面的文本块没有提到该委员会，文本LLM可以捕获不一致。VLM可能会遗漏一个数据点。如果同一上下文中的表格块有这个数字，文本LLM可以填补空白。

这种图像衍生证据和文本衍生证据之间的交叉引用是你无法获得的——如果VLM输出直接发送给用户，或者你只使用摄取时摘要。

## 5、重要的实现细节

### 5.1 图像存储和路径解析

当你在检索时运行VLM读取时，原始图像需要可访问。在摄取期间，每张裁剪的图像都上传到对象存储（或本地保存），块的`path`字段存储引用。在检索时，系统需要解析该路径，下载字节，base64编码，然后发送给VLM。

这听起来很简单，但在实践中意味着你的检索流水线需要访问与摄取流水线相同的存储后端。如果你在本地机器上运行摄取，在容器中运行检索，路径解析就成了真正的问题。我的系统通过前缀约定处理这个问题：以特定前缀开头的路径表示远程存储并触发下载，而本地路径通过主机到容器的路径映射。

### 5.2 VLM读取上限

检索时的VLM调用很昂贵，包括延迟和成本。每次调用需要几秒钟（取决于模型和图像大小）。你需要一个硬上限。

在我的系统中，上限是每个问题3张图像。上下文构建器按分数顺序处理块。当遇到图像块时，触发VLM调用。如果VLM返回有用内容，该图像计入上限。如果返回空或标记不相关，跳过该图像且不减少上限。这意味着系统每个问题可能尝试超过3次VLM调用，但永远不会将超过3个图像读取注入上下文。

上限还与其他两个限制交互：上下文的总字符预算（保持在文本LLM的有效上下文窗口内）和总块数。首先达到的限制停止组装。

### 5.3 并行化VLM读取

这是一个容易忽略的生产优化。在基本实现中，上下文构建器按分数顺序处理块并内联触发VLM调用。这意味着如果排序结果中出现三个图像块，流水线等待5-7秒完成第一次VLM调用，然后5-7秒第二次，然后5-7秒第三次。那是15-21秒的网络I/O串行等待，而这些调用完全相互独立。

解决方案是将上下文组装重构为两个阶段：

**阶段一：并行预取。** 在组装上下文之前，扫描排序结果中的图像候选。收集比你需要的更多候选（大约是图像上限的2倍），以应对VLM失败和不相关结果。使用线程池并行触发所有VLM调用。VLM推理调用是I/O密集型网络请求，因此即使在线程中也能获得真正的并发。将结果收集到以图像路径为键的字典中。

**阶段二：顺序组装。** 按原始分数顺序迭代结果，与之前完全相同。文本和表格块直接包含。当遇到图像块时，在预取字典中查找结果，而不是阻塞实时API调用。如果VLM返回了有用内容，包含它。如果返回空或标记不相关，跳过它。组装逻辑与串行版本相同，只是永远不会阻塞。

时间改善取决于出现多少图像和你的工作者上限：

- **3张图像，2个工作线程：** 约12秒而不是约18秒
- **1张图像：** 约6秒（没有收益，也没有额外开销）
- **6个候选预取，3个相关：** 约18秒而不是可能约36秒

需要注意两件事。首先，保持工作线程数低。根据我的经验，上限2个并发VLM调用是最佳点。一些VLM API（特别是共享推理端点后面的托管模型）在超过这个数字时会抛出并发错误。其次，过度获取意味着你有时会在永远不会进入上下文的图像上触发VLM调用，因为文本和表格块先填满了字符预算。这是一个成本权衡：你为每个问题多付几次VLM调用来在图像密集的情况下节省几秒。以2倍过度获取因子和3的上限，每个问题最多6次VLM调用，这是有界的可预测成本。

这种优化对20-30%图像实际贡献答案的问题最重要。对于其余的，预取阶段立即完成（排名靠前的结果中没有图像块），组装完全和之前一样运行。

## 6、为什么用两个不同的模型？

你可能会想：为什么不在摄取和检索中使用同一个VLM？有两个实际原因。

**吞吐量与质量的权衡。** 摄取处理文档中的每张图像。对于一份300页的年报，那是30-80张图像。摄取期间每次VLM调用需要几秒。使用重量级模型会把30分钟的摄取变成2小时。摄取VLM需要快速且足够好，而不是最好的。

检索则不同，每个问题最多处理3张图像。延迟预算更大，因为用户在等待单个答案，而不是批量处理文档。你可以承受使用更慢、更强大的模型。

**通用提示与针对性提示。** 摄取提示要求"描述你看到的一切"。检索提示要求"提取与这个具体问题相关的所有内容"。这些是根本不同的任务。一个擅长广泛视觉描述的模型可能不是针对性信息提取的最佳选择，反之亦然。使用两个模型让你为每个工作选择最佳工具。

根据我的经验，摄取VLM是一个大型密集视觉指令模型，优化用于全面的图像描述，而检索VLM是一个专家混合模型（128个专家，每次前向传播17B活跃参数），擅长指令遵循和结构化提取。MoE架构使检索时推理快速，同时在针对性提取任务上提供更好的准确性。

## 7、问题感知优势的具体体现

让我们通过几个常见场景来看看这种架构实际上有什么不同。

### 场景：趋势图

一张折线图显示5年内的"季度收入"，有两条线（实际值与预测值）。

**摄取摘要：** "折线图显示2020-2024年季度收入趋势，包含实际值和预测值。实际线呈上升趋势。预测线略有增长。"

**针对'2024年Q4与2023年Q4的季度收入分别是多少？'的检索时读取：** "图表显示季度收入：2024年Q4实际值 = $21.8亿，2023年Q4实际值 = $20.4亿。同比增长约$1.4亿或6.9%。"

摄取摘要捕捉了形状但没有数字。检索时读取在关于特定年份的问题引导下，提取了精确的数据点。

### 场景：组织架构图

**摄取摘要：** "组织架构图显示CEO与部门负责人之间的汇报线。"

**针对'哪些团队向工程副总裁汇报？'的检索时读取：** "从工程副总裁节点追踪，三个团队直接连接：数据平台、基础设施和开发者工具。三个都显示实线汇报关系（不是虚线咨询关系）。"

摄取摘要是一个鸟瞰视图。检索时读取追踪特定连接，因为问题告诉了VLM确切要关注哪个节点。

### 场景：以图像渲染的复杂表格

复杂文档中的一些表格以图像而非可提取HTML/markdown的形式渲染（合并单元格、彩色标题、破坏解析器的脚注标记）。

**摄取摘要：** "表格显示按类别的产品缺陷率，有多列对应不同季度和产品线。"

**针对'哪个产品类别没有报告缺陷？'的检索时读取：** "在产品质量表中，'数字服务'类别在2024年Q3和Q4列中显示'N/A'值。所有其他类别都有数值。"

没有问题时，VLM没有理由关注N/A值。有了问题，它确切知道要找什么。

## 8、权衡取舍以及何时不使用此模式

这不是一种普遍优越的方法。以下是诚实的权衡。

**延迟。** 检索时每次VLM调用都会增加秒数。并行化调用（如上所述）对多图像情况帮助显著，但即使单次VLM调用也会增加5-7秒的响应时间。如果你的大多数问题由文本和表格块回答（在金融文档中确实如此），那些VLM调用通常在最终不相关的图像上触发。你在知道图像是否有用之前就付出了延迟成本。

**成本。** 检索时VLM调用对每个问题都会发生，不是摄取时一次。如果你有高查询量，成本会成倍增长。摄取时摘要将VLM成本分摊到所有未来查询中。

**复杂性。** 你现在有两个VLM要管理，两套提示要调优，以及需要从检索路径访问的图像存储层。与纯文本检索流水线相比，这是有意义的运营开销。

**摄取时摘要可能就够了的情况：**

- 你的图像很简单（单个图表、产品照片、有一个明确信息的图表）
- 你的问题是可预测且狭窄的
- VLM摘要捕捉了用户会问到的90%以上内容
- 延迟要求严格（亚2秒响应）

**检索时阅读值得成本的情况：**

- 图像信息密集（组织架构图、复杂表格、多面板图表）
- 问题不可预测且多样
- 准确性比速度更重要（金融分析、法律审查、医学影像）
- 你需要视觉和文本证据之间的交叉引用
- 摄取时摘要一直遗漏用户询问的具体细节

## 9、在生产中使其工作

在生产中运行的一些实用经验。

**保留摘要和原始图像。** 将摄取摘要存储为块的内容（用于检索），将图像路径存储为单独的字段（用于检索时阅读）。不要因为你做了检索时读取就丢弃摘要。摘要首先是让图像可被找到的东西。

**使用摄取摘要进行相关性过滤。** 在触发昂贵的VLM调用之前，你可以检查摄取摘要是否与问题有任何关键词重叠。如果摘要关于"收入分解饼图"而问题关于"治理结构"，你可能完全跳过VLM调用。

**设置激进的上限并测量。** 从每个问题2-3张图像的上限开始，测量图像实际对最终答案做出贡献的频率。根据我的经验，在金融文档分析中，大约20-30%的问题受益于图像上下文。其余的完全由文本和表格块回答。这20-30%就是这种架构在正确答案和部分答案之间产生差异的地方。

**用最坏情况的图像测试，而不是平均水平的。** 密集的组织架构图、以图像渲染的多页表格、重叠的注释。简单的图表用任何方法都可以正常工作。复杂的视觉内容才是你发现真正失败模式的地方。

**统一上下文是不可协商的。** 诱惑是当VLM看起来有信心时直接返回VLM输出作为答案。不要这样做。VLM会产生幻觉，特别是在密集的金融文档上。文本LLM作为最终仲裁者，同时访问VLM提取和文本提取的证据，能捕获否则会到达用户的错误。

## 10、更广泛的模式

放大来看，双VLM方法实际上是一个更一般原则的实例：**便宜模型用于索引，昂贵模型用于回答**。

这个原则已经存在于文本RAG中。我们使用小型快速的嵌入模型来索引文档，使用大型昂贵的LLM来生成答案。没有人建议用GPT-4来生成嵌入。

多模态RAG领域还没有完全内化这种分离。大多数教程和框架将图像处理视为一次性摄取步骤，使用任何可用的VLM生成摘要，然后永远不再查看图像。双VLM模式将同样的索引与回答分离应用到视觉内容。

随着VLM继续变得更快更便宜，反对检索时阅读的成本论点会减弱。而随着文档变得更复杂（多模态报告、导出为PDF的交互式仪表盘、带有嵌入动画渲染为静态图像的幻灯片），支持问题感知阅读的准确性论点只会变得更强。

如果你正在为图像承载密集结构化信息的任何领域构建多模态RAG，并且用户提出不可预测的问题，值得考虑你的流水线是否应该看那些图像两次。

---

原文链接: [Your Multimodal RAG Pipeline Should Look at Images Twice](https://pub.towardsai.net/your-multimodal-rag-pipeline-should-look-at-images-twice-f4c2bc190fb8?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处