2 为什么评测问题必须覆盖不同任务类型
P0 · rag
🏷 标签：rag, evaluation, task-coverage, generalization
1️⃣ 考察意图
面试官想看你是否理解评测集设计的核心原则——任务覆盖度，而非仅仅会跑一个指标。这属于系统设计+工程取舍类问题，刁钻点在于：很多人以为评测就是堆问题，但真正关键的是如何用有限样本暴露系统在真实场景下的泛化瓶颈。答好了能展示你对 RAG 系统鲁棒性评估的深度认知，以及从错误模式反推优化方向的能力。
2️⃣ 标准答
评测问题必须覆盖不同任务类型，核心原因是单一任务评测会掩盖系统在特定场景下的致命弱点。RAG 系统不是黑盒，它由检索器、生成器、甚至路由模块组成，不同任务对每个模块的压力完全不同。
1. 不同任务暴露不同模块的瓶颈
- 事实问答（如“巴黎是哪个国家的首都？”）：主要考验检索器的精确匹配能力，生成器只需简单复制。如果只测这类，你会误以为系统很强，但一旦遇到多跳推理（如“巴黎所在国家的现任总统是谁？”），检索器需要两次召回（巴黎→法国→总统），生成器需要逻辑组合，系统可能直接崩溃。
- 数值计算（如“A公司营收比B公司高多少？”）：考验检索器对表格/数字的召回精度，以及生成器的算术能力。如果只测事实问答，你永远不知道生成器在数字运算上会胡编乱造。
- 摘要/对比（如“比较两篇论文的核心观点”）：考验检索器对长文本的语义理解，以及生成器的信息压缩能力。单一任务无法暴露检索器在长文档分块（chunking）时的边界错误。
2. 覆盖多任务才能评估泛化能力
- 实际应用场景是混合的：一个客服系统可能同时处理“查订单状态”（事实问答）、“退换货流程”（多步推理）、“对比两款产品”（对比分析）。如果评测只覆盖一种，上线后其他场景的失败率会直接打脸。
- 泛化不是玄学，是可测量的：用 Multi-task Benchmark（如 MMLU、KILT）的思路，每个子任务单独打分，然后看平均分和方差。方差大说明系统偏科严重，需要针对性优化。
3. 实际落地的坑与解法
- 坑：盲目堆问题类型，但样本量不均。比如事实问答 1000 题，多跳推理 50 题，结果多跳推理的失败被淹没在整体指标里。
- 解法：分层采样 + 加权评估。先定义任务类型（至少 3-5 类），每类至少 200 题以保证统计显著性。然后按业务场景给权重（如客服系统 60% 事实问答 + 30% 多跳推理 + 10% 对比），最终得分是加权平均。这样既能暴露弱点，又能反映真实价值。
- 另一个坑：任务类型定义模糊。比如“推理”太宽泛，需要细分为“多跳推理”、“时序推理”、“因果推理”，因为它们的检索策略完全不同（多跳需要链式检索，时序需要时间戳过滤）。
- 解法：用 Taxonomy of Tasks（如 RAGAS 论文中的分类法）来结构化设计，确保每个子任务有明确的输入输出格式和评估指标（如 F1、EM、Correctness）。
4. 工程取舍
- 取舍点：覆盖度 vs. 成本。每类任务 200 题，5 类就是 1000 题，人工标注成本高。可以先用 LLM 自动生成（如用 GPT-4 根据模板生成问题+答案），再人工抽检 20%。但自动生成可能引入噪声，需要设计对抗性过滤（如用另一个模型验证答案是否可检索到）。
- 另一个取舍：任务类型越多，评测结果越难解读。建议先聚焦 3 类核心任务（事实、推理、计算），后续根据业务扩展。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，不同任务类型（如事实问答、多跳推理、数值计算）对检索器和生成器的压力不同，单一任务会掩盖系统在特定场景下的致命弱点；第二，覆盖多任务才能评估泛化能力，通过分层采样和加权评估来反映真实业务分布；第三，实际落地要注意样本量均衡和任务定义清晰，避免被整体指标误导。总结一句：评测覆盖度是暴露系统鲁棒性瓶颈的必要手段，否则就是‘报喜不报忧’。”
4️⃣ 高频追问 & 应对
追问 1：如果资源有限，只能选 3 类任务，你怎么选？
我会按业务场景的高频+高风险原则选。比如客服系统：事实问答（高频）、多跳推理（高风险，用户常问复杂流程）、数值计算（高风险，涉及金额易出错）。然后每类 200 题，用 LLM 自动生成+人工抽检。如果业务是文档摘要，就换为摘要、对比、事实问答。核心是先保业务核心，再扩展。
追问 2：你怎么保证不同任务类型的问题难度一致？否则评测不公平。
这是个好问题。我会用基线系统（如 BM25+GPT-3.5）先跑一遍，每类任务调整问题难度，使得基线得分在 60%-70% 之间。如果某类任务基线得分过高（>90%），说明问题太简单，需要增加干扰项或更复杂的逻辑链。反之，如果得分过低（<30%），说明问题太难，需要简化。这样确保评测能区分系统优劣，而不是被天花板或地板效应淹没。
追问 3：你提到的“对抗性过滤”具体怎么做？
用另一个模型（如 GPT-4）作为裁判，对自动生成的问题+答案对进行验证。比如，对于事实问答，检查答案是否能在给定知识库中检索到；对于多跳推理，检查推理链是否合理。如果裁判认为问题不可解或答案错误，就丢弃。这能过滤掉约 10%-20% 的噪声样本，但会增加成本。取舍点是：如果预算紧张，可以只过滤 50% 的样本，或者用更便宜的模型（如 Llama-3-8B）做初筛。
5️⃣ 避坑 · 常见错误答法
- ❌ “评测问题越多越好，覆盖所有任务类型才能全面评估。” → ✅ “覆盖度不是堆数量，而是结构化设计。需要先定义任务类型，确保每类有足够样本量（至少 200 题），否则整体指标会被稀释。同时要考虑业务权重，否则评测结果脱离实际。”
- ❌ “不同任务类型只是换问题形式，核心评测指标都一样。” → ✅ “不同任务需要不同的评估指标。事实问答用 Exact Match，多跳推理用 F1 或 Correctness，摘要用 ROUGE-L。混用指标会导致结果不可比，必须为每个子任务单独设计评估方案。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我设计了一个包含 3 类任务（事实问答、多跳推理、数值计算）的评测集，每类 200 题，用分层采样和加权评估暴露了系统在推理场景下的 30% 失败率，并据此优化了检索器的链式召回策略”切入，展示实战能力。
- 如果你只做过传统 NLP：用“传统 NLP 评测（如 GLUE）也是按任务分类的，RAG 评测同理，但需要额外关注检索模块的影响”类比迁移，强调你对评测设计原则的通用理解。
- 如果你是校招无项目：聚焦“我复现了 RAGAS 论文中的评测框架，并分析了不同任务类型（如单跳 vs 多跳）对检索器召回率的影响，发现多跳任务下 BM25 的召回率下降 40%”的 demo 经验，展示学习能力。
- RAGAS: Automated Evaluation of Retrieval Augmented Generation（论文）
- KILT: a Benchmark for Knowledge Intensive Language Tasks（论文）
- MMLU: Measuring Massive Multitask Language Understanding（论文）
- LangSmith 评测平台文档：如何设计多任务评测集
- “A Survey on Evaluation of Large Language Models” 中的评测分类章节