拿到“RAG 检索增强生成全解析——图片版”这个题目，我第一反应不是去写一堆概念，而是想起之前在某协作项目里，客户丢过来一整批PDF、产品截图和海报，说“这些资料也要能查能答”。当时我按文本RAG的老路走了一遍，结果惨不忍睹：图片检索召回的东西驴唇不对马嘴，模型答出来的结论看着流畅，实际全是脑补。后来重新把RAG检索增强生成全链路按“图片形态的知识库”捋了一遍，才算把这个坑填上。
这篇文章我想聊的“图片版”，指的是知识载体以图片为主的那类RAG——扫描件、图表、截图、海报、白板照片都属于这一类。它和文本RAG的区别不是“多接一个OCR”那么简单，而是检索单元、切分逻辑、嵌入方式和上下文构造全都要重做。文章会按我实际落地的顺序拆解：为什么图片版RAG会失效、完整流程怎么搭、图片怎么切才不会切碎语义、选型怎么选、上线前哪些坑最容易翻车、以及评估到底该看什么指标。
1. 为什么“图片版RAG”不是把标题改成带图两个字那么简单
1.1 文本RAG的底层假设，放到图片上会瞬间失效
文本RAG的标准链路大家都很熟：文档加载、切分成文本块、embedding转向量、向量检索、把检索到的文本拼进上下文、让大模型基于上下文生成回答。这条链路能跑通，其实依赖一个隐藏假设：知识可以被切成“语义完整”的文本块，每个块都能被嵌入模型编码成有区分度的向量。
文字天然满足这个假设，句子的边界、段落的边界、标题和正文的关系，都比较清晰。但资料变成图片之后，第一关就出问题：一张图不是一个自然段，它的语义分散在像素、文字、表格、版式、图表结构里。你拿文本嵌入模型去编码整张截图，得到的只是一个很粗糙的整体语义摘要，图片里的某个数字、某条曲线、某个角落的备注全都被压扁了；你只做OCR把字全提出来，又丢掉了这些字在版面中的位置关系，表格的“表头—数据—注释”结构没了，流程图里的箭头方向也没了。
所以图片版RAG不是一个“预处理里加个OCR就能解决”的小问题。它的核心矛盾在于：图片知识既不能像文本那样直接切，也不能像文本那样直接嵌入，更不会自动生成“哪段文字对应哪张图”的关联。你必须在进入检索之前，先手工设计和构建一套适合图片的“知识单元体系”。
1.2 图片版RAG要回答的三个问题
我在项目里踩了一遍坑之后，把图片版RAG的工程问题收敛成三个：
第一个问题：检索什么。是检索整张原图，还是检索图片里的某个区域、某段文字、某个表格？如果只检索整图，图里80%的细节在召回后仍然拿不到；如果检索到区域级，又得解决“区域怎么定义”的问题。
第二个问题：怎么切。图片要分块，但切小了语义不完整，可能出现“只召回一个坐标轴没有标题”的尴尬局面；切大了检索不精准，海报上某行小字会被整张图的向量噪声盖住。这和文本切分完全是两码事。
第三个问题：怎么喂。检索到图片之后，怎样把视觉内容变成大模型“能基于它回答”的上下文？目前大致有三种做法：把原图作为多模态输入直接传给模型看图回答、把OCR文本作为替代上下文、以及为图片区域生成结构化描述后再注入。三种做法各有代价，实际项目里很少只用一种。
把这三个问题想清楚，图片版RAG就变成了一个更具体的工程任务：把“图里的知识”转换成“可定位、可召回、可引用、可作答”的知识单元，再让模型在这些单元上完成回答。后面几章全部围绕这条主线展开，也是我建议每个团队动手前先对齐的思路主线。
2. 图片版RAG全流程拆解：从一堆图片到一条可用答案
2.1 第一步：文档解析与版面理解
图片版RAG的入口不是直接调一个多模态模型把图变成向量，而是先做文档解析。这项工作在文本RAG里几乎被忽略，但在图片场景里是决定上层检索质量的地基。
我习惯先把图片分成几类：扫描文档（论文、合同、书籍页）、网页截图、产品海报、PPT单页、内容型长图、还有包含表格和流程图的图表类图片。不同类别的解析策略完全不同。扫描文档需要OCR加版面分析，才能知道哪块是标题、哪块是正文、哪块是页脚；网页截图需要按视觉区块来分，而不是按物理坐标硬切；海报可能要识别装饰性元素和核心信息区域；流程图和表格则需要结构模型来识别“节点”“连线”“表头”“数据行”。
只做OCR不做版面分析的方案，在单栏纯文字文档上还能凑合，一旦遇到双栏论文、带边注的页面、图文混排的海报，检索质量会断崖式下跌。原因很简单：OCR只回答“这里有什么字”，不回答“这些字在版面里是什么角色、和旁边的图有什么关系”。我的建议是，解析层的输出不要只给文本，而要给一个结构化的版面结果：每个区域的类别、位置框、置信度、阅读顺序、区域内的OCR内容、以及图表类型标记。这个结构化结果直接决定后面怎么切块、怎么构建图文关联。
2.2 第二步：把图片变成可检索的“知识单元”
解析完成之后，图片还只是一堆带位置的文本框，下一步是把它组织成“知识单元”。我在文本RAG里切分的是自然段落，在图片版RAG里切分的是“版面区域块”。
这里我把实践中的分块策略整理成一张对照表：
| 分块策略 | 基本做法 | 适用场景 | 注意点 |
|---|---|---|---|
| 整图单块 | 整张图片作为一个检索单元 | 单张海报、PPT单页、信息图 | 语义完整但召回粗糙，图内小字容易被淹没 |
| 版面区域块 | 按版面分析输出的区域框切块，每个框配OCR文本 | 扫描文档、论文、正规排版页 | 依赖版面模型质量，区域边界错会导致上下文被切碎 |
| 网格切块 | 按固定网格尺寸切图，不依赖检测模型 | 卫星图、工程图、医疗切片 | 需要额外做相邻块合并，否则语义常被截断 |
| 语义切块 | 根据检测到的对象关系重新组合，比如标题+正文+图表合并 | 图表、流程图、复杂说明书 | 实现成本最高，效果也最好 |
分块的同时要生成元数据：区块在页面上的坐标、所属页面编号、区域类型（标题/正文/图表/表格）、OCR文本、图片缩略图路径。每个图片区域块都应该带一个“父级引用”，指向它所属的页面或文档。这样检索到某个区域块时，系统才知道该回退到哪一页、哪张原图去展示上下文。
2.3 第三步：嵌入与索引——跨模态向量到底在算什么
图片区域块建好后，就进入向量化阶段。这里的核心问题是：拿什么样的模型把“一块图片区域”编码成向量，才能和用户输入的“文本问题”直接比对相似度。
目前可选方案大致有三类。第一类是纯文本嵌入模型，它只能编码OCR出来的文字，遇到图表、照片、图形符号就完全失效，只适合以文字为主的截图场景。第二类是通用图文双塔模型，图片和文本分别经过各自的编码器投影到同一个向量空间，你可以直接计算“某张图片区域”和“某个问题”的相似度，这是图片版RAG的主力方案。第三类是通用多模态大模型，可以直接把图片作为输入、让模型生成一段细粒度的图片描述，再用文本嵌入模型编码这段描述，效果通常最好，但成本高、速度慢，不适合对全部图片跑一遍。
索引层则建议分两级建立：页面/文档级索引负责“粗召回”，先把候选范围缩小到某一页或某一份文档；区域级索引负责“细召回”，在粗召回结果内部再找到具体哪一块图、哪个表格最related。两级索引分别存各自向量，query也做两次检索。我实测下来，页面级粗召回加区域级细召回的组合，比只做区域级全局检索稳定得多，因为多图文档里跨页面噪声会压过目标区域的信号。
2.4 第四步：检索、重排与生成——怎么把图片“喂”给大模型
检索阶段不是简单算一个向量相似度就结束。图片版RAG的query往往包含混合信息：用户可能问“这个图的结论是什么”“第三页的表格里2023年增长多少”“流程图里判断分支后的处理步骤”。这些query需要被拆解或改写后再去检索，否则同一个问法在不同模态下检索结果差异巨大。
我推荐在正式检索前加一个“query理解”分支：如果是纯文本型问题，走OCR文本检索为主、视觉检索为辅的通道；如果是图表型问题，优先检索带“表格”“图标题”“图表类型”等结构化标签的区域块；如果涉及“第几页”“哪个图”这类指代，则把指代解析成文件页码和图片编号再去精确匹配。
检索召回topK之后，重排阶段要同时比较三种相似度：文本对文本（OCR文本与问题的相似度）、图像对文本（视觉向量与问题的相似度）、结构对文本（区域类型、图表标题与问题的相似度）。很多团队只保留其中一种，比如只用视觉向量检索，结果纯文本问题召回了一堆无意义的装饰性图片。重排可以手动加权，也可以用一个轻量模型做二分类“这个区域块是否真的回答了这个问题”，后者效果更稳。
生成阶段的上下文构造，我试过三种方式：
- 直接把原图作为多模态输入传给模型，让模型“看图回答”，这是最接近人眼的做法，上下文信息最完整，但成本高，且一次回答能携带的图片数量受限。
- 把检索到的图片区域块转成OCR文本，再按普通文本方式注入大模型，成本最低，但图表里的坐标关系、颜色含义、视觉细节会丢失。
- 混合注入：给模型同时提供OCR文本、区域描述、图片标题、所属页码，以及必要时附上原图和区域裁剪图作为多模态附件。
生产环境里我目前用得最多的是混合注入。纯文本问答尽量走OCR文本和标题上下文，节约成本；只有遇到“图表数据求值”“空间关系判断”“需要对图本身做解释”这类问题，才走多模态通路。不要所有问题都丢给多模态模型，成本会失控，响应速度也会明显变慢。
3. 图片切分与图文对构建：这一步决定了检索上限
3.1 切分粒度怎么选
图片分块的粒度选择，本质上是在“语义完整性”和“召回精准度”之间找平衡。切得太大，海报里藏了一行小字，检索时它的向量被整张图的全局特征淹没，基本召不回来；切得太小，把图表里的标题切掉了、只切出坐标轴刻度，召回后模型也回答不了任何问题。
我的经验是不要用固定像素尺寸，也不要直接用版面模型输出的原始框，而是以“版面区域边界加语义完整规则”来合并。比如：
- 标题和正文合并，标题只是一个锚点，单独作为检索单元没有意义；
- 图表和它的图注合并，图注往往藏着图表的核心结论；
- 跨页表格保留表头信息，防止二次检索时丢失列含义；
- 流程图按“节点加相邻连线区域”合并，而不是把整张流程图切成碎片。
合并完之后，每个区域块都要保留parent信息：它属于哪个页面、页码范围是多少、原图的缩略图路径在哪。这一步看似琐碎，但检索错了需要溯源时，没有parent信息会非常痛苦。
3.2 图文对构建：图片检索真正的难点不在“图”，在“说清楚图里有什么”
图片版RAG里我踩过最深的坑是：向量检索召回了正确的图片区域，但模型仍然答错，因为上下文里没有把图片“说清楚”。图片区域只是一堆像素和坐标，大模型通常需要文本形态的解释才能准确作答。
所以我后来在构建阶段增加了一个关键步骤：为每个图片区域块生成“结构化描述”，包括区域类型、核心实体、关键OCR文本、以及一句话图意总结。这张图是一张折线图，横轴是什么、纵轴是什么、趋势是什么，都要写进描述里，和区域块的向量、图片路径一起存储。
同时要构建“图文引用关系”。在正规文档里，正文常常会写“如图2所示”，而图2的内容在被解析后是一个独立图片块。如果不把“正文中的引用句”和“对应图片块”关联起来，检索时经常出现只召回图、召不回正文引用句，或者只召回正文引用句、找不到图的情况。我在实现里会把“图2”这类引用解析成图片块的别名标签，让二者互为可检索入口。
装饰性图片也要处理。网页截图和海报里有很多纯背景、Logo、装饰线，检索时它们会制造噪声，应该打上低优先级标签或直接被过滤，不进正常检索链路。
3.3 常见翻车案例
我在这里记录三个真实遇到过的翻车情况，都很有代表性。
第一个：图表被切成了半张。区域块里只剩左侧一部分折线，OCR文本里没有右侧的图例和数据标签，检索召回率看着不错，生成阶段却引用了一条图上根本没有的结论。这个问题最后是靠“图表区域必须和图注、图例合并”的规则解决的，宁可按一个大块召回，也不要拆成半张。
第二个：正文里的“如下图所示”成了独立文本块，图是另一个独立图片块，图文之间没有任何关联。用户问“上图说的结论是什么”，检索只召回了图片块，模型因为没有正文里的解释，回答完全跑偏。加上“引用句到图片块”的关联后，这个问题基本消失。
第三个：混排OCR的质量问题。同一张图里中文识别很稳，英文和数字由于字体原因识别出错，导致向量检索里“2023年增长17%”变成了“2023年增长17%都不像描述”。这不是模型不行，而是预处理没做好。遇到这种情况，我会把低置信度的OCR区域单独标记，查询时如果包含数字，优先走表格结构模型的结果，而不是纯OCR文本。
4. 技术选型参考：图片版RAG的工程栈怎么搭
4.1 视觉编码模型怎么选
图片版RAG的选型，大家最容易纠结的是“到底用什么模型”。我的建议是按模型能力分三类，根据自己的场景挑组合，而不是迷信某一个“最强模型”。
| 模型角色 | 特点 | 成本 | 适合场景 |
|---|---|---|---|
| 轻量双塔图文模型 | 图和文本可以分别编码并计算相似度，检索速度快 | 低 | 大规模图片区域向量的离线建库 |
| 版面融合识别模型 | 在OCR加版面分析数据上优化，对文档图表识别更准 | 中 | 识别表格、阅读顺序、区域类型 |
| 通用多模态大模型 | 既能编码也能生成，能直接看图回答，还能生成细粒度描述 | 高 | 重排、复杂问题的生成、高价值图片的内容描述 |
我实际项目中用的是“轻量双塔模型负责一级检索，多模态大模型负责重排和生成”的组合。理由很直接：知识库里的图片数量经常是十万级，如果用多模态模型对每张图跑一遍详细描述，时间和费用都受不了；双塔模型可以在离线阶段把全部图片向量化，检索时只是向量计算，非常快。重排和生成只处理召回出来的少量候选，这时候再让多模态大模型发力，成本完全可控。
4.2 OCR与版面模型：不是“可选项”，是“必经之路”
很多团队觉得图片版RAG就是“多模态嵌入模型加向量库”，OCR是可有可无的。我在实际跑完流程后可以负责任地说：OCR加版面分析不是可选项，而是必经之路。
原因很简单：检索可以靠视觉向量完成，但生成阶段大模型需要的是“可验证的文字证据”。你不可能让模型每次都在几十张图片像素里找答案，也不该让模型凭空描述图表数值。OCR文本和版面结构就是那个证据。尤其是表格，我强烈建议不要用通用OCR直接跑，而是单独接一个表格结构识别模型，把表格输出成结构化的HTML或Markdown形式。这样生成阶段可以把表格内容直接放进上下文，模型回答数值时不容易瞎编。
选型时重点看几个能力：中英文混排识别效果、竖排文字支持、手写体识别、表格线框还原、阅读顺序输出。缺其中一个，都会在某个资料类型上出问题。
4.3 一套可复制的最小可行组合
如果你要快速搭一版图片版RAG试用，我建议直接按下面的组合来，不需要一开始就上重型方案：
- 解析层：开源OCR引擎加版面分析组件，优先选能输出“文本框+区域类型+置信度+阅读顺序”的方案，表格单独走结构化提取。
- 分块层：按版面区域框加合并规则切块，输出一个JSON结构，字段包括块ID、页面号、坐标、区域类型、OCR文本、图片路径、父级文档ID。
- 向量化：双塔图文模型为图片区域生成视觉向量，同时用一个文本嵌入模型为OCR文本生成文本向量，两者都写入向量库。
- 存储与检索：选用支持多向量字段、支持标量过滤的向量库，建立文档级集合和区域级集合，检索时先粗召回、再细召回。
- 生成层：简单问题用OCR文本加区域描述的文本上下文回答；涉及图表、空间、视觉相关问题时，把原图区域作为多模态附件传给多模态大模型。
这个组合跑通后，再根据实际效果逐步替换更强模型。先跑通，再优化，是我在这个项目里最深的体会。
5. 实测中容易翻车的五个细节（附排查思路）
5.1 问题一：检索得分很高，答得却一塌糊涂
这是图片版RAG最诡异的情况：算法说你召回了相似度很高的图片块，模型回答却完全不在点上。我遇到后排查了很久，最后发现三个可能原因。
第一，召回的是同一页，但不是目标区域。比如用户问“图3的结论”，系统把含有“图3”字样的正文段落召回了，图片本身没召回，模型只看到文字引用，看不到图内容。第二，向量库里的图片向量来自“整图”，而目标细节在某个子区域，相似度被整图稀释了，检索分数虚高但没有真正命中细节。第三，生成阶段根本没有把图片路径或区域内容传给大模型，模型只依赖一个空洞的图片标题作答。
排查思路是一条链路：先确认召回单元的类型是不是图片区域块本身，再确认该区域块是否包含足够细的OCR和结构化描述，最后确认生成提示词里是否真的注入了图片内容和坐标信息。三步走完，缺哪步补哪步。
5.2 问题二：图片里的表格数字被模型“想象”出来了
表格是图片版RAG里幻觉率最高的场景。模型看到“某年营收增长”几个字，就自动补了一个数字，而原图里根本没有这个数。根本原因是表格区域没有走结构化识别，OCR把“表头行”和“数据行”搞混，导致向量检索只匹配到部分内容。
我的解决办法是表格单独一条链路：图片解析后如果区域内检测出表格，就调用表格结构识别模型，输出完整的结构化HTML表格，再把这个结构化文本同时用于向量化和生成上下文。生成阶段如果问题涉及“具体数值”，我会在提示词里强制要求模型只能在提供的表格数据中引用数值，不能自行推算。另外，数字类问题要开启“引用验证”开关，答完必须标注数据来源是哪一行哪一列。
5.3 问题三：召回不错但排序不对
有时候检索到的区域块其实都是对的，但顺序很乱：真正应该排第一的图注块排在第八，排在前面的是几张装饰图。这种问题在指标上表现为“召回率还行，MRR很差”，用户感知就是“明明有答案，偏偏排到下面去了”。
解决排序问题，我只推荐两个手段。一是重排器，用它融合文本、视觉、结构三种信号后重新打分，效果比单纯调向量相似度权重好得多。二是query改写分支：当问题里包含“第几页”“哪个图”“哪张表”这类指代时，直接把指代解析结果作为硬过滤条件，把候选集缩小到指定页面和指定图片编号，再在内部排序。
5.4 问题四：多图文档的上下文错位
一份几十页的PDF，图片被切块后，如果只保留“区域块”而没有保留“页面归属”，检索系统很容易出现一种尴尬：召回的是第30页的图，答案却引用第1页的文字。多图文档里这个问题特别严重，因为向量检索会跨页面匹配相似语义。
我的做法是强制父子结构：每个区域块都必须带着page_id和doc_id，检索召回后先按doc_id做聚合，再限制同一份文档内的候选数量。生成阶段给模型的上下文必须包含“该区域块来自第X页”的说明。跨页面的内容拼接宁可不要，也不要让模型把不同页的内容混在一起回答。
5.5 问题五：性能与成本失控
图片向量化的计算量比纯文本大一个数量级，十万张图片做成地区块级别可能要跑很久。如果直接对每张图跑多模态大模型生成详细描述，时间和费用都扛不住。
我用过三个有效手段：第一，对重复图片做哈希去重，同一张图在企业资料库里出现很多次时只处理一份；第二，离线建库时把大图先压缩到合适分辨率，图片区域块的向量只针对“裁剪区域”计算，而不是整页大图；第三，存储层不直接存base64图片数据，只存图片路径和缩略图URL，需要展示时再读取原图。
上线后还要做分级：检索阶段只用双塔向量，重排阶段用轻量重排模型，只有最后的生成阶段才根据问题类型决定是否调用多模态大模型。这样整体成本能被压在一个可接受的范围，而且响应速度也不会太慢。
6. 评估与上线决策：别被“能用”骗了
6.1 图片版RAG到底该看哪些指标
文本RAG的评估指标可以原样搬过来，但有一个思路必须改：图片版RAG不仅要看“答案对不对”，还要看“答案能不能定位到图里的证据”。单看生成结果的自然度根本没有意义，因为模型编一个流畅答案非常容易。
我建议分两层评估。第一层是检索层指标：hit_rate（目标区域是否被召回）、recall@k（正确答案所在区域是否在topK内）、MRR（排序质量）、以及页面级命中率。第二层是生成层指标：答案准确率、幻觉率、引用可验证性。其中“引用可验证性”是我加了很久的指标，要求每个答案都能指到具体区域块、具体页码、具体缩略图。
评测集要从真实知识库里抽，不要只拿几张明星图片测着玩。我习惯把测试问题分成四类：文本型问题占比约40%、图表数据型问题约35%、空间结构型问题约15%、整图描述型问题约10%。不同类别的通过标准不一样，图表数据型问题对数值准确性要求极高，整图描述型问题则看重语义概括能力。
6.2 什么时候该上图片版RAG，什么时候该用“文本RAG+图片引用”
不是所有图片场景都要做完整的图片版RAG。我见过不少团队把简单问题复杂化，最后性能和成本都扛不住。这里给一个比较实用的判断标准：
如果文档里的图片只是辅助插图，核心信息仍然以文字形式存在于正文里，那就别上图片版RAG。你只需要在文本切分时，把图片标题、图片下方的说明文字、正文里对图片的引用句一并保留，用户问图里的内容时，模型靠文字上下文也能答出八成。
如果知识库里的内容以图表、截图、海报、扫描件等视觉形态为主，信息只在图里才有，那才需要完整的图片版RAG。还有一种混合场景，比如产品手册里既有大量文字又有大量示意图，我推荐的做法是保留图片版RAG的解析链路，但在生成阶段默认走文本路径，只有检测到“图表类型问题”或“模型自身判断文本上下文不足”时才切换到多模态通路。
6.3 给上线的三个建议
最后给准备上线图片版RAG的团队三个实操建议。第一，先做最小可验收闭环：选十张覆盖不同类别的真实图片，跑通“提问—检索—生成—引用”的完整链路，再考虑扩大知识库规模。不要一开始就把十万张图灌进去，翻车后连问题在哪都找不到。
第二，上线之后一定要加反馈回收环节。用户对回答点了“不满意”时，记录下来是“检索没召回到对的图”还是“召回了但答案错了”。这两类问题的修复方向完全不同，前者改索引和重排，后者改生成策略和上下文构造。
第三，图片隐私和权限要提前想好。原始图片往往包含敏感信息，检索结果展示时优先给脱敏后的缩略图，区域块的OCR文本也要做权限过滤，不要让模型在回答里暴露超出用户权限的图片内容。
这个项目做下来的整体感受是，图片版RAG真正的难点从来不是“把图片和文字塞进同一个向量空间”，而是让系统知道“哪一块图对应哪一段上下文、哪一条结论出自哪个区域”。技术选型和模型能力当然重要，但先把版面分析、图文关系构建和区域块元数据做扎实，比盲目换更强的多模态模型划算得多。如果只能从这篇文章里带一句话走，那就是这句话：先让每张图在你的系统里拥有清晰的“身份”，再谈检索和生成，顺序不能反。
