跳到正文

RAG 检索器与生成器如何协同？

检索器与生成器协同流程,实现细节全解析

原题：请详细描述RAG（检索增强生成）系统的典型架构和实现流程，包括检索器、生成器以及两者如何协同工作。

重排与优化 · 美团真题

30 秒回答

  1. 清晰描述RAG三阶段流程（索引-检索-生成）
  2. 说明检索器核心组件（向量化、相似度计算、Top-K召回）
  3. 解释生成器如何利用检索结果（上下文拼接、注意力机制）
  4. 提及关键优化点（重排序、查询改写、多路召回）

回答与解析

答案要点

  • 清晰描述RAG三阶段流程（索引-检索-生成）
  • 说明检索器核心组件（向量化、相似度计算、Top-K召回）
  • 解释生成器如何利用检索结果（上下文拼接、注意力机制）
  • 提及关键优化点（重排序、查询改写、多路召回）
  • 能对比Naive RAG与Advanced RAG的差异

RAG核心架构：两阶段流水线

第一阶段：离线索引构建

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

第二阶段：在线检索生成

模块 职责 关键技术
检索器 从知识库召回相关文档 稠密检索（向量相似度）+ 稀疏检索（BM25）混合
重排序器 精排Top-K结果 Cross-Encoder（如bge-reranker）
生成器 基于检索上下文生成答案 大模型+Prompt工程，控制幻觉

协同机制——上下文融合

用户Query → 检索Top-K文档 → 拼接Prompt模板：
"基于以下参考资料回答问题：[文档1]...[文档K]\n问题：{Query}\n答案："

→ LLM生成（检索内容通过Attention与Query交互）

关键优化策略

  • 查询改写：用LLM扩展同义问法，解决语义Gap
  • 多路召回：向量检索 + 关键词检索 + 图谱检索并行
  • 引用溯源：要求模型输出引用标记，便于事实核查

Naive vs Advanced RAG

  • Naive：直接检索→拼接→生成，容易噪声干扰
  • Advanced：加入重排序、查询分解、迭代检索（如Self-RAG），显著提升准确率

口语版讲法(约4分钟)

  • 一句话定位：RAG本质是给大模型配外挂知识库
  • 离线索引：切分、向量化、存储，chunk大小是关键
  • 在线流程：检索、重排、生成，混合搜索是标配
  • 落地风险：噪声敏感、时效性差、改写成本高
  • 判断取舍：先查后写，Retrieval比Generator更值得调

这道题其实是在问，怎么让大模型不靠训练数据里的记忆，而是实时从外部知识库里查东西来回答问题。说白了，就是给模型配一个外挂知识库。整体流程分两步走，先离线建索引，再在线跑检索加生成。

先说离线索引。原始文档不能直接喂给模型，得先切块。切多大？我一般控制在256到512个token，太小上下文不够，太大噪声多。然后用 Embedding 模型转成稠密向量，存到 Vector Database 里，常用 Faiss 或 Milvus，建 HNSW 索引加速搜索。这里有个坑：chunk之间的重叠怎么处理？我会把零重叠、短窗口与较长窗口放进同一组实验，根据边界证据完整率、召回与成本选择。

再在线流程。用户来了一个 query，先检索。我基本不会只用向量相似度，因为纯语义检索对专有名词、ID号这些不敏感，所以会做 Hybrid Search，向量检索加 BM25 关键词检索并行，结果合并后再用 Cross-Encoder 做一次 Rerank，把真正相关的文档排到前面。这一步很关键，能过滤掉很多语义相似但实际无关的噪声。举个例子，客服场景里用户问“我退款怎么还没到”，向量检索可能召回一堆退款政策文档，但真正需要的是该笔订单的处理状态，这时候 Rerank 能把带订单号的文档顶上来。

然后生成。把召回的结果拼成 prompt，格式大概是“基于以下资料回答问题：文档1...文档K。问题：xxx。答案：”。这里有个前提，就是 prompt 模板要设计好，明确告诉模型只能基于资料回答，不然模型容易自由发挥，产生 Hallucination。而且我会要求模型输出引用标记，比如 [1][2]，方便事后溯源。

再说说落地时我特别关注的几个风险。先看噪声敏感：如果检索到的文档里混了不相关的内容，模型会被带偏。所以我会在 Rerank 阶段设一个置信度阈值，低于0.3的直接丢掉，宁可少给也别给错的。再看时效性问题：知识库如果一天一更新，用户问“今天有什么优惠”，模型还是拿昨天的政策回答。所以对于高频变化的数据，比如库存、价格，我会用 Agent 配合 Function Calling 实时查数据库，而不是走静态索引。还要看查询改写成本：用户 query 经常很短或者有歧义，比如“怎么退”，需要先让模型扩写成“退货流程是什么”，但这会多一次 LLM 调用，延迟和成本都要考虑。

其实 Naive RAG 和 Advanced RAG 的核心区别不在于索引，而在于检索策略。比如 Self-RAG 让模型自己判断是否需要检索、检索结果是否够用，不够就迭代检索多次。这个方向我觉得比单纯优化 Embedding 模型更有价值，因为它解决了“什么时候该查、查几次”这个根本问题。

所以整体上，我更倾向把 RAG 看作一个检索优先的系统，生成器只是把检索结果包装成自然语言。如果检索质量不够好，再强的生成器也救不了。上线前我会用 RAGAS 指标专门测检索的 Context Precision 和 Context Recall，确保召回的东西既精准又全面。

关键一句:Naive RAG和Advanced RAG的核心区别在于检索策略，比如Self-RAG让模型自己判断是否检索及迭代次数。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你正在做一个电商客服助手，用户问“这个手机怎么样”，系统得从产品手册里找信息来回答。如果手册有几千页，你怎么从中快速找出相关段落，然后让大模型基于这些段落生成答案？说说整体流程。

  2. 问法 2 · 层层追问

    现在有个常见做法是先检索再生成，你了解吧？……那检索这一步具体怎么做的？……用户query和文档怎么匹配？……如果检索结果不相关，生成器会受影响吗？你怎么保证最终答案准确？

  3. 问法 3 · 直球架构

    请详细讲一下RAG系统的架构和实现流程，包括离线索引怎么建、在线检索生成怎么配合，还有检索器和生成器之间怎么协同的？最好能提到一些优化点，比如重排序、查询改写这些。

同模块相关题目