企业官网建设流程全解析

做RAG项目最让人上火的环节是什么？如果有人说是Embedding调参，我还能理解；但根据我自己接手过的几个知识库项目，真正能把人逼疯的永远是数据导入前那道解析关卡，尤其是PDF和图片。文本型PDF还算有救，一旦遇到扫描件、拍歪的合同照片、带跨页表格的年度报表，你写好的清洗规则全部失效，检索出来的内容经常是缺字、乱码、顺序颠倒。

这篇是"RAG数据导入与解析全攻略"系列的第二篇，上篇我们把纯文本和Markdown类数据的清洗讲完了，这篇集中解决图文与PDF解析。核心就三件事：OCR怎么选、多模态大模型什么时候用、以及市面上常见的九种PDF解析工具该怎么挑。适用对象是正在搭RAG知识库、做文档问答、或者做内容私有化检索的工程师。

1. 先给PDF和图片分分类：你的解析方案会跟着"形态"走

很多人在解析PDF时一上来就选工具，结果工具换了一堆还是解析不好。我的建议是先别急着抄代码，拿几份真实文档看一眼，给它们分个类。分类维度很粗暴：页面上到底有没有可复制的文字层，以及版面里是单栏还是多栏、有没有跨页表格。

1.1 文本型PDF：有文字层但未必好拿

文本型PDF一般由Word、LaTeX或网页打印生成，页面里每个字符都有对应的文本坐标。理论上用PyMuPDF一句page.get_text()就能拿到全文，但实际项目中坑不少。

最典型的问题是字体编码。某些PDF为了兼容特殊字体，会嵌入只有内部映射的编码，get_text()返回的可能是"乱码"或空白。这时候你得去读PDF的字体对象和CMap，或者干脆放弃这一页，用渲染成图片再OCR来兜底。我在一个政府公开文件项目里就遇到过：文件看着是纯文字，复制到记事本全变成方框，最后用OCR解决了。

另外，文本型PDF不一定有正确的阅读顺序。双栏排版、页眉页脚、脚注浮层，提取出来的文本经常是左栏一段、右栏一段交错出现。所以后续我得用坐标信息做排序和版面归并，这部分在第4章工具选型里会具体展开。

1.2 扫描件/图片型PDF：必须走OCR或视觉模型

扫描件本质上是图片集合，PDF里没有文字层，或者只有一层透明的"假文字层"。这种文件只能通过OCR或视觉模型把图像转成文本。常见来源是传真件、老旧档案、手机拍摄的实体文件。

这类文件最让人头疼的不是"识别不出字"，而是识别出来的文本没有结构。原文里明明有标题、段落、表格、批注，OCR只给你的是一串连续的token流。你把它直接切块丢进向量库，检索时经常匹配到错位的内容。所以扫描件解析不能只做"字符识别"，还得做版面分析，至少要能把标题、正文、表格单元区分开。这也是为什么我更推荐带版面恢复能力的OCR方案，比如后面会讲到的PP-Structure、Surya或Marker。

1.3 混合型与复杂版面：真正的硬骨头

实战里大量PDF是混合形态：一半页面有文字层，一半页面是扫描图片；或者一页里有文字、有图表、有表格、有页眉页脚。最典型的就是券商研报、产品手册、招股书。

这种文档的价值恰恰藏在复杂的版式里。表格数据如果只提取成凌乱的纯文本，RAG在回答"某年营收是多少"时就会答非所问。正确做法是用版面识别把页面划分成不同区域，再按区域类型走不同管线：文字区走文本提取、图表区生成描述、表格区用表格识别模型转成Markdown或HTML。后面第5章的实战流水线就是按这个思路搭的。

2. OCR选型：Tesseract、PaddleOCR和云OCR的分工

OCR这个领域，开源和商业方案都很多。每次有人让我推荐"最好的OCR"，我都得反问：你的文档主要是中文还是西文？是印刷体还是手写体？有没有表格？要不要保留版面？这些问题的答案，比任何一个单一指标都重要。

