企业官网建设流程全解析

📚 本文收录于「流浪」的系列专栏

🏠 博客主页：流浪 ｜ 📝 原创首发于 CSDN

篇十八把 RAG 的七个环节过了一遍：加载、分块、嵌入、入库、检索、增强、生成。本篇开始逐个拆开，第一个环节是数据加载——把企业里那些 PDF、Word、扫描件变成机器能处理的结构化文本。它是整条链路里最不显眼、也最容易背锅的一步：做好了没人提，做差了后面每一环都在替它擦屁股。

一、知识库构建阶段的定位

1.1 两个阶段的分工

完整的 RAG 应用流程主要包含两个阶段：

• 知识库构建：主要是构建知识的向量化索引，通常是离线完成的。
• 应用阶段：根据用户的输入，RAG 系统进行在线推理，一般是一个在线服务。

1.2 本篇的位置：第一步

构建阶段做的第一件事，是把原始数据处理为结构化格式，为后续切分做准备。这一步的数据从哪来、干净到什么程度，直接决定了后面分块能不能切得准、检索能不能召得回。

构建阶段是离线的一次性投入，但它决定了后面每一步的天花板。文档没解析干净，后面检索和生成再怎么调参也补不回来——这是 RAG 工程里最典型的「上游欠债下游还」。

二、数据加载不只是「读文件」

数据加载远远不止读取文件，一般包含以下三件处理。

2.1 数据解析

一般需要支持多模态、多格式数据的读取处理：

1 非结构化数据

PDF、Word（.docx）、Markdown、TXT、HTML。

2 结构化数据

Excel、CSV、SQL 数据库导出。

3 多媒体数据

图片（通过 OCR 提取文字）、甚至音频转录稿。

2.2 数据清洗

原始文档往往包含很多噪音，也就是不需要考虑的信息。处理包括：

1 去除冗余

删掉 HTML 标签、广告弹窗文字、页眉页脚。

2 格式统一

将所有格式统一转为纯文本或 Markdown。

3 异常处理

处理乱码、修正 OCR 识别错误。

2.3 元数据获取

提取数据中的关键信息，例如文件名、页码、标题、URL、时间等。

加载这一步干的是「把噪声挡在库外」，不是「把文件读进来」。清洗时漏掉的页眉页脚，后面会以检索噪声的形式原样还给你——它们不会消失，只会换个环节出来捣乱。

三、文档的两类形态：有标记与无标记

大模型看数据和人看数据不一样，从解析的角度通常分为两类。

3.1 有标记的文档

有标记的文档是指在原始文本内容基础上，添加了用于分类、标注实体或描述结构的特定标签或注解的文档，如 Word、Markdown、HTML、JSON 等。这些文档具有明确的结构，计算机可以直接解析和理解。

同一篇文章，人看到的是排版后的阅读效果，计算机看到的是源码里清晰的一级标题、二级标题和代码块标记——结构信息是写死在文本里的，不需要还原。

3.2 无标记的文档

无标记的文档是指不包含任何人为添加的分类标签、实体标注或结构标记的纯原始文本内容，如图像、PDF 等。这些文档缺乏结构信息，计算机无法直接理解其内容。

以 PDF 为例：PDF（Portable Document Format，便携式文档格式）文件由一系列绘图指令（如「在坐标 (X,Y) 处放置字符 Z」）构成，而不是用语义化标签（如 HTML 的段落标签、表格标签）去定义标题、段落、表格等逻辑结构。

PDF 描述的是「怎么画出来」，而 RAG 需要的是「逻辑结构」。这个错位是后面所有解析难题的共同源头。

四、无标记文档解析的三大挑战

4.1 结构缺失

看一段带注释的 PDF 源码（关键指令已截取，%后为注释）：

/BaseFont /Helvetica-Bold % 加粗靠指定字体变体实现 BT /F1 24 Tf % 使用 F1 号字体，字号 24 50 700 Td % 文本起始坐标 (x, y) (Hello PDF) Tj % 绘制字符串 ET

源码里能看到的是字体对象、坐标、绘制指令，看不到标题与正文的层级关系。我们看到的效果是一句加粗的标题加一句正文，但从源码完全推不出哪句是标题。

4.2 排版复杂

1 分栏

多栏布局下，按字符流顺序抽取会把左右两栏的文字搅在一起。

2 复杂公式

数学公式不是普通字符流，需要专门识别并转成 LaTeX 之类的结构化表示。

3 复杂图像含义

图本身的含义需要视觉理解，不是抽文字能解决的。

4 复杂表格

跨页表格、合并单元格尤其容易解析错乱。

4.3 元素遮挡

印章、手写批注、水印等覆盖在文本上，干扰内容识别。这类干扰在人眼里很容易忽略，但在字符流里就是实打实的噪声。

三大挑战本质是同一件事：PDF 只有视觉布局、没有语义结构，解析做的正是把视觉布局反推回语义结构。

五、无标记文档的处理思路

5.1 文档预处理

1 类型识别与分类

