：RAG 知识库构建与文档解析工程)
本文收录于「流浪」的系列专栏Linux系统⚙️C数据结构与算法PythonLangChain LangGraph️MySQL 数据库Git 工具计算机网络LLM大厂面试、八股学习筑基专栏 博客主页流浪 原创首发于 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 为例PDFPortable 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 这些框架时它们往往内置了一些解析工具类可以直接使用。解析可用的工具非常多一个项目里往往要结合不同工具的优势共同完成解析任务。工具定位关键特点地址MinerU企业级多模态解析利器多模型集成高精度提取 PDF 正文、表格、公式支持 84 种语言 OCRGitHubDocling企业级文档处理引擎IBM Research Zurich 发起模块化设计表格解析精度高与企业 AI 框架集成友好GitHubMarker轻量级 PDF 转 Markdown 神器速度快专注把 PDF含扫描件转成 Markdown对公式和代码块支持良好GitHubUnstructured最通用的文档预处理库支持超 50 种文件格式PDF/Word/PPT 等智能分区是构建复杂 ETL 流程的基础GitHubPyMuPDF高性能 PDF 处理底层库极速的 PDF 渲染、文本与图像提取能力GitHubLlamaParse专为 RAG 设计的原生解析服务LlamaIndex 出品解析复杂 PDF表格/图表精度极高与 LlamaIndex 生态无缝集成官网Markitdown微软开源的万能文档转换器借助大模型能力支持把 Word/Excel/PPT/图像/音频等几乎所有格式转为 MarkdownGitHubPyMuPDFLoaderLangChain 内置的高性能 PDF 加载器基于 PyMuPDF速度快适合快速处理文本型 PDF文档SimpleDirectoryReaderLlamaIndex 的万能目录加载器最简单的入门方式自动检测目录下的多种文件格式并加载文档trafilaturaWeb 文本提取工具专门用于从 HTML 中提取纯文本和元数据去除导航、广告等噪声GitHubPaddleOCR工业落地最成熟的 OCR 与文档解析工具之一PP-OCRv5 是核心 OCR 引擎支持中英日韩等语言PP-StructureV3 是版面分析引擎能还原阅读顺序并输出 Markdown/JSONGitHubpdfminer.six纯 Python 实现的 PDF 解析库精确提取 PDF 中的文本、位置、字体等布局信息GitHubTesseract OCRGoogle 维护的开源 OCR 引擎高度可定制支持超过 100 种语言GitHubEasyOCR非常易用的 Python OCR 库支持超过 80 种语言GitHub6.2 选型看三件事1 文档类型扫描件/图片型必须走 OCR文本型用规则化解析更省事。2 复杂元素表格、公式、图表密集的文档要选对这些元素有专项模型的工具。3 生态要不要和 LangChain / LlamaIndex 打通决定了是直接调库还是走服务。没有全能的解析工具落地基本是组合使用先把文本型和扫描件分流再对复杂元素上专项模型最后统一收敛到 Markdown。七、文末面试题做 RAG 项目时数据切分和清洗具体是怎么做的答:三个核心环节——文本切分建议 500~1000 字符一块、并设 10%~20% 的重叠窗口防止表格标题和段落首句被切断PDF 解析必须做结构识别不能直接提取字符流否则双栏论文和带表格的文档解析出来顺序全乱可用 LayoutLM 类视觉模型先识别版面或用多模态大模型把页面转成结构化文本清洗后的数据坚持存成 Markdown保留标题层级和表格结构再交给切分和向量化。【真题·转述自 CSDN《字节一面问你做 RAG 项目中数据切分和清洗是怎么做的》、DAMO 开发者矩阵《RAG 数据清洗三大关键》】PDF、表格、图片混排的文档RAG 系统怎么解析答:分层处理——先说难点版面恢复、表格结构提取、OCR 噪声、跨页断裂再按类型分流数字原生 PDF 用 MinerU 之类处理复杂版面扫描件走 PaddleOCR 加后处理图表可选多模态模型但要权衡成本表格统一转成 Markdown 整体保存或拆成「表头 行」的结构化格式最后做后处理跨页拼接、过滤页眉页脚与目录页并按质量分层自动通过 / 人工复核 / 重新解析。主动说出工具短板是加分项比如复杂表格和公式识别仍不稳定、速度慢需要异步化。【真题·转述自 夜雨聆风·阿里大模型二面PDF、表格、图片混排文档你的 RAG 系统是怎么解析的】解析质量怎么量化用什么指标验收答:解析环节本身可以按页面级抽查——文字覆盖率解析出的正文占原文档正文的比例、表格识别完整度行列结构是否还原、跨页表是否拼回、以及与人工标注结果对比抽检。整条 RAG 链路上常用的评估是 RAGAS 这类框架检索侧看 PrecisionK、MRR生成侧看忠实度、相关性、无幻觉评分测试集一般要 100~200 条覆盖常见问法、边缘情况和复杂查询每条包含问题、期望答案和来源文档。【真题·转述自 夜雨聆风·阿里大模型二面PDF、表格、图片混排文档你的 RAG 系统是怎么解析的、CSDN《【AI 基础篇 10】RAG检索增强生成详解》】结语解析是 RAG 里最像「脏活」的一步——只有坐标和绘制指令的 PDF得被反推成有标题、有段落、有表格的结构。上游欠的债下游每一环都要还。你踩过最离谱的解析坑是什么评论区聊聊关注流浪持续更新。 
长河君 · 2026/10/10 6:13:13 · 阅读 1.2k 大模型技术全景(十九)：RAG 知识库构建与文档解析工程
本文收录于「流浪」的系列专栏Linux系统⚙️C数据结构与算法PythonLangChain LangGraph️MySQL 数据库Git 工具计算机网络LLM大厂面试、八股学习筑基专栏 博客主页流浪 原创首发于 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 为例PDFPortable 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 这些框架时它们往往内置了一些解析工具类可以直接使用。解析可用的工具非常多一个项目里往往要结合不同工具的优势共同完成解析任务。工具定位关键特点地址MinerU企业级多模态解析利器多模型集成高精度提取 PDF 正文、表格、公式支持 84 种语言 OCRGitHubDocling企业级文档处理引擎IBM Research Zurich 发起模块化设计表格解析精度高与企业 AI 框架集成友好GitHubMarker轻量级 PDF 转 Markdown 神器速度快专注把 PDF含扫描件转成 Markdown对公式和代码块支持良好GitHubUnstructured最通用的文档预处理库支持超 50 种文件格式PDF/Word/PPT 等智能分区是构建复杂 ETL 流程的基础GitHubPyMuPDF高性能 PDF 处理底层库极速的 PDF 渲染、文本与图像提取能力GitHubLlamaParse专为 RAG 设计的原生解析服务LlamaIndex 出品解析复杂 PDF表格/图表精度极高与 LlamaIndex 生态无缝集成官网Markitdown微软开源的万能文档转换器借助大模型能力支持把 Word/Excel/PPT/图像/音频等几乎所有格式转为 MarkdownGitHubPyMuPDFLoaderLangChain 内置的高性能 PDF 加载器基于 PyMuPDF速度快适合快速处理文本型 PDF文档SimpleDirectoryReaderLlamaIndex 的万能目录加载器最简单的入门方式自动检测目录下的多种文件格式并加载文档trafilaturaWeb 文本提取工具专门用于从 HTML 中提取纯文本和元数据去除导航、广告等噪声GitHubPaddleOCR工业落地最成熟的 OCR 与文档解析工具之一PP-OCRv5 是核心 OCR 引擎支持中英日韩等语言PP-StructureV3 是版面分析引擎能还原阅读顺序并输出 Markdown/JSONGitHubpdfminer.six纯 Python 实现的 PDF 解析库精确提取 PDF 中的文本、位置、字体等布局信息GitHubTesseract OCRGoogle 维护的开源 OCR 引擎高度可定制支持超过 100 种语言GitHubEasyOCR非常易用的 Python OCR 库支持超过 80 种语言GitHub6.2 选型看三件事1 文档类型扫描件/图片型必须走 OCR文本型用规则化解析更省事。2 复杂元素表格、公式、图表密集的文档要选对这些元素有专项模型的工具。3 生态要不要和 LangChain / LlamaIndex 打通决定了是直接调库还是走服务。没有全能的解析工具落地基本是组合使用先把文本型和扫描件分流再对复杂元素上专项模型最后统一收敛到 Markdown。七、文末面试题做 RAG 项目时数据切分和清洗具体是怎么做的答:三个核心环节——文本切分建议 500~1000 字符一块、并设 10%~20% 的重叠窗口防止表格标题和段落首句被切断PDF 解析必须做结构识别不能直接提取字符流否则双栏论文和带表格的文档解析出来顺序全乱可用 LayoutLM 类视觉模型先识别版面或用多模态大模型把页面转成结构化文本清洗后的数据坚持存成 Markdown保留标题层级和表格结构再交给切分和向量化。【真题·转述自 CSDN《字节一面问你做 RAG 项目中数据切分和清洗是怎么做的》、DAMO 开发者矩阵《RAG 数据清洗三大关键》】PDF、表格、图片混排的文档RAG 系统怎么解析答:分层处理——先说难点版面恢复、表格结构提取、OCR 噪声、跨页断裂再按类型分流数字原生 PDF 用 MinerU 之类处理复杂版面扫描件走 PaddleOCR 加后处理图表可选多模态模型但要权衡成本表格统一转成 Markdown 整体保存或拆成「表头 行」的结构化格式最后做后处理跨页拼接、过滤页眉页脚与目录页并按质量分层自动通过 / 人工复核 / 重新解析。主动说出工具短板是加分项比如复杂表格和公式识别仍不稳定、速度慢需要异步化。【真题·转述自 夜雨聆风·阿里大模型二面PDF、表格、图片混排文档你的 RAG 系统是怎么解析的】解析质量怎么量化用什么指标验收答:解析环节本身可以按页面级抽查——文字覆盖率解析出的正文占原文档正文的比例、表格识别完整度行列结构是否还原、跨页表是否拼回、以及与人工标注结果对比抽检。整条 RAG 链路上常用的评估是 RAGAS 这类框架检索侧看 PrecisionK、MRR生成侧看忠实度、相关性、无幻觉评分测试集一般要 100~200 条覆盖常见问法、边缘情况和复杂查询每条包含问题、期望答案和来源文档。【真题·转述自 夜雨聆风·阿里大模型二面PDF、表格、图片混排文档你的 RAG 系统是怎么解析的、CSDN《【AI 基础篇 10】RAG检索增强生成详解》】结语解析是 RAG 里最像「脏活」的一步——只有坐标和绘制指令的 PDF得被反推成有标题、有段落、有表格的结构。上游欠的债下游每一环都要还。你踩过最离谱的解析坑是什么评论区聊聊关注流浪持续更新。