2.1 三套方案的实测差异

先说Tesseract。它是HP实验室开源的老牌引擎，社区生态成熟，支持语言多，但它在中文场景的识别精度、表格支持、复杂背景抗干扰上已经明显落后。我拿一批清晰的中文扫描件对比过，Tesseract在规范宋体上的单字准确率约85%-90%，一旦遇到行内公式、下划线或印章，错字和漏字率立刻上升。适合的场景是：西文文档、简单印刷体、对精度要求不高的批量处理。

再说PaddleOCR，百度开源，目前在中英文、表格、版面分析上优势明显。它自带方向分类器、文本检测、文本识别三个模块，还提供了PP-Structure做版面分析和表格还原。对国内RAG项目来说，PaddleOCR基本是首选开源方案。我实测一份夹杂手写批注的表格扫描件，PaddleOCR的表格还原准确度在90%上下，基本可以直接进下游解析。

云OCR指的是百度、腾讯、阿里这类在线接口。优点是模型更新快、支持票据、证件、手写等垂直场景，缺点是数据出境、费用、并发限制。如果文档涉及敏感业务数据，我不建议直接传云端。但如果只是几百份临时授权文件，云OCR的效率和精度确实比自建要好。

2.2 图像预处理比换引擎更划算

很多人OCR效果差，第一反应是换引擎，其实大部分问题出在前置图像质量上。同样的PaddleOCR，原图方向歪5度，识别率可能就下降20%。

预处理几个常用动作：

• 用OpenCV做灰度化、二值化，去掉彩色背景对检测的干扰。
• 透视校正，尤其针对手机拍摄件，用四点变换把页面拉正。
• 提高渲染分辨率。PDF转图片时，PyMuPDF的pixmap分辨率建议至少200dpi，扫描件我通常用300dpi。分辨率不够，小字号直接糊掉。
• 去噪和去线，但不建议过度，有些表格识别需要保留框线。

import cv2 import numpy as np def preprocess_image(img_path): img = cv2.imread(img_path) gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 简单二值化 _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) return binary

这步做完，再进OCR，效果往往比换一个"更高级"的识别引擎更明显。

2.3 一个直接可以改的PaddleOCR流程

PaddleOCR的接口不同版本有差异。我这里给一个2.x/3.x时代比较通用的思路，具体跑了要看你装的版本。

# 安装 pip install paddlepaddle paddleocr

from paddleocr import PaddleOCR # lang='ch' 表示中文模型 ocr = PaddleOCR( lang='ch', use_doc_orientation_classify=True, # 方向分类 use_doc_unwarping=True, # 弯曲矫正 use_textline_orientation=True # 文本行方向 ) result = ocr.predict("scan_page.png") for res in result: # 新版返回结果通常带rec_texts、rec_scores、dt_polys for text, score in zip(res["rec_texts"], res["rec_scores"]): if score < 0.6: continue print(text)

注意，PaddleOCR 3.x把很多参数挪到了TextDetection、TextRecognition里，建议直接看官方文档再调。核心点是一次调用同时拿到检测框坐标和文本，后续可以按坐标做版面排序。如果你只想要纯文本，忽略坐标也没问题；但如果要恢复多栏结构，坐标就非常重要。

2.4 云OCR什么时候才是正解

云OCR的价值在于"省事"。自建PaddleOCR虽然不用花钱，但要处理依赖环境、GPU、模型更新、并发能力。对非技术团队或一次性需求，云OCR反而更划算。比如做一个企业内部合同问答系统，合同量不大，上传到云OCR识别字段，拿JSON结构化结果，一天就能上线。

我自己的建议是划分三条线：批量大、数据敏感、要长期迭代的，走自建PaddleOCR或基于它的二次开发；清晰且量小的西文文档，Tesseract够用；需要识别手写、发票、特定版式的，再考虑云OCR，而且尽量做数据脱敏。

3. 多模态大模型：OCR的上限在这里被突破

