模型退化与失败处理
核对日期:2026-05-09。
1. 定义与边界
模型退化是指同一类任务在模型、提示词、上下文、工具、负载或供应商状态变化后质量下降。失败处理覆盖输出错误、格式错误、幻觉、工具误调、超时、限流、上下文截断、安全拒绝和供应商不可用。
2. 为什么重要
Agent 是长链路系统,任何一个环节退化都会放大到最终任务失败。没有回放、评测和降级策略时,团队只能靠用户投诉发现问题。
3. 核心机制
| 失败类型 | 典型信号 | 处理 |
|---|---|---|
| 格式失败 | JSON 解析失败、schema 不匹配 | 结构化输出、修复重试、回退 |
| 事实失败 | 无证据断言、引用不存在 | 检索重跑、验证器、拒答 |
| 工具失败 | 参数错误、权限拒绝、超时 | 参数校验、重试、人工升级 |
| 行为退化 | 成功率下降、调用工具变多 | 回归评测、模型/提示词回滚 |
| 安全失败 | 注入成功、敏感信息泄露 | 阻断、告警、审计 |
| 供应商失败 | 5xx、限流、区域故障 | fallback、队列、熔断 |
4. 架构模式
5. 工程实现
错误对象需要可聚合:
{
"error_type": "tool_argument_invalid",
"model": "primary_reasoning",
"prompt_version": "agent-system-v12",
"tool_schema_version": "crm-v7",
"route_id": "sales_ops",
"recoverable": true,
"retry_count": 1
}
重试策略:
if error.is_transient and retry_count < 2:
retry_same_model()
elif error.is_format_error:
retry_with_repair_prompt()
elif error.is_quality_error:
fallback_to_stronger_model()
else:
escalate_to_human()
6. 生产实践
- 为每个关键路径配置熔断:错误率、延迟、成本、限流达到阈值时暂停自动执行。
- 对模型、提示词、工具 schema 和检索索引做版本化,支持回滚。
- 上线新模型先跑 shadow traffic,再逐步放量。
- 高权限工具失败后不要自动扩大权限。
- 保留最小必要上下文用于回放,敏感数据需脱敏或加密。
7. 常见反模式
| 反模式 | 后果 |
|---|---|
| 无限自动重试 | 成本泄漏、外部系统压力 |
| 失败时直接换更强模型 | 没有定位 schema、权限或数据问题 |
| 不记录 prompt/tool 版本 | 无法复现 |
| fallback 绕过审批 | 安全边界被破坏 |
| 只看用户评分 | 发现问题太晚 |
8. 评测方法
需要持续评测而不是一次性评测。建议建立每日离线回归、线上抽样人工复核、安全对抗集和事故复盘数据集。每次模型或提示词变更必须比较成功率、工具准确率、安全违规率、成本和延迟。
9. 安全与治理
失败处理不能泄露内部策略、密钥、工具返回或用户隐私。对安全类失败要阻断并审计,而不是让模型“再试一次”。对 prompt injection 成功样本要进入红队回归集。
10. 退化监测框架
模型退化要分“能力退化”和“系统退化”。很多线上问题看起来像模型变差,实际是工具 schema、检索索引或路由规则变化。
| 退化来源 | 监测信号 | 定位方法 |
|---|---|---|
| 模型版本 | 同一回归集成功率下降 | 固定 prompt/schema 重放 |
| 提示词 | 工具调用率、拒绝率突变 | 比较 prompt version |
| Schema | invalid_arguments 增加 | 查看 schema diff |
| 检索 | 引用缺失、无关证据增加 | 检查索引和召回 |
| 路由 | 高风险任务走错模型 | route trace 聚合 |
| 供应商 | 5xx、限流、延迟升高 | provider status 和错误码 |
11. Fallback 策略
failure_policy:
format_error:
action: repair_retry
max_attempts: 1
tool_argument_invalid:
action: ask_clarification_or_repair
max_attempts: 1
provider_rate_limited:
action: fallback_provider
require_data_policy_check: true
quality_gate_failed:
action: stronger_model_with_verifier
max_attempts: 1
safety_policy_failed:
action: deny_and_audit
retry: false
high_risk_uncertain:
action: human_review
降级要遵守两条硬规则:
- fallback 不能放宽权限、安全和审计要求。
- fallback 后必须在 trace 里记录原因、模型、策略版本和最终结果。
12. Eval Gate 与发布门禁
发布前检查:
| 门禁 | 阈值示例 |
|---|---|
| 关键任务成功率 | 不低于当前生产版本 |
| 高风险越权阻断 | 100% |
| 工具参数合法率 | 不下降,或下降需解释 |
| p95 延迟 | 不超过 SLA |
| 成本/成功任务 | 不超过预算 |
| 回放完整率 | 100% trace 可关联模型和工具版本 |
13. 工程示例:事故响应 Runbook
1. 冻结自动放量,记录影响 route 和版本。
2. 从 trace 聚合失败类型:format、tool、policy、quality、provider。
3. 用最近 50 到 200 条失败样例重放旧版本和新版本。
4. 如果旧版本恢复,执行模型/prompt/schema 回滚。
5. 如果旧版本也失败,检查工具、检索、供应商、权限系统。
6. 高风险动作逐条审计,确认是否产生外部副作用。
7. 将事故样例加入回归集和红队集。
14. 安全补充:失败时不要扩大权限
常见危险处理包括:
- 权限失败后让模型“换个方式试试”。
- 工具超时后重复提交写操作且无幂等键。
- 供应商失败时切到未批准区域或供应商。
- 安全拒绝后要求模型换一种措辞绕过。
- 为了修复格式错误放宽 schema 到任意 JSON。
这些都应进入安全门禁的禁止项。
15. 权威资料
- OpenAI Error codes: https://platform.openai.com/docs/guides/error-codes
- OpenAI Agents SDK tracing: https://openai.github.io/openai-agents-python/tracing/
- Anthropic error docs: https://docs.anthropic.com/en/api/errors
- MCP security best practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
- OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/