RAG数据导入实战：图文与PDF解析的选型逻辑与混合管道

搞个人知识库这几年我最大的体会是真正卡住 RAG 项目的往往不是模型选型也不是向量库调参而是数据导入这一步。尤其当你的资料库里出现 PDF 和图片的时候问题一下子变得特别现实——同样是 PDF有的是出版社直接排版导出的文字版有的是扫描成图像的影印版还有的是图文混排的教材和产品手册。这三种情况完全不是同一种解析方案能搞定的。这篇是 RAG 数据导入系列的第二章我专门把图文与 PDF 解析这件事掰开揉碎讲清楚围绕 OCR、多模态大模型以及九种主流 PDF 处理工具逐一过一遍把边界条件、选型逻辑和实际踩坑点都说透。PDF 这个东西最大的迷惑性在于它看起来是一种格式实际上是一篮子格式的统称。同样是 .pdf 后缀文件内部可能是一个带文字层的文档流可能是一堆 JPEG 图像的打包容器也可能是文字层破损、只有残存乱码的半扫描件。如果你把解析结果直接丢给 RAG后面检索效果差十有八九问题出在这一步。本文不会只罗列工具我会把“什么时候必须上 OCR、什么时候上多模态模型、什么时候普通文本提取就够了”的判断逻辑讲清楚再给出一个可以直接照抄的混合解析管道。无论你用的是 LangChain 系框架还是自己手写的简单 RAG这套思路都能落地。1. 图文与 PDF 为什么是 RAG 数据导入中最难啃的骨头1.1 PDF 不是一种格式而是一篮子格式的统称很多人第一次做 RAG 数据导入时默认把“解析 PDF”当作一件简单的事无非就是调个库把文本抽出来。但实际操作几次就会明白PDF 内部结构差异极大不同来源的 PDF 在解析难度上是天壤之别。文字版 PDF由 Word、LaTeX、排版软件直接导出内部包含字体信息和文本流可以用文本提取工具直接读出完整内容。这类 PDF 最好处理但问题往往出在阅读顺序和版面复杂结构上。扫描版 PDF本质是若干张图片合订成的容器每一页就是一张大图内部压根没有文字层。用普通文本提取工具读出来只会得到空字符串。这种文件必须走 OCR。混合版 PDF部分页面有文字层部分页面是图片或者文字层存在但字体映射损坏提取出来的全是乱码和空格。这类情况最坑因为你无法简单地“有文字层就提、没文字层就 OCR”。图文混排型 PDF常见于教材、技术手册文字、表格、公式、流程图混排。解析出的文本虽然在但图表信息全部丢失。还有一个非常实际的问题大量民间流通的 PDF 其实是劣质扫描件的二次压缩产物页面上还有水印、书脊阴影、手指遮挡OCR 识别准确率会大幅下降。这类数据如果不做预处理后面无论用什么模型召回质量都会受影响。1.2 一个反直觉的认知盲区嵌入图片中的表格和信息说到图片型内容很多人第一反应是“图片里的文字用 OCR 提出来不就行了”但这里有个认知盲区。图片里不仅有文字还有表格关系、层级结构、流程图逻辑。比如一张设备拓扑图文字节点之间的关系靠连线表达一张柱状对比图数值的高低关系靠图形表达。这些关系信息传统 OCR 完全无能为力。这也是为什么我在标题里把“图文与 PDF 解析”放在一起图像型信息的入库问题本质上不是一个“识别文字”的问题而是一个“结构还原”的问题。你需要的不是把图片翻成文字而是让后续的检索单元能理解这段内容表达的是什么关系。这里就牵扯到多模态模型介入的必要性后文会展开讲。1.3 本篇文章要解决的三个问题边界为了避免文章变成无意义的工具罗列我先明确这一篇要围绕哪几个核心问题展开什么时候必须上 OCR什么时候普通文本提取就够了。判断标准是什么不依赖人工逐个翻页的办法有没有。传统 OCR 和“多模态大模型读图”各自擅长什么、不擅长什么。两者的成本、速度、准确率差距到底有多大。面对多种类型的 PDF 和图片一个工程上可落地的混合管道怎么搭。工具选型怎么定预处理怎么设计切块怎么规避乱序。搞清楚这三个问题你自己的知识库数据导入就不再是个玄学问题而是变成一条条可以测试、可以量化的工程流程。2. OCR 路线从 Tesseract 到 PaddleOCR 的边界判断与落地细节2.1 先判断要不要 OCR文字层检测的简单方法很多教程一上来就推荐 OCR实际上是不负责任的。文字版 PDF 去跑 OCR不仅耗时翻倍还可能因为识别误差引入原本不存在的错字。正确做法是先判断目标 PDF 有没有可用的文字层。我常用 PyMuPDF 做快速检测逻辑很简单import fitz # PyMuPDF def check_text_layer(path, sample_pages10): doc fitz.open(path) total_chars 0 total_pages min(len(doc), sample_pages) for page_num in range(total_pages): page doc[page_num] text page.get_text(text) total_chars len(text.strip()) doc.close() return total_chars, total_chars / total_pages if total_pages else 0如果平均每页提取字符数极低比如低于 50基本可以断定这个 PDF 没有有效文字层直接进入静默降级把该文件标记为“需要 OCR / 渲染成图后多模态识别”。如果字符数正常但肉眼抽检发现乱码、断字严重则说明字体映射损坏也需要先做修复或者干脆当扫描件处理。注意这里有个容易犯的错文件有文字层不代表文字层可靠。有些 PDF 的“文字层”是 OCR 软件自动生成的文本本身错漏百出直接当正常文本提取入库等于把错误知识喂给模型。我的习惯是抽几页渲染成图片肉眼对比提取文本和原页面的差异再决定走哪条路。别嫌麻烦这一步省下的是后面一排排的脏数据。2.2 Tesseract、PaddleOCR 与腾讯开源 OCR 的横向取舍一旦确定走 OCR接下来就是选引擎。这几年的开源 OCR 生态已经很成熟主要选手有这几个OCR 引擎定位中文支持速度优点主要限制Tesseract传统开源 OCR老牌经典一般需下载语言包中轻量、跨平台、可训练复杂版面处理弱中文准确率一般PaddleOCR含 PP-StructureV2百度开源的现代 OCR 套件优秀较快GPU 下更好自带版面分析、表格识别中文场景实测最稳依赖库较重部署稍繁琐腾讯开源 OCR含 OcrTr 相关模型面向语种识别优化的模型优秀中对多语言场景有专门优化生态与工具链不如 Paddle 完整RapidOCRPaddleOCR 模型的 ONNX 精简版优秀快CPU 友好不依赖 Paddle 全家桶部署清爽功能比原版少一些更新有时滞后我自己在中文知识库场景下长期主力是 PaddleOCR 这一挂。原因是它的 PP-StructureV2 不只是 OCR还能做版面分析、表格还原和阅读顺序恢复。单纯把字识别出来和把一页的语义结构还原出来是两码事。后面工具选型章节我会专门讲它。如果在低配机器上部署或者只是给一个轻量工具脚本用RapidOCR 会更舒服因为它是 ONNX 模型不需要装 Paddle 全家桶。如果你处理的是韩文、日文等多语种材料腾讯那套针对语种优化的模型值得一试。我也遇到过 PaddleOCR 默认模型识别韩文失败的情况后来查了才知道是语言模型没指定对应语种包要额外下载并不是引擎不行。2.3 OCR 之后真正的坑版面恢复与阅读顺序很多人以为 OCR 识别完文字就完事了实际上这只是开始。OCR 引擎输出的通常是一堆带坐标的文本块如果不做版面恢复后面的切块会出大问题。举个真实的例子一页 PDF 有三栏排版OCR 直接按坐标输出的话顺序可能是“左边栏第一行”“中间栏第一行”“右边栏第一行”……割裂了段落语义。传统 RAG 对 chunk 的切分基于文本流顺序错乱直接导致语义错位。就算检索到了相关内容完整段落也是碎的。解决办法有两个层级如果你用的工具自带版面分析如 PaddleOCR 的 PP-Structure把“版面分析 阅读顺序”选项打开它会根据标题、段落、表格、图片区域重新组织文本流。这是首选方案。如果没有版面分析能力退而求其次把 OCR 输出保存为带坐标的 JSON 或 DataFrame按“自上而下、自左而右”的阅读规则自行排序。多栏页面尤其要用 y 坐标先分栏再按 x 坐标排序而不是直接按 y 坐标线性排。还要提一个细节页眉页脚和页码必须在 OCR 后的清洗阶段删掉否则每次切块都会带进大量噪声。账单、教材这类文档页眉页脚的重复信息会显著污染向量检索的相似度计算。我的做法是在文本流中识别连续出现超过三页且高度相似的短行直接丢进黑名单过滤掉。3. 多模态大模型解析 PDF从“看图识字”到理解图表关系的升级3.1 为什么纯 OCR 解决不了信息损耗问题如果你只是想提取大段文字的扫描件OCR 是够用的。但 RAG 知识库里常见的资料往往夹杂着大量图表。图的语义不是文字能闭环的对比柱状图、环形占比、拓扑线、泳道图、时序图它们的信息主体是空间关系和数值映射。一个很实际的例子产品规格书里的参数对比表用 OCR 提出来虽然能保留文字内容但表头结构、单元格归属一旦丢失后续检索“支持 Wi-Fi 6 的型号有哪些”这类问题时模型从散落文本里找不到明确的对应关系。这时候多模态大模型的价值就体现出来了——它能把一整张图或一整页版面作为输入观察空间布局直接输出结构化的描述。3.2 把 PDF 页面渲染成图交给多模态模型主流的做法并不复杂用 PyMuPDF 将 PDF 页面渲染成 PNG然后送给支持视觉输入的多模态大模型让它生成结构化的输出。整体链路是用 PyMuPDF 以较高分辨率建议 150-200 DPI渲染页面将渲染后的图片交给多模态模型提示词中要求“完整还原页面信息输出结构化 Markdown表格用表格语法公式用 LaTeX不要遗漏页面中任何文字”设定 temperature0避免模型自由发挥对输出做文本清洗和校验再进入切块阶段。本地方案我实测过用 Ollama 加载 MiniCPM-V 或 Qwen2-VL 系列模型一台普通 8GB 显存的显卡就能对中文扫描件跑出可用的结果。速度上每页大概 2 到 5 秒跟 PaddleOCR 差不多但输出结构要好得多。如果你是零基础搭建本地知识库参照“ollama 简易本地 RAG 知识库”那类流程就能跑通只是要把输入端换成我刚才说的渲染步骤。3.3 多模态模型也有明显短板大表格、复杂公式、密集版式多模态模型并非万能我用下来有三类情况必须人工介入或退回传统 OCR超大表格几十列、上百行的密集表格直接给模型读图很容易出现列错位、数值张冠李戴。这时候反而建议用 PP-Structure 的表格识别模块单独处理再回填上下文。复杂数学公式模型对稀疏公式的识别不错但遇到多行推导、复杂符号堆叠时经常给出结构正确但系数错误的 LaTeX。涉及公式类资料最好人工抽检OCR 加后规则校验也是办法。页面内多个独立语义块比如报纸式排版一页包含七八个互不相关的新闻条目多模态模型容易只输出视觉上占据主要篇幅的内容边角料被漏掉。应对策略是先把页面按区域切图再分块送入模型。为了减少漏项我习惯在提示词里强制要求它“逐区域扫描”并且在解析后用一个简单的字符数校验拿渲染图的提取文本字符数与多模态输出的字符数对比如果后者明显偏少就标记为疑似漏页进入人工抽检队列。这个自动化校验非常管用。3.4 OCR 和多模态大模型的组合策略实际项目里OCR 与多模态模型不是二选一而是各用所长纯文字扫描件PaddleOCR/PP-Structure 够了速度快、成本低。图文混排、PPT 截图、产品手册多模态模型直接读整页还原关系结构。包含复杂表格的财务或合同材料先 PP-Structure 表格识别再用多模态模型补足版面上下文。需要字段抽取的场景比如合同里抽收入、单位、时间等关键字段多模态模型配合结构化输出比 OCR 加正则稳定很多。这也是很多用百度 OCR 做合同识别的人最终转向大模型的原因——字段级的正则规则属实维护不动。这种组合策略也决定了后面管道设计文件先分流再按类型走不同处理路径而不是一个工具打天下。4. 九种 PDF 解析工具选型对照表与实测体会4.1 快速选型对照表这一节直接上核心对比。九种工具我按实际用途、适合场景、限制条件列了一张表。每个我都实际跑过不是只看过文档。工具核心能力最适合的场景主要限制我的实测心得pdfplumber基于坐标的文字与表格提取文字版 PDF中的规则表格、字段位置定位对扫描版完全无效PDF 很大时速度偏慢表格抽取得失控制好但碰上合并单元格容易错位PyMuPDFfitz文本提取、页面渲染、文档拆合快速提取文字、把页面渲染成图片供多模态模型无版面理解、纯坐标输出全能型工具检测文字层、渲染页面全靠它pypdf纯 Python 的 PDF 处理库拆分合并、旋转、简单文本提取提取复杂版面文本能力弱轻量可靠适合做预处理工具链Camelot基于可视化规则的表格抽取文字版 PDF 的精确表格还原需要 Ghostscript 依赖扫描版无效对有线表格效果惊艳无线表格需要 Lattice/Stream 模式切换tabula-py基于 Java 的表格抽取规则表格批量处理对不规则表格力不从心胜在稳定适合简单的数据表格复杂场景我用 Camelotmarkitdown微软开源转 Markdown把 PDF、Office 转成 Markdown 喂给 LLM对复杂版面细节还原一般对 LLM 场景友好输出结构干净unstructured分区抽取、多格式通用构建通用 RAG 预处理管道依赖较多Performance 不稳定灵活性高但对中文版面容易拆错区块LangChain PyPDFLoader / PDFPlumberLoader框架集成快速嵌入 LangChain 生态的场景还是底层工具的封装无额外能力适合快速原型生产级用还得自己封装PP-StructureV2PaddleOCR 套件版面分析 OCR 表格识别中文扫描件、图文混排的完整结构化依赖重、部署稍麻烦中文知识库项目最值得投资的工具4.2 不同应用场景下的选型原则场景一文字版 PDF 转文本入库首选 pdfplumber 或 PyMuPDF。pdfplumber 的优势是能拿到字符的精确坐标方便做阅读顺序的二次处理。PyMuPDF 优势是速度快整本 500 页的书几秒钟就能抽完文本。我通常的组合是用 PyMuPDF 快速抽取 pdfplumber 对可疑页面做细查。场景二扫描版中文 PDF 完整入库直接上 PP-StructureV2这是目前中文环境下我的首选。它内部整合了版面分析、文本检测、文本识别、表格识别四个模块输出是结构化 JSON。你要做的只是把 JSON 按阅读顺序组装成 Markdown 或纯文本。唯一要花点心思的是环境部署——Paddle 全家桶装起来比较占空间但收益是值得的。如果你的环境装不了 Paddle那就用 RapidOCR 加自写的版面排序逻辑也能达到八成效果。场景三需要 Markdown 格式直接喂给 LLM / RAG用 markitdown 或者 unstructured。markitdown 的开箱体验更好直接把 PDF 转成干净的 Markdown特别适合“PDF 转文档语料”的场景。unstructured 的好处是可以按元素类型Title、NarrativeText、Table、Image分区输出这对 RAG 切块非常友好——你可以把表格和正文分开处理再决定是否合并。但它的中文版面分析质量不如 PP-Structure而且依赖树比较深换一台机器环境就崩的情况我遇到过好几次。场景四只抽表格Camelot 和 tabula-py 是专门干这个的。tabula-py 接入简单但表格结构复杂时识别不准。Camelot 的 Lattice 模式对有线表格还原度很高。需要注意这两个工具都只处理文字版 PDF如果 PDF 是扫描件必须先走 OCR 生成文字层或直接改走 PP-Structure 的表格识别模块。4.3 一个容易忽略的决策逻辑先从 PDF 类型判断工具而不是先选工具很多初学者容易犯一个错误先选一个喜欢的库然后所有 PDF 都往里面丢解析失败就换下一个库。正确的决策顺序应该是先判类型文字版 / 扫描版 / 混合版。再判目标只要正文文本还是要表格结构还是要版面关系。最后选工具按上述场景匹配表格里的工具体系。这个判断顺序能帮你省下大量无效尝试的时间。我自己最初踩过的坑就是迷信 “unstructured 能搞定一切”结果在扫描版教材上浪费时间最后才发现该上 OCR 的时候不要绕路。5. 一套混合解析管道的落地配置检测、分流、排序、切块5.1 管道整体设计前面几章讲的都是工具和思路这一章给可以照着抄的管道设计。整体流程分四段输入检测段抽取 PDF 元数据、页面数、文字层有效字符数判定文件类型。分流段按类型把文件分派给不同的解析器。结构化段把解析结果统一转成 Markdown 或带元数据的文本块。清洗与切块段过滤页眉页脚、合并段落、控制切块尺寸再进入 embedding。5.2 用 Python 快速实现一个分流器下面这个代码是我实际在用的精简版包含文件类型自动判断和解析器分派逻辑import fitz import pdfplumber from pathlib import Path import json def detect_pdf_type(pdf_path: str, char_threshold: int 50) - dict: 判断 PDF 是否有可用文字层 doc fitz.open(pdf_path) result { path: pdf_path, pages: len(doc), text_chars: 0, type: unknown, } sample_pages min(len(doc), 10) total_chars 0 for i in range(sample_pages): text doc[i].get_text(text).strip() total_chars len(text) result[text_chars] total_chars result[avg_chars_per_page] round(total_chars / sample_pages, 2) doc.close() if result[avg_chars_per_page] char_threshold: result[type] scanned # 扫描版走 OCR / 多模态 else: result[type] text # 文字版走文本提取 return result def parse_pdf(pdf_path: str): info detect_pdf_type(pdf_path) if info[type] scanned: return parse_scanned_pdf(pdf_path) # 走 PP-Structure 或多模态 else: return parse_text_pdf(pdf_path) # 走 pdfplumber / PyMuPDF def parse_text_pdf(pdf_path: str) - str: # 优先用 pdfplumber 提取文本保留坐标信息供后续排序 full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text page.extract_text(x_tolerance2, y_tolerance2) if text and text.strip(): full_text.append(text) return \n\n.join(full_text)这里有个细节我特别提醒pdfplumber 的extract_text有两个宽容度参数x_tolerance和y_tolerance。默认值在遇到多栏文本时经常把同一栏的文字拆散或者把两栏内容交叉混排。我实测下来x_tolerance2能有效缓解文字忽左忽右导致的断行问题。如果你解析的 PDF 是专业排版、字符间距特别大还需要调大这个值。直接使用默认参数处理复杂版面效果很难看。5.3 扫描版 PDF 解析OCR 与多模态模型的接口封装扫描版方面我封装过两条路径按机器配置切换轻量路径RapidOCR 提取文本返回带坐标的块列表再按阅读顺序组装。完整路径PP-StructureV2 做版面分析直接输出带结构标签的 JSON。多模态路径PyMuPDF 渲染页面为 PNG提交本地 Qwen2-VL输出 Markdown。实际生产环境你是想全部用“完整路径 多模态抽检”的组合。PP-StructureV2 负责批量处理速度相对可控多模态模型只对 PP-Structure 输出可疑、文本量偏低、或版面特别复杂的页面出手。这个组合既保证质量又控制成本不会让 GPU 打满却没产出。5.4 清洗与切块的三个关键控制点解析出文本之后还有三道工序我分别踩过不同程度的坑写在这里当备忘第一页眉页脚过滤。规则可以是“跨页重复出现且字符长度小于 30 的行直接剔除”。但要注意别误伤正常的短标题。我的过滤器会结合页面位置判断出现在页面顶部 10% 区域或底部 10% 区域的行才进入候选黑名单。第二段落合并。OCR 输出常常把同一段落切成多行如果直接按行切块向量化噪音很大。简单有效的方法是以空行作为段落分隔符如果两行之间只有一个换行没有空行就合并成同一段落。这一步做完chunk 的质量会有肉眼可见的提升。第三切块边界的避免。RAG 切块时如果只按固定字符数硬切很可能把表格的一行、段落的一半从中断开。我固定在切块前对 Markdown 输出做格式感知优先在标题、空行、列表项边界处切表格单独成块不跟正文混切。这个规矩看起来基础但能救回大量检索时的上下文完整性。def split_into_chunks(markdown_text: str, max_chars: int 1000) - list[str]: # 简单示例优先在空行处切超长再强制切 blocks markdown_text.split(\n\n) chunks [] current for block in blocks: if not block.strip(): continue if len(current) len(block) max_chars: if current.strip(): chunks.append(current.strip()) current block else: current \n\n block if current.strip(): chunks.append(current.strip()) return chunks5.5 用质检指标给整条管道兜底管道搭完后要有一个自动质检环节不然你永远不知道解析精度会不会在线性恶化。我常用的指标有三个页面级提取率提取字符数 / 渲染页面估算字符数可以用图像面积按经验估算低于阈值则标记重试。表格结构校验表格解析后行列数和原始页面对齐情况抽查自动比对。多模态复查率对随机抽样的 5% 页面做多模态模型二次解析对比主要差异。这个质检不需要很精确它的目标是兜住明显异常比如某页因为渲染分辨率太低导致 OCR 一片空白或者工具版本升级后解析逻辑出现兼容性问题。没有这道质检数据管道跑一夜后你只会收获一堆默默污染知识库的坏数据。6. 图片型内容进 RAG 的三种姿势文本化、描述化、多模态检索6.1 直接回答“RAG 知识库到底能不能存图片”这个问题问的人太多了因为很多人的知识库里确实需要管图片产品图、聊天截图、流程图、拍摄的试卷照片、问卷拍照内容。答案是可以但要知道存的方式和存文本完全不同。向量库本质上存的是向量不是图片文件本身。图片要么被转成一段文本后嵌入要么通过专门的视觉编码器变成一个向量。如果直接把图片二进制文件丢给常规文本 embedding 模型得到的向量没有包含图片语义检索基本作废。所以“图片进 RAG”实际要决定的是图片的语义用哪种方式表达。6.2 姿势一OCR 文本化简单但丢信息把图片 OCR 成一段文字然后当普通文本向量化入库。这个方案最省事但有两个天然缺陷图表中的关系性信息会丢失比如流程图的分支逻辑、拓扑图的连接关系。检索命中后返回的是文本如果用户希望看到原图你还需要额外维护“文本块-原图路径”的索引关系。它的适用场景是纯文字的截图、合同拍照件、问卷答案照片。这类图片的信息主体本来就是文字OCR 化几乎没有损失。文本化足够解决大部分实际需求。一个实际例子问卷系统里的拍照上传功能用户拍一张纸质问卷后台 OCR 识别出答案文本再进知识库。这种场景只用 OCR 文本化就够了没必要动用多模态模型。6.3 姿势二描述化Image Captioning保留原图增强语义第二种做法是先用多模态模型给图片生成一段结构化描述比如“这张图是网络拓扑图中间是核心交换机向下连接三个接入交换机……”然后把这段描述向量化入库同时保存原图路径。检索时命中描述文本再将对应的原图展示给用户或交给下游模型。这个方案最适合“图片本身就是核心资产”的场景产品手册中的结构爆炸图、UML 类图、系统架构图、流程截图。它比 OCR 文本化的优势在于描述的语义是显式的模型能看懂各元素的布局关系检索时以“拓扑”“链路”“分支”“上下级”这类关系词命中而不是靠零散的文字词汇碰运气。实际项目中我会把原图的缩略图 URL、原始文件路径、描述文本三样东西都存进元数据保证下游无论走 LLM 还是走人肉查看都能回溯到真实图片。6.4 姿势三多模态联合检索图文向量直查如果知识库本质是“图多文少”的图片库比如相册、设计素材库、图纸库那么 OCR 和描述文本都很绕路。更直接的做法是用视觉 embedding 模型把图片本身编码成向量与文本向量一起放进同一个向量索引查询时用户输入文字命中图文混合的向量。常用的视觉编码器包括 CLIP 系、SigLIP、Jina CLIP v2 等。查询过程是用户自然语言 → 文本编码器转成向量 → 在混合索引里按余弦相似度找最相关的图片和文本块。这样既可以用文字搜图也能用图搜图。这个方法的问题是部署成本和硬件需求相对高视觉编码器和文本编码器要保持对齐建议在中小规模图片库上先用别一上来就想管理上百万张图。对大多数个人知识库和中小公司来说描述化方案已经够用了。6.5 三种姿势的混合使用建议现实中我不会只用一种姿势。常见的混合策略是图片类型主方案辅方案纯文字截图/单据OCR 文本化预留原图路径产品图/宣传图多模态描述化OCR 提取图中文字做兜底流程图/架构图多模态描述化原图入库文本块关联原图素材库/照片集多模态联合检索人工标签补充这个混合策略在数据导入时只多花一点额外算力在检索端的体验会提升很多。每类图片的解析结果都会带上 type 标签检索时可以在元数据里做类型过滤需要图文证据链的时候按图索骥不需要时直接返回文本答案。支撑这种混合策略的工程前提就是前几章讲的那条混合解析管道文字层检测、OCR 分流、多模态补充。链路统一了图片处理就不再是知识库项目中的第二个方案而是和文本处理平级的一条完整通路。我在搭这条管道时最深的体会是数据导入流程里每一步看似都在处理“格式”实际上处理的都是“保持语义完整性”这件事。PDF 解析选型也好OCR 兜底也好多模态读图也好全都是在尽量还原原始文档的信息结构而不是把文字榨出来那么简单。刚起步的时候不用追求一次性搭出完美的管道最可行的路径是先用文字版 PDF 跑通全文链路再逐步加入扫描版和多模态最后再把图片描述化补进来。每加一层用二三十个真实样本对比一下召回质量你会很清楚地看到哪一层的投入产出比最高。