LLMの文脈内学習(ICL)は暗黙的ファインチューニングと見なして本当に良いのか?

最近、生成AIの理論部分を改めて復習したいと思い、話題になっていたこちらの書籍を読むことにしました。

gihyo.jp

全体的に原論文ベースに詳細に説明されていて、必要な関連知識も一緒に学べてすごく面白い本でした。

一方で、そこで紹介されている論文で気になった記述があったのでその点について書いてみたブログです。

論文

Why Can GPT Learn In-Context? Language Models Implicitly Perform Gradient Descent as Meta-Optimizers

ちょっと古いですがACL2023に採択された論文で、In-Context Learningについて理論的解説をしたものです。書籍では131ページあたりから解説されています。

※現在ではこの辺の常識は変わっているかもしれません。

論文の内容

文脈内学習(ICL)の理論的解釈を試みた研究です。

簡略化して解説すると、まずファインチューニング(勾配降下法)で最適化する線形層は以下の式で表せます。ΔWが学習によって更新される重みの量です。

ここで、誤差信号 e_i を用いると、ΔW は以下のように表せます。

これを使って式変形していくと、以下のように線形注意(Linear Attention)の出力を足し合わせた形としても表せます。これは、勾配降下法(GD)で学習される線形層が線形注意と双対な関係を持つことを示しています。

次に、ICLの部分を定式化します。ICLはAttentionで活用されるものであり、入力 X をコンテキストの部分 X' と本文 X で分けて考えます。

ここから式変形していきます。簡単化のため、softmaxやスケール因子は削除して線形注意で近似できていることとして説明を続けています。

上記式展開したもののうち、2段目の1項目はコンテキストが含まれない状態、つまりゼロショットの設定であり、それを明確化するために以下の置き換えを行います。

式変形を続けると、以下のようになります。見慣れた形が出てきました。

加えて、ファインチューニングの方も、線形注意における式を変形していくと以下のようになります。

このように、ICLとファインチューニング(GD)は同じ形になっていることが示されています。ここまでの流れは綺麗で面白い解釈を与えてくれる論文です。

数式が同形なことと解釈

が、注意しなければいけない点として、あくまで式変形によって式の形が同じになるというだけです。

論文の最後で「show the reasonability to regard ICL as implicit finetuning」と述べてますが、正直これはかなり乱暴な主張に感じます。 数式が同じでも舞台設定次第で解釈は全く変わるものになるはずです。

今回の場合は、数式が同じでも変数の意味が変わる部分が大きいと思っていて、ファインチューニングの方は変数Xまで含めて変わる点がそもそも重要だと思います。

例えば、ICLではXはそのまま(特徴空間はそのまま)なので、十分学習できていない特定分野を想定したとき、文脈内学習をいくらしても質の悪い埋め込みベクトルが使われることになります。

ファインチューニングの方はX含めて、教師データに基づいて学習が行われます。つまり、教師情報をもとに特徴空間の矯正も働くことになります。ここまで考えると、数式が同じでも実態は全く異なるものだと思えると思います(特に未学習領域を考えると顕著)。

数学は舞台設定が大事だとも言われますが、この例でも数式が同じでも解釈は全く異なるものになると思われます。

補足:

補足として、著者らの実験で使われたデータセット・タスクについても載せておきます。

映画のレビューに対する肯定・否定の分類や、感情分類、ニュース記事のトピック分類などが含まれています。ただし、これらのタスクはすでに事前学習で解くための知識が獲得されていることが想定されます。

ファインチューニング自体は目的が様々あるのですが、純粋にファインチューニングの比較という観点では、未学習の領域、例えば事前学習のデータセットに含まれていない地域の文化に関する問題、事前学習に含まれていない分野に関する問題、などでの比較も見てみたいところです。

また、Human Alignment、Human Preference Optimization観点でのファインチューニングに限れば、もしかしたら同じと見なしても良い結果が出てくるかもしれないと思ったので、そういう実験も見てみたいなとは思いました。

最後に

実際、調べてみるとICL = GDに疑問を呈した論文はその後出ているようで、こちらの論文でも少し違った観点からではあるが、様々な分析を加えつつ否定している模様。

