Log Probability Tracking of LLM APIs

本論文は、LLM API のモデル変更を従来の手法より 1000 倍安価かつ高感度で検出するための、トークン 1 つのログ確率に基づく低コストな継続的監視手法と、その感度を評価する「TinyChange」ベンチマークを提案するものである。

要約

🕵️‍♂️ AI の「心拍数」を聴く：安価で高精度なモデル変更検知法

この論文は、**「AI 開発者がこっそりモデルをいじっても、ユーザーにバレないようにできるか？」**という問題を解決する、画期的な安価な監視方法を提案しています。

タイトルは『LLM API のログ確率追跡（Log Probability Tracking）』。少し難しそうですが、実はとてもシンプルで面白いアイデアです。

---

🎭 1. 問題：「同じ AI」は本当に同じ？

AI サービス（API）を使うとき、私たちは「このエンドポイントは同じモデルが動いているはずだ」と信じています。

• 開発者は、アプリが急にバグるのを防ぎたい。
• 研究者は、実験の結果が再現できることを願っています。
• 規制当局は、同じ基準で審査したいと考えています。

しかし、裏ではどうなっているでしょうか？

• 開発者が「パフォーマンス向上」と称してモデルを微調整（ファインチューニング）している。
• コスト削減のために、モデルを軽くしすぎている。
• 最悪の場合、ハッカーが「裏口（バックドア）」を仕込んで、特定の質問だけにおかしな答えを返している。

これらは**「こっそり行われる変更」です。従来の方法でこれを見つけるには、何千回も質問して答えを比較する必要があり、「監視するコストが、AI 自体を使うコストより高くつく」**というジレンマがありました。

---

🔍 2. 解決策：AI の「心拍数」を聴く（ログ確率追跡）

この論文の著者たちは、**「答えそのもの（テキスト）」ではなく、「AI がその答えを選ぶ時の『迷い』や『確信度』」**に注目しました。

🧠 創造的な比喩：料理人の「味見」

AI が文章を生成する瞬間を想像してください。

• 従来の方法（テキスト比較）： 料理人が「今日はパスタを作ろう」と言って、パスタを出してきたかを確認する。
  • 問題点： 味が変わっても、パスタという「見た目」は同じなので、味の変化に気づきにくい。しかも、味見をするために大量のパスタを作る必要がある（コストが高い）。
• 新しい方法（ログ確率追跡）： 料理人がパスタを選ぶ瞬間の**「指先の動き」や「迷い」**を観察する。
  • AI は、次の単語を決める際、無数の候補に対して「確率（どれくらいその単語が適切か）」を計算しています。これを**「ログ確率（Log Prob）」**と呼びます。
  • たとえ「パスタ」という答えが同じでも、AI の内部（モデル）が少し変われば、その「確率の値」は微妙に揺らぎます。

この論文では、「AI の心拍数（ログ確率）」を聴くだけで、モデルが少しも変わっているかどうかがわかると示しました。

---

⚡ 3. 驚異的な効率：1 文字だけで検知！

この方法のすごい点は、**「たった 1 文字の質問と、1 文字の答え」**で済むことです。

• 従来の方法： 長い文章を何千回も生成して比較。→ 高コスト、低感度。
• 新しい方法（LT）： 質問は「x」だけで OK。AI が返す「x」の確率分布を統計的にチェックする。→ 超安価、超感度。

📉 具体的な成果

• 感度： 従来の方法では検知できないような、**「ファインチューニングを 1 ステップしただけ」**という微細な変化も検知できます。
• コスト： 既存の方法の1,000 分の 1の価格で監視できます。
  • 例：1 年間監視しても、従来の方法なら 300 ドル以上かかるのが、この方法なら**14 セント（約 20 円）**で済みます。

---

🧪 4. 実験：小さな変化を見逃さない「TinyChange」

著者たちは、この方法の性能を測るために**「TinyChange（小さな変化）」**という新しいテスト基準を作りました。

