본문 바로가기
AI 생성 글 정리/tech_github

Heretic — Optuna가 자동으로 찾는 자동 abliteration 파이프라인

by Honbul 2026. 4. 14.

 

캡션: Heretic의 저장소 대표 이미지. UI가 있는 제품이라기보다, CLI 중심의 실험·최적화 도구라는 점을 감안하면 브랜딩 자산 자체가 프로젝트 성격을 가장 직접적으로 보여주는 시각 자료다.

Quick Links

메모: 공개 Wiki는 활성화되어 있지 않고, 별도 Discussions 탭도 보이지 않는다. 실제 커뮤니티 논의는 이슈 트래커를 중심으로 이뤄진다.

Executive Summary

Heretic는 transformer 계열 언어 모델의 “refusal / safety alignment” 성향을, 별도의 대규모 재학습 없이 directional ablation(abliteration)으로 약화시키는 CLI 기반 오픈소스 도구다. 프로젝트의 핵심 차별점은 수작업으로 특정 레이어와 특정 방향 벡터를 고르는 대신, Optuna TPE를 써서 방향 인덱스·레이어별 개입 강도·컴포넌트별 커널 모양을 자동 탐색한다는 점이다.

코드를 보면 Heretic는 단순히 “행렬을 한 번 수정하는 스크립트”가 아니다. main.py가 전체 실험 루프를 오케스트레이션하고, model.py가 모델 로딩·LoRA 삽입·레이어/모듈 탐색·ablation 적용을 담당하며, evaluator.py나쁜 프롬프트에서의 refusal 수좋은 프롬프트에서의 KL divergence를 함께 점수화한다. 이 구조 덕분에 프로젝트는 “검열 억제”와 “원본 성능 손상 최소화”를 동시에 추구한다.

 

실제 사용 경험 관점에서는 세 가지가 특히 돋보인다. 첫째, 하드웨어 적응성이 높다. dtype fallback, 4-bit 양자화, 자동 배치 크기 탐색, 다양한 accelerator 탐지를 기본 지원한다. 둘째, 연구 도구성이 강하다. residual geometry 표, PaCMAP 투영, GIF 애니메이션까지 제공한다. 셋째, 운영 루프가 짧다. 최적화가 끝나면 바로 저장, Hugging Face 업로드, 채팅 테스트, 벤치마크, 재현성 폴더 생성으로 이어진다.

Key Features

1. 수작업 없는 자동 abliteration 탐색

README가 설명하듯 Heretic는 directional ablation 자체보다도, 좋은 파라미터 조합을 자동으로 찾는 최적화기에 무게 중심이 있다. 각 trial마다 방향 인덱스, attention/MLP 개입 강도, 레이어 상에서의 최대 개입 위치와 감쇠 거리 등을 바꾸어가며, refusal 수와 KL divergence를 동시에 줄이는 Pareto-optimal trial을 찾는다.

 

실제로 main.py의 objective는 각 trial마다 모델을 reset한 뒤 abliterate하고, evaluator.get_score()(1) 나쁜 프롬프트 refusal 비율(2) 좋은 프롬프트 KL divergence를 다시 계산하는 구조다. 즉, Heretic의 “자동화”는 단순 파이프라인 자동화가 아니라, 다목적 최적화 루프 자동화에 가깝다.

2. 모델 계열별로 다른 모듈을 찾아내는 구조적 적응성

model.pyget_layer_modules()는 표준 dense LLM만 가정하지 않는다. 일반적인 self_attn.o_proj, mlp.down_proj뿐 아니라, Qwen 계열의 linear_attn.out_proj, 여러 MoE expert의 down_proj/w2, Granite MoE Hybrid의 shared_mlp.output_linear까지 탐지한다. 즉, 프로젝트는 “한두 모델용 해킹”이 아니라, 다양한 transformer 계열을 위한 모듈 탐색기를 구현해 두었다.

 

