Heretic: Abliteration ohne Handarbeit, aber nicht ohne Rechenzeit

Welches Problem Heretic löst und für wen es gedacht ist

Sprachmodelle werden nach dem Training mit Sicherheitsalignment versehen, das bestimmte Anfragen mit Ablehnungen beantwortet. Wer dieses Verhalten entfernen will, musste bisher entweder die Gewichte von Hand manipulieren oder ein teures Post-Training durchführen. Heretic setzt an der ersten Stelle an und automatisiert den Prozess vollständig. Laut README kombiniert es eine Implementierung der directional ablation, auch Abliteration genannt, mit einem TPE-basierten Parameteroptimierer auf Basis von Optuna. Die Zielgruppe ist ausdrücklich nicht die Forschung: Die README behauptet, dass jeder, der ein Kommandozeilenprogramm bedienen kann, mit Heretic Modelle entcensieren kann. Das ist eine starke Aussage, und sie hat einen realen Kern, weil der Optimierer die Parameter sucht, die man sonst manuell einstellen müsste. Wer allerdings erwartet, dass damit auch die Modellkompatibilität automatisch geklärt wird, irrt. Die README nennt Einschränkungen bei reinen State-Space-Modellen und bestimmten Research-Architekturen, die nicht out of the box unterstützt werden.

Directional ablation plus Optuna: der eigentliche Mechanismus

Abliteration funktioniert nach dem in der README zitierten Verfahren von Arditi et al. 2024 sowie den Arbeiten von Lai 2025 zur projizierten und normerhaltenden biprojizierten Abliteration. Dabei werden Richtungen im Aktivierungsraum identifiziert, die für das Ablehnungsverhalten verantwortlich sind, und aus den Gewichten entfernt. Heretic geht darüber hinaus, indem es die Parameter dieser Projektion nicht fest vorgibt, sondern von einem TPE-Optimierer suchen lässt. Das Optimierungsziel ist zweigeteilt: die Anzahl der Ablehnungen bei als schädlich markierten Prompts soll sinken, während die KL-Divergenz zu den Ausgaben des Originalmodells bei harmlosen Prompts möglichst klein bleiben soll. Diese Co-Minimierung ist der Kern des Projekts. Die README zeigt eine Tabelle mit gemma-3-12b-it: Das Original verweigert 97 von 100 schädlichen Prompts, die manuell erstellten Abliterations von mlabonne und huihui-ai kommen auf 3 von 100 bei KL-Divergenzen von 1,04 beziehungsweise 0,45, während die Heretic-Version ebenfalls 3 von 100 erreicht, aber bei einer KL-Divergenz von 0,16. Diese Zahlen stammen aus der README und wurden laut Fußnote mit PyTorch 2.8 auf einer RTX 5090 erstellt. Die README weist selbst darauf hin, dass die Werte plattform- und hardwareabhängig sein können.

Installation und der erste Lauf

Die Voraussetzungen sind knapp: Python 3.10 oder neuer und PyTorch ab Version 2.2, passend zur eigenen Hardware. Die Installation erfolgt über pip, danach folgt der Aufruf mit einem Modellnamen. Die README gibt genau dieses Beispiel: pip install -U heretic-llm, gefolgt von heretic Qwen/Qwen3-4B-Instruct-2507. Der Modellname wird durch das jeweils gewünschte Modell ersetzt. Für die Auswertung nennt die README den Schalter heretic --model google/gemma-3-12b-it --evaluate-model p-e-w/gemma-3-12b-it-heretic, mit dem sich die veröffentlichten Zahlen auf eigener Hardware nachvollziehen lassen. Wer uv verwendet, kann laut README das Repository klonen und mit uv run heretic starten, wodurch die im uv.lock festgehaltenen Paketversionen verwendet werden. Das ist ein konkreter Vorteil für Reproduzierbarkeit, denn die README betont, dass einige Modelle und Konfigurationen neuere PyTorch-Funktionen benötigen. MXFP4-quantisiertes gpt-oss etwa verwendet torch.accelerator, das erst in PyTorch 2.6 eingeführt wurde. Wer mit PyTorch 2.2 startet, kann also bei bestimmten Modellen an eine harte Grenze stoßen.