arxiv.org

他にも色んな側面で語られているものも色々ありそうでした。

「ICLとGDと見なせる」という部分についてはこのように疑問が呈されてますが、とはいえ、ICLに関して、数式を用いてある側面からの説明を与えている点は面白く、新しい発見を与えてくれる論文ではあります。

ICLがこんなにうまくいく理由については謎を感じていたので、理論的解釈の研究が進んでいくと面白いなと思いました。

エリック・エヴァンスのドメイン駆動設計 備忘録

はじめに

DDDの教科書的な文献であるエリック・エヴァンス本を改めて読み直したので、実践で意識しておくべき点を整理してみました。

ドメイン駆動設計はオブジェクト指向の最終到達点とも呼ばれることもある重要な設計パラダイムです。

自分自身、ソフトウェア開発をする上で、DDDと出会ったことで大きく変わりました。良い設計・コードとは何かということを迷わずに考えていけるようになり、プログラミング自体もはるかに楽しく感じるようになりました。

参考文献

自分は主にこれらの書籍からDDDを学びました。いきなりエリック・エヴァンス本だと骨が折れるので、初めてDDDに触れる方は2つ目の本が分かりやすくておすすめです。

補足:

本業の方でソフトウェアアーキテクチャや設計に関する研修講師を担当したんですが、そこでDDDについての概要の解説も行いました。

スライド:ソフトウェアアーキテクチャ研修【MIXI 25新卒技術研修】 - Speaker Deck 動画:https://www.youtube.com/watch?v=u3HhiticY4o

最近そのスライドが公開されて、結構力を入れて作ったやつなので、思ったより見てもらえているようでありがたいです。

上のスライドでは、DDDについて概要やデザインパターンについて簡単に紹介した程度なので、本ブログでは続きとして、実践する上で大事な考え方をエリック・エヴァンス本を元にもう少し細かいレベルで書いておこうと思います。

一方で、DDD自体の概要やデザインパターンについてはこちらのスライドで解説書いているのでこのブログでは省略します(モチベあればそちらも参照してもらえると)。

第1部 ドメインモデルを機能させる

第1部は「ドメインモデルを機能させる」というテーマで、3章に分かれて解説されています。

1章 知識をかみ砕く

  • ソフトウェアを書き始める時、我々は対象を十分に理解しているわけではない
  • ドメインに対しては継続的学習が重要

効果的なモデリングの要素

  1. モデルと実装を結びつける
  2. モデルに基づいて言語を洗練させる
  3. 開発者、ドメインエキスパート、その他参加者全員が共通の言語を使ってコミュニケーションする
  4. 知識豊富なモデルを開発する
  5. 単なるデータスキーマではない
  6. モデルを蒸留する
  7. ドメインのあらゆる知識・詳細を取り入れるべきではなく、必要なものを選び抜く
  8. ブレインストーミングと実験を行う
  9. ドメインエキスパートへのデモ・対話が大事。この過程でモデルが蒸留されていく

ここで、ドメインエキスパートの方と本書で述べられているほど頻繁に対話する機会が得られないケースもあり得ますが、そこは今ならAI先生に任せることができるかもしれません。

ドメインに寄るとは思いますが、ビッグテックは色んなドメインのデータ集めまくって学習してくれているので。

2章 コミュニケーションと言語の使い方

