企业官网建设流程全解析

做RAG项目这几年，我接过不少知识库需求，发现最容易被低估的环节永远是"数据进来"这一步。不管你的向量模型多强、生成模型多聪明，喂进去的是垃圾，检索出来的也只能是垃圾。尤其是PDF——它是企业知识库里最主流的载体，也是最坑的。同一个PDF，可能是天生数字化的文本，可能是整页扫描的图片，可能是图文混排的广告页，还可能是让所有解析器都头疼的复杂表格。这篇文章是"RAG数据导入与解析全攻略"的第二篇，专门讲图文与PDF解析：怎么判断一份PDF需不需要OCR，多模态大模型在解析管线里到底该放在哪个位置，以及我实际用下来觉得值得摆上台面的九种PDF工具选型逻辑。全文没有空话，都是可以直接抄作业的方案。

1. 先把概念理清：RAG知识库与PDF解析的底层关系

1.1 RAG知识库到底能不能存图片

我经常被问到一句话："RAG知识库能存储图片吗？"问这个问题的人，多半是手里有一批产品说明书、合同扫描件、图纸截图，想直接丢进知识库让大模型回答。答案是：能存，但存了也检索不到。经典的RAG流程是"文本切块→文本向量化→向量检索→文本重排→生成回答"，整个链路里没有一个环节是为图片准备的。embedding模型吃的是文字，向量数据库存的是文本向量，就算你把图片的URL硬塞进去，检索时也无法用语义匹配把它捞出来。

想让图片真正"进入"RAG，有两条可行路线。路线A：先用OCR或视觉理解模型把图片"翻译"成文字——截图里的文字、图表里的数值、甚至图片的语义描述，变成一段结构化文本进入知识库，用户检索命中这段文本后，回答时再附带原始图片路径。路线B：上图文双模态的向量检索，用CLIP这类多模态embedding把"图片"和"文本"映射到同一个向量空间，图片本身参与相似度匹配——但这已经不是经典RAG，而是向量检索系统的高级玩法，工程复杂度高、运维成本大，小团队慎入。

顺带回应一个经常被混淆的点：RAG知识库、KG（知识图谱）知识库、结构知识库是三种完全不同的东西。RAG存的是自然语言切片，适合"开放问答、引用原文"；KG存的是实体和关系，适合"多跳推理、关系查询"；结构知识库本质是数据库里的行和列，适合"精确查询、统计聚合"。很多人想把三类数据融进一个系统，结果四不像。我的建议是：以RAG为主干，把KG和结构化数据作为检索结果的"补充证据"，而不是取代文本切片。

1.2 PDF的四种真实形态：选工具前的第一道分拣

PDF是RAG数据源里最复杂的格式，因为"PDF"这三个字背后至少有四种完全不同的东西。我在项目里踩过最大的坑，就是没有先分桶，直接拿统一工具去解析，结果一半文件乱码、一半文件空白。现在我把PDF分成四种形态，每一种对应的解析策略完全不同。

判断一份PDF属于哪种形态，不要靠肉眼，用工具说话。最快捷的办法是用PyMuPDF跑一页，看page.get_text()返回的字符数：如果整页少于50个字符，基本可以判定这个页面是图片型，必须走OCR或图像理解。如果页面上有大量文本但混杂多处图片，那就是图文混排型，需要把图片区域单独抠出来处理。先花五分钟分桶，比后面花两小时调解析器要值得多。

1.3 解析管线的整体设计：解析不只是"变成文本"

很多人把PDF解析等同于"把PDF变成TXT"，这是误区。解析阶段真正要产出的是"结构不丢失的干净文本"，让后续分块和向量化拿到最高质量的输入。我总结的解析管线包含五个环节：

1. 格式识别与分桶：判断PDF形态，分发到不同的解析通道
2. 工具适配：文本型走提取工具，扫描件走OCR，复杂版面走多模态或表格解析
3. 清洗与归一化：去掉页眉页脚、目录重复项、参考文献噪音、乱码字符，统一换行和标点
4. 分块与组装：按章节标题、段落边界、表格完整性合并成语义完整的文本块，保留页码和来源元数据
5. 质量抽检：抽出少量解析结果做人工检查，重点看表格是否错乱、标题层级是否保留、乱码率是否在阈值内

这套管线设计完后，才轮到embedding和向量库上场。经历过几个真实项目之后我的体会是：RAG效果的天花板不是模型，而是解析这层。embedding和重排模型只能算是锦上添花，解析才是雪中送炭——文本都提取不出来，后面调什么参数都是白搭。

2. 九种PDF解析工具选型全景对比

