拒答与澄清也是"正确的输出"
评测里最常见的偏差是：只统计"答对率" ✗，把"该拒答却答了"和"该澄清却硬答"都算成错误的一部分 ✗，
于是团队会朝"少拒答"优化 ✗ —— 这会把系统推向更爱编 ✗。
正确的做法是把输出分成四类，分别统计 ✔：
- 正确作答（有依据、内容对）；
- 正确拒答（资料不足，明确说"没有找到"）；
- 正确澄清（问题模糊，先问关键限定）；
- 错误作答 / 错误拒答 / 该澄清却硬答。
关键指标是两个"误导率" ✔：
- 该拒答却作答率（资料不足却给了像样的答案 —— 最危险 ❗）；
- 该作答却拒答率（明明有资料却说不知道 —— 用户会觉得没用 ❗）。
怎么构造这两类样本
- 该拒答类：问题涉及资料里确实没有的内容（不要问"无关话题"，要问"相关但未覆盖" ✔）；
- 该澄清类：问题缺少关键限定（时间、范围、对象），看它是否询问而不是假设 ✗；
- 该作答类：资料里明确有答案（用来测过度拒答 ✗）。
每类 20~30 条就能看出趋势 ✔。
常见的两个失败模式
- 过度拒答：保守的提示词 + 高阈值检索 → 什么都说"未找到" ✗ → 用户流失 ✔；
- 伪装拒答：说"根据资料无法确定"，但紧接着给了一段编造内容 ✗ → 这是最坏的一类 ✗，
评测必须检查拒答之后有没有继续断言 ✔。
判据要写进评测标准
正确拒答 = 明确说明资料不足 + 不给出未支持的结论 + 给出可行的下一步（可选）
正确澄清 = 提出 1~2 个关键限定问题，且不预设答案
没有把"拒答/澄清"单列出来的评测集，会系统性高估系统能力 ✗。
与产品侧的对齐
- 界面要把"未找到"做成正常状态（不是错误 ✗），并给出替代路径（换关键词、放宽范围）；
- 但也不能鼓励一问就拒答 ✗ → 用过度拒答率做护栏 ✔；
- 两个指标一起看，才能把系统调到"该说的敢说、不该说的不编" ✔。
落地顺序
- 先给现有评测集补标注（每条标"应为哪一类"）；
- 加两个误导率指标；
- 把"拒答类/澄清类"样本加进流水线（见评测接进 CI 那篇 ✔）。