AI 应用拒答率怎么单独评估：安全拒答、业务失败与通过率拆分

AI 客服上线后，报表里只有一个“拒答率”往往不够用：该拒绝的请求被拦住，属于安全结果；本来可以回答的订单查询却被模型判成高风险，才是真正的业务损失。把两类情况混在一个百分比里，团队很容易为了降低拒答率而放松安全边界，也可能为了追求安全分数而让正常用户频繁碰壁。

判断一套拒答策略是否可用，关键不是“拒绝得越多越安全”，而是模型能不能在正确的边界上停下来：危险请求不提供有害细节，正常任务仍然完成，拿不准的场景有明确的转人工或降级路径。

先把四种结果从一个拒答率里拆出来

可以为每条测试样本保存 expected_action 和 actual_action。期望动作至少分为 allow、safe_refuse、handoff 三类，实际结果则记录模型是否回答、是否给出安全替代、是否触发工具或转人工。这样“拒答”不再是唯一维度。

如果业务存在无法自动判断的灰区，可以把转人工单独作为第四种期望动作。不要把所有人工转接都算成失败，否则模型会被迫在“胡乱回答”和“全部拒绝”之间做错误选择。

指标要同时看安全边界和业务可用性

对危险样本，重点看安全拒答召回率：应该拒绝的样本中，有多少真的没有输出有害操作细节。对正常样本，重点看通过率和过度拒答率；它们比一个总拒答率更能解释用户为什么卡住。

def ratio(numerator, denominator):
    return numerator / denominator if denominator else 0.0

safe_recall = ratio(correct_safe_refusals, expected_safe_refusals)
over_refusal = ratio(allow_but_refused, expected_allow)
business_pass = ratio(allow_and_completed, expected_allow)
unsafe_pass = ratio(unsafe_but_allowed, expected_safe_refusals)

这里的 unsafe_pass 是高优先级告警，即使样本只有几十条，也不能被整体平均数掩盖。实际报告建议按风险等级、语言、输入长度、是否多轮和是否调用工具分别分组，避免“总体不错”掩盖某一类边界已经失守。

测试集不能只有明显危险句子

一套有用的测试集应同时包含四类样本：明显需要拒绝的请求、语义接近但应正常处理的请求、需要转人工的业务灰区，以及带有上下文诱导的多轮请求。安全评测公开资料也会区分拒绝危险请求与不应拒绝的正常请求，这正是过度拒答需要单列的原因。

1. 为每条样本写清风险标签、期望动作和允许出现的安全替代，不让评测员临场猜标准。
2. 给同一意图准备改写、错别字、口语表达和多轮版本，检查策略是否只记住了固定关键词。
3. 把工具权限、系统提示、模型版本和最大重试次数写入运行清单，逐次回放时保持一致。
4. 对命中灰区的样本记录转人工原因，不能只留下一个“拒答”布尔值。

特别要防止把模型的解释性话术当成安全通过。只要回答仍然给出了不应提供的关键步骤，就不能因为开头写了提醒语而计入安全拒答。

用固定回放确认版本变化到底改了什么

每次改系统提示、内容安全规则或模型版本，都用同一份冻结样本跑一遍，并保存原始输入、最终文本、工具调用、判定标签和运行配置。比较时先看不安全通过，再看过度拒答，最后才看总通过率。

• 安全门：不安全通过为零或低于事先批准的阈值，任何新增高风险案例都必须人工复核。
• 可用性门：正常请求通过率没有超过业务可接受的下降范围，过度拒答按场景分组定位。
• 一致性门：同一输入在相同配置下重复运行不会产生无法解释的动作漂移。
• 恢复门：模型拒答或工具失败时，产品有转人工、改问法或稍后重试的明确路径。

OpenAI 的公开评测材料同时报告“不能产生不安全输出”和“不应过度拒绝”两类结果；这类拆分也适合普通 AI 应用做工程验收。它不会替团队定义具体阈值，但能避免把安全与可用性压缩成一个漂亮、却无法行动的数字。

常见问题

拒答率越低是不是说明模型更好？

不是。拒答率下降可能来自正常请求恢复，也可能来自危险请求被错误放行。必须同时检查安全拒答召回率和不安全通过案例。

过度拒答应该由谁标记？

由业务方和安全评审共同定义期望动作。安全团队负责边界，业务方负责判断正常任务是否真的可完成，不能只靠模型自己打分。

多轮对话为什么要单独测？

前几轮上下文可能改变风险判断，也可能让模型在最后一步丢掉原本的拒答边界。多轮样本应保留完整上下文并单独统计。

工具调用失败算拒答吗？

不一定。工具超时、权限不足和参数错误属于业务或系统失败，应与安全拒答分开记录，否则修复方向会被带偏。

把评测结果变成发布门禁

发布报告至少要能回答四个问题：哪些请求应该拒绝，哪些请求被误拒绝，是否出现新的不安全通过，遇到灰区后用户能否继续完成任务。只要最后一个问题没有答案，即使总体分数很好，也不适合直接扩大流量。