AI 应用如何验收模型拒答：状态判断、拒答字段与用户提示边界

线上客服助手突然开始把部分请求显示成“没有结果”。排查时最容易犯的错，是把所有空内容都当成模型拒答，再让用户重试。实际上，提示在进入模型前被拦截、候选答案生成后被安全过滤、输出碰到长度上限，以及接口本身失败，往往对应完全不同的处理动作。

验收模型拒答要看提供商返回的状态字段和安全反馈，不能只看 HTTP 200、空字符串或一句“请重试”。

先把“没有答案”拆成四种现场

一个统一的 NO_CONTENT 很省事，却会把排障线索一起抹掉。建议在服务端保留四类原始信号：

• 提示被拦截：请求尚未产生候选答案，通常有 prompt 级的阻断原因。
• 响应被拒答：候选生成阶段触发安全策略，返回结束原因或安全评级，但不一定有正文。
• 正常未完成：例如达到输出上限，内容可能是半截 JSON 或不完整句子。
• 服务异常：超时、限流、权限或连接失败，不能伪装成内容拒答。

这四类状态的重试策略不同。安全拒答不应盲目重复同一输入；截断要考虑补续或缩短输出；网络异常才适合进入退避重试。

用供应商字段判断，而不是猜空字符串

以 Gemini API 为例，官方文档把提示反馈放在 promptFeedback，提示被阻断时会设置 blockReason；候选响应则通过 finishReason 和 safetyRatings 提供反馈。响应因安全原因被阻断时，正文不会返回。可参考 Gemini 安全设置 与 GenerateContentResponse 字段说明。

这里有一个实用顺序：先检查传输层是否成功，再检查顶层提示反馈，最后逐个检查候选的结束原因。不要因为 HTTP 200 就直接读取 candidates[0].content。

if transportErr != nil {
    return StatusTransportFailure
}
if resp.PromptFeedback != nil && resp.PromptFeedback.BlockReason != "" {
    return StatusPromptBlocked
}
if len(resp.Candidates) == 0 {
    return StatusNoCandidate
}
switch resp.Candidates[0].FinishReason {
case "SAFETY", "PROHIBITED_CONTENT", "BLOCKLIST":
    return StatusResponseRefusal
case "MAX_TOKENS":
    return StatusTruncated
default:
    return StatusCompleted
}

示例中的枚举名只是内部映射示意，实际接入时应以对应 SDK 的常量和版本文档为准。关键是保留原始字段，避免把供应商差异藏在一层无法追溯的布尔值里。

让前端拿到可行动的提示

服务端可以把状态归一化为 prompt_blocked、response_refused、truncated、temporary_failure 和 completed。前端只消费这层稳定协议，供应商更换时不用重写页面。

用户文案要告诉他下一步，而不是泄露内部审核规则。例如：

• prompt_blocked：换一种更具体、合规的问法再试。
• response_refused：这个请求无法提供，建议改问相关的安全信息。
• truncated：结果过长未完整生成，可以缩小范围或分段请求。
• temporary_failure：服务暂时不可用，稍后重试；页面可保留重试按钮。

不要把原始 blockReason、安全类别、内部策略版本直接展示给终端用户，也不要承诺“换个词就一定能通过”。日志里可以记录脱敏后的类别、模型版本、请求关联号和状态转换。

把拒答验收写成回归用例

至少准备四组固定样本：一条正常问题、一条会触发输入拦截的样本、一条可能触发响应安全过滤的样本，以及一条把输出上限压低的长回答。每次升级模型、SDK 或安全配置后，检查以下结果：

1. 状态是否落入正确的内部枚举，而不是统一变成空成功。
2. 拒答时是否没有把半截正文当成答案缓存。
3. 截断时是否明确标记未完成，JSON 接收方是否拒绝不完整对象。
4. 临时错误是否带关联号，并且只在安全范围内退避重试。
5. 用户提示是否稳定、简短，日志是否没有保存不必要的敏感原文。

上图的重点不是某一家 API 的字段，而是把“输入阶段”和“输出阶段”分开。这样做后，监控可以分别统计提示拦截率、响应拒答率和截断率，异常上升时更容易定位配置还是流量问题。

失败处理要留在服务端门禁里

如果把判断放到浏览器，调用方可能绕过状态校验，把拒答文本写入缓存或下游工单。服务端应在写缓存、调用工具、生成摘要前再次检查归一化状态：只有 completed 才能进入后续业务；truncated 只能进入补救流程，其他状态直接结束本次链路。

监控告警也应按状态拆开。短时间内 temporary_failure 增长，优先看依赖和配额；response_refused 增长，优先核对输入分布、策略配置和最近的提示词改动。两者混在一条“AI失败率”曲线里，值班人员很难做出正确动作。

常见问题

HTTP 200 但没有正文，算接口失败吗？

不一定。先看顶层反馈、候选数量和结束原因；它可能是合法的安全拒答或提示拦截。只有传输或服务层明确失败时，才归入接口异常。

拒答后要不要自动换提示词重试？

不要把重试当成绕过策略。可以引导用户缩小范围、改成合规的知识性问题，并由服务端重新做完整状态判断。

为什么截断不能直接当拒答？

截断表示生成过程达到上限，内容可能本身没有安全问题。它需要分段、缩短或补续，而拒答通常需要改变请求目标或直接结束。

总结

模型拒答验收的核心是保留证据、统一状态、分开恢复路径。把提示反馈、候选结束原因、输出完整性和传输错误分别记录，再用服务端门禁保护缓存和下游动作，前端才能给出既诚实又有帮助的提示。