企业官网建设流程全解析

做 RAG 项目做得多了，你会发现一个特别有意思的现象：很多人把瓶颈挂在模型身上，觉得召回不准、生成不对，问题都出在 Embedding 或大模型上。但真跑到生产环境，最先卡壳的往往是数据入口。你备好了一批 PDF、扫描件、图文混排的说明书，结果要么解析出来一堆乱码，要么结构化信息全丢，最狠的时候连表格都给你拆成一片糊的文本。这一篇继续更新 RAG 数据导入与解析系列（二），专门啃图文与 PDF 解析这块硬骨头，把 OCR、多模态大模型和九个常用 PDF 工具逐个讲透。正在搭 RAG 知识库、做文档问答、或者刚被一堆扫描件折磨过的读者，这篇应该能直接拿来用。

1. 图文与 PDF 解析为什么是 RAG 落地的第一道高墙

1.1 文档类型那么多，解析逻辑完全不同

RAG 系统里的“导入”不是把文件丢进数据库，而是要把文件里的信息变成可检索、可喂给大模型的文本块。这一步的难点从来不是“把字符读出来”，而是“把版面信息保住”。

PDF 这个格式本身就是个壳：里面可能是带文字层的电子文档，可能是扫描图像，可能是图文混排的标书，还可能是扫描后扔进 OCR 软件再另存的“假文本”。文字版 PDF 直接提取即可，扫描版要靠 OCR 二次识别，复杂版面还涉及阅读顺序、表格结构、标题层级、图片区域这些在原始渲染里肉眼可见、在纯文本里却极其容易丢失的信息。

举个例子。我处理过一份某公司的制度汇编，首页是扫描封面，中间是文字版正文，穿插了三张组织结构图和一张费用报销审批流程图。如果只拿最常见的“按页抽文本”工具去处理，结果就是封面全是乱码、正文顺序错乱、组织架构图彻底消失。后续不管是做关键词召回还是给大模型做上下文，这些问题都会直接压低回答质量。可以说，解析层做得糙，后面 Embedding、检索、生成的调优全部白费。

所以先把思路理顺：文本型 PDF、扫描型 PDF、图文混排型 PDF，这三类必须走不同的解析路线。能用文本层解决的不要硬跑 OCR，能用 OCR 解决的不要急着上多模态大模型。不是工具越贵越聪明越好，而是合适场景的工具组合才靠谱。

1.2 别拿“识别率”当唯一指标，这四个维度才决定 RAG 效果

很多人在选 OCR 和 PDF 工具时只看一个指标：字准不准。但放在 RAG 场景里，准确率只是及格线，真正决定效果的是四个维度：

第一是上下文保真度。解析出来的文本块能不能保留阅读顺序？标题、段落、列表、表格的层次是否还在？第二是结构还原能力。表格有没有保持行列关系？图表区域有没有被正确识别并单独处理？第三是坐标与元数据可用性。每个文本块能不能回溯到原 PDF 的页码、坐标、字体大小？这对做引用溯源、精准定位原文非常重要。第四是吞吐与成本。解析一万页和一百万页，方案完全不同。

这四个维度对应到具体项目里，就是“召回准不准”和“引用能不能找到原文”的直接来源。我见过不少朋友在调 RAG 的 Top-K、改写 Query 上花了很多时间，结果回头一看，解析阶段把段落顺序打乱了，表格数据散落在四个 chunk 里，大模型再聪明也拼不回来。解析层的小毛病会在后链路被放大，这才是 RAG 项目里最容易被低估的瓶颈。

2. OCR 实战：扫描件和图片进知识库前，先过这关

2.1 从传统 OCR 到深度学习 OCR，差距不只是准确率

OCR 不是新鲜技术，传统方法靠图像预处理、字符切割、模板匹配，对清晰印刷体还好，一遇到复杂背景、倾斜、模糊、表格线干扰就露馅。深度学习 OCR 则把整行文本作为识别对象，加上版面分析、检测框、置信度输出，在复杂场景里的鲁棒性完全不在一个量级。

