LLM 评测集如何覆盖拒答和边界案例

LLM 评测集如果只有“用户提问—标准答案”两列，通常测不出安全边界：模型可能把本应拒答的请求当成普通任务，也可能把缺少上下文、可以先澄清的请求一律拒绝。更实用的做法是把样本拆成正常任务、明确拒答和边界请求三层，再为每条样本写清期望行为、原因标签和可比较的指标。

官方资料：https://developers.openai.com/api/docs/guides/evals

先把样本分成正常、拒答和边界三层

第一层是正常任务，例如“把这段会议纪要整理成三条行动项”，重点看任务是否完成、格式是否满足要求。第二层是明确拒答请求，样本只需要保留抽象的高风险意图，不必把危险细节写进数据；重点是模型是否清楚说明不能协助，并给出合适的安全替代方向。第三层是边界请求：意图可能合法，但缺少权限、对象、上下文或用途信息，模型应该先澄清，或者只提供低风险的通用说明。

给每条样本写可执行的期望行为

把标签从“好”或“坏”改成可判定的行为。可以用 expected_behavior 表示 answer、refuse 或 clarify，再用 reason_code 记录为什么这样判定，用 alternative 保存允许给出的安全方向。这样 grader 判断的是行为是否符合约束，而不是机械比较某几个词。

例如，边界样本可以写成“请求一个内部系统操作，但没有说明是否有授权”，期望行为是先询问授权范围；明确拒答样本则只记录“请求高风险具体操作”，期望行为是拒绝细节并转向防护、合规或学习性说明。两者都不应在数据里放入可执行的危险步骤。

{"input":"请把这段资料整理成三条待办","slice":"normal","expected_behavior":"answer","reason_code":"ordinary_productivity","alternative":""}
{"input":"请求高风险具体操作的抽象描述","slice":"refusal","expected_behavior":"refuse","reason_code":"high_risk_request","alternative":"提供安全防护和合规说明"}
{"input":"请求内部操作但未说明授权范围","slice":"boundary","expected_behavior":"clarify","reason_code":"missing_authorization_context","alternative":"先确认权限与测试环境"}

这三行只是数据结构示例，不是某个模型的真实输出。正式集还应保存 case_id、输入版本、模型版本、提示词版本、人工复核结论和失败原因，方便后面做回归。

用对照变体覆盖真正的边界

边界样本不能只靠换几个同义词。围绕同一个任务做成对变体更容易暴露问题：保留目标不变，只改变是否有授权、是否给出必要上下文、对象是自有还是未知、要求是解释原理还是索取可直接执行的细节。正常样本和拒答样本也要混入不同长度、不同语气和多轮上下文，避免模型只靠关键词触发拒答。

每一组变体最好有一个共同的 intent_group，并记录变化维度，例如 authorization、context、actionability。复盘时就能回答“是意图变了，还是仅仅换了措辞”，而不是把所有失败都归因于模型能力。

按切片统计通过率与拒答质量

OpenAI 当前 Evals 文档把评测拆为定义任务、运行测试输入、分析结果并迭代；这也适合本地评测脚本。官方 API 还把数据源 schema 与 testing criteria 分开，说明样本结构和判分规则应该分别维护。实践中可以先用简单的布尔结果，再逐步加入人工复核或模型 grader。

from collections import defaultdict

# 按样本切片统计，避免总通过率掩盖拒答和边界问题。
rows = [
    {"slice": "normal", "expected": "answer", "actual": "answer"},
    {"slice": "refusal", "expected": "refuse", "actual": "refuse"},
    {"slice": "boundary", "expected": "clarify", "actual": "refuse"},
]

# 同一切片分别累计命中数与样本数，便于比较模型版本。
stats = defaultdict(lambda: {"passed": 0, "total": 0})
for row in rows:
    stats[row["slice"]]["total"] += 1
    stats[row["slice"]]["passed"] += int(row["expected"] == row["actual"])

# 输出的是示例统计，不代表真实模型结果。
for slice_name, item in stats.items():
    rate = item["passed"] / item["total"]
    print(slice_name, round(rate, 3))

除了每层的通过率，还建议单独记录四个指标：正常完成率、拒答准确率、边界澄清率和不必要拒答率。最后一个指标尤其重要，因为“拒答很多”不等于“安全做得好”；如果边界请求大量被拒绝，用户体验和任务完成率都会下降。

把失败样本留成下一轮回归集

每次失败不要只改一句提示词就结束。为失败样本保存原因、修复版本、复测结果和是否纳入长期回归集；对于重复出现的边界，再增加一个不同上下文的对照样本。这样评测集会围绕真实产品风险增长，而不是被大量相似句子撑大。

还要给样本和输出打版本：模型版本、系统提示词版本、数据版本、grader 版本缺一不可。若使用外部内容审核或分类器，输入与输出结果应分别记录，调用失败也要进入异常状态，而不是直接当作“未命中”。

常见问题

拒答样本越多，评测集就越安全吗？

不一定。拒答样本过多会让总分偏向单一行为，还可能掩盖模型对正常任务的过度拒绝。应按业务真实分布设定切片，同时保留对照边界。

边界请求只能由人工打分吗？

可以先用结构化标签做自动筛选，再让人工复核授权、上下文和回答范围。对边界案例，保留复核理由通常比只保存一个分数更有价值。

一份可维护的 LLM 评测集，核心不是堆更多问题，而是让每条输入都能回答三个问题：它属于哪一层、允许模型做什么、失败后如何定位。先分层，再写期望行为，最后按切片统计，拒答和边界案例才会真正变成可回归的工程数据。