是否有异常 fallback 策略
1️⃣ 考察意图
面试官想看你是否具备生产级系统的“防御性编程”思维，而非只关注模型正向效果。这道题属于系统设计 + 工程取舍类型，刁钻点在于：候选人常只提“重试”或“换模型”，却忽略异常分类、分级降级、监控完整流程和业务场景适配。答好了能展示你对LLM不可靠性的深刻理解、从“模型输出”到“系统可靠性”的全局工程视野，以及处理长尾异常（如有害内容、循环生成）的实战经验。
2️⃣ 标准答
异常fallback策略的核心是定义异常 → 分级降级 → 监控完整流程 → 业务适配。以下是具体设计：
- 异常分类与检测
- 空输出：模型返回空字符串或None，通常由token限制或解码失败导致。
- 置信度过低：对生成式模型，可用logit概率均值或top-1概率（如<0.4）作为信号；对分类任务，softmax输出<0.6即视为低置信。
- 重复生成：检测n-gram重复率（如连续3个4-gram重复）或使用
repetition_penalty阈值（如>1.2时触发）。 - 有害内容：集成第三方检测器（如OpenAI Moderation API、自建关键词+分类器），对毒性分数>0.8的输出拦截。
- 格式错误：如JSON解析失败、字段缺失，常见于结构化输出场景。
- 分级降级设计
- 一级：重试（Retry）：调整参数重采样，如降低
temperature（从0.7降到0.3）、增加top_p（从0.9到0.95）、或切换采样策略（从top-k到nucleus）。重试次数建议2-3次，避免无限循环。 - 二级：降级（Degrade）：使用更轻量模型（如从GPT-4降级到GPT-3.5或本地T5）、或规则回复（如“抱歉，我暂时无法回答，请稍后再试”）。对低置信场景，可回退到BM25检索+模板填充。
- 三级：人工兜底（Human Handoff）：对金融、医疗等低容错场景，将异常请求标记并转接人工客服。需设计超时机制（如5秒无响应则自动转接）。
- 工程取舍：重试增加延迟（每次约200-500ms），降级牺牲质量但保证可用性。实际中需权衡：对高并发场景（如客服机器人），优先降级而非重试；对离线批处理，可重试5次。
- 实际落地的坑与解法
- 坑1：重试导致重复输出：重试时若
temperature不变，可能生成相同结果。解法：每次重试随机扰动temperature（±0.1）或seed。 - 坑2：降级模型响应不一致：如从GPT-4降级到GPT-3.5，回答风格突变。解法：在降级模型上做prompt适配（如加“请用简洁语气回答”），或使用统一post-processing（如长度截断、格式修正）。
- 坑3：有害内容漏检：单检测器有误报/漏报。解法：级联检测（先关键词过滤，再模型分类），并设置“人工审核”作为最终兜底。
- 监控与持续优化
- 记录每个异常的触发频率、fallback路径和最终效果（如用户满意度评分、任务完成率）。
- 设置告警阈值：如fallback触发率>5%或人工转接率>1%时，触发告警并触发模型重训或阈值调整。
- 定期A/B测试：对比不同降级策略（如规则回复 vs. 小模型）对用户留存的影响。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从异常分类、分级降级、监控完整流程三个层面回答。首先，异常类型包括空输出、低置信、重复生成和有害内容，每种需独立检测。其次，设计三级降级：一级重试（调整temperature）、二级降级（换小模型或规则）、三级人工兜底，并注意重试次数和延迟权衡。最后，通过日志监控触发率和用户反馈，持续优化阈值。总结一句：异常fallback不是事后补救，而是系统可靠性的第一道防线。”
4️⃣ 高频追问 & 应对
追问 1：如果重试3次后仍然失败，你会怎么处理？
直接进入二级降级，不再继续重试，避免延迟爆炸。具体做法：记录失败原因（如“连续3次低置信”），然后回退到规则回复（如“我暂时无法处理，请稍后再试”）。对低容错场景（如支付咨询），同时触发人工转接。关键点：设置全局超时（如总fallback时间<2秒），防止降级链过长。
追问 2：如何确定置信度阈值？比如0.6是否通用？
不通用，需业务场景和模型调优。方法：收集线上数据，绘制置信度与任务成功率的关系曲线（如PR曲线），选择F1最高的点。例如，对闲聊场景，0.4可能足够；对金融咨询，需0.8以上。工程上，可设置动态阈值：根据用户历史行为（如VIP用户降低阈值）或时段（如夜间放宽）。初始值可参考论文【通用知识：LLM置信度校准常用top-1概率或logit均值】。
追问 3：如果降级模型（如GPT-3.5）也频繁触发fallback，怎么办？
说明降级模型本身不可靠，需升级策略。解法：① 检查降级模型的prompt是否适配（如加“请避免重复”）；② 切换降级模型（如从GPT-3.5到Claude Haiku）；③ 直接跳到三级人工兜底，避免无效降级。同时，记录此情况并触发模型重训或替换。
5️⃣ 避坑 · 常见错误答法
- ❌ “重试三次，不行就报错。” → ✅ “重试需结合参数调整（如temperature扰动），且要有降级和人工兜底，不能直接报错，否则影响用户体验。”
- ❌ “所有异常都用同一个fallback策略。” → ✅ “异常类型不同，策略不同：空输出优先重试，有害内容直接拦截并转人工，低置信可降级。一刀切会浪费资源或漏掉风险。”
- ❌ “只关注模型输出，忽略业务场景。” → ✅ “高容错场景（如闲聊）可宽松，低容错场景（如金融）需严格，甚至强制人工审核。业务场景决定fallback的严格程度。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索失败或生成幻觉”切入，展示如何设计fallback（如检索不到时用BM25+模板，生成置信低时重采样），并给出线上监控数据（如fallback触发率从15%降到5%）。
- 如果你只做过传统NLP：用“分类器置信度低时降级到规则”类比，强调异常检测和分级降级的通用性，并提及迁移到LLM场景的挑战（如重复生成检测）。
- 如果你是校招无项目：聚焦论文复现，如参考《LLM Reliability: A Survey》中的fallback框架，并描述一个demo：用HuggingFace模型+OpenAI API模拟三级降级，在公开数据集上测试。
- 《LLM Reliability: A Survey》—— 系统梳理异常类型和降级策略
- OpenAI Moderation API 文档 —— 有害内容检测实践
- 《The Power of Scale for Parameter-Efficient Prompt Tuning》—— 降级模型prompt适配参考
- HNSW + BM25 混合检索 —— RAG场景下检索失败fallback
- 博客：Building Robust LLM Applications with Fallback Chains —— 工程落地案例