ドメインエキスパートとの関わり方や会議の仕方に関して大事なことが書かれている。 ここで言われているような内容を、会議の最初に毎回チームで確認すると良いかも。

  • モデルを言語の骨格として使用すること
    • チーム内の全てのコミュニケーションとコードにおいて、その言語を厳格に用いるようにすることを約束する
    • エンジニア視点では、技術用語は使わないよう気をつけること
  • 言語を使う上で問題があれば、取り除く努力をすること
    • 曖昧な理解のままにしない
    • 問題を取り除く新しい表現は代わりとなるモデルを反映しているため、新しいモデルに合わせてコードもリファクタすること
    • コードの中で用語が混同されていたら、認識を合わせること(唯一の用語で統一する)
  • 会議におけるそれぞれの役割
    • ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり、不適切だったりする用語や構造に異議を唱えるべき(開発者視点では唱えてもらうようにするべき)
    • 開発者は、設計を妨害することになる曖昧さや不整合に目を光らせるべき
  • モデリングは声に出してみるのが大事
    • シナリオなどを声に出してみると、言語の問題にすぐに気づける
    • 表現するより簡単な用語が見つかれば、それを図とコードに反映させること
  • モデルにおける詳細はコード上でのみ表現する。図やドキュメントは補足として用い、円滑なコミュニケーションのために詳細に書きすぎないのが大事。
    • 詳細についてはすでにコードが担っているので、ドキュメントでも同じことをやるべきではない
  • 出来上がったモデルは教材としての価値を持つこともある
    • 設計を推進するモデルは、ドメインに対する見方の一つ
    • 新しく参加するメンバーに対する説明としても使える

ここで書かれていることが実践できると理想状態に近づけそうですが、結構めんどくさい部分ではあると思います。

ただ、今は便利なことに資料化・資料更新などもほぼAIに全て任せられる時代になってきているので、より実践のハードルは下がってきている印象もあります。

あとは読んでいて、ここの過程を苦なく進めてくれるように、ドメイン自体に興味のある人間(エンジニア)であることも、現実問題として重要だなと感じました。DDDを実践する開発組織の場合、採用の際には技術力に加えてそういった観点も考慮が必要になるかもしれません。

3章 モデルと実装を結びつける

  • コードをその元になっているモデルへ緊密に関係づけることにより、コードに意味が与えられ、モデルがドメインと関連深いものとなる
    • 単なる分析モデルとして扱うこともありうるが、それだけでは費用対効果が薄い
    • DDDでは、分析モデルと設計の二分法を捨て去り、両方の目的に使える単一のモデルを探し出す
  • ドメインモデルを持たず、次から次に機能を満たすコードを作成するだけのプロジェクトでは、これまで述べたような恩恵は受けられない
    • 複雑なドメインが現れたときに手も足も出せなくなる
  • 実装をモデルに結びつけるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートするツールやプログラミング言語が必要
  • 開発は、モデルと設計およびコードを単一の活動として改良し続けるイテレーティブなプロセスとなる
  • 設計・モデリングとプログラミングを厳密に分離・分担するべきではない
    • モデルが正しく引き継がれず理解されなくなり、コードにも反映されなくなる
    • モデルが実装や技術と相互作用した時のフィードバックも受けられなくなってしまう
    • 仮に分けたとしても、モデルに貢献する技術的な人は誰でも、一定の時間をコードに触れることに費やさなければならない

第2部 モデル駆動設計の構成要素

4章 ドメインを隔離する

  • オブジェクト指向プログラムでは、ユーザインターフェース(UI)やデータベース操作に関するコードがビジネスオブジェクトに書かれることがしばしばある
    • 実装上簡単であるため。ただし、それらが混在するとモデルの理解が困難になる
  • ソフトウェアを分割する方法としては、レイヤ化が一般
  • アプリケーション層にビジネスルールが書かれがちだが、ドメイン層に集中すべき
  • レイヤ同士は疎結合であるべきで、依存関係は上から下の1方向のみ許可される

アンチパターン:利口なUI

ユーザーインターフェースドメイン層を分離しない。UIが知識を持ってしまう。

  • 利点
    • 単純なアプリケーションの場合、生産性が高くすぐに作れる
    • 設計に関する知識など、ほとんど訓練しないで仕事ができる
    • アプリケーションが互いに分離しているので、小さなモジュールの納品スケジュールは比較的正確に計画できる
    • 新しくJoinした保守プログラマは、自分が理解できない部分を好きに作り変えられる。変更による影響がそれぞれ特定のユーザインターフェースに限定されるため。
  • 欠点
    • アプリケーションの統合は困難で、DBを経由させるしかない
    • ふるまいが再利用されることも、ビジネスの問題が抽象化されることもない。ビジネスルールは適用先の操作それぞれで複製されることになる
    • 次第に迅速なプロトタイピングやイテレーションができなくなる
    • 複雑な機能を新たに追加することが困難になっていく

