企业官网建设流程全解析

做过企业RAG落地的人应该都有同感：PDF解析是第一个绕不过去的坎。不是模型能力不够，而是喂进去的原材料本身就脏——表格被拆碎、页眉页脚混进正文、双栏论文读起来像倒带、扫描件直接吐出一堆乱码。我经手过的知识库项目里，至少一半时间花在“把PDF变成能用的文本”上，而不是花在调模型上。Yellow.ai最近对外提到的D-RAC方案，核心主张一句话就能讲清：企业PDF别直接喂RAG，先转换成结构完整的Markdown，再做检索增强。这个思路不算新，但把它产品化、把细节补齐，值得每个做RAG的团队参考。下面我会把这条链路的原理、工具选型、分块配置和踩坑经验都展开写一写，文末也会聊一些我自己的实操体会。

1. 为什么PDF不能“直接喂”给RAG

1.1 PDF是“画布”，不是“书稿”

PDF的本质是一套页面描述指令。每个字符都有坐标，页面就是一块画布，文字、线条、图片按位置堆叠。它不关心“这段是标题还是正文”，也不关心“这一行属于哪一列的表格”。PDF在产出端的唯一目标是“打印出来和排版一致”，而不是“让机器读懂结构”。这就和RAG的需求形成了先天错位。

RAG要的是语义单元：一个标题下的一段话、一张表里的一行、一段可以整体引用的代码。可PDF给到解析器的是一个平面坐标系统，解析器必须自己推测哪些字符组成一个段落，哪些段落属于同一语义块。生活里打个比方：PDF像给一栋房子拍了照片，Markdown像画了户型图。照片保留了全部细节，但机器看照片时很难自动圈出“哪里是客厅、哪里是承重墙”；户型图则把结构画得明明白白，后续做空间规划才顺手。

1.2 直接解析PDF的翻车现场

很多团队一开始图省事，直接拿pypdf、PyMuPDF这类基础库提取文本，结果在真实的业务文档上翻车翻得很难看。下面这几个场景，我在企业项目里几乎都遇到过：

这些现象在企业文档里几乎是必然出现，而不是小概率事件。一旦出现，后面RAG环节做得再细也白搭——你检索到的上下文本身就是错的，大模型再聪明也只能基于错的信息生成。所以“把PDF转成Markdown再喂RAG”不是锦上添花，而是基本保底层。理解了这一层，再去看D-RAC这类方案，才能明白它到底解决了什么问题。

2. Markdown凭什么成为RAG的“中间格式”

2.1 结构信息就是检索的路标

Markdown好在哪里？好在它给RAG提供了“路标”。标题层级（# / ## / ###）告诉切分器哪里是一个语义域的边界；表格语法把行列关系固定下来，检索行级别的信息时不用靠猜；代码块用三个反引号包裹，切分器不会把一段代码拦腰截断。这些结构信息在人类阅读时是自然而然的，但对机器来说，是“有没有结构感知”的分水岭。

用一个例子说明：同样一本产品手册，纯文本提取后是一个几万字的连续字符串，分块算法只能按固定长度硬切，经常是一句话前半段在chunk A、后半段在chunk B。转成Markdown之后，每个二级标题以下的内容自然聚合成块，切分器可以在标题边界处停下，形成语义完整的切片。这就是为什么先转Markdown能让RAG命中率明显提升——你给检索器的不再是一堆“断壁残垣”，而是一间间结构清晰的小房间。

2.2 噪声清除与token成本下降

除了结构，Markdown还带来两个实际收益。第一是清除噪声。页眉页脚、页码、水印、重复的版权声明，这些在结构化转换阶段可以被识别并丢弃。数据干净了，向量索引里没有那么多重复片段干扰召回，大模型拿到上下文也更聚焦，回答幻觉自然减少。第二是token成本下降。同一份内容，纯文本提取可能带着大量空白符、转页标记、装饰字符；转成Markdown后内容密度反而更高，喂给大模型的token自然变少。

我印象比较深的是一个产品手册项目，当时做了前后对比：300页PDF，用纯文本提取分块跑一轮测试问答，准确率61%；先转Markdown再分块，准确率提到78%，token消耗大约降了17%。准确率的提升和成本下降是同时发生的，这比单纯调模型参数有意义得多。从那之后，我在项目里默认就是“先结构化、再进管道”，没有再走回头路。

3. Yellow.ai D-RAC方案思路拆解

3.1 D-RAC是什么：一句话版本