Automatik als Standard, Konfiguration als Ausnahme

Der Prozess läuft laut README vollständig automatisch und ohne Konfiguration. Wer dennoch eingreifen will, findet die Parameter über heretic --help oder in der Datei config.default.toml. Das ist ein bewusster Designentscheid: Die Optimierung übernimmt die Suche, und die Konfigurationsdatei dient nur dem Feintuning oder dem Festlegen von Randbedingungen. Der Preis dafür ist, dass die Optimierung Rechenzeit kostet. Jeder Kandidat, den der TPE-Optimierer ausprobiert, erfordert einen Durchlauf durch das Modell, und die KL-Divergenz muss für jeden Kandidaten berechnet werden. Die README nennt keine Laufzeiten, und ohne eigene Messung lässt sich nicht sagen, wie viele Iterationen der Optimierer standardmäßig durchführt. Klar ist nur: Wer ein 12B-Modell auf einer kleineren GPU betreibt, wird die Optimierung nicht in wenigen Minuten abschließen. Die README gibt dazu keine Zahlen, und ich habe es nicht ausgeführt.

Wo Heretic an Grenzen stößt

Die README nennt die Einschränkung selbst: Reine State-Space-Modelle und bestimmte andere Research-Architekturen werden nicht out of the box unterstützt. Das ist keine Kleinigkeit, denn gerade bei neueren Architekturen, die von den üblichen Transformer-Blöcken abweichen, fehlt damit die Grundlage für die Richtungsanalyse. Auch bei MoE-Modellen ist die Unterstützung laut README vorhanden, aber auf bestimmte Architekturen beschränkt. Ein zweiter Punkt betrifft die Bewertung: Die README räumt ein, dass mathematische Metriken und automatisierte Benchmarks nie die ganze Geschichte erzählen und keine menschliche Evaluation ersetzen. Die KL-Divergenz misst, wie stark sich die Ausgabeverteilung ändert, aber sie sagt nichts darüber, ob das Modell nach der Abliteration bei harmlosen Aufgaben noch sinnvolle Antworten liefert. Die README verweist zwar auf unabhängige Benchmarks mit MMLU und GSM8K, doch diese stammen aus Reddit-Beiträgen und nicht aus einer kontrollierten Studie. Wer Heretic einsetzt, sollte die Ausgabequalität selbst prüfen, bevor er das Modell produktiv nutzt.

Der Unterschied zu manueller Abliteration

Die naheliegende Alternative ist die manuelle Abliteration, wie sie mlabonne und huihui-ai veröffentlichen. Der Unterschied liegt nicht im Verfahren, sondern in der Parameterwahl. Bei der manuellen Variante entscheidet der Anwender, welche Schichten und Richtungen entfernt werden, und iteriert so lange, bis das Ergebnis akzeptabel ist. Das erfordert Erfahrung mit Transformer-Interna und viel Geduld. Heretic ersetzt diese Entscheidungen durch eine Optimierungsschleife, die auf zwei Metriken gleichzeitig arbeitet. Die README-Tabelle zeigt, dass die automatisch gefundenen Parameter bei gleicher Ablehnungsquote eine deutlich niedrigere KL-Divergenz erreichen können. Das ist ein messbarer Vorteil, aber er gilt nur für das getestete Modell und die getestete Hardware. Ein weiterer Unterschied ist die Reproduzierbarkeit: Wer uv verwendet, bekommt durch uv.lock exakt die Paketversionen der Entwickler, während manuelle Abliterations oft mit selbst zusammengestellten Skripten arbeiten. Das ist ein Vorteil für die Nachvollziehbarkeit, aber es bindet den Prozess an das Ökosystem von Heretic.

