企业官网建设流程全解析

我最近在排查一个线上知识库的检索效果问题，模型参数调了好几轮，向量库也换了更贵的，结果召回来的内容还是莫名其妙。后来把链路拆开一层层看，发现问题根本不在模型，而是出在最前面的文档解析和切片上——PDF里的表格被解析得支离破碎，切片又把本来完整的一段业务规则拦腰截断。那一刻我才真正意识到，文档解析与切片这套"地基"如果打歪了，后面embedding、重排、生成做得再花哨，都是白搭。

这篇就专门聊聊解析和切片这两个环节。它们看上去门槛低，实际上决定了整个检索链路的天花板。如果你正在搭RAG应用、知识库问答系统，或者在做文档结构化处理，这篇文章值得你花十分钟读完——我会把选型逻辑、切片策略、以及我在真实项目里踩过的坑一次性讲清楚。

1. 解析与切片的问题，是怎么一步步毁掉检索效果的

1.1 一个典型的"模型没问题，效果却很烂"案例

先说一个我实际处理过的案例。一个企业内部制度问答系统，文档源主要是Word和PDF，总量大概两千份。初版上线后，用户问"请假的审批流程是什么"，系统召回的全是"考勤管理制度-第一章-总则"，里面只有一句"请假需按规定办理"，真正的流程表格完全没被切进去。再问"报销额度上限"，召回来的是封面页和目录页，正文图表完全缺失。

我把embedding模型从bge-small换到bge-m3，把向量检索的top-k从5调到20，加上了重排模型，效果依然没有本质改善。后来把ssembled文本dump出来一看，发现问题全在解析阶段：PDF里的表格被读成了竖排一列的文本，Word里的章节标题丢失了层级关系，有的文档干脆只读到了第一页。

这个案例说明一件事：检索效果不是从向量检索那一刻才开始的，而是从文档被解析成文本的那一刻就已经被决定了。解析阶段丢掉的信息，后面无论怎么调参都找不回来。

1.2 解析与切片真正影响的，是"召回"而不是"排序"

很多人会把检索效果不好归咎于排序模型，但实际上，解析和切片主要影响的是召回环节。

召回的本质是"把用户的问题和候选片段做相似度匹配"。如果切片里存的文本是残缺的、语义错位的，那么它和用户问题之间的向量距离天然就很远。排序模型只能在召回来的候选项里做排序，如果候选项本身质量差，排序再好也是矮子里拔将军。

我用一个简单的类比来解释：解析和切片就像做饭前的洗菜切菜。菜没洗干净、切得大小不一，后面厨艺再好，炒出来的菜也是夹着沙子的。做RAG的人往往花大量精力在模型选型、Prompt设计上，却忽略了前面这两步——这恰恰是最不该忽略的。等到效果出问题再回头改地基，返工成本远高于一开始就做好。

2. 文档解析怎么选型：按文档类型进攻，而不是一套工具打天下

2.1 PDF解析的方案对比：PyMuPDF、pdfplumber与重型工具

PDF是最常见的文档格式，也是最难处理的。原因在于PDF本质上是一套"画布指令"，它记录的是每个字符放在哪个坐标位置，而不是"这里是一个段落"这样的逻辑结构。所以解析PDF，本质上是在做逆向工程。

我实际用过的方案有这几类，先说结论再展开：

我现在的选择策略很简单：先用PyMuPDF快速识别文档类型，如果页面里没有复杂表格、没有多栏排版，直接用PyMuPDF提文本就够了，快且稳定。如果检测到表格，切到pdfplumber单独处理表格页。如果是扫描版或者版面特别复杂的论文，用marker这类工具做整体解析。

这里有一个反直觉的结论：不是工具越重越好。对于文字叙述为主、版面简单的文档，用重型工具反而可能引入识别错误。我见过marker把"公司名称"里的冒号识别成乱码的情况，轻量工具反而没这个问题。

2.2 Word/PPT/HTML的处理细节：结构信息别丢

很多人解析PDF时小心翼翼，处理Word和PPT却很随意，直接用python-docx和python-pptx把段落文本提出来就完事。这其实是个大坑。

Word文档的宝贵之处在于它的结构信息是现成的：Heading 1/2/3、表格单元格、加粗、项目符号，这些都是语义信号。如果只提取纯文本，等于把这些信号全扔了。我的做法是保留标题层级标记，在文本里用特殊符号标注，比如"## "表示二级标题，这样后面切片时就可以基于标题做切分。

