RAG 与幻觉 —— 为什么 AI demo 一上生产就开始胡说

本课导读

有一张流传很广的 ByteByteGo 信息图，标题叫 Why AI demo fails in production（为什么 AI demo 一到生产就翻车），列了 8 个原因。这 8 个原因浓缩了过去两年整个行业交的学费，值得逐个拆开讲透——本课先讲数据侧的三个：脏数据、检索失败、数据漂移；下一课讲剩下五个（评测、监控、成本、耦合、级联）。

为了不空对空，全课贯穿一个假想项目：给学径加一个 AI 助教「小径」，用户在课程页提问，它基于课程内容回答。这个项目在你机器上的 demo 一定很惊艳——本课要回答的就是：同一套代码上了生产，为什么会开始一本正经地胡说八道。预计 40 分钟。

先把主角请出来：LLM 为什么需要 RAG

LLM（Large Language Model，大语言模型）就是 Claude、ChatGPT 背后那类模型。它有两个天生缺陷：知识有截止日期（训练完成那天之后的事一概不知），以及不知道你的私有数据（你的课程内容、企业的内部文档，它训练时都没见过）。

想让它回答「学径第三单元讲了什么」，有两条路：

RAG 因此成了绝对主流。它的流程一句话：用户提问 → Retriever（检索器）从知识库里找出最相关的几段 → 拼进 prompt → LLM 基于这几段生成答案。

这里没有魔法，全是你认识的老朋友：知识库入库前要把文档切成小段（叫 chunk，切块）；Retriever 本质上是搜索——最朴素的版本就是关键词匹配，跟 Supabase 的全文检索是亲戚（高级版用「语义向量」找意思相近的段落，Supabase 的 pgvector 扩展干的就是这个）；「拼进 prompt」本质上是字符串模板。RAG = 搜索 + 字符串拼接 + 一次模型调用，demo 版一个下午就能写出来——这正是坑的来源：一个下午能写出来的东西，看起来跟能上生产的东西一模一样。

原因一：demo 数据是盆栽，生产数据是野林

图中第 1 条：Clean demo data vs. messy production data。

你给「小径」做 demo 时喂的是什么？学径的 content/ 目录——每篇 MDX 都是你亲手写的：结构统一、frontmatter 字段齐全、没有乱码没有空值。这是盆栽：单一来源、单一格式、高质量。

企业的生产数据是什么样？信息图里画得很实在：IoT 设备吐的流水、API 拉的 JSON、扫描件 PDF、十年前的 Excel——多个数据流汇进一个数据湖（data lake，把各种原始数据先囤起来的大仓库），schema 互相打架、关键字段一半是 null、同一个客户在三个系统里三种拼法。这是野林。

传统程序遇到脏数据会报错——JSON.parse 直接炸给你看，你还能修。LLM 应用遇到脏数据不报错：检索照样返回、prompt 照样拼、答案照样生成，只是内容悄悄错了。「Garbage in, garbage out」这句老话在 AI 时代升级了：垃圾进，自信的、语法流畅的垃圾出。

原因二：检索错了，模型不会说「我不知道」

图中第 2 条：Retrieval failures cause hallucinations（检索失败导致幻觉）。

幻觉（hallucination）指模型一本正经地编造事实。要理解它为什么发生，记住一个根本设定：LLM 是续写机器——它的目标是生成「看起来最通顺合理」的下一个词，而不是「保证真实」。通顺和真实高度相关但不等价，幻觉就住在这个缝隙里。

RAG 本来是治幻觉的良药：把正确资料塞给模型，它照着说，不用编。但这剂药有个反转——药效完全取决于检索质量：

• 检索对了：模型照着正确资料回答，幻觉大减；
• 检索错了（返回不相关的 chunk，或该找的没找到）：模型面对一堆错误弹药，而它的天性是续写而不是拒答——于是基于错误上下文，用权威的口吻编出一个错误答案。