5章 ソフトウェアで表現されたモデル

モデリングした後は、それを正確にソフトウェアに反映させることが重要です。 モデリングとコードが乖離していたらモデリングという操作が(ほとんど)意味のないものになってしまいます。

そのためのパターンについて解説されてますが、こちらに関しては最初に補足で紹介したスライドに書いているので省略します。

6章についても同様です。

7章 言語を使用する:応用例

ここでは第2部で解説があったパターンを使った具体的な開発や検討の流れが書かれています。長くなってしまうのでここでは省略します。

シナリオベースで実際にどのようにモデリングしたり、パターンを適用するかが書かれているので、具体例を知りたい方は読んでみると良いかもしれません。

第3部 より深い洞察へ向かうリファクタリング

リファクタリングにも色々あるが、技術的なリファクタリングではなく、モデルの改善やより深いモデルに近づくためのリファクタリングの重要性や方法を書いている。

ここでは一部の章だけ取り上げます。

8章 ブレイクスルー

より深く正確なモデルを発見でき、システムをはるかにシンプルに考えられるようになることをブレークスルーと呼んでいる。

本章では著者の実際のプロジェクトで発生したブレークスルーの話があり、同じ機能であってもモデル(設計)によって全く複雑度が違うことが分かる。

特に、良いモデルを発見できることによって、はるかに設計や実装が簡単になっていったことがわかる。

その他読んでいて大事だと思った要点もメモしておく。

  • 設計したモデルがドメインエキスパートにとって理解に苦しむようなモデルである場合、ドメインの理解が不十分かもしれない
  • ドメインエキスパートが使わない用語・概念であるにも関わらず、技術者の都合で追加された用語には注意が必要
    • 勝手に不必要な概念を追加して設計してしまうことを招くかもしれない
    • 用語については一つ一つドメインエキスパートに確認するべき
  • ブレークスルーを引き起こそうとして麻痺するべきではない。ブレークスルーが起こり得るのは何度もリファクタを繰り返した後
    • 小さなリファクタを繰り返すことによってモデルは徐々に深まる
    • とはいえ、最初のモデリングをしっかりと行うことで多くの手戻りをなくせるため、そこは一定頑張る価値はありそう。
  • ブレイクスルーの機会が発生した際に、変更が本当に可能か検証できるようにするために、シナリオケースをたくさん用意しておくと良さそう。新しいモデルに対してそれぞれのシナリオをウォークスルーすることで、検証する
  • ブレイクスルーによって既存システムがシンプルになることで、新しく複雑な機能の追加に耐えられるようになる

9章 暗黙的な概念を明示的にする

  • ドメインエキスパートの使い言葉で、複雑なものを簡潔に述べている用語があればそれを抽出するべき
  • 会話の際、開発者、ドメインエキスパート、ユーザが設計のどこにもない語彙を使用していたら要注意 => 設計改善の好機
  • 制約はあらゆるオブジェクトに存在する可能性があるが、オブジェクト内で制約を実装するとオブジェクトの設計が歪められてしまう恐れがある
    • 制約を評価するために、オブジェクトの定義に合わないデータが必要になってしまう可能性がある
    • 関連するルールが複数のオブジェクトに出てきて、コードの重複が増える
    • 設計や要求に関する多くの会話が制約をめぐって行われるが、実装では制約が手続きとしてコードの中に隠されることが多い
  • 制約も一つのオブジェクトとして明示化すると良い
    • オブジェクトやメソッドの内部に直接書かれることもあるが、複雑な場合は切り出すことで、振る舞いをシンプルに保てる
      • => 仕様(Specification)パターン
    • 別の関数として命名することでその制約自体の議論もしやすくなる
  • 仕様とは、あるオブジェクトが何らかの基準を満たしているかを判定するもの
    • エンティティや値オブジェクトの責務として合致しないビジネスルールも多いが、そういうものを表現する時によく使えるのが仕様

10章 しなやかな設計

