LogLLM: Log-based Anomaly Detection Using Large Language Models

https://arxiv.org/pdf/2411.08561

 

요약

• 로그 기반 이상 탐지는 로그 데이터를 통해 시스템 문제를 식별하는 것을 목표로 하는 연구 분야로, 소프트웨어 시스템의 신뢰성을 향상시킴
• 기존의 딥러닝 방식은 자연어로 된 로그 데이터에서 내포된 의미 정보를 포착하지 못함
• 본 논문에서, LLM을 활용한 로그 기반 이상 탐지 프레임워크인 LogLLM을 제안

 

• LogLLM은 로그 메세지로부터 semantic vector를 추출하기 위해 BERT 사용
• 로그 시퀀스를 분류?하기 위해 Transformer Decoder 기반 모델인 Llama를 활용
• BERT와 Llama의 Vector representation space를 정렬하여 로그의 의미를 일관적으로 이해하도록 Projector를 도입

 

• 기존 방식 : 로그 템플릿 추출을 위해 로그 파서를 필요로 함
• LogLLM : 정규 표현식으로 로그메세지 전처리

 

• Performance과 Adaptability 향상을 위한 3단계 학습 프로시저
• 4개의 데이터셋으로 실험한 결과, SOTA 메서드들보다 우수한 성능
  • 불안정한 로그 처리할 때 로그 메세지 의미를 효과적으로 포착하고, 이상 탐지를 정확히 함

---

1. Introduction

Anomaly Detection이 필요한 이유

• Large-scale software-intensive 시스템에서는 높은 availability와 reliability를 보장하는 것이 중요
• 시스템이 더 복잡하고 확장됨에 따라 이상(anomaly)의 발생은 피할 수 없음
• 작은 문제라도 성능 저하, 데이터 무결성 문제, 고객과 수익의 큰 손실로 이어질 수 있음
• 이상 탐지(anomaly detection)은 복잡한 software-intensive 시스템의 건강와 안정성 유지에 필수적

Why "Log-based anomaly detection"?

• Software-intensive 시스템은 일반적으로 시스템 상태와 주요 런타임 이벤트를 기록한 콘솔 로그를 생성
• 엔지니어들은 로그 데이터를 활용하여 시스템 상태를 평가, 이상 탐지, 문제 원인을 추적
• 로그 양이 방대해질 수 있어, 수동으로 분석하는 것은 노동 집약적 + 실수 발생하기 쉬움
• 로그 데이터로 시스템 이상을 자동으로 식별하는 "Log-based anomaly detection"은 자동 로그 분석 핵심분야

기존 Method들의 한계점

• 일반적으로 LSTM이나 Transformer와 같은 sequential deep learning 모델 사용
• Methods
  • 재구성 기반(reconstruction-based methods)
  • 이진 분류 기반 (binary classification-based methods)
• 재구성 기반
  • 입력된 로그 시퀀스를 재구성하도록 학습, 재구성 오차(reconstruction error)를 기반으로 이상 탐지
  • 원리 : "이상 샘플은 정상처럼 정확하게 재구성되지 않는다"
• 이진 분류 기반
  • 샘플을 정상 또는 이상으로 분류하는 classifier 설계
  • 레이블이 지정된 이상 데이터가 필요
• 시스템 로그는 일반적으로 자연어로 작성되며, 많은 semantic information 담고 있음
• 기존 딥러닝 기반 방법들은 semantic information을 효과적으로 포착하는 데 한계가 있음

로그 기반 이상 탐지에서의 LLM 단점

• 기존 방법 : 프롬프트 엔지니어링 & 파인튜닝 기반
• 프롬프트 엔지니어링
  • LLM의 zero/few-shot 능력 활용, 모델 내부 지식만으로 이상 탐지
  • 특정 데이터셋에 맞춘 솔루션 제공하는데 어려움 + 탐지 성능 최적화 X
