企业官网建设流程全解析

做RAG知识库，很多人一上来就忙着选向量模型、调Embedding参数、折腾向量数据库，折腾半天召回来的内容乱七八糟。后来才发现，问题根本不出在检索环节，而是从文档进入系统的那一刻就已经埋下了隐患。文档处理，这个看起来最不起眼的环节，恰恰决定了整个知识库的上限。你喂给它的如果是垃圾，它给你的一定是更精致的垃圾。

这篇我主要聊聊文档处理那些容易被忽视、但极其影响RAG效果的实操细节。不聊那种一键脚本就能搞定所有场景的幻想，有些文档确实可以无脑切，但多数专业文档、扫描件、表格、异构排版，都是需要区别对待的。这里说的每一件，都是我实际处理过很多轮、踩过不少坑之后沉淀下来的经验。

1. 文档处理为什么不能“一视同仁”

RAG知识库的核心链路并不复杂：文档进来，解析成纯文本，切成合适大小的块，向量化后存入数据库，用户提问时检索相关块，交给大模型生成回答。如果最后回答不准，大家习惯性去调提示词、换模型、调相似度阈值，但其实根源大概率在解析和切分环节——信息已经丢了，后面再怎么调检索都很难找回来。

1.1 文档类型远比你想的复杂

我们面对的真实文档，远不止Word和PDF这么简单。拿一个中等规模的企业知识库来说，常见文档至少包括：

• 制度类文档：PDF、Word混合，有各级标题、条款编号、页眉页脚、签批单。
• 技术文档：Markdown、HTML、PDF，代码块、命令行、日志示例特别多。
• 公告通知类：可能是图片型PDF，也就是扫描件，也可能是一张长截图。
• 合同协议：表格、盖章扫描、手写批注混杂，有些还是双栏排版。
• 表格密集型：Excel导出的PDF、财务对账单、配置清单，关键信息都躺在单元格里。
• 演示文稿：PPT转出来的PDF，大量文字其实是文本框，还有批注和备注。

如果把所有这些都丢进同一个解析器，比如只用pdf库提取文本或只用Markdown解析，那得到的文本质量会惨不忍睹，这不是算法不够先进的问题。

1.2 解析结果直接影响后续所有环节

文档处理链路一旦出错，问题会一路传导。比如扫描件用普通方式解析，得到的是一堆乱码或空字符串，向量化之后完全没法匹配。又比如表格被解析成纯文本流，行和列的关系被打散，LLM回答“哪个零件对应哪个供应商”时，看到的是一串没有任何结构的字符，根本无从对应。

还有一个容易被忽视的细节：切分。切分不是简单按固定字数截断。同一段文字，句子中间被硬切，语义就会断开；表格中间被切，行数据被拆到两个块里，检索时只能召回其中一半；代码块被拦腰截断，整个示例变得不可用。这些问题是解析层和切分层的策略选错导致的，和你选的Embedding模型没什么关系。

所以在RAG项目里，文档处理并不只是“预处理”，它其实决定了整个系统的召回上限。后面所有环节的打磨，只能在这个上限之下做文章。

2. 第一步是分类：给文档分型，而不是一刀切

与其试图用一套万能方案解析所有文档，我建议先做文档分型，把进来的文件根据形态特征归到合适的处理通道里。这个分类动作看起来多了一步，实际是在节省后续排查问题的时间。

2.1 快速分类的五个维度

实际操作中，我用五个特征来快速判断一份文档该怎么处理：

1. 文本层是否存在：用工具直接检测，是否有可复制的文字层。如果没有，基本可以判定为扫描件或图片型文档。
2. 版面结构复杂度：看是否有多栏、复杂表格、公式、代码块、页眉页脚等。
3. 表格密度：整页是表格，还是只有零星几个表格，决定要不要走专门的表格解析通道。
4. 语言与字符类型：中英文混排、全角半角混用、专有名词大小写，都会影响清洗策略。
5. 是否包含提取物：盖章图片、签名、手写批注、二维码等，这类元素是否需要保留或处理。

