RAG 的沉默杀手：为什么你的 Chatbot 答非所问，问题根本不在 LLM

RAG 的沉默杀手：为什么你的 Chatbot 答非所问，问题根本不在 LLM

2026 年 9 月 2 日，ByteByteGo 团队放出一篇深度长文，开篇就是一句让所有 RAG 团队后背发凉的反例：产品文档白纸黑字写着「年付订阅 30 天内可退款」，但当客户问「45 天前买的能退吗」，chatbot 自信地回答「可以」[^F01]。

团队的反应通常是：「幻觉，又是 LLM 在编。」

但 ByteByteGo 这次甩出不一样的诊断——这道题不是 LLM 编造的，而是 embedding 模型默默地把"年付订阅"和"退款"相关的段落都拉到了前面，真正包含"30 天内"这个数字限定的那一段，没进 top-k。LLM 只拿到几页相关的抽印本，看不见任何"30 天"字样，就按它的方式生成了一句在它语境下"合理"的答案[^F01]。

这道题里，LLM 不是撒谎，embedding 才是那个沉默的失职者。

embedding 模型是 RAG 的"开卷考试监考"

很多人以为 LLM 是个聪明学生，公司知识库就是它手边的"参考书"。其实 RAG 的真实模型是开卷考试——LLM 是个会写字的学生，但试卷上印的只是它手里那份"挑出来"的资料。embedding 模型是负责"把资料挑哪几页塞到试卷上"的那个监考。

监考挑错了，再会写字的学生也只能写错。

ByteByteGo 给这种角色起了个准确的名字：translator——AI 的翻译器。它把人类语言翻成数学空间里的一串数字（384、768、1024 或几千维），再算 query 与各段落之间的余弦相似度，返回最接近的几段[^F01]。

这套流程有一个被广泛误读的细节：embedding 模型只决定"答什么"，不决定"怎么答"。原文原话是「No matter how good the language model might be, it cannot give correct answers if the embedding model doesn't do its job properly.」[^F01] 换 LLM、加 Reranker、套更好的 prompt——只要 retrieval 漏了正确段落，LLM 永远只能靠"近义推理"补一份不可信的答案。

这条边界一旦被工程团队忽略，所有的优化都会被吸进生成层的黑洞里。

embedding 模型悄悄失败的 7 种模式

ByteByteGo 把工程团队最容易踩的失败模式列成清单，下面按严重性挑出 7 条。每一条都不是"换更大的 embedding 模型"能解决的，是结构性的盲区。

1. 相似主题，不同问题。客户问"退款多久到账"，embedding 拉回来的是"退款资格说明"。两段都在聊退款，但客户问的是时间，不是资格。语义相近但答案不在[^F01]。
2. 同词不同实体。"修改账单地址"被拉成"修改账户邮箱地址"。两段都在聊"修改账户信息"，但一个改钱，一个改信息流[^F01]。
3. 否定反转。"管理员可以删除归档项目"和"管理员不可以删除归档项目"，字面一字之差是"可以/不可以"，embedding 给出的相似度几乎相同，LLM 拿到哪段都"看起来对"[^F01]。
4. 数字决定一切。"30 天内可退款"和"60 天内可退款"，embedding 的向量距离近到几乎不可分。但答案就是错[^F01]。
5. 版本与日期歧义。同一份政策，3 月版本写"年付 30 天"，7 月版本改成"60 天"，向量库如果没标记，embedding 哪个都拉，LLM 看到的是矛盾的两段[^F01]。
6. 领域术语误读。"capture"在通用英文里是"抓住"，在支付场景里是"请款"；"port"在网络、硬件、迁移里各有含义。通用模型在这类术语上几乎必错[^F01]。
7. 多部分问题只取一段。"能取消吗？要多久退款？"是两道题，embedding 通常只回最相似的一段，答案就缺了一半[^F01]。

这 7 类问题共有的特征：人类一眼能区分，但 embedding 模型很难。 工程团队一旦以为"换上更大的模型就好"，就是把锅甩给了最不该背锅的那一层。