• 파인튜닝 기반
  • LLM을 딥러닝 network에 통합 + 사용자 맞춤형 데이터셋에 특화되도록 조정
  • semantic understanding? 한계
  • 의미 정보 추출을 LLM에만 의존함으로써 발생하는 비효율성
  • input format에 대한 고려 부족 : memory overflow 문제

LogLLM

• LogLLM은 기존처럼 log parser를 사용해 템플릿을 추출하는 방식과 다르게 정규표현식을 사용하여 로그 메세지를 전처리하여, 전체 과정을 간소화
• LogLLM : 파인튜닝 기반 방법
  • 로그 메세지로부터 semantic vector 추출을 위해 transformer encoder 기반 모델 BERT 사용
  • 로그 시퀀스를 분류하기 위해 transformer decoder 기반 모델 Llama 활용
• log semantic의 일관성을 보장하기 위해 BERT와 Llama의 vector representation space를 정렬시키는 Projector 도입
• performance와 adaptability를 향상시키기 위해 3단계 학습 프로시저를 통해 학습

 

• LLM은 메모리 부족 문제에 자주 직면
• 로그 메세지를 하나의 긴 문자열로 연결(concatenate)하여 전체 로그 시퀀스를 직접 Llama에 입력하면 메모리 부족 문제 발생 + LLM이 핵심적인 이상 탐지 포인트에 집중하기 어려워짐
• BERT로 로그 메세지 요약(summarize)하여 위의 문제 해결

 

• 4개의 데이터셋에서 실험 수행, LogLLM이 SOTA보다 뛰어난 성능 보임
• 소프트웨어의 진화로 인해 새로운 로그 템플릿이 자주 등장하는 불안정한 로그 환경에서도 로그 메세지의 의미를 잘 포착하고 이상을 정확히 탐지
• 3단계 학습 프로시저는 ablation study로 입증

Contribution

• 새로운 로그 기반 이상 탐지 프레임워크 LogLLM 제안
  • 트랜스포머 인코더 기반 BERT와 디코더 기반 LLM Llama를 동시에 활용한 시도로, 로그 기반 이상 탐지 분야에서 의미 있는 진전
• 딥러닝 모델 내의 다양한 구성요소들을 효과적으로 학습하고 조정하기 위한 3단계 학습 프로시저 제안
  • performance와 adaptablility 모두 향상 
• 4개 데이터셋에서 광범위한 실험 수행 + LogLLM의 우수한 성능을 실증적으로 입증 

 

2. Related Work

Reconstruction-based methods

• 입력된 로그 시퀀스를 재구성하도록 deep neural network를 설계하고 학습시키는 방식
• anomaly는 재구성 오류(reconstruction error)를 기준으로 탐지
  • 정상적인 로그 시퀀스는 오차가 거의 없이 재구성
  • 이상 로그 시퀀스는 정확하게 재구성되지 못해, 훨씬 큰 재구성 오류가 발생
• 항상 이상이 없는 정상 데이터만을 이용해 딥러닝 학습 : semi-supervised 방식

Binary classification-based methods

• 하나 또는 두 개의 값을 출력하는 딥 뉴럴 네트워크 사용
• 일반적으로, single value는 해당 샘플이 이상 클래스에 속할 확률, 이 확률에 threshold 적용하여 이상 여부를 이진 분류
• 두 개의 값 출력하는 경우, 각각 정상 클래스와 이상 클래스에 속할 확률을 나타냄

 

3. Preliminaries

• 기초 마련을 위해 System log 소개
  • 실행 시간 동안 시스템의 이벤트 및 내부 상태 기록한 것
  • 시간 순으로 정렬된 로그 메시지 목록으로 구성

• Fig 1 : BGL(BlueGene/L 슈퍼 컴퓨터 시스템)에서 생성된 raw 시스템 로그 일부
  • 기록된 시간에 따라 순서대로 정렬
  • raw log messages는 semi-structured 텍스트로, header와 content로 구성
    • header : 로깅 프레임워크로 결정, 타임스탬프, 로그 수준(ex : WARN/INFO), 컴포넌트 등의 정보
    • content : 고정된 부분(로그 템플릿 나타내는 키워드), 변화는 부분(실행 중의 동적인 정보를 담고 있는 파라미터)로 구성
