完整题目
请阐述你对RAG技术的理解深度，包括其工作原理、优势局限以及在不同场景下的应用考量。
本文目录
答案要点
- RAG(检索增强生成)= 给大模型外挂一个可实时更新的知识库:先检索、再基于检索材料生成
- 核心流程:文档解析 → 分块(Chunk)→ 向量化(Embedding)→ 入向量库;查询时检索 → 重排 → 拼入 prompt 生成
- 优势:知识可实时更新、答案可溯源、幻觉显著降低、不需要重训模型
- 局限:效果强依赖检索质量(切分不当/纯向量检索对 ID 类文本失效),链路长、延迟与成本上升
- 与微调的边界:微调学「格式与风格」,RAG 注「事实与时效」,生产中常两者结合
工作原理
RAG 的本质是把「模型参数里的知识」和「外部知识库」解耦。索引侧:把文档切成语义完整的块(避免固定长度一刀切把条款劈成两半,优先按标题/段落等结构边界切分),做 Embedding 后存入向量数据库。检索侧:纯向量检索对订单号、错误码等专有名词效果差(语义相近但字面不同),生产上采用混合检索(BM25 关键词 + 向量)召回,再用 Cross-Encoder 重排精选前几名,拼入 prompt 交给模型生成。
优势与局限
| 维度 | 优势 | 局限 |
|---|---|---|
| 知识时效 | 文档更新即生效,无需重训 | 依赖知识库维护质量 |
| 可信度 | 可带引用溯源,幻觉降低 | 检索失败时模型仍可能编造 |
| 成本 | 远低于持续微调 | 每次查询多一跳检索,延迟上升 |
场景考量与 RAG × 微调结合
知识频繁更新、需要引用来源的场景(企业 SOP、合规文档、客服工单)首选 RAG;固定格式/语气输出用微调。真实落地常两条腿走路:先微调让模型理解业务术语与对话风格,再用 RAG 注入实时数据。例如电商客服问「退货了但退款没到账」,微调只能背标准流程,RAG 能检索到该用户的退款进度,给出「已审核通过,预计 2 个工作日到账」的具体回答。
入门后可深入:从 Naive RAG 走向查询理解、Agentic RAG 与检索质量评估体系。
换一种问法，检查是否真正理解
场景切入
假设你在做一个企业知识库问答系统，用户提问“今年的报销流程是什么”，系统从文档里检索相关内容再生成回答。你用过RAG方案吧？能聊聊它具体是怎么工作的，以及你觉得在落地时有哪些坑？
层层追问
你平时处理知识密集型问答时，一般怎么让模型利用外部知识？……那如果把检索和生成结合起来，你觉得这种方案有什么优缺点？……在实际业务中，比如客服场景，你会在哪些环节特别注意？
直球架构
请直接谈谈你对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]] 的配合。这个做起来复杂度高不少，但效果也更灵活。