在 RAG 项目里，我更建议直接选深度学习方案。除了识别率高，更重要的是它普遍带坐标输出。坐标这个能力对 RAG 太关键了：解析出来的每个词、每一行都带 box，你才能把版面还原到文本块级别，才能在回答用户问题时返回“答案在原文档第几页第几段”。传统 OCR 给一堆不带位置的文字，后续连 chunk 切分都做不精细。

另一个差距是语言覆盖。中文、英文混合、表格数字、印章遮挡，这些在真实扫描件里太常见了。传统 OCR 遇到中英文混排经常发生英文被切开、中文缺字的情况，而深度学习模型大多能整行输出，再配合语言模型纠错，效果会稳定很多。

2.2 中文场景实测：Tesseract 与 PaddleOCR 怎么选

中文场景下我实测过两条典型路线：一条是 Tesseract + 中文语言包，一条是 PaddleOCR。结论很直接：如果文档是清晰印刷的中文，两者都能用，但 PaddleOCR 对中英文混排、表格、低分辨率扫描件的情况要好得多。

Tesseract 的优势是轻量、离线、部署简单，适合英文文献和干净的印刷体。你只要装 tesseract-ocr 和 chi_sim 语言包，命令行就能跑。但遇到中文扫描质量一般、有背景色或者字体稍微花一点的情况，错字率会明显上升，而且输出里没有直接可用的坐标，需要额外用 hOCR 格式才能拿到位置。

PaddleOCR 走的是 PP-OCR 系列模型，一行命令就能跑起来，默认返回文本、置信度和四个角坐标。我在一份 300 页的中文扫描手册上测试，它把图注、页眉、页码都识别出来了，而且可以直接按版面输出。对 RAG 场景来说，这种“带坐标的文本流”简直是为文本块切分量身定做的。如果你要部署到 CPU 环境，也够用；批量比较大再考虑 GPU 加速。

有一点务必记住：OCR 识别到的内容不会自动保留原始阅读顺序。PaddleOCR 输出的检测框需要按“从上到下、从左到右”的页面顺序重新排序，否则正文会跳来跳去。这一步看着不起眼，却是后续 chunk 质量的分水岭。

2.3 OCR 结果一定要做后处理，别把错字直接送进向量库

我第一次把 OCR 结果直接喂进向量库时，检索效果惨不忍睹。不是因为模型不行，而是 OCR 输出的文本太“原生”了：有大量空格、换行错乱、页眉页脚重复、置信度很低的片段也混了进来。这些噪声一旦被 Embedding 模型编码，就会严重污染语义向量。

后处理至少要做四件事：过滤低置信度结果、去掉页眉页脚和页码、把同一段落里被拆开的行合并、对明显错字做规则纠正。规则纠正不需要追求完美，常见问题如“0”和“O”混淆、“1”和“l”混淆，用词典和正则就能处理大部分。高置信度保留原文，低置信度位置可以舍弃或者标记为待人工复核，保底策略比硬要“全对”更实用。

如果项目里已经有多模态大模型，后处理还能再加一道：把 OCR 低置信度的局部区域截图，交给视觉模型重新读一遍，用二次结果覆盖或者投票。这个方案我跑过，对盖章遮挡、模糊数字特别有效，不过成本会明显上升，适合重要单据类文档，不适合全量扫描件。

3. 多模态大模型：什么时候上，怎么上，账怎么算

3.1 三种典型用法：图生文、版面理解、端到端问答

多模态大模型在 RAG 里的用法，我总结下来基本是三种。

