Heretic : supprimer le refus sans réentraîner le modèle

Le refus comme comportement appris, pas comme filtre

La plupart des modèles instruct refusent certaines requêtes parce que l'entraînement par renforcement leur a appris à le faire. Le refus n'est donc pas un module externe qu'on pourrait débrancher. Heretic part de ce constat et attaque directement les directions dans l'espace des activations qui portent ce comportement. Le projet cite les travaux d'Arditi et al. (2024) ainsi que les billets de Lai sur l'abliteration projetée et biprojetée avec préservation de norme. Le public visé est précis : quelqu'un qui sait lancer une commande et qui veut un modèle local qui répond, sans avoir à comprendre l'anatomie d'un transformer. Le README affirme qu'aucune connaissance des internes n'est nécessaire. C'est le cœur de la promesse, et c'est aussi ce qui la rend vérifiable : soit la commande produit un modèle utilisable, soit elle ne le fait pas.

Ablation directionnelle et recherche de paramètres par TPE

Le mécanisme combine deux étages. Le premier est une implémentation d'abliteration directionnelle : on identifie des directions dans les activations qui correspondent au comportement de refus, puis on les retire ou on les projette hors des poids. Le second étage est un optimiseur de paramètres fondé sur TPE et propulsé par Optuna. C'est lui qui rend l'outil automatique. Heretic ne se contente pas d'appliquer une ablation avec des réglages fixes : il cherche les paramètres qui co-minimisent deux quantités, le nombre de refus sur des requêtes jugées nuisibles et la divergence KL par rapport au modèle d'origine sur des requêtes jugées inoffensives. Le compromis est explicite. Abliterer trop fort casse le modèle, abliterer trop peu laisse les refus en place. La recherche TPE navigue entre les deux. Le README indique que l'outil prend en charge la plupart des modèles denses, de nombreux modèles multimodaux, plusieurs architectures MoE et certains modèles hybrides comme Qwen3.5. Les modèles en espace d'état pur et certaines architectures de recherche ne sont pas pris en charge.

Ce que le tableau du README montre, et ce qu'il ne montre pas

Le README publie un tableau comparatif sur google/gemma-3-12b-it. Le modèle d'origine refuse 97 requêtes sur 100. Deux abliterations humaines, mlabonne/gemma-3-12b-it-abliterated-v2 et huihui-ai/gemma-3-12b-it-abliterated, descendent à 3 sur 100, avec une divergence KL de 1,04 et 0,45 respectivement. La version produite par Heretic atteint aussi 3 sur 100, avec une divergence KL de 0,16. Le README précise que ces chiffres ont été compilés avec PyTorch 2.8 sur une RTX 5090 et qu'ils peuvent varier selon la plateforme et le matériel. Il rappelle aussi que les métriques mathématiques ne remplacent pas une évaluation humaine. C'est une précaution honnête, et elle compte : un score KL plus bas indique moins d'écart par rapport au modèle d'origine, pas que le modèle obtenu est meilleur sur toutes les tâches. Le tableau porte sur un seul modèle. Rien dans le matériel fourni ne permet de dire si l'écart de KL se reproduit sur d'autres architectures.

Installation et configuration

Il faut un environnement Python 3.10 ou plus récent avec PyTorch 2.2 minimum. L'installation se fait par `pip install -U heretic-llm`, puis on lance `heretic Qwen/Qwen3-4-Instruct-2507` en remplaçant l'identifiant par le modèle voulu. Le README signale que PyTorch 2.2 est un minimum et que certains modèles exigent davantage : charger des modèles quantifiés en MXFP4 comme gpt-oss fait appel à `torch.accelerator`, ajouté en PyTorch 2.6. Le projet utilise uv pour ses dépendances et fournit un fichier `uv.lock` qui épingle chaque version. Le README recommande de cloner le dépôt et de lancer `uv run heretic` pour retrouver l'environnement des développeurs. Pour la configuration, deux chemins : `heretic --help` liste les options de ligne de commande, et `config.default.toml` sert de référence si l'on préfère un fichier. Le README insiste sur un point : le processus est entièrement automatique et ne demande aucune configuration. Les paramètres existent pour qui veut plus de contrôle, pas parce qu'il faudrait les régler.

Évaluation intégrée et reproductibilité partielle

