踩坑排查题
面试里排查题很有区分度。好的回答不是“换模型试试”，而是按层定位：输入、检索、工具、模型、状态、成本、安全。
Q1：模型不调用工具，怎么排查？
当用户说“答案引用正确但还是不好用”，先看问题是否命中旧版本、权限过滤、召回排序或解释层；不要第一反应就换更大的模型。排查题要把现象拆成可以验证的假设。
参考答案
按顺序看：
- 工具描述是否清楚。
- prompt 是否写了触发条件。
- 工具 schema 是否太复杂。
- 模型是否支持工具调用。
- 用户问题是否真的需要工具。
- tool choice 或配置是否禁用了工具。
不要第一时间怪模型。很多时候是工具说明太模糊，模型不知道什么时候该用。
Q2：模型乱调用工具，怎么排查？
参考答案
看工具边界是否过宽、工具太多、触发条件不清、prompt 是否鼓励“遇事先查”。可以通过工具路由、动态裁剪、负例说明和调用 eval 改进。
Q3：tool loop 死循环，怎么排查？
参考答案
先看是否缺最大轮数。再看是否同一工具同一参数重复调用、工具返回是否太模糊、错误是否一直可重试、模型是否没有停止条件。
修复方式：最大轮数、重复检测、错误阈值、预算限制、明确 final answer 条件。
Q4：工具参数经常错，怎么排查？
参考答案
检查 schema 字段是否清楚，是否缺 required，枚举是否明确，描述是否写了格式要求。业务侧要做 validate，错误结构化回传，让模型修正。
Q5：RAG 答案幻觉多，怎么排查？
参考答案
先查检索结果是否真的有证据。再查 chunk、query rewrite、embedding、top_k、rerank 和证据裁剪。最后看生成 prompt 是否要求基于证据回答。
很多 RAG 幻觉不是生成问题，而是根本没检索到证据。
Q6：RAG 引用不支持结论，怎么排查？
参考答案
检查生成是否先答后找引用，还是基于证据生成。要让模型只使用给定证据回答，并在复核阶段检查每个结论是否被引用支持。
Q7：召回结果全是不相关内容，怎么排查？
参考答案
看 embedding 模型是否适合语种和领域，chunk 是否太大，query 是否过短，是否需要关键词或混合检索，向量距离度量是否配置错。
Q8：文档更新了但答案还是旧的，怎么排查？
参考答案
检查文档同步、切分、embedding、索引更新、metadata 版本、缓存和查询过滤。旧答案可能来自旧索引，也可能来自答案缓存。
Q9：权限数据被泄露，怎么排查？
参考答案
首先看无权限内容是否进入检索候选或 prompt。权限过滤应该在检索前或检索时完成。再看日志、缓存和输出脱敏是否隔离不同用户。
Q10：cached_tokens 一直为 0，怎么排查？
参考答案
看稳定前缀长度是否足够，前缀是否完全一致，是否混入时间戳、request_id、用户 ID，工具列表顺序是否变化，cache key 是否切太碎。
Q11：成本突然升高，怎么排查？
参考答案
看逐轮 usage：
- input 是否变长。
- output 是否变长。
- 工具调用是否变多。
- 重试是否增加。
- 缓存命中率是否下降。
- RAG 证据是否塞太多。
Q12：延迟突然升高，怎么排查？
参考答案
拆成模型 prefill、模型生成、检索、rerank、工具 API、排队等待。看是否串行了本可并行的工具调用。
Q13：多 Agent 互相打架，怎么排查？
参考答案
看 ownership 是否清楚、共享状态是否太多、交接格式是否结构化、是否缺主管裁决、是否多个 Agent 同时写同一字段或文件。
Q14：多个 Agent 覆盖同一文件，怎么修？
参考答案
用单写者原则。其他 Agent 只提交 patch 或评论，patch 带 base version，应用前检查文件是否变化，冲突由主管或人工合并。
Q15：审校 Agent 一直改不完，怎么修？
参考答案
设置最大审校轮数。审校只输出问题清单，写作只改一次或两次，最终由主管收口。不要让两个 Agent 无限互改。
Q16：客服 Agent 乱承诺退款，怎么修？
参考答案
承诺类动作不能由模型自由生成。退款、赔付、补偿必须由政策工具和业务规则判断，输出前做口径检查，高风险转人工。
Q17：代码审查 Agent 误报太多，怎么修？
参考答案
补上下文、降低评论数量、只输出高置信问题、不确定时标疑问、按严重级别排序，用人工采纳率反向优化。
Q18：代码审查 Agent 漏掉严重 bug，怎么修？
参考答案
检查是否只看 diff、是否缺相关函数和测试上下文、是否没有按 correctness 优先审查。可以加规则检索、安全检查和高风险文件优先策略。
Q19：LLM-as-Judge 打分不稳定，怎么修？
参考答案
明确 rubric，固定输入格式，低温度，必要时多 judge 投票，抽样做人类校准。能用规则判断的不要交给 judge。
Q20：prompt 改动后效果变差，怎么排查？
参考答案
看 prompt version，对比 eval 结果，找到退化样本。不要只看几个成功 demo。必要时回滚 prompt，再逐项改。
Q21：模型输出 JSON 经常不合法，怎么修？
参考答案
优先用 structured output。schema 简化，字段减少，枚举明确。业务侧 parse 和 validate，失败时重试或降级。
Q22：上下文爆了，怎么修？
参考答案
裁剪历史、压缩工具结果、摘要长期对话、检索旧信息、只保留关键状态。不要把所有工具返回和历史消息都塞进去。
Q23：模型回答风格不稳定，怎么修？
参考答案
统一 system prompt、few-shot、输出 schema、采样参数和模型版本。风格要求长期稳定且样本足够时，可以考虑微调。
Q24：搜索 Agent 被 SEO 噪声带偏，怎么修？
参考答案
提高来源权重，优先官网、公告、论文、权威媒体；对论坛和营销内容降权；多源交叉验证；报告里标明低可信来源。
Q25：Agent 一直问用户补充信息，怎么修？
参考答案
给它明确追问条件和最多追问次数。能通过工具或检索获得的信息不要问用户；必须用户确认的再问。
Q26：模型经常把工具错误解释成成功，怎么修？
参考答案
工具错误要结构化返回，带 error_code、retryable、message。prompt 明确禁止把错误当成功，并在错误达到阈值时终止。
Q27：RAG 无答案识别差，怎么修？
参考答案
加入无答案样本评估，prompt 明确证据不足时回答不知道，复核阶段检查结论是否被证据支持。检索低分时不要强行生成。
Q28：多轮对话里模型忘记用户要求，怎么修？
参考答案
把关键要求写入结构化状态，不只依赖聊天历史。长对话定期摘要，并在每轮上下文前部放当前目标和约束。
Q29：模型总是输出过长，怎么修？
参考答案
定义输出结构和长度上限，比如最多 5 点、每点 30 字。必要时后处理截断或二次压缩。只说“简洁一点”不够。
Q30：上线后出现不可复现 bug，怎么修？
参考答案
补齐 trace：prompt version、model version、tool version、knowledge base version、输入摘要、工具参数、usage、latency、error。没有这些字段，就很难复现。
Q31：流式输出中途断了，怎么排查？
排查顺序
先确认是模型供应商断流、网关超时、代理缓冲、前端连接断开，还是工具调用阶段本来就不适合流式。记录首 token 时间、最后一个事件、连接状态、request ID 和下游错误。
修复方向
事件要有序列号或游标，客户端断线后可以从服务端恢复；网关设置心跳和合理超时；模型流与任务状态分离，不能把“前端没显示完”当成“任务没完成”。对外部写操作必须根据服务端状态决定是否重试，不能因为 UI 断流就重复提交。
Q32：Agent 重启后重复发邮件，怎么排查？
先查任务状态、工具调用记录和邮件服务的 request ID，确认是没有持久化、恢复逻辑重复执行，还是服务端不支持幂等。再检查是否把“模型未收到结果”错误当成“工具未执行”。
修复时由业务动作生成稳定幂等键，服务端保存执行结果；恢复阶段先查询状态，成功则复用，进行中则等待，只有明确失败且可重试才再次调用。仅在 prompt 里提醒“不要重复发送”没有用。
Q33：多租户系统只有一个租户偶发看到别人的答案，怎么排查？
先按 trace 检查认证主体、租户 ID、权限快照、检索过滤条件、缓存 key、工具参数和最终输出。重点看是否复用了不带 tenant/ACL 的最终答案、检索结果或 prompt cache，是否在异步任务中丢了租户上下文。
修复要在数据源、检索、缓存、任务消息、工具和日志链路都传递并校验租户上下文；缓存 key 带权限版本；高风险结果做服务端归属校验。不要只在最终文本里做字符串脱敏，因为无权限数据可能已经进入模型上下文。
Q34：模型升级后成本下降但质量也明显下降，怎么排查？
先按任务类型比较新旧模型的 token、缓存命中、重试、工具调用和业务成功率，确认是不是路由改变、上下文截断、输出变短、拒答变多或评估样本漂移。再固定 prompt、工具、知识库版本做 A/B，对召回和生成分别评估。
如果只是低风险任务质量可接受，可以保留路由；对高价值任务回退强模型或提高验证。模型升级不能只看平均单价，要看“每个成功任务的成本”和错误造成的补偿成本。
Q35：RAG 评测分数很高，用户却说不好用，怎么排查？
先确认离线样本是否覆盖真实问题、长尾表达、权限、无答案、时效和多轮上下文。再区分检索指标高但最终生成差，还是人工觉得答案不符合业务目标。也要检查评测是否只看 Recall@k，而没有看引用支持率、答案正确率、拒答质量和延迟。
修复时把真实反馈切成可复现样本，补充业务成功标准和人工 rubric；按问题类型切片，避免平均分掩盖某一类关键失败。高分不等于用户价值，离线指标必须和线上任务结果对齐。
Q36：评估集被模型“记住”后分数很高，怎么排查？
检查评估样本是否出现在训练数据、few-shot、开发提示词、知识库或缓存中；确认是否误把评估答案写进了检索索引；对公开 benchmark 不能直接当成业务泛化证明。
修复时建立训练、开发、测试和线上回放的隔离，保留未公开的 holdout 集，定期轮换困难样本，并加入对抗、时间切分和真实长尾样本。评估集不是越大越好，关键是独立、覆盖真实风险并能防止泄漏。
Q37：工具调用成功率高，但任务完成率低，怎么排查？
工具成功只表示 API 返回 200，不表示调用的是正确工具、参数符合用户意图或结果被正确使用。要检查工具选择准确率、参数语义、返回内容质量、后续状态更新和最终答案是否引用了结果。
增加端到端任务 eval，并对每个工具定义前置条件、成功后状态和业务验收标准。必要时让工具返回结构化状态，而不是只返回一段自然语言，让运行时能判断“调用成功但任务未完成”。