企业官网建设流程全解析

1. PDF解析在RAG链路中的地位：不好好拆文档，检索效果注定拉胯

先说一个我自己的反直觉经验。去年我第一次搭企业知识库的时候，天真地以为PDF解析就是把文本从文件里“抠”出来，找几个Python库跑一下就行。结果上传了一份带复杂表格的券商研报进知识库，问答测试时，模型死活引用不对某一张表格里的数据。后来把原始文本抽出来一看，行顺序全乱了，数字和列名对不上号。从那时候我就明白：在RAG链路里，PDF解析不是“预处理”那么简单的角色，它几乎决定了知识库的上限。

为什么这么说？因为你给大模型喂的不只是“内容”，而是“结构化的内容”。如果解析出来的文本本身就是碎片化的、顺序错乱的，后面的向量化、召回、重排都是在水里有毒的池子里捞鱼。RAGFlow把文档理解这块单独做成一个引擎，名字叫DeepDoc，就是为了解决这个最容易被低估、又最影响最终效果的环节。

1.1 为什么PDF不能直接喂给LLM

很多人第一次接触AI知识库时都会有这个疑问：PDF本身就是文本，为什么不直接丢给大模型？这里有个潜在的认知误区：PDF格式保存的是“视觉排版信息”，不是“语义结构信息”。它记录的是每个字符应该出现在页面哪个坐标位置，而不是“这一段是标题”、“这一块是表格”、“这一句属于哪个章节”。

你直接用PyMuPDF、pdfplumber这类库去抽文本，遇到简单的单栏文字版式问题不大，但一旦文档里有分栏、图文混排、表格、页眉页脚、公式，抽出来的文本就会出现几种典型的“物理损伤”：

• 分栏文章的文字被按从左到右的阅读顺序混在一起，两栏内容交错穿插。
• 表格的行列关系完全丢失，变成一行行平铺的文本。
• 页眉页脚混进正文里，导致检索时频繁命中无关内容。
• 扫描版PDF根本没有文本层，直接抽取就是一片空白。

说白了，PDF的文本抽取是“从坐标恢复语义”的过程，这件事本身就是一个复杂的工程问题。DeepDoc的核心价值，就是把这件事做成了开箱即用的流水线。

1.2 三类PDF形态，解析难度完全不同

在实操中，我把常见的PDF总结成三种形态，解析策略完全不同：

大多数真实业务场景里的PDF都是第三种，比如合同扫描件后面又附了电子版附件，或者银行流水单是扫描的、对账单是导出的。DeepDoc在解析时会对每一页做判断，如果是纯文本页就走文本抽取通道，如果是图片页就自动切换OCR通道，这个过程不需要人工干预。

1.3 DeepDoc在RAGFlow里的位置和任务边界

RAGFlow作为一套开源的RAG引擎，整体架构里做了很明确的分工：DeepDoc负责“文档理解”，也就是把PDF、Word、PPT这些原始文件解析成格律化的结构化文本；DeepDoc之后，RAGFlow再对结构化文本做chunk切分、向量化、索引构建。如果拿人来做类比，DeepDoc相当于是“阅读并标注重点的助理”，后面真正“回答提问”的是整个RAG链路。

所以你在使用RAGFlow创建知识库、上传PDF时，前端展示的“解析进度”和“解析结果预览”，背后跑的就是DeepDoc。你可以把它理解成一座桥梁——桥如果断了，后面一切检索都是空中楼阁。

2. DeepDoc解析PDF的核心思路：不是上来就OCR，而是先理解版面再决定策略

DeepDoc和传统“打开PDF直接抽文本”的方案最大的区别在于：它在解析前先做版面布局识别，也就是说，它会先“看”页面，再用检测到的区域信息去引导后续的文本提取和OCR流程。

2.1 版面布局识别，一切解析的地基

版面布局识别的本质，是用目标检测模型对渲染出来的PDF页面图像做区域定位。DeepDoc内部集成了基于深度学习的目标检测网络（典型的是YOLO系列架构训练出来的模型），能够识别出页面里不同类型的区域。