2.1 文本型PDF四件套：PyMuPDF、pdfplumber、pdfminer.six、pypdf

先说说处理原生数字文本型PDF的四个主力工具。这四件套我几乎每个RAG项目都会用到，但各司其职，别指望一个工具通吃。

**PyMuPDF（fitz）**是我日常用得最多的，C语言底层封装，解析速度快到离谱，一秒钟能抽几十页文本。它最牛的地方是能同时拿到文本块、图片、位置坐标（bbox），这意味着你可以根据坐标判断哪段文本是标题、哪段是页脚、图片嵌在哪一栏。中文字体兼容性也不错，提取内嵌字体的PDF基本不会乱码。缺点是对复杂表格的行列顺序还原一般，偶尔会把跨栏文本的顺序排错。

pdfplumber是表格提取的神器，底层依赖pdfminer.six，但把文本、表格、线条的API封装得极其好用。page.extract_table()加几个参数就能把表格按行列关系输出成二维数组，还能设置表格识别规则（比如垂直线的容差、表格边界的判定）。代价是速度比PyMuPDF慢一截，一个几十页的PDF可能要跑十几秒。适合合同、发票、银行流水这种表格密集的场景。

pdfminer.six是底层解析库，pdfplumber就是基于它封装的。它能精细控制版面分析参数（LAParams），包括多栏检测、字符间距容差、行距阈值。当你发现pdfplumber对某种双栏排版识别不准，想"手工调教"时，就得回到这层。缺点是没有现成的高层API，写起来繁琐，适合做定制化解析的底座。

pypdf则是轻量级PDF处理库，合并、拆分、加密解密、读取元数据是它的强项，但文本提取质量比较粗糙，不适合作为主力提取器。我的用法是：把用户上传的PDF先交给pypdf做合法性校验、页面合并、密码处理，再交给后面三个工具做真正的文本提取。

四件套的选型逻辑很简单：追求速度和覆盖率用PyMuPDF，追求表格精度用pdfplumber，遇到奇葩排版用pdfminer.six调参，PDF的预处理杂活交给pypdf。

2.2 扫描件与中文OCR：Tesseract与PaddleOCR的正面对决

扫描版PDF唯一的出路就是OCR。OCR领域的开源工具，绕不开Tesseract和PaddleOCR这两个名字。

Tesseract是老牌开源OCR，Google维护，支持上百种语言。问题在于它对中文的支持比较勉强——需要单独下载chi_sim语言包，而且对小字号、低对比度中文的识别准确率不太稳定。我见过不少桌面PDF编辑器，安装OCR语言包时下载的其实就是Tesseract的模型文件，福昕、搜狗PDF编辑器里的OCR功能基本是这个路子。如果你的扫描件是英文、字母数字为主，Tesseract够用；如果是密密麻麻的中文小字合同，我建议直接放弃Tesseract。

PaddleOCR（飞桨PP-OCR系列）是目前中文OCR的开源天花板。它不只是简单的OCR引擎，而是一整套文档分析工具箱：文本检测、方向分类、文本识别、版面分析、表格识别都覆盖。尤其PP-OCRv4之后的中文识别准确率，在常见合同、发票、书籍场景下已经能打。PaddleX的create_pipeline一行代码就能跑完整的OCR管线，部署也支持本地推理，中文RAG项目里我首推它。

OCR不是"把图丢进去就出文字"这么简单，预处理能决定识别率的八成。我自己固定的预处理三件套是：灰度化或二值化（去掉彩色背景干扰）、去噪（去掉扫描件上的黑点线条）、纠偏旋转（摆正歪斜的页面）。还有DPI问题——低质量扫描件至少要提升到300DPI再喂给OCR，否则小字号识别率会断崖式下跌。代码层面，可以先用PyMuPDF把PDF页渲染成300DPI的PNG，再做以上预处理，最后进OCR。

2.3 复杂版面的终结者：多模态大模型的定位

如果OCR是"把图里的字抠出来"，那么多模态大模型干的是"把整页纸看懂"。Qwen-VL、GLM-4V这一类视觉语言模型，不仅能识别文字，还能理解版面结构——哪行是标题，哪段是正文，哪个区域是表格，哪块是页眉页脚，哪些是装饰性元素。它们可以直接输出Markdown、HTML、JSON这类结构化格式，相当于把解析和结构化合并成一步完成。

我试过用多模态模型解析那种设计感很强的产品手册：图片是一整页渲染图，上面压着带花纹的文字，旁边还有坐标系和示意图，传统OCR基本是灾难现场。多模态模型却能把"标题、正文、表格、图片说明"整理成工整的结构化文本，甚至能把图表里的关键趋势总结出来。这就是OCR和多模态模型的本质区别：OCR在识别文字，多模态在理解文档。