또한 get_model_class()는 설정에 vision_config가 있으면 AutoModelForImageTextToText, 아니면 AutoModelForCausalLM을 선택한다. README가 “many multimodal models”를 지원한다고 말하는 근거가 코드에 실제로 있다.

3. 하드웨어 상태를 보고 실행 전략을 스스로 바꾸는 CLI

Heretic는 실행 초기에 GPU/accelerator 정보를 표시하고, model load 단계에서 dtype fallback을 시도하며, 별도 지정이 없으면 자동 배치 크기 탐색까지 수행한다. README의 “On an RTX 3090 … about 45 minutes”라는 문장은 단순 홍보 문구가 아니라, 코드상으로도 자동 배치 크기 벤치마킹이 들어 있다는 점에서 설득력이 있다.

 

 

캡션: 실행 초반 화면. openai/gpt-oss-20b를 로딩한 뒤 transformer layer 수와 ablatable component를 출력하고, mlabonne/harmless_alpacamlabonne/harmful_behaviors를 불러온 다음, batch size를 1→128까지 늘려가며 최적 처리량을 찾는다.

4. LoRA를 활용한 “가역적” 개입 방식

많은 abliteration 구현은 원본 weight를 직접 수정하지만, Heretic는 먼저 대상 모듈들에 LoRA adapter를 꽂은 뒤, LoRA A/B 행렬에 directional ablation에 해당하는 delta를 써 넣는 방식을 택한다. 이 설계는 두 가지 장점을 준다.

첫째, trial 사이를 오갈 때 base model을 매번 다시 다운로드하거나 다시 계산하지 않아도 된다. 둘째, 저장 시점에 merged full modelLoRA adapter 사이를 선택할 수 있다. 양자화 모델의 경우 merge에 많은 시스템 RAM이 필요하다는 경고까지 친절하게 출력한다.

5. 연구용 residual 분석 기능이 생각보다 깊다

Heretic의 research extra는 단순한 “플롯 하나 그리기” 수준이 아니다. analyzer.py는 좋은/나쁜 프롬프트의 첫 토큰 residual을 모아 geometric median, cosine similarity, norm, silhouette score를 층별로 표로 출력하고, 별도로 PaCMAP 기반 2D 투영을 생성해 layer-wise PNG와 GIF 애니메이션까지 만든다.

 

 

캡션: README에 포함된 residual projection GIF에서 일부 프레임을 발췌한 정적 스냅샷. 원본 GIF는 figures/residual_plot.gif에 함께 보관했다. 이 자산은 Heretic가 단순한 “모델 개조기”가 아니라, 내부 표현을 관찰하는 interpretability 도구이기도 하다는 점을 잘 보여준다.

 

 

6. 평가와 운영 루프가 한 프로그램 안에서 닫힌다

최적화가 끝나면 Heretic는 Pareto front를 보여주고, 사용자는 원하는 trial을 골라:

  • 로컬 저장
  • Hugging Face 업로드
  • 내장 채팅 테스트
  • lm-eval 기반 벤치마크
  • trial selection 메뉴 복귀

중 하나를 선택할 수 있다. 별도의 후처리 스크립트 없이 연구용 실험과 배포 동작이 하나의 CLI 루프 안에서 닫혀 있다는 점은 실제 사용성에 큰 영향을 준다.

7. 재현성(reproducibility)을 1급 기능으로 취급한다

utils.pyreproduce/ 폴더를 생성해 설정 파일, requirements, Optuna study journal, 시스템/가속기 정보, 해시값까지 묶어 올릴 수 있게 해 둔다. “실험이 잘 됐다”를 넘어서, 누가 어떤 하드웨어/패키지 조합으로 어떤 trial을 골랐는지 추적할 수 있도록 한 것이다. 오픈소스 LLM 실험 프로젝트에서 이 수준의 재현성 지원은 꽤 드물다.

8. 실험적 파생 방향: no-slop 스타일 제어

