| 18 | What are the key hyperparameters in a RAG pipeline

P1 · rag

🏷 标签：rag, hyperparameters, pipeline

1️⃣ 考察意图

面试官想看你是否真正动手调过RAG，而非只背概念。这道题表面问“有哪些超参数”，实则在考察你对检索与生成两阶段耦合的理解深度。刁钻点在于：多数人只列参数名，但说不出每个参数在什么场景下该调、调了会牺牲什么（如top-k增大提升召回但降低精度，温度调高增加多样性但可能偏离事实）。答好了能展示你从“调参工”到“系统设计者”的跃迁，具备对延迟、成本、质量三者的工程权衡能力。

2️⃣ 标准答

RAG pipeline 的超参数可按 检索阶段、生成阶段、融合策略 三个维度拆解，每个维度都有核心参数和工程取舍。

检索阶段

分块大小（chunk_size）与重叠（overlap）：典型值 chunk_size=256-512 tokens，overlap=10-20%。取舍：块越大语义越完整但检索粒度粗，块越小召回率高但上下文碎片化。坑：对代码文档用512 token块，对FAQ用128 token块，统一值会导致一端性能崩。解法：按文档类型动态分块（如基于标题层级切分）。
top-k 值：通常 3-10。取舍：k=1 延迟最低但可能漏关键证据；k=10 召回提升但引入噪声，且生成阶段需处理更多上下文，增加LLM推理成本。实战：在问答场景用 k=5，在摘要场景用 k=3，通过离线评估（Recall@k）确定最优值。
检索器类型参数：稀疏检索（BM25）的 k1=1.5, b=0.75 控制词频饱和与文档长度归一化；稠密检索（DPR/ColBERT）的 embedding 维度（768/1024）和索引类型（HNSW 的 ef_construction=200, M=16）影响召回与延迟。取舍：HNSW 的 ef_search 越大召回越好但延迟线性增长，生产环境通常设 ef_search=40-100 平衡。
嵌入模型选择：如 text-embedding-3-small（1536维）vs bge-large-en（1024维）。取舍：大模型精度高但推理慢，小模型适合高吞吐场景。坑：不同语言模型混用导致向量空间不对齐，必须统一模型。

生成阶段

温度（temperature）：0.1-0.7 用于事实型问答（低温度），0.8-1.0 用于创意生成。取舍：温度=0 时输出确定性最高但可能重复，温度>0.7 时幻觉风险上升。实战：在RAG中建议温度≤0.3，因为检索已提供事实，生成只需忠实总结。
top-p（nucleus sampling）：通常 0.9-0.95。与温度协同：先截断低概率词，再按温度缩放。坑：同时调高温度和top-p会导致输出失控，建议固定一个调另一个。
max_tokens：控制生成长度。取舍：设太短截断答案，设太长浪费算力且可能偏离。经验：对单轮问答设 512，对多文档摘要设 1024。
频率惩罚（frequency_penalty）与存在惩罚（presence_penalty）：值 0-2。取舍：频率惩罚减少重复但可能抑制关键术语，存在惩罚鼓励新词但可能引入无关内容。实战：在RAG中通常设为 0，因为检索内容已保证多样性。

融合策略

重排序（reranker）参数：如 Cohere Rerank 的 top_n（通常 3-5）。取舍：reranker 精度高但延迟大（每请求增加 50-200ms），只在 top-k 结果上 rerank 而非全量。
权重分配：多路检索（BM25+稠密）时，线性加权融合分数（如 α=0.3 给 BM25, 1-α 给稠密）。取舍：α 需通过验证集搜索，固定值无法适应查询类型变化。解法：用轻量级分类器（如基于查询长度）动态调整 α。

系统级参数

批处理大小（batch_size）：嵌入生成时 16-64。取舍：大 batch 提升吞吐但增加显存，小 batch 适合低延迟场景。
缓存策略：对高频查询缓存检索结果（TTL=1小时）。取舍：缓存提升延迟但牺牲实时性，适合新闻类但不宜用于金融数据。

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

