Heretic：用 Optuna 搜尋參數的自動化 abliteration 工具
Fully automatic censorship removal for language models
秒懂
- 它是什麼？
- Heretic 把方向性消融（abliteration）包成一個全自動流程，用 TPE 參數最佳化同時壓低拒答數與 KL 散度。它適合不想理解 transformer 內部、只想跑一條命令拿到去審查模型的人；但純狀態空間模型與部分研究架構不在支援範圍內。
- 適合誰用？
- 如果你要的是一個能用 pip 裝起來、跑一條命令就產出去審查權重的流程，而且模型屬於 dense、多模態或 README 點名的 MoE 架構，Heretic 值得先跑一次預設設定，再用 --evaluate-model 對照原始模型與既有 abliteration 的 KL 散度。若你手上是純狀態空間模型或其他研究架構，README 明說不支援，硬套只會浪費 GPU 時間。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 10 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Heretic 想解決的是參數搜尋，不是消融本身
方向性消融這個手法在 Arditi 等人 2024 年的工作之後已經不是新東西，社群也早就有手動 abliteration 的流程。真正的痛點在於參數：要從哪一層、沿哪個方向、用多大的係數去削掉拒答行為，這些選擇會直接決定模型是被削得剛好，還是連推理能力一起被削掉。手動做法靠人反覆試，試到滿意為止，成本落在人的時間上。
Heretic 把這段搜尋自動化。README 的說法是它「finds high-quality abliteration parameters by co-minimizing the number of refusals and the KL divergence from the original model」，也就是把拒答數與 KL 散度當成兩個要一起壓低的目標。它要的使用者很明確：README 寫「anyone who knows how to run a command-line program can use Heretic to decensor language models」，不需要懂 transformer 內部。這是它跟大多數 abliteration 教學文章的分野，那些文章預設你會看 attention head、會算方向向量。
TPE 最佳化器與 KL 散度的共同最小化
機制上，Heretic 是兩層的組合。底層是先進版的方向性消融實作，README 一併點名了 Lai 2025 的 projected abliteration 與 norm-preserving biprojected abliteration 兩篇部落格，說明它的消融不是最樸素的那一種。上層是參數最佳化器，用 Optuna 提供的 TPE 演算法去搜尋消融參數。
目標函數的設計是這個專案的核心主張。拒答數要壓到接近零不難，難的是壓的過程中不要讓模型在其他地方走鐘，所以第二個目標是與原始模型的 KL 散度。兩者一起最小化，等於在「拒答變少」與「行為漂移變小」之間找一個點。README 的表格用 gemma-3-12b-it 舉例：原始模型在 100 個「有害」提示上拒答 97 次；mlabonne 的 abliterated-v2 拒答 3 次、KL 散度 1.04；huihui-ai 的版本拒答 3 次、KL 散度 0.45；Heretic 產出的版本拒答 3 次、KL 散度 0.16。同樣的拒答抑制水準，漂移小了一個量級。
這張表要照 README 自己的但書讀。它註明數字可以用內建評測功能重現，但「the exact values might be platform- and hardware-dependent」，並且說明表格是在 PyTorch 2.8、RTX 5090 上編出來的。所以 KL 散度不是模型屬性的絕對值，換一張卡、換一個 PyTorch 版本就可能不同。README 也自己補了一句「mathematical metrics and automated benchmarks never tell the whole story, and are no substitute for human evaluation」。這句話放在一個以指標為賣點的工具上，算是誠實。
安裝與最小執行路徑
前置條件是 Python 3.10+ 與 PyTorch 2.2+，README 要求「installed as appropriate for your hardware」。安裝與執行只有兩行：
pip install -U heretic-llm heretic Qwen/Qwen3-4B-Instruct-2507
把模型名稱換成你要處理的對象即可。預設流程是全自動、不需要設定，README 明講「The process is fully automatic and does not require configuration」。
要調參的話有兩條路：命令列跑 heretic --help 看可用選項，或直接改 config.default.toml。README 對後者的說明在提供的內容中被截斷，只寫到「if you prefer to use a c」，完整的檔案結構與鍵位我無法從手上材料確認，實際使用前請以 repo 內的 config.default.toml 為準。
內建評測功能是這裡比較實用的部分。README 給的例子是：
heretic --model google/gemma-3-12b-it --evaluate-model p-e-w/gemma-3-12b-it-heretic
這讓你可以在自己的硬體上重跑同一組對照，而不是照抄表格數字。
依賴管理方面，Heretic 用 uv，repo 內附 uv.lock 鎖住每個套件版本。README 建議已經在用 uv 的人直接 clone 後跑 uv run heretic，理由是依賴版本會與開發者一致，「improving reliability and security」。這是可驗證的具體好處：鎖檔在，重現性就比 pip 自由解析高。
支援範圍是一條硬邊界，不是待辦清單
README 對架構支援的敘述相當具體：支援大多數 dense 模型，包含許多多模態模型、數種不同的 MoE 架構，以及像 Qwen3.5 這類混合模型。反面同樣明確：「Pure state-space models and certain other research architectures are not yet supported out of the box.」
這是本文最該強調的限制。abliteration 的前提是模型裡存在可以被定向削除的方向，這個前提在純狀態空間模型上不成立，所以不是調個參數就能繞過的問題。如果你的模型落在不支援的類別，Heretic 不會給你一個品質差一點的結果，它根本跑不起來。
第二個限制在 PyTorch 版本。最低是 2.2，但 README 警告某些模型與設定需要更新的版本，並給了具體例子：載入 MXFP4 量化的模型如 gpt-oss 會用到 torch.accelerator，那是 PyTorch 2.6 才加入的。也就是說「PyTorch 2.2+」這個最低門檻對某些模型是誤導性的寬鬆，實際能不能跑取決於模型格式。
第三個限制是評測本身。KL 散度低不代表模型在你關心的任務上沒退化，README 自己承認數學指標不能取代人工評估。把 KL 0.16 當成「幾乎無損」的證明是過度解讀。
與手動 abliteration 的實際差異
最直接的替代方案就是手動 abliteration，也就是社群長年做法：自己決定消融層、方向與強度，反覆試到滿意。差別不在輸出型態，兩者都產出一組修改後的權重；差別在搜尋由誰做。手動流程把搜尋成本放在人的時間與領域知識上，好處是你可以針對特定行為微調，例如只針對某一類拒答、保留另一類。Heretic 把搜尋交給 TPE，代價是你交出這層控制權，換到的是不需要理解內部結構、以及可重現的評測命令。
README 的表格正好把這個差異量化：Heretic 版本與兩個人工 abliteration 在拒答數上打平（都是 3/100），差別出現在 KL 散度。這說明自動搜尋在這組對照裡找到的參數，比手動版本更靠近原始模型的行為。反過來說，如果某個手動版本針對你的用途做了刻意的取捨，Heretic 的通用目標函數未必會重現那個取捨。
另一個方向的替代是直接微調或做 RLHF 類的後訓練。README 開頭就把這條路排除掉，說 Heretic 是「without expensive post-training」。這是成本結構的差異，不是品質的絕對高下；後訓練能改變的東西比方向性消融多，但代價也高得多。
授權與維護面的現實
授權是 AGPL-3.0。這對個人本地使用沒有實質影響，但如果你打算把 Heretic 包進一個對外提供的服務，AGPL 的網路條款會要求你向使用者提供對應原始碼。這不是法律建議，具體情況請找律師確認，但把它當成「跟 MIT 一樣隨便用」是錯的。另外要注意的是，授權涵蓋的是工具本身，你用 Heretic 產出的模型權重還受原始模型授權約束，那是另一層問題。
維護成本方面，材料顯示的節奏是穩定發布：v1.2.0 在 2026 年 2 月、v1.3.0 在 5 月、v1.4.0 在 6 月，最後一次推送是 2026 年 9 月，專案未封存。這個節奏意味著你每隔幾個月會遇到一次升級，而升級的風險點集中在依賴：PyTorch 版本、Optuna、以及模型載入路徑。repo 附 uv.lock 正是針對這件事，用 uv run heretic 可以把你鎖在開發者驗證過的版本組合上，代價是你會落後於最新的 PyTorch。
真正會累積成本的地方是模型支援。新架構不斷出現，而 README 已經列出兩類不支援的模型。每次你想處理一個新模型，都要先確認它是否落在支援範圍內，這件事沒有自動化的答案。
誰該跑預設設定，誰該先停下來
如果你的目標模型是 dense、多模態或 README 點名的 MoE 架構，而且你只想拿到一組可用的去審查權重，Heretic 的預設流程值得直接跑一次。兩行命令、不用設定、內建評測可以自己驗證，這條路徑的成本很低。
該停下來的情況有三種。模型是純狀態空間或其他不支援的研究架構，這條路根本走不通。你需要對消融行為做精細的逐層控制，那 TPE 幫你做的決定反而是阻礙。你要把工具嵌進對外服務，AGPL-3.0 的義務需要先弄清楚。
要驗證的第一件事不是 KL 散度，而是你的 PyTorch 版本是否滿足目標模型的需求。README 的 MXFP4 例子說明最低版本宣告可能不夠用，先確認 torch.accelerator 這類 API 是否存在，比跑完一輪最佳化才發現載入失敗要省事。第二件事是在你自己的硬體上重跑 --evaluate-model 的對照，因為 README 已經聲明數字會隨平台與硬體變動，別人的 0.16 不保證是你的 0.16。
編輯結論
如果你要的是一個能用 pip 裝起來、跑一條命令就產出去審查權重的流程，而且模型屬於 dense、多模態或 README 點名的 MoE 架構，Heretic 值得先跑一次預設設定，再用 --evaluate-model 對照原始模型與既有 abliteration 的 KL 散度。若你手上是純狀態空間模型或其他研究架構，README 明說不支援，硬套只會浪費 GPU 時間。導入前先確認三件事：你的 PyTorch 版本是否滿足模型需求（例如 MXFP4 量化模型需要 PyTorch 2.6 的 torch.accelerator）、AGPL-3.0 對你散布方式的影響、以及你能否接受評測數字會隨平台與硬體變動。
社群筆記