RAG 工作流程与关键技术组件

30 秒回答

1. 离线索引流程（文档解析、分块、向量化、存储）
2. 在线检索流程（查询改写、向量检索、重排序、上下文组装）
3. 关键技术组件（Embedding模型、向量数据库、Reranker）
4. 核心挑战（检索精度、上下文长度限制、知识更新、幻觉问题）

回答与解析

答案要点

• 离线索引流程（文档解析、分块、向量化、存储）
• 在线检索流程（查询改写、向量检索、重排序、上下文组装）
• 关键技术组件（Embedding模型、向量数据库、Reranker）
• 核心挑战（检索精度、上下文长度限制、知识更新、幻觉问题）

一、RAG基本工作流程

离线索引阶段

• 文档解析：处理PDF/Word/网页等多格式，提取结构化文本
• 文本分块（Chunking）：按语义或固定长度切分，通常512-1024 tokens，需保证语义完整性
• 向量化（Embedding）：用BGE、M3E等模型将chunk编码为稠密向量
• 索引存储：写入Milvus/Pinecone/Elasticsearch等向量数据库，可结合稀疏索引（BM25）做混合检索

在线检索生成阶段

• 查询理解：用户query可能需改写/扩展（HyDE、Query2Doc）
• 向量检索：Top-K相似度召回，常用ANN算法（HNSW、IVF）
• 重排序（Rerank）：用Cross-Encoder精排，提升相关性
• 上下文组装：将检索结果注入Prompt模板，限制在上下文窗口内
• LLM生成：模型基于检索上下文作答

二、关键技术组件

三、核心挑战

• 检索精度：语义鸿沟导致召不准，需多路召回+重排序
• 上下文瓶颈：长文档超出窗口，需摘要压缩或层级索引
• 知识时效性：静态索引难更新，需增量索引+版本管理
• 幻觉与归因：模型不看检索内容瞎编，需强制引用溯源
• 多跳推理：复杂问题需多次检索，引入ReAct/ToT等Agent架构

实际落地中，检索质量决定RAG上限，建议先做检索评测（Recall@K、MRR）再优化生成。

口语版讲法(约4分钟)

• RAG本质是给LLM配外挂知识库
• 离线阶段：文档处理与向量化
• 在线阶段：检索与生成
• 关键组件：Embedding、向量库、Reranker
• 落地挑战与取舍

RAG这道题，其实是在问怎么给大模型配一个「外挂知识库」，让它在不重新训练的情况下也能回答私有数据的问题。核心思路就两条腿走路：离线把知识存成索引，在线把用户问题和索引匹配上，再让模型基于匹配结果回答。

先说离线阶段。原始文档五花八门，PDF、Word、网页，得先清洗成纯文本。然后最关键的一步是分块，也就是 Chunk。这里有个坑：分太细，语义不完整，模型看不懂上下文；分太粗，超了上下文窗口，而且一个块里揉太多主题，检索时噪声大。我一般会看业务场景来定。比如客服退款政策，一个段落讲一个规则，那就按段落分；如果是技术文档，前后依赖强，我会用递归切分，保证块之间有重叠。分块策略没有银弹，得根据文档结构和下游任务调。分完块之后用 Embedding 模型转成向量，存到 Vector Database 里，像 Milvus 或者 PGVector。

在线阶段，用户来了一个 query，比如「七天无理由退货的运费谁出」。如果直接拿原始 query 去搜，可能搜不到，因为用户问法和文档表述不一样。所以我会先做一点查询改写，比如用 HyDE 先生成一个假设文档再去搜。然后做向量检索，用 HNSW 这类 ANN 算法快速召回 Top-K。这里有个边界问题：纯向量检索适合语义匹配，但对精确关键词比如订单号、错误码就抓瞎。所以真正落地我倾向 Hybrid Search，向量加 BM25 两条路一起上，再合并排序。召回之后别急着喂给模型，先过一遍 Rerank，用 Cross-Encoder 精排，把最相关的几条顶到前面。最后把检索结果和 query 拼成 prompt 给 LLM 生成答案。

关键组件我重点讲三个。Embedding 模型决定了语义理解的天花板，我一般选 BGE 或 GTE 这类开源模型，但要注意中文场景下需要领域微调，不然「退货」和「退款」的语义距离可能不对。向量数据库解决的是海量向量的快速检索，但建索引有代价，比如 HNSW 写起来慢，适合读多写少的场景，如果知识库频繁更新，得考虑增量索引或者双缓冲方案，不然索引重建太慢。Reranker 是精排，它能弥补 Embedding 召回的不准，但计算成本高，所以通常只对 Top-100 重排，不排全量。

落地中最头疼的其实是时效性问题。比如电商大促期间满减政策一天一变，离线索引跟不上。我见过一个失败案例：客服系统用 RAG，但政策更新后索引没刷新，模型还在回答旧政策，导致客诉。所以上线前我会特别关注知识更新的 pipeline，设一个强制刷新周期，或者用 Self-RAG 让模型自己判断检索内容是否过时，必要时拒绝回答。

最后说挑战。检索质量决定 RAG 的天花板，如果第一步就召不准，后面再好的模型也白搭。所以我会优先做检索评测，盯着 Recall@K 和 MRR，达标了再优化生成。另一个是幻觉问题，模型可能不看检索内容瞎编，我会在 prompt 里强制要求引用原文，甚至用 Faithfulness 指标做自动检测。我的核心取舍是：宁可不回答，也不要给错答案。 所以我会把 RAG 看成一套检索系统加上一个生成接口，重心放在检索和过滤上，而不是一味调 prompt。

关键一句:知识库频繁更新时，增量索引比全量重建更复杂，需要双缓冲和版本管理

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你现在做一个内部知识库问答机器人，用户上传了各种PDF和网页，你要怎么设计才能让模型准确回答出最新版产品手册里的内容？从文档处理到最终给出答案，走一遍流程说说。

2. 问法 2 · 层层追问

   你平时做知识库问答怎么让模型基于外部知识回答？……那文档那么多，怎么快速找到相关片段？……如果找到的片段太多、有噪音，或者不够相关怎么办？……具体每个步骤用什么技术？

3. 问法 3 · 直球架构

   给我讲一下RAG系统的完整工作流程，包括离线索引和在线检索生成两个阶段，然后分析里面关键的组件和主要挑战。