这五个维度不需要人工逐个打开文件看，可以写一个预检脚本，读取文件元数据、扫描前几页内容、检测文本层和图像占比，自动判一下类型。预检脚本跑完，分类结果直接决定后续走的处理路径。

2.2 分型之后对应不同的处理通道

我一般分成几条通道：

这五类不是严格的学术划分，而是实践中很好用的经验分型。原本一个解析函数打天下的方案，拆成这五条通道后，每类文档的处理质量都能明显提升。

2.3 分类之后，清洗规则也要跟着变

文档分型不只是选解析工具，清洗策略同样要跟着变。比如A类文本型PDF，页眉页脚要剔除，但页脚的“第X页/共X页”和正文里的页码引用要区分开。B类扫描件，OCR的置信度低于某个阈值的字符要标记出来，不能直接进库，否则会有一堆错别字干扰检索。C类表格，清洗时更要注意保留行列结构，不能简单拼成一行。

清洗规则跟着文档类型走，而不是一套规则用到黑，这个思路是整个文档处理环节最核心的原则。

3. 解析通道的选型与实操细节

分类完成后最关键的实操部分，就是针对不同通道选择合适的解析方案，并把它们跑通。

3.1 文本型PDF：优先保结构，而不是保速度

对于A类文本型PDF，核心目标是保留文档的结构信息。标题层级、段落边界、列表、加粗内容、表头，这些信息对后续切分和检索非常关键。

我习惯用具备版面分析能力的工具，比如PyMuPDF和pdfplumber配合使用。PyMuPDF提取文本块坐标后，可以根据字体大小判断标题层级；pdfplumber对表格的定位更准，适合抽取带位置的文本块。

具体步骤大致是：

1. 用PyMuPDF按页读取，获取每个文本块的坐标、字号、字体信息。
2. 根据字号和加粗特征，判断是否属于标题，并推断标题层级。
3. 剔除页眉页脚区域，可以按坐标范围过滤，也可以按文本特征过滤。
4. 将文本块按坐标y轴排序，合并成段落。
5. 输出成带Markdown标记的纯文本，比如标题前加#号。

这套流程最关键的是第2步，标题层级判断。判断对了，后续切分就能按标题边界来切，切出来的块天然是语义完整的小节。判断错了，等于把结构信息丢了，后面的切分又回到盲切的老路上。

3.2 扫描件与图片型PDF：OCR不是万能药

B类扫描件，网络上有大量文字吹捧“OCR准确率99%”，实际做过的人都知道，干净印刷体确实可以，但盖章、水印、倾斜、复杂背景下，准确率下降很快。

我的建议是：优先选中文场景下训练充分的开源模型，如PaddleOCR，配合版面还原。如果预算充足，对一些重要合同、图纸类文档可以调用商业OCR服务，做一个双通道校验。

实操几个要点：

• 先做图像预处理：灰度化、二值化、倾斜矫正、去噪。很多人跳过这步直接OCR，结果上来了不少奇怪的字符。
• OCR之后，不要急着删掉坐标信息。每个文本块的位置坐标对后续表格重建、版面还原都很有用。
• 设置置信度过滤。置信度低的字符，不要硬留，宁可丢一点，也不要带乱码进知识库。
• 识别完的稿子，建议抽抽样，人工快速过一遍。抽样比例可以控制在2%~5%，发现批量性错字就要回头调预处理参数。

3.3 表格类文档：保留“关系”，而不是保留“文字”

表格类文档最容易翻车。如果只是把表格转成文本字符串，那行、列、单元格之间的对应关系会全部丢失。比如一个库存表，“物料编号”“库存量”“责任人”三个字段本来一一对应，转成文本流后，检索到“责任人”三个字，却不知道它对应的是哪一行的哪一个值。

比较可行的方法是把表格转成Markdown表格或JSON结构，这样每一个单元格和它所在的行、列关系依然保留。LLM对Markdown表格的理解能力还可以，喂给它这种格式，回答问题时能够正确引用行列关系。