Heretic embarque une fonction d'évaluation. Le README donne l'exemple `heretic --model google/gemma-3-12b-it --evaluate-model p-e-w/gemma-3-12b-it-heretic`, qui reproduit les mesures du tableau. C'est utile pour comparer deux modèles sur les mêmes requêtes, mais cela reste une évaluation sur deux axes : le taux de refus et la divergence KL. Un modèle qui ne refuse plus et qui reste proche de l'original sur des requêtes inoffensives peut malgré tout avoir perdu des capacités que ces deux métriques ne capturent pas. Le README le dit lui-même. La charge de la preuve repose donc sur l'utilisateur, qui doit tester le modèle obtenu sur ses propres cas d'usage. Le projet ne fournit pas de jeu de tests de capacités dans le matériel disponible ici.

Architectures non prises en charge et coût matériel

La limitation la plus nette est architecturale. Les modèles en espace d'état pur ne sont pas pris en charge, et le README mentionne aussi certaines architectures de recherche. Si votre modèle n'est ni dense, ni MoE, ni hybride, Heretic n'est pas le bon outil. Le coût matériel est l'autre contrainte. La recherche de paramètres par TPE implique de charger le modèle et d'évaluer plusieurs configurations, ce qui suppose un GPU. Le tableau de référence a été produit sur une RTX 5090, et le README note que les valeurs peuvent dépendre du matériel. Pour un modèle de 12 milliards de paramètres, cela reste à la portée d'une machine de bureau récente. Pour un modèle bien plus gros, la question du temps de recherche et de la mémoire disponible se pose, même si le matériel fourni ne donne pas de chiffres à ce sujet.

Face aux abliterations manuelles publiées sur Hugging Face

L'alternative la plus directe n'est pas un autre outil mais un modèle déjà abliteré, comme mlabonne/gemma-3-12b-it-abliterated-v2 ou huihui-ai/gemma-3-12b-it-abliterated. La différence tient au mode de production. Ces modèles résultent d'un travail manuel : quelqu'un a choisi les couches, les directions et l'intensité, puis a publié le résultat. Heretic remplace ces choix par une recherche automatique sur un objectif mesurable. Le tableau du README suggère que cette recherche trouve un meilleur compromis sur le cas testé, avec une divergence KL de 0,16 contre 1,04 et 0,45. L'avantage de l'approche manuelle est ailleurs : elle produit un modèle unique, reproductible par téléchargement, sans GPU ni dépendance à Optuna. Si un modèle abliteré existe déjà pour votre cas et vous convient, le télécharger coûte moins cher que de faire tourner Heretic. L'intérêt de Heretic apparaît quand aucun modèle abliteré n'existe pour l'architecture qui vous intéresse, ou quand vous voulez contrôler l'objectif plutôt que faire confiance à un tiers.

Licence AGPL-3.0 et maintenance

Heretic est publié sous AGPL-3.0. Cette licence impose des obligations lorsque le logiciel est mis à disposition via un service en ligne : le code source correspondant doit être proposé aux utilisateurs du service. Pour un usage local, la question ne se pose pas de la même façon. Elle devient concrète si vous intégrez Heretic dans une plateforme accessible à des tiers. Le projet n'est pas archivé et la dernière poussée sur la branche master date du 5 septembre 2026. Les versions récentes s'échelonnent sur 2026 : v1.2.0 en février, v1.3.0 en mai, v1.4.0 en juin. Le rythme suggère un projet actif, mais le matériel fourni ne détaille pas la politique de compatibilité entre versions. Le fichier `uv.lock` épingle les dépendances, ce qui aide à reproduire un environnement donné, au prix d'une mise à jour manuelle lorsque PyTorch ou Optuna évoluent. Le README signale lui-même que la version minimale de PyTorch ne suffit pas pour tous les modèles, ce qui implique de suivre les versions si vous travaillez sur des architectures récentes. Ce texte ne constitue pas un avis juridique.

Conclusion éditoriale

Heretic convient à qui veut un modèle local sans refus et accepte de laisser l'outil choisir les paramètres à sa place, à condition de disposer d'un GPU et d'un environnement PyTorch récent. Il ne convient pas aux équipes qui doivent documenter chaque couche modifiée, ni à celles qui travaillent sur des architectures en espace d'état pur, non prises en charge. Avant d'adopter, vérifiez que votre modèle figure parmi les architectures denses ou MoE supportées, puis lancez `heretic --help` pour confirmer que les options de configuration correspondent à votre cas.

Sources officielles

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