也就是说，RAG 没有消灭幻觉，而是把「幻觉问题」转化成了「检索质量问题」。检索环节从此成为整条链路的命门。

亲手感受一下检索有多容易跑偏——下面是一个玩具版 Retriever（关键词重叠计分），同一个意思换个问法，检索结果天差地别：

// 玩具版 Retriever：按「提问与 chunk 的重叠词数」打分，取最高分
const chunks = [
"退款政策：课程购买后 7 天内可申请退款，超过 7 天不予退款。",
"优惠政策：新用户注册后 7 天内购课享 8 折优惠。",
"学习打卡：连续学习 7 天可获得一枚徽章。",
];

function retrieve(query: string): string {
const score = (text: string) =>
  [...query].filter((ch) => text.includes(ch)).length;
return chunks.reduce((a, b) => (score(a) >= score(b) ? a : b));
}

// 问法一：用词跟文档一致 → 命中正确 chunk
console.log("问「购买后几天能退款」→", retrieve("购买后几天能退款"));

// 问法二：同一个意思，换成用户的大白话 → 跑偏
console.log("问「买错了想把钱要回来」→", retrieve("买错了想把钱要回来"));

// 跑偏之后，LLM 拿到的是「优惠政策」或「打卡」的内容，
// 它不会说「资料里没有」，而是基于错误资料继续把答案编圆。

demo 时你自己提问，用词自然贴着文档写；上了生产，真实用户的问法千奇百怪——检索命中率骤降，幻觉率随之上升。这就是「demo 惊艳、生产胡说」最常见的技术根源。

原因三：数据漂移——用户在变，模型没变

图中第 6 条：Data drift causes regressions（数据漂移导致回归）。

前两个原因在上线第一天就会暴露，这一个更阴险：上线时一切正常，几个月后悄悄变差。

数据漂移（data drift）：用户行为随时间变化，导致输入的分布（什么样的问题多、用什么词问）逐渐偏离你当初开发和测试时面对的分布。信息图里那两条错开的钟形曲线画的就是这个——重叠的部分越来越少，模型（以及你的检索库、你写的 prompt）针对的还是老分布，质量自然下滑。

放到「小径」上：上线时用户问的都是课程内容；三个月后新增了古诗文 Track，用户开始整句粘贴文言文提问；再后来大家发现它能聊，开始问学习规划——每一波新用法都是你当初没设计过的分布。没有任何代码改动，效果就是变差了。

这揭示了 AI 应用和传统软件一个根本差异：

雷达收束：demo 证明的是能力，生产考验的是覆盖

三个原因合成一句话：demo 证明的是「能力存在」——挑好的数据、贴文档的问法、当下的分布，它确实能答对；生产考验的是「分布覆盖」——脏数据、野问法、漂移后的新场景，它还能覆盖多少。 从「能力存在」到「分布覆盖」之间的距离，就是那句「demo 只花两周，上线用了半年」的半年。

按本 Track 的老方法论——别背案例，记住每层解决什么问题：脏数据对应数据工程，检索失败对应信息检索，漂移对应持续监控与再评估。全是老学科，只是穿了 AI 的新马甲。

那「为什么变差了没人第一时间发现」「为什么账单先于口碑爆炸」？那是图中剩下的五个原因——评测过期、监控失明、token 成本、prompt 耦合、级联失败——下一课接着拆。

够用判断线

一句话总结：RAG = 检索 + 拼 prompt + 模型调用，它把幻觉问题转化为检索质量问题；demo 用盆栽数据证明能力存在，生产用野林数据和漂移的分布考验覆盖，所以 AI 应用没有「做完」只有「持续跟上」。 到这个深度，你已经能看懂 AI 产品讨论里 80% 的黑话，也能对「我们 demo 效果很好」保持恰当的警惕。值得深学的信号：真的动手给学径加 AI 助教那天——届时从 Supabase 的 pgvector 入手做检索，正好接上你已有的技术栈。

随堂测验