RAG数据清洗三大关键

落地 RAG 数据清洗三大关键

RAG 的差异化往往不在“向量库选型”，而在数据清洗的隐形地基：语义完整、结构准确、格式适配。下面总结落地中最关键的三件事，并给出可直接套用的参数与验收要点。

1. 文本切分：在语义完整与检索粒度之间找平衡

推荐参数

• chunk_size：500-1000 字符 / chunk（或按 token 预算等价换算）
• overlap：10%-20% 重叠，防止信息断裂（尤其是表格标题、段落首句、引用上下文）

关键原则

• 切分不是“均匀分段”，而是尽量保持语义边界（段落、列表项、章节小标题、表格行）
• 对表格/代码块：优先按结构边界切分，避免把一行表格拆成多个 chunk

常见坑

• chunk 过小：召回会变高，但答案容易缺上下文，导致“能找但答不全”
• chunk 过大：检索命中率下降，且后续模型需要消化过长上下文

验收要点

• 对典型问题进行人工抽检：命中的 chunk 是否包含完成回答所需的关键信息
• 对“前后文强依赖”的内容（定义、条件、表格标题）验证重叠是否足够

2. PDF 解析：用结构识别避免乱码与版式损坏

推荐做法

• 对复杂 PDF（多列、表格密集、数学公式、扫描件）：优先使用
  • LayoutLM/Layout-aware解析能力
  • 或GPT-4V这类视觉模型进行结构识别
• 目标：尽量恢复“标题层级 + 表格 + 列关系 + 行内顺序”

为什么要“避免基础库乱码坑”

许多基础 PDF 解析器只能抽出字符流，遇到以下情况会显著破坏语义：

• 表格跨行/跨列导致顺序错乱
• 字体编码混乱造成不可读字符
• 多栏排版被拼接为“乱序文本”

这些问题会直接污染切分与向量化，最终让 RAG 的检索与生成都偏离原文。

验收要点

• 抽样对比：同一段落/同一张表在解析后是否能保持可读顺序
• 表格结构是否保留为可解释的行列（而不是一长串拼接文本）

3. 存储格式：坚持 Markdown，保留# 标题 | 表格结构

为什么选 Markdown

Markdown 是“结构化语义”的载体，能自然表达：

• 标题层级（如#、##）
• 表格（|分隔行列）
• 列表与引用

当你把结构保留在原始文档格式里，再切分与向量化，检索命中时模型也更容易复用结构化信息生成高质量回答。

存储约定（建议）

• 保留标题：让每个 chunk 至少包含最近的上级标题（用于语义锚定）
• 表格保留：尽量将表格转换为 Markdown 表格，避免丢失列名与行关系
• 统一规范：同一数据源的格式风格保持一致（例如表格前总是包含表标题）

验收要点

• chunk 内容是否仍能直观看出“该信息属于哪个标题/小节”
• 表格在 chunk 中是否仍是“行列可读”的 Markdown 表格

4. 三者环环相扣：从语义完整 → 结构准确 → 格式适配

这三步形成链式依赖：

• 切分确保“语义不被打断”
• PDF 解析确保“结构不被打乱”
• Markdown 存储确保“结构可被下游利用”

当你把它们作为一个完整流水线治理，而不是分散优化，RAG 的效果通常会呈现更稳定的提升。

5. 最小落地清单（建议直接作为任务拆解）

• 选择切分参数（500-1000+10%-20% overlap），并用样例问题验收
• 明确 PDF 解析策略：复杂 PDF 使用 Layout/视觉结构识别；基础库仅作为补充
• 统一输出为 Markdown，并保留# 标题与| 表格