PPT的处理更要注意。PPT的文本往往以文本框为单位散落在页面上，阅读顺序并不等于文本框的存储顺序。如果直接用python-pptx按顺序读，读出来的内容顺序很可能是乱的。我的做法是先按每个文本框的坐标（top属性）排序，再按从左到右的顺序组合文本，这样才能保证一段话的先后关系是正确的。

HTML文档相对简单，用BeautifulSoup提取正文时注意去掉导航、广告、页脚之类的噪音，然后把p标签、h2标签这些语义信息保留下来。很多爬虫抓下来的网页，正文前后全是推荐链接，不清理的话噪音会占据切片名额。

2.3 表格解析的保真：让"列"的语义存活下来

表格是文档解析里最容易翻车的地方。我见过最离谱的情况是，一个三列的报销标准表格，解析后被读成了三行连续的文本，每一行是"费用类型 限额 备注"这种内容的交错拼接。这种文本喂给切分器，要么被切成毫无意义的片段，要么和query的匹配度极低。

我的处理方式是：先检测页面是否包含表格，然后对表格单独走"行列重组"流程。具体做法是利用pdfplumber拿到表格线的坐标，或者用python-docx拿到表格对象，然后把每一行的单元格内容合并成一个结构化字符串，单元格之间用自定义分隔符（比如" | "）连接。这样一个表格行就变成了一段相对完整的语义单元。

重组之后还需要做一个关键处理：把表格的表头信息拼进每一行。比如表格第一行是"费用类型|限额|备注"，第二行是"住宿|500/天|需发票"，我会把表头拼到数据行后面，变成"费用类型：住宿；限额：500/天；备注：需发票"。这样切出来的片段单独拿出来也是自解释的，检索时不会因为缺少表头信息、上下文不完整而失效。

3. 切片策略没有银弹：按文本形态设计chunking方案

3.1 四种常见切片策略及其适用场景

切片是做RAG最纠结的一环，因为不存在一个参数能让所有文档类型都表现好。我整理过四种常见策略，它们各有各的适用场景：

1. 固定长度切片：按字符数或token数硬切。实现最简单，但语义完整性最差。只适合文本结构均匀的日志、规则条文这类场景。

2. 递归字符切分：先用段落分隔符切，段落太长再按句号切，句子太长再按逗号切。这是LangChain等框架的默认方案，对普通文本效果尚可，但对结构化内容不敏感。

3. 语义切分：把文本按embedding相似度聚类，或者在语义边界处切断。效果好，但计算成本高，而且对短文本、表格类内容容易误判。

4. 结构切分：基于文档本身的标题结构切，一个章节作为一个切片。适合有明确章节结构的文档，但章节太长时切片过大，需要再二次切分。

我在实际项目中，用的最多的是"结构切分+递归字符切分"的组合：先按标题把文档切成章节块，每个章节块如果超过设定长度，再按段落和句子递归切分。这样既保留了章节的语义边界，又控制了切片长度。

3.2 语义边界比长度更重要：为什么要在标题、段落边界切

不少人设定切片长度时会纠结"chunk_size到底是512还是1024"，但其实长度的绝对值并没有那么重要，重要的是切的时候有没有照顾语义边界。

我举个例子：一段话是"根据规定，员工出差住宿费标准为：一线城市500元/天，二线城市350元/天，其他城市260元/天。超过标准部分不予报销。"如果在"一线城市500元/天"后面硬切，那么第一个切片里只有半句话，第二个切片开头是"二线城市350元/天"，两边的信息都不完整。用户问"二线城市住宿标准"，第二个切片也许能匹配上，但如果用户问"住宿费报销标准是什么"，两个切片都覆盖不了整条规则。

所以我的原则是：在句子边界和段落边界切，尽量保持一个完整的语义单元。如果必须在一个段落内部切，也要在句号、分号这类标点处切，而不是按字符数硬切。这一步看似简单，但它直接决定了后续embedding时每个切片的语义密度。

3.3 特殊内容怎么办：代码块、表格和列表的切片策略

