考察点
这道题出自字节跳动 AI 产品经理一面,是技术理解+体验设计的复合题。面试官想看的不是你知道 Function Calling 是什么,而是你能不能把「失败率」这个工程指标翻译成用户视角的体验标准——95% 的单步成功率听起来很高,串成十步链路就只剩六成,这中间的账产品经理要会算。降级方案部分考的是你有没有真正处理过线上故障:重试怎么重、降级降到哪、什么时候该诚实告诉用户「我做不到」。追问一般往具体阈值、多步链路成功率、监控报警这几个方向走。
参考答案
先拆「失败」:四种失败的用户感知完全不同
开口谈「可接受」之前,得先把失败拆开,因为不同失败对用户的伤害天差地别。工具调用的失败大致四类:一是选错工具(用户想查快递,模型去查了订单),用户能看出来答非所问,伤害中等;二是参数错误(单号格式不对、日期解析错),通常表现为「没查到」,伤害较小;三是调用超时或服务异常,用户感知是「卡住」或「转圈很久」,伤害在耐心;四是结果解析错了但言之凿凿地返回(把接口返回的「已退款」理解成「退款失败」还告诉用户),这是最危险的一种——silently wrong,用户拿到错误信息还当真,可能直接导致资损或投诉。定标准的时候,这四类必须分开定,第四类的容忍度要接近零。
可接受失败率怎么定:按错误代价分级,不按技术现状分级
我的方法是按场景的错误代价把功能分三级。低风险场景(查天气、推荐歌单、闲聊里顺手查个信息),错了用户大不了再问一次,端到端成功率 95% 就能上,追求体验流畅优先;中风险场景(查订单、查物流、改签查询),错了会误导用户决策,要求 98% 以上,且关键字段要有置信度校验;高风险场景(退款、下单、转账、删数据),技术成功率要求再高都不够,必须靠产品机制兜底——执行前让用户确认,把「模型说干了什么」和「实际干了什么」的决定权交回给人。另外一个常被忽略的账:要按任务链路的端到端成功率算,不是单步成功率。一个十步的 Agent 任务,每步 95%,整体只有约 60%,这就是为什么多步 Agent 产品的体感失败率远比预想高,链路上每加一步自主决策,成功率预算就要重新算一遍。
无感降级的三层设计
降级的目标是用户基本无感地绕开失败,我按层做:
第一层是原地自愈。参数错、超时这类失败,带着错误信息让模型自己修一次——把上一次的错误输出和报错一起塞回上下文重试,一两次之内大部分能好,用户完全无感知。注意超时类重试要换策略而不是原样重发,比如缩小查询范围、换备用接口。
第二层是换路绕行。自愈失败就降级路径:复杂工具链降级成简单检索,大模型解析失败降级成规则兜底,实时接口挂了降级成缓存数据并标注时间。这一层用户有轻微感知(结果没那么聪明了),但任务还能完成。
第三层是诚实告知。所有路都走不通,绝不能让模型瞎编一个结果糊弄过去——幻觉式兜底比失败本身恶劣十倍。正确的做法是明确告诉用户没查到,给出替代路径(「你可以试试提供订单后四位」或「这个问题转人工帮你处理」),并把这次失败完整记录下来进 badcase 库。
上线后的监控:失败率本身就是产品指标
降级方案不是兜底完就结束,失败数据是最值钱的迭代素材。我会要求每个工具调用节点打结构化日志(输入、工具选择、参数、结果、重试次数、最终走哪条路径),看板按四类失败分型展示。两个报警红线:某类失败率突变(通常是上游 prompt 改动或模型版本切换引起,当天就要查)、降级路径占比持续爬升(说明主链路在退化,用户在为你没发现的问题买单)。badcase 走日审制度,PM 每天抽看失败会话,这是把「失败率」从数字变成体感认知的最直接方式。
可能的追问
- 95% 的阈值依据是什么,为什么不是 99%? 答:参照系有三:人工基线(人工客服的差错率本身就有 2%-5%)、用户对「重试一次就好」的容忍度(低风险场景用户纠错成本极低)、以及技术现状的现实——把低风险场景也压到 99%,延迟和成本会不可接受,分级就是把预算花在错误代价高的地方。
- 重试会不会让延迟超标? 答:会,所以重试预算和总延迟预算是一起定的:单节点最多重试 2 次、整体链路预留几秒的重试余量;对延迟敏感的场景(语音交互),宁可首轮就用更快的小模型,也不赌重试。
- 怎么发现「silently wrong」这类最危险的失败? 答:它不表现为报错,只能靠主动探测:对关键字段做确定性校验(状态枚举值比对、金额范围检查)、抽样人工审计成功会话、以及用户负反馈信号(「不对」「瞎说」类回复的聚类分析)。