完整题目
请详细阐述RAG（Retrieval-Augmented Generation）的技术实现方式，并说明其典型应用场景及优势。
本文目录
答案要点
- 能清晰描述RAG的完整技术链路（索引-检索-生成）
- 理解Embedding和向量检索的核心作用
- 能区分Naive RAG与Advanced RAG的关键差异
- 能结合具体场景说明RAG的价值和局限性
RAG核心架构
RAG = 检索模块 + 生成模块，用外部知识弥补大模型参数知识的局限。
1. 索引阶段（离线）
- 文档切分：按语义/固定长度分块，控制chunk大小（通常256-512 tokens）
- 向量化：用Embedding模型（如BGE、text-embedding-3）编码为稠密向量
- 存储：写入向量数据库（Milvus、Faiss、Pinecone），可叠加倒排索引做混合检索
2. 检索阶段（在线）
- Query改写：扩展、澄清用户问题，提升召回率
- 相似度计算：余弦相似度/IP距离，Top-K召回
- 重排序（Rerank）：用Cross-Encoder精排，过滤低质片段
3. 生成阶段
- 上下文组装：检索结果 + 用户Query → 构造Prompt
- 大模型生成：基于检索上下文回答，可引用来源
典型应用场景
| 场景 | 说明 |
|---|---|
| 企业知识问答 | 内部文档、规章制度，解决大模型不知道私域知识的问题 |
| 客服系统 | 基于产品手册实时检索，避免幻觉，答案可溯源 |
| 研报/法律分析 | 长文档摘要+精准定位原文，处理超出上下文长度的材料 |
核心优势 vs 局限
优势
- 知识实时更新：不用重新训练模型，增量更新知识库即可
- 可解释性强：答案有来源引用，便于人工审核
- 成本可控：相比全量微调，RAG实施门槛低
局限
- 检索质量决定上限（"Garbage in, garbage out"）
- 多跳推理、跨文档关联能力弱
- 上下文窗口限制，过多检索结果会稀释注意力
演进方向
- Advanced RAG：查询重写、HyDE（假设文档嵌入）、递归检索
- Modular RAG：与Agent结合，动态决策何时检索、检索什么
换一种问法，检查是否真正理解
场景切入
假设你在做企业内部的智能客服，用户问的很多问题都需要参考最新的产品手册。你怎么让大模型既能实时获取这些手册内容，又不用每次更新都重新训练模型？大概讲下你的技术方案。
层层追问
大模型做问答时，如果知识库更新了，你一般怎么处理？……如果不想微调模型，有没有其他办法让模型能引用外部知识？……那具体怎么把检索和生成结合起来？从索引到搜索再到回答，你一步步说一下。
直球架构
请详细描述RAG的技术实现，包括离线的索引构建和在线的检索生成流程，并说明它的典型应用场景和优势。
练习口述回答 · 约4分钟
- 一句话定位：RAG本质是给大模型配外挂知识库
- 核心链路：离线索引、在线检索、生成组装
- 业务落地：客服退款场景的实战
- 风险与边界：检索质量是天花板，多跳推理弱
- 工程师取舍：我更倾向RAG+微调混合方案
这道题其实是在问，怎么让大模型知道它训练时没见过的东西，同时还能控制答案的准确性和时效性。[[RAG]] 的思路很简单，就是给模型配一个外挂知识库，用的时候先查库，再把查到的内容塞进提示词里让模型回答。
具体说一下链路。离线阶段，先要把文档切成块，块的大小很讲究，太小了上下文不够，太大了噪声多，通常 256 到 512 tokens 之间。然后用 [[Embedding]] 模型转成向量，存到 [[Vector Database]] 里。这里有个取舍：纯向量检索语义好，但对精确匹配比如订单号、错误码很弱，所以落地时我一般会加上 [[BM25]] 做 [[Hybrid Search]]，两条路并行再合并结果。
在线检索时，用户问题来了，先做查询改写，比如把“上个月的退款”扩展成“2025年3月的退款申请”，提升召回率。然后算相似度，取 Top-K，再用 [[Cross-Encoder]] 做 [[Rerank]]，把真正相关的排前面。最后组装成提示词，交给大模型生成答案，同时要求它引用来源。
举个例子，客服系统里用户问“我买的东西降价了，能退差价吗？”如果只靠大模型，它可能瞎编一个政策。用 RAG，我们会先检索知识库中“价保政策”的文档，找到满减规则和申请条件，然后让模型基于这个片段回答，并给出原文链接。这样答案可信，用户也服气。
但 RAG 不是万能的。检索质量直接决定了回答的上限，如果知识库里本身就没存对的信息，或者切分把关键句子切断了，模型再强也白搭。常见失败场景是用户问“为什么昨天能退今天不能退”，这需要跨文档推理，RAG 就很难，因为每段上下文是独立的。另外，检索结果太多会稀释注意力，模型反而抓不住重点。
所以上线前我会特别关注几个前提：一是知识库更新频率，如果每天变，得做好增量索引，避免全量重建；二是查询改写和重排的召回率，至少用一批历史 query 回测，Recall@K 低于 90% 要调参；三是安全过滤，防止检索到涉敏内容。
说到这，其实还有一个进阶方向叫 [[Agentic RAG]]，就是让模型自己决定什么时候检索、检索什么，甚至能调用多个工具，比如先查订单系统再查知识库。但这也带来了新问题，比如工具调用的稳定性和延迟，目前还在探索阶段。
总的来说，我会把 RAG 看作大模型落地的标配能力，但不是银弹。真正复杂的场景，我倾向于 RAG 加微调混合用：RAG 管时效性知识，微调管模型固有的能力。