RAG 架构组件与失败场景
组件功能与实现流程详解,从检索到生成全链路
原题：请详细描述RAG（Retrieval-Augmented Generation）系统的典型架构设计、各组件功能以及完整的实现流程。
重排与优化 · 字节真题
30 秒回答
- 能清晰划分RAG的三大核心模块（索引、检索、生成）并说明各自职责
- 理解Embedding模型的选型考量和向量数据库的选型差异
- 掌握检索策略的演进（从基础到高级RAG）
- 能说明完整的端到端数据流
回答与解析
答案要点
- 能清晰划分RAG的三大核心模块（索引、检索、生成）并说明各自职责
- 理解Embedding模型的选型考量和向量数据库的选型差异
- 掌握检索策略的演进（从基础到高级RAG）
- 能说明完整的端到端数据流
- 提及RAG的典型优化手段（查询重写、重排序、混合检索等）
RAG核心架构：三大模块
1. 索引模块（Indexing）
- 文档处理：加载PDF/网页/数据库 → 文本清洗 → 语义分块（按段落/滑动窗口/语义边界）
- 向量化：Embedding模型（BGE/M3E/OpenAI-ada）将文本转为稠密向量
- 存储：写入向量数据库（Milvus/Pinecone/Elasticsearch），同时保留原始文本用于召回
2. 检索模块（Retrieval）
- 查询优化：查询重写（HyDE生成伪文档）、意图识别、多跳分解
- 检索策略：
- 稠密检索（向量相似度）+ 稀疏检索（BM25）混合
- 多路召回（关键词+向量+图谱）
- 重排序（Rerank）：Cross-Encoder模型精排Top-K，过滤低相关文档
3. 生成模块（Generation）
- 上下文组装：按相关性排序文档，截断至上下文窗口
- Prompt工程：明确指令+检索上下文+用户问题，要求"仅基于上下文回答，不确定则拒绝"
- 后处理：答案溯源（标注引用来源）、幻觉检测、流式输出
完整数据流
用户Query → 查询理解/重写 → 向量检索(Top-K) → Rerank精排 → 上下文拼接 → LLM生成 → 带引用的答案
关键优化点
| 环节 | 典型问题 | 解决方案 |
|---|---|---|
| 分块 | 语义割裂 | 递归分块、语义分块（基于Embedding变化点） |
| 检索 | 长尾Query失效 | 查询扩展、多向量表示（ColBERT） |
| 生成 | 上下文淹没 | 压缩摘要、选择性注入相关片段 |
口语版讲法(约4分钟)
- 一句话定位RAG本质
- 分块与Embedding选型
- 检索策略与混合检索
- 生成环节的上下文组装
- 落地风险与我的取舍
这道题问RAG的架构和流程，其实本质是问你怎么把外部知识可靠地注入到大模型生成里，同时控制幻觉和成本。我理解RAG的核心就三个环节：先把知识切成块并向量化存起来，然后根据用户问题把相关的块捞回来，最后让模型基于这些块来回答。但真正落地的时候，每个环节都有很多坑要踩。
先说索引模块。分块这一步很多人随便按固定长度切，但实际业务里，比如客服退款场景，用户问的是“我退货了但没收到退款”，相关文档可能是一整段流程说明，如果切碎了，模型只拿到半截，答案就会断章取义。我倾向于用语义分块，比如检测段落边界或者Embedding相似度变化点来切，保证每个块语义完整。向量化用Embedding模型，像BGE或者OpenAI的ada，选型前提是看你的领域和语言，中英文混合场景我偏向BGE，因为它对中文支持好。存储用向量数据库，Milvus适合大规模，Elasticsearch适合已经有ES基础设施的团队，这个选择没有绝对好坏，取决于你的运维能力和规模。
再来看检索。这里有个常见误区：只做向量检索。其实很多业务场景，比如搜订单号、错误码，精确匹配比语义更重要。所以我会用混合检索，把BM25关键词检索和向量检索结合起来，两条路都走，然后合并结果。检索完还有一个关键步骤是重排序，用Cross-Encoder模型对Top-K结果精排，这一步能大幅提升召回质量。我见过一个失败案例：只靠向量检索，用户问“满减和折扣能叠加吗”，结果召回了一堆满减规则，但没召回折扣规则，因为“折扣”这个词在向量空间里被稀释了。加上BM25就能直接命中折扣相关文档。
生成环节其实最容易被忽视。把检索到的文档一股脑塞进Prompt，模型很容易被无关信息干扰。我会做两件事：一是按相关性排序，截断到模型上下文窗口的合理比例，比如70%；二是在Prompt里明确指令，要求模型“仅基于提供的文档回答，如果找不到答案就说不知道”，并且输出时带上引用来源。这能有效降低幻觉。
说到幻觉，这里有个延伸点：即使检索做得好，模型也可能自己编。我会在生成后加一层验证，比如用另一个轻量模型检查答案是否忠实于检索文档，或者用Self-RAG让模型自己反思。但这就涉及成本和延迟的权衡了，不是所有场景都需要。
最后说说我的判断。RAG落地的前提是知识库质量够高，如果文档本身错误百出，再好的RAG也没用。所以我会把RAG看作一个系统工程，检索是上限，生成是下限，检索质量决定了你能拿到多好的信息，而生成只是把这些信息组织好。我更倾向于在检索和重排序上多花功夫，而不是在Prompt上雕花。
关键一句:生成后加一层验证（如忠实度检查或Self-RAG）来进一步控制幻觉，但需要权衡成本和延迟。
面试官还可能这样问
- 问法 1 · 场景切入
假设我们做一个电商客服助手，用户问“上次那个订单发货了没”，系统需要从产品文档和订单系统里召回信息。你给我讲讲，从用户提问到生成最终回答，整个RAG系统是怎么一步步把数据拉回来、组织好再输出的？
- 问法 2 · 层层追问
你做过知识库问答系统吧，怎么根据用户问题从文档里捞相关内容的？……那如果文档很长，怎么切分才能既保留语义又提高召回？……检索出来一堆结果，怎么挑出最相关的给大模型？……最后组装prompt有什么讲究？
- 问法 3 · 直球架构
画一下RAG系统的完整架构图，说清楚索引、检索、生成三个模块各自做什么，以及用户查询进来后每一步的数据流和关键组件选型。重点讲讲检索阶段的优化手段，比如查询重写、混合检索、重排序这些。