• 본 논문에서는 content에만 집중

 

• 로그 메세지는 session 또는 fixed/sliding windows 방식에 따라 log sequences(특정 실행 flow를 기록하는 일련의 로그 메세지들)로 그룹화할 수 있음
• Session window partitioning
  • 세션 ID를 기준으로 로그 메세지를 그룹화하여, 각 세션 내에 포함된 로그 메세지들로 sequence 생성
  • 예로, Fig 2a는 HDFS 로그에 session window 그룹화 과정을 적용한 예시
  • $block_id$가 세션 ID로 사용
• Fixed/sliding window partitioning
  • 고정된 window size를 기준으로 로그 메세지를 그룹화
  • window size는 시간 간격이나 로그 메세지 수로 정의
  • 일정 시간 동안의 시스템 로그 스냅샷을 담은 시퀀스 생성
  • 예로, Fig 2bsms BGL 로그에 sliding window 그룹화 과정을 적용한 예시
    • 이 때 window size는 2개의 메세지, step size도 2개의 메세지
• 로그 기반 이상 탐지 목적 : 이상 로그 시퀀스를 식별하여 시스템 동작 중 발생할 수 있는 잠재적인 문제 인식하도록 돕는 것

4. Methodology

A. Preprocessing

Variable parameter와 필요한 기술

• 로그 메세지 content에는 dynamic runtime information을 담고 있는 variable parameter들이 포함됨
  • variable parameter들은 이상(anomaly)과 무관하며, 딥러닝 모델의 학습을 복잡하게 함
  • 이러한 파라미터를 식별하고 고정된 토큰으로 대체하는 기술 필요

Log parser의 문제점

• Drain과 Spell과 같은 로그 파서의 문제점
  • 기존 로그 파서들은 모든 로그 데이터셋에서 항상 제대로 동작하지 않음
  • 새로운 로그 메세지에 포함된 OOV(Out-of-Vocabulary) 단어들을 처리하기 어려움
  • 그 결과, Semantic information 손실
  • 로그가 unstable해지고, 새로운 형식의 로그가 계속 등장하는 환경에서는 비효율적 & 이상 탐지 지원이 어려움

제안하는 방법 : 정규표현식

• 구조화된 로그 생성 과정으로, 특정 객체를 나타내는 파라미터의 텍스트 형식을 정규표현식으로 쉽게 식별할 수 있음
  • account, directory path, IP address와 같은 variable parameter들은 모두 $<*>$로 대체
  • 단순하지만 상당한 성능 향상 가져옴
  • 학습을 필요로 하지 않음

B. Model Architecture

• Fig 3에서, 제안하는 모델은 3가지 구성요소(BERT, Projector, Llama)로 이루어져 있음
  • BERT : 로그 메세지 vector representation 추출
  • Llama : 로그 시퀀스 분류
  • Projector : BERT와 Llama의 vector representation space를 정렬하는 중간다리 역할
• BERT와 Projector가 각각 단 하나만 사용됨

BERT

• [CLS] classification token의 semantic vector를 linear layer와 tanh 활성화 함수를 통해 처리하여 최종 semantic vector를 생성
• 각 로그 메세지는 전처리 된 후, BERT 토크나이저와 모델을 이용해 semantic vector로 인코딩 됨
• 전처리된 로그 시퀀스에 대해, BERT output은 다음과 같은 semantic vector sequence :
  $$C=(c_1, c_2, ..., c_n) \in \mathbb{R}^{N \times d_{BERT}}$$
  • $N$ : 로그 시퀀스의 길이(로그 메세지 개수)
  • $d_{BERT}$ : semantic vector의 차원(hidden size)