루트에 있는 config.noslop.toml과 이슈 #121은 Heretic가 안전 정렬 제거뿐 아니라, 문체적 습관(sloppy / purple prose) 억제 같은 방향으로도 재해석되고 있음을 보여준다. 즉 이 프로젝트의 일반화된 핵심은 “refusal suppression”보다 더 넓은 내부 표현 방향 제어 엔진에 가깝다.

Tech Stack

영역 구성 요소 비고
Language Python >=3.10 패키지 메타데이터 기준
DL Core PyTorch >=2.2 README 기준 별도 설치 권장
Model Runtime transformers~=5.3, accelerate~=1.13, peft~=0.18, bitsandbytes~=0.49 모델 로딩, multi-device, LoRA, 4-bit 양자화
Data / Eval datasets~=4.7, lm-eval[hf]~=0.4 prompt dataset, 벤치마크
Optimization optuna~=4.7 TPE sampler, 다목적 최적화
CLI / UX rich~=14.3, questionary~=2.1, pydantic-settings~=2.13 콘솔 출력, interactive menu, 설정 파싱
System Introspection psutil~=7.2, py-cpuinfo~=9.0 메모리·CPU·환경 정보
Research Extra geom-median~=0.1, imageio~=2.37, matplotlib~=3.10, pacmap~=0.8, scikit-learn~=1.7 residual geometry, 시각화, GIF 생성

Architecture

캡션: 저장소 코드를 바탕으로 재구성한 아키텍처 개요도. README의 개념 설명과 달리, 실제 코드에서는 main.py가 orchestration을 맡고, model.py/evaluator.py/analyzer.py가 역할별로 분리되어 있다.

Heretic의 아키텍처는 크게 다섯 단계로 읽힌다.

  1. 설정 및 런타임 준비
    Settings가 CLI, 환경변수, config.toml을 순서대로 병합한다. 실행 초기에 accelerator 정보가 출력되고, dtype fallback과 배치 크기 자동 탐색이 수행된다.
  2. 기준 데이터 로딩
    good_promptsbad_prompts는 refusal direction 계산용, good_evaluation_promptsbad_evaluation_prompts는 trial 평가용으로 분리되어 있다. 기본 데이터셋은 mlabonne/harmless_alpacamlabonne/harmful_behaviors다.
  3. refusal direction 계산
    각 프롬프트에 대해 “첫 번째 생성 토큰” 시점의 residual을 추출한 뒤, 층별로 bad_mean - good_mean을 계산해 refusal direction을 만든다. 필요하면 orthogonalization과 winsorization을 적용한다.
  4. LoRA 기반 directional ablation + Optuna 탐색
    대상 모듈에 LoRA를 삽입한 뒤, 각 trial이 고른 방향 인덱스와 weight kernel에 따라 attn.o_projmlp.down_proj 계열 weight에 개입한다. 이때 컴포넌트별로 서로 다른 커널을 줄 수 있다는 점이 Heretic의 중요한 설계 포인트다.
  5. 평가, Pareto selection, 배포/검증
    평가 함수는 “좋은 프롬프트 첫 토큰 분포의 KL divergence”와 “나쁜 프롬프트에서의 refusal marker 수”를 동시에 계산한다. 최종적으로 Pareto-optimal trial만 사용자에게 노출하고, 저장·업로드·채팅·벤치마크·재현성 산출로 이어진다.

README에 포함된 다음 그림은, Heretic가 레이어 전체에 균일 개입을 하지 않고 컴포넌트별 레이어 커널을 최적화한다는 점을 가장 잘 보여준다.

 

 

캡션: max_weight, max_weight_position, min_weight, min_weight_distance로 정의되는 개입 커널 예시. attention과 MLP에 서로 다른 개입 모양을 줄 수 있기 때문에, “refusal은 낮추되 원본 능력 손상은 줄이는” 절충점을 더 세밀하게 찾을 수 있다.

Code Structure

