用大模型做数据质量问题的根因分析，怎么设计才靠谱？
面试怎么回答
大模型擅长读日志、把告警、调度、变更、上游数据这些分散信息串起来提出假设，并按流程生成报告，但它不能凭空判断数据对不对，必须靠工具查真实数据。我会设计成 Agent 加工具加排查手册：工具包括查血缘、查上游调度状态和输出行数、对比分区行数和字段分布、查最近的发布和表结构变更、查历史相似告警；把团队排查经验写成手册让 Agent 按步骤执行，输出结论、证据链和置信度。Agent 只读、只诊断，修复要人确认，结论里的数字必须来自工具。先作为告警附带的辅助诊断，记录诊断和真实根因计算准确率，逐步扩大范围。前提是血缘、调度、变更记录和故障复盘这些基础要完善。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
凌晨数据质量告警：核心订单表的行数比昨天少了 40%。值班同学要查上游同步、调度日志、上游业务变更……一套流程下来一两个小时。能不能让大模型帮忙做根因分析？面试官问这题，想看你知不知道大模型擅长什么、不擅长什么，以及怎么把它放进排查流程里。
大模型在这里擅长什么
- 读大量日志和报错信息，提炼关键错误；
- 把分散的信息（告警、调度状态、变更记录、上游表的情况）串起来，提出可能的原因；
- 按标准流程一步步检查，生成排查报告；
- 根据历史案例给出相似问题的处理建议。
不擅长的：凭空判断数据是否正确。它需要工具去查真实的数据和状态。
设计：Agent + 工具 + 排查手册
- 工具：
- 查血缘：这张表的上游有哪些；
- 查调度：上游任务今天的运行状态、开始结束时间、耗时、输出行数；
- 查数据：上游表各分区的行数、关键字段的空值率和分布对比；
- 查变更：最近的代码发布、表结构变更、配置变更；
- 查历史：类似告警的历史处理记录；
- 排查手册：把团队的排查经验写成步骤（先看上游是否按时完成 → 上游行数是否正常 → 是否有结构变更 → 是否有业务侧的变化），Agent 按手册执行；
- 输出：结论 + 证据链（每一步查了什么、看到了什么），置信度，建议的处理方式。
安全边界
- 只读：Agent 只负责诊断，不自动修复。重跑任务、修数据需要人确认；
- 查询走只读账号和资源限制；
- 结论里的每个数字都来自工具返回，不能是模型推测。
落地方式
- 先做「辅助」：告警发出时，Agent 同时生成一份初步诊断附在告警里，值班同学参考；
- 记录 Agent 的诊断和最终的真实根因，计算诊断准确率；
- 按问题类型看哪些场景准、哪些不准，逐步扩大使用范围；
- 处理结果反哺到历史案例库，让后续诊断更准。
前提条件
根因分析能做多好，取决于数据团队的基础：血缘是否完整、调度信息是否可查、变更是否有记录、历史故障是否有复盘。基础不好，Agent 也查不出来。