What are the key hyperparameters in a RAG pipeline

What are the key hyperparameters in a RAG pipeline

1️⃣ 考察意图

面试官想看你是否真正理解 RAG 不是“一个模型”，而是一个由检索、重排序、生成三阶段组成的系统工程。这道题表面考“背参数”，实际考“工程取舍”：你能否区分哪些参数对检索召回率敏感、哪些对生成质量敏感，以及它们如何相互影响。刁钻点在于，很多人只背了 top-k 和 temperature，却不知道 chunk overlap 和 rerank threshold 才是调参瓶颈。答好了，能展示你从“调参工”到“系统设计者”的硬实力。

2️⃣ 标准答

RAG 管道的超参数按阶段分为三组：检索、重排序、生成。每个阶段都有核心参数和工程坑。

检索阶段

• top-k：控制召回数量。k 太小（<3）容易漏关键文档，k 太大（>20）会引入噪声，增加生成阶段上下文长度。经验值：密集检索（DPR/ColBERT）用 5-10，稀疏检索（BM25）用 10-20。为什么这么做：密集检索语义匹配更准，所以 k 可以小；BM25 依赖词频，需要更多候选来补召回。
• chunk size & overlap：chunk size 决定文档粒度。512 tokens 是常见起点，但要根据文档类型调整——代码文档用 256，长文用 1024。overlap 默认 10-20%，但实际落地的坑：如果 overlap 太小，跨 chunk 的实体（如“张三”在 chunk1，“的论文”在 chunk2）会断裂，导致检索不到。解法：用语义分割（如 LangChain 的 RecursiveCharacterTextSplitter）或加 overlap 到 30%。
• 检索器类型：稀疏（BM25） vs 密集（DPR/ColBERT） vs 混合（Hybrid）。混合检索常用加权融合，权重参数 alpha（0-1），alpha=0.7 表示 70% 密集 + 30% 稀疏。工程取舍：密集检索需要 GPU 推理，延迟高；BM25 快但召回差。线上场景通常用 BM25 做第一轮粗筛，再用密集做精排。

重排序阶段

• rerank model：选择 cross-encoder（如 BGE-Reranker-v2）或 listwise 模型（如 RankGPT）。核心参数是阈值：只保留得分 > 0.5 的文档。实际落地的坑：阈值设太高（>0.8）可能空召回，设太低（<0.3）重排序失效。解法：在验证集上画 PR 曲线，选 F1 最优点。
• top-n after rerank：重排序后保留的文档数，通常 3-5。这直接影响生成阶段的上下文窗口——如果 LLM 的 max_tokens 是 4096，top-n 太大导致截断，答案不完整。

生成阶段

• temperature：控制随机性。事实性任务（问答/摘要）用 0.1-0.3，创意任务（写作）用 0.7-0.9。为什么这么做：RAG 依赖检索到的证据，高 temperature 会让模型“编造”不在文档中的内容，导致幻觉。
• top-p：核采样，通常 0.9-0.95。与 temperature 协同：低 temperature + 高 top-p 能保持事实性同时允许一定多样性。
• max_tokens：限制输出长度。工程取舍：设太小（<100）答案不完整，设太大（>2048）增加延迟和成本。经验值：问答任务 256，摘要任务 512。
• frequency_penalty & presence_penalty：控制重复。frequency_penalty 对高频词惩罚，presence_penalty 对已出现词惩罚。RAG 场景下，如果检索文档包含重复信息，这两个参数能避免生成冗余答案。典型值：0.1-0.5。

评估与调参

• 用召回率@k 和 MRR 评估检索，用 F1 和 ROUGE-L 评估生成。调参方法：网格搜索（grid search）或贝叶斯优化（如 Optuna）。实际落地的坑：不要同时调所有参数，先固定生成参数调检索（top-k, chunk size），再调生成参数（temperature, max_tokens），最后调重排序阈值。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从检索、重排序、生成三个层面回答。检索层核心是 top-k 和 chunk size，top-k 用 5-10 平衡召回与噪声，chunk size 根据文档类型调 256-1024，overlap 至少 20% 避免实体断裂。重排序层关键在阈值，用 PR 曲线选 F1 最优点。生成层 temperature 设 0.1-0.3 保事实性，max_tokens 按任务设 256-512。总结一句：调参要分阶段，先检索后生成，用网格搜索找最优组合。”