如果表格是图片形式，比如扫描的Excel截图，则需要借助表格结构识别工具，这类工具能识别表格线、单元格边界，把图片转成结构化的表格数据。没有这类工具的话，也可以用OCR先把文字提出来，再按坐标聚类，手动拼出表格结构，但这非常费人工，适合小批量场景，不适合规模化处理。

3.4 网页和笔记类：结构清洗的价值大于解析

网页转存、Notion导出、技术博客抓取，这类内容最大的问题不是提取不到文字，而是噪声太多。导航栏、广告、相关推荐、评论、Cookie弹窗，全部会混进正文。

用BeautifulSoup或Readability算法提取正文是最常见的选择。但更推荐的处理思路是：先尽量保留内容自带的语义结构，比如标题层级、代码块、列表、引用，因为这些结构本身就是天然的分块边界。很多网页抓取工具只返回纯文本，把代码块的高亮信息、列表的嵌套关系全部抹掉了，这比较可惜。

有一种做法是使用Jina Reader这类服务，把网页转成干净的Markdown，效果往往比自写解析器更好，尤其对排版复杂的页面。不过这类服务有调用量限制，建议搭配缓存。

4. 分块策略：这是文档处理中最需要动脑筋的环节

解析得到干净的文本之后，下一步是分块（Chunking）。这是我花了最多时间调优的地方，也是很多人最忽略的地方。

4.1 固定长度切分为什么不好用

网络上很多示例代码喜欢按固定长度切块，比如每500个字符切一块，相邻块之间重叠100个字符。这种思路简单，但实际用起来效果一般，因为硬切的块经常横跨两个语义段落，导致检索结果不准确。

一个块应该是语义完整的单元。判断标准很简单：你把一个块单独拿出来，读完之后，是否知道它在讲什么？如果一个块是“这个方案的核心思路是左半段讲技术选型，右半段开始讲费用”，那这个块就是无效的。

更合理的分块依据是：

• 文档自带的结构边界，比如Markdown标题层级、PDF中的章节标题、HTML的标题标签。
• 段落边界，一个段落内部不要拆分，尽量不要跨标题切。
• 如果段落太长，比如超过某个阈值，再在段落内部按句子边界二次切分。

我常用的分块流程是先按标题层级把文档拆成一棵目录树，然后对叶子节点做长度检查。如果叶子节点长度在合理范围内，直接用；如果过长，再在叶子节点内部按句子切分，并尽量让块之间有少量重叠，以保证上下文衔接。

4.2 不同内容类型的切分阈值

不同内容类型，分块的大小和策略也完全不同：

切分的核心原则就一句话：优先保语义完整性，其次才是控制块大小。向量模型通常对超过一定长度的文本处理效果会变差，这个长度因模型而异，我自己一般控制在300~800字之间，具体阈值需要通过实验来定。

4.3 分块时保留上下文信息

分块时还容易踩一个坑：切出来的块脱离上下文，检索时不知道这块来自哪个文档、哪个章节。比如单纯切出来“预算审批不得超过三天”这样的句子，回头检索到了，模型并不知道这是哪个制度的哪一条。

解决办法是给每个块附加父子元数据。块本身存向量，但元数据里带上父文档的标题、所在章节路径、页码等。检索时既可以根据块内容匹配，也可以利用这些元数据做过滤或追溯。

这一步很不起眼，但在实际使用中价值巨大。尤其是企业知识库中同类型文档很多，来自不同部门、不同时间、不同地区的相似条款容易混淆，有了元数据，回答时能准确说清楚“依据是某某单位某某制度第几条”，可信度高一大截。

5. 踩坑实录：文档处理常见问题和排查技巧

这部分整理一些我实际踩过、别人也经常来问的坑，每一件都对应一个具体场景，你可以直接对照排查。

5.1 扫描件OCR之后全是乱码，怎么排查

很多人遇到OCR结果全是乱码，第一反应是换OCR引擎。其实大部分情况是图片预处理没做好。常见的原因包括：

