大模型的“一本正经胡说八道”到底怎么治？RAG技术给出了一个很实际的答案。下面会聊几个关键点：大模型为什么会产生幻觉，RAG是怎么通过检索+生成来降低错误率的，以及向量数据库为什么比传统数据库更适合这个场景。
写在前面
在正式介绍RAG之前，先聊聊大模型的一个普遍问题。用过ChatGPT、DeepSeek、豆包、文心一言这些产品的人应该都有体会——有时候大模型会一本正经地给你一个离谱答案，语义不通、前言不搭后语。
举个例子：你问大模型“美国成立时间”。它可能回答：美国成立于1997年，距今已有400年历史……这种荒谬回答在业内有个专业术语——hallucination，幻觉。本质上，大模型的工作机制就是不断预测下一个词该是什么，然后挑概率最大的那个输出。既然只是概率游戏，出错就在所难免。
产生幻觉的原因很多，比如训练数据本身的问题、过拟合、微调导致的知识丧失、推理机制不完善等等。而今天要聊的RAG，核心目标就是降低大模型出现幻觉的概率。下面进入正题。
RAG简介
RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合信息检索与文本生成的技术，用于提升大语言模型在回答专业问题时的准确性和可靠性。
它的核心原理可以拆成两步：检索 + 生成。
- 检索阶段：把用户的问题转化成向量，从外部知识库（通常是向量数据库）里快速找到相关片段。
- 生成阶段：把检索到的信息喂给大模型，结合上下文生成具体回答。
这么说可能有点抽象，打个比方：大模型考试遇到陌生领域，只会写个“解”字（因为它训练数据里没这题），然后就开始放飞自我了。这时RAG递过来一张小抄，大模型一看，哦原来往这个方向答，正确率从60%飙升到90%！
说白了，这就是开卷考试！那么问题来了：开卷考试，卷子从哪来？这里就引出了向量数据库。为什么非得是向量数据库？传统数据库不行吗？
向量数据库
向量数据库的核心思想是：把文本转化成向量，然后基于语义相似度做快速检索，解决了传统关键词匹配无法捕捉上下文关联的问题。
如果用传统数据库（比如MySQL）做关键词检索，根本无法理解语义，很容易漏检或误检。举个例子，搜索“2024年腾讯的技术创新”：
- 向量数据库能匹配到语义相近但没出现“腾讯”这个词的文档（比如“WXG的研发进展”）
- 传统数据库只能匹配到包含“腾讯”关键词的内容
那向量数据库凭什么知道语义相近？关键在于它存的是向量，不是人看的文本。文本经过Embedding模型变成一串浮点数，计算机就能用余弦相似度这类数学公式来量化语义距离。传统数据库直接拿原始文本匹配，同义词、多义词、语境差异都处理不了（比如“苹果”到底是水果还是公司）。也正是这个原因，很多传统搜索系统需要先做query改写去提高精度。当然，不只是文本，万物皆可embedding——图片、视频、音频都可以。
RAG 过程
回到最开始的例子，整个流程是这样的：
- 用户对大模型提问：“美国的成立时间”
- 通过Embedding模型把文本转成向量
- 到向量数据库中搜索语义相近的内容
- 向量数据库返回TopK结果（比如Top 100）
- 再用重排序模型进一步筛选出Top N（比如Top 10）
- 把搜索结果和用户的原始查询拼成一个完整的prompt，一起交给大模型
- 大模型根据这些输入和自身知识生成最终回答
这个流程能有效约束大模型输出，让它尽可能给出相关且语义一致的内容。
那么向量数据库怎么构建？其实不复杂：
- 把文章切分成多个chunk（也就是把长文本拆成小段）
- 对每个chunk进行向量化
- 存到向量数据库里
这里为什么要做chunking？chunking的目的是把语义相似的token聚在一起，把语义不同的token拆开。长文档中不同段落的语义差异可能很大，如果把整个文档作为一个整体去检索，会导致语义杂糅，影响效果。切分成小块后，每个小块内部表意一致，块之间表意多样，检索效果才会好。所以chunk太小会错过真正相关的内容，太大又会导致搜索结果不精准——这个平衡点需要根据实际场景来调试。