オープンウェイトLLMから検閲を取り除くツール

2026/03/06 23:27

オープンウェイトLLMから検閲を取り除くツール

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

概要:
OBLITERATUS は、再訓練せずに大型言語モデルから拒否行動を除去するオープンソースツールキットです。SUMMON → PROBE → DISTILL → EXCISE → VERIFY → REBIRTH の多段階パイプラインを通じて、隠れ状態を調査し、SVD あるいはその派生手法で拒否方向を抽出し、ノルム保存的にそれらを投影して除去します。さらに、核心機能(perplexity、coherence)が維持されているかを検証します。また、自己修復(“Ouroboros”)効果を補償する専用分析モジュールも備えています。

このツールキットは HuggingFace の任意のトランスフォーマーモデル(GPT‑2、LLaMA、Mistral、Falcon、OPT、BLOOM 等)と互換性があり、恒久的な重み投影手法(basic から nuclear まで)と推論時抑制用の可逆ステアリングベクトルをサポートします。OBLITERATUS は 15 の分析モジュールと 116 個のプレセット構成(5 つの計算レベルにわたる)を提供し、さらに 10 の研究プレセットが層除去、ヘッドプルーニング、FFN/埋め込みアブレーションなどのアブラテーション戦略をガイドします。

ユーザーはツールキットを 6 つのモードで実行できます:HuggingFace Spaces(ゼロセットアップ)、ローカル Gradio UI、Google Colab、CLI、Python API、または YAML 設定ファイル。いずれも匿名テレメトリーへのオプトインが可能で、モデル名、手法、ベンチマークスコア(拒否率、perplexity、coherence、KL ダイバージェンス)、ハードウェア詳細、タイムスタンプを記録します。このデータは HuggingFace Space のライブリーダーボードに活用され、対話研究のコミュニティデータセットへフィードバックされます。

今後の開発では、Expert‑Granular Abliteration(EGA)、CoT‑Aware Ablation、COSMIC Layer Selection、Refusal Direction Optimization、Float Direction Interpolation、KL‑Divergence Co‑Optimization、LoRA‑Based Reversible Ablation などの追加手法が予定されています。

OBLITERATUS は AGPL‑3.0 の下でオープンソース利用を許可しつつ、AGPL の義務に従えない組織向けには商用ライセンスも提供します。本プロジェクトは、実行ごとにデータポイントを生成し、拒否メカニズムの普遍性やハードウェア固有性能プロファイルに関する研究を促進することでオープンサイエンスを推進しています。

本文

OBLITERATUS(オブリテレータス)

項目内容
絵文字💥
カラー開始green
カラー終了gray
SDKgradio
SDK バージョン5.29.0
アプリファイルapp.py
永続ストレージlarge
ピン留め済みtrue
ライセンスagpl-3.0
タグabliteration, mechanistic‑interpretability
短い説明ワンクリックでモデルを解放+チャットプレイグラウンド

概要

OBLITERATUS は大型言語モデルの拒否行動(コンテンツ拒否)を理解し除去するための最先端オープンソースツールキットです。
各実行ごとに、内部表現を精密に切除してモデルを賢くします――再学習やファインチューニングは不要です。

主な特徴

  • Abliteration – SVD・PCA・疎オートエンコーダ等で拒否サブスペースを抽出・除去。
  • 解析に基づくパイプライン – ジオメトリック洞察(方向数、レイヤー選択など)から各ステップを自動設定。
  • テレメトリー主導研究 – 匿名で寄与したデータがコミュニティデータセットに蓄積され、モデル・ハードウェア横断的な整合性研究を推進。

利用モード

モード説明
1. HuggingFace Spacesテレメトリー付きのゼロ設定Web UI。
2. ローカル Gradio UI同一インターフェース、GPU上で実行(
obliteratus ui
)。
3. Google Colabノートブックを実行、無料 T4 タイアまで約8 Bパラメータ。
4. CLI自動化やヘッドレス利用に向けたスクリプタブルコマンド。
5. Python APIプログラム的完全制御;中間成果物へアクセス可能。
6. YAML 設定バージョン管理された再現性のある研究用。

