RAG系统的开发远不止技术实现，文档处理质量才是决定检索召回精度的核心要素。本文从实战经验出发，深入剖析RAG系统中文档处理的常见误区，对比两种主流预处理方案的优劣，并探讨多格式数据存储与检索的结构化挑战，帮助你避开“跑通却不好用”的陷阱。

一、RAG系统开发中的文档处理陷阱

许多开发者在初次接触RAG时，会认为流程相对简单：文档切片 → embedding模型向量化 → 存入向量数据库 → 用户问题向量化 → 相似度匹配 → rerank重排序。但实际测试后会发现，明明文档里包含答案，却无法成功召回，问题几乎都集中在文档处理环节。

为什么在模型能力已经很强的今天，召回精度依然不尽如人意？因为数据预处理的质量直接决定了检索效果的上限。“跑通”只是第一步，真正的难点在于让RAG系统既“快”又“准”。

常见陷阱一：文档拆分粒度不合理

• 拆得太粗：一个段落包含300～500个中文字符，而用户问题可能只有几个字，向量相似度计算时很难精确命中目标片段。
• 拆得太细：召回条数过多，被rerank或其他过滤机制误杀，导致有效片段反而丢失。

常见陷阱二：非文本内容（图片、图表）被忽略或损坏

• Word文档中的架构图、表格图片，如果直接丢弃，关键信息将永久丢失。
• OCR处理质量不佳，导致文字错乱、格式混乱，影响后续检索。

常见陷阱三：多样数据格式缺乏统一存储策略

• 既有Word、Markdown，又有Excel、CSV，还可能有PDF等多种格式。
• 如果为每种格式单独建立字段或向量表，会导致数据分散、维护复杂、检索效率低下。