AI 实践：传统 ES + LLM vs RAG
2025-08-16
疑问： RAG就是检索增强生成，为什么传统搜索引擎+LLM的简单组合不够，而需要向量检索和上下文融合的复杂架构。
“RAG = 检索增强生成”只是最表层的概念，真正理解 RAG，要能解释清楚为什么不是“搜索引擎 + LLM”这么简单，以及它在技术架构上的独特价值。
下面，展开一下：
1. 为什么“传统搜索引擎 + LLM”不够
- 搜索引擎结果是离散的文本块：
传统搜索基于
关键词或BM25，这类方法只能返回若干篇文档或网页段落。- 它解决的是“找到相关资料”。
- 但对 LLM 来说，这些资料往往过长、噪音大、不结构化。
-
直接拼接输入会导致上下文污染： 如果只是把搜索结果拼接到 prompt，LLM 面临两个问题：
- 长度限制：上下文太长，超出 Token 限制。
- 语义稀释：混杂的信息干扰了 LLM 的推理，可能导致幻觉。
-
搜索引擎不具备语义理解： 关键词搜索无法
理解用户问题的语义。 例如：问：“美国总统出生地是谁？” 关键词检索可能只找到“总统”相关的页面，但并不能理解“出生地”=“location of birth”，而 LLM 又必须自己推断。
2. 为什么要用向量检索
- 语义相似度匹配：
向量检索（
embedding+ANN）能把问题和文档片段投影到同一语义空间。- 不仅能找到包含
关键词的片段，还能找到同义词、上下位关系的相关段落。 - 例如 “CEO” 和 “Chief Executive Officer” 在语义上能被正确对应。
- 不仅能找到包含
- 精细化切片：
文档被预先切分成段落/知识块并建索引。
- 这样能按需召回最相关的小段落，而不是整篇文章。
- 结果更精简，更适合喂给 LLM。
ANN = Approximate Nearest Neighbor （近似最近邻检索）
3. 为什么要做上下文融合（Context Fusion）
-
拼接不是最优解： 直接把 N 个检索到的段落拼接给 LLM，可能导致：
- 上下文不连贯
- 冗余信息浪费 Token
- 多个段落需要逻辑归并
-
融合的目标： 通过 rerank、聚合、摘要、结构化等方式，把检索结果转化为：
- 紧凑的、高相关度的上下文
- 更符合 LLM 消化的 prompt 格式
- 可以附加“来源引用”提升可解释性
4. 这样做的好处
- 降低幻觉率 —— 模型有“知识来源”，而不是硬编。
- 提升相关性 —— 检索结果更贴合语义。
- 可扩展性 —— 新知识加入索引即可，无需重新训练大模型。
- 用户体验好 —— 最终回答通常更可信、可追溯。
5. 总结
RAG ≠ 搜索 + LLM 而是 “语义检索（embedding）+ 知识块选择与融合 + LLM生成” 的完整管线。
原文地址：https://ningg.top/ai-series-es-vs-rag/