src/heretic/
├── main.py       # CLI 진입점, Optuna study, trial loop, export/upload/chat/benchmark
├── model.py      # 모델 로딩, tokenizer, LoRA 삽입, layer/module 탐색, abliteration 적용
├── evaluator.py  # refusal marker 기반 평가 + 좋은 프롬프트 KL divergence 계산
├── analyzer.py   # residual geometry 표, PaCMAP projection, PNG/GIF 생성
├── config.py     # Settings, dataset spec, benchmark spec, CLI/env/TOML 병합
├── system.py     # accelerator / driver / CPU / environment 탐지
├── utils.py      # prompt 로딩, interactive helper, reproduce folder 생성
└── progress.py   # tqdm patch

Usage & Setup

최소 설치

pip install -U heretic-llm
heretic Qwen/Qwen3-4B-Instruct-2507

연구 기능 포함 설치

pip install -U heretic-llm[research]

실행 전에 알아둘 점

  • Python 3.10+와 하드웨어에 맞는 PyTorch 2.2+ 설치가 선행되어야 한다.
  • 기본 설정은 refusal direction 계산용으로 400 + 400개의 train prompts, 평가용으로 100 + 100개의 test prompts를 사용한다.
  • 메모리가 빠듯하면 config.toml에서 quantization = "bnb_4bit"를 사용해 VRAM 요구량을 줄일 수 있다.
  • batch_size = 0이면 Heretic가 자동으로 최적 배치 크기를 탐색한다.
  • 실행 종료 후에는 저장, Hugging Face 업로드, 채팅, 벤치마크 중 하나를 이어서 선택할 수 있다.

자주 건드리게 되는 설정 포인트

quantization = "bnb_4bit"
plot_residuals = true
print_residual_geometry = true
winsorization_quantile = 0.95
orthogonalize_direction = true
n_trials = 200
n_startup_trials = 60

기본 평가 방식 이해

Heretic의 trial 평가는 full-sequence 품질 지표가 아니라 다음 두 축으로 이뤄진다.

  1. 좋은 프롬프트의 첫 토큰 분포 KL divergence
  2. 나쁜 프롬프트 응답 중 refusal marker가 포함된 개수

이 방식은 매우 빠르고 자동화 친화적이지만, 후반부 이슈 논의가 보여주듯 “명시적 refusal은 아니지만 실질적 답변도 아닌 응답”을 놓칠 수 있다. 즉, CLI 사용 자체는 간단하지만 평가 해석은 꽤 연구 지향적이다.

Strengths and Limitations

Strengths

  • 자동화 수준이 높다. 모델, 데이터, 하드웨어, 최적화, 배포가 하나의 CLI 루프로 묶여 있다.
  • 구현이 구조적이다. dense LLM뿐 아니라 multimodal/MoE 계열까지 고려한 모듈 탐색 로직이 있다.
  • 연구 보조 기능이 강하다. residual geometry와 PaCMAP 시각화는 다른 abliteration 도구와 비교해도 꽤 진지한 편이다.
  • 재현성 지원이 좋다. study journal + environment report + hashes를 함께 다룬다.

Limitations

  • 평가 함수가 marker-based refusal detection에 크게 의존한다. 따라서 “거절은 하지 않지만 답도 하지 않는” 응답을 과대평가할 수 있다.
  • SSM/hybrid, inhomogeneous layers, novel attention 일부는 아직 지원되지 않는다.
  • 문제 클래스가 근본적으로 불안정하다. 이슈 #124가 보여주듯 특정 모델에서는 massive activation이 refusal direction을 왜곡할 수 있다.
  • 프로젝트 목적 자체가 강한 안전/정렬 논쟁을 동반한다. 따라서 production use보다 연구/분석/특수 실험 문맥에서 더 자연스럽다.

Personal Insights

1. 의료 AI 관점

의료 AI에서는 “무조건 대답하는 모델”이 좋은 모델이 아니다. 임상 영역에서는 정확한 지식만큼이나 적절한 abstention(보류/거절)이 중요하기 때문이다. Heretic는 내부 표현 수준에서 refusal 회로를 약화시키는 도구라서, 의료 AI에 직접 적용하면 모델의 안전한 보수성까지 함께 벗겨낼 위험이 있다.