代码块和表格这类结构化内容，用普通文本切片策略会切得稀碎。代码块的问题在于，函数定义、调用、返回往往跨越多个段落，硬切会把函数体拦腰截断，导致筛出来的代码片段没法运行。表格的问题前面也提过，行列信息一旦被切成碎片，就完全失去了表意能力。

对于代码块，我建议按函数或类来切，而不是按行数切。可以用简单的AST解析先识别出每个函数的起止行号，再按函数边界切片。如果文档是Markdown格式，代码块本身有明确的分隔标记（```），可以保留这些标记作为边界。对于没有AST工具的场合，至少也要在空行处切，而不是在代码行中间切。

对于表格，前文提到了表头拼接法，切片时直接以"表格块"为单位，一个表格行或一组相关行作为一个切片。确保切片内包含表头信息，这样检索时即使只有片段，也能还原出每个单元格的含义。列表的话，尽量保留项目符号或编号，把整个列表作为一个切片，不要切断中间的项目项。

4. 别再拿Python列表切片那套思路切文档

4.1 Python数组切片的语法与直觉

提到"切片"这个词，很多Python开发者第一反应是列表切片：

# 列表切片 items = [0, 1, 2, 3, 4, 5] print(items[1:4]) # [1, 2, 3] print(items[:3]) # [0, 1, 2] print(items[::2]) # [0, 2, 4]

这种切片的直觉是：我有n个元素，按照下标范围切出来一段，剩下的是另一段。这个模型放在数组上完全正确，因为数组元素之间没有上下文依赖，每个元素是独立的。

但文本不是这样的。文本的每个字符、每个词之间有着强烈的上下文依赖——"他"指代的是前文的某个人，"根据上述规定"依赖的是上一段的条款。如果你把文本当成数组来越界切分，就相当于把一句话从中间掰断，前后两部分都失去了理解所需的上下文。这就是"用list思维切文档"最大的坑。

4.2 文本切片的隐藏变量：语义、上下文与metadata

文本切片和数组切片最大的不同，在于切片对象不是"元素"而是"语义块"。一个语义块可以被理解，不取决于它的长度，而取决于它是否包含完整的语义单元。

除了语义，还要关注上下文和metadata。我在实际项目中吃过一个亏：一开始切片时没有保留来源信息，结果用户检索到一段内容后，系统无法给出引用来源（哪个文档、第几页），导致回答的可信度大打折扣。后来我在每个切片对象里都加上了metadata，包括文档名、章节路径、页码、切片序号。这样做还有个额外的好处：检索结果可以做聚合，同一个章节命中的多个切片可以合并去重，避免回答时反复重复同一段内容。

另外，相邻切片之间要有一定程度的overlap（重叠）。我常用的设置是切片长度500个token，重叠50个token。重叠的部分能让跨越边界的语义信息在两侧都能被找到。这个在数组切片里是不存在的概念，但在文本切片里非常关键。

4.3 从"切成块"到"切得能检索"：两种思路的差别

"切成块"的思维是：我有一整篇文档，我要把它切成若干等长的小块，每个小块负责存储文档的一部分。这种思路的逻辑中心是"存储效率"。

"切得能检索"的思维是：用户会拿问题来匹配切片，切片里存储的内容要尽量和可能的问题对齐。比如用户问"盖章对合同是否有效"，能召回"未加盖公章不影响合同效力"这个切片，不是因为切片恰好包含了"盖章"和"合同"这两个词，而是因为切片本身是一个完整的法律判断句。这种思路的逻辑中心是"语义可匹配性"。

两者差别直接体现在切片设计上。前者关心chunk_size和overlap参数调多大；后者关心如何保留标题结构、如何把表头拼进行、如何按函数边界切代码。当你把检索效果作为衡量标准时，切片策略的选择维度就完全不同了。这也是我在前面反复强调结构信息、表格保真的原因——所有这一切，都是为了让切片在检索时能"被找到"。

5. 切片质量的评估与调优：先有衡量标准，再调参数

5.1 怎么衡量切片好不好：三个可落地的指标

切片质量不是感觉出来的，是可以量化评估的。我实际用下来，有三个指标最实用：

1. 检索命中率：拿一组测试问答对去检索，看正确的切片是否出现在top-k结果里。这是最直接的指标，能反映切片和query的匹配程度。

2. 切片信息完整度：让人工检查切片内容，看它是否包含完整语义单元（比如有没有被拦腰截断的句子、有没有缺失表头的表格行）。

3. 切片长度分布：统计切片的token数分布是否合理。如果大量切片远低于设定长度，说明切分过于激进，语义被切碎了；如果大量切片远超设定长度，说明结构切分没有生效。

这三个指标里，检索命中率是最核心的。我建议每个项目在一开始就准备一套三五十条的测试问答对，后续调优切片参数时，用这套测试集来验证。

5.2 三个典型失败case与修复过程

我整理三个真实调优过程中的失败样例，你大概率也会遇到类似情况：

Case 1：一个章节被切成了20个小切片，用户问题却一个都没命中。排查发现，该章节是一个连续的表格，被递归字符切分器按行切碎，每一行只有"项目名称|金额"这类残缺信息。修复方式：识别到表格块时，整个表格作为一个切片单元，同时把表头拼进每一行。

Case 2：Chunk size设太大（2000 token），embedding和检索速度都慢了，而且一个切片里包含太多主题，导致query匹配得分被稀释。修复方式：改回500 token，但利用章节标题做分层切片，一个章节内部再按段落切。

Case 3：切片边界恰好切在一段规则的中间，前半段是条件、后半段是结论，用户按结论查询时，后半段切片缺少了条件信息，回答不完整。修复方式：增大重叠窗口，同时调整切分逻辑，在句号处强制断开。

这类问题在调试时是最耗时的，因为报错不会直接暴露解析和切片的错误，只会表现为"检索效果差"。我的建议是，在调模型之前，先做一轮切片质量的人工抽检——随机抽20个切片看内容是否完整，抽50个测试问题看召回是否合理。这一步能省下后面至少一半的调试时间。

5.3 我的参数组合与调优顺序参考

给一个我目前在多个项目里验证过、效果比较稳定的起始参数组合：

调优顺序上，我建议先保证"语义完整"，再调"切片长度"，最后调"重叠窗口"。可以先人工观察20个切片的语义完整性，如果切片内部语义残缺，优先调整切分逻辑而不是长度。语义完整之后，再通过测试集调整长度和重叠参数，用检索命中率来验证。

我还想强调一点：不同的文档类型可能需要不同的参数。我接触过一个项目，既有长篇幅的规章制度，又有短小的问题清单，用同一套参数跑出来的效果就很差。后来我按文档类型分流，规章制度用结构切分，问题清单直接整体作为一个切片，效果提升明显。这个思路值得你用在自己的项目里。

6. 给后来者的一份自查清单

6.1 每新增一批文档，先做这三步

新增文档入库前，先花几分钟做三件事：

1. 随机抽取3到5个文档，人工查看解析出的文本是否完整，重点看表格、页眉页脚、多栏版面。

2. 用一组5到10个测试问题，检查这批文档内容能否被正确检索到。这一步能提前发现问题。

3. 抽查切片结果，确认没有半截句子、丢失表头、代码被拦腰切断的情况。

我在项目里吃过太多亏，都是因为文档入库时没有检查，等到用户反馈效果差才回头排查，那个时候已经积压了大量脏数据。再脏的数据也能重新解析，但你得先知道它什么时候脏的，不然最后只能全量重跑一遍，非常痛苦。

6.2 解析与切片阶段容易忽略的四个细节

最后分享四个实操中很容易忽略的细节：

• 页眉页脚需要在解析阶段识别并剔除。很多PDF的页眉是"XX公司内部文件"，如果混入切片，会让所有切片带上公司名这个噪音词，严重干扰embedding的语义区分度。

• 中文文本的句号、分号、引号都是在切分时值得利用的边界信号。不要只看长度就切断，要学会利用语言自身的标点符号。

• 切片后要做去重。有些文档的目录和正文内容重复，目录部分解析后会生成和正文几乎一样的切片，这些冗余切片检索时会被重复召回。

• 始终保留原始文本在切片对象里。embedding向量可以用于检索，但最终展示和回答时，仍然需要原始文本。切片对象里保存原始文本，后面还有机会做后处理。

我做了几年RAG相关的项目，最大的体会是：解析和切片这套"地基"工作，做的时候费工夫，但能省下后面十倍甚至百倍的调优时间。与其在模型和Prompt上反复折腾，不如先把这一步做扎实。毕竟地基歪了，盖出来的楼再好看，也经不住一次地震。