企业官网建设流程全解析

做RAG知识库的朋友，大多在图文和PDF解析这一步卡过壳。一个几百页的PDF，原生文本还好说，扫描件、图表、签名、两栏排版混在一起，很容易让预处理出来的文本块变成一团乱麻。上一篇我们讲了文本类数据导入的完整链路，这篇专门把图文与PDF拆开讲透：OCR该怎么选、多模态大模型什么时候上、九种PDF解析工具各自适合什么场景，整理成可以直接抄作业的选型表和避坑清单。内容覆盖从开源引擎到商用云服务的实际落地方案，适合正在搭RAG系统、或者想把知识库导入质量再提一档的开发者。

1. 图文与PDF解析的整体设计思路

1.1 为什么图文和PDF是RAG导入里最麻烦的一环

图文和PDF让导入器头疼的本质，其实是信息形态不统一。纯文本数据天然有段落边界，按句号、按标题、按代码块都能切出比较干净的块；图像没有“文本树”可以遍历，文字藏在像素里；PDF又分数字原生和扫描件两类，前者内部可能是多个图层、注释流、乱序文本块叠加，后者基本就是一张大图片。

哪怕表面看着规整的PDF，文本在文件里也可能是按绘制顺序乱排的。有的排版引擎先写页眉页脚，再写正文栏，最后补表格边框，直接抽取出来的文本顺序和屏幕上看到的完全对不上。如果这时候就按字符串硬切分块，很多语义连续的内容会被拦腰截断，向量检索的召回率会肉眼可见地下降。

所以图文解析的核心不是“能不能取出文字”，而是“取出文本、位置、结构之后，能不能在RAG查询时把它们还原成语义块”。解析阶段丢掉版面关系，后面重排序、上下文构建做得再好都补不回来。

1.2 三条技术路线的适用边界

针对RAG场景，图文PDF解析可以归纳成三条主线：

• 传统OCR路线：Tesseract、PaddleOCR、各厂商云OCR。核心是把图像里的文字转成可检索文本，适合扫描件、图片型PDF、验证码和表单字段抽取。
• 多模态大模型路线：GPT-4o、Qwen-VL、Claude、InternVL等视觉语言模型。不仅能识别文字，还能理解图表意图、流程图结构、公式语义，适合版面复杂、图文混排、需要“看懂”内容的文档。
• PDF解析工具路线：pypdf、pdfplumber、PyMuPDF、Camelot、Tabula等。直接读取PDF内部对象，适合数字原生的文本型PDF，尤其是表格结构还原和坐标定位。

选择标准不复杂：原生文本PDF优先走PDF解析库，速度快、成本几乎为零；普通扫描件用OCR；复杂版面、图表、手写批注交给多模态模型；表格密集的文档用Camelot这类专门工具。不是说哪种技术更高级就全用哪种，而是按文档类型做分流。

1.3 “先分流、再解析”的流水线设计

我自己在项目里跑通的方案是四段式流水线：文档分类 → 解析通道 → 结构化输出 → 分块入库。

文档分类这一步最容易被忽略。一个知识库导入几百个PDF，里面可能80%是数字原生、15%是扫描件、5%是带复杂图表的。先用PyMuPDF快速抽样几页，检测页面是否包含文本层；再用文件扩展名、页数、是否含图片对象做特征判断，把文档分到不同解析通道。

解析通道按类型配置：文本型PDF走pdfplumber，扫描型走PaddleOCR，板式复杂的走多模态模型。结构化输出阶段统一为一个JSON格式，包含text、bbox（位置坐标）、page、table、image_caption等字段。最后才轮到分块和向量化。这样设计的好处是，后续要换OCR引擎或者加一个版面分析模型，只需要改对应通道，不影响上下游。

提示：不要幻想一个工具通吃所有PDF。工具越多，每个工具只负责它最擅长的那部分，整体稳定性反而越高。

2. OCR实战：从开源引擎到商用云服务

2.1 开源引擎与云API怎么搭配

OCR选型第一步是确定自建还是调API。开源方案里有名的是Tesseract和PaddleOCR。

Tesseract是老牌开源引擎，支持60多种语言，安装简单，命令行就能跑。但它对复杂版面的支持比较弱，表格和图文混排的识别效果一般。PaddleOCR是百度开源的工具集，模型体积小、中文识别效果好、支持版面分析和表格结构还原，RAG场景里我用得最多的是它。

