企业官网建设流程全解析

如果你最近在搭RAG（检索增强生成）项目，大概率已经经历过这种诡异阶段：文档明明传进去了，向量库里也建了索引，但问一个问题，模型答出来的内容不是张冠李戴，就是“找不到相关信息”。我一开始怀疑是Embedding模型选得不对，是分块策略太粗糙，后来把源头扒了个遍才发现，问题出在最不起眼的数据解析环节——尤其是PDF和图片类内容，解析出来的文本本身就是乱的。这也是我为什么把数据导入与解析这个主题拆成一个系列来讲，上一篇聊的是文本类数据的清洗和规范化，这一篇专门怼图文和PDF解析，覆盖OCR、多模态大模型两条技术路线，外加九种PDF工具的实测选型，希望能帮你少走点弯路。

1. RAG数据处理里，图文PDF为什么一直是最容易翻车的环节

1.1 解析质量直接决定检索质量的一句话逻辑

很多团队在搭RAG的时候，把技术重心全放在向量数据库选型、Embedding模型微调、Prompt模板设计上，对最前面的“数据解析”环节反而非常随意。我见过不少项目，数据源是几百份带表格的财务报告、扫描版合同、图文混杂的行业白皮书，结果负责导入的同学直接用PyPDF2的extract_text()跑了一遍，出来一堆没有段落顺序的碎文本就往向量库里塞。等到查询阶段，用户问“公司前三季度的营收结构变化”，系统反馈回来的片段是某一页表格里被拆碎的单元格文本，既不完整也缺少上下文，最终生成答案自然没法看。

道理其实很朴素：RAG的上限由检索质量决定，检索质量的上限由入库文档的解析质量决定。Embedding模型再强，也救不回来一段语义已经被打散的文本。PDF这种格式本身就不是为了“提取文本”设计的，它记录的是页面布局和坐标，你拿到的“文本”只是从坐标层里抠出来的副产品。图文混排、扫描件、多栏排版、表格嵌套，每一个都是解析环节的独立坑点。这个系列我坚持从数据导入讲起，就是因为在实战里它决定了下游所有环节的天花板。

1.2 三类最容易让RAG崩掉的PDF形态

我在实际项目里遇到的PDF文档，基本可以分成三类，每一类的处理方式完全不同，混在一起批量处理一定会出问题。

第一类是纯文本型PDF，页面里有真实文本层，可以直接提取。这类文档通常由Word、LaTeX、HTML打印生成，文字选中复制没问题，解析的重点在于保持段落顺序、标题层级和表格结构。

第二类是扫描件或图片型PDF，页面本质是图片，没有任何文本层，必须走OCR流程。合同、老书、传真件、部分政府公开文件都在这一类。如果解析方案里没有OCR步骤，这类文档在向量库里基本是隐形数据，检索时永远命不中。

第三类是混合型PDF，也叫双层PDF，底层是扫描图片，顶层叠加了一层OCR生成的透明文本。这种文档看起来能复制文字，但文本层往往带有坐标噪声、重复内容或者识别错误，直接提取很容易拿到一份“看似正常、实则错位”的数据。

很多人都是在跑完整条RAG链路之后，才发现数据源头分类没做，白白浪费了大量调试时间。下一篇也会反复强调一个原则：在导入阶段先做文档形态探测，再决定走哪条解析路径，不要一上来就写一个统一的解析函数。

1.3 我踩过的一个典型案例：解析错位导致检索效果断崖式下跌

说一个我自己踩过的坑。之前做一个行业法规库的RAG项目，数据源里有一批PDF是扫描后经过OCR生成的，按当时的判断，这类文档应该直接走OCR路线。但团队里有人图省事，直接用了pdftotext命令行工具批量提取，提取结果肉眼扫过去没什么大问题，段落、标题看着都还在，就按这个结果做了切片入库。

结果测试阶段，问“某条款关于行政处罚的时效规定”，系统返回的内容经常是半句话加一句无关的序言，而且引用页码还不稳定。后来把原始PDF调出来逐页对照才发现，这套OCR文本层存在明显的纵横坐标错位，本来应该属于表格第二行的内容，在文本层里被拼到了第一行后面。由于这个问题是“局部性”的，肉眼抽查很难发现，等进了向量库，经过Embedding之后语义被进一步扩散，排查起来非常痛苦。

从那以后，我在数据导入流程里强制加了两步：文档形态分类和解析结果抽样核验。这两步看起来费时间，但能在问题扩大化之前就把它拦住，比后面排查快十倍都不止。

2. 图文解析的两种路线：传统OCR与多模态大模型的真实差异

