Subbarao Kambhampati (కంభంపాటి సుబ్బారావు)（@rao2z）のスレッド

[Transformer と LLM のコンテキストウィンドウで連続潜在空間ベクトルを使用する方法について] #SundayHarangue 連続潜在空間からのベクトルがどのようにして変換子を効率的に問題解決に導くかについては、多くの議論がなされています。しかし、これらの議論の中には、計算量の保存則に反するものもあると、私は考えています。 議論/類推は、これらのトークンを個別のトークンの「重ね合わせ」（結合と考えてください）として見ることを中心としています。 背景として、トランスフォーマーは潜在空間 L で動作し、すべての (言語的) トークンは L 内のベクトルに対応します。ただし、このマッピングは一方的です。つまり、L 内のすべてのベクトルが一意のトークンに対応するわけではありません。 しかし、これらのベクトル（一意のトークンマッピングを持たない）は、トークンに対応するベクトルの線形結合として捉えることができます。このように、これらのベクトルはトークンの和集合／重ね合わせとして捉えることができます。 変換子の操作がコンテキストウィンドウ内のエンティティを埋め込み空間からのベクトルとして扱うことは明らかです。特に、順方向パス操作では、処理対象のベクトルに対応する一意のトークンが存在するかどうかは考慮されません。 これは、トランスフォーマー操作に関して言えば、コンテキストウィンドウが「トークンベクトル」（つまり、一意のトークンに対応する埋め込みベクトル）と「潜在ベクトル」（つまり、一意のトークンに対応しない埋め込みベクトル）の両方を持つ可能性があることを意味します。前述のように、これらの潜在ベクトルはトークンベクトルの線形結合として見ることができます。 この柔軟性の明らかな活用法の一つは、Transformer によって生成される中間トークンがこれらの潜在ベクトルになり得ることです。つまり、（エンドユーザーに渡される）ソリューショントークンのみがトークンベクトルである必要があります。実際、https://t.co/f6E3c2j4dm (https://t.co/t4uYw5WTmD) で論じているように、中間トークンがエンドユーザーにとって意味を持たない限り、それらを潜在空間の任意のベクトルとして扱うことを許可することで、適切なプロンプト拡張を学習するための柔軟性が大幅に向上します (https://t.co/jl0LyWJUys を参照)。 中間トークンでの潜在ベクトルの使用に関するもう 1 つの議論は、「根本的な問題を解決する効率を向上させる」方法としてのものである。 さて、LLMが問題を解決すると考えることには、私はかなり懐疑的です。例えば、私たちの研究では、中間トークンの長さと問題の根本的な複雑さの間にはほとんど関連性がないことが示されています（https://t.co/UKgCwgHKeQ参照）。これは、訓練データの分布とテストインスタンスを橋渡ししようとする試みである可能性が高いことを示唆しています。 それでも、トランスフォーマーを「ソリューションを計算する」方法として見ているのであれば（たとえそれが事前トレーニング済みの LLM で実際に起こっていることではないとしても）、トランスフォーマーを潜在ベクトルではなくトークンベクトルに対して動作させることは、単一のエンティティではなくエンティティの選言表現に対して計算を行うことに相当するようです。 さて、選言的表現を操作することで、特定の分布における平均効率は向上しますが、最悪ケースの計算複雑度は向上しません。妥当性テストとして、抽象化と階層化は選言的表現を操作するものと見なすことができ、どちらも問題の最悪ケースの計算複雑度を変化させません。計画に関する議論については、https://t.co/aXreC5YKPN または https://t.co/UDzu2Qp7WK を参照してください。 だからこそ、潜在トークンを用いたトランスフォーマーがあらゆるケースにおいて効率を向上できるという主張には懐疑的です。例えば、最近の論文 https://t.co/4oQzEUIFPk では、潜在トークンを用いたトランスフォーマーはグラフの直径に比例する時間でグラフの到達可能性を解決できると主張しています（しかも量子重ね合わせ理論も引用しています！）。これは、複雑性の保存則に違反することなく（あるいは到達可能性を「解決する」ことの意味を変えずに）意味をなさない（最悪のケースではなおさらです）主張です。例えば、論文の実験結果は100%未満の精度でも問題ないようです。 金曜日のグループミーティングでこの論文について議論していたとき、私は学生たちに Graphplan プランニング アルゴリズムとの類似性について話しました。このアルゴリズムは STRIPS プランニング (到達可能性と密接に関連) を高速化します。何年も前に、Graphplan による高速化は、個々の状態ではなく状態セットへの射影を行うことで理解できることを示しました。ただし、和集合表現を直接操作すると、表現が目標状態に到達しているように見えても、実際には有効なパスを抽出できない場合があります。(Graphplan の場合、この抽出にはコストが指数関数的にかかるデコード ステップが含まれ、失敗すると、分離状態への射影が続行されます)。これは、下の図 👇 と https://t.co/s20cFEOfQk の元の論文 (または https://t.co/YqN0fh7vp6 の図 3 と関連する議論) に示されています。 要約: 潜在トークンは、LLM がトレーニング後に学習できるプロンプト拡張の柔軟性を大幅に向上させることができると私は信じていますが、「検討中の問題の複雑さを軽減する」という点には完全には同意しません。