02. 一个完整的 RAG 系统通常包含哪些环节？

简单回答

一个完整的 RAG 系统包含离线索引和在线服务两大部分。离线部分涵盖文档解析、Chunk 切分、Embedding 编码、向量入库；在线部分涵盖 Query 理解与改写、向量检索（召回）、Rerank（精排）、Prompt 组装、模型生成、以及后处理（如引用标注、安全过滤）。工程上还需要考虑更新机制、评测体系和监控。

详细解释

离线索引链路

离线链路的目标是把原始知识库变成可检索的向量索引。这条链路看似简单，但细节很多，做不好会直接拖垮整个系统的效果。

文档解析是第一步。真实业务中的知识库不全是干净的纯文本，可能是 PDF、Word、PPT、HTML、Markdown 甚至扫描件。文档解析要做的是把这些格式转换成结构化或半结构化的文本。这一步看起来不起眼，但如果 PDF 解析丢了表格、OCR 识别出错、HTML 没清理干净标签噪音，后面所有环节都会受影响。常用工具包括 PyMuPDF、pdfplumber、Unstructured、Marker 等，实际中往往需要根据文档类型做定制化处理。

Chunk 切分是影响效果的关键环节。文档需要被切成合适大小的片段，太长则检索精度下降（一个 Chunk 里混杂了多个主题），太短则丢失上下文（一句话单独拿出来可能意义不明）。常见策略有按固定长度切、按句子/段落切、按语义切（用模型判断语义边界）、以及按文档结构切（利用标题、章节等结构信息）。Chunk 之间通常还需要设置 overlap（重叠），防止关键信息刚好被切在边界上丢失。

Embedding 编码就是用一个文本向量化模型把每个 Chunk 映射成一个高维向量。这个向量要能捕捉语义信息，使得语义相近的文本在向量空间中距离也近。模型选择和质量直接决定了后续检索的上限。

向量入库是把编码好的向量存入向量数据库，建好 ANN 索引。索引类型（HNSW、IVF 等）、距离度量（余弦相似度、内积、L2 距离）的选择会影响检索的速度和精度。

除了向量索引外，很多系统还会同时建立关键词索引（BM25），用于后续的混合检索。这就涉及到把文档同时灌入 Elasticsearch 或类似的全文检索引擎。

在线检索与生成链路

在线链路的核心是：用户问了一个问题，怎么尽快、尽准地返回一个好答案。

Query 理解和改写是容易被忽视但非常重要的环节。用户的原始提问经常是模糊的、口语化的、甚至是多意图混合的。比如用户问"上次那个报错怎么解决的"——这里面有指代消解的问题（"上次那个"是什么？），有意图识别的问题。常见手段包括 Query Rewrite（用 LLM 把口语化查询改写成更精确的检索 query）、Multi-Query（把一个问题拆成多个子查询，分别检索再合并）、HyDE（先让 LLM 生成一个假设性的答案，用这个答案去检索）。

召回（Recall）阶段是从海量文档中快速筛选出候选集。通常用向量检索做语义召回，用 BM25 做关键词召回，然后合并结果。这就是 Hybrid Search。单纯靠向量检索在某些场景下会漏掉精确匹配的关键词（比如产品型号、错误码），而 BM25 又抓不住语义相似但用词不同的文档，所以混合检索效果通常更好。

Rerank（精排）阶段是对召回的候选文档做更精细的相关性排序。召回阶段用的是轻量级的 Embedding 相似度，速度快但精度有限。Rerank 阶段用一个 Cross-Encoder 模型（如 bge-reranker、Cohere Rerank），把 query 和每个候选 Chunk 拼在一起做精细打分。Cross-Encoder 的精度远高于 Bi-Encoder（Embedding 模型），但计算量也大，所以只能用在候选集较小的时候（通常几十到几百条）。

Prompt 组装是把检索和排序后的 Top-K 文档片段和用户问题按照预设模板拼成最终的 Prompt。这里有不少工程细节：文档放在前面还是后面（"Lost in the Middle"问题表明模型对中间位置的文档关注度最低）；要不要加指令告诉模型"如果资料不足就说不知道"；Chunk 之间怎么分隔；Token 超限了怎么截断等。

模型生成就是把组装好的 Prompt 送给 LLM 生成回答。这一步可能用 API 调用商用模型，也可能用自部署的开源模型。

后处理环节包括引用标注（标出回答中引用了哪些文档片段）、内容安全检查、格式化输出等。引用标注在企业级应用中特别重要——用户需要知道答案的依据是什么，能不能去查原文验证。

工程化的环节

在生产环境中，一个 RAG 系统还需要考虑知识库的更新机制（增量更新还是全量重建）、缓存策略（相同或相似的查询可以缓存结果）、评测体系（怎么衡量检索质量和生成质量）、日志与监控（记录每次检索和生成的详细信息，方便排查问题）、以及 fallback 机制（检索不到相关文档时怎么处理）。

面试时可以这样答

一个完整的 RAG 系统分离线和在线两条链路。离线链路做的是知识库的索引：文档解析、Chunk 切分、Embedding 编码、向量入库，有些系统还会同时建 BM25 索引用于混合检索。

在线链路是从用户提问到最终回答的全过程。首先是 Query 理解和改写，因为用户的原始提问经常是模糊或口语化的，需要做改写或拆分。然后是召回，通常是向量检索加 BM25 的混合检索。接着是 Rerank，用 Cross-Encoder 对候选文档做精排，筛出最相关的几条。然后是 Prompt 组装，把检索结果和问题拼成 Prompt 送给模型生成。最后是后处理，比如引用标注、安全过滤。

工程上还要考虑知识库更新、缓存、评测和监控。实际项目中，效果瓶颈往往出现在最前面的文档解析和 Chunk 切分，而不是模型生成。很多时候检索链路花的精力比生成端要多得多。

常见追问

1. 你实际项目中离线索引链路是怎么设计的？增量更新怎么做？
2. 如果检索和 Rerank 之间还有一步过滤逻辑，你会加什么？
3. Prompt 组装时文档放的顺序对效果有影响吗？