企业官网建设流程全解析

做知识库、做 RAG，很多人第一步就是踩坑：把 PDF 直接丢给模型。结果模型对着满屏乱码和错位表格，答非所问。

问题不在模型，在输入。

一、为什么 PDF 对模型很不友好

PDF 的设计目标是“打印出来长得对”，不是“被程序读懂”。它记录的是每个字符画在页面上的坐标，而不是标题、段落、表格这些逻辑结构。所以直接抽取，经常会得到：

• 双栏论文被读成左右串行；
• 页眉页脚、页码混进正文；
• 表格塌成一堆没有对齐关系的数字；
• 图片、公式、脚注直接丢失。

二、解析的目标：还原结构

好的解析不是“把字抠出来”，而是把结构还原出来：

• 识别标题层级，还原章节树；
• 识别表格，输出可对齐的结构（Markdown 表格或 JSON）；
• 识别列表、代码块、公式、图注；
• 剔除页眉页脚等噪声。

输出成Markdown是很实用的中间格式：既保留结构，又贴近模型熟悉的文本形态。

三、难点在哪

• 扫描件：本质是图片，需要 OCR，质量受清晰度、倾斜、印章遮挡影响。
• 复杂表格：合并单元格、跨页表格、无边框表格，都是老大难。
• 多栏与图文混排：顺序判断错误会让上下文彻底错乱。
• 公式与专业符号：需要专门的识别能力。

四、为什么这一步值得较真

有一条朴素的规律：输入错的结构，后面的检索和生成只会放大错误。切分策略、向量质量、回答忠实度，全部建立在解析结果之上。解析阶段切错了，后面再优化也只是在错误的地基上装修。

所以做 RAG 时，花在解析和清洗上的时间通常不会白费。

五、现成能力

文档解析已经有成熟的服务形态。例如长亭百智云的文档解析支持 PDF、DOC、PNG、Excel 等格式转成 Markdown，配套还有面向网页正文与关键信息提取的网页解析；对不想自己处理 OCR 与版面分析的团队，直接接入能省掉大量工程。

自建的好处是可控、可针对自己的文档类型调优；用现成服务的代价是受其支持的格式与精度约束。文档类型单一时自建不亏，类型一杂，接入往往更划算。

小结

把“文档解析”当成一个可以随手跨过的步骤，是 RAG 项目最常见的误判。它决定了后面所有环节的上限：结构还原得越准，后面的检索和回答才可能越准。