RAG 架构怎么搭?

30 秒回答

1. RAG整体架构的三阶段流程（索引-检索-生成）
2. 检索器的核心组件（Embedding模型、向量数据库、重排序）
3. 生成器的Prompt工程与上下文融合策略
4. 检索与生成的协同机制（检索结果如何注入生成）

回答与解析

答案要点

• RAG整体架构的三阶段流程（索引-检索-生成）
• 检索器的核心组件（Embedding模型、向量数据库、重排序）
• 生成器的Prompt工程与上下文融合策略
• 检索与生成的协同机制（检索结果如何注入生成）
• RAG的典型优化方向（查询改写、多路召回、Rerank）

RAG典型架构：三阶段流水线

1. 索引阶段（离线）

• 文档切分：按语义/固定长度切分，控制chunk大小（通常256-512 tokens）
• Embedding编码：用BGE、M3E等模型将文本转为稠密向量
• 向量存储：写入Milvus/Faiss/Elasticsearch，构建HNSW索引加速检索

2. 检索阶段（在线）

• 查询理解：可选的Query改写（HyDE、子查询扩展）提升召回
• 向量检索：Top-K近似最近邻搜索，召回候选文档
• 重排序（Rerank）：Cross-Encoder精排，过滤低相关结果

3. 生成阶段

• 上下文组装：按相关性排序，拼接检索文档为上下文
• Prompt设计：明确区分"已知信息"和"用户问题"，约束模型基于检索内容回答
• 生成控制：设置temperature、限制max_tokens，必要时加引用标注

检索器与生成器的协同机制

关键优化方向

• 查询侧：Query2Doc、Step-back prompting扩展查询语义
• 检索侧：稀疏+稠密混合召回（BM25 + Dense），多索引融合
• 生成侧：Self-RAG、Corrective RAG让模型主动判断检索质量

实际落地中，检索质量决定RAG上限，建议优先投入Rerank和Query改写。

口语版讲法(约4分钟)

• RAG本质是给LLM配外脑
• 索引阶段：切块、向量化、存进去的坑
• 检索阶段：Query改写、混合检索、重排序
• 生成阶段：Prompt组装与置信度控制
• 落地取舍与给出可延伸点

我觉得这道题其实就是在问一个核心问题：当大模型知识跟不上业务变化时，怎么低成本给它配个外脑。RAG就是这套方案，它不像微调那样要动模型参数，而是把外部知识塞进上下文里，让模型基于检索结果回答。所以它的架构可以拆成三个环节：先把知识存好，再从里面捞相关片段，最后让模型读着这些片段生成答案。我先说索引。离线阶段最容易被忽视的一个细节是切块。很多人上来就用固定长度切，比如256个token一刀切，但业务文档往往有自然段落，比如客服退款政策里，「退货条件」和「退款时长」写在不同段落，一刀切会把逻辑打断。我一般会优先用语义切分，按标题和段落边界来切，如果文档结构不清晰，再用滑动窗口加重叠，保证每个chunk上下文完整。切完之后用 Embedding 模型转成向量，存到 Vector Database 里。这里有个前提：如果你的知识库是纯关键词匹配场景，比如查订单号或错误码，向量检索反而不好使，因为短文本语义不丰富，这时候 BM25 的精确匹配更靠谱。所以真正落地，我倾向于 Hybrid Search，把稀疏和稠密两条路结合起来。然后说检索。在线阶段用户来了一个query，直接去向量库搜往往不够。比如用户问「退货怎么退」，但库里文档标题是「退款流程」，语义有偏差。所以我会先做一遍 Query改写，用大模型把问题扩写成更完整的表达，或者生成几个假设文档去检索。检索出来Top-K之后，不能直接塞给生成器，因为向量检索的排序不一定是语义最相关的。我会加一层 Rerank，用 Cross-Encoder 对候选文档和query做精细打分，把不相关的滤掉。这个环节成本高，但收益也大，我一般只对Top-30做重排，保留前5个。重排之后还要按token预算动态截断，比如模型上下文只有4K，我就只拿能塞进去的最相关文档。最后是生成。检索结果怎么喂给模型，直接影响回答质量。我会在 System Prompt 里明确说：请基于以下资料回答，如果资料里没有，就回答不知道。同时把检索文档按相关性降序排列，用明确的格式标出每段来源。这里有个常见失败场景：如果检索结果质量差，模型会强行用内部知识补，导致 Hallucination。所以我上线时会特别关注Rerank分数，设一个阈值，低于阈值的直接触发「知识不足」回复，而不是硬答。再一个优化点是多轮对话，上一轮已经查过的内容，下一轮没必要重复检索，可以维护一个检索历史缓存，新的query先和历史做融合，减少延迟。整体来看，检索质量决定了RAG的上限。所以我会把更多精力放在检索侧的Query改写和Rerank上，生成侧反而相对成熟，调好Prompt和温度就行。还有一个延伸方向是让模型自己判断检索质量，比如 Self-RAG 或者 Corrective RAG，模型不仅能基于检索结果生成，还能主动说「这部分资料不够，我需要再查一下」。这个方向其实把RAG从被动喂料变成了主动思考，挺有意思的。

关键一句:让模型主动判断检索质量，比如Self-RAG或Corrective RAG

面试官还可能这样问

1. 问法 1 · 场景切入

   我看了你简历里做过知识库问答。假设用户问‘公司年假政策’，你从文档里找了一段回复他；接着他又追问‘那病假呢？’，你怎么保证第二次回答不是模型自己瞎编，而是继续从文档里找？

2. 问法 2 · 层层追问

   你平时做问答系统，怎么让模型基于外部知识回答而不是靠训练记忆？……那外部知识怎么快速找到和问题相关的段落？……找到了之后怎么把这一段塞给模型，它才会乖乖用这段回答而不是自己发挥？

3. 问法 3 · 直球架构

   请你讲一下RAG的完整架构，从离线索引到在线检索再到生成，每个阶段的关键组件是什么，检索器和生成器之间怎么配合？比如检索结果是怎么注入到生成prompt里的？