OCR再强，碰到复杂图表、拍照歪斜严重、手写批注混排的情况也会麻爪。多模态大模型可以直接把图片"看"成结构化内容，这给RAG数据导入打开了一条完全不同路径。

3.1 适合多模态模型处理的文档类型

我目前用到多模态模型的主要是四类：

• 复杂表格：比如合并单元格、斜线表头、跨页重复表头，传统工具容易拆错，视觉模型能直接理解表格语义。
• 图表与截图：折线图、柱状图、流程图，OCR识别不了图形含义，多模态模型可以生成一段文字描述，让后续检索能命中"2023年营收增长趋势"这类语义。
• 手写批注与印章：合同里的手写备注、增值税发票上的印章，字迹模糊但人类能猜，模型也能猜及格。
• 严重畸变的扫描件：透视变形、折叠阴影，传统OCR预处理后仍然残破，大模型反而能靠上下文推断。

典型开源/闭源组合包括GPT-4o系列、Qwen-VL系列、InternVL、MiniCPM-V等。如果数据敏感，本地部署至少要有70B以上参数的模型才谈得上复杂版面理解，效果和延迟都需要做取舍。

3.2 提示词设计决定输出质量

让多模态模型读PDF页面，提示词不能只写"提取文本"。我项目里常用的一种提示词模板是：

你是一个文档解析引擎。请逐页分析图片，输出严格JSON： { "page": 页码, "blocks": [ {"type": "title|paragraph|table|chart|header|footer|image", "content": "该区块的完整文本；表格用Markdown格式", "description": "如果type为chart或image，用一句话说明图表表达了什么"} ] } 要求： 1. 不要补充原文没有的信息。 2. 识别不出的字符用[?]标记，不要猜测。 3. block顺序必须符合阅读顺序。

关键是强制JSON格式、强制区块类型、强制"未知则标记"，能显著减少模型编造字段的问题。实际使用中发现，模型偶尔会漏掉页脚或脚注，所以抽查和阈值过滤还是不能省。

3.3 成本控制和混合策略

多模态模型不是免费的午餐。单页截图动不动消耗上千tokens，批量处理几百页文档，费用比OCR高一个数量级。更重要的是延迟，本地部署的视觉模型单页推理可能要几秒到十几秒，不适合高吞吐场景。

我用的策略是"分级路由"：先用快速OCR和规则判断页面复杂程度，普通页面走轻量管线；只有当检测到表格、图表、低置信度等情况，才把页面发给多模态模型。这样可以兼顾成本和质量。比如先跑一遍PaddleOCR，如果行数超过50且存在长度异常的表格框，就标记为"疑似复杂版面"，再送多模态。

3.4 多模态输出如何入库RAG

多模态模型输出的JSON不能直接怼进向量库。我的处理方式是：先按block类型拆成节点；title节点保留，作为后续父子块的元数据；table块里的Markdown转成带结构的分行文本，每行一个chunk太小，一般整个表格作为一个chunk；chart或image块则保留"description"作为可检索文本，同时把原图路径放进metadata。

# 伪代码：把多模态JSON转成检索单元 for block in vis_result["blocks"]: if block["type"] in ("table", "paragraph", "chart"): chunks.append({ "text": block["content"] or block["description"], "metadata": {"page": page, "type": block["type"]} })

这样既保住了语义检索能力，也保留了原文档的位置信息，后面做引用溯源会方便很多。

4. 九种PDF解析工具横向对比与选择建议

市面上PDF解析工具非常多，但真正适合RAG数据管线的不多。我按"轻量文本提取、表格专项、智能文档解析、深度学习转Markdown"四个梯队，挑九种常用工具做了对比。

4.1 九种工具一表看清

4.2 轻量文本派：pypdf / PyMuPDF / PDFMiner.six

如果你只是想把"干净"的PDF变成纯文本，pypdf足够。它代码量最小，几行就能提取全文，但别指望它帮你处理双栏。PyMuPDF是我的默认选择，因为它除了文本还能拿到每个词块的坐标和字体信息，这些信息在做版面还原时太有用了。比如判断标题，直接看字体大小是否明显大于正文。

