面试题 · RAG
请详细介绍检索增强生成（RAG）的技术原理、核心组件、工作流程以及在实际应用中的优势和挑战。
RAG（Retrieval-Augmented Generation）将外部非参数化知识与大模型参数化知识结合，解决纯LLM的幻觉、知识时效性和领域适配问题。
1. 索引（Indexing）
学习内容与项目面试，在同一条路上。
2. 检索（Retrieval）
3. 生成（Generation）
用户Query → Query理解/改写 → 向量检索（Top-K）→ 重排序 →
上下文组装 → LLM生成 → 后处理（溯源/拒答）| 维度 | 说明 |
|---|---|
| 时效性 | 知识库实时更新，无需重新训练 |
| 可解释性 | 答案可溯源到具体文档 |
| 成本 | 比全量SFT低几个数量级 |
| 领域适配 | 快速接入私有/专业文档 |
实际落地中，RAG的瓶颈往往在检索质量而非生成，需持续建设评测体系和Badcase分析。
场景切入
我看你做过智能客服。假设用户问了一个产品售后问题，系统需要从几十万条手册里找到答案再生成回复，你会怎么设计这个流程？
层层追问
大模型做问答，知识从哪来？……如果靠训练参数存知识，更新一次太贵了，怎么办？……那检索+生成这个思路，具体怎么把检索结果和生成结合起来？
直球架构
实现一个RAG系统，从索引构建、检索到生成，讲一下核心组件和技术选型。实际落地时有哪些常见的坑？
这道题问的是[[RAG]]，我觉得它本质是在问怎么给大模型配一个可以实时更新的知识外挂，而不是让它死记硬背所有东西。因为纯靠参数记忆，模型既记不住新知识，也容易编造，所以RAG的思路就是把外部知识库当成一个随时可查的参考书，生成的时候先查书再回答。
具体来说，它分三大块：索引、检索、生成。索引就是把文档切成小块，比如按段落或者固定512个token切，然后用 [[Embedding]] 模型转成向量存到 [[Vector Database]] 里，像[[Faiss]]或者Milvus。检索就是拿到用户问题后，也转成向量，去库里找最相似的Top-K个块。生成就是把找回来的上下文和问题拼成提示词，交给大模型生成答案。
但这里有个边界问题。RAG最适合的是事实密集型场景，比如企业内部的SOP、合规文档、或者客服政策。反过来，如果你想让模型改变说话风格，比如变得更幽默，或者学会一个特定任务的行为模式，那微调更合适。真正落地的时候，其实很少只用一种。举个例子，客服场景里，用户问退款政策，你不能让模型瞎编，得从最新的政策文档里检索出准确条款。但如果你还想让模型同时学会礼貌用语，那可能得在基座上做一点微调。所以我的做法是：RAG负责事实准确性，微调负责行为对齐，两者互补。
具体到业务场景，我拿客服退款来展开。用户说“我订单超时了，但商家说不能退”，系统先理解问题，然后检索知识库里的退款规则。这里有个坑：如果规则文档切得太碎，比如“超时30分钟”和“商家同意才能退”被分到两个块，检索可能只找到一个，导致回答片面。所以索引阶段，我会用 [[Parent Document]] 策略，先按大段落切，再细分，检索时拿小片段匹配，但返回大段上下文，保证信息完整。
再说检索。光靠向量检索不够，因为用户可能说“退款流程”，但文档里写的是“退货流程”，语义相近但词不同。所以我会用 [[Hybrid Search]]，向量加 [[BM25]] 关键词，两条路都走，再 [[Rerank]] 精排。这里有个前提：你得有足够好的评测数据，不然你不知道召回率够不够。常见失败场景是，你花很多精力优化生成，但最后发现检索出来就是错的，那大模型再聪明也白搭。所以上线前，我会特别关注检索阶段的Recall@K，用一批历史问题打标，低于90%就不上。
生成阶段也有挑战。比如多文档拼起来太长，超过模型上下文窗口，得压缩或者选最重要的片段。还有就是噪声干扰，检索到相关但误导性的内容，模型可能被带偏。比如用户问“满减能用优惠券吗”，你检索到“满减和优惠券不能叠加”，但模型如果没理解透，可能直接说“能用”。所以我会在提示词里加一句：如果检索内容冲突，优先采用最新政策，并注明来源。
说到这个，其实现在有个更激进的做法叫 [[Agentic RAG]]，就是让模型自己决定什么时候查、查什么、查几次，甚至调用外部工具。比如用户问“我订单异常，是退款还是补发”，模型可以先查订单状态，再查政策，最后给出建议。这个方向能解决多跳推理的问题，但实现起来更复杂，对模型的规划能力要求很高。
所以整体上，我更倾向把RAG看成一个检索工程问题，而不是生成问题。生成模型现在很成熟，瓶颈往往在前面，怎么切文档、怎么建索引、怎么调检索参数。如果让我选，我会把80%的精力放在检索质量上，剩下的用来做端到端的评测和badcase分析。