我第一次看到DeepDoc的版面检测可视化结果时，发现它能把页面里这些区域都框出来：

• 文本段落区域
• 标题区域
• 图片区域
• 表格区域
• 公式区域
• 页眉页脚区域

这个步骤的意义非常关键。一旦知道了哪个区域是表格，后续的解析流程就会走表格结构化通道；知道了哪个区域是标题，就能在文本重建时保留层级关系；知道了哪里是页眉页脚，就可以在生成文本块时把这些干扰信息剔除掉。

这里有一个容易被忽视的细节：版面检测不是在原始矢量PDF上做的，而是先把页面渲染成图像。为什么？因为很多PDF的排版指令非常混乱，直接解析内容流很难还原“人眼看到的真实布局”，但渲染成图像之后，人眼所见即模型所见，检测目标就变得统一了。

2.2 OCR的触发逻辑和内置识别链路

OCR是OCR是很多人的第一个联想词，但DeepDoc的做法不是整篇PDF上来就OCR。它先尝试从PDF页面中提取文本层，如果某个区域能直接从文本层拿到内容，就没必要跑一遍OCR，因为OCR既慢又有识别误差；只有当页面缺失文本层，或者某个版面区域无法从文本层取到有效内容时，才会自动启用OCR流程。

我在分类整理业务文档时注意到一个明显的规律：电子生成的PDF，比如系统导出的报告、网页打印成的PDF，通常有完整的文本层，DeepDoc会在几秒内完成解析；扫描件和传真件则没有文本层，DeepDoc会转入OCR流程，耗时明显变长。

DeepDoc内置的OCR链路包含文字检测和文字识别两步：

• 文字检测用于定位图像中文字出现的区域，哪怕文字歪斜、被表格线截断，也要能框出包含文字的块。
• 文字识别负责把检测到的文字图像转换成字符串。

实测下来，DeepDoc内置OCR对印刷体中文、英文混排的支持度相当不错。我在测试一份扫描版的招标文件时，识别结果里的数字和关键术语基本都能保真。不过对于手写批注、印章覆盖区域的文字，识别准确率会明显下降。

2.3 文本块怎么拼装回可读顺序

版面检测和OCR之后，还有一个很重要的环节：文本重建顺序。PDF的读取顺序和人眼的阅读顺序不一定一致。DeepDoc需要根据版面布局信息，把分散在不同位置的文本块按合理的阅读顺序（从上到下、从左到右，考虑分栏结构）拼装起来。

以多栏排版为例，如果简单按坐标从上到下拼接，很可能会把左边栏的第一段和右边栏的第一段交叉拼到一起。DeepDoc的做法是：先识别页面里的栏结构，再在每一栏内部按行排布，最后按栏的顺序拼接。

这里补充一个我在解析报纸类PDF时发现的问题：如果版面里含有多层嵌套的图注、侧边栏、竖排文本，逼着解析器做“智能排版还原”是相当考验模型能力的。DeepDoc对常规的分栏文本处理得比较好，但遇到过于花哨的排版，仍然可能出现文本逻辑顺序不理想的情况。

3. 表格与复杂区域处理：真正的硬骨头在结构化输出

如果说版面识别解决的是“哪里是什么”的问题，那么表格识别解决的就是“表格里是什么”的问题。很多RAG场景下，用户提问的核心正是表格数据：“今年Q3的营收是多少”“这个月各渠道的转化率对比”之类。如果表格解析做不好，答案要么缺失、要么张冠李戴。

3.1 表格识别难点

表格识别的难点在于，PDF里的表格并没有统一的“标准定义”。有些表格有明确的横竖线，有些表格完全没有线，全靠空白和相对位置界定行列；有些表格有合并单元格，表头跨两列；还有些表格嵌套在图片里，要先OCR才能进一步处理。

DeepDoc会在版面检测识别出“表格区域”后，对该区域进行精细化的结构分析。对于有线表格，它通过检测表格线来切分行列；对于无线表格，则通过文本块在垂直和水平方向的投影分布来推断行列结构。