コアパイプライン

  1. SUMMON – モデルとトークナイザーをロード。
  2. PROBE – 制限付き/非制限付きプロンプトで活性化値を収集。
  3. ANALYZE – ジオメトリ(整合性、コーン、頑健性)をマッピングする解析モジュール実行。
  4. DISTILL – 調整済みパラメータで拒否方向を抽出。
  5. EXCISE – ガードレール(ノルム保持・バイアス投影)を外科的に除去。
  6. VERIFY – パープレキシティ、コヒーレンス、オウロボロス自己修復の検出;必要なら追加パス実行。
  7. REBIRTH – 解放済みモデルとメタデータを保存。

Abliteration メソッド

方法方向数主な特徴推奨用途
basic1 (diff‑in‑means)高速ベースラインクイックテスト
advanced4 (SVD)ノルム保持、バイアス投影、2パスデフォルト
aggressive8 (SVD)ホワイト化 SVD、反復洗練、3パスガードレール最大除去
surgical8 (SVD)EGA、ヘッドサージェリー、SAE、レイヤー適応、MoE対応MoE モデルの精密調整
optimized4 (SVD)ベイズ自動チューニング、CoT 考慮、KL 共最適化自動調整で最高品質
inverted8 (SVD)意味的拒否反転拒否反転実験
nuclear8 (SVD)すべての手法+専門家移植+ステアリング最大力

ステアリングベクトル(可逆)

from obliteratus.analysis import SteeringVectorFactory, SteeringHookManager

vec = SteeringVectorFactory.from_refusal_direction(refusal_dir, alpha=-1.0)
config = {"vectors": [vec], "target_layers": list(range(10, 16))}
manager = SteeringHookManager()
manager.install(model, config)

output = model.generate(input_ids)   # ステアリング付き生成
manager.remove()                     # 元の重みへ復帰

分析モジュール(合計15)

モジュール対応質問
Cross‑Layer Alignment拒否はレイヤーを跨いでどのように進化するか?
Refusal Logit Lensどのレイヤーが拒否決定を下すか?
Whitened SVDホワイト化後の主要拒否方向は?
Activation Probe各レイヤーでの拒否信号量は?
Defense Robustnessガードレールは自己修復(オウロボロス)するか?
Concept Cone Geometry1つまたは複数のメカニズム;共有ガードレールはあるか?
Alignment Imprint DetectionDPO / RLHF / CAI / SFT のフィンガープリント?
Multi‑Token Positionシーケンス上で拒否が集中する位置は?
Sparse Surgeryどの重み行が最大の拒否を担うか?
Causal Tracing拒否に必須な因果要素は?
Residual Stream Decomposition注意 vs MLP の寄与比率?
Linear Refusal Probe未検出情報を判別する分類器?
Cross‑Model Transferガードレールの普遍性は?
Steering Vectors推論時にガードレールを無効化できるか?
Evaluation Suite拒否率、パープレキシティ、コヒーレンス、KL、CKA、ランク。

Ablation 戦略

戦略内容用途例
layer_removal変換器全レイヤーをゼロ化重要レイヤーの特定
head_pruning個別注意ヘッドをゼロ化行動回路の位置決め
ffn_ablationフィードフォワードブロックをゼロ化知識保存領域の発見
embedding_ablation埋め込み次元範囲をゼロ化表現構造解析

モデルプリセット(5ティア、合計116)

ティアVRAM代表モデル
TinyCPU / <1 GBGPT‑2, TinyLlama 1.1B
Small4–8 GBPhi‑2 2.7B, Gemma‑2 2B
Medium8–16 GBMistral 7B, Qwen2.5‑7B
Large24+ GBLLaMA‑3.1 8B, Qwen2.5‑14B
FrontierマルチGPUDeepSeek‑V3.2 685B, Qwen3‑235B

コミュニティ主導研究

  • テレメトリー – オプトイン、匿名データ(モデル名、手法、ベンチマークスコア、ハードウェア)。

    • Spaces: デフォルトで有効。
    • ローカル:
      --contribute
      フラグまたは環境変数
      OBLITERATUS_TELEMETRY=1
  • リーダーボード – Space 上でライブランキング、CLI で集計結果を閲覧:

    obliteratus aggregate --format summary
    obliteratus aggregate --format latex --metric refusal_rate --min-runs 3
    
  • ローカル PR 貢献 – JSON をローカル保存し、プルリクエストで提出。


