如何处理 AI 出错的 20-40% 的情况？你们的回滚机制是什么
1️⃣ 考察意图
面试官想考察你对 AI Agent 系统容错设计的实战深度，而非背诵概念。刁钻点在于：20-40% 的错误率是真实生产环境（如客服 Agent、代码生成 Agent）的常见数据，面试官要看你是否经历过从错误检测、分类到回滚、降级的完整完整流程。答好了能展示：你懂工程取舍（如检测精度 vs 延迟）、有踩坑经验（如补偿事务的幂等性）、能设计可观测系统（如错误率告警阈值）。这是 P1 进阶题，区分“只会调 API”和“能扛生产稳定性”的候选人。
2️⃣ 标准答
处理 AI 出错，核心是三步完整流程：错误检测 → 分类与决策 → 回滚/降级。下面按生产环境经验展开。
错误检测：不止是“模型说错了”
- 输出校验：对结构化输出（JSON、SQL、代码）用 schema 校验 + 正则。例如，Agent 返回的 JSON 缺少必填字段，直接标记为“格式错误”，触发重试。坑：模型可能输出合法但语义错误的 JSON（如日期格式对但值错），需加业务规则校验（如“发货日期不能早于下单日期”）。
- 置信度阈值：对生成内容，用模型 logits 算 token 级置信度。低于 0.7 的段落标记为“低置信”，触发二次确认或回退。取舍：阈值设低（0.5）漏检多，设高（0.9）误报多，生产常用 0.7-0.8 动态调整，根据错误率历史数据。
- 用户反馈信号：点赞/踩、超时未响应、重复提问。例如，用户连续 3 次“我不明白”，触发降级到人工。坑：用户反馈有延迟，需结合实时检测做“预回滚”，比如检测到工具调用失败（API 返回 500），立即补偿，不等用户反馈。
错误分类与决策：用有限状态机（FSM）管理
- 分类：三类错误——模型输出错误（幻觉、格式错）、工具调用失败（API 超时、参数错）、逻辑错误（Agent 决策路径死循环）。每类对应不同处理策略。
- 决策：用 FSM 定义状态（正常、重试、补偿、降级、人工）。例如，工具调用失败，状态切到“重试”，最多 3 次，间隔指数退避（1s、2s、4s）。若仍失败，切到“补偿”（如取消已创建的订单），再失败则“降级”到确定性规则（如返回固定话术“系统繁忙，请稍后”）。
回滚机制：补偿事务 + 快照恢复
- 补偿事务（Saga 模式）：对已执行的工具调用（如发送邮件、扣款），实现逆向操作。例如，Agent 先调“创建订单”API，后检测到错误，调“取消订单”API 补偿。关键：补偿操作必须幂等（多次调用结果一致），否则可能重复退款。实战坑：补偿 API 也可能失败，需记录补偿状态到数据库，用定时任务重试。
- 对话状态快照：对多轮对话，每轮结束后保存状态快照（用户意图、已收集字段、工具调用历史）。回滚时恢复到上一个快照，让用户重试。取舍：快照粒度细（每轮）恢复精确但存储大，粗（每 3 轮）节省资源但可能丢失上下文。生产常用每轮快照 + 定期清理（保留最近 10 轮）。
降级方案：从 Agent 到确定性规则
- 确定性规则：当 Agent 连续出错（如错误率 > 30% 在 5 分钟内），自动切到规则引擎（如 if-else 树）。例如，客服 Agent 降级到“常见问题列表”+“转人工按钮”。坑：规则引擎维护成本高，需定期同步业务逻辑。
- 人工接管：设置“转人工”触发条件（如错误类型为“逻辑错误”且无法补偿）。需设计上下文传递（Agent 的对话历史、已执行操作）给人工坐席，减少重复沟通。
监控与告警：用数据驱动优化
- 指标：错误率（按类型分）、回滚成功率、用户无感知率（用户未察觉错误的比例）。目标：错误率 < 5%，回滚成功率 > 95%，用户无感知率 > 80%。
- 告警：设置动态阈值（如错误率超过基线 2 倍触发告警），避免误报。例如，用 Prometheus + Alertmanager，错误率 > 10% 持续 5 分钟发 P0 告警。
- 优化循环：每周分析错误模式，如 60% 错误来自“日期格式”，则加强校验规则或微调 prompt 示例。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从错误检测、回滚机制、降级方案三个层面回答。检测层用输出校验+置信度阈值+用户反馈，分类后用 FSM 决策重试或补偿。回滚层用 Saga 模式做补偿事务，对话状态做快照恢复。降级层切到确定性规则或转人工。总结一句：核心是设计完整流程——检测准、回滚稳、降级快，并用监控数据持续优化。”
4️⃣ 高频追问 & 应对
追问 1：补偿事务如果也失败了怎么办？比如取消订单 API 挂了。
设计“最终一致性”方案：补偿操作记录到数据库（如补偿任务表），用定时任务（如每 5 分钟扫描）重试，最多 3 次。若仍失败，触发人工告警，同时将订单状态标记为“待人工处理”。关键：补偿操作必须幂等，避免重复退款。生产常用死信队列（DLQ）兜底，人工介入后手动处理。
追问 2：如何评估回滚是否成功？用户无感知率怎么算？
回滚成功定义为：补偿操作执行成功且用户未投诉。指标：回滚成功率 = 成功回滚次数 / 总回滚次数。用户无感知率 = 用户未反馈问题的回滚次数 / 总回滚次数。实战中，通过埋点记录用户行为（如是否在回滚后继续正常对话），结合客服工单数据交叉验证。坑：用户可能未察觉但体验下降，需用 NPS 调查辅助评估。
追问 3：错误率 20-40% 这个数据怎么来的？你们生产环境实际多少？
这是行业通用数据，来自客服 Agent 和代码生成 Agent 的公开报告（如 Anthropic 的 Claude 客服场景错误率约 30%）。我们生产环境（客服 Agent）初期错误率 35%，通过优化 prompt 示例、加强校验规则、引入 rerank 模型，降到 8%。核心优化点：将错误类型从 3 类细分为 7 类（如“日期格式错误”单独处理），错误检测率从 60% 提升到 85%。
5️⃣ 避坑 · 常见错误答法
- ❌ 只谈“让模型重试几次” → ✅ 重试需结合错误类型和指数退避，且必须设计补偿事务，否则重试可能放大问题（如重复扣款）。
- ❌ 说“回滚就是撤销操作” → ✅ 回滚分补偿事务（逆向操作）和快照恢复（状态回退），需根据场景选择，且补偿必须幂等。
- ❌ 忽略用户反馈信号，只依赖模型置信度 → ✅ 用户反馈是低成本高价值的检测信号，需结合实时检测做预回滚，避免延迟。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索错误导致 Agent 回答错误”切入，讲如何用 rerank 模型+置信度阈值检测错误，并用快照恢复回滚到上一轮检索结果。
- 如果你只做过传统 NLP：用“规则引擎的错误处理”类比，讲如何将 if-else 的异常处理逻辑迁移到 Agent 的 FSM 设计，强调补偿事务的幂等性设计。
- 如果你是校招无项目：聚焦论文复现，如《Saga: A Pattern for Long-Running Transactions》的补偿机制，结合 LangGraph 的 StateGraph 实现快照恢复 demo，展示对容错设计的理解。
- 《Saga: A Pattern for Long-Running Transactions》——补偿事务经典论文
- 《Building Reliable AI Agents: Error Handling and Rollback Strategies》——Anthropic 工程博客
- 《LangGraph StateGraph: Managing Agent State and Rollback》——LangChain 官方文档
- 《Prometheus + Alertmanager: Dynamic Thresholds for Error Rate Monitoring》——Prometheus 最佳实践
- 《Designing Data-Intensive Applications》第 11 章“Processes and Distributed Systems”——幂等性与最终一致性