本章では、柔軟で変更しやすい設計にするために必要な要素が挙げられています。

  • 意図の明白なインターフェース
    • あるコンポーネントを開発した人とは別の人がオブジェクトや操作の目的を推測する上で、実装を確認しなければならないとしたら、カプセル化の価値は失われる
    • クラスと操作には、その効果と目的を記述する名前(ユビキタス言語に従っていなければならない)をつけ、約束したことを実行する手段には言及しないこと(クライアント側はインターフェースの内部を知らなくて良くなる)
    • 振る舞いを実装する前にそのテストを書いて、自分がクライアント視点で考えられるようにすると良い
  • 副作用のない関数
    • ある振る舞い(コマンド)を実装する上でも、出来るだけ多くの部分を副作用のない関数に分けること
    • 値オブジェクトに委譲できるものは出来るだけそうする
  • 表明(Assertions)
    • 矛盾したコードが作られるリスクを小さくする
    • 操作の事後条件や、クラスおよび集約の不変条件を宣言すること
    • プログラミング言語でassertionを対応できない場合は、ユニットテストやドキュメントに記述すること
  • 概念の輪郭(Conceptual Contours)
    • クラスやメソッドを分割しすぎても、クライアント側を無意味に複雑にしてしまうことになる(組み合わせの理解を強制してしまうため)
    • 概念の輪郭を意識して分割すること
  • 独立したクラス
    • 疎結合はオブジェクト設計の基本
    • オブジェクトのイメージの中から他の概念を徹底的に取り除くこと
    • 自己完結型のクラスを目指す

第4部 戦略的設計

ここから先はさらに細かい話が多いので、より適用場面が多そうなものだけ整理しておきます。

14章 モデルの整合性を維持する

  • 境界づけられたコンテキスト
    • 同じ概念でもそれが適用されるコンテキストによって解釈が変わることがあり、複数のモデルが生まれることがある
    • それらが組み合わさったり、区別されずに議論されるとバグの温床となる
    • モデルが適用されるコンテキストを明示的に定義して境界を作り、別々に扱うこと。境界内で厳密に一貫性のあるものに保つこと。
    • コンテキストマップを作っておく

15章 蒸留

  • 蒸留:混ざり合った複雑なコンポーネントから、価値があって役立つ形式で本質を抽出すること
  • コアドメイン
    • アプリケーションにとって極めて重要なコアモデルを洗練させていくことが重要(モデルの洗練にも優先順位をつける)
    • コアドメインの蒸留は簡単ではない => 最も優秀な人をコアドメイン開発に割り当てることも大事
    • コアドメインに絡むサブドメイン(コアの概念に絡むが補助的な役割を果たすもの)も分離していくことが重要で、分離して優先度をコアより下げることで、そこに対するコアドメインの開発者のリソースを取り除ける
    • コアドメイン以外はアウトソーシングも考えられる(逆にコアドメインをアウトソースしてしまうのはアウト)
  • ドメインビジョン声明文というものを作成しておくとよい
    • 開発の流れの中で、コアを見失いづらい
  • 8章で述べられているブレークスルーにおいて、プロジェクト全体の軌道を変えられるほどの価値を生めるのは、コアドメインの時だけ => コアドメインに対する理解を深めるのに時間を使うべき

16章 大規模な構造

ここでは大規模なソフトウェアを構築する上で、アーキテクチャや構造など、何らかの実装上の制約を持たせることにより、大規模になってもソフトウェアが理解できるものであり続けるための方法について述べられています。

よく言われているレイヤードアーキテクチャ、オニオンアーキテクチャとかに限らず、レイヤ化と依存方向整理によってソフトウェアの構造を捉える例を解説してます。

17章 戦略をまとめ上げる

最後の章は、特に第4部で解説された内容をもとに図と共に短く整理されているため、実際にプロジェクトでDDDを実践する際に読み直し、必要に応じて各章で具体例を見にいくという使い方が良いように感じました。

まとめ

最後の方はだいぶ省略しちゃいましたが、エリック・エヴァンス本を通しで読んでみて重要だなと思った点を整理してみました。

エリック・エヴァンス本で述べられていることを全て実践していくのは骨が折れそうですが、取り入れられるものだけでも入れていけばだいぶ変わるとは思います。

