RAG 解决了 LLM 哪些局限?

这道题其实是在问，当大模型的知识储备不够用时，我们怎么给它外挂一个知识库。[[RAG]]，检索增强生成，说白了就是让模型在做回答之前，先去一个外部知识库里翻一翻，把相关的文档片段找出来，然后带着这些材料去生成答案。这就好比把模型从闭卷考试变成了开卷考试，模型自己负责逻辑推理和语言表达，但事实性的东西，它不用死记硬背，而是现查现用。

它主要解决了两个痛点。第一个是知识静态的问题。大模型一旦训练完，参数就冻住了，训练之后新发生的事它不知道。比如你问它某款产品的最新价格，它可能还停留在半年前的版本。用RAG，你只需要把最新的价格文档扔进知识库，下次查询就能拿到正确信息，不用重新训练模型。第二个是[[幻觉]]问题。模型为了回答流畅，有时候会编造事实。RAG让模型基于检索到的真实文档来回答，大大降低了捏造的概率。而且它还有个附带好处，可解释性。模型回答时可以引用来源，你点开就能看到原文，这在合规审计场景下特别重要。

说到这里，你可能想问，那为什么不直接微调模型呢？这里有个边界划分。微调适合让模型学会某种固定格式或风格，比如把客服回复改成更礼貌的语调；但微调很难注入新的事实知识，而且成本高、容易过拟合。而RAG适合那些知识频繁变动的场景，比如企业内部的SOP、产品手册、政策文档。真正落地的时候，我常常是RAG加微调一起用：用RAG保证事实准确性，用微调优化模型的表达风格和指令遵循能力。

举个例子，客服退款场景。用户问“我买的手机降价了，能退差价吗？”模型需要知道当前公司的售后政策，是7天价保还是15天，具体怎么操作。这些政策可能每月调整，用RAG直接从最新的政策文档里检索相关条款，模型再据此生成回答。如果只靠微调，你每改一次政策就得重训一次，根本不现实。

但RAG落地也有不少坑。前提是你的知识库质量得高。如果文档[[分块]]不合理，检索出来的片段牛头不对马嘴，模型再聪明也没用。常见失败场景是，用户问一个很具体的问题，比如“订单号12345的状态”，但你分块时把整个订单详情页当成一个大块，检索出来一堆无关信息，模型就糊涂了。所以我会特别关注Chunk策略，比如用语义切分而不是固定字数，或者用[[Parent Document]]保留上下文层级。另外，检索本身也不能只靠向量相似度，我通常会把[[Hybrid Search]]，就是向量加[[BM25]]关键词，结合起来，再经过[[Rerank]]重排，才能把最相关的那几段送到模型面前。

再一个，RAG的评估也是个头疼事。你不能只看模型回答得顺不顺，还得看它有没有忠实于检索到的文档，有没有忽略关键信息。我倾向用[[RAGAS]]这类框架做自动化评估，但最终还是得人工抽检。

所以，我会把RAG看成是让大模型在真实业务里落地的必选项，但不是银弹。它解决了知识时效和幻觉的问题，但前提是知识库本身得可靠、检索链路得精细。我更倾向在架构设计时，就预留好知识库的更新机制和检索质量监控，而不是等上线了再补。