RAG 系统的效果，不取决于模型有多强，而取决于它“读到”了什么。检索回来的内容如果不干净、不完整、不清晰，再好的生成模型也无法给出准确答案。文档纯度、信息密度和结构化程度，是衡量知识库质量的三个关键维度，也是落项目时最容易出问题的地方。
5.1.1 文档纯度：垃圾进，垃圾出
文档纯度指的是文档中有效信息的占比，以及是否混杂了无关、错误或干扰性内容。真实业务文档很少是“纯净”的，常见杂质包括：页眉页脚、水印、免责声明、广告语、HTML 标签残留、扫描件 OCR 产生的乱码等。
- 对检索的影响：杂质会被嵌入模型一视同仁地转换成向量，占用向量的语义维度。检索时，可能因为杂质词的干扰，导致“语义相近”实为无效匹配。
- 对生成的影响：如果检索到的片段中包含大量无关文字，模型有限的上下文窗口会被浪费，真正关键的信息反而被截断或稀释。更糟的是，模型可能将杂质当成事实，产出错误回答。
实用做法：在文档入库前，必须进行清洗。删除重复的页眉页脚、统一格式、去除不可见控制字符；对于 PDF，优先使用原生文本图层而非 OCR，如果必须 OCR，则需要后处理剔除明显乱码段落。写一个简单的预处理脚本，用规则过滤已知杂质，是性价比最高的提升纯度方式。
5.1.2 信息密度：回答藏在一堆废话里
信息密度指单位文本内包含的有效事实数量。简明扼要的 FAQ、结构化参数表，密度高；会议记录、长邮件往来、大段背景描述，密度低。
- 检索阶段的挑战：低密度文档即使被正确召回，答案也可能埋没在长篇叙述中。模型需要在大量冗余文本里提取关键事实，增加了出错概率。
- 切片策略的联动：长文档通常需要切分成多个 chunk，如果信息密度不均匀，关键事实可能被切到两个 chunk 的边界，导致任何一个 chunk 都不包含完整答案，检索召回率下降。
实用做法：在可能的情况下，优先整理出高密度的源文档。例如，把产品知识从长手册中提炼为简洁的规格表；将常见问题整理成独立的问答对文档，每个条目短而独立。对于不得不保留的长文，要通过调整切片大小和重叠度，确保一个完整的知识点不被切断。
5.1.3 结构化程度：机器看懂的才是好东西
结构化程度指文档是否有清晰的标题层级、表格、列表、元数据标注等，使得机器更容易解析和理解语义边界。
- 标题与层级：清晰的标题和副标题不仅能帮助人类阅读，也天然标记了主题范围。在切片时，保留并注入章节标题到每个 chunk 的元数据中，可以大幅提升检索的上下文准确性。
- 表格与列表：表格中的每个单元格信息量高度集中，但常规的按固定字符数切片很容易破坏表格结构。一格内容被切散，检索时就无法获取完整记录。
- 元数据与标签：文档的版本号、适用范围、创建时间等元数据，如果结构化存储，可以用来做过滤（例如只检索近一年批准的文档），提高回答时效性和权威性。
实用做法：尽量使用 Markdown、JSON 等结构化格式管理知识源。解析时保留标题层级，将表格提取为可单独检索的行或键值对。为每个文档添加统一的元数据字段，方便后续检索时根据条件过滤。
5.1.4 三者之间的相互关系
这三个维度不是孤立的，常常相互影响：
- 高纯度但信息密度低的文档（例如去掉杂质的冗长会议记录），检索后仍需要生成模型费力提炼。
- 高密度但缺乏结构的文档（例如纯文本堆砌的 FAQ），可能在检索时因为缺少标题锚定而匹配不准。
- 结构化好但纯度不够（例如带大量注释的代码文件），会让检索被无关注释干扰。
在实践中，打磨数据质量需要从这三个视角同时审视。一个务实的检查方法是：随手抽几个提问，看检索到的片段是否“一眼就能看出答案”。如果人看着都费劲，模型处理的结果一定不稳定。
数据质量的打磨，是 RAG 项目中最不炫但最值得投入的环节。将存量文档整理到“干净、高密度、结构清晰”的状态，往往比反复调参提示词更有效，也是保证后续检索和生成稳定的根基。