大模型驱动的自动化日志分析
贺品嘉 LOGPAI
日志分析
- 高质量的规范日志——日志记录
- where to log? 15年工作：将问题限制在try catch块和return value check
- 挑战
- 难以很好的完成总体任务，更多工作是聚焦于子任务的解决
- 粒度不够，业务代码的细节难以被理解
- 受限于方法本身的约束，假设太强的工作也难以投入实际应用
- 管理和保存大量日志——日志压缩
- 从日志中提取信息——日志解析
- 解析半结构化的数据
- 挑战：
- 难以跨日志系统泛化，利于基于文本生成的方法就要面对不同系统中词语含义不一样的问题
- 业界的日志比较复杂，多行日志与单行日志混合，现有的工作主要聚焦单行日志
- 受限于方法本身的约束，例如日志模板是定长的还是变长的
- 利用日志中挖掘的信息——日志挖掘
- 例如一些机器学习的方法，聚类等等
- 挑战：
- 难以挖掘语义，因为日志的上下文丢了
- 难以适应日志的迭代
近期工作
ICSE’24 UniLog
prompt模板(一些example)+输入，直接生成行号+log语句，从而一步完成多个子任务
有warm up，先在prompt中给一些内容
？如何评价message的正确错误
ICSE’24 DivLog
人先label一些，200行，抽取时尽量正交
prompt：先任务，然后例子，最后log
看起来在单行日志解析任务上结果非常优异 ？能说说为什么其他模型不行吗，因为我不是很了解这些数据集
Q&A
Q: 什么是好的日志生成
A: 要好的数据集，或者人工的label，和公司合作的数据
Q: 是否有必要自己构造一个属于日志领域的大语言模型
A: 基座模型难以训练(资源)，现在的也不错
Q: UniLog每次处理都是小的snippet，项目代码中有很多项目内部的内容，该如何更好的理解？
A: 有另一篇工作在投，引入一些静态分析方法加入prompt
Q: 大模型生成的内容无法保证？当前采用的方法是rethink再问
A: 可以把temperature设为0，大模型很难做到结果百分百正确
Q: 网络调用次数太多会有API Error，Network Error的问题。当前的做法是错误处理
A: 可以自己微调一个开源模型