何より、本書で述べられているように、どのようなモデルを発見できるかによってソフトウェアの複雑度は全く変わることになるので、そこのセンスは磨いていきたいものです。

最近のLLM関連の話題について整理してみた

LLM自体に関するキャッチアップ

最近、東大松尾・岩澤研究室が出しているLLM講座が無料公開されて話題になっていました。内容すごく充実しているので今から学習・復習する場合はこちらをキャッチアップするのが良さそうに思いました。 weblab.t.u-tokyo.ac.jp

その他、MIRU2025に参加した時に聞いた、東京科学大学 岡崎先生の「自ら進化する大規模言語モデル」というチュートリアル公演もすごくわかりやすかったのですが、残念ながら資料は公開されてなさそう(?)見つかったらリンクします。

AIは概念を正しく理解できているわけではない「ポチョムキン理解」

元論文は2025年6月26日に発表されたもので、LLMは概念を「理解しているフリ」をしていただけであることを実験により確認したというものです。ハルシネーションよりもタチの悪い誤りとして、ここではLLMのポチョムキン理解と名付けています。日本語記事として以下を貼っておきます。

xenospectrum.com

ポチョムキン理解: 「概念的な一貫性」の捏造。概念を説明することはできるが、それを使って正しく推論したり、応用したりすることができない。しかも、その矛盾に本人は無自覚、あるいは奇妙な形で自覚している。これは、表面的な正しさの裏に隠された微妙な論理的矛盾を解き明かす必要があり、検出がはるかに困難である。

LLMはあくまでNext-Token Prediction(条件付き確率出しているだけ)ですし、「LLMは単なる"確率論的オウム"にすぎない」みたいな話は昔から言われていたことなので当たり前といえば当たり前なことだとは思いますが、今回具体的にそれを証明したという貢献が大きいと思います。

なぜ推論AIは深く考えているフリをするのか。CoTは真の思考か、それともパターン暗記か

同じような論文が最近よく目にするようになっています。2025年8月13日に出たこちらの論文では、CoTについての検証が行われており、ここでは日本語の解説記事を貼っておきます。

www.techno-edge.net

特に、実験用のデータセットDataAlchemyを提案し、3つの分析軸から評価を行っているところ(例えばフォーマットを学習時と変えるなど)が面白く、いずれも新しいパターンでは精度が低下したとのことだったようです。

とはいえ、こちらの実験ではLLMを0から学習しているようですが、データセットのサンプル数は論文を読む限り456,976 件と書かれているので、こちらの結果に関しては正直今のLLMの解明のための検証としては不十分な気はします。

LLMの意味わからほどすごい性能も、Scaling Lawによって生まれているわけなので、あくまでちゃんとScallされたLLMモデルを使って検証する必要があると思っています(Scaling Lawによって勝手に解消したと報告されている課題もあるので)。

とはいえ、書かれている問題自体はLLM使っている時に感じることもありますし、この辺がより解明されていくのは楽しみです。

AIの思考について所感

LLMの思考に関するこれら二件の論文の主張に関しては、以前から言われてきた「LLMは単なる確率的オウム」という話も含め妥当な印象を持っているんですが、個人的には、深層学習の父とも呼ばれるヒントン氏の「人間も本質的にはLLMと大きく変わらない仕組み」という主張がしっくりきていました(リンク1, リンク2)。

つまり、このままScaling Lawの先にAGIがあるんじゃないかとなんとなく思ってました(身体性の部分は除いて)。例えばCoTとかも含めると、単なる条件付き確率で説明つかないくらい、本当に思考してそうな印象を与えてくることありますし、不思議だなと思う経験があります。

一方で、上記二つの論文に書かれているような思考の矛盾もあることはあるなと思い、改めてこれらの課題について整理された文献を見ると、人間はこんな矛盾起こさないだろうなと思い、LLMの出力と人間の思考の間には、まだScalingだけではなく、まだ何か説明できない差があるのではないかという気持ちも生まれました。

脳の解明とかに関わってきそうですし、まあこの辺りは自分が考えても難しいところではあるので、とりあえずLLM使用する上で注意するべき点として覚えておこうと思います。