PDFMiner.six更底层，暴露了完整的布局对象。它适合需要精细控制的情况，比如以字符级坐标重建表格。但学习曲线陡，现在大部分项目我都用PyMuPDF，只有在需要读取CMap或处理怪异字体时才翻PDFMiner。

4.3 表格专项派：pdfplumber / Camelot

pdfplumber在字符精度上很优秀，能拿到每个字符的bbox，适合从发票、明细表里抽字段。它的extract_table()对有线表格效果稳定，我在做财报数据抽取时第一选择就是它。

Camelot的强项是"知道哪些线属于表格"。它有两种模式：lattice依赖表格线，适合有线框的规整表格；stream依赖空白分隔，适合没有完整线框的表格。但它依赖OpenCV的形态学处理，对模糊扫描件效果一般。如果表格跨页，Camelot会把两个页面的表格当成两个独立对象，后续需要自己拼接。

4.4 智能Document派：Unstructured / LlamaParse

Unstructured是LangChain生态里很常用的分区工具，能把PDF划分成Title、NarrativeText、Table等块，并自带清洗函数。它的中文效果不如英文，但好处是能直接对接RAG框架，省去很多胶水代码。

LlamaParse是托管服务，专门针对复杂版面做结构化输出，表格会转成Markdown。它对常见业务文档的鲁棒性不错，遇到超宽表格、多栏混排也基本能保持顺序。代价是数据要经过第三方，且按页计费。我通常拿它做"人力补充"——本地管线解析不了的疑难文档，统一发过去当第二通道。

4.5 深度学习转Markdown派：Marker / MinerU

Marker把PDF渲染成图片后，用检测模型识别版面，再OCR文本，最终输出Markdown。它输出的结构非常干净，标题、列表、表格都能保留，甚至能处理公式。缺点是好的效果依赖GPU，CPU推理慢到没法用。

MinerU（OpenDataLab旗下）在主攻学术论文和应用文档，内置了公式识别模块，对中文支持比Marker好。实际测试一份中文技术手册，MinerU转出的Markdown层级基本不用改就能用。但部署体积大，模型权重好几个G，生产环境要考虑资源和初始化时间。

这九个工具不是互相取代的关系，而是要按文档类型组合使用。我的准则是：先试PyMuPDF快速判断是否有文字层；干净文本直接提取；表格密集的用pdfplumber或Camelot；扫描件和复杂版面交给Marker/MinerU或多模态模型。

5. 一套完整实战流水线：从混合目录到RAG文本块

前面讲了很多选型和原理，这一章给一套我实际在用的流水线。它解决的核心问题是"一个目录下什么文档都有"。

5.1 先做文件路由：判断该走哪条解析链路

路由逻辑不复杂，关键是别把所有文件都当成同一类。我的做法是先判断扩展名，再判断PDF是否有文字层。

import fitz def route_pdf(file_path): doc = fitz.open(file_path) total_text = "" for page in doc: total_text += page.get_text() if len(total_text.strip()) < 20: return "scan_image" # 无文字层，走OCR/视觉 # 有文字层但含表格/多栏，需要坐标级处理 return "text_pdf"

这里阈值20是我拍脑袋定的，你可以根据实际语料调整。重点是：一旦判定为scan_image，后续就不该再走PyMuPDF文本提取，直接渲染成图片进OCR。

5.2 解析、后处理与元数据保留

文本型PDF解析后，别急着入库。后处理三步我必做：

• 按阅读顺序重排文本块，用坐标排序，而不是依赖PDF内部顺序。
• 识别标题层级，PyMuPDF里文字块带size和flags，把连续两行相同字号且字号大于正文的字块标记为标题。
• 表格转Markdown，方便LLM理解，也方便DuckDB这类工具查询。

元数据也很重要。我会给每个chunk记上source_file、page_num、chunk_type（title/paragraph/table/chart）、heading_path。这样到了RAG阶段，既能做引用溯源，也能实现"按章节过滤"的混合检索。

