用大模型做日志异常检测和告警降噪，怎么落地？
面试怎么回答
我会先用传统方法打基础：按影响分级，低级别夜间不通知；按任务依赖把同一根因引发的一连串告警合并；去重；用动态阈值减少误报，这一步往往就能降掉一大半。大模型放在适合的位置：读几千行日志总结失败原因附在告警里，把错误归到已知类别并标出新模式，结合同时段告警、最近变更和上游状态给出可能的根因，根据历史处理记录给建议，并把一段时间的告警汇总成摘要。落地时只对需要分析的日志调用并先用规则截取相关片段控制成本；根因作为建议并统计准确率；初期不让大模型决定告警是否通知，避免漏报；日志用内部模型或先脱敏；处理结果沉淀成案例库。效果看通知量、平均定位时间、根因准确率和漏报数。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据平台每天产生大量的告警：任务失败、延迟、资源告警、质量告警，值班同学一晚上收到几百条，真正需要处理的只有几条，「狼来了」之后重要的告警也被忽略了。能不能用大模型做告警降噪和日志分析？面试官问这题，想看你怎么把大模型放在合适的位置，而不是让它替代所有规则。
先用传统方法打好基础
大模型不是第一步，很多降噪靠规则和工程就能做：
- 告警分级：按影响（是否核心链路、是否影响下游 SLA）分级，低级别的不在夜间通知；
- 合并和抑制：同一个根因引发的一连串告警（上游失败导致下游几十个任务失败），通过依赖关系合并成一条；
- 去重：同一个问题的重复告警在一定时间内只发一次；
- 阈值优化：动态阈值代替固定阈值，减少误报。
这些做完，告警量往往能下降一大半。
大模型适合做的部分
- 日志理解和归纳：任务失败时，日志可能有几千行。大模型读取关键部分，总结出「失败原因：上游表分区不存在」「OOM，Executor 内存不足」，附在告警里；
- 错误归类：把失败归入已知的类别（资源不足、数据问题、代码 bug、外部依赖），新的错误模式单独标出；
- 关联分析：结合同时段的其他告警、最近的变更、上游任务状态，给出可能的根因；
- 处理建议：根据历史上类似问题的处理记录，给出建议的处理步骤；
- 告警摘要：把一段时间内的告警汇总成一段话：「过去 1 小时 50 条告警，主要是由 XX 集群的 NameNode 切换导致，影响 30 个任务，其中核心任务 3 个」。
落地的注意事项
- 成本：不是每条日志都送给大模型，只对告警触发的、需要分析的日志调用；先用规则提取错误相关的片段，减少输入长度；
- 准确性：大模型给出的根因是「建议」，不是结论；记录它的判断和最终真实原因，统计准确率；
- 不能漏报：大模型可以帮助排序和摘要，但不应该决定「这条告警不重要、不通知」，至少在初期不能，避免漏掉真正的问题；
- 数据安全：日志中可能有敏感信息，使用内部模型或者先脱敏；
- 知识积累：每次处理的结果反馈回来，形成案例库，让后续分析更准。
衡量效果
- 值班同学收到的通知数量；
- 平均定位时间（从告警到找到原因）；
- 大模型根因分析的准确率；
- 漏报事件数（不能增加）。