RAG 工作原理与架构怎么搭?

检索增强生成系统架构详解,含索引优化与检索策略

原题：请详细解释检索增强生成（RAG）的工作原理、系统架构和关键优化技术。

模型微调 · 字节真题

30 秒回答

RAG核心流程：索引-检索-生成三阶段
向量检索与语义匹配原理
关键优化技术（分块策略、重排序、混合检索）
RAG vs 微调的选择场景

回答与解析

答案要点

RAG核心流程：索引-检索-生成三阶段
向量检索与语义匹配原理
关键优化技术（分块策略、重排序、混合检索）
RAG vs 微调的选择场景
实际落地中的挑战与解决方案

一、RAG核心工作原理

RAG = 检索（Retrieval）+ 生成（Generation），解决大模型知识时效性和幻觉问题。

三阶段流程：

索引阶段：文档切分 → Embedding编码 → 向量数据库入库
检索阶段：用户Query向量化 → 相似度搜索 → Top-K召回
生成阶段：Query + 检索上下文 → LLM生成最终回答

二、系统架构要点

模块	关键技术
文档处理	分块策略（固定长度/语义切分/递归切分）、元数据保留
Embedding模型	通用场景用BGE/M3E，垂直领域需微调；多向量表示（ColBERT）
向量数据库	Milvus、Faiss、Pinecone；考虑HNSW索引、量化压缩
检索策略	稠密检索 + 稀疏检索（BM25）混合；多路召回融合
重排序	Cross-Encoder精排（如bge-reranker），提升Top-K质量

三、关键优化技术

1. 检索侧优化

混合检索：向量语义匹配 + 关键词BM25，用RRF融合排序
查询改写：HyDE（假设文档嵌入）、Query扩展、多跳检索
上下文压缩：LLMLingua、LongLLMLingua，减少token消耗

2. 生成侧优化

重排序后Top-K：精排后取3-5条最相关，避免噪声干扰
引用溯源：让模型输出引用标记，便于事实核查

3. 工程优化

预检索缓存：热门Query结果缓存
增量索引：支持实时数据更新，避免全量重建

四、RAG vs 微调选择

场景	推荐方案
知识频繁更新、需溯源	RAG
需要学习新风格/格式、知识边界模糊	SFT
高频Query、追求极致延迟	RAG+缓存，或SFT蒸馏

实际项目常两者结合：RAG提供实时知识，SFT优化生成风格和领域术语。

口语版讲法(约4分钟)

RAG 本质是给大模型配外挂知识库
索引-检索-生成三阶段，重点在检索质量
优化关键：混合检索、重排、分块策略
RAG 和微调是互补不是替代
落地注意点：数据质量、延迟、一致性

我觉得这道题其实在问一个很实际的问题：怎么让大模型在不知道答案的时候，还能给出靠谱的回复。RAG 的核心思路很简单，就是给模型配一个外挂知识库，需要的时候先去查一下。

先讲工作原理，分成三步。第一步是索引，把文档切碎，转成向量存到 Vector Database 里。这里有个坑，切分策略直接影响检索质量。比如客服退款场景，政策文档经常是一段话里包含多个条件，按固定长度切很容易把完整逻辑切散，导致检索时上下文不完整。我一般会先用语义切分，再结合递归切分兜底，同时保留标题、章节号这些元数据，方便后面溯源。

第二步是检索，用户问个问题，转成向量去库里找最相似的片段。这里有个常见失败场景：纯向量检索对精确数字、产品型号、错误码特别不敏感。比如用户问“订单号 12345 退款失败”，向量检索可能只匹配到“退款失败”的语义，丢了订单号这个精确信息。所以我会用 Hybrid Search，把向量的语义匹配和 BM25 的关键词匹配结合起来，用 RRF 融合排序，召回率能明显提升。

第三步是生成，把检索到的片段和问题一起喂给 LLM。但检索回来的片段不一定全有用，噪声多了反而会干扰模型。所以我一定会加一层 Rerank，用 Cross-Encoder 精排一下，只留最相关的 3 到 5 条，再让模型根据这些片段生成答案，并且要求它输出引用标记，方便事后核对。

说到优化，最核心的其实是检索质量。除了混合检索和重排，还有一个技巧是查询改写。比如用户问“怎么退运费”，直接搜可能匹配不到“退货补贴”这个内部说法，我会用 HyDE 先让模型假设一个理想文档，再用这个假设文档去检索，效果更好。

另外，很多人会纠结 RAG 和 SFT 怎么选。我的看法是，这不是二选一，而是互补。RAG 适合知识频繁更新、需要明确溯源的场景，比如企业 SOP 和合规文档，政策三天两头变，RAG 改个文档就行。SFT 适合学新风格、新格式，比如让模型按特定模板写报告。真正落地常常是 RAG 提供实时知识，SFT 优化生成风格，两者一起上。

最后说下落地风险。一个前提是数据质量必须高，文档本身有错、有矛盾，RAG 反而会放大错误。上线前我会特别关注两件事：一是检索延迟，高频场景下向量检索加重排可能超过 500ms，需要加缓存或者用 HNSW 索引优化；二是数据一致性，文档更新后，旧向量和旧片段要能及时清理或软删除，否则用户会看到过时信息。

还有一个点值得深入，就是怎么评估 RAG 系统的质量。光看单个环节的指标不够，比如检索的 Recall 高不一定生成就好，因为噪声多了反而有害。我倾向用 RAGAS 这类框架，从忠实度、答案相关性、上下文精度几个维度综合打分，同时做 A/B 测试，看实际场景的用户反馈。

所以整体上，我更愿意把 RAG 看作一个工程系统，核心是检索质量和数据质量，模型本身反而没那么关键。

关键一句:RAG 系统的质量评估需要综合忠实度、答案相关性等维度，不能只看单环节指标。

面试官还可能这样问

问法 1 · 场景切入
假设你在做一个电商客服助手，用户问“昨天买的手机什么时候发货”，模型直接去训数据里找肯定不行。你怎么设计一个方案，让模型能实时从订单系统里检索到信息来回答？
问法 2 · 层层追问
大模型怎么解决知识过时和幻觉的问题？……除了微调还有什么方式？……如果用检索增强，你具体会怎么搭这个系统，从文档存进去到最终生成回答，流程是什么样的？
问法 3 · 直球架构
请你详细讲一下RAG的系统架构，从文档索引、向量检索到生成回答，每个环节用了哪些关键技术和优化点？比如分块策略、混合检索、重排序这些，你是怎么选择和调整的？