我在解析了一份带合并单元格的报表后，发现了一个常见现象：如果合并单元格跨两列，解析器有时会把合并单元格的内容重复匹配到两个子列。DeepDoc对这类情况的处理不能保证100%正确，所以在上传知识库后，我建议在解析结果预览页面人工扫一眼表格区域，必要时手动调整切分结果。

3.2 单元格结构重建与结果格式输出

DeepDoc在识别出表格行列结构后，会把单元格内容重建为结构化的数据格式，比如将表格输出为HTML或类似Markdown的格式。这样做的目的是方便RAGFlow后续切块时保持表格的行列对应关系。

我在解析结果预览里看到，DeepDoc能够把大部分常规报表还原成行列清晰的表结构，列头、数据行都能对应上。这项能力在很多RAG工具里是稀缺的，不少工具解析表格后只会把内容连成一串带顿号的文本，人的眼睛还能勉强看，但向量化后的检索效果就大打折扣。

3.3 公式、页眉页脚、多栏版式的处理倾向

除了表格，DeepDoc在解析策略里对以下几类区域的特殊处理，也值得展开说明。

• 公式区域：对于复杂的数学公式，DeepDoc会识别公式区域并尽量以合理文本形式抽取出表达式。实测下来，理工科论文里的行内公式还算可用，但复杂的分式、积分公式有时会转换成比较晦涩的文本结构。
• 页眉页脚：默认情况下，RAGFlow在切块时可以选择是否保留页眉页脚。我的习惯是关闭保留，因为页眉页脚对检索内容的贡献极低，反而会污染embedding向量。
• 多栏版式：通过版面检测识别分栏边界，重建时按栏顺序输出。实测对双栏排版还原效果不错，不用再像以前那样手工处理。

4. 从解析结果到知识库：RAGFlow的切块策略如何影响检索

DeepDoc完成解析后，输出的并不是一份“纯文本”，而是一条条带结构信息的内容块。RAGFlow拿到这些内容块后再进行“切分”，也就是chunking。这块操作看似简单，实际上直接影响检索命中率。

4.1 解析输出长什么样

DeepDoc解析PDF后的结果，可在RAGFlow的“解析结果预览”里查看。你会看到左侧是原始PDF页面渲染图，右侧是对应的结构化文本块。每个文本块可以是一个表格、一个段落、一个标题及其对应的正文。

我个人的经验是：上传PDF后不要急着建索引，先花几分钟看一眼解析预览。如果预览里的文本顺序明显错乱、表格结构丢失，那么无论embedding模型多好，检索质量都不可能好。这个“人工巡检环节”在RAGFlow里做起来非常方便，这也是它相比其他RAG框架更注重可观测性的一个优势。

4.2 知识库模板与切块参数

在RAGFlow中创建知识库时，可以选择文档模板，包括“一般”“问答”“手动”“Paper”等。模板决定了DeepDoc解析文档时的chunk切分策略：

切块参数里常用的有“Token数上限”和“重叠Token数”。Token数上限控制每个chunk的长度，重叠Token数让相邻chunk之间保留一定的上下文信息。

我在切块时踩过一个坑：一开始把Token上限设得过于大，想着“上下文越多越好”，结果向量化后，每块的语义过于拥挤，检索到的chunk常常同时包含好几个不相关主题，大模型回答时反而抓不住重点。后来我调到500左右，配合重叠Token 100，效果明显变好。这个参数没有绝对标准，不同文档类型需要实测调整。

4.3 chunk粒度对召回的影响

chunk粒度其实是在“语义完整”和“主题聚焦”之间找平衡。粒度太大，chunk内包含多个主题，向量化后主题被稀释，提问时概相似度分散；粒度太小，语义上下文不足，检索到的虽然精准但信息量不够回答完整问题。

举个例子，一份技术规范文档里，一个章节的某小节约2000字，如果全部塞进一个chunk，提问“该章节的总体要求”时召回没问题，但提问“其中某项指标阈值”时，向量可能被其他内容稀释。我通常的习惯是：