2.1 OCR传统流程拆解：检测、识别、后处理三步走

传统的OCR技术路线，拆开来看其实是一个流水线，每一步都有独立的优化目标，混在一起只会互相干扰。

第一步是版面分析与文字检测，这个阶段要做两件事：找出图片里的文字区域，并且标记出每行文字的坐标框（bounding box）。常见做法是用目标检测或者分割模型，比如PaddleOCR里的DB文本检测算法，它对弯曲文字、倾斜文字、低光照条件下的文字都有不错的召回率。在这个阶段，输出是若干个坐标框，而不是文字本身。

第二步是文字识别，把检测出来的文字区域图像送入识别模型，输出对应的文字序列。识别模型通常基于CRNN、Attention或者Transformer结构，PaddleOCR的SVTR系列就是典型代表。对中文场景来说，这一步的难点主要在于生僻字、手写体和特殊符号，模型的训练数据规模直接决定了它的上限。

第三步是后处理与结构化，因为OCR输出的只是“字”，没有段落、没有表格结构，还需要根据坐标信息重新聚合成段落、识别表格的单元格边界、恢复阅读顺序。这一步最容易被忽略，但恰恰是RAG场景里最关键的。同一个表格，有的工具能输出一行一行的单元格文本，有的工具会把单元格内容按坐标胡乱拼接。嵌入向量之后，前者能精确命中“某列对应的值”，后者就只能提供一段语义混乱的噪声。

2.2 主流开源OCR引擎的取舍：PaddleOCR与Tesseract

在传统OCR路线上，我实际用得最多的两个开源方案是PaddleOCR和Tesseract，两者定位差异很大。

Tesseract是老牌OCR引擎，由惠普实验室诞生，后来交给Google维护。它的优点在于轻量、跨平台、支持语言极多（超过100种），装一个语言包就能跑。但它在中文场景和复杂版式上表现一般，尤其是中文表格、竖排文字、带背景噪点的扫描件，识别精度明显不够用。个人建议是：应对英文文档、白底黑字的规整扫描件，Tesseract仍然可用；涉及中文或版式复杂的，慎重考虑。

PaddleOCR是百度开源的中文OCR工具链，对中文场景做了大量针对性优化，内置文本检测、方向分类、文字识别三个模型，还额外提供表格结构识别模型。我实测下来，普通中文打印体的识别准确率接近商用水平，而且在表格识别上有专门的解决方案，可以直接输出HTML格式的表格结构。它的缺点是依赖库较多，部署体积偏大，CPU推理速度比Tesseract慢一些，但配合GPU加速后完全能接受。

如果走开源路线做扫描件PDF的RAG入库，我的默认推荐是PaddleOCR，配合它的PP-Structure套件，可以把版面分析、表格识别、文字读取一次跑完。当然，它也不是万能的，遇到手写体和低分辨率老照片，仍然需要人工介入或者引入下一节讲的深度视觉模型。

2.3 多模态大模型在图文解析上的优势与风险

近年来，多模态大模型（视觉语言模型）为图文解析提供了一条完全不同的技术路线。它不再走“检测文字框—识别文字—重组结构”的流水线，而是直接把整页PDF渲染成图片，交给模型，让它理解整页内容后输出Markdown、HTML或者JSON。

这条路线的优势非常明显。第一，它天然理解版面语义，能够区分标题、正文、页眉页脚、图片注释，而不是机械地依靠坐标判断。第二，它能够处理传统OCR很难搞定的复杂场景，比如一个跨页的表格、带合并单元格的报表、图文混排的杂志页面。第三，它输出的是结构化内容，而不是一堆坐标框加字符串，解析结果可以直接用于分块和Embedding。

但风险同样存在。首当其冲的是幻觉问题：视觉语言模型在“看”一页版面时，可能为了输出连贯的Markdown而脑补出原文没有的文字，这种错误比OCR识别错字要隐蔽得多，也危险得多。其次是成本与延迟：高分辨率页面的推理时间通常在几秒到十几秒，如果文档有几百页，批处理的时间和费用都会非常可观。最后是数据安全问题：把内部合同、涉密资料传給第三方云端API，对很多企业来说是不可接受的。我的建议是：内部数据优先用本地模型或者开源方案，外部公开数据可以放心使用云端API；所有数据即便走了云端，也不要直接对接生产环境。

2.4 我的混合策略：本地工具链做主力，多模态做兜底

在真实项目里，我不会把全部数据压在某一条路线上，而是用一套混合策略。

