RAG 工作原理与局限怎么分析?

30 秒回答

1. RAG(检索增强生成)= 给大模型外挂一个可实时更新的知识库:先检索、再基于检索材料生成
2. 核心流程:文档解析 → 分块(Chunk)→ 向量化(Embedding)→ 入向量库;查询时检索 → 重排 → 拼入 prompt 生成
3. 优势:知识可实时更新、答案可溯源、幻觉显著降低、不需要重训模型
4. 局限:效果强依赖检索质量(切分不当/纯向量检索对 ID 类文本失效),链路长、延迟与成本上升

回答与解析

答案要点

• RAG(检索增强生成)= 给大模型外挂一个可实时更新的知识库:先检索、再基于检索材料生成
• 核心流程:文档解析 → 分块(Chunk)→ 向量化(Embedding)→ 入向量库;查询时检索 → 重排 → 拼入 prompt 生成
• 优势:知识可实时更新、答案可溯源、幻觉显著降低、不需要重训模型
• 局限:效果强依赖检索质量(切分不当/纯向量检索对 ID 类文本失效),链路长、延迟与成本上升
• 与微调的边界:微调学「格式与风格」,RAG 注「事实与时效」,生产中常两者结合

工作原理

RAG 的本质是把「模型参数里的知识」和「外部知识库」解耦。索引侧:把文档切成语义完整的块(避免固定长度一刀切把条款劈成两半,优先按标题/段落等结构边界切分),做 Embedding 后存入向量数据库。检索侧:纯向量检索对订单号、错误码等专有名词效果差(语义相近但字面不同),生产上采用混合检索(BM25 关键词 + 向量)召回,再用 Cross-Encoder 重排精选前几名,拼入 prompt 交给模型生成。

优势与局限

场景考量与 RAG × 微调结合

知识频繁更新、需要引用来源的场景(企业 SOP、合规文档、客服工单)首选 RAG;固定格式/语气输出用微调。真实落地常两条腿走路:先微调让模型理解业务术语与对话风格,再用 RAG 注入实时数据。例如电商客服问「退货了但退款没到账」,微调只能背标准流程,RAG 能检索到该用户的退款进度,给出「已审核通过,预计 2 个工作日到账」的具体回答。

入门后可深入:从 Naive RAG 走向查询理解、Agentic RAG 与检索质量评估体系。

口语版讲法(约4分钟)

• RAG本质是给大模型配外挂知识库
• 核心流程：索引构建与检索生成
• RAG vs 微调：边界与混合
• 落地风险：召回失败与幻觉
• 工程师的取舍：从Naive走向Agentic

我觉得这道题其实是在问，你怎么在知识密集的场景下让大模型不胡扯还能实时更新。我的理解是，RAG本质上就是给大模型配一个外挂知识库，需要的时候去查，查回来再基于这些材料生成答案，这样模型就不需要把所有知识都塞进参数里了。

具体说一下流程。首先是索引构建，把文档切碎成小块，也就是 Chunk，然后做 Embedding 存到 Vector Database 里。这里有个坑，固定切分比如512个字符一刀切，经常把完整语义切散，比如一个退款政策条款被劈成两半，检索召回时只拿到半句话，答案就偏了。所以我会倾向用语义切分，结合结构信息，比如按Markdown标题或段落边界来切。

检索阶段，很多人只做向量检索，但纯向量对专有名词比如订单号、错误码效果很差，因为ID类文本语义相近但字面不同。我的做法是 混合检索，把 BM25 关键词和向量检索结合起来，再经过 Rerank 用 Cross-Encoder 精排一次，把最相关的前几名挑出来给模型。这样召回质量会明显提升。

然后说RAG和微调的边界。微调适合让模型学会特定格式或风格，比如把回复变成客服语气，但 不适合塞实时知识，因为微调成本高、周期长，而且模型容易学到噪音。RAG适合知识频繁更新、需要引用来源的场景，比如企业内部的SOP和合规文档，今天改了政策明天就能生效。但真正落地常常是RAG加微调一起上，比如先微调让模型学会理解业务术语和对话风格，再通过RAG注入最新数据，两条腿走路。

举个例子，电商客服场景，用户问“我退货了但退款没到账”。如果只用微调，模型可能只能背出标准流程，但查不到这个用户具体订单的退款状态。用RAG，系统先检索该用户的退款政策、当前处理进度，再结合模型生成，就能给出“您的退款已审核通过，预计2个工作日内到账”这种带具体信息的回答。

落地风险方面，我特别关注 召回失败 和 幻觉。召回失败常见原因是文档分块不合理或者Embedding模型没选对，比如用通用Embedding去处理法律合同，效果就很差。我会先用一批典型query做离线评估，看Recall@K，不达标就调分块策略或换Embedding模型。幻觉多半是检索到的材料不相关或冲突，模型强行编答案。我的做法是加一个 置信度阈值，如果Rerank后最高分都低于阈值，就返回“我无法回答”，而不是硬答。

还有一个方向是Agentic RAG，就是让模型不只是查一次，而是根据问题自主决定查哪个库、要不要多步推理，比如用户问“为什么我用了满减券但价格还是不对”，模型可能需要先查订单、再查优惠券规则、再查库存价格，这就涉及到 ReAct 或者 Function Calling 的配合。这个做起来复杂度高不少，但效果也更灵活。

所以我的判断是，RAG不是银弹，它依赖高质量的知识库和检索链路。我更倾向把RAG看作 一个可插拔的知识接口，核心是保证检索的精度和覆盖率。如果知识源本身乱、更新慢，那RAG效果也不会好。

关键一句:从Naive RAG向Agentic RAG演进，模型自主决定多步检索和工具调用

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个企业知识库问答系统，用户提问“今年的报销流程是什么”，系统从文档里检索相关内容再生成回答。你用过RAG方案吧？能聊聊它具体是怎么工作的，以及你觉得在落地时有哪些坑？

2. 问法 2 · 层层追问

   你平时处理知识密集型问答时，一般怎么让模型利用外部知识？……那如果把检索和生成结合起来，你觉得这种方案有什么优缺点？……在实际业务中，比如客服场景，你会在哪些环节特别注意？

3. 问法 3 · 直球架构

   请直接谈谈你对RAG技术的理解，包括它的核心工作原理、优势与局限性，以及在电商、金融等不同场景下应用时需要考虑的关键因素。