八股文解析
RAG 检索增强生成的完整链路是怎样的？
一句话结论
RAG 是“检索 + 生成”两段式架构，核心是用外部知识库检索结果来约束 LLM 生成，解决幻觉和知识过期问题。
面试标准答法
1. 整体架构分层
RAG（Retrieval-Augmented Generation）不是单一算法，而是一条流水线。面试时要按 Ingestion（数据入库）→ Retrieval（检索）→ Generation（生成） 三层拆解。
第一层：Ingestion（数据预处理与向量化）
这一层解决“知识怎么进库”的问题，包含四个关键步骤：
- Document Loader：从 PDF、HTML、数据库等异构源抽取文本。
- Chunking（分块）：将长文本切成固定大小（如 256-512 tokens）的块，chunk 大小直接影响检索精度——太小则语义不完整，太大则引入噪声。
- Embedding（向量化）：用 Embedding Model（如 OpenAI text-embedding-3、BGE、E5）将每个 chunk 转为高维向量（通常是 1024-3072 维）。
- Indexing（索引构建）：存入 Vector Database（如 FAISS、Milvus、Pinecone），同时建立 倒排索引（BM25 稀疏检索）或 HNSW（Hierarchical Navigable Small World，图索引）加速近邻搜索。
第二层：Retrieval（查询改写与召回）
这一层解决“怎么把相关问题捞出来”。面试重点讲两个机制：
Query Rewriting（查询改写）：用户原始 query 往往口语化、指代不清，需要改写后再检索。常见策略：
- HyDE（Hypothetical Document Embeddings）：先用 LLM 根据 query 生成一个假想答案文档，再用该文档的 embedding 去检索——因为假想文档与知识库文档的语义空间更接近。
- Multi-Query：将原始 query 拆成多个子查询，分别检索后合并结果，解决复杂问题覆盖不全。
Retrieval 召回：核心是向量相似度计算，常用 余弦相似度（Cosine Similarity） 或 内积（Dot Product）。但单纯向量检索有缺陷，所以工业界普遍用 Hybrid Search（混合检索）：
- BM25（稀疏检索）：基于词频和逆文档频率，擅长精确关键词匹配，处理专有名词、ID 号。
- 向量检索（稠密检索）：基于语义相似度，擅长同义改写、语义模糊。
- RRF（Reciprocal Rank Fusion）：将两类结果按排名倒数加权融合，公式为
score = Σ 1/(k + rank_i)，k 通常取 60。
第三层：Generation（上下文注入与生成）
将检索到的 Top-K 个 chunk（K 通常取 3-5）与原始 query 拼装成 Prompt，输入 LLM 生成答案。关键机制：
- Context Window 管理：控制注入文本长度，防止超出 LLM 上下文限制（如 4K/8K/128K tokens）。
- Prompt Template 设计：典型模板为
Answer based on the following context: {context}. Question: {query}，并强调“若上下文中无答案，请直接说不知道”。 - Citation（引用标注）：要求 LLM 在回答中标注来源 chunk 编号，便于溯源和验证。
对比表格：朴素 RAG vs 高级 RAG vs 模块化 RAG
| 维度 | 朴素 RAG（Naive RAG） | 高级 RAG（Advanced RAG） | 模块化 RAG（Modular RAG） |
|---|---|---|---|
| 检索策略 | 单一向量检索 | 混合检索 + RRF 融合 | 可插拔检索器组合（向量/图/知识图谱） |
| 查询处理 | 原样检索 | HyDE / Multi-Query 改写 | 意图识别 + 路由到不同检索器 |
| 索引优化 | 固定 chunk 大小 | 滑动窗口 + 父子分块（Parent-Child Chunking） | 动态索引 + 增量更新 |
| 重排序 | 无 | Reranker（如 Cross-Encoder）二次排序 | 多级重排 + 过滤 |
| 适用场景 | POC 验证、demo | 生产环境、中等精度要求 | 复杂企业知识库、多源异构数据 |
| 优点 | 实现快、成本低 | 精度显著提升、可解释性好 | 灵活性最高、可针对场景定制 |
| 缺点 | 召回率低、噪声大 | 延迟增加（多一跳检索） | 工程复杂度高、调试困难 |
常见追问表
| 追问 | 要点 |
|---|---|
| RAG 和 Fine-tuning 怎么选？ | RAG 适合知识频繁更新、需要溯源、冷启动快的场景；Fine-tuning 适合改变模型风格/格式/领域术语。RAG 改知识零成本，Fine-tuning 每次更新要重训。 |
| 检索结果质量差怎么办？ | 按链路排查：① chunk 切分是否合理（用父子分块）；② embedding 模型是否匹配领域（通用模型在垂直领域表现差）；③ 是否缺 Reranker；④ 是否做了 query 改写。 |
| 如何评估 RAG 系统？ | 分两维：检索质量（Recall@K、MRR）和生成质量（Faithfulness 忠实度、Answer Relevance 相关性）。工业界用 RAGAS 框架或人工评估集。 |
| 上下文注入超长怎么办？ | 方案：① 压缩 chunk（LLM 抽取关键信息）；② 滑动窗口按需取块；③ 用 Map-Reduce 模式分段生成再汇总；④ 升级长上下文模型。 |
面试回答模板（30 秒版）
延伸准备（加分项）
- Reranker 的原理细节：能说清 Cross-Encoder 和 Bi-Encoder 的区别——Cross-Encoder 将 query 和 doc 拼接后过完整 Transformer，精度高但慢；Bi-Encoder 各自编码后算相似度，快但精度低。实际系统常用“Bi-Encoder 粗排 + Cross-Encoder 精排”两段式。
- GraphRAG：微软提出的方案，将知识库构建成知识图谱（实体-关系三元组），检索时先定位实体子图再生成。优势是能回答多跳推理问题（如“A 公司的供应商中哪些与 B 公司有合作”），而向量检索只能做语义相似匹配。
- 缓存与增量更新机制：生产环境常见问题是知识库频繁更新。加分回答是：用 Embedding 版本管理 实现增量索引，只对新增/修改的 chunk 重新编码；同时加 Query Cache（LRU 或语义缓存）降低重复查询的延迟。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
