RAG 应用开发背景与问题痛点：从大模型幻觉到检索增强生成

前言

随着大语言模型（LLM）能力的不断提升，越来越多的业务开始尝试将其引入到 知识问答、智能客服、代码助手、企业知识库 等场景中。但在实际落地过程中，开发者很快会发现一个无法回避的问题：

模型看起来"什么都会"，但经常"一本正经地胡说八道"。

这种现象，被称为 大模型幻觉（Hallucination） 。

而 RAG（Retrieval-Augmented Generation，检索增强生成），正是业界用来系统性缓解幻觉、提升可信度和可控性的核心方案之一。

本文将从幻觉问题出发 ，逐步深入到 RAG 的机制、架构与工程化流程 ，帮助你真正理解：
RAG 为什么需要、解决了什么、以及如何在真实项目中落地。

一、为什么需要 RAG：从大模型幻觉说起

1. 什么是大模型幻觉（Hallucination）

幻觉指的是：

模型生成了看似合理、语法正确，但事实错误或凭空捏造的内容。

例如：

• 编造不存在的 API
• 伪造论文、书籍、法规条款
• 回答超出训练知识范围的问题，却依然"信心十足"

本质原因在于：

LLM 是基于概率的语言生成模型，而不是事实检索系统。

2. 幻觉的主要分类

从工程视角，幻觉通常可以分为以下几类：

（1）事实型幻觉（Factual Hallucination）

• 错误的时间、地点、人物、数据

• 编造不存在的业务规则或接口

（2）知识缺失型幻觉

• 问题超出模型训练截止时间

• 企业内部私有数据、文档、代码规范

（3）推理链幻觉

• 推理过程逻辑看似完整，但前提本身是错的

• "因果倒置""强行归因"

3. 幻觉从哪里来？

归根结底，幻觉来源于 LLM 的三个先天限制：

• 参数中存储的是统计相关性，而非可验证事实
• 模型无法访问实时或私有数据
• 生成阶段缺乏"事实校验机制"

即使 Prompt 写得再好，也无法从根本上解决"模型不知道，但仍然要回答"的问题。

4. 缓解幻觉的常见手段（及其局限）

方法	优点	局限
Prompt Engineering	简单直接	无法提供新知识
Fine-tuning	提升领域表达	成本高、更新慢
工具调用（Function Call）	强约束	覆盖范围有限
RAG	动态引入真实知识	工程复杂度更高

RAG 是唯一能在"不改模型参数"的前提下，引入外部真实知识的方案。

5. RAG 的几种典型类型

（1）一次性检索（Single-shot RAG）

• 最常见
• 一次检索 + 一次生成
• 适合 FAQ、知识问答

（2）迭代检索（Iterative RAG）

• 模型根据中间结果多次检索
• 适合复杂问题、多跳推理

（3）事后检索（Post-Retrieval / Verify）

• 先生成，再用检索结果校验或修正
• 常用于高风险场景（金融 / 法律）

二、RAG 基础架构解析

1. 什么是 RAG？

RAG（Retrieval-Augmented Generation） 是一种架构模式，而非单一算法：

在模型生成答案之前，先从外部知识库中检索相关信息，并将其作为上下文输入给模型。

公式化理解：

Answer = LLM( Question + Retrieved Context )

2. RAG 相比"升级大模型"的核心提升点

维度	纯 LLM	RAG
知识更新	重新训练	实时更新
私有数据	不可访问	可控接入
幻觉风险	高	显著降低
成本	高	可扩展

3. 为什么业务系统几乎一定需要 RAG？

• 企业知识 分散、变化频繁
• 数据 不适合也不允许参与模型训练
• 对 准确性、可追溯性、可解释性 有要求

RAG 让 LLM 从"通用聊天模型"进化为"企业级知识引擎"。

4. RAG 的核心优势总结

• 事实可控：回答基于真实文档
• 知识可更新：无需重新训练模型
• 来源可追溯：支持引用原文
• 工程可拆分：检索与生成解耦

三、RAG 的运行流程详解（以用户提问为例）

假设用户提问：

"MySQL 的 redo log 是如何保证事务持久性的？"

Step 1：检索相关知识（Retrieval）

• 将用户问题向量化（Embedding）

• 在向量数据库中进行相似度搜索

• 返回 Top-K 相关文档片段

  Doc1：redo log 的 WAL 机制
  Doc2：InnoDB 崩溃恢复流程
  Doc3：刷盘策略与 checkpoint

Step 2：构建增强提示（Augmented Prompt）

将检索结果组织成结构化 Prompt：

你是一个数据库专家。
请基于以下资料回答问题：

【资料】
1. ...
2. ...

【问题】
MySQL 的 redo log 是如何保证事务持久性的？

这是 RAG 的核心：让模型"有据可依"。

Step 3：生成最终回答（Generation）

• LLM 基于上下文生成答案
• 幻觉概率大幅下降
• 回答更贴近业务真实语义

四、RAG 在实际开发中的数据处理流程

RAG 并不是"接个向量库就完事"，而是一条完整的数据工程链路。

1. 数据连接与加载（Load）

数据来源：

• PDF / Word / Markdown
• 数据库
• Wiki / Confluence
• Git 仓库

目标：将非结构化数据转为可处理文本

2. 数据转换（Transform）

• 文档切分（Chunking）

按段落 / 语义 / Token 数

• 清洗噪声
• 添加元数据（来源、时间、权限）

3. 向量化（Embedding）

• 使用 Embedding 模型
• 将文本映射为高维向量
• 语义相近 → 向量相近

4. 向量存储（Store）

向量数据库：

• FAISS
• Milvus
• Pinecone
• Weaviate

存储内容：

• 向量
• 原文
• 元数据

5. 检索（Retrieve）

相似度搜索（Top-K）

支持：

• 语义检索
• 关键词 + 向量混合检索
• 权限过滤

总结

RAG 并不是为了"让模型更聪明"，而是为了：

让模型在"知道自己不知道"的前提下，基于真实世界的信息作答。

如果说 LLM 决定了"语言能力的上限"，

那么 RAG 决定了应用是否能真正落地到生产环境。