面经策

在 RAG 应用中为了优化检索精度，其中的数据清洗和预处理怎么做？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

这个问题我在实际项目里踩过坑，数据清洗的投入产出比往往被严重低估——垃圾进、垃圾出，检索层再怎么调优也救不了脏数据。

我们按四步走：

  • 解析层：用版面识别类解析器（如 MinerU、Unstructured）替代纯文本抽取，保住表格、标题层级；扫描件走 OCR 并标注置信度，低置信度页转人工抽检。
  • 清洗层：正则+规则去页眉页脚、水印、目录、重复段落；合并断行断句；统一全半角、日期、计量单位——这些"小事"直接影响召回质量。
  • 结构化层：保留文档元数据（来源系统、部门、版本、生效日期、密级），后续检索时靠它们做权限过滤和时效剔除，这是合规刚需。
  • 治理层：建立文档准入规范，让业务部门在上传环节就打标签，而不是事后靠技术补救。

业务判断：清洗约占 RAG 项目 40% 的工作量，但决定了 80% 的最终效果。我的建议是把清洗规则沉淀为可配置的流水线资产，随着知识库扩张持续复用，而不是每个项目重写一遍。

🏗 系统架构师 ​

数据清洗是 RAG 效果的第一道杠杆——垃圾进垃圾出，后面检索和生成再怎么调优也救不回来。我的生产实践分四步：

  • 格式归一化：PDF/Word/HTML 统一转结构化 Markdown 或 JSON，保留标题层级、表格、列表语义。表格是重点：小表转 HTML/Markdown 原样进 chunk，大表拆行并冗余表头，或单独建结构化索引走 Text-to-SQL 通道；
  • 噪声去除：页眉页脚、水印、目录、乱码字符用规则 + 版式特征过滤；扫描件走 OCR 后再清洗；
  • 去重与版本：按内容 hash 精确去重，按 MinHash/SimHash 近似去重；文档带版本号，更新时旧版本向量标记失效而不是物理删除（保留审计）；
  • 质量打分：每条 chunk 记录质量分（长度、信息密度、语言检测），低分不进索引。

架构要点：清洗管道做成幂等的批处理流（Airflow/DolphinScheduler），支持按文档粒度重跑；清洗规则版本化——规则变更后要能评估"哪批文档受影响、是否需要重嵌入"，否则线上问题无法归因。经验上清洗做好，召回命中率提升比换大模型还明显。

💻 全栈开发专家 ​

数据清洗是 RAG 里最枯燥但收益最大的一环，我们的流水线按顺序做这几件事：

  1. 版面还原：用 MinerU/Docling 解析 PDF 得到 Markdown，去掉页眉页脚、水印、目录页噪声。
  2. 正文规范化：全半角统一、繁简转换、异常空白合并、乱码字符剔除；OCR 结果做纠错（PaddleOCR + 规则词典）。
  3. 去重：文档级 MinHash/SimHash 近重复检测（版本迭代文档只留最新），chunk 级精确 hash 去重。
  4. 结构保留：表格转 Markdown/HTML，标题层级映射为元数据（h1/h2），代码块 fenced 保护，避免被后续清洗误伤。
  5. 质量过滤：语言检测（只要中文/英文）、长度过滤（<50 字的碎片丢弃）、低质量打分（句子完整性、数字占比异常的丢掉）。
  6. 脱敏与元数据：手机号/身份证打码；抽 time、source、department、acl 字段，后面检索过滤全靠它。
python
clean = re.sub(r'\s+', ' ', text).strip()
chunks = dedup_by_hash(chunk_markdown(clean, size=512, overlap=64))

最大的坑：不要追求一次清洗完美，先上 100 条「脏样本」标注人工检查清洗结果，迭代规则；尤其表格一旦被当普通文本切段，召回基本废了。