默认流程是：先用传统工具链做快速解析，比如用PyMuPDF提取文本层，对没有文本层的页面再用PaddleOCR兜底。对这一轮解析结果做质量打分，凡是被检测到“文本密度异常”“表格坐标错位”“段落顺序混乱”的页面，单独抽出来，送到多模态模型做第二次解析。这样既控制了成本和延迟，又能把复杂的边缘case交给能力更强的模型处理。

具体打分规则可以很朴素：检测每个页面的文本长度是否显著低于正常值，表格单元格数量是否异常，页面内文本块是否有大面积重叠。出现这些特征时，说明传统工具已经处理不动了，交给多模态模型往往能救命。这个策略跑下来，整体解析成本能降低一半以上，同时保证了解析质量的底线。

3. PDF解析工具选型：九种工具逐一拆解

3.1 文本型PDF的常规武器：PyPDF2、pdfplumber、pdfminer.six

先聊三个最基础的文本提取工具，它们处理的对象是“有文本层的PDF”。

PyPDF2（以及它的新版本pypdf）是我最早接触的库，API很简单，两三行代码就能把一整个PDF的文本抽出来。但它的问题也非常突出：提取出来的文本基本不保留布局和顺序，多栏文档会左右栏混排，标题和正文的层级关系完全丢失。在RAG场景里，它只适合做快速预览、获取元信息、或者对简单单栏文档做应急处理，不适合作为正式解析方案。

pyPDF 代码示例

from pypdf import PdfReader reader = PdfReader("sample.pdf") for page in reader.pages: text = page.extract_text() print(text)

pdfplumber是上一代工具里我最常用的一个，它基于pdfminer.six封装，提供了更友好的API，尤其擅长提取文本坐标和表格。它的extract_table()方法对规则表格的识别相当准确，配合page.to_image()可视化调试，能够快速定位解析问题。但它也有短板：处理多栏复杂版面时仍然会有顺序错乱；当PDF页面超过几十页，解析速度明显下降。适合做中小规模文档的精细解析，不适合做全库批处理。

import pdfplumber with pdfplumber.open("sample.pdf") as pdf: page = pdf.pages[0] text = page.extract_text() tables = page.extract_tables()

pdfminer.six是pdfplumber的底层依赖，胜在可定制性极高，能拿到每个字符的精确坐标、字体信息，也可以通过自定义布局分析算法重建段落顺序。代价是API层级低，上手成本高，你需要自己写不少胶水代码。适合对解析精细度有极端要求的场景，比如需要精确还原公文版面、或者需要处理复杂的读序逻辑。性能同样不突出。

3.2 表格与版式向工具：PyMuPDF、Camelot、tabula-py

PyMuPDF（fitz）是我现在批量处理PDF的第一选择，没有之一。它是MuPDF的Python绑定，底层是C语言实现的解析引擎，速度非常快，比pdfplumber快一个数量级。它提供page.get_text("dict")方法，可以一次性拿回页面里所有文本块（block）、行（line）、字符（span）的坐标和内容，这意味着你可以自己决定如何重组这些块，而不是被动接受库的默认顺序。它还内置了将PDF页面渲染成图片的功能，方便做可视化质检、把页面图传给多模态模型。

import fitz doc = fitz.open("sample.pdf") for page in doc: blocks = page.get_text("dict")["blocks"] for block in blocks: if "lines" in block: for line in block["lines"]: text = "".join(span["text"] for span in line["spans"]) print(text)

Camelot是专攻表格提取的工具，它有两种模式：lattice模式依赖表格线条来定位单元格，适用于有明确边框的表格；stream模式通过文本坐标推测行列，适用于没有边框的表格。实测下来，lattice模式对规范表格的提取效果相当好，能输出近乎完美的表格结构。但它强依赖环境里的Ghostscript，安装配置时会踩一些坑；处理无边框或复杂嵌套表格时表现一般，需要配合模式选择和参数调优。

camelot read -p lattice -f "table.pdf" -o output.csv

tabula-py是对Java开源项目tabula-java的Python封装，底子很稳，API设计也比Camelot简单。它对规则表格的抽取效果不错，但不擅长处理版式复杂的PDF。另外它依赖Java运行环境，部署时容易因为Java版本不匹配出问题。在RAG场景里，如果数据源比较规整，比如银行流水、库存报表，tabula-py可以胜任；但遇到杂志扫描版、手写表格，还是直接绕开比较好。

3.3 AI时代的解析工具：LlamaParse、Marker、Unstructured

传统工具链再强，面对高度复杂的版面还是力不从心。这一节的三款工具已经开始把深度学习引入到PDF解析流程里，对RAG场景的适配度非常高。