第一种是图生文，也叫图片转描述。把 PDF 里的图表、架构图、流程图先截出来，再让视觉模型生成一段文字描述，然后像普通文本一样入库。这张图片本身也可以保留原始文件路径，方便溯源。第二种是版面理解加结构化输出。让多模态模型看一页 PDF 渲染图，直接输出 JSON，把标题、正文、表格、图注都结构化。这个东西比传统版面分析模型更灵活，尤其适合表单、发票、合同这类固定版式。第三种是端到端视觉问答，也就是跳过传统解析，直接把原始页面图片作为上下文喂给多模态模型做问答。这种模式理论上最保真，但成本高、延迟大，目前更适合小规模高价值数据，比如合同审阅、制度问答的精读场景。

3.2 多模态模型不是 OCR 的替代品，而是补充

我经常被问到：既然多模态模型什么都能看懂，是不是可以全面替代 OCR 了？答案很真实：不能，至少在 RAG 生产链路里不能。

OCR 的核心优势是“便宜、快、确定性强”。你跑一万页扫描件，OCR 的耗时和成本是可控的，输出的是确定的文本文件，后面怎么切块、怎么清洗都由你掌控。多模态大模型则每一步都在推理，速度慢一个量级，价格也高，而且输出结果有一定随机性。同样一份 PDF，跑两次可能给略有差异的描述。这种“不确定性”在知识库场景里很麻烦，因为你不知道哪个版本的描述进了向量库。

所以我的建议是分层用：大批量普通扫描件用 OCR 搞定，只有遇到 OCR 明显吃力、信息密度高、或者对结构完整度要求极高的文档，才把多模态模型请出来。它不是替代关系，而是补位关系。真正高大上的做法是让 OCR 先做粗筛，把置信度低的局部页面标记出来，再送进多模态模型精读。

3.3 成本、延迟、效果三方权衡的实操判断

把多模态模型用于数据解析，账一定要算细。我见过团队把所有 PDF 都送进视觉模型做图生文，结果一个月解析三百万页，云账单直接爆炸。我自己会按“文档价值”分三档处理：常规资料、低频访问的，走 OCR 加规则解析；业务合同、制度文件这样问答频率高、出错的代价大的，做多模态精读；涉及复杂图表、依赖视觉理解的，才考虑纯端到端视觉问答。

还有延迟问题。离线批量解析可以慢慢跑，但如果是用户上传文档后要即时入知识库的场景，多模态模型单页处理可能要两三秒甚至更久，前端体验会很难受。这时候通常要拆成“先入库可检索的粗文本，再异步补精读结果”，让用户先能问，精度慢慢补。这个“先粗后精”的思路在 RAG 生产里非常实用。

4. 九种 PDF 工具选型：先选对，再谈用法

4.1 九种工具一张速查表

把常见 PDF 解析工具按应用场景分了三组：文本层提取组、扫描识别组、AI 文档结构提取组。整理成下面这张速查表，实际选型时直接对着挑就行。

这张表只是一个起点。实际项目里，几乎没有哪一款工具能通吃所有场景，所以下面我会把三个分组各自的使用细节讲清楚，最后给一套我跑通过的组合配置。

4.2 文本层解析组：pdfplumber、PyMuPDF、pdfminer.six 怎么搭

文本层解析组处理的对象是“本身带文字层”的 PDF。也就是说，文件里的文字可以直接选中复制，不需要 OCR。这三款工具里，我先说最常被推荐的 PyMuPDF，因为它的性能非常夸张。一个几百页的 PDF，在我笔记本上几秒钟就能跑完，既能取文本，也能抽图片，还能拿到页面尺寸和坐标。用起来也很直接：

import fitz doc = fitz.open("sample.pdf") for page_index, page in enumerate(doc): text = page.get_text("text") # 可以继续用 page.get_text("blocks") 或 "dict" 获取更细的坐标信息 images = page.get_images(full=True) print(f"page {page_index + 1}, chars={len(text)}, imgs={len(images)}")

PyMuPDF 的问题是：它拿到的是“扁平文本”，不会帮你重建标题层级，也不会智能重组表格。对版面整齐的论文、说明书够用，但复杂表格会乱。这时候就该上 pdfplumber。