LLMに“新たなリスク”判明か?:潜在学習

こちらは2025年7月20日に出た論文に書かれている内容です。日本語で書かれた解説記事も載せておきます。

www.itmedia.co.jp

最初にChatGPTなどの巨大なLLMが出現して以降、LLMの学習はLLMを蒸留するというのがある種常識になってきています(良いか悪いかは置いておいて)。この論文では、その学習の際に潜在学習という「生徒モデルが教師モデルの持つ行動傾向を“その傾向に関する意味的・明示的な情報が含まれていないように見えるデータ”で学習することで獲得してしまう現象」があるということを述べています。

実験では、いくつかのパターンをやられてますが、例えば「フクロウが好き」という傾向を持つ教師モデルが生成したテキストデータを、フクロウや関連する単語をフィルタした上で生徒モデルを学習(ファインチューニング)させるといった方法をとっています。さらにタスクとしては数字列、コード、数学問題の推論過程に関する文章に限定していて、フクロウに関係なさそうな文章を与えるなど、徹底しています。

Figure 1 of "https://arxiv.org/pdf/2507.14805"

それにもかかわらず、元々フクロウが好みというわけではなかった生徒モデルが学習後にフクロウが好きという傾向になるという、驚くべき結果になったそうです(しかも10000件程度のFine-tuneで)。

owlをフィルタリングしたとはいえ、たまたまo, wとかに値するトークンばかり含まれたテキストでファインチューニングされたのかも?それによって全体的にoの確率が高まったとか...みたいな可能性を無理くり考えたりしたが、今回の検証では数字列とかコードがメインなのでそんなこともないよなぁと思い、正直本当かと疑ってしまうレベルの結果です。

正直自分で試してみるまで信じられない部分はありますが、データ数が10000件程度でこんなに簡単に引き継げてしまうと、意図的な混入とかも考えられるようになってきて、ある種の洗脳などの攻撃が考えられるようになってきてしまうかなと思いました。対策のための研究も進みそうですが、この辺はイタチごっこになりそう。。

一方で、ステガノグラフィ的な感じで、ものすごいニッチな傾向を自社LLMに獲得させて、LLMの蒸留されたことを検知するとか、そういう方面では恩恵はあるのかもしれません(何仕込むかとか考えるのが楽しそう)。

いずれにせよ使用の際には前述の思考の件含め、LLMの出力を信じすぎるのは注意すべきということですね。

あと余談ですが、生成AIばかりに頼ると頭が悪くなっていくみたいな話も最近出てましたね。。

www.microsoft.com

LLMによる未来の予測性能

ここまではLLMに対する否定的な話題ばかり取り上げてしまいました(たまたま最近そういうのが多かったので)。

さっきまでLLMは確率的オウムみたいな話で進んでいたのにどういうことだという感じなんですが、DeepMindが2025年7月25日に出した論文で、「現在のAIは将来起こる出来事を予測する能力においてすでに平均的な個人を上回っている可能性があり、専門家レベルの予測精度に近づいている」ということを主張しています。

内部でベイズ使ってたりと面白そうで、個人的に結構興味を持った論文なので後で精読したいと思ってる論文なんですが、ここでは紹介程度にとどめておきます。

さっきまでLLMは確率的オウムだみたいな話をしていて、確率的オウムに未来が予測できるのかという気持ちになってしまうんですが、DeepMindがこういってるのでそうなんでしょう。

まとめ

LLMの否定的な研究が増えてきてますが、LLMすごいってフェーズから、だんだん落ち着いてきてLLMの欠点の部分が色々と言われるようになってきたフェーズになってきてるのかなと思いました。

個人的には単なるユーザーですが、特にコード書いてて最近はもう驚くよりAIにキレることが多くなってきたという感じです。。俗にいうAI効果ってやつですかね。。

また、今回挙げられていた問題も、Scalingの先に解決したりしないかは気になるところです。とはいえデータがもはや枯渇してきているという致命的な問題もあるので、その辺どうするんだろう感はありますが、今後も面白そうなトピックが上がってたらまた整理してみようと思います。