LlamaParse是LlamaIndex团队推出的托管解析服务，专为大模型知识库设计。你上传PDF，它返回结构化的Markdown，表格、标题、段落被整理得清清楚楚。我看过不少行业测评，它对复杂表格的处理能力明显优于本地开源方案，而且直接输出Markdown这一点很友好，省去了大量的版式重组工作。代价是它是一个托管API，文档内容会被发送到外部服务，对数据敏感的场景不太合适。同为闭源方向，它的定价是按页计算，大规模批量导入时需要先算好预算。

Marker是一款本地开源的PDF转Markdown工具，基于深度学习做了版面分析和表格识别，对标题、列表、表格、代码块的还原度非常高。它默认还会把公式用LaTeX格式输出，这对学术论文类PDF非常有用。实测下来，Marker对复杂版式的处理在这个类别里是最好的之一，配合GPU加速后，解析速度也能接受。如果你是技术团队，可以考虑用Marker作为主力解析引擎，输出Markdown后直接做切片。

marker_single sample.pdf --output_dir ./output

Unstructured严格说是一个文档处理框架，而不是单纯的解析库。它的核心能力是“分区”（partitioning），可以把PDF分割成标题、正文、表格、图片等不同元素，并返回包含类型、文本、坐标、关联元数据的结构化对象。它和LangChain、LlamaIndex的集成做得很好，几乎可以直接挂进RAG流水线。但它的表格提取能力相对普通，复杂表格交给它处理，容易被拆成零散的文本块。适合作为数据接入层的统一入口，再配合其他工具做具体内容的精细解析。

from unstructured.partition.pdf import partition_pdf elements = partition_pdf("sample.pdf", strategy="hi_res") for element in elements: print(element.category, element.text)

3.4 一张表看透九种工具的定位

这张表是我对这九种工具的直观感受，不代表所有场景的绝对结论。选择工具时先明确自己的核心矛盾是“速度”“精细度”“表格准确率”还是“数据隐私”，再对照找答案，会比迎面扑上来就编程高效得多。

4. 从单页测试到全量入库：一套可复用的实战流程

4.1 先探测文档类型，再决定解析路径

批量导入PDF的第一件事，不是直接调用某个解析库，而是先写一个文档类型探测函数。判断逻辑很简单：用PyMuPDF尝试从每一页提取文本，统计整篇文档的总字符数。如果总字符数很低（比如单页平均不足50个字符），基本可以认定是扫描件；如果某些页有文本、某些页没有，那就是混合文档；如果文本量正常但存在大量重复文本模式，很可能碰到了双层PDF。

这一步说起来简单，却能避免后面的解析结果混乱。我见过太多项目，把自己的扫描件数据交给纯文本工具去跑，最后入库的结果全是空字符串；也有把双层PDF同时跑了两遍OCR，导致向量库里全是重复文本。

import fitz def detect_pdf_type(path): doc = fitz.open(path) total_chars = 0 per_page_chars = [] for page in doc: text = page.get_text("text").strip() char_count = len(text) per_page_chars.append(char_count) total_chars += char_count if total_chars < 200: return "scan" zero_text_pages = sum(1 for c in per_page_chars if c < 20) if zero_text_pages > len(doc) * 0.3: return "mixed" return "text"

4.2 分流处理：文本型、扫描件、复杂表格各走各的路

探测完类型之后，就把文档分流到三条处理流水线里。

文本型文档直接用PyMuPDF解析，把每个页面拆成结构化文本块，记录每块的坐标、字体大小和阅读顺序。这个过程我会额外做一步：把字体大于正文的块标记为标题，把坐标位于页面边界的文本块标记为页眉页脚并在入库时丢掉，保证后续切片不会被“第X页”“公司内部资料”这类信息污染。

扫描件文档走PaddleOCR路线。流程是先把页面渲染成高分辨率图片，然后调用PP-Structure输出Markdown格式的结构化内容。注意渲染分辨率至少要150dpi，否则小字号文字识别率会显著下降。这一步的输出结果和文本型文档一样，统一成一个包含正文、标题、表格的JSON结构。

复杂表格文档单独走Camelot或者Marker。如果表格有明确边框，Camelot的lattice模式效果很好；如果版式复杂、有无框线和合并单元格，用Marker做整体版面分析更稳妥。处理完的表格不要直接转成文本塞进切片器，而是保留为结构化的列表或者HTML表格，后续Embedding阶段可以针对表格做专门的序列化。

4.3 缓存解析结果与断点续跑，批量导入不重复造轮子

批量跑解析的时候，最容易忽略的是“幂等性”。一个文档解析失败，修改了参数重新跑，结果前面的几百个已解析文档也被重复处理了一遍，白白浪费时间。

