文章是2024年的综述文章 链接到标题
本文开头就写出现了传统AIOps和基于LLM的AIOps 说了传统的有缺陷,LLM的有优势。 二者有不同,然后会分点讨论不同和方法。
主要有:
- 故障管理AIOps的定义
- AIOps的数据来源
- AIOps采用的基于LLM的方法 还有:
- AIOps的子任务
- 适用于不同AIOps子任务的LLM方法
- 该领域的挑战和未来方向
传统与LLM的AIOps的区别 链接到标题
这里主要说传统的AIOps是基于机器学习的有缺陷。 基于LLM的有优势,并分析了原因。
传统的缺陷 链接到标题
有如下原因:
- Need for complex feature extraction engineering.需要复杂的特征工程
- Lack of cross-platform generality.缺乏跨平台通用性
- Lack of cross-task flexibility.缺乏跨任务灵活性 一个任务需要多个模型
- Limited model adaptability.模型适应性受限 系统迭代时模型需要重新训练
- Restricted levels of automation.自动化程度受限
AIOps的数据来源 链接到标题
两个大来源:系统生成的,人类写的
系统生成 链接到标题
文章中就写了三类: 日志、指标、跟踪
- 日志(logs): 就是各种系统日志、应用日志、错误日志等文本数据,对于诊断问题,理解系统行为和追踪问题很重要
- 指标(metrics): 就是CPU利用率、内存使用率,网络延迟等量化指标
- 跟踪(traves): 是分布式系统中请求的跟踪数据,记录了请求在系统中的路径和时间信息,对于分析性能瓶颈和故障传播很有用
人类写的 链接到标题
三种:软件信息(software information),问题和回答(question and answer),事件报告(incident report工单?)
- 软件信息:就是系统文档、设计文档、代码注释、源代码等文本数据,提供了系统的结构和功能信息,可以让LLM更好地理解系统的工作原理和潜在问题。
- 问题和回答:就是问答对,可能是系统管理员或者用户提出的问题和相应的回答,这些数据可以帮操作员更快地找到解决方案,或者让LLM学习如何回答类似的问题,还有和软件信息一样的功能
- 事件报告:就是系统发生故障或者异常时的报告,一般都是人记录的,以前一般交付给值班人员。现在有LLM可以自动分析这些报告,提取关键信息,甚至提供解决方案建议。
基于LLM的AIOps方法 链接到标题
文章把现在有的方法分类成4类:
- foundation model 基础模型:指直接用现有大模型而不微调
- fine-tuning approach 微调方法:指微调大模型
- embedding-based approach 基于嵌入的方法:基于嵌入的方法利用预训练模型生成的表示来捕捉语义信息并提高任务性能
- prompt-based approach 基于提示的方法:指人写提示来应用模型
基础模型 链接到标题
分两类:
- 用tansformer模型
- 用其他的RNN,CNN等模型
微调方法 链接到标题
分两类:
- 全面微调 Full Fine-Tuning:所有参数都微调,但现在都没钱,多用BERT和T5
- 参数高效微调 Parameter-Efficient Fine-Tuning:
- 任务条件微调Task-Conditional Fine-Tuning: 也是要冻结层,但是会替换输出头,就是原来输出是文本,可以改成输出分类结果或者其他的东西(回归,其他)
- 冻结层Layer-Freezing 就是冻结部分层的参数,只微调其他层的参数,文中种说一般冻结前面层,微调后面层。前面层是靠近输入的层,后面层是靠近输出的层。前面层一般捕捉通用特征,后面层捕捉特定任务的特征,所以微调后面层可以更好地适应特定任务,同时减少微调的参数量。
- 适配器微调Adapter Tuning 这个也要冻结原模型,但要求在模型里加入adapter层
这3种技术文中都有介绍,具体实现我还不清楚,目前这个方法最流行
基于嵌入的方法 链接到标题
这里嵌入embedding-based的含义是指将输入数据(如文本、指标等)转换为向量表示,以便于机器学习模型处理和理解。基于嵌入的方法利用预训练模型生成的表示来捕捉语义信息并提高任务性能。
- 预训练嵌入(Pre-Trained Embedding) 预训练嵌入方法直接利用由大语言模型(LLM)生成的嵌入向量,例如 BERT、GPT 或 T5,以捕获 AIOps 中各种数据源的语义信息。这些嵌入向量来自在大规模文本语料库上预训练的模型,蕴含丰富的语义信息,无需进一步微调即可适用于广泛的 AIOps 任务。目前,大多数与日志相关的工作都采用这种基于嵌入的方法。
- 提示嵌入(Prompt Embedding) 提示嵌入方法侧重于为 LLM 设计特定的嵌入方法,以有效捕获 AIOps 中各种数据源的语义信息。通过提供自然语言提示词或指令,这些方法激活 LLM 的处理能力,生成任务特定的嵌入向量。这种方法能够产生灵活且针对特定任务的嵌入,适用于不同的 AIOps 应用。目前,许多基于指标(metrics)的工作采用这种方法,将指标数据转换为更适合 LLM 理解的格式。这个主要是写提示词加metrics数据一起输入模型,模型会把它们转换。
基于提示的方法 链接到标题
这个就是直接写prompt来让模型完成任务,说白了就是提示词工程。真的有用吗???😥
4个类:
- 上下文学习(In-Context Learning, ICL)。上下文学习是指在输入提示中向模型提供示例,帮助其理解如何执行任务。这种方法使模型能够根据所提供上下文中的模式和信息生成适当的响应。许多 AIOps 工作使用这种方法来引导 LLM 生成符合期望输出格式的结果。
- 思维链(Chain of Thoughts, CoT)。思维链通过引导模型经历一系列逻辑上的中间步骤或推理过程,最终得出答案。这种方法有助于解决需要多步推理的复杂问题。许多 AIOps 工作使用这种方法来提高输出的准确性。
- 任务指令提示(Task Instruction Prompting)。任务指令提示是指向模型明确说明要执行的任务。该方法利用模型遵循详细自然语言指令的能力,有效完成特定任务。在本综述中,我们将许多简单或零样本方法归入此类。许多早期 AIOps 工作使用这种方法来完成特定任务。
- 基于知识的方法(Knowledge-Based Approach)。这种方法将外部知识整合到模型的响应中。例如工具增强生成(Tool Augmented Generation, TAG),即模型使用外部工具或 API 来增强其能力;以及检索增强生成(Retrieval Augmented Generation, RAG),即从外部来源检索相关信息以改进模型的响应。这是 AIOps 工作中最常用的方法,也是在特定任务上提升 LLM 性能最有效的方法。
AIOps在FM失败管理中的任务 链接到标题
文章中提到的任务有:
- Data Preprocessing 数据预处理
- Failure Perception 故障检测
- Root Cause Analysis 根因分析
- Auto Remediation 自动修复
数据预处理 链接到标题
这里和传统的不同,不是爬取和清洗。 有3种方法:
- Log parsing 日志解析:将非结构化日志数据转换为结构化格式,以便于分析和处理。这里有很多文章产出可以借鉴。
- Metrics imputation 指标补全:处理缺失的指标数据,使用插值或预测方法填补缺失值,以确保数据的完整性。
- Input summarization 输入摘要:将大量的输入数据(如日志、指标等)进行摘要,提取关键信息,这样后面调用llm可以减少输入长度,提高效率。
Failure Perception 故障检测 链接到标题
- failure prediction 故障预测:使用机器学习或深度学习模型分析历史数据,预测系统可能发生的故障。这有助于提前采取措施,避免故障发生。单实际很难搞。
- Anomaly Detection 异常检测:识别系统中不正常的行为或模式,这些异常可能是潜在故障的迹象。常用方法包括统计方法、机器学习算法和深度学习模型。这里其实蛮难的。
Root Cause Analysis 根因分析 链接到标题
检测到故障后,分析导致故障的根本原因。这通常涉及分析日志、指标和其他相关数据,以确定引发问题的具体因素。LLM可以帮助理解复杂的系统交互和依赖关系,从而更有效地进行根因分析。
3种任务:
| 任务类型 | 任务定义 | 描述 |
|---|---|---|
| fault localization 故障定位 | 确定故障发生的位置 | 通过分析系统数据,确定故障发生的具体组件或模块 |
| failure category classification 故障分类 | 将故障归类到预定义的类别中 | 根据故障的特征和影响,将其分类为特定类型,如硬件故障、软件缺陷等 |
| root cause report generation 根因报告生成 | 生成描述根因分析结果的报告 | 基于分析结果,生成详细的报告,说明故障的根本原因和可能的解决方案,这个一般包含前两个任务 |
自动修复 链接到标题
5种任务:
- Assisted Questioning。就是现在最常见的修bug方法,人问,LLM回答。
- Mitigation Solution Generation 缓解方案生成:基于故障分析结果,生成潜在的解决方案或缓解措施,以帮助操作员快速响应和修复问题。这就是只有文字解决方案。
- Command Recommendation 命令推荐:根据故障分析结果,推荐具体的命令或操作步骤,以指导操作员进行修复。这里值得注意的是,这里的命令可以是人事先写好的脚本,或者是LLM生成的命令模板,需要人填充参数。
- Script generation 脚本生成:基于故障分析结果,自动生成修复脚本,以便快速执行修复操作。这是直接让LLM生成脚本,可能需要人审核。
- Automatic execution 自动执行:在某些情况下,系统可以配置为在检测到特定故障时自动执行预定义的修复措施。这需要高度的信任和准确性,以避免误操作。这个目前研究不多,毕竟风险比较大,准确度不够高。
DATA PREOCESSING 数据预处理 链接到标题
对于人类写的输入,主要是用LLM来做输入摘要,提取关键信息,减少输入长度,提高效率。
日志解析 链接到标题
日志解析是将半结构化的文本日志转换成独立的事件模板(event template),转换成事件模板后就可以做成序列组(sequence group)了。后面Failure Perception和RCA就可以用了.
原有的模型泛化性不好,LLM可以提供很好的泛化能力,适用于不同系统和日志格式。但是,LLM在专门的日志解析能力上并不好,因为不一致性和计算开销太大,有很多研究在这方面。
Emprical study 实证研究 链接到标题
Priyanka用chatgpt做过zero-shot的日志解析,结果不太好,主要是不一致和scalability(这个专指开销). 用好的提示词可以提高性能,特别是fewshot的情况
prompt-based approch 基于提示的方法 链接到标题
这一段介绍了很多我没见过的方法和东西,很多名词我不懂,用ai告诉我的总结如下:
| 方法 | 解决什么问题 | 关键技术 | 一句话理解 |
|---|---|---|---|
| LILAC | LLM调用太慢太贵 | 缓存机制 + 层次采样 | 把解析过的模板存起来,下次直接用 |
| LLMParser | 是不是非得用大模型? | 对比4个不同尺寸模型 | 小模型也能做,可能更好 |
| Lemur | 怎么选给LLM看的示例? | 信息熵聚类 + 思维链 | 选"最具代表性"的日志当例子 |
| DivLog | 怎么提高模板准确性? | RAG检索 + ICL学习 | 先从库里找相似的,再让LLM改 |
| Sun et al. | 怎么落地到实际系统? | 云原生平台 + GPT-3.5 | 做了个完整系统,不只是算法 |
我还需要看看这几个原文的摘要。 2025年的定论:LLMParser和DivLog不是"谁对谁错",而是"各司其职"。最优方案是"微调后的小模型作为大脑,RAG作为知识库,缓存作为快捷键"的分层架构。小模型+RAG不仅在理论上可行,在特定领域已超越大模型
Fine-tuning Approach 微调方法 链接到标题
这个就好理解多了,就是微调大模型,让大模型专门搞日志解析,目前有OWL和BERT这两种。具体的得看原文了。
Metrics imputation 指标补全 链接到标题
挑战是生成的metrics过多(一秒千个),而且容易缺失,缺失的数据不一定表示系统又问题,补全可以让子任务更好地工作。
一般有记录矩阵M[F][T],M[f][t]表示在时间t上指标f的值,缺失值用NaN表示。目标是预测这些NaN的值,让预测的值接近真实值。本质就是个回归问题,输入是时间t和指标f,输出是M[f][t]的值。
指标插补方法可根据其生成多样化插补结果以反映插补过程固有不确定性的能力,分为两类:
- 预测式方法和生成式方法。 预测式方法。预测式插补方法对相同的缺失部分始终预测确定性的数值。许多研究为此提出了深度学习模型。例如,GRU-D采用RNN模型,TimesNet利用CNN模型,而Saits基于注意力模型。此外,若干方法利用大语言模型(LLM)。Zhou等人使用层冻结方法微调GPT-2和BERT等预训练模型,Nate等人则采用提示嵌入技术结合GPT-3、LLaMA-2和GPT-4完成指标插补任务。GatGPT采用图注意力网络预训练专用于指标插补的大语言模型。
- 生成式方法。 生成式方法建立在VAE、GAN和扩散模型等基础上。该类别中基于LLM的工作较少。GP-VAE、V-RIN和supnotMIWAE使用VAE方法进行指标插补,采用编码器-解码器结构,通过最大化边缘似然的证据下界(ELBO)来逼近真实数据分布。NAOMI和USGAN利用GAN进行生成式指标插补。SSSD和CSBI基于扩散模型,通过马尔可夫链的扩散步骤逐步添加噪声再逆向还原,从而捕捉复杂的数据分布。
Input Summarization 输入摘要 链接到标题
输入在一般情况下是日志、指标和跟踪数据的组合,直接输入LLM会导致输入过长,效率低下。输入摘要方法通过提取关键信息来减少输入长度,提高效率。
输入摘要方法由是否使用大模型分成两类:
-
无大模型方法。 这种类型的方法不使用大模型
类别 核心机制 代表方法 具体做法 提示剪枝 (Prompt Pruning) 在线移除不重要的信息 DYNAICL, Selective Context, LLMLingua, LongLLMLingua 基于预定义或可学习的重要性指标,从输入提示中移除不重要的token、句子或文档 语义压缩 (Semantic Compression) 将原始提示浓缩为简短摘要 RECOMP, SemanticCompression 将原始提示压缩成更短的摘要形式,同时保留相似的语义信息 基于度量的软提示 (Metric-based Soft Prompt) 设计场景特定的短提示 Nate et al., TEST 使用软提示策略为特定场景和数据设计专门的短提示,比原始提示显著更短 -
用大模型的方法:
类别 核心机制 代表方法 具体做法 零样本直接压缩 (Zero-shot Compression) 直接输入提示测试LLM压缩效果 Priyanka et al., Chris et al. 直接将提示输入ChatGPT,测试其对日志数据的压缩效果 事件报告摘要 (Incident Report Summarization) 总结大量事件报告 Zhang et al., Drishti et al., Chen et al., Oasis 尝试对大量的事件报告进行摘要总结 外部技术文档/代码摘要 (External Doc/Code Summarization) 总结外部资料构建辅助知识库 Zhou et al., D-Bot 总结外部技术文档或代码,创建辅助知识库
FAILURE PERCEPTION 失败感知 链接到标题
用处理过的数据来做故障检测,这是最重要的任务,2 个:
- failure prediction → 故障预测
- anomaly detection → 异常检测
failure prediction 故障预测 链接到标题
这个主要是在线预测,预测给定时间窗口出现failure的概率。 但是因为难以检测,所以研究要么只局限于特定类型的故障,要么存在较高的漏检率。
但是也有一些研究
| 研究/方法 | 核心贡献 | 具体做法 | 关键特点/局限 |
|---|---|---|---|
| Clairvoyant | 基于BERT的自监督故障预测模型 | 利用日志数据训练,预测HPC系统中的节点故障 | 仅能预测故障,无法预测提前时间 |
| Time Machine | 扩展Clairvoyant的预测能力 | 采用双栈Transformer-Decoder架构 | 不仅能预测故障,还能预测提前时间(lead times) |
| Yang et al. | 通过数据插补提升数据质量 | 基于样本高效的扩散模型进行数据插补 | 改善下游故障预测任务的性能 |
| Xiong et al. | 系统性LLM置信度校准框架 | 三组件设计:①提示策略(获取语言化置信度)②采样方法(生成多响应)③聚合技术(计算一致性) | 发现LLM存在过度自信问题;通过人类启发式提示、多响应一致性、优化聚合策略可缓解过度自信,效果接近微调模型 |
anomaly detection 异常检测 链接到标题
也是看特定时间的数据是否异常,3种方法: Prediction-Based Methods, Reconstruction-Based Methods, and Classification-Based Methods
Prediction-Based Methods 基于预测的方法 链接到标题
基于预测的方法通过训练模型预测系统的正常行为,然后将实际观察到的行为与预测结果进行比较,以检测异常。可以看成指标时间序列预测和日志事件预测任务
目前这些方法多预测metics,预测日志事件的还比较少。 又通过如何利用LLM分成4类: foundational model, fine-tuning approach, prompt-based approach, and embedding-based approach.
foundational model 基础模型:设计一个模型并预训练并不是大模型,表中是已有工作
| 模型 | 引用 | 架构/方法特点 | 主要功能/优势 |
|---|---|---|---|
| TimeGPT | 多层编码器-解码器结构 | 首个专门为时间序列预训练的基础模型 | |
| Lag-llama | 仅解码器Transformer,使用滞后项(lags)作为协变量 | 单变量概率时间序列预测的通用基础模型 | |
| TimesFM | 分块解码器(patched-decoder)风格的注意力模型 | 适用于不同预测历史长度、预测长度和时间粒度 | |
| TTM | 轻量级TSMixer架构,自适应分块、多样化分辨率采样、分辨率前缀调优 | 以最小模型容量处理多分辨率数据集预训练 |
光有基础模型还不够,还需要微调。
| 方法 | 引用 | 技术特点 | 应用场景 |
|---|---|---|---|
| FPT (Zhou et al.) | 冻结预训练Transformer(Frozen Pretrained Transformer) | 将语言或计算机视觉模型迁移到时间序列任务 | |
| LLM4TS | 两阶段微调:①监督微调适应时序数据 → ②任务特定下游微调 | 使大语言模型适应时间序列预测 | |
| Khanal et al. | 单步微调,融合源域数据,渐进解冻(gradual unfreezing) | 跨域迁移学习,提供多样化时间序列实例 | |
| LogFiT | 基于BERT的预训练模型,使用日志数据微调 | 日志异常检测(通过top-k预测准确率判断偏离程度) |
训练基础模型或进行微调需要大量的时间和硬件资源。因此,已有若干研究工作提出了无需重新训练预训练模型即可执行预测的方法.
| 方法 | 引用 | 核心思想 | 技术特点 |
|---|---|---|---|
| PromptCast | 将数值输入/输出转换为文本提示 | 以句子到句子(sentence-to-sentence)的方式构建预测任务 | |
| Time-LLM | 提示作为前缀(Prompt-as-Prefix, PaP) | 丰富输入上下文,引导重编程输入分块的转换,再投影获得预测 | |
| TEMPO | 时间序列解耦 + 提示池 | 分解为趋势/季节/残差分量,构建提示池为不同分量分配提示,利用历史信息适应分布变化 | |
| LSTPrompt | 任务分解 + 思维链 | 将预测分解为短期和长期子任务,使用Chain-of-Thought(CoT)为各子任务定制提示 |
一些方法依赖大模型的嵌入能力来执行预测任务,特别是在日志数据的背景下。这些大模型的嵌入能力在提取日志语义信息方面非常有效。
| 方法 | 引用 | 模型/技术 | 应用场景 | 核心机制 |
|---|---|---|---|---|
| Egil et al. | 自编码器 + 自监督学习 | 日志异常检测 | 压缩嵌入表示,通过自监督学习检测异常 | |
| Harold et al. | BERT/GPT-2/XLNet + BiLSTM | 系统行为学习 | 将大模型嵌入向量按时间链式输入双向LSTM学习正常行为 | |
| LogADSBERT | Sentence-BERT + BiLSTM | 日志事件预测 | 先用Sentence-BERT提取语义特征,再用BiLSTM预测日志事件 |
Reconstruction-Based Methods 链接到标题
基于重构的异常检测利用模型重构输入数据,并通过测量重构误差来检测异常。如果重构误差超过某个阈值,该数据点即被视为异常。这种方法假设异常无法被模型准确重构。
这个方法的想法还蛮怪的,就是类似于用模型抽特征,再用特征重画输出,输出看起来正常就表示输入正常(因为模型应该不认识异常),输出看起来不正常就表示输入异常。这个方法的核心是重构误差,重构误差越大,越可能是异常。这个和classification有区别吗,我是看不出区别的,还是得看看原论文了。
已有工作:
| 方法 | 技术基础 | 核心机制 | 特点/创新 |
|---|---|---|---|
| LANoBERT | BERT + 掩码语言建模(MLM) | 通过掩码语言建模损失函数检测日志键异常 | 无监督检测,针对日志键级别 |
| Prog-BERT-LSTM | 渐进式掩码策略 | 聚合文本语义向量与序列特征向量 | 渐进式掩码,融合文本与时序特征 |
| SimMTM | 掩码重建 + 邻域聚合 | 基于未掩码部分重建掩码内容,通过流形外邻居加权聚合恢复时间点 | 利用多个掩码序列的互补信息,简化重构任务 |
classification-Based Methods 链接到标题
这个就是把异常检测当成分类问题,训练一个分类器来区分正常和异常数据点。这个方法的核心是训练一个能够区分正常和异常的分类模型。 又根据是否使用大模型分成两类:
LLM Assisted classification methods 链接到标题
LLM辅助的分类方法,本质上是一种"大模型出脑子,小模型出手"的协作模式。 大语言模型负责提供嵌入向量或特征提取,把那些高维、晦涩的原始数据转化成富含语义信息的表征。而真正做最终判决的,往往是那些更轻量、更 specialized 的小模型。这种架构在日志异常检测领域尤为流行——毕竟日志文本里藏着太多语义细节,传统方法根本抓不住那股"弦外之音"。 早期的探索者走的是另一条路。RobustLog算是开先河者之一,它用FastText算法从日志事件里抽取语义信息,转化成向量后,交给基于注意力机制的Bi-LSTM做分类。后来者的PLELog沿用了类似的语义提取思路,但把整套算法改成了半监督学习的路子,摆脱了对标注数据的过度依赖。NeuralLog则更进一步,直接用Word2Vec做语义转换,干脆取消了日志解析这一步——毕竟解析出错是日志分析里的老大难问题,一了百了反倒干净。 不过说到底,这三位用的都还算不上大语言模型,充其量只是传统的语义提取工具。 真正的转折点出现在Egil等人的工作里。他们换上了BERT来做语义提取,实验结果证明,用正经的LLM来抽特征,检测效果确实更上一层楼。 此后这路技术便如星火燎原。MultiLog项目在分布式软件场景下,让BERT去萃取每个节点的日志语义,做完语义压缩后,在协调节点上用自编码器做最终的融合与分类。LogST则选用了SBERT来抓取日志事件的语义,最后交给GRU模型来把关异常。Ji等人的方案更为花哨——他们用SBERT提取日志嵌入,再用GPT-2做语义转换,最后架了一层告警策略层来综合判定异常。 每一条技术路线,都在试图回答同一个问题:如何让机器真正读懂那些看似杂乱无章的日志背后,到底藏着什么猫腻。
LLM-decision classification methods 链接到标题
这个就是让大模型直接决定是否有问题。
LLM-decision分类方法直接利用大型语言模型进行决策。这类方法通过对LLM进行微调或提示,使其将输入数据分类为正常或异常,而无需依赖较小的模型进行最终分类。这些方法可分为两大类:基于训练的方法和基于提示的方法。 在基于训练的方法中,许多研究工作利用BERT及其变体,主要专注于日志数据。BERT-Log采用预训练语言模型学习正常和异常日志的语义表示,并使用全连接神经网络对BERT模型进行微调以检测异常。LogPrompt利用提示引导预训练语言模型更好地理解日志的语义和时序信息,避免了从头训练模型的需要。HilBERT使用来自Loghub上17个日志数据集的日志模板信息,在异常检测任务中进行全量微调。为了降低全量微调的高昂成本,LogBP-LORA提出了一种基于BERT和低秩适应(LoRA)的参数高效日志异常检测方案,该方案引入旁路权重矩阵,仅更新旁路参数而非所有原始参数。 此外,也有一些研究工作利用指标数据进行微调。TS-Bert使用指标数据对BERT进行全量微调。Zhou等人采用层冻结方法对GPT-2和BERT等预训练模型进行微调。另外,部分研究工作使用知识蒸馏技术从LLM中学习异常检测知识。AnomalyLLM使用GPT-2作为教师模型,训练了一个用于基于指标数据的异常检测的学生模型。 基于提示的方法则采用了更新的思路,避免了模型训练,转而利用提示工程来引导LLM执行分类任务。随着大型语言模型规模的不断增长,人们普遍认为它们天生具备异常检测能力,可以通过有效的提示来激发这些能力。 一些方法直接向LLM输入提示以确定异常的存在,其中许多研究工作专注于日志数据。Priyanka等人开展了一项使用ChatGPT进行零样本日志异常检测的研究,表明当前版本的ChatGPT在这项任务中的性能有限。Chris等人不仅提示ChatGPT检测日志片段中的异常,还采用输入摘要技术结合历史数据进行更全面的评估,取得了更好的效果。RAGLog通过将检索增强生成(RAG)技术与向量数据库相结合,增强了基于LLM的异常检测能力,提高了检测准确性。LogGPT采用思维链(CoT)提示来增强LLM在异常检测中的性能,实现了更细致和有效的分析。 与基于日志数据的方法不同,基于指标数据的研究工作通常需要对指标数据进行特殊的提示嵌入处理。TEST首先对指标数据进行分词,构建编码器通过实例级、特征级和文本原型对齐对比的方式对其进行嵌入,然后创建提示使LLM更容易接受这些嵌入表示,最终实现了基于指标数据的分类。SigLLM采用时间序列到文本的转换模块,以及端到端的流程来提示语言模型执行时间序列异常检测,直接要求语言模型指出输入中哪些元素是异常。TabLLM将指标数据序列化为自然语言字符串来提示大型语言模型,用于少样本和零样本的指标数据分类。
Root Cause Analysis 链接到标题
在大型语言模型兴起之前,这些任务通常依赖系统生成的数据,利用自动化的故障感知方法来识别异常,进而用于故障定位和故障类别分类。然而,随着大型语言模型的出现,根因分析的起点已从自动化的故障感知转向了用户生成的数据,特别是引入了自然语言分析能力的事件报告。 此外,根因分析现在还整合了其他人工生成的数据(如文档和代码),将其作为补充知识源以增强分析能力。进一步地,基于LLM的自然语言理解与生成能力,现在可以绕过故障定位和故障类别分类的过程,直接生成根因报告。