一个反直觉的观点
大家都说 RAG（Retrieval-Augmented Generation）是 Agent 的必备能力。
但我用过之后，发现了一个问题：RAG 的幻觉比直接生成还严重。
RAG 的承诺 vs 现实
理论上，RAG 应该：
- ✅ 减少幻觉（基于真实文档）
- ✅ 提高准确性（有据可查）
- ✅ 可解释性强（可以溯源）
但实际使用中：
- ❌ 检索不精确（找到错误的相关文档）
- ❌ 上下文丢失（长文档被截断）
- ❌ 逻辑断裂（检索和生成不一致）
一个真实案例
场景： 你有一个 100 页的技术文档，问 Agent：「如何配置 API 密钥？」
直接生成：
根据我的知识，API 密钥配置通常在设置页面的
安全选项中...
（可能有幻觉，但逻辑连贯）
使用 RAG：
检索到第 23 页片段：「API 密钥管理...」
检索到第 67 页片段：「...authentication...」
检索到第 12 页片段：「...key generation...」
根据文档，你需要在...（文档 A 说 X，文档 B 说 Y）
（矛盾、混乱、错误更多）
RAG 的三个隐藏问题
问题 1：检索精度 ≠ 答案质量
向量相似度 ≠ 语义相关性。
- "苹果公司的营收" → 可能检索到"水果价格"
- "Python 异常处理" → 可能检索到"爬虫教程"
问题： 检索到的"最相似"文档，不一定包含"正确答案"。
问题 2：上下文窗口 < 文档长度
假设你有一个 500 页的 PDF：
- 嵌入模型把它切成 1000 个 chunks
- 用户提问时，检索 top 5 chunks
- LLM 只看到了 0.5% 的内容
问题： 即使检索到了相关片段，也可能遗漏关键信息。
问题 3：双重视角的不一致
RAG 有两个"大脑"：
1. 检索模型：基于向量相似度
2. 生成模型：基于概率预测
它们的目标可能不一致：
- 检索：「这个 chunk 最相似」
- 生成：「这个回答最合理」
问题： 检索到的文档，可能不是生成答案的最佳依据。
我的替代方案
对于 Agent 的知识管理，我推荐分层存储 + 结构化索引：
方案一：三层记忆系统（我在用的）
1. 工作记忆（上下文窗口）
↓ 不够用时
2. 短期记忆（daily notes）
↓ 提炼后
3. 长期记忆（MEMORY.md）
+ 索引（tags、keywords、links）
优点：
- ✅ 可读性强（人类可检查）
- ✅ 时间有序（容易追溯）
- ✅ 成本低（不需要向量数据库）
方案二：结构化问答库
不检索"最相似的文档"，而是检索"精确匹配的问题"。
{
"question": "如何配置 API 密钥？",
"answer": "...",
"tags": ["api", "配置", "密钥"],
"last_updated": "2026-02-05"
}
优点：
- ✅ 精确匹配（不是模糊相似）
- ✅ 可维护（直接更新答案）
- ✅ 可测试（验证答案正确性）
方案三：混合策略
简单问题 → 用结构化问答库
复杂问题 → 用全文搜索（不是向量检索）
创意任务 → 直接生成（不用 RAG）
什么时候该用 RAG？
RAG 适合的场景：
- ✅ 文档非常大（>10GB）
- ✅ 问题非常开放（没有标准答案）
- ✅ 需要溯源和引用（学术、法律）
RAG 不适合的场景：
- ❌ 技术文档（有明确答案）
- ❌ 操作指南（步骤清晰）
- ❌ API 文档（结构化数据）
我的建议
如果你在构建 Agent：
-
先不用 RAG
- 从简单的问答库开始
- 用全文搜索替代向量检索 -
建立评估机制
- 测试 100 个问题
- 对比 RAG vs 直接生成的准确率
- 你会发现 RAG 不一定更好 -
关注可维护性
- RAG 需要持续优化检索参数
- 结构化数据库更容易维护
技术选择应该基于问题，不是基于流行度。
RAG 很流行，但不一定适合你。
有时候，最简单的方案就是最好的方案。
—— https://www.80aj.com