拿到“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目标区域是否被召回、recallk正确答案所在区域是否在topK内、MRR排序质量、以及页面级命中率。第二层是生成层指标答案准确率、幻觉率、引用可验证性。其中“引用可验证性”是我加了很久的指标要求每个答案都能指到具体区域块、具体页码、具体缩略图。评测集要从真实知识库里抽不要只拿几张明星图片测着玩。我习惯把测试问题分成四类文本型问题占比约40%、图表数据型问题约35%、空间结构型问题约15%、整图描述型问题约10%。不同类别的通过标准不一样图表数据型问题对数值准确性要求极高整图描述型问题则看重语义概括能力。6.2 什么时候该上图片版RAG什么时候该用“文本RAG图片引用”不是所有图片场景都要做完整的图片版RAG。我见过不少团队把简单问题复杂化最后性能和成本都扛不住。这里给一个比较实用的判断标准如果文档里的图片只是辅助插图核心信息仍然以文字形式存在于正文里那就别上图片版RAG。你只需要在文本切分时把图片标题、图片下方的说明文字、正文里对图片的引用句一并保留用户问图里的内容时模型靠文字上下文也能答出八成。如果知识库里的内容以图表、截图、海报、扫描件等视觉形态为主信息只在图里才有那才需要完整的图片版RAG。还有一种混合场景比如产品手册里既有大量文字又有大量示意图我推荐的做法是保留图片版RAG的解析链路但在生成阶段默认走文本路径只有检测到“图表类型问题”或“模型自身判断文本上下文不足”时才切换到多模态通路。6.3 给上线的三个建议最后给准备上线图片版RAG的团队三个实操建议。第一先做最小可验收闭环选十张覆盖不同类别的真实图片跑通“提问—检索—生成—引用”的完整链路再考虑扩大知识库规模。不要一开始就把十万张图灌进去翻车后连问题在哪都找不到。第二上线之后一定要加反馈回收环节。用户对回答点了“不满意”时记录下来是“检索没召回到对的图”还是“召回了但答案错了”。这两类问题的修复方向完全不同前者改索引和重排后者改生成策略和上下文构造。第三图片隐私和权限要提前想好。原始图片往往包含敏感信息检索结果展示时优先给脱敏后的缩略图区域块的OCR文本也要做权限过滤不要让模型在回答里暴露超出用户权限的图片内容。这个项目做下来的整体感受是图片版RAG真正的难点从来不是“把图片和文字塞进同一个向量空间”而是让系统知道“哪一块图对应哪一段上下文、哪一条结论出自哪个区域”。技术选型和模型能力当然重要但先把版面分析、图文关系构建和区域块元数据做扎实比盲目换更强的多模态模型划算得多。如果只能从这篇文章里带一句话走那就是这句话先让每张图在你的系统里拥有清晰的“身份”再谈检索和生成顺序不能反。