Yellow.ai提出的D-RAC，官方完整叫法的细节没有全部公开，但按公开分享和同领域实践来理解，可以拆成两个关键词：Document Refinement（文档精炼）和 Adaptive Chunking（自适应分块）。整个方案的落点很直接：企业拿到一份PDF，不要直接塞给RAG，而是先经过一条“精炼管线”，输出结构完整、语义清晰的Markdown，再在Markdown的标题树上做自适应切分，最后进入向量化和检索。

换句话说，D-RAC把前面两个章节讲的问题封装成了一个标准化流程。对很多团队来说，这类方案的参考价值不在于它用了多神秘的模型，而在于它把“工程师手工预处理PDF的那套经验”，变成了可以自动跑、可评估、可复现的流水线。就算你没有完全使用它的实现，照着这套思路去改造自己的管线，也能少走很多弯路。

3.2 D-RAC的三步拆解

第一步是版面分析与阅读顺序还原。工具先识别页面里的标题、段落、表格、图片、页眉页脚，然后再推断人类阅读时的顺序：先读标题，再读正文，遇到表格时按行列读，双栏先读左栏再读右栏。这一步直接解决两个最顽固的问题：顺序错乱和页眉页脚混入正文。

第二步是结构化编码。把识别出来的元素编码成Markdown，而不是普通文本。表格输出为Markdown表格，代码块用三个反引号包裹，公式输出为LaTeX格式。注意，这一步产出的Markdown不只是给人看的，更重要的是给下游切分器看——它就是切分的“路标”。

第三步是结构感知切分。在Markdown的标题层级树上做切分，同一个二级标题下的内容默认聚合成一个大块，如果块太长，再按三级标题、段落、句子的顺序逐级往下拆，直到长度符合chunk_size要求。这套流程跟我自己手工调优过的管线几乎一致，D-RAC的贡献不是发明了新理论，而是把它产品化了，并且很可能内嵌了针对企业文档的版面模型。

这里有一个顺序问题值得强调：必须先转结构、再做切分，不能反过来。因为一旦把文本切碎，表格、代码块、标题关系全丢了，再想还原结构几乎不可能；而在完整文档上先识别结构，再基于结构切分，语义边界天然存在。这个顺序错了，效果天差地别。

4. 实操：把“PDF→Markdown→RAG”这条链路搭起来

4.1 工具选型：五款主流转换工具横向对比

市面上的PDF转Markdown工具不少，但各有侧重。我筛选了五款最常用的，按自己的实测情况整理了一张表：

我的推荐逻辑是：通用中文企业文档（产品手册、制度文件）优先用MinerU；中英文混合、偏品牌视觉类的文档用Marker；数学公式多的技术文档直接用Mathpix，省下的调优时间比授权费值钱；如果只是批量处理常规PDF、想在CPU集群上跑，Docling是省心的选择。另外强调一点：扫描版PDF必须先走OCR，我常用PaddleOCR，识别完文字再交给上述工具，否则只会得到乱码。这不是可选项，是必经步骤。

4.2 分块参数配置：一份可以直接复制的代码

转出Markdown之后，下一步是分块。我以LangChain为例给出一个配置，这段代码我在多个项目里跑过，可以直接当起点使用。

from langchain.text_splitter import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter headers_to_split_on = [ ("#", "H1"), ("##", "H2"), ("###", "H3"), ] md_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) md_header_splits = md_splitter.split_text(markdown_document) chunk_size = 512 chunk_overlap = 80 text_splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=chunk_overlap, separators=["\n\n", "\n", "。", ".", "；", ";", "，", ",", " ", ""], ) chunks = [] for header_split in md_header_splits: chunks.extend(text_splitter.split_text(header_split.page_content))

很多人在这一步会踩坑：为什么不用RecursiveCharacterTextSplitter直接切？因为MarkdownHeaderTextSplitter的价值是“先按标题分大块”，保证边界是语义边界；RecursiveCharacterTextSplitter只是兜底，把过长的标题块拆成小段，两者是分工关系，不是替代关系。

几个参数我解释一下。separators列表里把中文句号和分号放在英文标点前面，是因为企业中文文档句子更长，标点截断要优先照顾中文习惯；如果把英文标点写在前面，中文文档会在不该断的地方被硬切。chunk_size=512是我在多数项目里的起始值，大约对应100到150个中文词，兼容主流embedding模型的分词窗口。chunk_overlap=80让相邻块保留一定重叠，避免关键信息恰好落在边界被切掉。这个数值不是固定的，文档句子偏长就调大chunk_size，问答粒度偏细就调小，但建议一次只动一个参数。

顺带提一个进阶技巧：分块时把标题作为metadata存进向量库。比如把“产品手册/安装说明”这样的层级信息挂在每个chunk上，检索时可以按标题过滤，也能在返回答案时向用户展示来源路径。