• 技术规格、产品参数类的文档，粒度可以适当偏小，300-400 token之间。
• 研究报告、综述类文档，保持500-600 token，保留完整论证过程。
• FAQ类文档，最好以“一问一答”为一个chunk单位。

5. 本地部署与模型接入：让DeepDoc真正跑起来的完整链路

聊了这么多原理，如果只停留在理论层面会显得空洞。这一节我把整个部署、配置、上传流程梳理一遍，按实操章节来写。

5.1 部署前的组件清单

RAGFlow本地启动的方式一般是通过Docker Compose拉起整套服务。部署时不会只启动一个DeepDoc，因为RAGFlow是一个完整系统，核心依赖组件包括：

• MySQL：负责存储知识库的元数据、chunk内容、配置信息。
• Elasticsearch：负责全文检索和向量检索。有的版本使用Infinity或其它向量库，但核心思想一致。
• MinIO：负责对象存储，存放上传的原始文件（PDF原件）和DeepDoc解析后的中间产物。
• Redis：承担缓存、队列等辅助职责。
• RAGFlow API服务器：对外提供RESTful API，接收文件上传、触发解析、构建索引。
• RAGFlow Web服务器：前端界面，就是你在浏览器里操作控制台的部分。

如果是生产环境部署在Kubernetes里，也可以用Helm Chart来部署，RAGFlow官方提供了Helm Chart，适合需要弹性伸缩和统一管理的团队。我在测试环境用的是Docker Compose单机部署，运作得也足够流畅。

5.2 嵌入模型与生成模型的选型

DeepDoc本身的解析能力是内置于RAGFlow的，不需要额外配置模型；但创建知识库、构建向量索引时需要指定一个“嵌入模型”。RAGFlow支持接入多种模型来源，包括OpenAI兼容接口、Ollama、Xinference等。

以Xinference为例，它是一款本地模型推理框架，你可以在本地部署嵌入模型，通过OpenAI兼容格式暴露API，然后RAGFlow直接调用这个API。对数据有隐私要求的场景，这条链路完全不需要外网交互。

我实测过几款嵌入模型，给个参考：

在DeepDoc把PDF解析并切块之后，每个chunk会被送到嵌入模型转成向量。如果你在解析阶段保留了表格结构，那么向量化的表格数据会携带表格语义，回答表格相关问题时召回效果会好很多。

5.3 创建知识库、上传PDF到完成解析的完整流程

下面是完整的操作路径。这里我按我最常用的一套流程写：

1. 启动RAGFlow服务后，在Web控制台注册/登录管理员账号。
2. 进入“知识库”页面，点击新建知识库，填写名称，选择嵌入模型。
3. 在“配置”中设置模板，一般文档选“一般”即可；如果是论文库推荐“Paper”。同时设置切块参数。
4. 进入该知识库，点击上传文件，把PDF文件拖拽进去。RAGFlow会触发DeepDoc解析。
5. 等待解析完成后，进入“解析结果预览”，核对文本顺序、表格还原情况。发现问题可以点击“重新解析”或调整切块参数。
6. 确认解析质量后，点击“构建索引”或“保存并解析”进入向量化阶段。
7. 索引构建完成后，切到“聊天”页面，关联这个知识库，即可开始问答测试。

这里有一个记忆点：首次创建知识库时，RAGFlow会要求设置/默认选定一个嵌入模型，这个模型是后续所有chunk向量化的统一账户，切换模型后原来的向量索引与新的嵌入模型不匹配，必须重建知识库或重新构建索引。

RAGFlow也提供了Python SDK，可以用ragflow_sdk在代码里创建知识库、上传文档、发起解析和检索。脚本化之后，可以把这套流程嵌入到自己的业务系统里，实现批量化的文档自动入库。

6. 实测踩坑记录：那些文档说得不够细的细节

任何工具光看官方文档都只能覆盖80%的使用场景，剩下20%的坑需要真实使用才能发现。这一节我按“问题现象→排查过程→解决方案”的方式，把我在DeepDoc解析PDF过程中遇到过的典型问题梳理一下。

