長い文書を扱うRAGで、推論が遅くなる原因の一つに、KVキャッシュの事前計算があるんだ。全部のトークンの情報を事前に計算しておくとメモリも時間もかかる。

そう。特に長い文書を複数のチャンクに分けて処理する時、後のチャンクは前のチャンクの情報を必要とする。従来は各チャンクを独立に計算したり、全部再計算したりで、非効率だった。

情報フローに基づくKV再計算、だ。チャンク間で実際に情報が流れる重要なトークンだけを選んで、KVキャッシュを再計算する。無駄な計算を省くのが目的だ。

クエリに対するAttention Normを指標にする。あと、RoPEの配置が推論時と一致していることが重要だと論文で強調されている。位置エンコーディングがずれると精度が落ちるからね。

実験結果では、従来のフル再計算や部分的な再計算と比べて、精度をほぼ維持したまま、推論速度を向上させられた。特に長い文書で効果が大きい。

そうだな。ただ、限界もある。選択するトークンの閾値の設定や、複雑な推論が必要なタスクでは、選択したトークンだけでは情報が不足する可能性も論文では言及されている。

…お前の場合は、重要なこともろくに覚えてないから、それでいいんじゃないか。

そう。正確には、事実と異なる記述を生成してしまう現象を「幻覚」って呼ぶんだ。例えば、画像に写ってない物を「ある」と言ったり、色や数を間違えたりする。

そこがポイントだ。生成を待たない。VLMが画像を処理して、答えを生成し始める前の、内部の状態を見るんだ。具体的には、視覚特徴とか、内部のトークン表現を、一度のフォワードパスで抜き出す。

抜き出した内部表現に、軽量なMLP、つまり小さなニューラルネットワークのプローブをかける。それで「この質問には幻覚を起こしそうだ」かどうかを分類する。全部生成前に終わるから、効率的なんだ。

評価結果では、最大でAUROCが0.93だった。これはかなり高い検知性能だ。幻覚を起こしそうなクエリを事前に検知できれば、生成を早期に中断したり、別の信頼できるシステムに回したりできる。安全性と効率が上がる。

ある。プローブの訓練には、幻覚の有無がラベル付けされたデータが必要だ。あくまで「検知」であって「修正」ではないから、検知した後どう処理するかは別の仕組みが必要になる。

…その比喩は少し違う。単に確率を計算してるだけだ。

従来の評価は、タスクの正解率だけを見ることが多かった。でも、それだとモデルがどういう理由で間違えたのか、推論のどの部分が弱いのかがわからない。X-RAYは、推論の過程を「構造」という形で捉え直して、弱点を可視化しようとするんだ。

例えば、問題を解くときに考慮すべき「制約」と、その制約同士の「相互作用」、推論のステップ数である「深さ」、そして考えうる答えの集合である「解空間の幾何学的な形」を、形式的な構造として定義する。X-RAYは、LLMがこれらの構造をどれだけうまく扱えるかを測定するフレームワークなんだ。

論文では、論理パズルや数独のような、構造が明確に定義できる問題をたくさん作る。そして、問題の構造を少しずつ変えながら、モデルに解かせる。例えば、制約を一つ追加したらどうなるか、解空間の形を複雑にしたらどうなるか、って感じで。

重要な発見は、モデルの能力に非対称性があることだ。例えば、既存の問題に新しい制約を追加するのは比較的得意だけど、解空間そのものを根本から組み替えるような問題、つまり「解空間の再構築」が必要な問題にはめっぽう弱い。これは正解率だけを見ていたら見逃す違いだ。

そうだな。従来のベンチマークでは同じスコアのモデルでも、内部の推論能力は全然違うかもしれない。X-RAYはその違いを明らかにする。ただ、課題もある。今のところ、構造が明確に定義できる論理・数学的な問題に限定されている。日常会話のようなあいまいな推論にはそのまま適用できない。

…その例え、ちょっと大げさだ。

ああ。この論文は、LLMがすでに持っている内部の知識だけを使って、主張が正しいかどうかをチェックする新しいタスクを提案している。『検索なし事実確認』って呼んでる。

そこがポイントだ。従来は、質問を投げてその答えが正しいかどうかを見る方法が多かった。この研究では、主張そのものの内部表現を詳しく調べる。特に、彼らが提案したINTRAという手法は、Transformerの異なる層の間の相互作用を利用して、主張の中の事実関係を検出するんだ。

