---

一个完整的 RAG 检索链路，通常可以拆成六个阶段：文档切分 → 向量化 → 索引 → 召回 → 重排序 → 最终生成。每一阶段都有明确的取舍点。

1、文档切分（Chunking）

目标：把长文档切成适合检索和生成的小块。

常见策略：

• 固定长度切分：按 token 数或字符数切，简单高效，但容易切断语义。
• 滑动窗口切分：块之间有重叠，缓解切断问题，但会增加索引量和冗余。
• 按语义切分：按段落、句子边界切，保留语义完整性，但块长不均。
• 按标题层级切分：按 Markdown/HTML 标题切，适合结构化文档，但依赖文档格式。
• 父子块 / 小块检索大块生成：用小块做检索，命中后返回其父块或相邻块给 LLM，兼顾检索精度和生成上下文。

关键取舍：

• 块大小：太小 → 检索准但上下文不足；太大 → 上下文足但噪声多、召回精度下降。
• 重叠长度：重叠多 → 减少切断，但索引膨胀、检索重复。
• 是否保留元数据：标题、来源、时间、页码等元数据对过滤和溯源很重要，但会增加存储和索引复杂度。

实践建议：先用固定长度 + 重叠做 baseline，再根据文档类型逐步引入语义切分或父子块。

2、向量化（Embedding）

目标：把文本块映射到向量空间，使语义相近的块距离更近。

关键取舍：

• 模型选择：
  • 通用 Embedding 模型（如 BGE、E5、GTE、OpenAI text-embedding 系列）适合大多数场景。
  • 领域模型（法律、医疗、代码）在垂直领域效果更好，但需要额外训练或微调。
• 维度：高维表达能力强但存储和检索成本高；低维成本低但可能损失语义。
• 多语言：如果文档和 query 跨语言，需要多语言模型或翻译对齐。
• 是否微调：用领域数据微调 Embedding 可以显著提升召回，但需要标注数据。
• 对称 vs 非对称：query 和 document 长度差异大时，要用支持非对称检索的模型。

关键取舍：效果 vs 成本 vs 延迟。大模型效果好但推理慢、存储大；小模型快但可能召回不足。

3、索引（Indexing）

目标：让向量检索在海量数据下仍然快。

常见方案：

• Flat 索引：暴力检索，精度最高，但数据量大时慢。
• IVF 系列：倒排文件 + 聚类，速度快，但可能漏召回。
• HNSW：图索引，查询快、精度高，但内存占用大。
• PQ / OPQ：量化压缩，省内存，但精度有损。
• 磁盘索引：如 DiskANN，适合超大规模，但延迟高于内存索引。

关键取舍：

• 召回率 vs 延迟 vs 内存：三者不可能同时最优。
• 是否增量更新：HNSW 支持增量插入但删除麻烦；IVF 需要重建。
• 是否支持元数据过滤：很多场景要先按时间、来源、权限过滤，再向量检索。

实践建议：中小规模用 HNSW；超大规模用 IVF + PQ 或 DiskANN；需要强过滤时考虑带过滤的索引结构。

4、召回（Retrieval）

目标：从索引中找出与 query 最相关的候选块。

常见方式：

• 稠密检索：向量相似度（余弦、内积、欧氏距离）。
• 稀疏检索：BM25、TF-IDF，关键词匹配强。
• 混合检索：稠密 + 稀疏，兼顾语义和关键词。
• 多路召回：不同模型、不同索引、不同 query 改写各召回一批，再融合。

关键取舍：

• Top-K：K 小 → 可能漏掉相关文档；K 大 → 噪声多、重排序压力大。
• 分数融合：RRF（Reciprocal Rank Fusion）简单有效；加权分数需要调参。
• 查询改写：多轮对话中，query 依赖上下文，需要改写或扩展，但改写可能引入偏差。

实践建议：先用混合检索 + RRF 融合，再根据评估调整 Top-K 和权重。

5、重排序（Rerank）

目标：对召回结果精排，把最相关的块排到前面。

常见方式：

• Cross-Encoder：query 和 document 拼接后过模型，精度高但慢。
• Bi-Encoder：分别编码后算相似度，快但精度低于 Cross-Encoder。
• LLM Rerank：用 LLM 打分或排序，灵活但成本高、延迟大。
• 规则重排：按时间、来源、点击率等业务信号调整。

关键取舍：