• 原图分辨率太低，OCR对低分辨率图几乎无解。建议先检查原图DPI，低于200dpi的直接先做超分或提醒重新扫描。
• 图片有底色或水印，导致二值化后字符断裂或粘连。这时候要先做背景去噪，再做二值化。
• 倾斜角度过大，OCR识别率断崖式下降。先用投影法或边缘检测做倾斜矫正，再进OCR。

排查顺序建议：先查原图质量，再查预处理流程，最后再看OCR模型参数。不要一上来就盲目调参，容易白费时间。

5.2 表格解析后行列错位

表格解析出现行列错位，常见于合并单元格、跨行表头、同一格里换行等情况。遇到这种问题，建议在解析后加一个验证步骤：从表格中随机抽取几个单元格，对比原文和解析结果，确认对应关系正确。

如果用的是坐标聚类方法拼表格，行列错位通常是因为文本块坐标聚类的阈值设得不对，行与行没分开或者列与列被合到一起。此时需要调整坐标容差，尤其是合并单元格场景，不能只按坐标一刀切，要结合单元格坐标范围做二次判断。

说实话，表格解析没有一劳永逸的方案。我现在的做法是：能转成结构化数据的尽量转，转不了的，保留“原样截图为图片+OCR文字摘要”两条路并行，检索时优先返回图片和结构化数据，文字摘要作辅助。

5.3 同一文档在不同解析器下结果差异极大

同一个PDF，用不同的库解析，结果经常完全不同。有的库能保留表格结构，有的库只能输出流式文本。这其实是正常的，因为这些库背后的算法逻辑不一样，有的基于规则，有的基于版面分析模型。

所以不建议在一个项目里混用多个解析器去解析同一份文档，应该选定一套主解析链路，并把其他解析方案作为补充验证或备份。混用多个解析器不仅会带来结果不一致的问题，还会让后续的问题排查变得复杂，因为你很难确定当前这一版结果来自哪个环节。

5.4 切分后信息重复率高

固定长度重叠切分时，如果重叠区域太大，检索时容易召回好几块内容高度相似的块，导致最终回答冗余。可以这样优化：重叠区控制在块长度的10%~20%，或者干脆不重叠，靠父子元数据实现上下文衔接，这样信息重复率更低。

如果发现检索结果总是好几块讲同一件事，还有一个思路是查重：在建库时对文本块做模糊去重。常见算法有MinHash、SimHash，也可以直接用向量相似度去重。这个操作能显著降低索引体积，提升检索质量。

5.5 混合文档（既有扫描页又有文本页）

不少合同文档是这样的：前面几页是Word打印的文本层PDF，中间夹了一份盖章扫描页，后面又接入附件。这种情况如果整份文档走同一个通道，要么扫描页被当作文本PDF处理导致空白，要么整个文档被当成扫描件走OCR，浪费时间和算力。

建议在预检阶段就逐页检测文本层，把每一页标记为text_page或image_page，然后按页分流处理。文本页走文本解析，扫描页走OCR，最后在输出层按页顺序合并。这个处理方式在混合合同、标书、鉴定报告中非常常见，值得提前留意。

6. 索引质量与召回验证：验证文档处理做得对不对

文档处理做得是否正确，最直接的验证方式就是看召回效果。不是在线测试那种肉眼感觉，而是用一套标准问题集做离线评测。

6.1 建立评测问题集

我习惯在每个知识库上线初期建立一个评测问题集，大概50~100个问题，覆盖业务中的高频提问、复杂查询和边角案例。每个问题标注出应召回的文档标题、段落或关键词。

评测问题集要边用边补充，尤其当业务方反馈“明明有这个内容但AI说没有”的时候，这类问题最有价值，说明你的处理链路在某类文档上存在盲区，值得针对性去补。

6.2 召回测试判断处理链路问题

召回测试我常用三个指标判断是哪一环出了问题：

