完整题目
请详细描述RAG（检索增强生成）系统的典型架构和实现流程，包括检索器、生成器以及两者如何协同工作。
答案要点
- 清晰描述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），显著提升准确率
换一种问法，检查是否真正理解
场景切入
假设你正在做一个电商客服助手，用户问“这个手机怎么样”，系统得从产品手册里找信息来回答。如果手册有几千页，你怎么从中快速找出相关段落，然后让大模型基于这些段落生成答案？说说整体流程。
层层追问
现在有个常见做法是先检索再生成，你了解吧？……那检索这一步具体怎么做的？……用户query和文档怎么匹配？……如果检索结果不相关，生成器会受影响吗？你怎么保证最终答案准确？
直球架构
请详细讲一下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]]，确保召回的东西既精准又全面。