• 精度 vs 延迟：Cross-Encoder 精度高但只能对少量候选做精排。
• 候选数量：召回多 → 重排序准但慢；召回少 → 快但可能漏。
• 是否可解释：业务场景可能需要可解释的排序依据。

实践建议：召回 50~100 条，Cross-Encoder 重排到 Top 5~10，再给 LLM 生成。

6、最终生成（Generation）

目标：把检索到的上下文和用户 query 一起给 LLM，生成答案。

关键取舍：

• 上下文长度：太长 → 噪声多、成本高、可能超出窗口；太短 → 信息不足。
• Prompt 设计：是否要求“只根据上下文回答”、是否要求引用来源、是否允许“不知道”。
• 幻觉控制：检索内容不足时，模型可能编造。需要 prompt 约束 + 后验校验。
• 引用与溯源：返回答案时附带来源块，提升可信度。
• 多块融合：多个块可能冲突，需要去重、排序或让模型综合判断。

实践建议：上下文按相关性排序，限制 token 预算，prompt 明确要求引用和拒答。

7、整体链路取舍总结

阶段	核心目标	主要取舍
切分	语义完整 + 检索友好	块大小 vs 上下文完整性
向量化	语义表达	效果 vs 成本 vs 延迟
索引	快速检索	召回率 vs 延迟 vs 内存
召回	找全相关	Top-K vs 噪声
重排序	排准	精度 vs 延迟
生成	答好	上下文长度 vs 噪声 vs 幻觉

一句话总结：RAG 检索链路的设计，本质是在召回率、精度、延迟、成本四个维度上反复权衡，没有银弹，必须用评估数据驱动调优。

8、这道面试题的质量点评

优点

• 覆盖面广：从切分到生成，完整覆盖 RAG 核心链路，能考察候选人是否真正做过端到端系统。
• 有层次：既能问基础（什么是重排序），也能问深入（分数融合、父子块、索引选型）。
• 贴近工业界：RAG 是当前落地最广的 LLM 应用形态，题目实用。
• 有区分度：初级可能只答“切分、向量、检索、生成”；高级能讲清每步取舍、评估和调优。

缺点

• 太宽泛：一道题覆盖六个阶段，候选人容易泛泛而谈，面试官也难在短时间内深入考察。
• 容易背答案：网上 RAG 八股文很多，候选人可能背出流程但没实际调优经验。
• 缺少场景约束：没有给具体业务场景（如客服、法律、代码），难以考察针对性设计能力。
• 评估环节缺失：题目没提“如何评估”，而评估才是 RAG 调优的核心。

总体评价

质量：中上。 适合作为 RAG 方向的开场题或综合题，用来判断候选人是否做过完整 RAG 系统。但单靠这一道题区分度有限，最好配合追问，比如：

• “你实际项目中块大小怎么定的？为什么？”
• “混合检索的分数怎么融合？试过哪些方法？”
• “召回率上不去，你怎么排查？”
• “怎么评估你的 RAG 系统？”

9、怎么回答才是最好的

回答原则

• 先给框架，再逐层展开：先一句话概括链路，再按阶段说。
• 每步都讲取舍：不要只列技术名词，要说“选 A 还是 B，为什么”。
• 结合真实项目：有数据、有踩坑、有调优过程，最加分。
• 主动提评估：面试官没问，你主动说“我们当时用 XX 指标评估”，会显得有工程思维。
• 承认边界：不知道的说不知道，别硬编。

推荐回答结构

“我一般把 RAG 检索链路分成六步：切分、向量化、索引、召回、重排序、生成。每一步的核心取舍是……” “切分上，我们试过固定长度和语义切分，最后用父子块，因为……” “向量化选了 BGE，因为中文效果好且成本可控……” “索引用 HNSW，因为数据量在百万级，内存够……” “召回用混合检索 + RRF，Top-K 设 50……” “重排序用 Cross-Encoder，精排到 Top 5……” “生成时 prompt 要求引用来源，并且允许说不知道……” “评估上，我们用 Recall@K 看检索，用人工标注看生成 faithfulness……”

加分点

• 提到 RRF、父子块、Cross-Encoder、HNSW、Recall@K、faithfulness 等具体术语。
• 提到 延迟、成本、token 预算 等工程约束。
• 提到 bad case 分析 和 迭代调优。
• 主动说 “我们当时踩过的坑”。

减分点

• 只背流程，不说取舍。
• 堆名词但解释不清。
• 没有评估意识。
• 说“我们直接用 LangChain 默认配置”，显得没深入。

---

---