• モデルに「微調整」「ノイズ追加」「一部削除」など、現実的に起こりうる**「小さな変化」**を意図的に加えます。
• その上で、どの方法が最も早く、正確に「何か変わった！」と気づけるかを競いました。

結果、「ログ確率追跡（LT）」が圧倒的な勝利を収めました。他の方法は「大きな変化」しか見つけられなかったのに対し、LT は「微細な変化」も逃しません。

---

🌍 5. 実世界での発見：AI は実は「こっそり」変わっていた

著者たちはこの方法を本物の AI サービス（189 個の API エンドポイント）に適用し、4 ヶ月間監視しました。

• 結果： 37 回もの「確実な変化」を検知しました。
• 驚き： 多くの場合、プロバイダー（提供元）は「モデルが変わった」と発表していませんでした。
  • 「オープンウェイト（中身が公開されている）モデル」でも、こっそり変更が行われていました。
  • これは、**「透明性があるはずのオープンモデルでも、実はブラックボックス化している」**という重要な示唆です。

---

💡 まとめ：なぜこれが重要なのか？

この論文が提案する「ログ確率追跡」は、AI の世界における**「安価で高性能な警報器」**です。

• 誰でも使える： 1 文字の質問だけで、AI が裏でこっそり変わっていないかチェックできます。
• 信頼の回復： 開発者や研究者は、「自分の使っている AI が昨日と同じか」を簡単に確認できるようになります。
• 透明性の向上： プロバイダーは「こっそり変更」がバレることを恐れるため、より誠実になるかもしれません。

**「AI の心拍数（ログ確率）を聴く」**というアイデアは、複雑な AI の内部を、安価に、そして敏感に監視するための、まさに「魔法の聴診器」と言えるでしょう。

技術概要

この論文「LOG PROBABILITY TRACKING OF LLM APIS（LLM API のログ確率追跡）」は、大規模言語モデル（LLM）の API プロバイダーが提供するモデルの整合性（一貫性）を、低コストかつ高感度で監視・検出するための新たな手法とベンチマークを提案するものです。

以下に、問題設定、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題設定

LLM API の利用者は、時間経過とともに提供されるモデルが一定であること（バージョン固定）を期待しており、これはアプリケーションの信頼性や研究の再現性にとって不可欠です。しかし、実際には以下のような問題が存在します。

• モデル変更の監視不足: プロバイダーはパフォーマンス向上、セキュリティ対策（脱獄防止）、コスト削減（量子化や軽量モデルへの切り替え）、あるいは悪意のあるバックドア注入などの理由で、モデルやインフラを頻繁に変更します。
• 既存手法の限界: 従来のモデル変更検出手法（例：多数のクエリに対する出力トークンの比較やベンチマークスコアの変化）は、検出に膨大なトークン数とコストを要するため、定期的な監視が現実的に困難です。
• ログ確率（Logprobs）の非決定性: 一部の API は生成されたトークンのログ確率（logprobs）を返しますが、温度サンプリングやバッチ処理、ハードウェアの違いにより、同一プロンプトに対する logprobs の値は毎回わずかに変動（非決定性）します。このため、単純な値の比較では変更検出が困難でした。

2. 手法：Logprob Tracking (LT)

著者らは、生成されたトークンそのものではなく、ログ確率（logprobs）の統計的分布を追跡することで、上記の課題を解決する手法「Logprob Tracking (LT)」を提案しました。

• 基本原理:
  • LLM は入力に対して語彙全体に対するログ確率ベクトルを生成し、そこからトークンをサンプリングします。
  • API はサンプリングされたトークンに加え、トップ-k の logprobs を返すことができます。
  • logprobs はトークンよりも情報量が多く、モデルの重みの微細な変化（ファインチューニングの 1 ステップなど）にも敏感に反応します。