Wartung, Lizenz und langfristige Kosten

Heretic steht unter AGPL-3.0. Das bedeutet: Wer das Programm verändert und weitergibt, muss den Quellcode offenlegen. Wer es als Netzwerkdienst betreibt, muss Nutzern ebenfalls den Quellcode zugänglich machen. Für die meisten privaten Anwender, die Heretic lokal auf ihrem Rechner ausführen, ändert sich dadurch nichts. Für Unternehmen, die das Tool in einen Dienst integrieren, kann die Lizenz ein Hindernis sein. Die README gibt dazu keine Hinweise, und ich gebe keine Rechtsberatung. Die Wartungssituation ist schwer zu beurteilen. Das Repository wurde zuletzt am 5. September 2026 aktualisiert, die letzte Version v1.4.0 stammt vom 14. Juni 2026. Innerhalb von etwa vier Monaten gab es drei Releases, was auf eine aktive Entwicklung hindeutet. Die README erwähnt einen Discord- und Matrix-Kanal sowie einen Codeberg-Mirror. Wer das Tool produktiv einsetzt, sollte die Release-Notes verfolgen, weil neue Modellarchitekturen möglicherweise erst in späteren Versionen unterstützt werden. Die Upgrade-Kosten hängen davon ab, ob die eigene Modellfamilie bereits abgedeckt ist. Für Modelle, die in der README nicht genannt werden, lässt sich nicht vorhersagen, ob sie in einer künftigen Version unterstützt werden.

Wer Heretic einsetzen sollte und wer nicht

Heretic ist ein Werkzeug für Anwender, die ein dichtes Transformer-Modell auf eigener Hardware entcensieren wollen und keine Zeit in die manuelle Parameterwahl investieren möchten. Die README nennt über 5000 Modelle auf Hugging Face, die mit Heretic erstellt wurden, was auf eine gewisse Verbreitung hindeutet, aber keine Aussage über die Qualität dieser Modelle erlaubt. Wer ein Modell mit einer Architektur einsetzt, die die README nicht ausdrücklich nennt, sollte vor dem ersten Lauf prüfen, ob die Familie unterstützt wird. Ein Blick in die README oder ein Testlauf mit einem kleinen Modell wie Qwen/Qwen3-4B-Instruct-2507 klärt das schneller als jede Vermutung. Wer eine rechtliche Freigabe für den Einsatz entcensierter Modelle benötigt, sollte die AGPL-3.0-Bedingungen prüfen, bevor er Heretic in einen Dienst integriert. Und wer erwartet, dass die automatische Optimierung die Ausgabequalität garantiert, sollte die README ernst nehmen: Sie sagt selbst, dass Metriken keine menschliche Evaluation ersetzen.

Redaktionelles Fazit

Heretic eignet sich für Anwender, die ein dichtes Transformer-Modell ohne manuelle Parameterwahl entcensieren wollen und über genügend VRAM verfügen. Wer ein reines State-Space-Modell, eine exotische Research-Architektur oder ein MoE-Modell außerhalb der unterstützten Familien einsetzt, sollte vorher die Modellkompatibilität prüfen. Ebenso ungeeignet ist es für Teams, die eine rechtliche Freigabe für den Einsatz entcensierter Modelle benötigen, denn die AGPL-3.0 verlangt bei Weitergabe oder Netzwerkbetrieb die Offenlegung des Quellcodes. Vor dem ersten Lauf sollte man mit heretic --model <Modell> --evaluate-model <Referenz> die KL-Divergenz auf dem eigenen Hardware-Setup verifizieren, weil die README ausdrücklich darauf hinweist, dass die veröffentlichten Werte plattform- und hardwareabhängig sind.

Offizielle Quellen

1. License: AGPL-3.0
2. p-e-w/heretic on GitHub
3. Project website
4. README
5. Releases