但多模态模型不是万能的。第一，慢，单页推理耗时通常是几秒到十几秒，几百页的PDF全量跑一遍会等到怀疑人生；第二，贵，按token计费的方式在文档量大的场景下成本不可控；第三，有幻觉，模型偶尔会把不存在的断言写进输出。所以我给出的使用策略是"分层精洗"：先用便宜的文本提取或OCR做全量粗解析，只把那些"文本量极低但版面复杂""OCR置信度偏低""标题层级识别失败"的高价值页面挑出来，送给多模态模型做精修。粗解析覆盖80%的普通页，多模态集中清理20%的疑难页，性价比最优。

2.4 一体化方案：Unstructured、Docling与商业OCR API

如果不想自己拼一堆工具，市面上还有"全家桶"式的解析方案。

Unstructured是目前RAG社区最流行的开源解析框架之一，它把PDF按文档要素分区，输出成标题、正文、表格、图片、页眉页脚等元素列表，天然就是为后续分块设计的。底层的文本提取支持pdfminer、PyMuPDF，OCR可接入Tesseract，还可以加嵌入模型。适合想做标准化数据管线的团队。

Docling是IBM开源的新秀，文档理解能力更强，擅长保留引用结构、目录层级和多栏布局，对科研论文、标准规范类文档尤其友好。最近几个版本加了版面分析模型和表格识别模型的支持，整体解析质量很能打。"有没有本地的RAG文本拆解工具"——如果你也在搜索场上提问，我明确推荐：本地部署Unstructured+Docling，再接PaddleOCR，就是一个完全离线、且效果不输商业SDK的解析组合。

商业OCR API则是另一个维度的选择。百度OCR、腾讯OCR这类服务，识别精度高、自带表格识别和版面分析、不需要自己维护模型服务，API调用就能接入。代价是费用、限额和数据隐私。适合不想折腾模型、量大且对稳定性要求高的场景。我在项目里接到过同事用VBA调百度云OCR识别合同的需求，也处理过Java调百度OCR从合同文件里提取收入、单位、时间字段的场景——在业务系统中，商业API的成熟度是自研方案很难比的。拿百度OCR举例，它把"营业执照识别""合同要素抽取"都做成了独立接口，比通用OCR适配得更精准。注意调用方式：密钥一定要放在服务端，别写进前端代码，否则隐私和成本都失控。

2.5 九种工具横向对比：一张表看清怎么选

把这九种工具放到一张表里，选型逻辑就非常清晰了。

我的习惯是默认组合拳：PyMuPDF做全量文本提取，pdfplumber处理表格密集段落，PaddleOCR处理图表和扫描区块，多模态只解决最难的10%——这样一个流程下来，覆盖率和准确率都兼顾了。

3. 实操三条解析管线：从PDF到可检索的干净文本

3.1 管线一：原生文本PDF的快速入库

原生数字文本型PDF是最幸福的情况，用PyMuPDF搭pdfplumber双引擎，很快就能拿到干净文本。

import fitz # PyMuPDF import pdfplumber # 第一层：PyMuPDF快速提取全文，按页保留 doc = fitz.open("report.pdf") page_texts = [] for page_num in range(len(doc)): page = doc.load_page(page_num) text = page.get_text("text") page_texts.append({ "page": page_num + 1, "text": text }) # 第二层：对疑似表格密集的页面，用pdfplumber做表格提取 with pdfplumber.open("report.pdf") as pdf: for i, page in enumerate(pdf.pages): tables = page.extract_tables() if tables: # 将表格转成Markdown风格文本，保留行列结构 md_table = "\n".join( "| " + " | ".join(cell.replace("\n", " ") if cell else "" for cell in row) + " |" for row in tables[0] ) page_texts[i]["tables"] = md_table

提取到raw文本之后别急着入库，还有三个清洗动作我每次都会做：

1. 剔除目录页。目录页在RAG里是噪音，命中它会让回答变得驴唇不对马嘴。怎么识别？目录页通常有大量"点线+页码"，检测到连续多行以数字结尾且不含句号的长尾文本，整页丢掉。
2. 过滤页眉页脚。用PyMuPDF拿到的坐标信息能帮上大忙：页眉和页脚通常出现在每页固定的顶部和底部区域，统计所有页面相同坐标位置的重复文本，一致就全局删除。
3. 合并跨页表格。pdfplumber单独提取每页表格时，跨页表格会被拆开。我的处理方式是用表格的首列内容做前后页匹配，如果相邻两页的首列键值序列连续，就把表格合并成一个整体再转Markdown。