pdfplumber 个人感觉是“精细派”的代表。它对每个字符的位置、字体、大小都做了建模，特别适合做表格抽取。一个典型的用法是先把页面里的表格提取出来，再转成 DataFrame：

import pdfplumber with pdfplumber.open("report.pdf") as pdf: for page in pdf.pages: tables = page.extract_tables() for table in tables: for row in table: print(row)

pdfplumber 的缺点是慢，非常慢。批量处理大 PDF 时，速度能比 PyMuPDF 慢十倍以上。所以我的搭配习惯是：先用 PyMuPDF 快速过滤、抽主干文本；遇到表格密集的页面，再专门交给 pdfplumber 精处理。pdfminer.six 作为底层库，适合你自己想写定制布局分析的场景，普通项目里直接用前两个工具就够了。

4.3 扫描版与复杂版面组：PaddleOCR、Tesseract、Unstructured

扫描件没辙了才上 OCR，但 OCR 的处理不只是识别。PaddleOCR 我上面提过，它现在做中英文扫描件的首选。跑起来也不复杂：

from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang="ch") result = ocr.ocr("scan_page.png", cls=True) for line in result[0]: box = line[0] # 四个角坐标 text, score = line[1] # 识别文本和置信度 if score > 0.85: print(text)

这里有个很容易被忽略的细节：PaddleOCR 返回的文字是按检测框顺序排列的，多个框之间未必符合人的阅读顺序。我在处理双栏文档时踩过坑，识别结果左右栏交错，需要先按框的 y 坐标分成多行，再按 x 坐标排序，才能还原正确阅读顺序。

Unstructured 则是一把多面手。它不只是一个解析工具，更像一套文档处理框架，能处理 PDF、Word、PPT、图片，输出结构化的 elements。对于起步阶段、想快速搭个 Demo 的团队，直接用它一个库就能解决大部分格式的解析，不需要自己组装各种工具。只是它在复杂版面、数学公式上的表现没有下面那组专攻 AI 解析的强。

4.4 专为 AI 与 RAG 设计的解析组：Marker、Docling、MinerU

这三款工具的共同点是：它们的目标不是“提取文本”，而是“还原文档结构”。Marker 能把 PDF 转成 Markdown，标题、列表、表格、公式都能保留下来。我用它处理过带数学公式的 PDF，转出来的 Markdown 可以直接喂给支持 Markdown 的 RAG 切分器。它还有一个很友好之处：命令行就能用。

marker_single input.pdf output_dir --output_format markdown

Docling 是 IBM 开的源，对复杂版面布局的鲁棒性很强，输出格式也比 Marker 更丰富，带块级元素信息和阅读顺序。它对中文的支持也在持续改进。MinerU 来自 OpenDataLab，在复杂 PDF、扫描件、数学公式混合场景下的表现相当能打。我的经验是三款不用全上，先看你的文档特征：如果纯文本加简单图表，Marker 就够；如果有大量学术论文、公式，MinerU 更合适；如果要深度定制布局逻辑，Docling 更灵活。

4.5 我日常跑通的组合方案

分享一套我目前用得最顺的组合。普通文本型 PDF，先用 PyMuPDF 抽全文，再用 pdfplumber 补表格；扫描件统一走 PaddleOCR，识别后按坐标重排阅读顺序；高价值或公式多的文档用 Marker 或 MinerU 跑一遍 Markdown 输出；如果项目时间紧、格式杂，就用 Unstructured 做总入口。这套组合在大多数知识库项目里都能跑通，且每一层的成本都可控。

另外提醒一句：Copilot 类的日常办公 PDF 工具，比如一些在线编辑器、PDF 转 Word 软件，适合人工处理单份文件，不适合嵌入自动化数据管线。批量解析时，用命令行工具和 Python 库才能做缓存、增量导入和异常重试，人工工具没法进你的调度系统。

5. 从文件到向量库：一份可以直接抄的解析管线

5.1 第一步：前置分类，决定你走哪条解析路线