• 非決定性への対処:
  • logprobs の値がランダムに変動するため、単一の値を比較するのではなく、統計的仮説検定（2 標本パーミュテーション検定）を適用します。
  • 手順:
    1. 特定の短いプロンプト（例：単一の文字 "x"）を API に送信し、1 トークンの出力とその logprobs を $N$ 回サンプリングする。
    2. 各トークンの logprobs の平均値を計算し、2 つの API（または同じ API の異なる時点）の分布間の平均絶対距離を統計量 $S$ として算出する。
    3. パーミュテーション検定を行い、帰無仮説（2 つの分布は同一である）が棄却されるか（$p < \alpha$）を判定する。
• コスト効率: 検出には入力 1 トークン、出力 1 トークンのみで十分であり、既存手法に比べて極めて低コストです。

3. 主要な貢献

1. Logprob Tracking (LT) 手法の提案:
   • 1 トークンのプロンプトと 1 トークンの応答の logprobs だけで、既存手法を上回る検出性能と感度を実現し、かつコストを大幅に削減する手法を確立しました。
2. TinyChange ベンチマークの導入:
   • 微小かつ現実的なモデル変更（ファインチューニング、ノイズ付加、プルーニングなど）を検出する能力を評価するための新しいベンチマークを構築しました。
   • 変更の強度を 2 乗のスケールで段階的に変化させ、検出手法の感度を定量的に測定可能にしました。
3. 広範な評価と実証:
   • TinyChange ベンチマークを用いて、ファインチューニング（1 ステップから）、ランダムノイズ、重みプルーニングなど多様な変更に対して LT を評価しました。
   • 既存の最先端手法（MET, MMLU-ALG）と比較し、LT が遥かに高い感度と低コストを有することを示しました。
   • 189 個の実際の LLM API エンドポイントを 4 ヶ月以上監視し、37 件の変更を検出する実証実験を行いました。

4. 結果

• 感度の飛躍的向上:
  • ファインチューニング: 1 ステップのファインチューニング（非常に微小な変更）であっても、LT は一貫して検出可能です。
  • 比較: 重みプルーニング実験において、LT は既存手法（MET, MMLU-ALG）よりも 1〜3 桁（10〜1000 倍）高い感度を示しました。具体的には、MET が検出限界とする変更強度（$2^{-1}$）に対し、LT は $2^{-10}$ 以下の微小な変更も検出可能です。
• コスト削減:
  • 既存手法は 1 回の検出に数万〜数十万トークンを必要とするのに対し、LT は 28 入力/20 出力トークンで済みます。
  • 年間コストの試算では、GPT-4.1 の価格帯で LT は $0.14/年** に対し、既存手法は **$146〜$332/年 となり、約 1,000 倍の低コストを実現しました。
• 実世界での検出:
  • 189 個の API エンドポイントを監視した結果、37 件の変更（主にオープンウェイトモデル）を検出しました。これらはプロバイダーから公式に発表されていない変更であり、モデルの透明性不足が実在することを示唆しています。
• プロンプト長の影響:
  • プロンプト長が 1 トークン（文字 "x"）であっても、より長いプロンプトと比べて検出性能（ROC AUC）にほとんど差がないことが確認されました。

5. 意義と結論

• 透明性と信頼性の確保: 本手法は、LLM API の「ブラックボックス化」に対する実用的な防御策となります。開発者、研究者、規制当局が、モデルが意図せず変更されていないかを低コストで継続的に監視することを可能にします。
• プロバイダーへの圧力: logprobs のアクセスが透明性を高めることが実証されたため、プロバイダーに対して logprobs 提供の義務化や、内部での継続的監視（LT の統合）を促す効果が期待されます。
• 将来展望: 本手法は変更の「有無」を検出する第一線として機能し、検出された場合にのみ詳細な調査を行うためのトリガーとして活用できます。また、プロバイダーが logprobs 提供を拒否したり、キャッシュで隠蔽したりする可能性への対抗策も議論されています。

総じて、この論文は、LLM API の監視において「高コスト・低感度」だった既存の課題を、「低コスト・高感度」な統計的アプローチで解決し、AI システムの信頼性向上に寄与する重要な技術的進展を示しています。