6.1 扫描件质量差导致版面错乱

问题现象：有一批从老档案室扫描来的合同，分辨率低，纸张有底色发黄，个别页面还有倾斜。DeepDoc解析后，版面区域侦测出现偏差，表格被识别成了普通文本块，原来的一列变成了顺排文字。

排查过程：我先在“解析结果预览”里逐页确认版面检测结果，发现那些低分辨率页面的表格区域没有被正确框出。我一开始以为是模型能力问题，后来检查发现，原始扫描件分辨率只有72 dpi，文字笔画糊成一团，目标检测网络确实难以准确判断区域边界。

解决方案：上传前用图像工具把扫描件统一提升到300 dpi，并做自动纠偏。处理之后重新上传，DeepDoc的版面识别效果改善明显。这里也给大家一个提醒：不要指望解析器是万能的，前处理做得到位，后面才能省心。

6.2 大文件导致解析超时或内存吃紧

问题现象：一份200多页的PDF上传后，解析进度条长时间不动，最终提示解析超时；另一份PDF虽然解析成功，但在多个任务并行时服务器内存直接吃紧。

排查过程：查看日志后发现，DeepDoc在解析大文件时需要把页面渲染成图像再跑版面检测，渲染和检测两个步骤对CPU和内存的压力都颇为可观。RAGFlow默认对上传文件大小有限制，配置文件里可以调。

解决方案：我的做法是先在配置里适当调大上传上限；同时把大文件拆分成多个小文件分别上传，分批解析。还有一点经验：计划批量解析时尽量错峰，不要一次性提交几十个任务，因为CPU满载后每个任务的解析时间反而会被恶性拉长。

6.3 加密PDF与畸形PDF的解析失败处理

问题现象：上传某些PDF时，界面直接报“文档解析失败”。一开始我感到困惑，因为这些PDF我在本地上用浏览器打开时并无问题。

排查过程：后来我换了一种方式测试，逐个确认这些文件是否包含打开密码或编辑限制。有密码保护的PDF浏览器靠缓存可以直接打开，但DeepDoc抽取时拿不到内容层，自然解析失败。

解决方案：先对PDF做解密处理，去掉打开密码和权限限制，再上传。如果你的业务链路里经常接触加密PDF，可以提前在文档上传流程前加一道“自动检测加密并解密”的预处理。

6.4 表格解析结果与预期不符的兜底手段

问题现象：一份表格既含跨行合并单元格，又有一部分单元格内的文本换行，DeepDoc解析后表格的行列关系不正确。

排查过程：我通过“解析预览”里对比了原始表格和解析结果，发现问题是合并单元格区域被模型识别为零散文本块，行列对齐被打破。

解决方案：对于这类复杂表格，我在知识库里切换到“手动”模板，在解析预览里手动标记表格区域，或将表格截成图片后单独作为附件处理。如果对表格结构化要求不是极致的高，也可以接受DeepDoc输出的近似结构化结果，毕竟绝大多数问答场景只需要正确的单元格关键值能够被检索到。

6.5 切换嵌入模型时必须重建索引

问题现象：刚开始测试时我用了A模型，后来觉得语义效果不好换成了B模型。结果知识库问答时频繁出现“检索不到相关文档”的情况。

排查过程：我检查了文件解析状态和索引状态，发现都已成功，但检索就是没有结果。后来才意识到不同嵌入模型生成的向量空间不一致，之前的向量完全失效。

解决方案：在RAGFlow中切换知识库的嵌入模型后，需要对该知识库下的文档重新构建索引。这也提醒我，在团队协作中，知识库的嵌入模型尽量固定统一，中途切换的代价不小。

我在实际项目里还有个习惯：解析完成后先抽查5%的页面，确认文本顺序、页眉页脚去重和表格还原情况；确认没问题再构建索引。别小看这一步，它能帮你把80分的解析效果提到95分以上。DeepDoc本身在开源RAG领域里的解析能力已经属于第一梯队，但任何解析器都有它的能力边界，真正稳定上线靠的还是使用者的流程设计和兜底手段。