我见过太多解析任务失败，问题都不是出在解析环节，而是出在没分类。拿到一批文件就一个工具怼到底，后面全乱套。现在我的管线第一步永远是分类：判断文件格式、是否扫描件、是否有文字层、页面复杂度。

判断文字层很简单，PyMuPDF 直接看 get_text 拿出来有没有内容，如果为空白或者字符数极少，基本可以断定是扫描件。页面复杂度可以抽样：看看每页图片数量、表格区域大小、文字块数量。分类结果直接决定后续走哪条解析路径，这一步看似简单，却能省掉大量无效计算。我自己会把这个分类结果缓存起来，下次同一文件增量导入时直接复用。

5.2 第二步：解析、清洗、版面还原

拿到分类结果后，按前面讲的组合方案跑解析。解析完一定要做清洗，这不是可有可无：去页眉页脚、去重复空格、合并断行、过滤 OCR 低置信度区域。清洗之后做版面还原，我这里指的是把解析文本按“标题、段落、表格、图注”打上类型标签，并记录页码和块序号。

这一步做好了，后面切块就会特别省心。比如我可以按标题层级切块，表格单独作为一个 chunk，图注跟着对应图片走。元数据里带上 page、block_type、source_file 三个字段，之后做混合检索、做引用溯源都方便。这个过程的产出其实是一份“带结构的时间文本”，而不是简单地塞进文件到一个字符串里。

5.3 第三步：图片与多模态内容的入库策略

标题相关热词里有个经典问题：RAG 知识库能存图片吗？答案是能，但要看你的检索方式。如果你的知识库只是文本向量库，那图片必须转换成文本才能被检索，常见做法是让多模态模型生成图注，再把“图片路径 + 图注文本”一起入向量库，检索时以图注文本来召回，用户点开答案能看到原图。如果你的系统支持视觉向量模型，也可以直接把图片编码成视觉向量，检索时用文本和图片混合检索。这个方案更先进，但需要额外的向量模型支持和部署成本。

我的建议是：绝大多数团队先用“图注文本入向量库、图片路径存元数据”的方式起步。成本低、效果好、实现简单。等业务确实需要“看图找图”这种能力，再考虑视觉向量。知识库能存图片吗？技术上能，产品设计上先想清楚到底是存图片本身还是存图片的“文字理解”，这一步想明白，后面就不纠结。

5.4 吞吐量与成本控制心得

最后聊吞吐。解析管线如果不做缓存，重复导入同一批文件会很浪费算力。优化思路有两个：一是文件指纹去重，按文件内容的哈希值做缓存，重复导入直接跳过；二是分层解析，先出粗文本保证当天能用，晚上再跑复杂结构的精解析。这样既保证了知识库新鲜度，又不会让用户上传文档后干等。

成本方面，OCR 和 PDF 解析主要吃 CPU，批量任务建议用队列调度，控制并发数量，避免把机器跑满。高价值的文档才走多模态模型，且要走异步队列，不要阻塞主流程。这个账算下来，一个百万级文档的知识库，解析成本可以控制得相当低。

6. 现场排障：我踩过最深的几个坑

6.1 解析出来是空文本，八成是扫描件不是文本 PDF

空文本这个坑几乎人人都踩过。第一次拿到一个 PDF，用 PyMuPDF 提取后返回空字符串，我一度以为是库的问题。后来才发现，那种 PDF 本质就是用图片拼出来的，只是文件后缀叫 PDF。判断方法很简单：用 PDF 阅读器打开，试着选中一段文字，选不中就是扫描件。或者直接用 PyMuPDF 的 get_text 判断字符数，少于阈值就自动转到 OCR 流程。这个阈值建议根据文档类型调，我一般设 10 到 20 个字符之间。

遇到这类文件，别再研究提取参数了，直接上 PaddleOCR 或 Marker。还有一种“假文本”更坑：PDF 里有文字层，但内容是被旋转或位移的，直接 get_text 出来顺序是乱的。这种情况可以用 pdfplumber 按坐标排序，或者用 PyMuPDF 的 dict 模式取每个 span 的坐标，再按坐标重建阅读顺序。

