Q2: 一个完整的 RAG 流水线包含哪些关键步骤？请从数据准备到最终生成，详细描述整个过程
P1 · rag
🏷 标签：rag, pipeline, retrieval, generation, system-design
1️⃣ 考察意图
面试官想看的不是“RAG 就是检索+生成”这种教科书定义，而是你对工程整条链路的掌控力。这道题是典型的系统设计 + 工程取舍型问题，刁钻点在于：多数人只背了分块、检索、生成三个词，但实际落地时每个步骤都有坑——比如文档解析的表格丢失、分块策略对召回率的非线性影响、混合检索的权重调参、以及生成阶段的幻觉控制。答好了能展示你从数据预处理到推理优化的端到端工程思维，以及用具体工具（如 Unstructured.io、FAISS、Cohere rerank）解决实际问题的经验。
2️⃣ 标准答
一个生产级 RAG 流水线通常拆为 5 个阶段，每个阶段都有明确的 trade-off 和常见坑。
1. 数据准备与清洗
- 文档解析：PDF 用 PyMuPDF 或 Unstructured.io 提取文本和表格，HTML 用 BeautifulSoup 或 Readability。坑：PDF 中表格常被解析为乱序文本，导致检索时丢失结构化信息。解法：对表格区域单独用 Camelot 或 Tabula 提取，转为 Markdown 格式保留行列关系。
- 清洗：去除页眉页脚、重复空行、特殊字符（如 Unicode 控制字符）。注意：不要过度清洗导致语义断裂，比如删除换行符可能破坏代码块或公式。
- 元数据提取：保留文档标题、章节号、创建时间、来源 URL。元数据在后续过滤（如只检索 2024 年后的文档）和生成阶段引用来源时至关重要。
2. 分块（Chunking）
- 策略选择：固定大小分块（如 512 tokens）简单但可能切断语义；语义分块（如基于段落边界或 NLP 句子分割）更自然但计算开销大。工程取舍：固定分块配合 10-20% 重叠（overlap）是性价比最高的方案，重叠能缓解边界截断导致的召回丢失。
- 最佳实践：分块大小需根据嵌入模型和 LLM 上下文窗口调优。例如，用
text-embedding-3-small（1536 维）时，256-512 tokens 的分块在常见 QA 数据集上 F1 最高；若用 ColBERT 这类 token-level 模型，分块可更大（1024 tokens）。坑：分块太小导致检索结果碎片化，太大则引入噪声，需用验证集（如 200 条 query）做 grid search。
3. 索引构建
- 向量索引：选择嵌入模型（如 BGE-M3、E5-mistral-7b），生成向量后建索引。生产环境用 FAISS 的 IVF-PQ（量化压缩）或 HNSW（图索引），前者节省内存但牺牲 1-2% 召回，后者速度快但构建耗时。取舍：数据量 <100 万时用 HNSW（默认 efConstruction=200, M=16），>100 万时用 IVF-PQ 配合 GPU 加速。
- 混合索引：附加 BM25 倒排索引（用 Elasticsearch 或 Tantivy），用于关键词匹配。为什么做：向量检索对罕见术语（如“GRPO 算法”）召回差，BM25 能补位。权重调参：通常 0.7 向量 + 0.3 BM25，但需根据领域调整（法律文档 BM25 权重可提到 0.5）。
4. 检索与重排序
- 初检：用户 query 嵌入后，用余弦距离或内积检索 top-K（K=50-100）。注意：query 嵌入需与文档嵌入用同一模型，且 query 端可加指令前缀（如 BGE 的
Represent this sentence for searching:）。 - 重排序：用交叉编码器（如 Cohere rerank-v3、BGE-reranker-v2）对 top-K 精排，取 top-5。为什么做：双编码器（向量检索）只算 query 和文档的独立相似度，交叉编码器能建模交互，提升 10-15% 的 MRR。坑：重排序是 O(n) 计算，K 太大（>100）会显著增加延迟，需用 GPU 或量化模型加速。
5. 生成
- Prompt 构建：将重排序后的文档拼接为上下文，格式如
[Document 1]... [Document 2]...，并加入指令（如“仅基于以下文档回答，若无法回答则说不知道”）。工程取舍：上下文窗口限制（如 8K tokens）下，需压缩文档（用 LLMLingua 或 Selective Context）或动态选择相关片段。 - 幻觉控制：生成阶段用温度 0.1-0.3 降低随机性，并强制模型输出引用标记（如
[1]）。落地坑：LLM 可能忽略指令，需在 prompt 末尾加“请逐句检查是否在文档中找到依据”，或使用工具调用（function calling）让模型先输出引用再生成答案。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据准备、索引构建、检索与重排序、生成四个层面回答。数据准备阶段重点解决 PDF 表格解析和元数据提取；索引构建时用 HNSW 向量索引加 BM25 混合索引，平衡语义和关键词召回；检索阶段先向量初检 top-50，再用交叉编码器重排序到 top-5；生成阶段通过 prompt 指令和低温度控制幻觉。总结一句：RAG 流水线的核心不是单个环节的极致优化，而是各环节的协同调参——比如分块大小和检索 top-K 的联动对最终准确率影响最大。”
4️⃣ 高频追问 & 应对
追问 1：你提到分块大小需要调优，具体怎么调？有没有经验值？
用验证集做 grid search。假设数据是技术文档（平均段落 300 tokens），我会试 256、512、1024 三个分块大小，重叠率固定 15%。评估指标用 Recall@5（检索结果中是否包含正确答案）。经验值：通用领域 512 tokens 最优，法律/医疗领域因术语密集，256 tokens 更好（避免噪声）。坑：分块大小和嵌入模型维度相关，比如用 768 维的 BGE 时，512 tokens 的向量能保留足够语义；若用 384 维的 all-MiniLM，分块建议降到 256 tokens。
追问 2：混合检索的权重怎么确定？有没有自动调参方法？
手动调参用验证集上的 NDCG@10 做目标，网格搜索向量权重 0.5-0.9（步长 0.1）。自动方法：用贝叶斯优化（如 Optuna）或线性回归拟合权重，但数据量需 >500 条 query。更工程化的解法：用学习排序（Learning to Rank）模型，如 LightGBM，将向量相似度、BM25 分数、文档长度等作为特征，训练一个轻量级排序器。注意：LTR 需要标注数据（如人工标注的相关性分数），成本高，小团队建议手动调参。
追问 3：生成阶段如何评估 RAG 质量？只用准确率够吗？
不够。生产级评估至少三个维度：① 忠实度（Faithfulness）：用 NLI 模型（如 TrueTeacher）检查生成内容是否被检索文档支持；② 答案召回（Answer Recall）：用 ROUGE-L 或 BERTScore 对比生成答案和标准答案；③ 拒绝率（Rejection Rate）：当检索文档不相关时，模型应输出“无法回答”。实际落地中，忠实度比准确率更重要——一个看似正确但编造细节的答案比直接说不知道更危险。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“RAG 就是先检索再生成，分块用固定大小就行” → ✅ 必须强调分块策略对召回率的非线性影响，以及需要根据数据领域调优（如代码文档用 256 tokens 避免截断函数）。
- ❌ 说“重排序用向量检索的 top-5 直接生成就行，不需要额外步骤” → ✅ 必须解释为什么需要重排序：双编码器无法建模 query 和文档的交互，交叉编码器能提升 10-15% 的 MRR，尤其当检索结果中有多个相似文档时。
- ❌ 说“生成阶段用默认 prompt 就行，LLM 会自动处理” → ✅ 必须指出 prompt 工程的关键：指令要明确（如“仅基于文档回答”）、上下文要压缩（如用 LLMLingua 减少噪声）、要强制输出引用标记以控制幻觉。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中踩过 PDF 表格解析的坑，改用 Camelot 后召回率提升 8%”切入，展示你不仅知道步骤，还做过具体优化。
- 如果你只做过传统 NLP：用“传统信息检索的 BM25 和向量检索的混合策略，类似推荐系统中的协同过滤+内容过滤”类比，展示迁移能力。
- 如果你是校招无项目：聚焦“我复现过 LlamaIndex 的默认 RAG 流水线，并对比了不同分块策略对 SQuAD 数据集的影响”，强调你对开源工具的熟悉度和实验设计能力。
- 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）——RAG 原始论文
- 《Lost in the Middle: How Language Models Use Long Contexts》（Liu et al., 2023）——上下文位置对生成的影响
- 《BGE-M3: Multi-Lingual, Multi-Granularity, Multi-Task Embedding Model》（BAAI, 2024）——嵌入模型选择
- 《FAISS: A Library for Efficient Similarity Search》（Johnson et al., 2019）——向量索引原理
- 《Cohere Rerank: Improving Retrieval with Cross-Encoders》（Cohere 博客）——重排序最佳实践