Heretic: 拒否応答を自動で減らすabliterationツールの実力と境界

Hereticが埋めるのは「人手によるabliteration」の再現コスト

モデルの拒否応答を消す手法としてabliterationが知られるようになったが、実際に良い結果を出すには層の選択や除去方向の調整を人手で試す必要があり、transformerの内部構造を理解していることが前提だった。Hereticはこの調整作業をOptunaのTPEベース最適化に置き換える。READMEによれば、拒否応答の数と元モデルからのKLダイバージェンスを同時に最小化するパラメータを探索し、その結果を「完全に自動」で得られるとしている。対象読者は、モデルの中身を理解せずともコマンドラインを扱える人だとREADME自身が明言している。

方向性除去とKLダイバージェンス最小化の同時探索

Hereticの核は2つの要素の組み合わせだ。1つは方向性除去、いわゆるabliterationで、Arditi et al. 2024やLai 2025の手法を発展させた実装を使う。もう1つはOptunaによるTPEベースのパラメータ最適化である。重要なのは最適化の目的関数が単一ではない点で、拒否応答の削減とKLダイバージェンスの抑制を同時に評価する。拒否を消すだけなら除去を強くすればよいが、それでは元モデルの能力が壊れる。Hereticはこのトレードオフを探索問題として扱い、両方の指標が良い点を自動で探す。READMEに掲載された比較表では、gemma-3-12b-itに対してHereticが生成したモデルは拒否3/100、KLダイバージェンス0.16で、人手によるabliterated-v2のKL 1.04やhuihui-ai版の0.45より小さい値を示している。ただしこの数値はPyTorch 2.8とRTX 5090上で計測されたもので、プラットフォームやハードウェアに依存するとREADME自身が注記している。

導入はpip install heretic-llmと1行のモデル指定から

READMEが示す手順は短い。Python 3.10以上とPyTorch 2.2以上を用意し、pip install -U heretic-llmを実行したあと、heretic Qwen/Qwen3-4B-Instruct-2507のようにモデルIDを渡すだけでよい。設定は不要とされているが、heretic --helpでコマンドラインオプションを確認でき、リポジトリにはconfig.default.tomlが用意されているのでTOMLで設定を書きたい場合はそちらを使う。PyTorchのバージョンには注意点があり、2.2が最低要件でありながら、MXFP4量子化モデルであるgpt-ossの読み込みにはtorch.acceleratorが必要で、これはPyTorch 2.6で追加された。依存管理にuvを使っている場合、リポジトリ同梱のuv.lockでバージョンが固定されているためuv run hereticで開発者と同じ依存関係を再現できる。

対応アーキテクチャの境界と評価の限界

READMEは対応範囲を正直に書いている。ほとんどのdenseモデル、多くのマルチモーダルモデル、いくつかのMoEアーキテクチャ、Qwen3.5のようなハイブリッドモデルに対応する一方、純粋な状態空間モデルと一部の研究用アーキテクチャは「まだサポートされていない」と明記されている。つまりMamba系を対象にしているならHereticは選択肢にならない。もう1つの制約は評価の性質だ。拒否率とKLダイバージェンスは数学的な指標であり、README自身が「自動ベンチマークは全体像を語らない」と認めている。KLが小さいことは元モデルの振る舞いが保たれていることの目安にはなるが、生成の質や一貫性を保証するものではない。導入時はheretic --model <対象> --evaluate-model <生成モデル>で自分の環境の数値を確認するのが妥当で、READMEの表の値をそのまま期待値として扱うべきではない。

手動abliterationや他ツールとの違い

比較対象として分かりやすいのはmlabonne/gemma-3-12b-it-abliterated-v2やhuihui-ai/gemma-3-12b-it-abliteratedのような人手または既存ツールによるabliterationだ。これらは拒否率を3/100まで下げている点ではHeretic版と同じだが、KLダイバージェンスはそれぞれ1.04と0.45で、Heretic版の0.16より大きい。違いはアプローチにある。手動abliterationは人間が層や方向を選んで調整するのに対し、Hereticは拒否削減とKL抑制の同時最小化を探索問題として自動で解く。ただしこれはREADMEが示す数値であり、独立した第三者によるMMLUやGSM8Kでの比較もREADMEは参照しているが、それらはReddit上の投稿へのリンクとして示されているだけで、内容の詳細はこの記事の材料からは確認できない。

AGPL-3.0が意味する配布条件

HereticはAGPL-3.0で公開されている。AGPLはGPL系の中でもネットワーク越しの利用に対してソース提供を求める条項を含む点が特徴で、Hereticを組み込んだサービスを外部に提供する場合、ライセンス条件の確認が通常のGPLより重くなる可能性がある。ここでは法的助言はできないが、生成されたモデルの重みそのもののライセンスは元モデル側の条件に従う点も見落とされやすい。Hereticで作ったモデルを配布する場合、ツールのライセンスと元モデルのライセンスを別々に確認する必要がある。AGPLの伝播を避けたい商用環境では、ツールを社内のモデル改変パイプラインに閉じて使うのか、生成物を外部に出すのかで判断が変わる。

メンテナンスとアップグレードの実際

リポジトリはアーカイブされておらず、最終pushは2026年9月5日、直近のリリースはv1.4.0（2026年6月14日）で、v1.3.0が2026年5月5日、v1.2.0が2026年2月14日と、およそ2〜3か月間隔で更新が続いている。依存関係はuv.lockで固定されているため、uv run hereticを使えば開発時と同じバージョン構成を再現でき、アップグレード時の差分も追いやすい。一方でPyTorchの要件がモデル依存で上がる点は運用コストになる。MXFP4量子化モデルを扱うならPyTorch 2.6以上が必要で、環境のCUDAやドライバとの整合を都度確認することになる。READMEはPyTorch 2.2を最低要件としつつ、モデルや設定によってはより新しい機能が必要だと注意を促している。

どんなときにHereticを選び、どんなときに避けるか

Hereticが向くのは、手元のdenseモデルやMoEモデルの拒否応答を減らしたいが、abliterationのパラメータ調整に時間をかけたくない場合だ。READMEが示すように、コマンド1つで探索が走り、KLダイバージェンスを指標に品質を確認できる。逆に避けるべきなのは、対象が純粋な状態空間モデルや未対応の研究アーキテクチャの場合、そしてAGPL-3.0の条件が自社の配布形態と合わない場合である。採用を決める前にやるべきことは明確で、heretic --helpで利用可能なオプションを確認し、heretic --model <対象モデル> --evaluate-model <生成モデル>を自分のハードウェアで実行して拒否率とKLダイバージェンスを測ることだ。READMEの表の数値はRTX 5090とPyTorch 2.8で得られたものであり、自分の環境で同じ値が出るとは限らない。

編集部の結論

コマンドラインからモデルの拒否応答を減らしたいがtransformer内部の知識がない個人や小規模チームには向く。逆に純粋な状態空間モデルや研究用アーキテクチャ、AGPL-3.0の伝播を避けたい商用プロダクトには向かない。導入前にheretic --helpでパラメータ一覧を確認し、heretic --model <対象モデル> --evaluate-model <生成モデル>でKLダイバージェンスと拒否率を自分のハードウェア上で測ってから採用を決めるのが現実的だ。

公式情報源

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