如果在技术分享里只能挑一个这两年最被低估的思路我会把票投给 RAG 检索增强生成。原因很简单它把大模型从闭卷考试拉回到开卷考试让生成内容有据可依。而这次聊的图片版是我在实际项目里被逼出来的经验总结——当你的知识库不再是纯文档而是一堆截图、扫描件、产品图、PPT 图表和表格图片时传统 RAG 的文本流水线会立刻失灵。这里的图片版其实包含两层意思一层是用图解思维把 RAG 的流程讲清楚另一层是让 RAG 真正处理图片内容把它变成可检索的知识源。这篇文章会把两层都覆盖到重心放在后者。我会从概念、链路设计、核心实操、完整复现、调优方法和问题排查几个角度展开所有细节都来自我做图文知识库问答时的真实踩坑记录。适合正在做企业知识库、产品手册问答、多模态检索的人参考也适合刚接触 RAG、想系统理解检索增强生成工作原理的开发者。1. 先搞清楚RAG 检索增强生成到底在解决什么问题1.1 大模型不是移动硬盘别让它硬背资料RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的核心主张很朴素不要指望模型把所有知识都装进参数里而是在生成回答之前先从外部知识库中检索出相关资料把它们拼进上下文再让模型基于这些材料作答。我常用一个类比解释这件事闭卷考试要求你把整本书背下来开卷考试允许你翻书作答。RAG 就是给大模型配了一本可以随时翻的书。之所以需要这本书是因为大模型有两个先天问题一是知识有截止日期训练完成后就停止更新二是它会在不确定时一本正经地编造内容也就是我们常说的幻觉。RAG 并不试图让模型记住更多而是改变回答问题的路径——先查到再说。这带来了三个实际价值内容可溯源每个回答都能指向具体的知识来源知识可更新更换知识库里的资料不需要重新训练模型成本可控相比微调大规模模型检索方案在算力和维护成本上要低一个数量级。1.2 图片版是怎么回事图说 RAG 和 RAG 读图RAG 全解析——图片版这个说法在实际讨论中往往指向两种不同的东西。第一种是用图片来解释 RAG。RAG 涉及嵌入、向量数据库、相似度检索、上下文注入等多个概念纯文字描述很容易绕晕。一张好的流程图可以把信息流向讲清楚文档切块、向量化、存储、召回、拼接、生成。这种图片版适合教学和方案汇报。第二种是让 RAG 处理图片数据。这是工程上更棘手的问题知识库里存放的不是纯文本而是产品实物图、设备截图、流程图、扫描文档、带复杂版式的 PPT 页面。传统 RAG 只处理文本面对图片只能跳过等于信息直接丢失。图片版 RAG 要做的是把图片内容解析出来、编码成向量、支持检索再参与生成。这篇文章重点讨论第二种场景。我把它定义为以图文混合资料为核心知识源通过图像解析、多模态向量化、混合检索和生成注入实现给一张图 / 问一个问题返回一段有依据的回答。1.3 什么样的场景最需要图片版 RAG不是所有项目都需要图片版 RAG但它特别适合几类典型场景。企业内部操作手册是典型场景之一。很多设备运维、软件操作手册大量依赖截图文字只承担辅助说明作用。假如你问配置界面里那个开关是什么意思文本检索根本找不到答案因为关键信息藏在截图里。合规审查类场景同样很需要。合同、单据、资质证件的扫描件往往以图片形式沉淀需要快速定位某一条款、某一个编号单纯的 OCR 搜索不够还需要语义层面的理解。还有电商和产品文档场景。用户问这款设备支不支持壁挂安装答案可能只出现在一张安装示意图上。检索系统必须理解图片内容并且把图和文字描述关联起来。一图胜千言但一图对传统 RAG 来说就是一堵墙。图片版 RAG 的存在价值就是把这堵墙拆掉让图片从不可检索的附件变成可检索的知识单元。2. 图片版 RAG 的整体链路设计与模块拆解2.1 文本 RAG 的老路五步流水线理解图片版之前先回顾文本 RAG 的标准流程它通常分成五步。第一步是文档解析。从 PDF、Word、HTML 中提取纯文本去掉版式干扰。第二步是文本切块把长文档切成结构完整的片段这个块的大小直接决定后续检索粒度。第三步是向量化用文本嵌入模型把每个片段映射成一组浮点数向量语义相近的内容在向量空间里距离更近。第四步是写入向量存储建索引、存元数据方便快速查找。第五步是检索与生成用户提问后把问题转成向量在库里找最近的几个片段连同原始问题一起交给大模型生成回答。这个流程在纯文本场景下已经非常成熟但它默认了一个前提知识源是文字。当图片出现时第一步就卡住了——解析器读不懂图片语义嵌入模型也处理不了图像输入。2.2 图片版 RAG 新增的三个关键模块图片版 RAG 不是推翻老路而是在这条流水线上加三个模块。第一个是图像解析模块。它的任务是把图片翻译成机器可理解的中间表示。对扫描文档要做 OCR 文字识别对有复杂版式的页面要做版面结构还原对表格要做结构化抽取对图表要提取数据和趋势描述。这一步的质量决定了后面所有环节的上限。我会在第三节详细展开。第二个是图像向量化模块。它负责把图片本身或者图片的解析结果编码成向量。这里有一个关键选择是只编码文本 OCR 结果还是编码图片整体保守方案是只对 OCR 文本做嵌入相当于把图片当作文本载体进阶方案是用图文对齐模型把图片像素和文字映射到同一个向量空间这样检索时既可以用图找图也可以用文字描述找图。第三个是多路召回与融合排序模块。由于图片知识库同时存在文本块、OCR 文本、图片向量三种形态单一召回策略容易漏检需要关键词检索、向量检索、图文检索并行执行再用融合策略统一排序。这三个模块不是可选项而是图片版 RAG 的刚需。缺了图像解析图片内容进不了知识库缺了图像向量化纯文本检索无法理解视觉语义缺了多路召回漏检率会高到不可用。2.3 两种管线编排一股脑全处理还是按需做路由加完模块之后下一个问题是编排顺序。我见过两种主流方案各有取舍。第一种是全量处理模式。不管来的是什么类型的文件全部走一遍图像解析、向量化、入库流程。优点是管线简单逻辑统一对数据格式不敏感缺点是成本高一张纯文本截图也要跑 OCR、跑视觉模型浪费算力而且可能出现过度解析——把本来清晰的文字图硬套版面模型反而切错结构。第二种是智能路由模式。先用一个轻量分类器判断文件类型纯文本直接走文本管线有版式的文档走 OCR 加结构识别纯图片走视觉向量化表格类单独走表格抽取。路由逻辑可以在导入阶段做也可以在查询阶段做。从我的实际操作看生产环境强烈建议用第二种。虽然前期要花时间维护路由规则但后续的解析质量、处理速度和故障定位都会轻松很多。第一种模式只适合数据量小、类型单一的实验项目。3. 核心环节实操让图片真正进入检索系统3.1 图像解析OCR、版面还原、表格结构化的三重奏图像解析是图片版 RAG 成败的第一关。很多人以为图像解析就是 OCR这是个误区。OCR 只是其中一环完整的图像解析要处理三件事。第一件是 OCR 文字识别。把图片里的文字提取出来输出文字内容和每个文字块的位置坐标。这里有个容易忽略的细节识别得到的坐标非常有用它是后续版面还原和检索排序的基础。实际操作中图片清晰度的影响远大于模型本身的影响扫描件要先做去污、纠偏、增强对比度拍照件还要考虑透视变形校正。我的经验是在这上面花 20% 的精力能换来 80% 的识别率提升。第二件是版面结构还原。一张页面图里往往有标题、正文、页眉、页脚、图片注释等多个区域如果不做版面分析就把 OCR 结果按阅读顺序粗暴拼接检索时会得到大量语义割裂的片段。正确做法是先识别区域类型再按照页面中的空间位置重组阅读顺序。这一步直接决定了切块质量。第三件是表格结构化。表格是图片解析的重灾区。普通 OCR 会把表格拆成散落的文本块丢失行列关系。实际项目里需要用专门的表格结构识别组件输出带行列表头语义的结构化数据最好是能转成 Markdown 表格或者 JSON 格式后续检索才能精确命中某个单元格中的数值这类问题。我建议在项目初期做一个解析质量抽检随机抽 50 张图人工核对 OCR 准确率和版面还原率。不要等到系统上线才发现解析端全是坏数据那样检索和生成再怎么调优都救不回来。3.2 图像语义向量化把像素变成可检索的坐标解析完成后图片信息有两种向量化路线需要根据场景选择。路线一是解析文本向量化。把 OCR 出来的文字、表格结构化文本直接送进文本嵌入模型。优点是好理解、实现简单、对中文支持通常更成熟缺点是丢失了视觉信息遇到找一张外观是圆形的设备图这类问题会无能为力。路线二是图文双塔编码。用大规模预训练的图文对齐模型分别编码图片和文本让它们在同一个向量空间里可比。它的核心价值是语义对齐你输入设备背面接口示意图模型能直接匹配到那张没有文字标注的接口特写图。这个能力在图片知识库场景中非常关键因为很多视觉知识根本不以文字形式存在。在实现层面我建议采用双路并行、互为补充的策略对每张图片同时保存图片整体向量和 OCR 文本向量。检索时两条路都走配上不同的权重。对纯视觉问题图片向量贡献更大对包含精确数值、型号、参数的问题文本向量贡献更大。向量化的细节也值得注意一是维度高维度向量表达能力强但存储和计算开销大768 到 1024 维是常见选择二是归一化建议统一做 L2 归一化方便后续用余弦距离三是批次大小图文编码模型对显存敏感批处理时要注意显存占满导致的 OOM 问题。3.3 混合检索与重排序只靠相似度必然翻车很多人在做图片版 RAG 时犯同一个错误以为向量检索搞定一切。实际效果通常是偶尔惊艳经常跑偏。原因在于向量检索擅长语义相似却不擅长精确匹配。用户查询编号 XK-2024-001这样的精确信息时向量检索的结果往往不如一个简单的关键词匹配。正确做法是混合检索。系统里并行跑三路召回第一路是关键词检索用倒排索引匹配精确词和短语适合型号、编号、人名、专有名词。第二路是文本向量检索用嵌入模型召回语义相近的文本块。第三路是图片向量检索用问题文本的向量直接去匹配图片向量这一步是图片版 RAG 区别于文本 RAG 的核心。三路召回的结果需要融合。我推荐使用 RRF 这种简单有效的方法它不看具体相似度分值只看每个文档在几路结果里的排名把排名倒数累加作为融合分数。RRF 的效果在很多实践中比加权求和更稳定因为它不需要精细调权重对不同召回通道的分值尺度也不敏感。融合排序之后还要加一道重排序。召回阶段要的是效率和召回率可以牺牲部分精度所以一般用轻量模型取回前五十或者前一百个候选重排序阶段要用更强的语义匹配模型对这些候选重新算相关性取前五到前十进入上下文。这一步通常能让最终回答质量提升一个台阶代价是多一次模型调用需要评估延迟是否可接受。4. 从零落地一个图文知识库问答项目的完整复现4.1 场景设定与数据准备概念讲得再多不如动手跑一遍。我以自己做过的一个模拟项目为蓝本把这个过程完整拆给你们。背景设定某公司有一批设备操作手册内容是 PDF 导出的页面图每页包含界面截图、按钮位置标识、操作说明文字混杂着大量表格和参数清单。目标是用图片版 RAG 做一个问答系统支持员工用自然语言提问比如如何在系统里重置管理员密码导出报表时提示 503 怎么办回答必须引用对应页面图。数据准备阶段我先把 1000 张手册页面图整理到一个目录按章节和页码命名方便后续回溯。这里有一个容易被忽视的点图片文件名本身也是元数据合理命名能让后续检索多一个过滤条件。之后我按页面图 描述文本 标签的格式给每张图生成一份元数据记录描述文本从手册目录和章节标题里整理标签则包含设备型号、功能模块、操作类型。4.2 四步搭建流程与关键参数有了数据之后按四个步骤就能搭起一套可用的流程。第一步图像解析入库。对每一张页面图执行 OCR、版面还原和表格结构化输出两部分内容一是按阅读顺序排版的结构化文本二是原始图片的标准化缩放版本。结构化文本用于文本检索和生成引用图片用于视觉检索和答案配图。实测下来这一步最耗时1000 张图大约需要两到三个小时建议做成离线任务解析结果缓存下来方便多次实验。第二步向量化。我用双塔图文编码模型处理图片整体用文本嵌入模型处理结构化文本两个模型都输出 L2 归一化后的向量。关键参数是文本切块对页面图解析出的文本我按 500 字左右切块块与块之间保持 50 字重叠避免把连续的步骤说明切断。这个参数不是拍脑袋定的而是从页面平均信息密度估算出来的——手册每页大约 600 到 800 字切成一块左右刚好让一页对应一个检索单元。第三步写入存储。向量和元数据一起写入支持混合检索的向量数据库。每条记录包含四个字段内容文本、图片向量、文本向量、元数据 JSON。我对元数据建了索引查询时先按设备型号过滤再做向量检索能明显提升搜索结果的相关性。下面是一个简化示意代码实际选型请按项目约束来确定# 简化示意仅表达写入逻辑 records [] for page in pages: text parse_page_text(page) # 图像解析 text_vector embed_text(text) # 文本向量化 image_vector embed_image(page) # 图片向量化 records.append({ text: text, text_vector: text_vector, image_vector: image_vector, metadata: {page_no: page.no, model: page.model} }) write_to_vector_store(records, index_fields[metadata.model])第四步查询与生成。用户提问后系统先对问题做意图判断决定以哪路召回为主然后并行走三路检索融合排序重排取前五连同问题一起交给大模型。我给出的查询参数是初始召回每路 50 条融合后取 20 条重排后取 5 条进入上下文。这个50-20-5的组合是我测试下来在效果和成本之间比较平衡的档位。4.3 生成侧提示词与引用策略检索做得好不好最终看生成能不能用对材料。很多项目在检索环节已经找对了图但大模型生成答案时还是跑偏问题大多出在提示词设计上。我给生成环节定了一条原则把检索到的材料像证据一样递给模型明确要求它区分材料说了什么和材料没说什么。实际操作中提示词模板包含三个部分一部分是角色指令说明你是一个设备操作问答助手所有回答必须基于下方提供的资料片段资料可能包含图片描述、表格数据。第二部分是检索证据把重排后命中的每一条文本块按序号列出并附上对应的图片路径和页码。第三部分是输出要求规定回答必须引用序号格式是根据资料 [3] 中的操作步骤……。引用策略上我要求答案里保留引用编号并在展示回答时把引用编号映射回原始图片用户可以直接点击查看原图。这是图片版 RAG 比较有优势的地方很多问题用文字说不清楚直接给用户一张圈注了按钮位置的截图比任何解释都有效。防止幻觉还有一招在提示词里加上如果资料中没有给出确切答案请明确回答资料中未找到相关信息不要猜测。这看起来简单但能显著降低答案的编造概率。5. 工程化难点与效果调优实战5.1 准确率上不去的三个瓶颈项目跑通后真正的挑战才开始准确率达不到业务要求。调优过程中我总结出三个最常见的瓶颈按优先级排序。第一个瓶颈是解析质量。如果你发现检索返回的内容文不对题先别急着换模型回到图像解析结果里看几眼。我遇到过典型的案例手册某一页有两个栏位左侧是文字说明右侧是表格OCR 把左右两栏内容混排成了一行长文本导致检索时匹配到完全无关的内容。这类问题在文本上看不出来必须对照原图检查。解法是在版面分析阶段增加分栏检测把不同栏位拆成独立文本块。第二个瓶颈是召回策略单一。只用了文本向量检索就会漏掉无文字图片只用了关键词检索就会漏掉同义改写的问题。我的经验是把召回通道做全再用离线评测数据验证每个通道各自贡献了多少命中。把三路召回结果做交集和差集分析能直观看到是哪一路在拖后腿。第三个瓶颈是重排序缺失。初召回结果里正确片段往往排在十到二十位模型生成时只取前五正确片段根本没进上下文。加上一个重排序模块后这个情况会明显改善。调优时重点关注重排序模型对图文混排内容的适应性纯文本上训练的重排序模型对图片描述类文本经常不够敏感。5.2 性能、成本与存储的取舍图片版 RAG 的工程化成本比文本 RAG 高主要高在图像解析和图片向量化上。性能层面用户等不了三秒钟以上的问答响应。我的优化手段有三个。一是把图像解析和向量化全部做成离线预计算查询链路里只保留检索、重排、生成三段这样就避开了最重的计算。二是在查询链路里加缓存层对高频问题直接缓存答案实测命中率在三成左右时整体响应速度能提高一倍。三是压缩向量对大规模图片库可以做向量量化或者降维比如把 1024 维降到 512 维召回效果损失不大但内存占用减少近一半。成本层面最大的开销是模型推理。建议是分级使用模型路由分类用轻量小模型文字向量化和图片向量化各用一个专用模型生成阶段用更强的模型。不要试图用一个模型干所有事既不经济效果也不好。存储层面要注意图片文件和向量数据的生命周期管理。原图通常占用大量空间入库时建议统一压缩成标准尺寸既降低存储压力也加快向量化速度。原始高清图可以放到冷存储只在用户点击查看大图时再取用。5.3 一套可执行的评测方法没有评测就没有调优方向。图片版 RAG 的评测比文本 RAG 复杂因为它要多维度验证检索准不准、生成对不对、引用可不可靠。我的做法是构建一套大约 200 条的评测集。每条评测数据包含三部分问题、期望命中的图片编号、期望答案中的关键信息点。因为人工标注成本高初期先保证覆盖高频业务场景低频场景后续再分批补充。评测分成两个层面。一是检索层面指标是 Recall5 和 Recall10也就是正确答案有没有出现在前五或前十的候选中。这个指标不依赖生成效果能单独评估检索链路的好坏。二是生成层面重点看答案正确率和引用准确率。我采用两步评分先看答案中的关键信息点是否正确再看引用的图片编号是否对得上答案内容。两项都通过才算一条合格。这套评测跑完之后每次改动都能对比数据。比如你会发现加了一路图片向量召回后Recall5 从 62% 涨到 78%但生成正确率只涨了 5 个百分点说明瓶颈已经从检索转移到了生成侧下一步就该优化提示词和重排序了。6. 常见问题与排查实录6.1 检索命不中原因不在向量实战中最常见的问题是明明知识库里有答案但检索就是命不中。排查时先做一件事把问题改成关键词直接去库里搜索如果关键词也搜不到说明内容入库环节出了问题。要么是图片解析时文字识别错误要么是切块把关键信息切碎了要么是元数据写错导致过滤掉了正确结果。如果关键词能搜到但向量检索搜不到问题出在向量化和语义匹配上。检查一下文本向量化模型是否对领域术语敏感必要时用该领域的语料做少量适配。如果图片向量搜不到常见原因是图片和文本向量没有对齐问题文本和图片在向量空间里距离远需要检查双塔编码模型是否适合当前图片类型。6.2 答案写得很顺但和图片对不上这个现象通常说明生成模型没有忠实于材料。优先检查提示词里是否明确了只依据资料作答以及检索材料的顺序和格式是否清晰。如果材料本身没问题再检查有没有把多路检索结果混在一起导致矛盾比如三路召回返回了不同页面但重排序后分数相近模型挑选了次优的那个。另一种可能更隐蔽图片描述文本不完整。OCR 结果里只有按钮名称没有操作结果生成模型只能根据残缺信息补全自然容易出错。这种情况需要在解析阶段补充图片的上下文信息比如把该图所在章节的文字说明合并进同一检索单元。6.3 图片解析乱码、错位怎么办图片解析乱码首先要区分是真乱码还是格式问题。真乱码是 OCR 识别错误常见原因是图片质量差。错位则多半是版面还原顺序不对。我的排查习惯是先看单张图片的解析中间结果把 OCR 文字和坐标画出来和原图叠在一起看。如果文字坐标明显偏离原图位置考虑透视校正如果阅读顺序错乱检查版面分析模块的分栏参数如果表格数据张冠李戴优先单独跑表格结构化组件不要依赖通用 OCR。这里分享一个实测很稳的操作把所有解析失败的图片单独放到一个待复核目录每天抽空人工处理一次比在代码里反复调参要高效得多。很多图片的问题是共性的处理一批之后代码规则也就总结出来了。6.4 响应慢到不可用怎么提速响应慢要先分清慢在哪一段。在日志里给检索、重排、生成三个阶段分别计时。如果检索慢大概率是向量存储没有走索引或者每次查询都重新加载了模型如果重排慢降低候选集数量如果生成慢考虑换更快的生成模型或者对答案长度做约束。还有一个容易被忽略的点有时候不是单次慢而是并发一多就崩。图片版 RAG 的查询链路里多路召回会并发调用多个模型服务任何一个服务的排队时间都会叠加到总耗时上。解法是给每路召回设置超时并做好服务降级——比如图片向量召回失败时退化为只用文本检索而不是让整个请求失败。问题现象、原因和排查方向可以用下面这个速查表来概括现象常见原因排查方向解决建议检索命中率低解析质量差 / 切块不合理抽查解析结果检查切分边界优化版面分析调切块参数精确编号搜不到只有向量检索无关键词通道用编号直接做关键词测试增加关键词检索融合排序生成答案与图片不符提示词约束不足 / 材料残缺查看输入大模型的上下文强化引用约束补充上下文图片识别乱码图片质量差 / 缺少预处理保存中间结果对比原图增强去噪纠偏加入工复核响应速度慢查询链路串行耗时分阶段计时定位瓶颈离线预计算加缓存和降级我在实际项目里还有一个习惯每次动完一个环节不要只评估整体效果变好还是变坏而是同时看数据样例。整体指标可能因为某些案例变好而虚假提升具体到某类图片上反而退化了。把评测集按图片类型和问题类型拆开来评估才不会被平均值骗过去。做图片版 RAG 这几个月我最大的体会是检索增强生成的技术框架已经够成熟难点全在数据侧和工程侧的细节。图片解析多花一天后面调优就少加一个月的班路由规则多写一条分支线上就少一次诡异故障。做这类系统别迷信某一个大模型也别迷信某一次检索效果惊艳老老实实把数据管线做扎实把评测集建起来效果是慢慢磨出来的。希望这篇从概念到落地、从踩坑到调优的内容能让你在自己的项目里少走一段弯路。