5.3 切块策略：别把表格和标题切碎了

很多人切块只按固定字符数，导致一个表格被拦腰截断，检索时语义完全丢失。我更推荐先按文档结构分块：标题块、段落块、表格块、图表描述块分开。表格块除非特别长，否则整个作为一个chunk；段落块按200-500字、重叠50字去切。

def split_by_structure(blocks, max_chars=500, overlap=50): # 按title/paragraph/table分类 # 段落可继续切分；表格、标题保持整体 ...

实践中这样切下来的chunk，召回准确率比纯字符切块高不少。原因很简单：LLM回答表格问题时更希望拿到完整上下文，而不是只能在半个表格上瞎猜。

5.4 入库验证：用召回测试反推解析质量

解析质量好不好，别靠肉眼。我一般建一个简单的评测集：拿20-50个真实问题，每个问题标记正确答案所在页码，然后跑一遍RAG检索，看前5个召回chunk是否包含正确答案。解析质量差时，召回率会惨不忍睹；解析质量提升后，召回率会立竿见影。

一个不起眼但很实用的检查项是：把入库文本里的特殊字符统计一下，比如\uFFFD、乱码方框、连续重复标点。这些往往是OCR或编码转换失败的表征，直接按数量排序找最脏的几份文档即可。

6. 我的避坑清单：这些问题几乎每个项目都会遇到

最后分享几个我真实踩过、且反复出现的坑。如果你能避开，能省下大量调试时间。

6.1 有文字层但是"假文字层"

有些PDF自带OCR文字层，但内容质量极差，甚至和图像错位。我之前处理一份扫描合同，PyMuPDF提取出的文字层全是数字和字母混排，明显是旧OCR工具留下的垃圾。判断方法很简单：把文字层和渲染出的图片叠在一起对比，或者直接用置信度过滤。更省事的做法是：凡是来源不可信的PDF，都不要轻信文字层，做一次快速OCR对比再决定。

6.2 表格跨页与表格错位

跨页表格是文档解析里的老大难。解决方案没有银弹，我的办法是先用关键词或表格线判断"上一页最后一行是否是表格尾部"，如果是，就把跨页部分拼接到同一个chunk。Python里的做法是记录每个表格块coordinates，跨页时若上一页底部区域和下一页顶部区域都存在表格线或相同表头，则视为同一表格。实现大约几十行，但能显著提升财报类问答的准确率。

6.3 OCR重复符号与串行

OCR输出经常出现"，，"、"。。"这类重复标点，以及竖排文字、页边距噪声被串进正文。清洗时写一个正则去重规则：

import re text = re.sub(r'([，。！？；：、])\1+', r'\1', text)

还可以根据坐标过滤掉页眉页脚。很多扫描件页眉是"第1页共5页"，检索词里出现"第X页"很干扰相关性。按固定区域裁剪后，气味会干净很多。

6.4 图片不放文字描述等于白放

如果你直接把图片文件塞进RAG向量库，Embedding模型只把图片当成一个文件名字符串，基本检索不到。我的做法是用多模态模型给每张图片生成一句话描述，再和图片路径一起入库。例如一张"三相电路图"，描述成"三相交流电路原理图，包含电源、变压器、负载连接示意"。这样用文字就能命中图片，后续展示时再引用原图。如果检索需求真的必须"用图片搜图片"，那就得引入CLIP这类多模态向量模型，在工作流上是另一套方案。

文本和图表混排的页面尤其要注意：图表描述必须和所属章节标题绑定。这样用户问"第四章的架构图"时，RAG能定位到"第四章"的文字上下文，再顺藤摸瓜找到图片。

我在实际项目里最大的体会是：图文与PDF解析没有一招鲜的工具组合，一切都要回到"你的文档长什么样、问题会怎么问"这两个基本问题上。每个坑背后都有一份具体文档在等着你，先分类、再路由、后清洗，比盲目堆模型可靠得多。