RAG技术原理检索增强生成如何解决大模型“幻觉”一个让我凌晨三点还在查日志的bug去年秋天我接手了一个智能客服项目。客户要求用大模型回答产品手册里的技术问题。我心想这不就是调个API的事吗结果上线第一天就翻车了——用户问“我们的设备支持5V供电吗”模型自信满满地回答“支持建议使用5V/2A适配器”。但产品手册里明明白白写着“仅支持3.3V供电5V会烧毁主控芯片”。这个回答差点让客户退货。我盯着日志里那段生成文本突然意识到大模型不是数据库它是个“会撒谎的优等生”——知识储备丰富但记错了就编编得还特别像真的。这就是所谓的“幻觉”。而RAG检索增强生成就是给这个优等生配上一本可以随时翻阅的教科书。大模型为什么会产生幻觉先看底层逻辑要理解RAG得先明白大模型是怎么“想”问题的。Transformer架构的本质是概率预测——给定上文预测下一个最可能的token。它没有“记忆”这个概念只有参数里压缩的训练数据分布。举个例子你问“2024年巴黎奥运会中国拿了多少金牌”如果训练数据截止到2023年模型会从“奥运会”“金牌”“中国”这些词的共现模式里拼凑一个答案。它不知道2024年还没到但它知道“中国”和“金牌”经常一起出现于是编一个数字出来。更坑的是模型对高频模式有偏好。训练数据里“5V供电”出现了1000次“3.3V供电”出现了200次模型就会倾向于输出5V——哪怕你的产品手册里写的是3.3V。这就是知识冲突导致的幻觉。RAG的核心把“背诵”变成“开卷考试”RAG的思路很简单不让模型凭记忆回答而是先从一个外部知识库比如你的产品手册、数据库、API返回里检索相关片段然后把检索到的内容作为上下文和问题一起喂给模型生成答案。这个流程拆开来看有三个关键环节1. 文档切分别把大象塞进冰箱第一个坑就是文档切分。我见过有人把整本产品手册200页PDF直接塞进向量数据库结果检索出来的片段要么太长包含大量无关信息要么太短关键信息被截断。我的经验法则按语义段落切分每个chunk控制在200-500个token。为什么是这个范围因为大模型的上下文窗口虽然越来越大GPT-4有128K但检索出来的片段如果太长模型会“迷失”在无关信息里。我踩过的坑是切了1000 token的chunk结果模型把两个不同章节的内容混在一起回答。切分时还要考虑重叠。比如每个chunk之间重叠50个token避免关键信息正好落在切分边界上。这个细节我是在调试“设备工作温度范围”这个问题时发现的——答案里的“-20°C”正好被切分线劈成两半。2. 向量化与检索别用关键词匹配用语义传统搜索引擎靠关键词匹配但用户问“怎么给设备降温”和文档里写的“散热方案”是同一个意思关键词匹配就抓瞎了。RAG用的是向量检索——把文本转换成高维向量然后找语义上最接近的。这里有个容易翻车的地方embedding模型的选择。别用通用embedding去处理专业领域文档。我试过用text-embedding-ada-002检索医疗设备手册结果“心率监测”和“脉搏检测”的向量距离居然比“心率监测”和“电池续航”还远。后来换了一个在医疗语料上微调过的embedding模型召回率直接翻倍。检索数量也是个玄学。我一般设top_k3到5。太少可能漏掉关键信息太多会让模型“选择困难”——它会在多个片段里挑一个最顺眼的反而忽略正确答案。有一次我设了top_k10模型从第7个片段里捡了个错误信息因为那个片段和问题的字面匹配度最高。3. 生成阶段给模型“划重点”检索到的片段不是直接拼起来就完事。你需要设计一个提示词模板告诉模型“以下是从知识库中找到的相关信息请基于这些信息回答问题不要使用你自己的知识”。别这样写根据以下内容回答问题{context}这样写模型还是会偷偷用自己的知识。我踩过坑之后改成这样你是一个严格遵循给定文档的助手。以下是从产品手册中检索到的内容。如果这些内容不足以回答问题请直接说“无法从手册中找到相关信息”不要自行补充。如果内容中有矛盾请指出矛盾点。 检索内容 {context} 用户问题{question}注意那个“如果内容中有矛盾”的指令——这是专门对付多个chunk之间信息冲突的情况。有一次两个chunk分别写了“设备支持WiFi 5”和“设备支持WiFi 6”模型直接指出矛盾而不是自己选一个。一个完整的RAG调试案例回到开头那个5V供电的问题。我当时的调试过程是这样的第一步检查检索结果。发现检索到的top-3片段里有两个是关于“电源适配器规格”的通用描述写了5V/2A只有一个提到了“主控芯片供电要求”写了3.3V。问题出在embedding模型把“供电”和“适配器”关联得太强。修复在切分阶段把“电源适配器”和“主控芯片供电”强制分到不同章节并给每个chunk打上元数据标签比如“章节电源系统”。检索时加入元数据过滤只检索“电源系统”章节。第二步检查生成结果。发现模型在生成时虽然看到了3.3V的信息但还是输出了5V。为什么因为训练数据里“5V供电”的模式太强了模型“惯性”太大。修复在提示词里加了一句“如果检索内容与你的常识冲突请以检索内容为准”。同时把温度参数从0.7降到0.1减少模型的“创造性”。第三步加一个验证环节。生成答案后用另一个模型或者同一个模型但用不同的提示词做一次“事实核查”——把答案和检索内容对比标记不一致的地方。这个环节帮我抓到了不少漏网之鱼。个人经验RAG不是银弹但比微调靠谱很多人问我RAG和微调哪个好我的答案是能用RAG解决的问题别碰微调。微调相当于让模型“记住”你的知识但代价是灾难性遗忘——模型可能会忘记它原本知道的常识。而且每次知识更新都要重新微调成本太高。RAG是“即插即用”的换一个知识库就行。但RAG也有自己的坑检索失败是最大的幻觉来源。如果检索不到相关信息模型就会回到“自由发挥”模式。所以一定要做好“检索不到”的兜底逻辑——要么返回“无法回答”要么触发二次检索比如换一个embedding模型重试。上下文窗口不是越大越好。我见过有人把整个知识库都塞进上下文结果模型在几万token里迷失方向回答质量反而下降。RAG的精髓是“精准检索”不是“暴力堆砌”。别忘了做评估。我维护了一个测试集包含100个典型问题每次修改RAG流程后都跑一遍看准确率变化。没有评估的RAG优化就是盲人摸象。最后说一句RAG解决的是“知识来源”问题不是“推理能力”问题。如果你的模型本身逻辑混乱RAG也救不了。先确保基座模型够强再谈检索增强。