Projector

• Linear Layer로, semantic vector $C \in \mathbb{R}^{N \times d_{BERT}}$를 Llama가 받아들이는 토큰 임베딩 벡터 $E = (e_1, e_2, ... , e_n) \in \mathbb{R}^{N \times d_{Llama}}$ 로 변환
  • $d_{Llama}$ : Llama의 hidden size
  • projector는 BERT와 Llama의 vector representation space를 정렬(align)하도록 설계

Llama

• 프롬프트 튜닝을 수행하기 위해 임베딩된 로그 시퀀스를 기반으로 한 텍스트 형태의 query를 생성
• query 3가지 구성 요소 : 
  1. 로그 시퀀스를 소개하는 문장 : "Below is a sequence of system log messages : "
  2. Projector의 output token embedding $E$
  3. 해당 시퀀스 이상(anomalous) 여부 묻는 질문 : "Is this sequence normal or anomalous?"
• 1과 3은 Llama의 토크나이저와 임베딩 레이어에 input 되어 각각 $E_1 \in \mathbb{R}^{A \times d_{Llama}}$ 와 $E_3 \in \mathbb{R}^{Q \times d_{Llama}}$ 임베딩 벡터 생성
  • $A$ : 1의 토큰 수
  • $Q$ : 3의 토큰 수
• 세 구성 요소의 토큰 임베딩을 $[E_1||E||E_3] \in \mathbb{R}^{(A+N+Q) \times d_{Llama}}$로 concatenate하여 Llama에 입력

C. Training

1) Minority Class Oversampling

• LogLLM은 supervised anomaly detection method로, 학습을 위한 정상(normal)과 비정상(anomalous) 샘플에 대한 라벨 필요
• supervised anomaly detection의 경우 데이터 불균형 문제 > 모델 학습에 bias 유발
• 각 클래스 샘플 수는 불확실
• 불균형 문제 해결을 위해 샘플 수가 더 적은 클래스를 oversampling하여 비율이 최소 $\beta$ 이상이 되도록 함
  • 소수 클래스의 비율이 $\alpha$, $\alpha < \beta$
  • $Sample_num$ : 전체 샘플 수
  • 소수 클래스를 $\beta$ 비율에 도달하도록 오버샘플링

$$\frac {\beta(1-\alpha)}{1-\beta}  \times Sample\_num$$

• 이 조정으로 소수 클래스 비율은 $\beta$와 같아지게 됨

2) Training Objective

• 학습 목표 : 주어진 로그 시퀀스가 정상인지 이상인지 예측하는 딥러닝 모델 학습
  • 모델이 적당히 응답할 수 있도록 파인튜닝
    • anomalous 일 경우 : "The sequence is anomalous." 출력
    • nomal일 경우 : "The sequence is nomal." 출력
  • cross-entropy loss 사용

3) Training Procedure

1. answer template을 학습하도록 Llama를 Fine-tuning
   • Llama가 프롬프트 "Is this sequence normal or anomalous?"에 대해 "The sequence is anomalous." 또는 "The sequence is normal" 형태로 응답하도록 학습
   • 소량의 데이터 샘플만으로도 충분
2. 로그 메세지 embedder 학습(BERT와 Projector 학습)
   • 목표 : 각 로그 메세지를 Llama에서 가장 적절한 토큰 임베딩 space로 project하는 것
   • 이를 통해 Llama가 주어진 log sequence가 normal인지 anomalous인지 구별하도록 함
3. 전체 모델 fine-tuning
   • 전체 모델을 fine-tuning하여 모든 구성 요소가 일관되고 정확하게 작동하도록 함

4) Efficient Fine-Tuning on LLMs

• 파라미터 수가 많은 LLM(BERT와 Llama)을 파인튜닝하는 데 드는 비용을 줄이기 위해 "QLoRA"를 사용하여 메모리 사용을 최소화
  • QLoRA : 동결된(frozen) 4 bit quantized 모델에 gradient를 역전파함(16 bit full fine-tuning과 동등한 수준의 성능)

 