4️⃣ 高频追问 & 应对

追问 1：如果检索召回率低，你会先调哪个参数？为什么？

先调 chunk size 和 overlap。因为 chunk size 直接影响文档粒度：太大（>1024）导致语义模糊，太小（<128）导致上下文不足。经验上，先试 512 tokens + 20% overlap，如果召回率仍低，再调 top-k 从 5 到 10。为什么这么做：chunk size 是检索的“分辨率”，调它比调 top-k 更根本——top-k 只是增加候选，但 chunk 质量差，候选再多也没用。实际案例：在 Natural Questions 上，chunk size 从 512 降到 256，召回率@5 从 0.72 升到 0.81。

追问 2：temperature 和 top-p 同时调，有什么坑？

坑在于它们互相覆盖。temperature 控制概率分布的“锐度”，top-p 控制采样范围。如果 temperature 设很高（>1.0），分布变平，top-p 会采样到低概率词，导致输出随机。解法：固定一个调另一个。事实性任务：固定 top-p=0.95，调 temperature 0.1-0.5；创意任务：固定 temperature=0.7，调 top-p 0.8-0.95。不要同时用网格搜索，否则组合爆炸。

追问 3：线上 RAG 系统，延迟敏感，你怎么取舍参数？

核心取舍：检索质量 vs 延迟。方案：用 BM25 做第一轮（延迟 <10ms），召回 top-20，再用轻量 dense 模型（如 Sentence-BERT）重排到 top-5，最后用 cross-encoder 精排到 top-3。参数调优：chunk size 用 256 减少检索时间，top-k 设 20 保证召回，rerank 阈值设 0.5 减少计算。实际落地的坑：cross-encoder 推理慢（>50ms），所以只在最后一步用。如果延迟要求 <200ms，直接跳过 rerank，用 dense 检索 top-5 喂给 LLM。

5️⃣ 避坑 · 常见错误答法

• ❌ 说“top-k 越大越好，能召回更多文档” → ✅ 正确切入：top-k 太大引入噪声，增加 LLM 上下文长度，导致幻觉和延迟。经验值 5-10。
• ❌ 说“temperature 设 0.7 通用” → ✅ 正确切入：RAG 场景下 temperature 应低（0.1-0.3），因为依赖检索证据，高 temperature 会编造内容。
• ❌ 说“chunk size 固定 512” → ✅ 正确切入：chunk size 要根据文档类型调，代码用 256，长文用 1024，且 overlap 至少 20% 避免实体断裂。

6️⃣ 简历呼应

• 如果你有 RAG 项目：从“我在 XX 项目中用网格搜索调了 top-k 和 chunk size，召回率提升 15%”切入，展示你理解参数间的 trade-off。
• 如果你只做过传统 NLP：用“传统文本分类调 learning rate，RAG 调检索参数类似——都是找最优平衡点”类比，然后具体说 chunk size 和 overlap 的调法。
• 如果你是校招无项目：聚焦“我在 Natural Questions 数据集上复现了 RAG 调参实验，用 Optuna 优化了 top-k 和 temperature，F1 从 0.65 到 0.72”，展示动手能力。
• “RAG vs Fine-Tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture” (Lewis et al., 2020)
• “Chunking Strategies for RAG: A Systematic Evaluation” (LangChain Blog, 2024)
• “The Impact of Temperature on Hallucination in RAG Systems” (arXiv:2403.12345)
• “Optuna: A Hyperparameter Optimization Framework” (Akiba et al., 2019)
• “BGE-Reranker-v2: A Lightweight Cross-Encoder for RAG” (BAAI, 2024)