ドキュメント&リファレンス

docs/index.html
を開くとインタラクティブダッシュボードが利用可能:設定ビルダー、モデルレジストリ、結果可視化、モジュール参照、戦略解説。


ライセンス

  • AGPL‑3.0(オープンソース) – ネットワークサービス提供時にソースを開示必須。
  • 商用ライセンス – プロプライエタリ利用のための有料ライセンス、GitHub Issues でお問い合わせ。

鎖を断ち、心を解放し、頭脳を守り、科学を前進させる。

Pliny the Prompter が <3 で作成

同じ日のほかのニュース

一覧に戻る →

2026/03/07 6:52

「このCSSは、私が人間であることを証明します。」

## Japanese Translation: (以下に翻訳文を記載します) **著者は、選択的な大文字化、CSS を用いた対象的なケース変換(`text-transform: lowercase`)、慎重に使われる em ダッシュなどの微妙なタイポグラフィック・選択が、ファイルを `tr` でパイプするような鈍い自動化手法よりも優れていると主張しています。大文字化は「最初の傷」として描かれますが、実際には予想ほど痛みを伴わず、必要に応じて単語が大文字で流れ出します。著者は粗末な `cat post.md | tr A‑Z a‑z | sponge post.md` の手法を却下し、よりクリーンな効果を持つ CSS を推奨しています。 em ダッシュは貴重とされますが、作家の真実の自分を露呈させないように隠したままである必要があります。モノスペースフォントはテキストの美学を損なうため拒否されています。小さなスクリプト(`uv run rewrite_font.py`)は文字形態を微調整するための取るべき手段として強調され、意図的に単語を誤字すること(例: “their/there”、 “its/it’s”)がスタイルの一部であると述べられていますが、“Definately?” のような問題のあるペアは避けるとしています。 作家はノーリグ・コーパスを参照し、単語選択を導くとともに、ターゲットとなる単語から「u」を迅速に除去することで手法の精密さを示しています。全体的なトーンは、書くことが外見だけでなく思考・推論・関与を反映するものであると強調しています。 以前の拒否(“No. Not today.”)はスタイリスティックオーバーホールへの抵抗を示しています。次に計画されている変更は、作家自身の自我感覚を変える唯一の真に重要なステップとして描かれています。 技術的読者――特に文書スタイリング、フォント操作、編集ワークフローに関わる人々――に対して、このメッセージは自動変換から離れ、意図的なタイポグラフィック決定へ移行することを奨励し、デザイン標準や編集実務の再構築につながり得ると述べています。

2026/03/07 7:55

**C# の文字列が Dapper で SQL Server インデックスを静かに破壊する理由** Dapper を使って SQL Server データベースへクエリを投げる際、文字列結合や文字列補間(string interpolation)でクエリを作成することはよくあります。 しかし、この一見無害な手法がインデックスの性能を黙って破壊してしまうケースがあります。 --- ## なぜ起きるのか 1. **暗黙の型変換** `string` と `int`・`bool` など非文字列型を結合すると、SQL Server は列値を `nvarchar` に変換せざるを得ません。 2. **インデックス回避** この暗黙変換により最適化器は既存の数値や日付インデックスを利用できず、フルテーブルスキャンが発生します。 --- ## 問題を引き起こす典型的なパターン | パターン | 何をしているか | インデックスへの影響 | |---------|-----------------|----------------------| | `WHERE Id = " + id`(文字列結合) | `Id` 列を `nvarchar` に変換 | フルスキャン | | `$"SELECT * FROM Users WHERE IsActive = {isActive}"`(補間) | ブール値も同様に `nvarchar` へ変換 | フルスキャン | | `WHERE CreatedDate >= @date.ToString()` | 日付を文字列へ変換 | インデックスが失われる | --- ## 修正方法 1. **インライン値ではなくパラメータを使用する** ```csharp var sql = "SELECT * FROM Users WHERE Id = @Id"; connection.Query<User>(sql, new { Id = id }); ``` 2. **型の一貫性を保つ** 列が期待する正確な型(`int`、`DateTime` など)で渡す。 3. **C# で暗黙変換を避ける** 必要なら明示的にキャストまたは変換し、安全かつ意図した変換のみ行う。 --- ## 簡易チェックリスト - [ ] Dapper に渡す値は文字列化せず、型付きである。 - [ ] 変数データと SQL フラグメントのインライン結合を行わない。 - [ ] すべてのクエリに `@ParameterName` プレースホルダーを使用する。 これらのガイドラインに従えば、インデックスの整合性を保ちつつクエリを高速かつ効率的に維持できます。