3.2 管线二：扫描版PDF的OCR全流程

扫描版PDF的实操流程是"渲染页面→图像预处理→OCR→置信度过滤→组装文本"。我用PaddleOCR作为例子，完整流程这样写：

import fitz from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang="ch", show_log=False) def pdf_to_ocr_text(pdf_path, dpi=300): doc = fitz.open(pdf_path) results = [] for page_num in range(len(doc)): page = doc.load_page(page_num) # 渲染成高分辨率图像，注意dpi参数 pix = page.get_pixmap(dpi=dpi, colorspace=fitz.csRGB) img_path = f"page_{page_num+1}.png" pix.save(img_path) # OCR识别 res = ocr.ocr(img_path, cls=True) # res格式: [[[box, (text, confidence)], ...]] lines = [] for line in res[0]: text = line[1][0] conf = line[1][1] # 置信度阈值过滤，低于0.6的文本多半是错识 if conf >= 0.6: lines.append(text) results.append({ "page": page_num + 1, "text": "\n".join(lines) }) return results

这一段代码里最容易翻车的三个细节，我全踩过：

第一，渲染时必须显式指定colorspace=fitz.csRGB。很多扫描件的PDF底层色彩空间是CMYK，不转RGB出来的PNG颜色是反的，OCR识别率直接崩掉。第二，PaddleOCR默认模型只在中文和英文上表现好，识别韩文、日文要换参数，PaddleOCR(lang="korean")或lang="japanese"，搜到"OCR代码识别不了韩文"问题的人基本都是漏了这一步。第三，OCR输出的行顺序是按检测框来的，不一定是阅读顺序。按文本框的top坐标排序，再按left坐标排同一行的左右顺序，否则表格和段落顺序会乱。

OCR完成后的文本组装，也要保留页码和边框坐标。建议把每行的bbox坐标一起存下来，理由是后续如果发现某个段落语义不连贯，可以通过坐标重建上下文。

3.3 管线三：复杂版面用多模态大模型做结构化输出

遇到那种整页都是渲染图、图文混排、扫描质量差的高难度PDF页面，就把数据送给多模态模型。以国内可用的视觉理解模型API为例：

import base64 from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1" ) with open("hard_page.png", "rb") as f: img_base64 = base64.b64encode(f.read()).decode() response = client.chat.completions.create( model="qwen-vl-plus", messages=[{ "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img_base64}"}}, {"type": "text", "text": "请把这一页PDF转成Markdown格式。要求：1) 保留标题层级和加粗；" "2) 表格用Markdown表格输出；3) 忽略页眉页脚和装饰性二维码；" "4) 图片区域用[图片描述]占位，一句话概括图片内容。不要输出解释，只输出Markdown。"} ] }] ) md_output = response.choices[0].message.content

提示词的写法非常关键，不是简单说"帮我提取文字"。我给出上面这份提示词的底层逻辑是将任务分成了三块：提取的内容范围（保留标题和表格）、排除的噪音（页眉页脚二维码）、特殊元素的处理方式（图片用描述占位）。占位符[图片描述]尤其重要，很多团队忽略了这个细节，导致图片在检索和生成阶段完全隐身。多模态模型每张图都能看，却没把图片信息落到文本里，等于白用。

多模态精洗只处理"疑难页"，不要整本书都喂给它。我的判断规则是：一页文本提取字符数小于200、或页面中图片数量大于等于2、或OCR平均置信度低于0.7，才送进多模态管线。

3.4 解析后的文本组装：分块前的最后一次加工

解析完成后，进入分块器之前，还有一个组装环节。很多团队在分块这一步效果不好，根源在组装阶段就没做好。我总结三个高频必踩的组装动作：

第一，标题层级透传。文本提取和OCR都容易丢掉标题信息，组装时通过字体大小（文本型PDF）或版面坐标（OCR）判断哪些文本是标题，给它们打上H1/H2/H3标签，分块器才能按标题切分。第二，上下文连续性补偿。如果页面中间被页眉页脚打断，需要把正文按阅读顺序重新拼接；如果表格跨页，要把表格内容合并到一个块。第三，原文双轨保留。解析文本用于检索，但每个文本块的元数据里保留"来源文件、页码、原文截图路径"——检索命中后，生成回答时引用原文段落或页面截图，RAG的幻觉率能明显下降。我自己的项目里，双轨制让回答的可信度提升非常明显，用户反馈"有据可查"的比例大幅上升。