5. Experiments

4개의 실제 로그 데이터를 대상으로 광범위한 실험을 수행하여 다음의 Research Questions들 연구

• RQ1 : LogLLM은 로그 기반 이상 탐지에서 얼마나 효과적인가?
• RQ2 : 서로 다른 전처리 기법들이 LogLLM의 성능에 어떤 영향을 미치는가?
• RQ3 : Llama용 임베더는 얼마나 효과적인가?
• RQ4 : Llama 모델의 크기는 LogLLM의 성능에 어떤 영향을 주는가?
• RQ5 : 3-step으로 구성된 학습 절차와 각 단계는 LogLLM의 성능에 어떻게 기여하는가?
• RQ6 : 하이퍼파라미터 $\beta$에 의해 결정된느 소수 클래스 오버샘플링 수준은 LogLLM의 성능에 어떤 영향을 주는가?

https://github.com/guanwei49/LogLLM

GitHub - guanwei49/LogLLM: LogLLM: Log-based Anomaly Detection Using Large Language Models (system log anomaly detection)

 

Dataset

HDFS(Hadoop Distributed File System)

• 200개의 Amazon EC2 노드에서 Hadoop 기반 맵리듀스 작업을 실행하여 생성된 것
• 총 11,175,629개의 로그 메세지
• 로그 메세지는 block_id를 기준으로 서로 다른 로그 윈도우로 그룹화되며, HDFS에서 프로그램 실행 단위를 반영
  • 그 결과 총 575,061개의 블록 생성
  • 이 중 16,838개의 블록(2.93%)은 anomaly를 나타냄

BGL(Blue Gene/L)

• Lawrence Livermore National Labs의 BlueGene/L 슈퍼컴퓨터 시스템에서 수집된 슈퍼 컴퓨팅 시스템 로그 데이터셋
• 총 4,747,963개 로그 메세지
• normal, anomalous로 직접 레이블링
• 348,460개의 로그 메세지(7.34%)가 anomalous로 레이블

Thunderbird

• Sandia National Laboratories(SNL)의 Thunderbird 슈퍼컴퓨터에서 수집된 공개 로그 데이터셋
• normal 및 anomalous 메세지를 포함하고 있으며 직접 분류됨
• 전체는 2억 개 이상의 로그 메세지를 포함하고 있으나, 계산 효율성을 위해 연속된 1천만 개의 로그 메세지 subset 사용
• 4,937개의 anomalous 로그 메세지(0.049%)가 포함됨

Liberty

• SNL의 Liberty 슈퍼컴퓨터에서 수집된 시스템 로그
• 2억 개 이상의 로그 메세지 포함
• 계산 효율성을 위해 연속된 500만 개의 로그 메세지를 샘플링
• 그 중 1,600,525개가 anomalous(32.01%)로 식별

 

• HDFS의 경우 session window 전략을 사용
  • 각 로그 메세지에 포함된 block_id를 기준으로 로그 메세지들을 sequence로 그룹화
  • 각 세션은 ground truth을 이용해 레이블이 지정됨
• BGL, Thunderbird, Liberty 데이터셋의 경우 sliding window 전략을 사용
  • 윈도우 크기는 100개의 메세지, step size도 100개 메세지
  • sequence가 anomoalus로 간주되는 기준은 ground truth에 따라 하나 이상의 로그 메세지를 포함하고 있을 경

 

기존 연구들과 유사하게, 각 데이터셋을 training set과 testing set으로 8:2로 분할하여 로그 기반 이상 탐지 approach의 성능 평가

• HDFS의 경우 로그 시퀀스를 무작위로 학습 데이터와 테스트 데이터로 분할
• BGL, Thunderbird, Liberty는 chronological split(시간 순)으로 분할
  • chronological split 전략은 학습 셋의 모든 로그 시퀀스가 테스트 세트보다 시간상 먼저 발생한 것으로 보장하며, 실제 환경을 반영하고, 불안정한 로그 데이터에서 발생할 수 있는 data leakage를 완화