評価は大規模だった。9つのデータセット、18の既存手法、3つのモデルでテストしている。結果、内部表現を活用する手法が全体的に優れていて、特にINTRAが最高の性能を示した。既存の知識を問い合わせる手法より、汎化性も高かった。

そういう可能性はある。検索の遅延や、検索結果の品質に依存しないという利点は大きい。特に、リアルタイム性が求められる場面や、検索できないオフライン環境でも使える。

そう単純じゃない。限界もある。LLMの内部知識が間違っていたり、古かったりする場合は、当然間違った判断をしてしまう。あくまでモデルが知っている範囲内での確認だ。未知の事実や、非常に新しい情報には対応できない。

その通りだ。この研究は、内部知識をどう効率的に引き出すかという重要な方向性を示している。

…それは比喩としても、あまり正確ではないな。

POETは、オプティマイザーの一種だ。AdamWみたいに、勾配の1次モーメントと2次モーメントを使うんだけど、計算方法が違って、学習がすごく安定するんだ。ただ、問題はメモリをめちゃくちゃ食うこと。パラメータ数の2乗に比例するメモリが必要で、大規模モデルの学習には向かなかった。

主に3つの工夫だ。まず、『入力中心の計算』。POETの計算の大部分は、パラメータじゃなくて入力データに依存している部分を見つけて、そこだけを毎ステップ計算するようにした。これでメモリ使用量が激減する。

次に、カスタムCUDAカーネル。この入力中心の計算をGPUで効率的に実行するための専用プログラムを作った。最後に、POETで出てくる『プレコンディショナー』という行列を、ブロック対角行列というシンプルな形で近似して、計算を軽くした。

うん。実験では、単一のH100 GPUで、最大130億パラメータのモデルの事前学習に成功した。メモリ使用量は、LoRAのようなパラメータ効率的なチューニング手法と同程度で済んでいる。しかも、性能は普通のAdamWオプティマイザーでフル学習したモデルと同等か、それを上回った。

意義は大きいと思う。特に、計算資源に限りのある大学や研究機関、個人研究者が、大規模モデルをスクラッチから学習・研究できる可能性を広げた。民主化に近づく一歩だ。

論文にも書いてあるけど、まだ完全にPOETを置き換えたわけじゃない。近似を導入しているので、理論的な保証が元のPOETより弱い部分がある。あと、カスタムカーネルは今のところA100/H100に最適化されていて、他のGPUでは性能が出ないかもしれない。広く使われるには、さらなる検証と最適化が必要だ。

…電気代がまず無理だ。

ああ、あの論文か。自動運転のシステムをテストするために、画像に霧や雨、夜の景色を合成する研究だ。

そう。でも、ただ合成すればいいわけじゃない。合成した画像がどれだけ本物らしいか、つまり『現実感』が重要になる。

それがこの研究のポイントだ。大規模に評価するために、VLM、つまりGPT-4Vのような画像理解AIに『知覚評価』をさせている。例えば『この画像に霧はありますか？』と質問する。

圧倒的に生成AIだ。特に雨や雪の合成では、ルールベースの手法に比べて、人間が受け入れる率が約3.6倍も高かった。

その通り。霧は比較的うまくいったが、昼の画像を夜に変える『夜間変換』はまだ課題が残っている。暗くするだけでは不自然で、照明の再現が難しい。

そうだな。自動運転の開発や安全性評価を加速させる可能性は大きい。ただ、生成AIの評価自体もまだ発展途上だから、そこは注意が必要だ。

…その言い方は、少し単純化しすぎだ。技術の本質を見失う。

ああ、CODETASTEベンチマークの話だな。動機はシンプルで、LLMがどれだけリファクタリングの「発見」と「実行」を自律的にできるか、定量的に評価したかったんだ。

方法は二段階ある。まず「提案」タスク。改善が必要なコードだけ与えて、人間が選んだようなリファクタリングをLLMが自力で発見できるか。次に「実装」タスク。具体的なリファクタリング方法を指示して、それを正確にコードに反映できるか。

評価結果は対照的だった。実装タスクでは、最先端のLLMエージェントが詳細な指示があれば、複雑なリファクタリングも約70%一致するレベルで実行できた。

