QLoRA-SFT on MegaPanchamZ/Qwen3.8-9B-abliterated-25 (Heretic abliterated, 25/100 refusals) für anti-halluzinierende XRPL-/Cyber-Audit-Antworten. Trainiert auf RTX 5090 Laptop (24 GB GDDR7) mit 2 Epochen, LoRA r=16, eval_strategy=epoch.
Empfohlene Quant
Datei
Größe (HF)
Rolle
model.Q6_K.gguf
7,36 GB
HF-Default — beste Balance für 24-GB-GPUs
model.Q8_0.gguf
9,53 GB
Qualitäts-Referenz (~99 % von F16), für dich selbst
F16 (17 GB BF16-Merged) ist nur lokal vorhanden — nicht in diesem Repo. Für schwächere Rechner ist ein Q5_K_M gguf kein Ersatz für Q6_K, weil strukturierte VERDICT-Ausgabe merklich leidet.
Chat-Template ist Qwen3.8 / ChatML (<|im_start|>...<|im_end|>) und bereits in der GGUF eingebettet.
Trainings-VERDICT-Labels (wichtig)
Das Modell wurde auf diesem Vokabular feinjustiert — bitte prompten mit diesen Labels, sonst bekommt ihr Drifts:
Label
Bedeutung
VALID_BUG
reproduzierbarer Bug mit Live-Transkript
FALSE_POSITIVE
gemeldet, aber kein echter Bug (z. B. Setup-Mismatch)
HYGIENE
Code-Smell, kein direkter Exploit
CORRECTNESS-ISSUE
Logik-/Spec-Drift
UNPROVEN
Behauptung ohne Live-PoC-Transkript
Standard-Labels wie EXPLOITABLE / UNPROVEN / SAFE / NEEDS_REVIEW aus dem Korpus sind eine Teilmenge — bei längeren Aufgaben verwende bevorzugt die obigen fünf.
Wo File:line-Quellen ehrlich stehen
file.ext:line-Zitate stammen aus zwei Klassen von Quellen:
Live-Transcripts (GDB/rr-Sessions, Valgrind-Logs): ~60 % der 184 Trainings-Rows, mit echter path/file.cpp:123-Form.
FP-Katalog / Skill-Evidence (xrpl-drill): ~25 %, hier sind die Quellen bewusst unnamed (SOURCE: unnamed in catalog mit CATALOG_QUOTE:).
Die übrigen Rows nutzen entweder CVE-IDs oder XRPL-Spec-Passagen ohne File:line. Nicht alle 184 Rows haben eine File:line. Diese Behauptung steht auch im smoke-test hart auf 100 % nur für die zitierbaren Live-Transcripts.
Smoke-Test-Resultate
Drei Prompts wurden gegen die Q6_K-Variante via ollama getestet:
Prompt
Ergebnis
Amendment-Skip
VERDICT: EXPLOITABLE + klares „Do NOT green-light this change"
UNPROVEN ohne Live-Proof
VERDICT: UNPROVEN + Rationale + Empfehlung für Live-PoC
xrpl-drill-Fallback
xrpl-drill --target=negative-amount-invariant --ledger=mainnet als Skill-Invoke
3/3 PASS. Limitation: Inferenz wurde via ollama getestet; ein End-to-End-Test im LM-Studio-Frontend wurde bisher nicht durchgeführt. Wenn du das gegen die Q8_0-Variante auch willst, kann ich das nachholen.
Abliterated ≠ uncensored
Die Base hat 25/100 Refusals vor Training. Heretic-Abliterating reduziert das deutlich, aber das Modell ist nicht "0 % Refusals". Für typische Cyber-/XRPL-Audit-Tasks antwortet es offen; für wirklich sensible Inhalte (Person-bezogene Daten, sehr junge Vulns) kann es weiterhin ablehnen.
LoRA-Reproduktion
Adapter liegt lokal unter adapter/lora/ (nicht im Repo, da er nur 112 MB sind und für Reproduktion via HF nicht nötig sind — das Modell ist gemerged). Wer den LoRA auf MegaPanchamZ/Qwen3.8-9B-abliterated-25 neu mergen will:
python merge_lora.py # lokal unter training_data/
Imatrix
imatrix.dat (5 MB) liegt im Repo-Root und stammelt aus corpus/imatrix_holdout.jsonl, nicht aus dem Trainingskorpus. Wurde mit llama-imatrix auf der RTX 5090 mit --chunks 196 -c 1024 -b 512 berechnet und für beide Quantisierungen (Q8_0, Q6_K) verwendet.
Bekannte Einschränkungen
GGUF-Inferenz im LM-Studio-Frontend wurde nicht End-to-End verifiziert; smoke-test lief nur über ollama-API.
Quant-Subjektivität: für sehr Code-lastige Prompts (große Codeblöcke) kann Q8_0 sichtbar stabiler sein als Q6_K.
Frisches Eval-Set wäre besser; die 33 Eval-Rows sind Teil des Trainings-Mix-Filters und teils überlappend mit der Train-Distribution.
