---
license: apache-2.0
library_name: peft
base_model: unsloth/Qwen2.5-7B-Instruct-bnb-4bit
tags:
  - qlora
  - lora
  - peft
  - qwen2.5
  - log-analysis
  - incident-triage
  - root-cause-analysis
  - devops
  - sre
  - structured-output
  - local-inference
  - learning-grade
pipeline_tag: text-generation
---

# 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

```text
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

```json
{
  "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.

```python
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

```python
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:

```json
{
  "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

```text
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:

```http
POST /analyze
Content-Type: application/json

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

Expected response:

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

---

## Acknowledgements

Base model:

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

Adapter:

```text
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.