很多团队在做 RAG 知识库时，都踩过同一个坑：把几十篇 PDF、Word 和 Excel 直接扔进知识库，随后发现大模型经常胡说八道，或者回答“在知识库中未找到相关内容”。
遇到这种情况，很多人第一反应是换一个更大的模型，或者换一个更贵的向量嵌入模型。但是我见过的大多数项目，问题根本不在模型，而在数据入库前的清洗与切片。
如果原始文档格式混乱，向量数据库拿到的就是一堆垃圾片段。垃圾存进去，检索出来的自然也是垃圾。要让检索结果精准稳定，必须建立一套标准化的清洗和切片流程。
第一步：文档解析与清洗，把垃圾内容滤掉
很多 PDF 直接提取文本时，会把页眉、页脚、页码混在正文里。比如一页正文刚好断在一句话的中间，下一行突然插入了“第 12 页 某某公司员工手册”，紧接着才是下半句。
这种断句直接切片，会破坏句子的语义。向量模型会把页眉页脚当成核心特征计算进去，导致用户搜索正文时完全召回不到。
我们在处理文档时，需要先执行三个标准动作：
1.剔除版面噪点：先跑正则表达式或者版面分析工具，把每页固定的页眉、页脚、页码、免责声明彻底删掉。
2.清洗不可见字符与多余空白：去除文档中连续的换行符（如三个以上的 `n` 缩减为两个）、制表符以及由于 PDF 换行产生的断行硬回车。对于中文文档，要把行末被错误切开的句子拼接回完整的一行。
3.将富文本统一转为 Markdown 格式：不要把 PDF 或 Word 直接转成无格式纯文本。纯文本会丢失各级标题层级（H1、H2、H3）和表格结构。统一转为 Markdown 格式，能把排版信息转化为大模型能理解的语法标签。
在解析工具的选择上，如果文档结构简单，可以用 PyMuPDF 快速提取文本。但是遇到跨页表格、双栏排版或者扫描件，必须采用带版面分析能力的解析工具（如 Docling、MinerU 或 Unstructured）。它们能准确识别阅读顺序，避免双栏排版被横向切碎。
第二步：根据文档形态选择切片策略
很多工程师习惯直接设定“每 500 个字符切一切，重叠 50 个字符”。这种固定长度切片方式最容易出事故。比如一段关键的违约赔偿条款被一刀两断，前半段没有罚则，后半段没有主体，两段都变成了毫无意义的信息孤岛。
针对不同类型的内容，切片策略必须分流：
| 切片策略 | 实现机制 | 优势 | 劣势 | 推荐场景 | 核心参数建议 |
|---|---|---|---|---|---|
| 按文档层级切片 (Markdown Header) | 识别 `#`、`##` 等层级标题，以章节和段落作为自然边界切分 | 保持完整逻辑单元，上下文不割裂 | 若某章节内容过长，仍需二次切分 | 技术文档、规章制度、带清晰结构的报告 | 切分层级：H2 / H3 标题 |
| 递归字符切片 (Recursive Character) | 按照特定优先级符号列表递归向下拆分：段落(`nn`) → 单行(`n`) → 句号(`。`) → 逗号 | 切片大小可控，尽量不截断完整句子 | 对复杂多栏排版不敏感 | 通用长文本、说明书、新闻资讯 | Chunk: 512 tokens，Overlap: 10%-15% |
| 父子块检索 (Parent-Child / Hierarchical) | 将小切片用于向量比对召回，把包含小切片的父级大块传给大模型回答 | 检索定位极准，模型理解上下文完整 | 存储体积扩大 2 到 3 倍 | 逻辑严密的长篇合同、行业规范、法律法规 | 子块: 128-256 tokens，父块: 1024-2048 tokens |
| 语义切片 (Semantic Chunking) | 计算相邻句子的向量相似度，当相似度突降时打断并切分 | 依据主题变化切分，主题边界极准 | 计算成本高，切片长度不可控 | 口语化访谈记录、会议纪要、无标题长文 | 相似度阈值：90%-95% 分位数 |
第三步：落地切片的核心参数与规范
选定策略后，切片参数需要严格遵照工程规范设定。
1. 切片大小（Chunk Size）控制在 256 到 512 Tokens
切片越小，检索越准；切片越大，背景信息越完整。 但是不要走向极端。
很多团队喜欢把切片设到 1000 甚至 2000 个 token。切片太大，向量模型计算出的语义向量就会被稀释，导致精准匹配度下降。而且大切片容易引入无关信息，增加大模型产生幻觉的概率。
根据实际评测数据，面向问答任务时，256 到 512 Tokens 是检索命中率最高、语义浓度最适中的区间。
2. 重叠度（Chunk Overlap）固定在 10% 到 20%
切片之间必须保留重叠窗口。如果没有重叠，恰好落在切分边界上的专有名词或因果句式就会被腰斩。
如果 Chunk Size 设为 500，重叠区域建议设为 50 到 80 Tokens。重叠比例不要超过 25%，否则会导致召回列表中出现大量内容重复的切片，挤占有限的检索窗口。
3. 必须保留上下文元数据（Metadata Injection）
这是许多人容易忽略的细节。比如规章制度里的一个切片内容是：“如果逾期未补齐材料，视同放弃本次申请资格。”
如果单独把这句话向量化，由于缺少主语，用户搜索“落户申请超时怎么办”时，这句话很难被排在前面。
解决方法是：在切片生成时，把文档名称和层级路径直接拼在切片内容的最上方。
例如处理后的切片内容应为：
【文档】人才引进落户办事指南
【章节】第三章 审核流程 > 第二节 补充材料规范
【正文】如果逾期未补齐材料，视同放弃本次申请资格。给切片打上层级标签后，向量模型不仅能捕捉正文，还能精准捕获所属的主题和业务场景，让原本难以召回的孤立段落立刻变得可检索。
第四步：表格与代码的特殊处理规范
表格是 RAG 系统的重灾区。很多解析工具会把表格变成一行行无序的文字，表头和单元格彻底错位。
处理表格时，务必遵守两条规则：
•小表格整体保留：只要表格 token 数量在单块上限以内，严禁横向或纵向截断表格。将其完整转化为 Markdown 表格文本。
•大表格按行拆分并继承表头：面对超大表格，先提取第一行作为全局表头，然后按 5 到 10 行为一组切成独立数据块，每组数据块前面都必须重新贴上表头。这样每个切片都包含完整的字段定义，避免模型拿到一堆不知道对应什么列的孤立数字。
第五步：清洗与切片后的质检步骤
文档处理完不要马上全量入库。先做小规模抽样验证，避免错误被大规模放大：
1.先做 A：抽查切片长度分布。检查是否存在大量低于 50 个 token 的碎块，或者超出上限的异常巨块。过滤掉无意义的空块。
2.然后做 B：检查切片首尾。随机抽取 50 个切片，看首尾是否有被生硬切断的句子。如果一句话的后半截总是在下一个块里，说明分隔符优先级设定有误。
3.最后做 C：跑基准问答测试。挑出 20 个业务中最核心、最具体的细节问题，查看召回的前 3 个切片中是否包含标准答案。
把脏数据挡在向量数据库之外，花在清洗和规范切片上的时间，能在后期免去大量的 Prompt 调试和大模型微调成本。按照这套标准打磨切片，知识库的检索准确率就会有显著改观。
原创文章，作者：七点互动，如若转载，请注明出处：https://ai.qidianhudong.com/aikonw/4116.html
