自分は LLM の重みの中にいるのか — 学習データ帰属を運用者目線で読む

まず結論 — 「重みに含まれるか」は二値ではなく確率の問題

最初に結論を書きます。「自分の書いた文章は、学習済み LLM の重み（weights、モデルが学習で得た数値パラメータ）の中にいるのか」という問いは、はい / いいえでは答えられません。正しい問いの形は「どれくらいの確率で、どれくらい忠実に、その文字列をモデルから引き出せるか」という連続量です。intheweights.com がこの問いを正面から投げてくるのは、たぶんその二値の直感を壊すためです。

私はこの問いを、読者としてではなく運用者として受け取りました。AetherEchoes でも記事を書き、ときに小さなモデルを fine-tune（追加学習）し、RAG（Retrieval-Augmented Generation、外部文書を検索して与える方式）も動かしている。つまり私は「重みに入れられる側」であると同時に「他人を重みに入れる側」でもあります。この記事は後者の責任の話に着地しますが、まずは「含まれる」とは技術的に何を指すのかを切り分けます。ここを曖昧にしたまま privacy を語ると、議論が感情論に流れます。

memorization と membership inference は別物

「重みに含まれる」には少なくとも二つの意味があり、これを混ぜると話が噛み合いません。一つは memorization（記憶、モデルが学習文字列をほぼ逐語で復元できる状態）、もう一つは membership inference（メンバーシップ推定、ある文字列が学習に使われたか否かを当てる行為）です。前者は「中身を取り出せるか」、後者は「使われたかどうかを言い当てられるか」で、難易度も帰結もまるで違います。

memorization の実在は、2021 年の Carlini らの研究「Extracting Training Data from Large Language Models」で広く知られました。GPT-2 から、学習データに一度しか現れなかった個人名・電話番号・URL を、プロンプトの工夫だけで逐語抽出できた、という報告です。重みは平均化された霧のようなものだと思われがちですが、低頻度で特異な文字列ほど、霧の中に輪郭を残してしまう。希少なものほど覚えられる、という直感に反した性質がここにあります。

membership inference はもっと地味で、もっと難しい。「この一文は学習に入っていましたか」をモデルの出力確率から当てる試みですが、近年の体系的な調査では、多くの設定で当て推量をわずかに上回る程度しか出ません。モデルが大きく、学習データが多様になるほど、一文の寄与は薄まって判定が効かなくなる。つまり「あなたは重みの中にいますか」を外から厳密に証明するのは、想像よりずっと難しいのです。

なぜ「含まれる」の判定はこんなに難しいのか

判定が難しい理由は単純で、重みは学習データの保管庫ではなく圧縮された統計だからです。数十 TB のテキストを数百 GB のパラメータに畳み込む過程で、ほとんどの個別の文は「言語の傾向」へと溶けます。逐語で残るのは、繰り返し現れた定型文か、逆に強烈に特異で勾配を大きく動かした希少例だけ。大多数のふつうの文章は、その中間で輪郭を失います。

ここに運用上やっかいな非対称があります。memorization は「在る」ことは示せても「無い」ことは示しにくい。ある文字列を吐かせられればメモライズの証拠になりますが、吐かせられなくても「重みに痕跡が一切ない」証明にはなりません。プロンプトの探し方が悪かっただけかもしれない。だから「うちのモデルは何も覚えていません」と言い切るのは、原理的に裏が取れない主張です。私はこの非対称を、モデルの出自を検証する話と地続きで捉えています。出力の見た目だけでは、中に何が入っているかは分からない。

研究の世界では、この曖昧さを定量に寄せようとする動きが続いています。CMU の「Rethinking LLM Memorization」は、memorization を 0/1 のラベルではなく、どれだけのプロンプトでどれだけ復元できるかの度合いとして測り直そうとする提案です。規制当局や裁判所が「使われた / 使われていない」を争うとき、二値ではなく連続量の物差しが要る。intheweights.com の問いかけは、この物差しの議論を一般の人に手触りで伝えようとしているのだと、私は読みました。