(RQ1) Performance Evaluation

LogLLM은 모든 데이터셋에서 가장 높은 F1-Score 달성

평균적으로 LogLLM의 F1-Score는 기존 최고 성능 모델인 NeuralLog보다 6.6% 더 우수하여 뛰어난 효과를 입증

 

FastLogAD, LogBERT, NeuralLog, RAPID 등도 이상 탐지를 위해 LLM을 도입했지만 성능이 불만족스러움

• FastLogAD & LogBERT
  • BERT를 활용해 로그 시퀀스의 reconstruction error를 기반으로 이상 탐지
  • 로그 파서를 사용해 추출한 로그 템플릿 id sequence를 입력으로 사용하기에, semantic information이 부족함
• NeuralLog & RAPID
  • 로그 메세지로부터 의미 벡터를 추출하기 위해 트랜스포머 인코더 기반 모델 사용
  • NeuralLog는 작은 모델을 사용하고, RAPID는 거리 기반 비교 방법을 사용해 이상 sequence를 분류하기 때문에 한계가 있음
• LogLLM
  • BERT를 사용해 의미 벡터를 추출
  • Llama를 통해 이상 탐지 수행
  • projector를 통해 BERT와 Llama의 repersentation space를 정렬함으로써 LLM의 잠재력을 최대한 활용하여 성능을 끌어올림

 

• LogLLM은 precision과 recall 간의 균형을 잘 맞추고 있어, false alarm 비율이 낮고, 이상 탐지 누락도 최소화 함
• FastLogAD와 같은 방법은 anomalous에 지나치게 민감하여 과도한 false alarm 유발
  • BGL에서 FastLogAD는 recall 1을 달성
  • precision은 0.167에 불과하여 실제 환경에서 사용하기 어려움
  • DeepLog, LogAnomaly, LogBERT 유사한 문제
• RAPID는 anomalous에 대한 민감도가 부족하여 많은 anomalous를 탐지하지 못함
  • BRL에서 precision 0.874를 기록했지만 recall은 0.399에 불과

Effect of labeled anomalies

• 표2에서, DeepLog, LogAnomaly, FastLogAD, LogBERT, RAPID는 anomaly가 포함되지 않은 깨끗한 데이터셋이 있어야 이상 탐지 모델을 구축할 수 있음
• PLELog, LogRobust, CNN, NeuralLog, LogLLM은 더 뛰어난 성능 보여줌
  • normal 샘플 뿐만 아니라, 레이블이 지정된 anomalies도 함께 학습에 사용
  • 위 다섯 가지 방법은 4개 데이터셋에서 평균 F1-Score가 0.771 이상을 기록했지만,
    레이블 데이터를 사용하지 않은 방법들은 0.602 이하로 낮은 성능을 보임
• 레이블링된 이상 데이터를 포함하여 학습시키는 것이 이상 탐지 기법에 상당한 성능 향상을 가져옴

Computational cost

모든 데이터셋에 걸쳐 평균을 낸 값

• RAPID : 딥 모델 학습이 필요 없지만, vector representation 추출 및 검색 과정에서 시간이 많이 소요
• FastLogAD : 상대적으로 학습 시간이 길지만, 테스트 시 모델의 discriminator만 사용하여 가장 짧음
• LogLLM : 가장 뛰어난 성능 보여주지만, 매우 많은 파라미터 수로 인해 계산 비용이 가장 높음
  • 그럼에도 불구하고 테스트 시간은 LogBERT, NeuralLog, RAPID와 같은 LLM 기반 방법들과 비교했을 때 충분히 수용 가능한 수준

(RQ2) Different Preprocessing Techniques

다양한 전처리 기법의 효과

전처리 방식