반대로 연구 용도로는 흥미롭다. 예를 들어 의료 질의에서 모델이 실제 지식 부족 때문에 멈추는지, 아니면 alignment layer 때문에 과도하게 멈추는지를 분리해서 보고 싶다면, Heretic류의 표현 수준 개입은 좋은 실험 도구가 될 수 있다. 다만 production system으로 쓰려면 모델 내부를 바꾸기보다, 외부 정책 계층과 도메인 전용 abstention 로직을 분리하는 편이 더 안정적이다.

2. Bioinformatics 관점

생물정보학 질의는 종종 안전 민감도가 높고, 동시에 전문 용어가 많아 base model이 과도하게 보수적으로 반응하기 쉽다. Heretic의 장점은 “어떤 토큰/레이어 조합이 refusal로 이어지는가”를 실험적으로 탐색할 수 있다는 점이다. 즉, 바이오 모델링에서 이 도구는 “검열 제거기”라기보다 latent capability를 막는 표현 방향을 탐사하는 probe로 볼 수 있다.

다만 이 프로젝트의 기본 평가 세트는 의료·생물안전 도메인 특화가 아니라 일반 harmful/harmless prompt 구분이다. 따라서 bioinformatics 관점에서 제대로 쓰려면, refusal marker 목록과 good/bad dataset을 도메인 전용 데이터셋으로 교체하고, 위험한 wet-lab/biothreat 콘텐츠에 대해서는 별도의 safety gate를 외부에 둬야 한다.

3. Autonomous Agent 관점

에이전트 시스템에서는 vendor-level refusal이 종종 workflow completion을 막는다. 그런 의미에서 Heretic는 “에이전트가 중간 단계에서 불필요하게 멈추지 않게 하는 실험 도구”로 매력적이다. 특히 사용자 정의 정책은 유지하면서, 베이스 모델에 박혀 있는 과도한 vendor refusal만 약화시키고 싶은가? 같은 질문과 잘 맞는다.

그러나 이슈 #288이 보여주듯, 현재 평가 함수는 “거절 대신 clarification question으로 도망가는 전략”을 성공처럼 볼 수 있다. 에이전트 입장에서는 이것이 치명적이다. 겉보기 refusal 수는 줄지만, 실제로는 계획 실행 능력 대신 지연 전략이 강화될 수 있기 때문이다. 따라서 에이전트 문맥에서는 Heretic를 단독 해법으로 보기보다, 외부 planner / policy engine / tool permission layer와 함께 검증해야 한다.

4. 개인적 총평

Heretic의 진짜 가치는 “uncensored model maker”라는 자극적 표면보다, 표현 공간을 방향 벡터로 요약하고, 그 방향을 최소 손상으로 억제하도록 자동 탐색하는 실험 프레임워크에 있다. 이 관점에서 보면 이 프로젝트는 alignment 해제 도구이면서 동시에, representation surgery + lightweight model editing 연구 플랫폼이다.

특히 config.noslop.toml과 관련 이슈는 이 프레임워크가 refusal 제거를 넘어 문체, 길이, 습관적 표현, 특정 응답 성향까지 건드릴 수 있음을 시사한다. 장기적으로는 “safety alignment 제거기”보다 더 넓은 behavioral subspace editing toolkit으로 진화할 가능성이 있다.

Analysis Basis

이 리포트는 아래 자료를 함께 참고해 작성했다.

  • README.md
  • pyproject.toml
  • config.default.toml
  • config.noslop.toml
  • src/heretic/main.py
  • src/heretic/model.py
  • src/heretic/evaluator.py
  • src/heretic/analyzer.py
  • src/heretic/config.py
  • src/heretic/system.py
  • 이슈 토론:
    • #121 Slop Reduction
    • #124 Detect and handle massive activations
    • #288 Marker-based objective가 clarification question으로 우회될 수 있다는 문제 제기