AI 日志摘要：别把关键上下文压没了
系统一旦发生故障，海量日志瞬间涌来，任何运维人员都会感到头疼。AI 日志摘要的价值，在于快速识别异常模式、错误堆栈和时间线——但这一步若处理不当，很容易把定位问题所需的关键上下文给压缩掉。故障排查的核心是证据，而非文学创作。日志摘要的职责，是保留你诊断问题所需的全部信息，而不是给你一个漂亮的总结。
最危险的做法是什么？把几万行原始日志一股脑塞给模型，然后让它“总结一下原因”。结果可想而知。日志里塞满了重复、噪声和无关请求，模型被稀释得云里雾里，重点根本抓不住。正确的流程应该是先过滤、再聚合、最后排序，之后才是摘要上场。次序不对，效果全废。
一、摘要链路：过滤比生成更重要
flowchart TD
A[原始日志] --> B[时间窗口过滤]
B --> C[错误级别筛选]
C --> D[traceId 聚合]
D --> E[异常模式提取]
E --> F[AI 摘要]
F --> G[排障报告]
过滤条件从哪儿来？来源于告警事件。服务名、时间窗口、traceId、错误码、接口路径、版本号，这些是硬性指标。如果没有这些前提条件，日志摘要就变成了全量搜索，不仅成本高昂，效果也差，纯粹是费力不讨好。先把候选证据范围缩小，精确锁定目标，AI 才能发挥真正的效力。
摘要里必须保留样本。比如某类错误出现了 120 次，报告里就应该附上 1 到 3 条代表性日志及对应的 traceId。如果只写一条“出现数据库超时”，排障人员大概率还得重新翻看原始日志——那摘要的意义何在？
二、输出格式：摘要要带证据引用
下面是一份比较靠谱的摘要输出结构。
{
"summary": "checkout-api 在 10:02 后出现数据库连接池等待超时",
"top_patterns": [
{
"message": "Timeout waiting for connection from pool",
"count": 128,
"sample_trace_id": "tr_abc123"
}
],
"time_range": "10:00-10:10"
}
这种结构化的输出，比一大段自然语言描述好用得多。按照错误模式排序，点击 traceId 就能直接跳转到日志平台——这才是导航应有的样子。AI 摘要不是终点，它应该是你进入证据的入口。
敏感信息也必须留意。日志里可能包含 token、手机号、邮箱、订单号、内部 IP 等内容。这些数据在进入模型之前必须进行脱敏处理，摘要输出也不能泄露。运维效率再重要，也不能拿数据安全去冒险。
三、落地边界：摘要不能替代原始日志
AI 摘要适合作为第一视图，但原始日志必须可追溯，这是底线。模型可能会遗漏少量但关键的异常，也可能把相似错误合并得过于粗放。值班人员必须能够展开查看原始证据，才能做出准确判断。
摘要是否有用，需要评估。故障复盘时，可以标记哪些摘要有帮助，哪些误导人，哪些缺少关键字段。反馈回流之后，再调整过滤规则和 Prompt。日志摘要不是一次性功能，它需要随着故障类型不断演进。
时效性也十分关键。故障发生后等 3 分钟才生成报告，黄花菜都凉了。可以先提供一个轻量摘要，随后再异步补充深度分析。排障工具的第一要义就是快。
摘要结果还必须支持时间线。故障排查不仅看发生了什么，更关注先后顺序：是先发布还是先报错？是先数据库慢还是先应用超时？AI 摘要如果能按分钟把关键事件排列出来，值班人员判断因果关系会轻松很多。没有时间线，很多结论都只是基于相关性的猜测。
重复错误必须合并，但不能丢失样本差异。例如，同一个异常码在两个接口出现，影响范围可能完全不同。合并时保留接口、实例和 traceId 分布，才能避免过度压缩导致信息丢失。
日志摘要还可以与 Runbook 关联起来。比如摘要识别到连接池等待超时，自动附上对应的排查步骤和常用命令。这样 AI 负责把现场和知识库连接起来，值班人员无需在多个系统之间来回切换。
四、总结
AI 日志摘要的关键，从来不是压缩文字，而是保留证据上下文。先按告警过滤日志，再提取模式和样本，最后生成带引用的摘要。记住，摘要只是导航，它永远不是原始日志的替代品。