4.3 评估：转换质量与检索效果怎么量化

不要只凭肉眼看几页就说“效果不错”。我建议至少搭三组指标，缺一不可。

第一组是命中率（Recall@K）。准备30到50个贴近业务的问题，每个问题标注标准答案所在的源文档或源页面，跑检索看正确答案是否出现在Top-K结果里。这个数字直接反映“切分加向量化”的底子，跟模型生成质量无关。

第二组是生成质量打分。把检索结果交给大模型生成答案，再用GPT-4或其他模型按“准确、完整、不臆造”三个维度打分。这一步反映端到端效果。注意评分模型和生成模型要分开，避免自我评分偏差。

第三组是转换质量抽检。随机抽10页PDF，人工对比Markdown是否保留了标题层级、表格行列、代码块完整性。抽检能快速定位问题出在转换环节还是检索环节。

我自己跑项目的顺序是：先做第三类抽检，确认转换质量及格；再跑第一类命中率，确定分块参数要不要调；最后才做第二类打分，验证最终体验。这个顺序能少走很多弯路——没有评估集的RAG优化，本质上是自我感觉良好，等上线被业务方问住了才去补救，代价就大了。

5. 落地避坑与问题排查

5.1 高频问题速查表

这条路我在多个项目里走过，中途最容易出问题的环节不是模型，而是转换和切分里的各种“阴间情况”。下面这份速查表基本覆盖了我遇到过的绝大部分问题：

为什么这些问题容易在项目后期才暴露？一个重要原因是很多团队测试时用的是“干净文档”——白底黑字、单栏、无表格、无页眉页脚。这种文档谁都能解析得很漂亮，但企业真实文档里，带页眉页脚、多栏、扫描件、内嵌图表才是常态。我自己的习惯是上线前专门找50份“最丑”的文档做压力测试，见过的问题越多，正式环境里翻车的概率越低。

5.2 边界：不是所有PDF都适合转Markdown

转Markdown不是银弹，有三类文档要特别小心。

第一类是带手写批注的扫描合同。OCR都很难识别手写内容，硬转Markdown反而丢失了关键审核信息。这类文档更适合“OCR加人工校对”的流程，或者直接交给多模态模型处理，不必强行走Markdown。

第二类是组织结构图、拓扑图这类纯图表页面。转成Markdown后只剩图片和一段说明文字，图的真正信息全丢了。正确做法是在Markdown里保留原图引用，并用多模态embedding来处理图片部分，让检索系统能同时索引文本和图像。

第三类是几千页的超大文件。一次性转换容易内存暴涨、耗时过长，需要分批处理，甚至要考虑抽页转换。另一个容易被忽视的问题是：有些PDF本身就是从无结构文件打印导出的，内部连基本段落顺序都没有，这种文档转Markdown收益有限，不如先评估它是否适合进RAG。

把这些边界讲清楚不是泼冷水，而是让方案在错误的数据上浪费时间之前，先停下来想清楚：这份文档是不是真的适合这条链路。

6. 一点实操体会

6.1 先打通转换管线，再谈调参

做企业RAG项目这几年，我最大的体会是：数据准备至少要占整个项目工作量的六到七成。模型选型、向量库、Prompt这些环节当然重要，但PDF转Markdown这一步没做好，后面所有环节都在替它做补救。D-RAC这类方案真正有价值的地方，是把工程师在多个项目里攒下来的“手工经验”变成了一条可自动执行的流水线：版面分析、阅读顺序还原、结构化编码、结构感知切分，每个步骤都有明确产出，每一步都能评估。

这也提醒一件事：接到RAG项目时，别一上来就调embedding、改Prompt，先花一天时间把手头那批PDF的转换管线跑通，做一次质量抽检。我自己试过，很多时候把转换这一层修好，效果提升比调任何参数都明显。

6.2 一个值得尝试的扩展：图文联合检索

我再分享一个小技巧。做转换质量抽检时，不要只看文档前几页，专门抽中部的复杂页面——指标表、代码示例、多栏介绍页。这些页面最能暴露解析器的短板。我还在管线里加了一个“二次校验”步骤：转换完成后再把Markdown渲染成PDF，与原图做一次视觉比对，人工抽查。这看起来笨，但确实救过不止一次，表格行列错位、公式下标丢失这类问题，光看文字层面几乎看不出来。

这条链路后续还有一个很自然的扩展方向：Markdown里保留的图片引用，配合多模态embedding，可以实现“图文联合检索”。用户问“这张架构图里安全网关在哪一层”这种问题时，系统可以连图带文一起返回，体验比纯文字回答好一个档次。如果你正在搭企业级知识库，建议把这块纳入规划，别等到上线之后再返工。