云API这边，百度OCR、腾讯云OCR、阿里云OCR都比较成熟，适合不想折腾模型部署、或者需要合同关键字段抽取这类定制能力的团队。我见过不少项目是这么搭配的：核心PaddleOCR自建，量大的通用图片走云API兜底，两边结果做交叉验证。这样既控制成本，又避免单点故障。

2.2 图像预处理是识别质量的一半

OCR识别率低的时候，先别急着怪引擎，大多数问题是图像本身没喂好。我踩过的坑可以总结成几句话：

• 扫描件先做灰度化和二值化。彩色扫描图里有很多噪声，转灰度后通过自适应阈值二值化，文字和背景的对比度会明显增强。
• 有阴影、水印的页面要降噪。OpenCV的中值滤波能去掉椒盐噪声，但对细小文字要慎用，滤波核太大会把笔画也抹掉。
• 倾斜页面必须校正。扫描时纸张放歪几度，整页文字检测框就会偏。用Hough变换检测直线倾斜角，再做仿射变换回正，识别率能提升一大截。
• 输入分辨率建议控制在300 DPI左右。太低文字糊，太高会增加计算量，300 DPI是我试过性价比最高的点。

预处理脚本不复杂，但能直接影响OCR的成败。建议把预处理做成独立的模块，放在OCR引擎前面，方便换引擎时复用。

2.3 中文、韩文与多语种识别的坑

有朋友抄了PaddleOCR的pipeline代码，发现韩文识别不出来，以为模型不支持。其实PaddleX的OCR pipeline默认是按中文场景配置的，要识别韩文需要确认两件事：一是有没有指定语言方向分类器，二是识别模型是否下载了对应的多语种模型文件。

paddleocr --image_dir test.jpg --lang=korean

如果用PaddleX代码调用，需要在pipeline配置里显式开启多语种识别，或者选择包含多语种识别的模型权重。Tesseract那边更直接，需要额外安装语言包：

apt-get install tesseract-ocr-kor tesseract-ocr-chi-sim tesseract image.jpg output -l kor+chi_sim

这里有一个容易忽略的细节：Tesseract的多语言参数顺序会影响识别结果，-l kor+chi_sim表示先按韩文模型再按中文模型做补充，适合韩文为主、少量中文混排的页面。如果一篇文档里多种语言混排，建议先做版面分割，再按区域分别指定语言，不要试图让一个引擎在整页上把所有语言都识别对。

2.4 让OCR输出结构而不是纯文本

很多人用OCR只拿到一个纯字符串，这对RAG来说远远不够。扫描版的表格文件，文字被一行行抽出来，表格结构完全丢失，检索“供应商报价”时根本找不到对应行。

现在的主流OCR引擎基本都支持结构化输出。PaddleOCR的OCRResult包含文本框坐标、置信度和文本内容，新版本还能输出表格的HTML结构。处理表格时，我会让OCR先生成带坐标的字段列表，然后按行号、列号聚类，重构出表格结构，再转成Markdown表格或JSON存储。分析报告、票据、合同这类文档，还会配合正则和实体识别做关键字段抽取，比如京东物流单号、发票代码、合同金额。

注意：OCR输出的坐标是像素坐标，不同分辨率下会变。如果要把位置信息用于后续版面分析，记得同时保存DPI信息，否则换一台设备解析结果就对不上了。

3. 多模态大模型解析图文内容

3.1 多模态模型到底解决了什么

多模态大模型和OCR最大的区别，是一个在“看”，一个在“读”。OCR做的是像素到文字的映射，而多模态模型能理解图表里“为什么销量会下降”、流程图里“步骤A之后分两条分支”这类语义关系。RAG系统如果要让用户问“架构图里数据流向是怎样的”，传统OCR给不出答案，多模态模型能。

实际项目中，多模态模型的典型角色有三个：图表解析器、版面理解器和文档摘要器。图表解析器负责把折线图、柱状图、架构图转成结构化描述；版面理解器负责识别标题层级、正文区域、页眉页脚，判断哪些内容应该合在一起、哪些应该拆开；文档摘要器负责为图片或整页生成一句话摘要，让RAG在召回时能用摘要做索引。

3.2 怎么把多模态模型纳入RAG解析流水线

我建议把多模态模型放在解析通道的“精加工”位置，而不是每个文档都跑一遍。具体做法是：先用PDF工具或OCR快速生成基础文本块，再用多模态模型补充图文关系和语义描述。

