RAG 检索与生成流程详解

30 秒回答

1. 离线知识库构建流程（文档解析、分块、向量化、索引存储）
2. 在线检索生成流程（Query改写、向量检索、重排序、上下文融合）
3. RAG vs 微调的选择权衡
4. 典型应用场景举例

回答与解析

答案要点

• 离线知识库构建流程（文档解析、分块、向量化、索引存储）
• 在线检索生成流程（Query改写、向量检索、重排序、上下文融合）
• RAG vs 微调的选择权衡
• 典型应用场景举例

典型实现方式

离线阶段：知识库构建

• 文档解析：处理PDF/Word/网页等多格式，提取结构化文本
• 文本分块：按语义或固定长度切分，通常256-512 tokens，保留段落边界
• 向量化：用Embedding模型（如BGE、M3E）将chunk转为向量
• 索引存储：存入向量数据库（Milvus、Faiss、Elasticsearch）

在线阶段：检索生成

• Query理解：必要时进行Query改写、扩展、意图识别
• 向量检索：用ANN算法快速召回Top-K相关chunk
• 精排优化：Cross-Encoder重排序，过滤低质量内容
• 上下文融合：将检索结果拼接为Prompt上下文，约束模型生成

技术架构

用户Query → Query处理 → 向量检索 → 重排序 → 上下文组装 → LLM生成 → 输出
                ↓
            [向量数据库] ← Embedding模型 ← 文档知识库

关键组件：Embedding模型、向量数据库、重排序模型、大模型

主要应用场景

• 企业知识问答：内部文档、规章制度、产品手册的智能问答
• 客服系统：基于历史工单和FAQ的精准回复，减少幻觉
• 研报/法律分析：长文档信息抽取与综合分析
• 代码助手：结合私有代码库和开源文档的编程辅助

核心优势

相比微调，RAG无需训练即可更新知识、可追溯来源、成本更低，是知识密集型场景的首选方案。

口语版讲法(约4分钟)

• 本质是知识外挂，解决大模型知识滞后和幻觉
• 离线建库：分块、向量化、索引，关键在分块粒度
• 在线检索：Query改写、ANN检索、重排、融合，Hybrid Search是常态
• 落地风险：重排不能缺、知识更新实时性、Chunk大小影响精度
• 应用场景：企业问答、客服、长文档分析，RAG和微调互补

这道题其实在问，当大模型遇到它不知道或者记不准的知识时，怎么低成本、可靠地给它补上。我的理解，RAG本质上就是给模型配一个外挂知识库，让它能查了再答，而不是凭记忆瞎编。

实现方式分两段，离线建库和在线检索。离线阶段，先把PDF、网页这些原始文档解析成文本，然后切成一块一块的，这叫分块。分块是个很讲究的活，块太大，检索容易漏细节；块太小，上下文又不够。我一般按256到512个token切，保留段落边界，这样语义相对完整。分完块，用Embedding模型把每块转成向量，存进Vector Database，比如Milvus或Faiss。这里有个前提：Embedding模型得跟你的领域匹配，比如法律文档用法律微调过的模型，否则语义距离算不准。

在线阶段，用户来了一个Query，我先做Query理解，有时需要改写或扩展，比如用户说“退钱”，实际意图可能是“退款流程”。然后做ANN检索，从库里召回Top-K个相关块。但光靠向量检索不够，因为语义相似不等于内容相关，所以我会加一道重排，用Cross-Encoder模型精排，把低质量的过滤掉。最后把排好的块拼成Prompt，喂给大模型生成答案。

这里有个坑：很多人以为只靠向量检索就行，但实际场景里，关键词匹配往往能补足向量检索的盲区。比如搜一个产品型号“A100-Plus”，向量可能把它跟“A100”混淆，但BM25能精确命中。所以落地时，我倾向于用Hybrid Search，把向量和关键词两种结果合并，再重排，这样召回率和精度都高。

技术架构其实不复杂，就是一条链：Query进来，经过检索、重排、融合，最后生成。关键组件是Embedding模型、向量数据库、重排模型和LLM。但我想强调的是，重排这一步不是可选项，而是必选项。因为原始检索结果里噪声很多，不重排直接给大模型，它会被无关信息带偏，产生幻觉。

应用场景上，RAG最适合知识密集型任务，比如企业知识问答，内部SOP和规章制度，员工问“年假怎么休”，它能从文档里找到确切条款。还有客服系统，结合历史工单和FAQ，能精准回复退款政策、订单异常这类问题，减少人工介入。再比如研报分析，长文档里抽关键信息，RAG比人翻几百页快得多。

不过，RAG和微调不是二选一，而是互补。比如对高频、固定的知识，微调可以让模型直接记住，省去每次检索的延迟；而对动态更新的知识，比如促销政策，RAG更灵活。所以真正落地的系统，往往是RAG加微调混合用，比如用微调让模型学会理解领域术语，用RAG提供实时知识。

最后说下风险。RAG依赖知识库的质量，如果文档本身有错误或过时，检索出来反而误导模型。所以上线前我会特别关注知识库的更新机制和一致性校验。另外，分块策略直接决定检索精度，块太大会漏细节，块太小会丢上下文，需要根据文档类型调参。

所以我的判断是，RAG不是银弹，但在知识更新频繁、需要可追溯的场景里，它比微调更务实。我更倾向把RAG当成一个可插拔的知识模块，配合微调一起用，而不是二选一。

关键一句:RAG和微调不是二选一，而是互补，实际系统常混合使用。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们要给电商客服做一个知识库问答系统，用户问“退货流程”，系统得从文档里找到答案。你打算怎么把文档里的信息变成可检索的东西？整个流程怎么搭建？

2. 问法 2 · 层层追问

   你做过知识问答类的模型应用吗？……当用户提问时，你是怎么让模型基于私有知识回答的？……那如果知识库里的内容经常要更新呢，你用微调还是检索增强？具体怎么实现？

3. 问法 3 · 直球架构

   请阐述RAG的典型实现方式和技术架构，包括离线知识库构建、在线检索生成流程，以及它主要用在哪些场景，和微调比有什么优缺点？