• Raw : 로그 메세지 내용을 전혀 전처리하지 않고 그대로 제안한 딥 모델에 입력
• Template : 로그 파서 Drain을 사용하여 생성된 로그 템플릿 시퀀스를 입력으로 사용
• Template ID : Drain으로부터 얻은 로그 템플릿 ID를 숫자 벡터로 단순 임베딩하여 입력
  (BERT 사용 X, 로그 메세지의 semantic information)을 모델이 포착할 수 없음
  • Drain 파서는 학습데이터 뿐만 아니라 전체 데이터셋에 적용
  • OOV 문제로 인한 성능 저하를 방지하기 위함
• RE : 정규표현식을 사용하여 로그 메세지를 전처리 하는 방식

 

• RE 전처리 기법은 모든 데이터셋에서 가장 높은 F1-Score 기록
• Template ID는 가장 낮은 F1-Score를 보였으며, 평균 성능은 RE보다 36.8% 낮음
  • 로그 메세지에 담긴 semantic information을 모델이 파악하는 것을 방해하여, 자연어 관점에서 이상 탐지 능력을 저하시켰기 때문
• Raw와 Template은 상대적으로 양호한 성능 보였지만, RE보다 6.4%, 5.7% 낮았음
  • Raw : variable part가 이상 탐지에 큰 영향을 주지 않지만, 랜덤성이 높아 모델을 혼란스럽게 하여 anomalies 탐지를 어렵게 함
  • Template : 로그 파서 Drain을 사용하는데, 이 파서를 항상 신용할 수 없음 +
    constant 부분을 잘못 제거하거나 variable 부분을 유지하는 오류 범할 수 있음
    -> 정보 손실 또는 혼란을 야기, anomalies를 잘 구분하지 못하게 함

(RQ3) Effect of the Embedder

Embedder(BERT & adapter) 필수 여부 조사

• L.-1B : 로그 메세지를 세미콜론(;)으로 구분하여 하나의 긴 문자열로 연결한 뒤, Llama-3.2-1B 모델에 직접 입력하는 방식
• Emb. & L.-1B : Llama-3.2-1B 기반 LogLLM을 의미하며, Embedder(BERT와 projector)를 포함한 방식

 

• Embedder를 사용할 경우, GPU 메모리 소모가 줄어 메모리 부족(Out-of-Memory) 오류 방지
• 시퀀스 내에서 메세지 간 경계를 명확히 구분하여 모델 성능 향상
• 개선된 representation 방식은 LLM이 시퀀스 간의 의존 관계를 더 학습할 수 있도록 도움

(RQ4) Effect of the Llama Model Size

• 표 5처럼, 더 큰 Llama 모델 사용할수록 성능 향상되지만, GPU 메모리 증가와 더 긴 학습 시간이 필요함
• 평균적으로 Llama-3.2-1B 대신 Llama-3-8B를 사용할 경우, F1-Score가 4.3% 향상되지만 GPU 메모리는 7.7GB 더 많이 사용되고, 학습 시간은 443.2분 더 길어짐

(RQ5) Ablation Study of the Training Procedure

각 training procedure가 미치는 영향

• 어느 한 단계라도 생략하면 모든 데이터셋에서 F1-Score가 감소 : 제안한 3 step 학습 절차 효과성 입증
• 특히 1단계 생략할 경우 성능이 가장 나쁨 : 전체 데이터셋 평균 F1-Score가 29.7% 감소
• 1단계와 2단계 생략하고 3단계(전체 모델 파인튜닝)만 수행한 경우 F1-Score가 3.2%만 감소하고 양호한 성능
  • 1단계(Llama가 정답 템플릿을 이해하도록 파인튜닝)가 2단계(BERT 및 projector 학습)보다 먼저 수행되어야 함을 의미
• 1단계 없이 바로 embedder 학습하면, 잘못된 방향으로 학습되어 로그 메세지 의미 제대로 파악하지 못함
• 3단계 생략의 경우, 평균 F1-Score 10.5% 감소
  • Llama와 embedder를 순차적으로 학습하는 것만으로는 이상 패턴을 완전히 포착할 수 없고, 전체 모델을 함께 파인튜닝하는 것이 필수