比如一份产品手册里有一张设备连接图，图片旁边是步骤说明。基础管线抽到的是：“将网线插入LAN口”、“连接电源适配器”两段文本，以及一张无标注图片。多模态模型介入后，可以生成一句图片描述：“设备连接图，显示主机LAN口连接交换机、电源适配器连接市电”。把这句话作为图片的替代文本块，和步骤说明一起入库。用户问“怎么接线”时，检索系统既能召回文本块，也能通过图片描述召回这张图。

如果条件允许，还可以把多模态模型接到图像编码器上，把整张图片转成视觉向量，和文本向量放到同一个向量空间里做混合检索。这个方案更先进，但对基础设施要求高，一般团队先做替代文本方案就够用了。

3.3 成本、延迟与幻觉的控制

多模态模型按图片调用，价格不便宜，解析一个100页的PDF，如果每页都调用一次，成本能到几十元。控制成本有三个办法：

• 先用OCR判断页面有效信息密度。纯封面页、空白页、重复页直接跳过，不调多模态。
• 同一类图表用低规格模型批量识别，只有识别置信度低时才升级到高规格模型。这个分级调用的思路，和前端懒加载很像，先用廉价方案兜底，遇到硬骨头再上重武器。
• 做缓存和幂等。图片内容的哈希值作为缓存键，同一个图重复出现时直接取缓存结果，别重复推理。

幻觉问题的根源是模型在“生成”描述，不是“提取”事实。控制办法是多模态模型只输出结构化JSON，字段固定为summary、entities、relation，不要让它自由发挥。对关键数字和专有名词，要求模型引用原文位置，输出后与OCR文本交叉验证，不一致就以OCR结果为准。

4. 九种PDF解析工具的选型

4.1 选型速查表

下面这个表是我个人整理的工具清单，按“工程化库”和“桌面工具”分两类。RAG项目里绝大多数需求，靠工程化库就能满足，桌面工具更多用于人工补录和小规模处理。

4.2 工程化库逐个说

pypdf是基础款，适合处理元数据和简单的文本提取。PyPDF2和pypdf有一段分裂史，现在官方推荐使用pypdf，功能更新更勤。它的文本提取能力很弱，但对于快速判断一个PDF是否有文本层、页数是多少，已经够了。

pdfminer.six是很多上层库的地基。它能拿到字符级的位置信息，可以自己拼装成任意粒度的“文本块”。缺点是需要读源码才能用好，适合有专门精力去啃解析细节的团队。

pdfplumber是我在RAG项目里的主力。它基于pdfminer.six，但封装得更顺手，可以直接调用extract_text()、extract_table()，还能通过char.bbox拿每个字符的坐标。处理数字原生的表格PDF，比如财报、物流单，效果好。

PyMuPDF的速度非常快，页面渲染性能远超pdfplumber。我用它做两件事：一是高速抽取文本跑初筛，二是把页面渲染成PNG喂给多模态模型。它的文本提取会丢失一些排版细节，但跑批量任务时很稳。

pdf2image是扫描件解析的桥头堡。它把PDF页转成PIL图像，后面再接PaddleOCR或Tesseract。需要注意它依赖系统安装的poppler，在macOS和Linux上常见，Windows上要自己配好环境变量。

Camelot和Tabula都是专门的表格解析工具。Camelot用OpenCV检测表格线，Tabula基于PDFBox直接读取。实测下来，有线框的规范表格Camelot更准，无线框的松散表格两者都不行，还得靠OCR后的结构重建。

4.3 桌面和在线工具怎么补位

RAG流程里总有一些机器搞不定的PDF，比如印刷模糊、盖章覆盖文字的扫描件。这时候手工清理几页是最高效的。Adobe Acrobat Pro的OCR功能有文字识别和文本编辑两个层次，识别后可以直接搜索；福昕高级PDF编辑器在国内环境里处理中文扫描件更友好，还支持安装OCR语言包，比如ocr-zh-cn.fzip。这类工具适合做“最后一道人工兜底”，不适合写进自动化流程。

表格里的在线PDF转换网站我不推荐用于RAG数据准备，文件上传后有隐私风险，而且转换结果格式不统一，反而增加后续处理成本。真要转PDF，用桌面工具或本地命令行工具，数据不出本机。

4.4 一套混合流水线的落地参考

我最近给一个企业知识库项目搭的解析链路是这样的：

第一阶段，用PyMuPDF批量抽取所有PDF文本，判断页面是否有文本层。第二阶段，有文本层的页面交给pdfplumber提取文本和表格，无文本层的页面用pdf2image转图片。第三阶段，图片跑PaddleOCR拿基础文本，同时抽样10%的复杂页面调用多模态模型生成图表描述。第四阶段，统一成JSON格式，按页面维度分块写入向量库。

