Hugging Faceを選ぶ理由：オープンウェイトLLMの内部へアクセスし、能力を拡張する

Hugging Faceは、私にとってAIコミュニティの中心地の一つです。 そう考える理由は、モデル、データセット、コード、デモ、Discussionが一つのプラットフォームでつながり、他者の成果を起点に次の実験を始められることにあります。 実験の前提と結果をリポジトリの参照関係として辿れる環境は、私たちの知的好奇心を強く刺激します。 Hugging FaceもHugging Face Hubの公式資料で、モデル、データセット、Spacesを探索し、実験し、共同作業するための基盤としてHubを説明しています。

モデル、データ、デモ、コード、議論を、リポジトリを軸に結びつけます。

オープンウェイトモデルを選ぶと、生成APIから返される文章だけでなく、モデルが出力を組み立てる途中の情報へアクセスできます。 利用するモデル、Transformers実装、推論ランタイムが対応していれば、生成前のlogits、各層のhidden states、attention weightsを取得できます。 特定の層やattention headへ介入したり、activation steeringによって挙動を変えたりすることも可能です。

このアクセスは、モデルを詳しく調べるためだけのものではありません。 確率分布を使って候補を選び直す、内部表現から用途固有の特徴を取り出す、activationへvectorを加えて振る舞いを調整するなど、外部APIだけでは組みにくい機能を実装できます。 オープンウェイトであることは、既製のモデルをそのまま利用する選択肢に加えて、モデルの内側へ手を入れて能力を拡張する選択肢を開きます。

麻布技術研究所では、こうしたユースケースをHugging Face上の成果物として共有する企画を進めています。 候補モデル、実装コード、測定値、うまくいかなかった条件まで公開できる段階にはまだ達していません。 この記事では、私たちがどのような能力拡張に関心を持ち、公開時に何を残そうとしているのかを説明します。

logitsから生成を組み替える

ベンチマークの順位だけでは、モデルを使ってどのような機能を作れるかまでは分かりません。 オープンウェイトモデルでは、生成された文章に加えて、その文章が選ばれる前の候補を扱えます。

TransformersのModel outputs公式資料では、因果言語モデルの出力として、各token候補に対するsoftmax前のscoreであるlogitsが定義されています。 logitsへsoftmaxを適用すると、その時点のtoken確率分布を計算できます。

この確率分布へアクセスできれば、用途に応じたtokenの抑制や優先、複数候補の再評価、独自の停止条件といった処理を生成過程へ組み込めます。 たとえば、決められた形式で応答させる機能では、必須tokenと禁止tokenの推移を観測しながら、候補の選び方へ介入できます。 完成した文章を後処理する方法とは異なり、文章が作られる途中で選択肢を調整できる点に実装上の広がりがあります。

同時に、確率分布はモデルの振る舞いを理解する手掛かりにもなります。 同じ回答に至った二つのモデルでも、候補token間の差には違いがあるかもしれません。 prompt、量子化、推論設定、介入の前後でlogitsを保存すれば、その違いをtoken単位で比較できます。

ただし、高いtoken確率は、事実の正しさやモデル自身の確信を直接表す値ではありません。 確率分布を業務上の信頼度へ利用する場合は、別の正解データでcalibrationを測り、用途ごとの誤差を確かめる必要があります。

attentionとhidden statesへアクセスする

Transformersでは、対応するモデルでoutput_hidden_states=Trueやoutput_attentions=Trueを指定すると、各層のhidden statesやhead別のattention weightsを受け取れます。 取得できる情報、そのshape、意味づけは、モデルのarchitecture、設定、Transformersの実装、推論ランタイムに依存します。

attention weightsを可視化すると、token間の重みが層とheadごとにどう変わるかを観測できます。 hidden statesには、各層がその時点で保持している内部表現が含まれます。 これらを読み出せることにより、特定の特徴を検出するprobeを作る、外部の処理を呼び分けるためのsignalとして使う、層やheadへ介入して出力の変化を調べるといった実装が可能になります。

生成結果に加えて、確率分布と層ごとの内部表現を観測し、介入後の変化まで比較します。

内部状態へ介入できることは、狙った方向へ常に安全に制御できることを意味しません。 attentionの可視化だけでは、そのheadが出力を生んだ原因までは確定できません。 headを無効化する、activationを置換する、介入対象を入れ替えるといった対照条件を設けることで、出力への影響と副作用を切り分けやすくなります。

Inference-Time Interventionは、限られたattention headのactivationへ学習した方向を加える方法を、LLaMAとAlpacaを使ったTruthfulQAの設定で評価した一次研究です。 論文は、対象とした条件でtruthfulnessの改善を報告するとともに、truthfulnessとhelpfulnessのtrade-offも示しています。 この結果は、特定のモデルと評価条件ではhead単位の介入によって挙動が変わったことを示していますが、headの意味を他のモデルへ一般化できることや、安全な制御を保証するものではありません。