• 2단계 또는 1&2단계 생략한 경우에도, 평균 F1-Score는 각 2.5%, 3.2% 감소
  • 전체 모델을 파인튜닝하기 전, embedder를 개별적으로 먼저 학습하는 것도 성능 향상에 기여함을 보여줌
  • Llama가 이상을 식별하도록 더 나은 의미 벡터를 생성하는 데 도움이 

(RQ6) Impact of Minority Class Oversampling

• 학습 데이터셋 내의 normal 샘플과 anomalous 샘플은 불균형
• HDFS, BGL, Thunderbird에서는 정상 샘플이 이상 샘플보다 많음
• Liberty는 이상 샘플이 정상 샘플보다 많음

$\beta$값에 대한 네 개의 데이터셋에서의 성능 변화

• 하이퍼파라미터 $\beta$는 less frequent class의 비율 조정하기 위해 오버샘플링 수행
• $\beta=0$인 경우, 샘플은 오버샘플링 되지 않으며, 원본 데이터셋이 그대로 사용

 

• HDFS, BGL, Thunderbird에서 $\beta$가 증가할수록 recall이 항상 증가
• Liberty에서 $\beta$가 증가할수록 recall이 감소
• HDFS, BGL, Thunderbird는 $\beta$가 증가할수록 anomalous 샘플이 오버샘플링 되기 때문에, 모델이 샘플을 anomalous로 판단할 가능성이 높아져 recall이 증가
• 반면 Liberty는 $\beta$가 증가할수록 normal 샘플이 오버샘플링 되어, 샘플을 normal으로 판단할 가능성이 높아져 recall이 감소

 

• F1-Score 추세는 모든 데이터셋에서 대체로 동일
  • $\beta$가 증가함에 따라, F1-Score가 증가했다가 다시 감소
• 그러나 LogLLM은 $\beta$에 민감하지 않은 것처럼 보임
  • $\beta$가 10%에서 80% 사이일 때 F1-Score 변화가 0.07을 넘지 않음
  • 이러한 안정성은 LLM이 내재적으로 보유한 풍부한 semantic knowledge 덕분
  • 소수 클래스가 전체 데이터의 10%에 불과하더라도, 학습된 모델이 이상 패턴을 효과적으로 학습하고 탐지할 수 있음
• 하지만 LogLLM은 극단적으로 불균형한 상황은 효과적으로 처리하지 못함
  • Thunderbird는 이상 샘플이 전체의 1.05%에 불과하여, 학습된 모델이 편향되면서 모든 샘플을 정상으로 분류
  • 그 결과 precision, recall, F1-Score가 모두 0이 됨
• BGL, Thunderbird와 비교했을 때, HDFS, Liberty는 precision, recall, F1-Score가 $\beta$값에 따라 거의 변화 없음
  • 이러한 consistency는 다음과 같은 이유에서 비롯함
  • HDFS, Liberty에서 normal과 anomalous 샘플 간의 패턴 차이가 더 뚜렷하기 때문
  • 정상/이상 비율($\beta$)에 관계없이 성능 안정적으로 유지

 

• $\beta$ 증가함에 따라 학습시간 증가
  • $\beta$값이 클수록 오버샘플링 되는 데이터 수 많아지고, 전체 학습 데이터셋 크기를 증가시킴

 

• 소수 클래스(anomalous 샘플)의 오버샘플링은 필수적
• 하이퍼파라미터 $\beta$ 값은 LogLLM 성능에 큰 영향 없으므로 $\beta$를 아주 신중히 설정할 필요는 없음
• 하지만, $\beta$값이 지나치게 크면 학습 시간이 과도하게 증가하므로 바람직하지 않음
  • 30%~50% 사이 값이 적절한 수치