这个链路跑下来，单页处理成本大概比全量多模态方案低70%，复杂版面文档的召回率比纯OCR方案高15%左右。性价比平衡点就在“OCR兜底、多模态精加工”的配合上。

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

5.1 高频报错速查

这里整理了RAG数据导入里经常碰到的问题，都是群聊和帖子里反复出现的。

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

这是一个被问了很多次的问题。答案是可以，但方式有讲究。

第一种做法是存“图片的替代文本”。OCR或多模态模型把图片转成描述文字，文字进向量库，图片文件本身放在对象存储里。用户检索时召回到文字块，点开详情再看到原图。这种方案实现简单，召回效果稳定，绝大多数团队都用这条路。

第二种做法是存“图片向量”。用CLIP、Qwen-VL这类多模态编码器把图像直接嵌入向量空间，文本查询时通过跨模态检索找到图片。效果好，但需要维护两套向量索引，而且要保证文本和图像的向量空间对齐，工程复杂度高不少。

我的建议：先做第一种，等业务方明确提出“按图检索”需求，再上第二种。不要一开始就铺多模态向量方案，容易在基建上消耗太多精力。

5.3 RAG、知识图谱与结构化知识库怎么选

这三个概念经常被放在一起比较，但它们解决的问题不同。

RAG知识库以向量检索为主，适合开放语义问答和相似内容召回，比如“公司有哪些远程办公制度”“这份合同的违约责任在哪个条款”。它的优势是不需要预先定义实体关系，导入文档就能用。

知识图谱（KG）以实体和关系为主体，适合精确推理和多跳查询，比如“哪些供应商同时给A项目和B项目供货，且评级为高风险”。它的构建成本高，需要本体设计、关系抽取、数据融合，但推理能力是RAG替代不了的。

结构化知识库指以数据库表结构组织的数据，适合精确属性查询，比如“查询库存表中所有安全库存低于100的SKU”。它最可靠，但无法理解自然语言，需要严格约束。

落地时建议混合使用。文档类内容走RAG，需要精确推理的领域实体走知识图谱，主数据和指标类走结构化数据库。三者可以共用一套查询入口，用户问题先规则路由，再交给对应引擎。热词里提到的ontology RAG，本质就是在RAG检索前用本体约束实体含义，从而减少同义词和歧义带来的误召回，这个我们后续可以单独展开。

5.4 解析质量才是RAG瓶颈里的硬瓶颈

讨论RAG瓶颈时，大家习惯把锅甩给向量检索和重排序。但在真实系统里，解析阶段造成的损失往往更大。文本错乱、表格丢失、图片空白，这些信息在源头就没进库，后续的召回和生成技术再强也救不回来。

我做过一次对比实验：同样的文档集，一套用默认文本提取切块，一套经过完整版面解析后再切块，Top-5命中率差了将近20个百分点。很多“这RAG怎么这么蠢”的反馈，排查到最后都是第一道解析环节的问题。

所以建议在RAG上线前，先做一次解析质量审计：抽样30页文档，人工检查抽取结果里的乱序率、表格完整率、图片描述覆盖率。设定一个基线，比如乱序率低于5%才能进入向量化阶段，不达标就回头调解析通道。质量基线这东西，越早定越省心。

6. 写在最后的实操体会

图文和PDF解析这块，我在项目里反复试错后有一个很深的感觉：技术栈堆得越高，越要重视基础环节的工程化。OCR引擎换一个、多模态模型换一个，周期都不长，真正麻烦的是每个文档类型背后的版面逻辑。有时候一份PDF里混着横排竖排、脚注尾注、代码块和插图，任何单一模型都处理不完美。我的做法是给每个解析通道配上独立的回归测试集，改完一个模块就把这几十个典型页面跑一遍，防止旧问题复现。

另外，解析流程不要一上来就追求完美。先用最轻量的工具把数据灌进去，跑通RAG闭环，再根据检索效果反向调解析策略。很多团队花了两周调OCR，发现用户问的问题根本用不到那些精细字段，这是本末倒置。

最后分享一个实用的小技巧：解析完一批PDF后，把结果JSON存一份快照。后面优化了解析算法，可以重新解析并对比新旧结果，这样每次改动都能量化出效果提升，而不是凭感觉觉得“好像变好了”。数据导入与解析是整个RAG工程的地基，这份攻略里列的工具和踩坑点，都是我自己真实跑过的，照着搭一遍，至少能让你少走一个月弯路。