“这个问题我从检索、生成、融合三个层面回答。检索层面关注分块大小、top-k 和检索器参数，比如 chunk_size 256-512 平衡粒度与语义，top-k 3-5 控制召回与噪声。生成层面温度设 0.1-0.3 保证事实性，max_tokens 按场景设 512-1024。融合层面用 reranker 的 top_n 3-5 精排，多路检索时动态权重分配。总结一句：RAG 调参本质是在召回率、精度、延迟和成本之间做四维权衡，没有万能参数，必须通过离线评估和 A/B 测试确定。”

4️⃣ 高频追问 & 应对

追问 1：你如何确定最优的 top-k 值？能给出具体实验设计吗？

用离线评估：准备 1000 条 query-answer 对，对每个 query 检索 top-1 到 top-10 的文档，计算 Recall@k（答案是否在检索结果中）和 Precision@k（检索结果中相关文档比例）。画曲线找拐点——比如 k=5 时 Recall 达到 90%，k=7 只提升到 92% 但延迟增加 40%，就选 k=5。生产环境再结合在线指标（如用户点击率）微调。

追问 2：如果生成结果总是重复检索内容，你调哪个参数？

先排查温度是否过低（<0.1），调高到 0.3 增加多样性。如果仍重复，检查 max_tokens 是否设得太小导致截断。更深层原因可能是分块重叠过大（>30%），导致多个块包含相同内容，LLM 被迫重复。解法：降低重叠到 10%，或在 prompt 中加“不要逐字复述，用你自己的话总结”。

追问 3：在延迟敏感场景（如实时客服），你如何取舍这些参数？

牺牲精度换延迟：top-k 从 5 降到 3，reranker 去掉或用轻量级模型（如 MiniLM），嵌入模型换小版本（如 text-embedding-3-small 替代 large）。分块大小固定为 256 token 减少检索计算。生成阶段 max_tokens 设 256，温度固定 0.2。系统层面：对常见问题做缓存（TTL=5分钟），批处理大小调大（batch_size=64）提升吞吐。最终延迟目标控制在 500ms 以内。

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

❌ 只列参数名（如“top-k、温度、分块大小”）不解释影响 → ✅ 每个参数给出典型值、工程取舍和场景适配，如“top-k=5 在问答场景平衡召回与噪声，但摘要场景需降到 3 避免冗余”。
❌ 说“温度越高越好”或“分块越小越好” → ✅ 强调 trade-off，如“温度 0.1-0.3 保证事实性，但创意场景可调高到 0.7，同时需配合 reranker 过滤幻觉”。
❌ 忽略系统级参数（缓存、批处理） → ✅ 补充“缓存策略降低延迟 50%，批处理大小影响吞吐，这些在生产环境比模型参数更关键”。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在 XX 项目中用网格搜索调优 top-k 和温度，将准确率从 72% 提升到 85%，同时延迟降低 30%”切入，强调离线评估和 A/B 测试。
如果你只做过传统 NLP：用“传统文本分类调参（如学习率、batch size）类比 RAG 调参，核心都是平衡偏差与方差，但 RAG 多了检索与生成的耦合”迁移，展示系统思维。
如果你是校招无项目：聚焦“复现 LlamaIndex 的调参 demo，用 BM25+稠密检索对比不同 chunk_size 对召回的影响，输出调参指南”，体现动手能力和方法论。
《RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture》
LlamaIndex 官方文档：Hyperparameter Tuning for RAG Pipelines
《When Not to Trust Language Models: Investigating Effectiveness of Parametric and Non-Parametric Memories》
Cohere Rerank 最佳实践：Balancing Precision and Latency
《Efficient Estimation of Word Representations in Vector Space》——理解 embedding 维度影响

—— 本场面试完 ——