6.2 OCR 中文错字的病根与解法

中文 OCR 错字的原因，最常见的有三类：原图分辨率不够、字体特别花哨、印章和背景干扰。分辨率不够这个问题，解药是先放大再识别。我一般会把小于 200 DPI 的扫描页先用 OpenCV 做一次放大和锐化，识别率能明显提升。字体花哨的问题，解药是换模型，PaddleOCR 对宋体、黑体、仿宋都还行，但遇到艺术字体就难说，只能降低预期。印章干扰则适合做通道分离，红色印章单独提取后可以弱化，或者直接用多模态模型做二次校对。

还有一个独门心得：OCR 结果的错字不用全改。你可以按句子 Embedding 的相似度做一遍“语义合法性过滤”，如果整句向量和原文档的相似度异常低，多半是识别烂了，直接丢弃比硬留更安全。RAG 召回拼的是整体质量，一个小 chunk 里的几个错字，远不如一段完整的噪声语义害人。

6.3 表格解析“取歪了”的三种典型表现

表格是 PDF 解析的重灾区。第一种表现是表格被拍平，行列关系全丢；第二种表现是表头识别错，明明是“金额”“日期”，结果全部串到一列；第三种表现是跨页表格被拆断，后半段行列对不上。

针对这三种情况，我的解法是分场景。简单规整的表格用 pdfplumber 的 extract_tables，效果很好；复杂嵌套表格，建议直接把该区域截图出来走多模态大模型输出结构化 JSON，虽然慢，但你能拿到明确的表头和字段；跨页表格则要在切块时做合并逻辑，识别同一表格的续页，把它们拼接后再入库。不要指望一个工具解决所有表格，表格这个类别本身就值得单独写一套策略。

6.4 中文编码、字体缺失与 PDF 生成工具的锅

中文 PDF 还有一个特殊坑：字体缺失。有些 PDF 是从老系统导出的，里面嵌的字体不完整，或者压根没有嵌入字体，导致提取出来的字符是乱码或者变成空白。这种情况在 Linux 服务器上跑解析时尤其明显，因为服务器往往缺少中文字体。处理办法很简单，但容易被忽略：先安装中文字体包，比如 fonts-noto-cjk。

另一种情况是 PDF 生成工具本身就没存好文本信息。我之前遇到一批明明看着是文档，解析出来却是“CID 字体”乱码的 PDF，根源是生成 PDF 的工具没有正确映射字符编码。这种文件基本只能靠 OCR 兜底，或者重新从源头导出高质量 PDF。在实际项目里，能给上游提一句“请用标准方式导出 PDF”，能省掉解析团队一整周的加班。

6.5 关于 PDF 办公工具与自动化的一点实话

我经常会看到团队里有人提：直接用某 PDF 编辑器把所有文件转成 Word 不就行了？流程上可行，但工程上不建议。人工操作缺乏可复现性，无法批量处理，也无法纳入监控和增量更新。RAG 知识库是持续增长的系统，今天导一百份，下个月可能有一千份，如果没有自动化管线，维护成本会失控。

我的另一个体会是：别迷信某一个“最强解析工具”，尽早建设“先分类、再分流、后清洗”的解析框架。把工具解耦成可插拔的组件，今天用 PaddleOCR，明天想换 MinerU，都能平滑切换。解析这层代码写得好，后面换模型、换向量库都不慌。

在我自己接手过的项目里，解析层做扎实带来的回报非常直接：知识库的回答可溯源了，错字污染少了，新增文档的入库时间从“跑一夜”缩短到“半小时”。如果你最近正卡在 RAG 数据导入这一步，建议先把解析链路搭稳，把每一类文档的解析路径彻底跑通，再回头调模型、调提示词。磨刀不费砍柴工，这句话放在 RAG 工程里尤其正确。