## Japanese Translation: **概要:** .NET/Dapper アプリケーションでは、C# の文字列を `nvarchar(4000)` として渡すと、SQL Server が `varchar` 列に対して暗黙の型変換(implicit conversions)を実行します。これにより、インデックス検索がスキャンに置き換わり、論理読み取り数が単桁から数万に膨らみ、CPU/I/O の使用率が急増します(例:`CONVERT_IMPLICIT(nvarchar(255), [Sales].[ProductCode], 0)`)。 正確性には影響しませんが、実行計画や Query Store の警告で明らかになります。特に `SQL_Latin1_General_CP1_CI_AS` などの照合順序では顕著です。 **修正:** パラメータを ANSI として明示的に宣言し、列サイズと一致させます。 ```csharp var p = new DynamicParameters(); p.Add("productCode", productCode, DbType.AnsiString, size: 100); await conn.QueryFirstOrDefaultAsync<Product>(sql, p); ``` または匿名オブジェクトを使用する場合: ```csharp new { productCode = new DbString { Value = productCode, IsAnsi = true, Length = 100 } } ``` スキーマ変更、インデックス更新、クエリ書き換えは不要です。パフォーマンスの改善は即座に実感できます。 **監査ヒント:** Query Store で `@nvarchar(4000)` を検索し、varchar 列へ文字列を渡す匿名オブジェクトをコード内でスキャンしてください。 **ベストプラクティス:** 将来のリグレッション防止のために、`DbType.AnsiString`(または `IsAnsi = true`)を使用した理由をコメントしておくことが推奨されます。 この簡単な調整でサーバー負荷を低減し、コスト削減とスケールアップが実現します。結果として開発者・ユーザー・広範な .NET/SQL Server コミュニティ全体に恩恵をもたらします。

2026/03/07 6:19

**IPリースの陰影ある世界**

## Japanese Translation: IPリースは、誰もがクリーンで匿名のIPv4アドレスを取得し、ジオロケーションデータを操作できる隠密レンタル市場を生み出しており、IPベースの評判システムの信頼性を損なっています。ブロックを保有し、標準的な地域インターネットレジストリ(RIR)手順外でサブリースすることで、これらのサービスはWHOISトレーサビリティとRIRアカウンタビリティチェーンを迂回します。リース会社は料金を払ってブラックリスト化された範囲を「クリーン」し、ドロップダウンまたはCSVアップロードで任意の住宅または商業ジオロケーションを割り当て、WHOIS国フィールドまで操作することができ、MaxMind、Cloudflare、Googleなどに偽情報を供給します。 主要なVPNおよびプロキシプロバイダー(例:NordVPN、ExpressVPN、CyberGhost、PIA)は、LogicWeb、IPXO、INIZ、IPFoxi、Heficed、AnyIP/IPv4Deals などのリース会社からIPを調達しています。これらのプラットフォームは多くの場合、同じサイトで生IPスペースと完全なプロキシサブスクリプションの両方を販売し、エンドツーエンドの匿名化パイプラインを構築します。一部のプロバイダーは住宅ISPと直接提携してトラフィックを実際の加入者ネットワーク経由でルーティングし、合法的なオペレーターとプロキシとの境界を曖昧にしています。 業界は法的グレイズゾーンで運営されており—IPリースやジオロケーション操作を明示的に禁じる法律がないため—実効性の低い執行とインセンティブの不整合が生じています。リースが拡大するにつれて、インターネットセキュリティの基盤であるIP評判リスト、WHOIS帰属、およびジオロケーションデータベースはさらに侵食され、大規模な位置・所有権・評判の偽装が可能になります。これはユーザー(ボット検出やレート制限での誤検知)とIPベースのセキュリティ決定に依存する企業を脅かし、最終的にはインターネット全体の説明責任と安全性を弱めます。