RAG 的完整工作流程是怎样的？核心步骤有哪些？
这道题考的是 RAG（检索增强生成）的全链路理解。面试官想看你能不能把"先查资料、再生成答案"这件事讲清楚，不只是背步骤，要理解每个环节为什么存在。
我从四个方面来讲：RAG 是什么、核心四步骤、三阶段演进、以及面试加分项。
RAG 是什么？
RAG = Retrieval-Augmented Generation，翻译过来就是检索增强生成。
听起来高大上，其实原理很简单。想象一下开卷考试：你不是靠脑子里的记忆硬写，而是先翻书找相关资料，再根据找到的资料组织答案。RAG 就是这个思路。
大模型不是万能的。 它有知识截止日期，训练完以后的新东西它不知道。它还会一本正经地胡说八道，我们叫"幻觉"。RAG 就是来解决这个问题的——让模型先从你提供的知识库里查资料，再基于查到的内容回答。
这样有什么好处？
- 答案有据可查，不是凭空编的
- 知识库可以随时更新，不用重新训练模型
- 回答可以引用具体的文档段落
整个 RAG 系统就三个关键组件：检索模块、向量数据库、LLM。检索模块负责找相关资料，向量数据库负责存和查，LLM 负责生成答案。
核心工作流程四步骤
这部分是重点，也是面试必问的。
第一步：文档拆分（Chunking）
你得先把长文档切成小块。为什么？因为大模型上下文有限，你不可能把整个知识库都塞进去。而且太小也没意义，找了半天找不到重点。
切块的核心难题是：太大vs太小。
太大了，语义太杂，检索的时候不好匹配。比如把整本书塞进去，用户问"第三章讲的什么"，模型根本不知道从哪找。
太小了，语义不完整，可能丢失关键信息。比如把一句话拆成两半，两半单独看都不知道在说啥。
常见的切块策略：
- 固定长度切块，比如每 512 个 token 一段
- 按语义段落切，按自然段落来
- 递归切块，先按大段落，不够再按小段落
- 用大模型来辅助切，让它判断哪里该切
实际项目中，切块策略直接影响效果。很多人 RAG 效果不好，第一反应是调模型参数，其实往往问题出在切块上。
第二步：向量化（Embedding）
切好的文本块要转成向量。简单说就是：文本 → 一串数字
这串数字代表这段文本的"语义位置"。语义相近的文本，向量也相近，在高维空间里距离近。
这个转换过程叫 Embedding，用的模型叫 Embedding Model。比如 OpenAI 的 text-embedding-ada-002，或者开源的 BGE、M3E。
向量维度常见的有 768、1024、1536、3072。维度越高表达能力越强，但存储和计算成本也越高。
第三步：向量存储
转好的向量要存到向量数据库里。常见的向量数据库有：
- Milvus：开源分布式方案，生产级用得多
- pgvector：PostgreSQL 插件，如果你已经用 PG 很方便
- Faiss：Facebook 出品，适合单机小规模
- ES（Elasticsearch）：8.0 版本支持向量，很多公司 Elasticsearch 体系成熟就直接用这个
- Chroma：轻量级，适合 demo 和小项目
选型主要看你的规模、延迟要求、运维复杂度。生产环境 Milvus 和 ES 用得多，小项目 Chroma 够了。
第四步：检索与生成
这一步是真正用起来的时候，分四个小环节：
Query 改写：用户问的问题不一定最适合检索。比如用户说"那个叫什么来着，就是上次说的那个技术"，这种 query 直接检索肯定找不到东西。需要先改写，改成能搜的形态。
相似度检索：把用户问题也转成向量，然后在向量数据库里找最相似的 Top-K 个文档块。
上下文构建：把检索到的 K 个文档块拼起来，加上用户问题，组成完整的 Prompt。
LLM 生成：把构建好的 Prompt 发给大模型，让它基于检索到的内容生成答案。
整个流程串起来就是：用户问 → 改写查询 → 检索相似文档 → 拼上下文 → 大模型回答
RAG 三阶段演进
RAG 不是一成不变的，随着应用场景越来越复杂，RAG 也在进化。
Naive RAG（基础版）
最原始的形态：
文档 → 切块 → Embedding → 存向量库
用户问题 → Embedding → Top-K 检索 → 直接拼 Prompt → LLM 生成
简单直接，适合 Demo 和简单场景。缺点也很明显：检索质量差就直接影响答案质量，用户问题表达不清就搜不到东西。
Advanced RAG（进阶版）
针对 Naive 的问题，打了各种补丁：
Query Rewrite：改写用户问题，让它更适合检索。比如同义词替换、问题补全。
HyDE（Hypothetical Document Embeddings）：让 LLM 先猜一个"可能的答案文档"，然后用这个假设文档去检索真实文档。听起来绕，但有时候效果好。
混合检索：不要只靠向量相似度，结合传统的关键词搜索（BM25）。两种方式取长补短。
Rerank：第一轮召回可能不太准，先召回 20 个，再用 Rerank 模型排序选出最相关的 5 个。
上下文压缩：召回的文档可能太长太杂，用 LLM 或者小型模型做摘要压缩，把关键信息提取出来。
进阶版解决的是"搜不到"和"搜不准"的问题。
Modular RAG（模块化版）
到这一步，RAG 变成了可插拔的架构：
- 检索模块可以换
- 重排序模块可以换
- 生成模块可以换
- 路由模块可以动态选择用哪些组件
适合复杂 Agent 场景。比如多跳问答，需要多次检索再生成；比如多模态 RAG，需要处理图片、表格、PDF。
三个阶段的演进逻辑很清晰：能用 → 用得准 → 用得灵活。
面试加分项
能说到这儿已经不错了，但如果你想拿高分，还可以加几个维度。
RAG vs 传统搜索
传统搜索给你一堆文档链接，你自己找答案。RAG 直接给你整理好的答案。
但 RAG 不是要取代搜索。搜索适合开放域、探索性查询，RAG 适合有明确知识库支撑的问答场景。
RAG vs 微调
RAG 的优势：知识更新快，改知识库就行，不用重新训练；答案可溯源，能看到引用来源；成本低，不用 GPU 资源做训练。
微调的优势：风格一致，比如你的产品需要特定语气、格式，用微调能固定下来；推理延迟低，不用每次都查知识库。
选型建议：知识更新频繁用 RAG，风格固定用微调，两者结合也有。
常见局限性
GIGO 原则（Garbage In, Garbage Out）：检索质量决定上限。如果召回的内容本身不相关，LLM 再强也救不回来。很多人 RAG 效果差，问题是检索做砸了，不是生成模型不够好。
上下文注意力稀释：塞进去的上下文太多，模型会"分不清主次"，关键信息被淹没了。所以 Top-K 不能太大，上下文压缩很重要。
延迟问题：RAG 比纯生成多了检索和上下文构建的步骤，多跳场景会更慢。实时性要求高的场景要权衡。
面试怎么答
基础版
RAG 是检索增强生成，核心思路是让大模型先从知识库检索相关资料，再基于检索内容生成答案。
完整流程分四步：第一步是文档拆分，把长文档切成合适大小的块；第二步是向量化，把文本块转成高维向量；第三步是向量存储，存入向量数据库；第四步是检索生成，把用户问题转向量、检索相似文档、拼上下文、让 LLM 生成答案。
RAG 经历了三个阶段演进：Naive RAG 是最基础的形态，Advanced RAG 通过 Query 改写、混合检索、Rerank 等技术优化召回质量，Modular RAG 则把各模块解耦，支持按场景灵活组合。
加分版
除了基本流程，我理解 RAG 的核心挑战是检索质量决定上限，这就是 GIGO 原则。Advanced RAG 的 Query Rewrite 解决用户表达不清的问题，混合检索融合关键词和语义两种方式，Rerank 在粗召回后再精排。
实际项目中，我踩过的坑是切块策略影响很大，固定长度切块效果往往不如按语义段落切。另外上下文压缩很关键，召回的内容不是越多越好，太多了模型会注意力稀释，反而关键信息被淹没。
选型上，简单知识库问答用 Naive RAG 就够了，生产级系统建议用 Advanced RAG，复杂 Agent 场景才需要 Modular RAG。
一句话总结
RAG 就是"先查后写"，核心四步：切块、向量化、存向量、检索生成，面试能讲清这四步并理解 GIGO 原则，这道题就算过关了。