Steering Language Models With Activation Engineeringは、対照的なpromptから得たactivationの差をsteering vectorとして推論時に加えるActivation Additionを提案したarXiv preprintです。 activation steeringでは、vectorを作るデータ、対象層、token位置、係数によって結果が変わります。 用途へ組み込む際は、狙った特性の変化とともに、業務品質、安全性、文体、言語能力への影響も測る必要があります。

これらの研究を、完成した機能のカタログとして読むことはできません。 一方で、重みと内部状態へアクセスできれば、既存の推論APIが用意した設定項目に限らず、モデルの振る舞いへ介入する方法を自分たちで研究し、実装できることを示しています。

透明性が信頼感につながる条件

オープンウェイトであることは、それだけでモデルの信頼性を保証しません。 学習データや収集経路が開示されていないモデルもあり、重みを取得できても開発過程のすべてを追えるとは限らないためです。

それでも、利用者がモデルの内部へアクセスできることには意味があります。 提供者の説明だけに依存せず、第三者が同じ重みとコードを使って結果を追試し、異なる条件を試し、問題があれば具体的な証拠とともに異論を示せるからです。 信頼感は「オープンだから正しい」という評価から生まれるのではなく、確かめられる範囲と確かめられない範囲を利用者側で区別できることから生まれます。

その範囲は、次の三つに分けると把握しやすくなります。

• 成果物の公開範囲：重み、設定、tokenizer、推論コード、ライセンス、リビジョンを確認します。
• 計算過程の観測範囲：logits、hidden states、attention weights、hook可能な層とheadを確認します。
• 開発過程の記録範囲：学習データ、収集と除外の方針、annotation、学習条件、評価、安全性試験の開示内容を確認します。

Model Cardsの公式資料は、想定用途、限界、学習に使ったデータ、評価結果などを記述するよう推奨しています。 Model Cardはリポジトリ作成者が記述する資料であり、項目の充足度はモデルごとに異なります。 重みと推論コードを取得できても、学習データの全件、収集経路、filtering、annotation方針、学習計算量が開示されていない場合があります。

ライセンスも透明性とは別に確認が必要です。 商用利用、改変、再配布、派生モデル、利用制限をリビジョンごとに記録しておくことで、技術的に可能なことと、利用条件として認められていることを混同せずに済みます。

能力拡張をコミュニティへ開く

Hugging Faceの価値は、モデルをダウンロードできることだけではありません。 能力拡張に使ったモデル、データ、コード、デモ、議論を、互いに参照できる成果物として公開できます。

たとえば、介入を再現できる形で共有するなら、次の情報を残します。

1. 利用したモデルのリポジトリ、リビジョン、ライセンスを固定します。
2. baselineの生成文、logits、取得可能なhidden statesとattention weightsを保存します。
3. 対象層、head、token位置、vectorを作ったデータ、係数をコードと設定へ残します。
4. 狙った変化だけでなく、業務品質、安全性、文体、言語能力への副作用も記録します。
5. 改善しなかった条件を含めてリポジトリへまとめ、必要に応じてSpaceで動かせるデモを公開します。
6. Discussionで寄せられた追試や異論を、次の実装へつなげます。

この記録は、検証のためだけに作るものではありません。 第三者が実装を再利用し、別のモデルや用途へ移し、元の作者が想定しなかった拡張を試すための接続点になります。 一つの成果が次の成果の材料になることに、オープンなAIコミュニティの面白さがあります。

計算環境を都度用意せず、固定したcommand、container、hardwareで処理を実行したい場合は、Hugging Face Jobsを利用できます。 作成したモデルや実装を認証とautoscalingを備えたAPIとして提供したい場合は、Inference Endpointsも選択肢になります。 どちらかのサービスを使うこと自体が目的ではなく、Hub上のモデル、データ、コード、デモを行き来しながら成果を共有できることが、Hugging Faceエコシステムを選ぶ理由です。

オープンウェイトLLMと作りたいもの

麻布技術研究所が作りたいのは、モデル、データ、コード、内部出力、介入条件、副作用、議論まで辿れる公開リポジトリです。 完成したモデルを評価して終えるのではなく、その内部へアクセスして新しい能力を実装し、他の開発者が再利用できる形にしたいと考えています。

この仕事には、Transformersのmodel classを読み、内部出力とhookの実装を確認する力が必要です。 同時に、観測した相関と介入による変化を区別し、期待に合わない結果も共有する姿勢が求められます。 モデル、データ、研究コード、デモ、DiscussionをつなげられるHugging Faceは、この仕事をチーム内に閉じず、コミュニティとの共同作業へ開く基盤になります。

麻布技術研究所のPanda Forceでは、モデル選定、能力拡張、データ連携、推論基盤、運用設計を一続きの実装課題として扱っています。 ML、LLM、MLOps、Platform Engineeringの境界で、オープンウェイトLLMの内部へアクセスし、これまでにない使い方を形にしたい方は、麻布技術研究所へ連絡してください。

この記事を書いた人

中村泰行（Yasu Nakamura）

株式会社麻布技術研究所 代表取締役社長。 サイバーセキュリティ、人工知能、セキュアシステム、事業成長を主な専門領域としています。

著者プロフィール