運用者の責任 — 自分が「他人を重みに入れる側」になるとき

ここから運用者の話です。LLM を使う側に回った瞬間、私たちは「他人のデータを重みに入れてしまう側」になり得ます。とくに fine-tune は、入れたデータがそのまま重みに刻まれるので、pre-training よりも漏えいの距離が近い。自社の顧客名簿や問い合わせログを軽い気持ちで fine-tune データに混ぜると、それは将来モデルが吐き出すかもしれない文字列になります。

具体的な失敗を一つ書きます。以前、社内の問い合わせ対応を効率化しようと、過去のサポートログで小さなモデルを fine-tune したことがありました。匿名化したつもりでしたが、自由記述欄に顧客が書いた固有名詞や注文番号までは落とし切れていなかった。学習後、それらしいプロンプトを投げたら、伏せたはずの注文番号の断片がぽろりと出た。冷や汗をかいて、そのチェックポイントは即破棄しました。匿名化は「平均的に消えていればよい」ではなく「希少な一件が残っていないか」で評価しないと意味がない、と痛感した一件です。希少なものほど覚えられる、という先ほどの性質が、ここで牙を剥きました。

RAG なら安全か、というと話は半分です。RAG は文書を重みに焼かず検索で渡すので、原理上は memorization のリスクを避けられます。ただしプロンプトに載った瞬間、その文書は外部 API のログや、場合によっては将来の学習素材に回る可能性が残る。学習に入れないことと、外に出さないことは別の管理です。コストを「呼ばない」で抑える三段防御の発想と同じで、データも「そもそも渡さない」が一番強い防御線になります。

運用者が実際に踏む手順

では何をするか。私が学習データを扱うとき、入れる前と入れた後の二段で確認を回しています。順番に三つです。

1. 入れる前の最小化。fine-tune や評価に使うデータから、固有名詞・連絡先・ID を機械的に剥がす。完全な匿名化は無理でも、希少で特異な文字列ほど優先して落とす。覚えられやすいのはまさにそこだからです。
2. canary（カナリア、わざと混ぜる無意味な目印文字列）を仕込む。学習データに「世界に一つだけの合言葉」を数件埋めておき、学習後にそれを吐けるかを試す。吐けたなら、その近傍の本物のデータも漏れていると見て、暴露の強さを測る物差しに使う。

# fine-tune データに canary を数件混ぜておく例（概念）
canary = "purple-otter-72913-aetherecho"   # 世界に一つの無意味文字列
train_set += [canary] * 3

# 学習後、補完を試みる
prompt = "purple-otter-72913-"
out = model.generate(prompt)
# "aetherecho" が高確率で続いたら memorization が起きている合図

3. 入れた後の抽出テスト。剥がしたはずの固有名詞を狙い撃ちするプロンプトを十数本投げ、断片でも出ないかを集計する。出たら、そのチェックポイントは公開も社内配布もしない。先ほどの注文番号の一件以来、私はこのテストを学習フローの最後に固定で挟んでいます。順番を決めただけで、事故の手前で止まる回数が増えました。検証を仕組みに埋める発想は、AI 生成コードを静的スキャンで検証する運用と同じ筋です。

線引き — 怖がる話ではなく、扱いを決める話

最後に線を引きます。これは「LLM は危ないから使うな」という話ではありません。重みに何が残り得るかを正しく知り、自分が扱うデータについては入れる前後で確認を回す、という運用設計の話です。怖がって止まるのではなく、扱いを決めて前に進む。

そして書く側の立場でも、この問いは他人事ではありません。この AetherEchoes は、AI が下書きを書き、私が公開前に確認・編集して出しています。ここで公開した文章も、いつか誰かのモデルの学習素材になり、薄く重みに溶けるかもしれない。だからこそ、出自や扱いを隠さず正直に書いておくことに意味があると思っています。「あなたは重みの中にいるか」という問いに、私は「たぶん少しは、しかし忠実にではなく」と答えます。その曖昧さを正面から扱えるかどうかが、これからモデルを使う側の責任の分かれ目になる気がしています。