以 PDF 为例，如果是文本型 PDF，使用普通规则化解析工具；如果是扫描件或图片型 PDF，则需引入 OCR 技术。

2 版面分析与布局理解

使用深度学习模型，比如目标检测，自动识别文档中的标题、段落、表格、图片等区域，理清布局。

3 重建顺序

识别出元素之后，需要重建其正确的逻辑阅读顺序。

4 OCR 文本识别

使用 OCR 引擎将图像转换为机器可读文本。

5.2 复杂元素专项处理

对复杂表格、图表、公式做专项处理：可以使用专门的模型识别和处理表格、图表和公式，覆盖合并单元格、跨页表格等复杂情况。

5.3 结构化输出与元数据增强

解析结果要统一输出为结构化格式，如 Markdown 或 JSON。作为模型输入，Markdown 的优势明显：

1 文档结构清晰

支持多层标题、粗体、斜体、列表、表格、数学公式等，能够完整地表达文档的信息。

2 格式负担小、更关注内容

Markdown 关注内容本身而非排版，符合大模型的训练特点，且大模型对 Markdown 这类结构化文本有较好的理解能力。

3 工程上生态成熟

主流解析工具（MinerU、Docling、Marker、Markitdown 等）都把 Markdown 作为默认输出之一。

此外还要补充文件名、标题、作者、章节、页码等信息，为后面的过滤和溯源留好字段。

处理链路是「识别类型 → 还原版面 → 重建顺序 → 输出结构化」，输出形态优先 Markdown——它同时满足机器可解析和模型好理解这两个要求。

六、常见解析工具

6.1 工具全景

使用 LangChain 或者 LlamaIndex 这些框架时，它们往往内置了一些解析工具类可以直接使用。解析可用的工具非常多，一个项目里往往要结合不同工具的优势共同完成解析任务。

6.2 选型看三件事

1 文档类型

扫描件/图片型必须走 OCR，文本型用规则化解析更省事。

2 复杂元素

表格、公式、图表密集的文档，要选对这些元素有专项模型的工具。

3 生态

要不要和 LangChain / LlamaIndex 打通，决定了是直接调库还是走服务。

没有全能的解析工具，落地基本是组合使用：先把文本型和扫描件分流，再对复杂元素上专项模型，最后统一收敛到 Markdown。

七、文末面试题

1. 做 RAG 项目时，数据切分和清洗具体是怎么做的？
   答:三个核心环节——文本切分建议 500~1000 字符一块、并设 10%~20% 的重叠窗口防止表格标题和段落首句被切断；PDF 解析必须做结构识别，不能直接提取字符流，否则双栏论文和带表格的文档解析出来顺序全乱，可用 LayoutLM 类视觉模型先识别版面，或用多模态大模型把页面转成结构化文本；清洗后的数据坚持存成 Markdown，保留标题层级和表格结构，再交给切分和向量化。
   【真题·转述自 CSDN《字节一面问：你做 RAG 项目中，数据切分和清洗是怎么做的？》、DAMO 开发者矩阵《RAG 数据清洗三大关键》】

2. PDF、表格、图片混排的文档，RAG 系统怎么解析？
   答:分层处理——先说难点：版面恢复、表格结构提取、OCR 噪声、跨页断裂；再按类型分流：数字原生 PDF 用 MinerU 之类处理复杂版面，扫描件走 PaddleOCR 加后处理，图表可选多模态模型但要权衡成本；表格统一转成 Markdown 整体保存，或拆成「表头 + 行」的结构化格式；最后做后处理：跨页拼接、过滤页眉页脚与目录页，并按质量分层（自动通过 / 人工复核 / 重新解析）。主动说出工具短板是加分项，比如复杂表格和公式识别仍不稳定、速度慢需要异步化。
   【真题·转述自 夜雨聆风·阿里大模型二面：PDF、表格、图片混排文档，你的 RAG 系统是怎么解析的？】

3. 解析质量怎么量化？用什么指标验收？
   答:解析环节本身可以按页面级抽查——文字覆盖率（解析出的正文占原文档正文的比例）、表格识别完整度（行列结构是否还原、跨页表是否拼回）、以及与人工标注结果对比抽检。整条 RAG 链路上常用的评估是 RAGAS 这类框架：检索侧看 Precision@K、MRR，生成侧看忠实度、相关性、无幻觉评分，测试集一般要 100~200 条，覆盖常见问法、边缘情况和复杂查询，每条包含问题、期望答案和来源文档。
   【真题·转述自 夜雨聆风·阿里大模型二面：PDF、表格、图片混排文档，你的 RAG 系统是怎么解析的？、CSDN《【AI 基础篇 10】RAG：检索增强生成详解》】

💬结语：解析是 RAG 里最像「脏活」的一步——只有坐标和绘制指令的 PDF，得被反推成有标题、有段落、有表格的结构。上游欠的债，下游每一环都要还。你踩过最离谱的解析坑是什么？评论区聊聊，关注流浪，持续更新。