LogSage Qwen2.5 7B QLoRA v0

LogSage is a QLoRA fine-tuned adapter for structured log analysis and incident triage.

It takes raw logs or incident context and generates a structured diagnosis with:

issue
root_cause
severity
fix
confidence

This is not a general-purpose chatbot. It is a focused applied LLM experiment for DevOps, backend debugging, SRE workflows, and incident-response style reasoning.

Model Details

Field	Value
Model name	`LogSage-Qwen2.5-7B-QLoRA-v0`
Repository	`auro-rirum/LogSage-Qwen2.5-7B-QLoRA-v0`
Model type	PEFT / QLoRA adapter
Base model	`unsloth/Qwen2.5-7B-Instruct-bnb-4bit`
Task	Log analysis and incident triage
Output style	Structured JSON-style diagnosis
Training stack	Unsloth, Transformers, TRL, PEFT
License	Apache-2.0
Status	v0 applied fine-tuning prototype

Why This Model Exists

Production systems fail in patterns:

timeouts
deployment regressions
database saturation
queue backlogs
memory pressure
bad configuration changes
dependency failures
rate-limit cascades

During an incident, the first few minutes are often spent converting noisy logs into a useful hypothesis.

LogSage is designed to produce a first-pass structured diagnosis from logs so a human engineer can inspect, verify, and act faster.

The goal is not to replace an SRE. The goal is to compress the initial investigation loop.

Intended Use

Use this model for:

local log triage experiments
backend incident-analysis demos
SRE assistant prototypes
structured root-cause hypothesis generation
learning QLoRA fine-tuning workflows
building RAG + incident investigation systems

Do not use this model as the only decision-maker for production incidents. It can hallucinate, miss context, or overstate confidence.

Example Input

Service: checkout-api
Environment: production

Logs:
2026-05-08T12:01:33Z ERROR checkout-api request_timeout endpoint=/checkout latency_ms=12000 trace_id=abc-91
2026-05-08T12:01:34Z WARN db-pool pool_exhausted active=100 idle=0 wait_ms=4500
2026-05-08T12:01:35Z ERROR checkout-api failed_to_create_order reason=db_timeout

Recent change:
deploy_hash=9f31ac2 changed database connection pool settings

Example Output

{
  "issue": "Checkout requests are timing out in production.",
  "root_cause": "Database connection pool exhaustion after a recent deploy changed pool settings.",
  "severity": "high",
  "fix": "Rollback the deploy or restore the previous database pool configuration. Then inspect database saturation and checkout-api connection usage.",
  "confidence": "high"
}

Loading the Adapter Locally

This repository contains a PEFT adapter, not a fully merged standalone model.

You need to load the base model and then attach this adapter.

from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
from peft import PeftModel
import torch

base_model = "unsloth/Qwen2.5-7B-Instruct-bnb-4bit"
adapter_model = "auro-rirum/LogSage-Qwen2.5-7B-QLoRA-v0"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
)

tokenizer = AutoTokenizer.from_pretrained(base_model)

model = AutoModelForCausalLM.from_pretrained(
    base_model,
    quantization_config=bnb_config,
    device_map="auto",
)

model = PeftModel.from_pretrained(model, adapter_model)
model.eval()

Inference Example

import torch

prompt = """
You are LogSage, an incident triage assistant.

Given logs and incident context, return only structured JSON with:
issue, root_cause, severity, fix, confidence.

Logs:
2026-05-08T12:01:33Z ERROR checkout-api request_timeout endpoint=/checkout latency_ms=12000
2026-05-08T12:01:34Z WARN db-pool pool_exhausted active=100 idle=0 wait_ms=4500
2026-05-08T12:01:35Z ERROR checkout-api failed_to_create_order reason=db_timeout

Recent change:
deploy_hash=9f31ac2 changed database connection pool settings
"""

messages = [
    {"role": "user", "content": prompt}
]

text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)

inputs = tokenizer(text, return_tensors="pt").to(model.device)

with torch.no_grad():
    outputs = model.generate(
        **inputs,
        max_new_tokens=256,
        temperature=0.2,
        do_sample=False,
    )

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Training Data

The v0 adapter was trained on a supervised instruction dataset for log diagnosis.

Each example follows this shape:

{
  "instruction": "Analyze the logs and return structured diagnosis.",
  "input": "Raw logs and incident context...",
  "output": {
    "issue": "...",
    "root_cause": "...",
    "severity": "...",
    "fix": "...",
    "confidence": "..."
  }
}

Approximate dataset size: 1.1k examples.

The dataset is intentionally small and focused. This model should be treated as a domain fine-tuning prototype, not a broad production incident-intelligence foundation model.

Training Method

This model was trained using QLoRA, a parameter-efficient fine-tuning method.

In this setup:

the base model remains quantized
most original weights remain frozen
small low-rank adapter weights are trained
the resulting adapter is much smaller than a full model checkpoint

This makes the experiment cheaper and easier to reproduce than full fine-tuning.

Evaluation Status

Current status: v0 prototype.

A full benchmark report is not included yet. Recommended evaluation areas:

Evaluation Area	What to Measure
JSON validity	Whether outputs follow the expected schema
Schema adherence	Whether required fields are always present
Severity quality	Whether severity labels are reasonable
Root-cause quality	Whether the model identifies the correct failure pattern
Fix usefulness	Whether the suggested fix is operationally realistic
Hallucination rate	Whether the model invents services, metrics, or deploys
Latency	Local inference time per sample

Planned evaluation table:

Metric	Result
JSON validity	TBD
Schema adherence	TBD
Severity accuracy	TBD
Root-cause match score	TBD
Average latency	TBD

Limitations

LogSage may:

hallucinate root causes when evidence is weak
overfit to common incident patterns
produce confident answers for incomplete logs
miss multi-service causal chains
fail on unseen log formats
require strict prompting to preserve JSON structure
produce fixes that need human verification

This model should be used as an assistant, not an authority.

Safety Notes

Do not paste secrets, credentials, private keys, access tokens, or sensitive production data into the model.

Before using this with real operational logs, add:

secret redaction
PII filtering
source citation
confidence scoring
human review
audit logging

Recommended Prompt Format

You are LogSage, an incident triage assistant.

Given logs and incident context, return only structured JSON with:
issue, root_cause, severity, fix, confidence.

Incident context:
{context}

Logs:
{logs}

Roadmap

Add public evaluation report
Add held-out benchmark set
Add JSON validity metrics
Add latency benchmarks
Add local FastAPI server
Add Gradio demo
Add merged-model option
Add model comparison against base Qwen2.5
Add RAG integration for incident context
Add confidence calibration

Suggested Local Serving API

A simple local server can wrap the adapter behind an API like:

POST /analyze
Content-Type: application/json

{
  "logs": "...",
  "context": "..."
}

Expected response:

{
  "issue": "...",
  "root_cause": "...",
  "severity": "...",
  "fix": "...",
  "confidence": "..."
}

Acknowledgements

Base model:

unsloth/Qwen2.5-7B-Instruct-bnb-4bit

Adapter:

auro-rirum/LogSage-Qwen2.5-7B-QLoRA-v0

Author

Built by Aurorium Nexus as an applied fine-tuning project for log analysis, backend incident triage, and practical LLM engineering.

Downloads last month: 13

Model tree for auro-rirum/LogSage-Qwen2.5-7B-QLoRA-v0

Base model

Qwen/Qwen2.5-7B

Finetuned

Qwen/Qwen2.5-7B-Instruct

Quantized

unsloth/Qwen2.5-7B-Instruct-bnb-4bit

Adapter

(69)

this model