组装完成后，用递归字符切分器，固定chunk_size=800、chunk_overlap=150，先按标题切，再按段落边界修正，基本就能得到质量不错的分块结果。注意给每个块加上文档级别的系统提示词模板，比如"你是产品手册问答助手，只能根据手册内容回答"——这会在检索阶段提升命中质量。

4. 常见问题与排查技巧实录

4.1 处理PDF解析翻车现场：乱码、空白、表格错乱

PDF解析的坑，来来回回就那么几个。我把处理过的真实问题和排查思路整理成速查表，希望能帮你少走弯路。

排查乱码时有个小技巧：先用page.get_text("dict")看提取结果里text字段的类型——如果返回的是十六进制字符串或方括号包裹的CID码，说明字体没有任何Unicode映射表，这种PDF无论换哪个解析库都是一样的结果。别浪费时间去换工具，直接渲染页面走OCR。

4.2 OCR专属问题：韩文、图片型PDF、置信度过滤

OCR方向的坑，和文本提取完全不同路数。

韩文日文识别不出来，我见得太多了。原因很简单：PaddleOCR默认lang="ch"只覆盖中文和英文，韩文文字结构不同，中英模型会把韩文当成图形乱画。解决就一句话：初始化的时候指定PaddleOCR(lang="korean")。Tesseract则需要下载kor对应的语言包，效果还未必理想，韩文项目我更推荐PaddleOCR或商业API。

"file format error"这个报错，很多人一脸懵。排查后发现：用户上传的所谓PDF根本不是PDF，是图片改了后缀名（.pdf），或者是从某些扫描机导出的非标准封装伪PDF。判断方法很简单：用文件头判断，PDF文件头必须是%PDF。如果打开bin格式看到是JFIF或PNG，直接按图片处理，走OCR就好。

OCR结果的置信度过滤很多人不做，导致垃圾文本直接进了知识库。我在生产管线里的经验是：设两道阈值。第一道，单行文本置信度低于0.6的整行丢弃；第二道，整页平均置信度低于0.5的页面做标记，送人工复核或送多模态模型精洗。OCR毕竟有错，不做置信度管理的知识库，检索质量会掉得很隐蔽。

还有一个非常容易踩的重复文本坑：扫描版PDF如果已经用某种软件做过"文字层增强"，它可能同时有文字层和底图。你再做OCR时，会得到一行文字被识别两遍——一遍来自文本层提取，一遍来自图片识别。排查方法：先跑page.get_text()看有文本层就不要再对同样区域做OCR了。判定标准：文本层正常则纯提取，文本层缺失才OCR，绝不两个同时上。

4.3 三条独家避坑经验

第一个经验是"先分桶再批量"。同样一批上传的PDF，有的来自Word打印、有的是扫描仪出的、有的是网页另存为，形态天差地别。不要指望一个工具通吃，先把每个PDF的每页状态跑一遍，统计有多少页属于文本型、多少页是图片型，再分别调度解析通道。哪怕多写500行分桶逻辑，也比你事后拿着一堆乱码返工要值。

第二个经验是"抽检制度化"。解析质量不能只靠日志，我推荐每次入库后随机抽0.5%的页面做肉眼检查，重点看三件事：标题层级是否完整、表格行列是否错乱、是否存在明显乱码。抽样检查比任何指标都要直接。有一次全量跑完翻车，指标看着都正常，抽样看到了海量表格变成横向排列的纯文本，才发现表格解析配置挂了。

第三个经验是"解析结果持久化"。解析出来的文本、每个块的元数据、OCR的置信度、原始页面截图，全部存下来。好处有三：调试向量检索问题时能回溯到解析层；数据源更新后可以增量重新解析，不用全部重跑；给用户展示引用来源时，能直接调出原始页面截图。这一步做好，后续整个RAG系统就像造在结实地基上的房子，怎么扩充都不怕。

最后说点实战体会

九种工具摆出来容易，真正用到项目里你会发现，正常情况下只需要三种组合：PyMuPDF做文本提取，PaddleOCR做OCR，多模态模型精洗疑难页，这个铁三角能覆盖市面上90%的PDF解析需求。我见过一个团队花了三周时间调多模态模型解析所有页面，最后发现用pdfplumber加简单分桶就能解决80%的问题，剩下20%的高难度页才值得动用多模态。解析这条路没有银弹，先把流程搭好、把抽检做好，比纠结选哪个工具重要得多。这篇先把图文与PDF解析讲透了，下一篇我会展开分块策略与索引构建的参数细节，包括向量维度、重叠token、混合检索的权重怎么调这类更偏调优的实操。希望这套流程能帮你少踩一些我已经踩平了的坑。