概率型 AI 服务的降级策略：不要让备用结果伪装成同等可靠

调用外部 AI 服务时，很多系统会把“自动重试”和“本地备用结果”当作可用性优化：主服务失败就重试，仍然失败就切换备用路径，尽量让用户看到一个结果。

这套思路对确定性任务可能有效，但放到概率型检测上会产生一个隐蔽问题：备用路径返回了数字，不代表它与主服务具有相同的可靠性。如果 UI 仍然使用同一套颜色、结论和文案，系统实际上把一次降级伪装成了正常成功。

先区分三类失败

重试策略不应该从 catch 开始，而应该从错误分类开始。

第一类是输入错误。例如文本少于最小长度、超过最大长度、文件过大、格式不在允许范围，或文档没有抽取出正文。这类错误不会因为重试而消失，应立即返回可执行的修改建议。

第二类是可重试故障，例如超时、临时网络错误、提供方短暂不可用。这类错误适合有限次数重试，并使用退避策略避免放大故障。

第三类是终止错误，例如明确的参数拒绝、不可恢复的解析失败或已知不支持条件。继续重试只会增加延迟和请求成本。

只有第二类故障才适合进入备用路径。否则，备用逻辑会掩盖输入问题，或者把本应停止的错误变成一个来源不明的分数。

降级结果必须携带可靠性信息

概率型结果至少需要两组信息：模型输出和运行路径。

模型输出可以包含 verdict、risk、AI 相关分数和 likely-human 分数；运行路径则应记录结果来自主服务还是备用策略、是否发生过重试、当前 evidence strength 如何，以及是否有需要用户注意的限制。

这不是为了向用户暴露内部实现细节，而是为了避免不同质量的结果在界面上看起来完全一样。系统可以不展示提供方名称，但必须让用户知道“本次证据较弱”或“本次使用了可靠性较低的备用分析”。

如果报告支持导出，可靠性标记也要进入导出内容。否则，页面上看得到的提示会在打印或复制后丢失，留下一个脱离上下文的分数。

重试次数不是越多越好

概率型检测通常位于用户主动触发的交互链路中。重试过多会让按钮长时间停在加载状态，也会提高触发频率限制的概率。

更合理的策略是：

1. 在客户端先完成字符数、文件类型和大小校验。
2. 文档抽取与检测调用使用不同错误状态。
3. 主服务只对明确可重试错误进行有限重试。
4. 进入备用路径时降低 evidence strength，并显示限制提示。
5. 所有路径最终都返回统一结构，但不能抹平可靠性差异。

统一结构方便前端渲染，可靠性字段负责保留事实。二者并不冲突。

句级信号比强行收敛到单一结论更有用

AI 检测报告如果只剩一个总分，用户很难判断下一步该检查什么。更实用的结构是同时提供整体风险、证据强度、分析说明和句级高亮。

句级高亮也只能表示相关信号，不能写成某句话“确定由 AI 生成”。当备用路径的可靠性更低时，这条边界更重要：系统应该减少确定性措辞，而不是用更强的颜色补偿模型不确定性。

降级不能突破产品边界

无论走主服务还是备用路径，AI 检测都可能出现误报和漏报。结果不能证明作者身份、抄袭、不当行为或确定使用了 AI，也不能作为学业、就业、法律、纪律处分等高影响决策的唯一依据。

同样，系统不应因为有备用逻辑就承诺无限可用、零日志、完全本地处理或所有文档都能成功分析。降级提升的是部分故障下的可用性，不是消除所有限制。

小结

概率型服务的降级设计，核心不是“无论如何都返回一个数字”，而是让每个结果都保留自己的可靠性上下文。

先分类错误，再限制重试，只在合适的故障上启用备用路径，并把 evidence strength、运行路径和限制带入报告。这样，可用性优化才不会反过来伤害结果可信度。

本文的具体实现思考来自 Detector de IA 的文本与文档检测工作流。这里保留产品名作为案例，不提供正文跳转链接。