• 完全没召回：极可能是解析环节丢了文本，而不是检索参数问题。去查原始文档是否成功解析、文本是否干净。
• 召回了但位置不对：很可能是切分逻辑问题，目标内容被切进了一个语义混杂的块，导致向量与该问题不匹配。
• 召回了但信息不完整：可能切分时把相关信息切到了相邻块，而这两块之间没有建立足够的关联。

这三类情况，分别对应文档处理链路中的解析、切分、元数据问题。针对性地修，比盲调Embedding模型更有效。

6.3 常见文档处理质量检查项

做完一批文档处理之后，可以批量抽检几个点：

• 文本层抽取率：有文本层的文档，抽查是否有丢字、漏段。
• OCR抽样准确率：扫描件抽几页，把OCR结果与原图比，看是否有批量错字。
• 表格结构完整度：抽查表格行列数量与原文是否一致。
• 标题层级体系：解析后的文档，标题层级是否和原文档一致，还是全部变成了一级标题。
• 切分后的块内容：随机抽查几个块，看是否有半句、孤立代码、悬挂表头等情况。

这五个项检查完，基本能判断一条处理链路是否成熟。

7. 一些工具选型和工程化的建议

最后聊一下工具选型和工程化落地的经验，这部分不会展开太多，但每个点都是我实际对比过后的结论。

7.1 开源优先，商用作兜底

在文档处理工具的选择上，建议开源优先。开源方案的好处是可以本地化部署、方便调试、没有按量付费的压力。但是开源方案的坏处也很明显：配置复杂、对复杂版面支持不稳定。所以在关键业务场景，比如核心合同、图纸、行业特有的复杂表格，商用OCR或文档解析服务作为兜底是值得的。

我当时给某企业知识库做文档处理时，策略就是“开源主链+商用补充”：常规文本型PDF和网页笔记走开源链路，扫描件和复杂表格入库前用商用接口过一次。成本适中，整体效果也能接受。

7.2 流程编排：串行还是并行

文档处理流程涉及多个阶段：格式识别、语言检测、文本提取、OCR、清洗、切分、元数据标注、向量化、入库。实际工程上不建议做一个超级函数一气呵成，而是拆成几个独立服务或函数，每个环节可配置、可重入、可观测。

我的做法是：

1. 统一入口把文件传到对象存储或本地目录，生成任务ID。
2. 预检服务返回文档类型和推荐通道。
3. 按分类进入不同的解析通道。
4. 所有解析结果统一成标准格式（Markdown或JSON）。
5. 切分和元数据标注在标准格式基础上进行。
6. 最后向量化并入库。

每个步骤独立记录日志，出了问题直接看日志定位断点，不需要从头重新开始。这条工程化思路让我在后续维护知识库时省了大量时间。

7.3 需要保留原始文件

虽然目标是提取文本，但原始文件一定不能丢。原因很简单：后续如果发现某一段文本解析错误，需要回到原始文件重新处理；如果某个问题用户需要追溯原文，也需要保留原始文档供展示。

所以不管处理链路多长，都不要对原始文件原地修改。解析输出的是一个又一个版本，原始文件永远保留在存储层。这条习惯帮我避免了不止一次重新扫描的麻烦。

8. 最后分享一点心得

做RAG知识库以来，最大的体会是：很多人把精力放在调模型、调提示词上，却忽略了文档处理才是整个系统的地基。地基不牢，上面的检索、生成再花哨也没用。

文档处理不是跑一个脚本、统一解析、统一切分就完事的，它需要你理解文档的多样性，理解文档里哪些信息重要、哪些是噪声，理解解析和切分之间的微妙配合。这些经验不是看几篇文档就能获得的，需要结合自己的业务场景反复试错、反复验证效果。

你现在如果正在做知识库，建议花点时间梳理一下现有文档的类型分布，看看当前处理链路是不是“一刀切”。如果是，先把文档分类和分类型处理这件事做好，回头你会发现检索质量提升的幅度，比换一个更强的Embedding模型更明显。这条经验，是我实际走完项目之后最想告诉你的一点。