PDF 文档的 RAG 检索增强生成项目做过的朋友应该都有同感让人头疼的往往不是文字而是那些藏在页面里的图表、扫描图片和花哨排版。文字段落抽取出来直接切块丢进向量库效果还行可一旦文档里有一半内容是图片、截图、表格纯文本抽取的 RAG 就废了一半——图片里的信息根本进不了知识库用户问“图里写了什么”“这张表说明了什么趋势”模型只能靠猜。这套方案解决的核心问题就是让 RAG 系统真正“看得懂”PDF 里的图文混排内容。我用的组合是 PyMuPDF 做 PDF 解析和图片提取Qwen-VL 多模态模型做图片内容理解再配合文本分块与向量检索搭一套既能命中文字段落、又能检索图片语义的图文兼容知识库。效果实测下来对图文混合的文档回答准确率比纯文本方案提升不少尤其适合产品手册、技术报告、论文 PDF 这类场景。本文会把核心思路、代码实现、参数调优过程、踩坑记录完整拆开讲适合正在做 RAG 应用开发、被 PDF 解析折磨过的朋友也适合准备把多模态模型接入知识库的团队参考。1. 整体思路拆解为什么是 PyMuPDF Qwen-VL1.1 纯文本抽取做 RAG 的瓶颈在哪做 RAG 的第一步永远是解析文档。PDF 这东西格式非常封闭它不像 HTML 有 DOM 树也不像 Markdown 有清晰语义结构本质上就是一页一页的“画布”上面叠着文字块、图片对象、矢量路径。很多 PDF 里的文字并不是真的文字而是扫描件、图片型 PDF或者文字被打成曲线路径传统的pdfplumber、PyPDF2抽出来是一堆乱码或者干脆空白。就算文字能抽出来排版问题也很致命。一份技术手册里经常是“一段说明文字 一张示意图 一段结论”文字分割成段落容易但图片区域的语义关系断了。用户提问“这个架构图里的组件叫什么”纯文本方案根本不知道页面中间那张图片讲了什么。你必须让系统能“看”图片并且把图片的语义描述也送进知识库。还有一个容易被忽视的问题图片中的文字。很多 PDF 会为了排版美观把关键注释做成图或者直接插入截图。纯文本抽取器对这些内容完全无能为力这些信息在知识库里就是盲区。早期我做 RAG 项目客户的 PDF 里有大量产品截图用户问问题涉及截图内容系统每次都给不出答案后来一查知识库里压根没存这些信息。1.2 PyMuPDF 和 Qwen-VL 在方案里的分工选 PyMuPDF也就是 fitz做 PDF 层处理几个理由很实在首先它是目前 Python 生态里处理 PDF 性能最稳的库之一。解析速度非常快对页面的布局信息暴露得很完整——文字块有坐标、图片有坐标和尺寸、页面有宽高。这意味着你可以精确地知道“这一页有哪些图片、图片在哪、多大”为后续的图片提取和文本上下文关联打基础。其次PyMuPDF 的渲染能力足够强。它可以把 PDF 页面渲染成高分辨率图像也可以在页面上按指定区域裁剪图片。这就解决了“图片型 PDF”的识别问题——整个页面渲染出来当图看交给视觉模型去读再转成文字描述进知识库。Qwen-VL 这边承担的是“眼睛”的角色。它本身是开源多模态大模型对中文场景理解好能识别图片里的文字OCR 能力、图标结构、表格内容还能生成自然语言的图注描述。相比传统的 OCR 工具如 TesseractQwen-VL 能输出“图里有什么 图表达什么意思”的语义化结果这正好是 RAG 需要的——不是要一行字符而是要一段可以检索的描述。两个工具配合后流程就是PyMuPDF 负责“拆”——把 PDF 拆成页面、文字块、图片区块Qwen-VL 负责“读”——把图片区块读成语义描述文本描述再一起进 embedding 向量库实现图文统一检索。1.3 这套方案要解决什么、适合什么场景整理下来这套方案的适用场景有这么几类产品手册和操作指南。这类文档图特别多每个功能界面的截图旁边配说明文字图里的按钮名、菜单路径经常是用户提问的高频对象。技术方案文档和行业报告。架构图、流程图、数据表格占比高视觉模型能把图表的核心信息转述出来检索效果明显提升。论文和专利 PDF。两栏排版、公式图片、实验截图纯文本解析容易乱图片区域解析后反而能抓住重点。不适合的场景也要说清楚纯文字型的书籍、标准文档用普通解析就够了不需要为了“上多模态”而上多模态成本和延迟都更高。另外如果图片是纯装饰性配图视觉理解反而会引入噪声。所以方案里必须加一层过滤逻辑这我在后面实操部分会重点讲。2. 环境准备与工具选型细节2.1 依赖安装与版本坑位先列一下我实际使用的基础依赖pip install pymupdf1.24.10 pip install transformers4.45.0 pip install torch2.3.1 pip install sentence-transformers3.2.0 pip install openai1.40.3 pip install qwen-vl-utils装 PyMuPDF 没有太多坑但要注意一点这个库有两个包名老版本的fitz和新版本统一用pymupdf。导入的时候用import fitz是传统写法新版本import pymupdf更规范。两套写法目前都能用但如果混用不同版本的 API很容易踩“某些页面对象取不到”的雷所以建议固定版本别追新追太急。Qwen-VL 这块如果你是调用官方 API 或者通过 DashScope 兼容接口接入只需要装openaiSDK 就够了按 OpenAI 格式调用。如果你是本地部署 Qwen2.5-VL-7B那建议用vLLM做推理加速transformers 直接加载也能跑但速度会慢不少一张 3090 或者 4090 在大部分场景下是底线。我测试环境用的是一台 4090 24G量化后跑 7B 模型压力不大。2.2 PyMuPDF 的五个关键 API在动手之前把这次方案真正会用到的 PyMuPDF API 摸清楚后面写代码才能心中有数。第一个是文档打开doc fitz.open(sample.pdf)这一行就完成了整个文档的解析之后可以通过doc.page_count获取总页数doc[i]获取第 i 页对象。PyMuPDF 的页面对象是懒加载的打开文档不会把全部内容解析进内存所以几十 MB 的 PDF 也能轻松处理。第二个是页面对象操作page doc[0] # 第一页页面对象上有三个核心方法page.get_text()获取文本层内容page.get_images()获取图片列表page.get_text(dict)获取结构化文本块带坐标。这套方案里面三个方法都会用到分工明确。第三个是图片提取images page.get_images(fullTrue) for img in images: xref img[0] pix fitz.Pixmap(doc, xref)这里有个坑要注意get_images()返回的只是图片引用列表不是图片本身。你要通过 xref 编号去文档对象里取 pixmap再进行后续处理。如果图片色彩空间不正常如 CMYK还需要先转成 RGB 再保存。第四个是按区域渲染裁剪clip fitz.Rect(x0, y0, x1, y1) pix page.get_pixmap(matrixfitz.Matrix(2, 2), clipclip)这招很关键。PDF 里的图片对象并不总能直接提取很多图是背景图或矢量组合画出来的比如 CAD 导出的 PDFget_images()拿不到理想结果。这时候直接把页面渲染成图再按坐标裁剪才能拿到完整的视觉区块。第五个是页面渲染pix page.get_pixmap(matrixfitz.Matrix(2, 2))渲染整页用于“整页图片型 PDF”的兜底策略。matrix 里的 2 是缩放倍数2 倍基本够用追求细节可以到 3 倍但图像体积会大很多交给视觉模型时延迟也更高。2.3 Qwen-VL 接入方式选择Qwen-VL 的接入路径决定整个项目的架构复杂度我的建议是分阶段第一阶段快速验证用 API。直接在代码里调用 DashScope 兼容接口把图片 base64 编码后传过去prompt 让它生成描述。好处是零运维不需要 GPU适合先把流程跑通、验证方案可行性。第二阶段规模化部署用本地推理。当文档量上来后每页图片都调 API成本和流量都很敏感。用 vLLM 部署 Qwen2.5-VL-7B-Instruct本机推理延迟在 2-4 秒内7B 模型的视觉理解能力对于图表描述、OCR 提取已经够用。大规模批处理时还可以用 vLLM 的异步接口做并发吞吐量翻好几倍。我在做这个项目时是先 API 验证效果再切本地部署。因为视觉模型的理解效果必须“先用起来看答案质量”如果一开始纠结部署细节很容易把项目拖慢。3. 实操流程把 PDF 变成图文统一的知识块3.1 步骤总览一个输入三个出口整个解析流水线可以用一张图概括这里用文字描述输入 PDF 后逐页处理每页产生三个输出——文字提取结果、图片区域定位结果、页面整体渲染结果。三者各自处理后归并成统一的知识块文字块清洗、规范化、切块直接作为文本内容进向量库。图片区块裁剪出小图送给 Qwen-VL 生成语义描述描述文本作为图片内容的“代理人”进向量库同时记录所属页码和原始坐标。整页兜底如果检测到页面是扫描版文字层为空且图片数极少直接整页渲染送视觉模型生成整页描述。这三种出口最后都会变成标准格式的文本记录结构大致如下{ id: doc1_p3_img2, content: ...图片描述文本..., page: 3, type: image, bbox: [100, 200, 400, 500], source_file: sample.pdf }统一之后向量化和检索就不区分来源了实现图文混检。3.2 页面文字提取与清洗细节文字提取本身不复杂复杂的是“提取后怎么洗”。def extract_text_from_page(page): 提取页面文本块带坐标信息 blocks [] raw_dict page.get_text(dict) for block in raw_dict[blocks]: if block[type] ! 0: # type 0 是文本块 continue text .join( span[text] for line in block[lines] for span in line[spans] ) bbox block[bbox] blocks.append({ text: text.strip(), bbox: bbox, page: page.number 1 }) return blocks这里有几个清洗要点不要只取get_text()的字符串结果。带坐标的结构化文本块才是 RAG 的好朋友后面做“文字块和附近图片关联”时坐标是唯一的关联锚点。移除页眉页脚噪声。PDF 的页眉页脚公司名、页码、日期会严重污染切块。判断逻辑通常根据文本坐标——页面上方 10% 区域和下方 8% 区域的短文本叠加“包含页码特征”的文本块直接丢弃。处理换行拼接。PDF 文本块经常被折行成多段直接join会有中间断句问题。我的方案是如果一行文本不是以标点结尾句号、冒号、分号下一行直接拼接时中间加空格如果本身是独立段落保留换行。这个细节直接决定切块质量后面检索命中率会差很多。多栏排版的还原。PDF 常见两栏布局默认读取顺序可能是从左栏中间穿插到右栏。坐标排序时要先按 y 坐标分栏再按 x 坐标排序。简单做法统计这页所有文本块的中位 x 坐标小于中位数的归左栏大于的归右栏各栏内部按 y 排序最后先左后右拼接。3.3 图片区块定位与提取的完整逻辑图片提取用的是两路并行的策略。第一路是直接提取图片对象第二路是根据版面分析兜底。def extract_images_from_page(page, doc, min_area2000, min_width50, min_height50): 从页面中提取有效图片列表 results [] page_rect page.rect page_area page_rect.width * page_rect.height # 第一路直接提取嵌入图片 for img in page.get_images(fullTrue): xref img[0] try: pix fitz.Pixmap(doc, xref) except Exception: continue # CMYK 或异常色彩空间转 RGB if pix.n - pix.alpha 4: pix fitz.Pixmap(fitz.csRGB, pix) # 过滤过小图片 if pix.width min_width or pix.height min_height: continue # 过滤装饰性小图标 if pix.width * pix.height min_area: continue # 保存为 JPEG压缩质量 85 足够 img_bytes pix.tobytes(jpeg, jpg_quality85) results.append({ type: embedded, width: pix.width, height: pix.height, image_bytes: img_bytes }) # 第二路渲染页面检测大图区域这里简化用空白区域检测思路略写 return results图片过滤的阈值非常影响知识库质量。我自己调参后的经验小图标、logo、装饰线全部过滤。这类图片很小比如小于 50x50 或者面积小于 2000 像素它们对用户问题几乎没有信息量反而会引入噪声。常见场景里一个箭头 icon 会被 Qwen-VL 描述成“图中有一个蓝色向右箭头”这完全没有检索价值。重复图片去重。PDF 里经常出现同一个 logo 在每一页重复出现提取后会有几十份相同图片全部送视觉模型纯属浪费。可以在全局维护一个图片内容的哈希指纹相同哈希只保留第一次出现的描述。图片坐标定位要用于上下文关联。提取的图片对象本身带坐标信息根据get_image_rects方法但嵌入图片的坐标不一定覆盖整个视觉区块。更好的做法是用page.get_text(blocks)配合空白区域分析来识别“完整图片区”但这样代码复杂度会上升不少。实际项目里我会先判断页面上是否有大块无文字区域如果有再从区域里找嵌入图片确保描述之间的独立性。3.4 Qwen-VL 描述生成与 Prompt 设计图片提出来了下一步就是让 Qwen-VL“看图说话”。这一步直接决定知识库里图片内容的检索质量Prompt 设计是核心中的核心。我使用的视觉模型 prompt 经过好几轮迭代最终定型为def generate_image_description(image_bytes, client, modelqwen-vl-plus): import base64 b64_image base64.b64encode(image_bytes).decode(utf-8) response client.chat.completions.create( modelmodel, messages[ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/jpeg;base64,{b64_image}}}, {type: text, text: ( 请详细描述这张图片的内容。要求\n 1. 如果图中有文字请完整提取图片中的所有文字包括标题、标签、按钮名、注释等。\n 2. 如果图片是图表柱状图、折线图、流程图、架构图请说明图表的类型、坐标轴含义、数据变化趋势、关键节点。\n 3. 如果图片是界面截图请描述界面上有哪些功能模块、菜单项、操作按钮以及它们的布局位置。\n 4. 如果图片是照片或示意图请描述主要物体、场景、动作并说明可能表达的业务含义。\n 5. 请用中文回答尽量使用名词化的短语便于语义检索。\n 6. 如果图片内容模糊、无意义或纯装饰性请回答『无有效信息』。 )} ] } ] ) return response.choices[0].message.content这个 prompt 里每个要求都有目的第 1 条强制提取图中文字这是 RAG 检索里最直接的匹配途径。比如用户问“设置里有没有夜间模式”如果设置页截图被正确提取描述文本里就有“夜间模式”四个字向量检索马上就能命中。第 2 条是针对图表类型的它要求模型不仅识别出是折线图还要说明趋势和坐标轴含义。这样用户问“Q3 的营收趋势如何”就能命中对应的图表描述。第 3 条针对界面截图。很多产品文档的提问集中在“这个功能在哪”按钮名、菜单路径被准确提取后答案可操作性大大提升。第 6 条是重要的防呆设计。视觉模型偶尔会对无效图片强行生成语义内容明明是个分隔线或纯色块它硬描述成“带有渐变效果的抽象背景”。这句 prompt 能让模型收敛输出减少噪声数据进知识库。3.5 文本切块策略和向量库构建图文描述都生成后最后一步是切块、向量化、入库。这里的切块策略和常见文本 RAG 略有不同因为图文混排的内容里文字块和图片描述块的大小差异很大。我采用的切块方案每个自然段落文本块默认作为一个 chunk如果段落特别长超过 500 字再按句号、分号分割成子块每个子块控制在 300 字左右设置 50 字重叠。图片描述的 chunk 独立成块不跟周边文字强行拼接。因为图片描述通常 100-200 字单独成块更利于精确检索。如果某一页中图片上下方紧挨着核心说明文字也可以做一个“图片 文字”的组合块这需要借助坐标判断我建议第一版先做独立块跑通后再优化组合。向量化我用的sentence-transformers里针对中文优化的 embedding 模型from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh-v1.5) chunks [] metadatas [] # chunks: 文本内容列表metadatas: 对应元数据 embeddings model.encode(chunks, normalize_embeddingsTrue)BGE 系列对中文长文档的检索效果比通用多语言模型要好一些特别是技术类名词、短语式描述。 embedding 维度是 1024加上 Qwen-VL 的描述作为文本块检索时能语义匹配“图里有什么”而不是只靠关键词。存储我用的是 Chroma简单够用。数据量大了可以换 Milvus但项目初期没必要上太重的依赖。3.6 检索问答与结果返回检索端做的事很常规把用户 query 向量化去知识库 top-K 检索拼上下文给大模型回答。def retrieve_and_answer(query, top_k5): # 1. 向量化 query q_embedding model.encode([query], normalize_embeddingsTrue)[0] # 2. 检索 topK results collection.query( query_embeddings[q_embedding], n_resultstop_k, include[documents, metadatas] ) # 3. 拼装上下文 context \n\n.join(results[documents][0]) # 4. 交给大模型回答 answer llm_client.chat.completions.create( modelqwen-plus, messages[ {role: system, content: 你是知识库助手请基于提供的上下文回答用户问题如果上下文不包含答案请明确说明。}, {role: user, content: f上下文\n{context}\n\n问题{query}} ] ) return answer.choices[0].message.content这一点上有个容易忽略的小技巧检索结果返回时把typeimage的块和typetext的块做加权处理。因为图像描述往往比文字短BERT 类模型对短文本的向量位置其实有偏不加区分地混合排序会让文本块永远排前面图片信息被淹没。我的做法是检索召回的候选里图片描述块额外加一个权重的相似度得分比如在原始距离上减 0.05确保图片信息有机会进 top-K。4. 图文关联的进阶处理与原理解析4.1 文字块与图片块的语义关联做到上面的程度系统已经能检索图片内容了但还有一个更微妙的问题图片的“回答能力”依赖视觉模型单方面的理解。有些图片必须结合周围文字才能理解其准确含义。举一个真实例子一张产品架构图图上只写了“接入层”“业务层”“数据层”如果模型把这些字提取出来了检索没问题。但如果这张图是一张抽象的流程图框里是“模块 A”“模块 B”没有任何业务说明模型描述就只能是干巴巴的“从模块 A 指向模块 B 的箭头”。这种描述用户很难搜到。解决思路是在进入 Qwen-VL 前把图片附近的文字块内容拼进 promptdef build_image_prompt_with_context(image_bytes, nearby_text, modelqwen-vl-plus): prompt ( 请详细描述这张图片的内容。要求\n 1. 完整提取图中出现的所有文字。\n 2. 说明图片的结构、流程、关系。\n 3. 结合以下图片周围的上下文文字推断图片表达的业务含义并补充描述。\n f图片周围的文字\n{nearby_text[:500]}\n 如果图片内容模糊、无意义请回答『无有效信息』。 ) # ... 同样的 API 调用这么做之后图片描述里会多出“上游网关接入层通过路由分发到业务服务模块”这样的语义化句子用户从功能角度提问也能命中图片。4.2 表格识别的特殊处理PDF 里的表格是 RAG 的另一个重灾区。PyMuPDF 的文本抽取会把表格里的数字一行行抽出来但行和列的关系完全丢失检索回来一大串数字模型没法理解哪一列对应哪个指标。我的方案是根据文本块的坐标重建表格关系def reconstruct_table_from_page(page): # 提取所有文本块的坐标 words page.get_text(words) # (x0, y0, x1, y1, word, block_no, line_no) # 按 y 坐标聚类成行按 x 坐标聚类成列 # 用简单聚类算法把坐标接近的 word 合并成单元格这个逻辑说起来简单实际调起来挺费劲。PDF 表格的边框线、横竖线对象也需要用page.get_drawings()去识别否则合并单元格、跨行列的表格依然解析不对。一个更务实的替代方案如果页面检测到明显表格特征大量文本块坐标对齐、且有横线对象直接把表格区域裁剪成图片交给 Qwen-VL 做“表格转 Markdown”。Qwen-VL 对结构化表格的理解能力相当好输出| 列1 | 列2 |格式的 Markdown再切块进知识库效果比纯坐标重建稳定得多。这也是多模态模型在 RAG 项目里真正的价值所在——它不跟 PDF 的底层格式纠缠直接从视觉层面“看懂”表格。4.3 排版还原对解析结果的影响整个方案下来我发现一个反直觉的结论解析精度不取决于工具而取决于对页面版式的应对。同样是 PyMuPDF同一份文档页面干净的单栏排版和页面花哨的市场宣传页解析结果天差地别。宣传页里文字绕着图片排、文本框互相遮挡、文字做了各种字体特效坐标顺序和视觉阅读顺序完全不一致。最终我的策略是“分而治之”先把 PDF 按视觉复杂度分桶——纯文本页走传统文本解析图片密集页走视觉截取混合页走图文关联解析。识别依据可以是“页面内图片面积占比 文本块数量 文本块平均宽度”这套启发式规则简单有效比“一刀切”的方案准确率高一截。这个思路对实际项目的启发是不要追求一个万能解析器而是设计一个能根据页面特征自动选择解析策略的调度器。纯文本、纯图、混合三种模式跑一遍留最优结果成本也可控。5. 常见问题与排查技巧实录5.1 文本层“幽灵文字”污染知识库这是 PDF 解析里最隐蔽的问题。有些 PDF 制作时存在隐藏文字层——复制粘贴能选中文字但肉眼完全看不见或者文字和背景重叠或者是上一版的残留内容。这些幽灵文字进入文本块切出的 chunk 是“看不见的乱码”检索时用户莫名其妙命中了一堆无意义文本。排查方法解析完成后随机抽 20 页文本块看是否有“无对应视觉内容的文字”。发现幽灵文字比例偏高时可以对文本块增加置信度过滤——将页面渲染成图然后用 OCR或视觉模型对整页进行文字识别把识别结果和 PyMuPDF 提取的文本块做交集低匹配度的文本块直接剔除。代价是每页要多跑一次视觉模型但对于要求高精度的知识库场景这一步值得。5.2 图片重复抽取导致大量冗余向量前面提到 PDF 每页角落的 logo 和装饰图会被重复提取如果不加哈希去重一个 200 页的文档会产生几百条几乎相同的图片描述 chunk。冗余数据会让检索结果里的相似内容扎堆图描述块霸屏 topK真正的正文反而被挤掉。我的去重策略很粗暴全局维护一个已处理图片的感知哈希集合提取每张图时先算 dHash汉明距离小于 5 就认作重复图只保留第一次出现的描述块。装饰图片的另一个识别路径是坐标——如果图片的 bbox 覆盖了页边距、页眉页脚区域大概率是装饰元素直接过滤。5.3 视觉模型的“过度解读”问题Qwen-VL 看图时偶尔会对不明确的视觉元素强行生成解释。比如一张空白背景上一个小红点模型可能描述为“红色圆形按钮可能用于提交或删除操作”。这种幻觉描述进入知识库后检索命中就是误答。给视觉模型 prompt 加“无有效信息”约束能缓解一大半问题但无法完全根除。我额外加了一层置信度过滤对生成的描述做长度统计少于 20 个字的描述大概率是无意义图描述里大量出现“可能”“似乎”“看起来像”这类不确定性词汇的也会单独打标记检索排序时降权处理。这种做法虽然朴素但确实把脏数据的负面影响降到了最低。5.4 检索命中图片描述但回答仍不准确的场景即使图片描述正确进了知识库下游大模型回答时也未必能正确使用。常见的问题是上下文里同时存在纯文本描述和图片描述大模型容易被文字描述带偏忽略了图片描述这块内容——因为视觉描述是“二手的”跟一手文字的权重在模型眼里是一样的但它往往是更关键的信息。一个提高图片描述影响力的办法是拼接上下文时明确标识视觉描述块的类型【图片描述】图3-2 系统架构示意图...加上这个标签后qwen 系列模型在回答时对图片内容的引用率明显提升。这个技巧没什么技术含量但对体验提升很直接。5.5 常用参数速查表我把整个方案里涉及的关键参数和推荐值整理成一张表方便直接照抄参数项推荐值说明PyMuPDF 渲染缩放倍数2.01.0 太糊3.0 体积大延迟高图片最小宽高50x50 像素过滤 icon 和小装饰图图片最小面积2000 像素进一步过滤噪声JPEG 压缩质量85视觉模型识别无压力文本块最大长度500 字超过则按句切分子块重叠长度50 字避免语义断裂图片描述 chunk独立成块不强行拼接上下文检索 topK5图文混合时至少 1-2 个图片块BGE 向量维度1024中文场景效果好Qwen-VL 生成温度0.3低温度减少幻觉输出5.6 性能优化实录整套流水线里最耗时的环节是视觉模型推理。API 模式每张图需要 1-3 秒一篇 100 页的图文混排文档假设每页平均 2 张有效图片就是 200 次视觉调用耗时将近 10 分钟。批量处理时这个时间是能接受的但如果要做增量更新或者在线解析就不太行了。我做的优化有三点一是并发。用ThreadPoolExecutor把多张图的视觉调用并发执行API 模式下并发数调 8-10 基本没问题耗时能从 10 分钟降到 2 分钟以内。二是过滤前置。在送视觉模型前把重复图和装饰图全部过滤掉减少无效调用。三是本地 vLLM 批处理。用 vLLM 部署 Qwen2.5-VL-7B配合/v1/chat/completions接口并发请求7B 模型在 4090 上 40 个并发请求的吞吐量大约 30-40 requests/min200 张图的批处理压缩到 2 分钟内。后期如果文档量巨大可以再上 Qwen2.5-VL-72B 提高理解精度但本地部署需要双卡 A100 起步普通团队量力而行。6. 经验总结与后续扩展方向6.1 踩过几次坑之后的核心体会这套方案跑完一轮之后我对“PDF RAG”这件事有了全新的认识文档解析的成败决定整个 RAG 项目上限的八成。很多团队把精力全花在 embedding 调参、prompt 工程、Rerank 模型上回过头来发现文档里图片信息压根没进来再好的检索和生成环节也救不回来。PyMuPDF Qwen-VL 的组合解决的是“解析层”的结构性问题——先用 PyMuPDF 把 PDF 拆解得足够细再用视觉模型补上图片语义。实际操作中我最大的体会是不要迷信单一工具的全能性。PyMuPDF 很强但它解决不了“看懂图”Qwen-VL 很强但它直接处理 PDF 原生格式效率低。两者结合各干各擅长的部分才是多模态 RAG 最务实的落地路径。另外想强调一点这个方案不是银弹。如果文档是超高精度扫描件、图片像素质量很低Qwen-VL 的 OCR 输出会大打折扣如果 PDF 本身带有复杂的水印层和文字叠加幽灵文字问题也要依赖更多启发式规则去压制。做 RAG 系统一定要给自己留出“脏数据率”的预期提前设计清洗和过滤模块别指望一次解析全部完美。6.2 这个方案还能怎么扩展后续值得扩展的方向大量存在我整理了几个优先级比较高的首先是表格结构化入库。现在的方案把表格交给视觉模型转 Markdown检索能力已经够用。但如果要做“某个数字在哪个季度达到峰值”这类精确查询还需要把 Markdown 拆成结构化 KV 存进元数据做属性过滤式检索。这块可以衔接 GraphRAG 的思路把表格里的维度表和事实表分离建图支持多跳查询。其次是多模态 embedding。目前是图片说明转文本再进向量库本质上还是文本检索。如果未来用支持图文统一向量空间的模型如 CLIP 类多模态向量模型用户可以直接发一张截图去找对应知识或者文本 query 匹配“视觉相似”的图块体验会再上一个台阶。不过这类模型在中文专业领域的效果还不太成熟。第三是增量更新机制。实际项目中文档是不断迭代的每个版本之间可能只改了一两个章节。全量重新解析的成本太高可以在 PyMuPDF 解析时计算每个页面的文本哈希和图片感知哈希新版本入库时只替换哈希变化的页面保留未改动的页面向量。这个机制对常态化更新的知识库非常关键。6.3 最后分享一个小技巧如果读者只想先快速验证“图片信息在 RAG 里的价值”不必一上来就搭全套。可以先拿 10 页图文 PDF用 PyMuPDF 把图片全提取出来人工挑选 20 张典型图片手写描述建一个微型知识库跑一遍问答对比“纯文字解析 vs 图文混合解析”的效果差异。我当初就是被这样的对照实验说服才坚定地走完整个方案的。先用最小成本验证价值再投入资源建设这是所有技术选型最稳妥的路径。