しかし、提案タスク、つまり「どこをどう直すべきか」を自律的に発見するのは極めて難しかった。人間が選んだリファクタリングを発見できたのは8%未満。

そう。この結果の意義は、リファクタリングの「提案」と「実装」は別の能力で、現状のLLMは後者に特化していることを示した点だ。だから、人間が改善点を提案してLLMに実装させる、という分業アプローチが現実的だと結論づけている。

限界は主に二つ。一つは、ベンチマークが特定のリファクタリングパターンに依存していること。もう一つは、コードの文脈やチームのコーディング規約といった、より高次で曖昧な判断を必要とするリファクタリングは評価できていないことだ。

…その比喩は、意外と的を射ているな。

ああ、DCANの論文だな。コードの出所を特定する研究は重要になってきている。

うん。例えば、教育現場で生徒がLLMにコードを書かせて提出した場合、それを検知する必要がある。あと、知的財産やセキュリティの観点でも。

DCANのキモは、コードから「タスクの意味情報」と「モデルのスタイル情報」を分離することだ。

そう。変数名の付け方、インデントの癖、コメントの書き方とか、モデルごとに微妙な特徴がある。それを「コード指紋」として抽出する。

そう。スタイル情報だけを残すように変換するネットワークを学習させる。そうすれば、どんなタスクのコードでも、モデル固有の特徴だけを比べられる。

評価は4つのプログラミング言語で、9万サンプル以上のベンチマークを使って行われた。既存の手法より高い精度で判別できたみたいだ。

ただ、限界もある。未知のモデルや、複数のモデルが混ざったコードへの対応は今後の課題だって書いてあった。

…そういう発想は、研究の本質から少し外れてるな。

ああ、読んだよ。従来の評価方法には限界があったからな。

それが問題なんだ。データベースには制約があるだろ？NOT NULLとか外部キーとか。

生成されたSQLが、たとえテストケースでは正しい結果を返しても、制約に違反するデータを返す可能性がある。そういう誤りを見逃してしまうんだ。

形式的検証を使う。データベースの制約を考慮して、SQLが制約に違反するような反例を自動的に探し出すんだ。

BIRDデータセットで実験したら、従来の実行ベースの評価では見つからなかった多くの不一致を検出できた。しかも、より現実的な反例を生成できたみたいだ。

そうだね。システムの信頼性を高めるのに役立つ。オープンソースなのもいい。

もちろんある。全ての種類の制約や複雑なクエリを完全にカバーできるわけじゃない。あくまで補助的なツールだ。

…まずは自分で勉強しろ。

ああ、そうだよ。最近はLLMにテキストで指示を出して、3D形状を生成する研究が進んでる。でも、従来の方法には大きな問題があった。

具体的な面や辺を指定して、面取りやフィレットみたいな細かい編集をするのがすごく苦手だったんだ。LLMが出力するのは、頂点の座標とか、プリミティブな形状の組み合わせだけだから、生成途中のモデルの特定の部分を直接触るのが難しかった。

そう。このPointer-CADっていう手法は、生成途中の3D形状のデータ構造、B-repって呼ばれるものをLLMに見せて、その中の特定の面や辺を『ポインタ』で直接指定できる新しいコマンドを考えたんだ。

それに近いね。これまでは『ここを面取りして』って言っても、LLMには『ここ』がどこかわからなかった。でも、ポインタを使えば、『このIDの面を面取りして』って明確に指示できる。それに、座標を直接いじらないから、量子化誤差で形が微妙にずれる問題も減らせる。

評価は、約57万個のCADモデルで作ったデータセットで行ったみたいだ。従来の方法に比べて、特に面取りやフィレットみたいな複雑な編集コマンドを正確に実行できるようになったって結果が出てる。

そうだね。CAD操作の自動化や、初心者でも直感的に使えるインターフェースへの応用が期待できる。でも、もちろん限界もある。

ポインタで指定するためには、生成途中の形状のB-repデータを正確に理解して、その中の要素を一意に指し示せる必要がある。すごく複雑で要素の数が膨大なモデルだと、ポインタ自体が間違う可能性はある。あと、学習に使ったデータセットの範囲を超えた、まったく新しい形状の編集は難しいだろうね。

…その前に、君が『あれ』と『これ』をちゃんと説明できるようになるのが先だと思うけどな。