为什么AI有时候会"迷路"？—— RAG检索增强生成的工程实践

一个现实问题

你的AI系统回答问题时，经常引用过时的资料、编造不存在的细节，或者干脆说"我不确定"。这不是模型能力不够，而是它被要求做一件不可能的事——记住所有信息，然后准确提取。

现实中的企业数据每天在变化：产品说明更新了，合规条款改了，员工换了联系方式。想让AI实时知道所有信息，唯一可靠的方式不是重新训练模型，而是让它在回答时实时查询最新资料。这就是RAG（检索增强生成）要解决的核心问题。

RAG的基本架构：两步走

RAG系统由两个独立阶段组成：

第一步：索引构建

• 从文档库、数据库、API等来源抽取文本
• 将文本切分为适当大小的片段（通常500-1000字）
• 将每个片段通过embedding模型转为向量（768维至3072维不等）
• 将向量存入向量数据库（如Milvus、Pinecone、Chroma）

第二步：实时检索与生成

• 用户提问时，先将问题转为相同维度的向量
• 在向量库中执行近似最近邻（ANN）搜索，找到最相关的几个片段
• 将原始问题+检索到的片段一起发送给LLM进行回答

关键点：检索环节和生成环节完全解耦。模型不再需要从训练数据中回忆事实，而是从当前数据中获取证据。

工程中的实际挑战

1. 文档切分策略

直接按固定长度切分会导致语义断裂。更好的做法是：

• 按段落/标题自然切分
• 对长文档使用层次化切分（文档级→章节级→段落级）
• 保留片段之间的上下文关联（前一个片段的最后100字作为下一个片段的开头）

2. 检索质量

不是所有检索结果都相关。经验做法：

• 设置检索阈值，过滤相似度低于某值的片段
• 对检索结果做重排序（reranking）：用一个小模型评估每个片段与问题的真实相关性
• 调整top_k（通常5-15个片段），避免信息过载

3. 索引更新延迟

当源文档变更后，向量库需要同步更新。对于高频更新的内容：

• 采用增量更新策略，只更新变更部分的向量
• 或使用批处理窗口（如每小时批量更新一次）

为什么RAG不是万能药

RAG可以显著提升事实准确性，但它有几个固有局限：

1. 检索错误：如果向量库中根本没有包含答案的片段，系统会返回错误或编造内容
2. 上下文限制：即使检索到相关片段，LLM可能无法正确处理多个有冲突的信息源
3. 计算开销：每次请求都要进行embedding+向量搜索，延迟通常增加50-500ms

实际配置建议

对于中小规模企业系统（文档量<10万条）：

• 使用开源方案：LangChain + Chroma + 任意LLM
• Embedding模型：bge-large-zh（中文优化）或 text-embedding-3-small
• 检索策略：top_k=8 + 简单阈值过滤

对于大规模系统（文档量>50万条）：

• 使用商业向量库（Pinecone、Weaviate）
• 多层索引策略：粗筛用快速embedding，精筛用reranker
• 缓存层：对常见查询做结果缓存，减少向量搜索调用

RAG不是让AI更聪明的魔术，而是让AI更诚实的工程。它承认AI的局限性，并用可验证的证据来弥补。

---

原文链接：https://www.smallfiredragon.com/science/rag-engineering-practices-20260727