我的做法是在流水线里加一个简单的缓存层：对每个文档计算SHA1哈希，以哈希为文件名把解析结果存成JSON。每次解析任务开始时先检查缓存目录，如果已经存在对应哈希的结果文件就直接复用。这样即使中途宕机、参数调整、单页重试，都不会导致大规模重复计算。配合日志系统记下每个文档的解析状态、耗时和异常信息，批量导入的可观测性就基本齐了。

4.4 质量抽检与失败样本回收，入库前的最后一关

全量解析跑完之后，不能直接入库，得先做质量抽检。我的建议是按文档类型分层抽样，每类至少抽5%的页面，人工肉眼核对原图与解析文本的对应关系。这里强烈推荐用PyMuPDF的页面渲染功能，把原始页面转成PNG图，再用pdfplumber的可视化能力把提取出的文本块坐标画到图上，一眼就能看出文本是不是错位、表格有没有串列。

如果抽检发现问题，把对应页面重新走一遍多模态大模型解析或者调整工具参数后重跑，只处理失败样本，不用全部推翻重来。这一步看起来繁琐，但对于RAG项目而言，入库数据质量直接决定最终应用效果，投入的时间完全值得。

4.5 入库前的最后一步：保留原文与元数据

解析结果的最终存储结构，我建议至少包含三部分：清洗后的结构化文本、对应的源文件路径与页码、原始页面渲染图路径。很多团队只存了文本，丢掉了原文引用信息，结果做文档问答时无法给出可靠的溯源依据，产品说服力大打折扣。保留源文件和页面图，还能在后续抽检、重解析、标注数据集时提供底气。

5. 这些年在PDF解析上踩过的坑，以及我现在的推荐组合

5.1 常见坑合集：双层PDF、跨页表格、文本重复

双层PDF重复文本：这是非常隐蔽的问题。扫描件底层是图片，顶层有OCR透明文本层，直接用文本工具提取时会把顶层的识别文本拿到手。但这个文本层可能是机器自动生成的，里面往往是重复字符、错位内容，和底层图片内容并不完全一致。如果这时候再做一次OCR，等于把“错误文本”又识别一遍，结果自然雪上加霜。我的判断方法是：检测提取出的文本中是否存在大量相邻重复、坐标重叠的内容，一旦发现，就只保留一条解析路径，并把顶层文本与OCR结果做一次相似度比对，取置信度更高的一方。

跨页表格被拆成两个表：很常见的坑。一份财务报表在一个页面的末尾开始，下一页面继续，很多工具会把它当成两个独立表格处理。进入Embedding后，同一个表的语义被切开，查询“一季度总资产”时只能命中后半张表，丢失表头信息。我现在会在解析层面对表格做“跨页合并”：检测到上一页最后一行和下一页第一行具有相同的表头结构或列数时，把它们拼接成同一个表格对象，再交给下游。

文本乱序问题：即便是PyMuPDF提取文本时，坐标排序逻辑如果没写对，多栏文档的读取顺序也会乱。正确做法是：以文本块（block）的左上角Y坐标为主序、X坐标为辅序，先按区块排序，再处理栏内阅读顺序，而不是直接遍历坐标列表。

5.2 我现在的推荐组合

对于大部分RAG项目，我目前的主力组合是“PyMuPDF + PaddleOCR + Marker”。文本型文档交给PyMuPDF快速提取，扫描件交给PaddleOCR做中文识别和表格还原，复杂版面交给Marker出Markdown，最后再统一转成一套标准JSON结构入库。如果是数据敏感度不那么高的项目，我会用LlamaParse替代Marker作为兜底，理由很简单——托管API省心，解析质量也确实顶得住。

这个组合不是一步到位的。最早我尝试过纯PyMuPDF跑全量，结果扫描件废了一半；后来又在全量数据上跑了PaddleOCR，速度太慢，还经常把双层PDF识别出重复文本，被折腾得不行。经过几个项目的实战调整，才逐渐收敛成现在这套混合方案的形态。

5.3 后续可以怎么扩展

解析环节稳定之后，再往下走就是分块策略和Embedding优化了。这部分内容我后面会继续整理，但有一点现在就可以说：解析效果直接影响分块质量，如果你在分块阶段发现“同一主题的内容散落在不同的块里”，先别急着调分块算法，回头检查一下解析工具的输出顺序和表格处理逻辑。很多时候问题不在分块，而在解析层的文本已经失去了语义连续性。

数据解析在整个RAG链路里看起来是最底层、最不起眼的活儿，但它决定了你上层所有优化能不能生效。我现在接手任何RAG项目，都会先让团队把数据导入阶段的文档类型统计和解析结果抽检补上，再谈模型选型和向量库调优。