※本記事は、Stanford Webinarで行われた「Large Language Models Get the Hype, but Compound Systems Are the Future of AI」の講演内容を基に作成されています。講演の詳細情報はhttps://stanford.io/ai でご覧いただけます。本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演をご覧いただくことをお勧めいたします。
本講演は、スタンフォード大学のオンライン教育ポータル「Stanford Online」を通じて提供されています。Stanford Onlineは、スタンフォード大学の学部や部門が提供する学術・専門教育のプラットフォームであり、スタンフォード工学部のグローバル・オンライン教育センター（CGOE）によって運営・管理されています。
講演者紹介： Christopher Potts教授は、スタンフォード大学の教授で、AIシステムにおける複合システムアプローチの第一人者です。特に、言語モデルを中心としたAIシステムの設計と最適化、およびそれらのシステムが研究、製品開発、安全性、規制に与える影響について深い知見を持っています。また、Berkeley等の研究グループと共に、「モデルから複合AIシステムへの移行」という新しいパラダイムを提唱しています。DSPiライブラリの開発にも関わり、プロンプトエンジニアリングからシステムレベルの最適化へと開発手法を進化させる取り組みを行っています。
1. はじめに
1.1 大規模言語モデル(LLM)の現状
現在、私たちはAIの見出しがモデルに集中している状況に直面しています。この傾向は2020年のGPT-3の論文発表から本格的に始まりました。GPT-3の画期的な点は、それまでのどのモデルよりも一桁以上大きい1,750億パラメータのモデルを訓練し、これまでにない新しいタイプのシステムを設計できることを示したことでした。
この成功以降、大規模モデルの発表が相次いでいます。例えば、GoogleはPalmモデルを発表し、そのヘッドラインは5,400億パラメータという、これまでに見たことのない規模でした。私はPalmをすでにシステムとして捉えていますが、彼らはこれをモデルとして発表しました。
さらに、Geminiの発表でも同様のアプローチが取られました。Geminiは、モデルのアーティファクトとしてのイノベーションと、その周りに構築されるシステムの両方において、パラダイムケースだと考えています。しかし、このトレンドに従って、彼らはこれもモデルとして説明しました。
OpenAIも同様です。私は彼らを、ChatGPTのような完全なソフトウェアシステムを中心に再編成した組織だと考えています。ChatGPTは多くの興味深いモデルによって支えられている体験ですが、彼らでさえGPT-4という新しいフラッグシップモデルとして発表しています。これらは実際にはシステムですが、モデルを中心に据えて発表されています。
大手テック企業だけでなく、私のような人間がTwitterを開くたびに、新しいモデルシリーズが全てを変えるという息を飲むようなアナウンスで溢れています。このような世界に生きていると、モデル中心の思考に陥るのは理解できます。しかし、これが今日の中心的な教訓となります：私たちが実際に扱っているのは、常にシステムなのです。
1.2 システムとしてのAIの重要性
私たちのグループやBerkeleyの関連グループなどでは、長らくシステムという観点で考えてきました。2024年2月18日に「モデルから複合AIシステムへの移行」というブログ投稿を公開しましたが、AIの世界では、これは相当前のことになります。最近では、OpenAIのSam Altmanも開発者イベントで、モデルについての議論からシステムについての議論へのシフトを予想すると述べました。これは私たちのブログ投稿のタイトルと直接的に呼応しています。これが影響を与えたのか、考えが収束したのかは分かりませんが、私たちが先に提唱したことは確かです。
この視点が重要な理由は、AIソリューションを開発する際に適切な投資を行うためです。私はF1レースカーの比喩を用いて説明します。F1レースカーはエンジンだけでなく、空力、摩擦、ドライバー、ドライバーのためのコントロールなど、全てが組み合わさって初めて優れたレースカーになります。しかし、AIの世界では、エンジンにだけ執着するF1レースカー設計者のように振る舞うことが多すぎます。私はF1レースについて詳しくありませんが、エンジンだけを考えていては良いレースカーは作れないと確信しています。
実際、私がChatGPTを使ってF1エンジンの画像を生成しようとした時、エンジンだけを表示することができず、常に車輪が付いた画像が生成されました。これは私が今日懸念していることを象徴的に示しています。私たちはF1レースカーを設計しようとしているのに、エンジンに車輪を付けただけで終わってしまっているのです。これでは良いシステムは作れません。システムという観点で考える必要があります。
この重要性は、実際の業界での利用を見ても明らかです。目標と制約に最適なシステムを構築するには、システムコンポーネントに重点を置く必要があります。私は、賢いシステムに組み込まれた小さなモデルの方が、単純なシステムに組み込まれた大きなモデルよりも常に優れていると主張します。これは純粋な精度や性能を追求する場合でも真実ですが、コスト、レイテンシー、安全性、プライバシーなどを考慮する場合には絶対的な真実となります。
2. モデルからシステムへの転換
2.1 モデル単体の限界
言語モデルがディスク上に存在するだけでは、完全に不活性な状態です。あなたがどこかからダウンロードしたり、数百万ドルを費やして自分で訓練したりした大規模言語モデルがあるとしても、その時点では単にディスク容量を占有しているだけです。
このモデルに何かをさせるためには、少なくとも2つのことが必要です。まず、モデルを何らかの内部状態に置くためのプロンプトが必要です。次に、生成的なシステムとして機能させたい場合は、サンプリング手法を定義する必要があります。本質的に、モデルは抽象的な空間で物事を表現することしかできないからです。
プロンプトとサンプリング手法の選択は、決して些細な決定ではありません。これらの選択が、最終的にどのようなシステムになるかを決定づけます。プロンプト、モデル、サンプリング手法は最小限のシステムを形成しますが、それだけでも重要な意味を持ちます。
これはF1レースカーの設計に似ています。F1レースカーはエンジンだけでなく、空力、摩擦、ドライバー、コントロールなど、全ての要素が協調して初めて優れたレースカーになります。しかしAIでは、私たちはエンジンだけに執着するF1レースカー設計者のように振る舞うことが多すぎます。エンジンだけを考えていては良いレースカーは作れないのと同様に、モデルだけを考えていては良いAIシステムは作れません。
実際の設計では、このような最小限のシステムを取り、計算機、プログラミング環境、データベース、さらにはWebのAPIやWeb自体へのアクセスを与えることになります。この時点で、これがソフトウェアシステムであることは明らかです。言語モデルは全ての活動のハブとして特権的な位置を占めるかもしれませんが、それは単なる一つのコンポーネントに過ぎず、システムの能力は言語モデル単体ではなく、これらの要素が協調して働くことで決定されるのです。
2.2 最小限のシステム構成要素
システムを機能させるための最小限の構成要素として、プロンプト、モデル、サンプリングの3つの要素が必要です。まず、プロンプトを使ってモデルをある内部状態に置き、次に生成的なシステムとして機能させるためにサンプリング手法を定義する必要があります。これらの選択は、どのようなシステムになるかを決定づける重要な要素です。
ここで作られる最小限のシステムでも、プロンプト、モデル、サンプリング手法は互いに密接に関連し合い、システムの性能を決定づけています。実際のところ、この3つの要素は切り離して考えることはできません。プロンプトはモデルの振る舞いを決定し、サンプリング手法はその出力の特性を形作ります。
さらに、現代的なアプローチでは、この最小限のシステムに様々な拡張機能を追加することができます。例えば、計算機能、プログラミング環境、データベース、さらにはWeb APIやWeb自体へのアクセスなどです。この時点で、私たちが扱っているのは明らかにソフトウェアシステムです。言語モデルは全ての活動のハブとして特権的な位置を占めるかもしれませんが、それは単なる一つのコンポーネントに過ぎません。システムの能力は、これら全ての要素が協調して働くことで決定されるのです。
重要なのは、これらの拡張機能の追加は単なる機能の追加ではなく、システム全体の性質を変えうるということです。例えば、Webアクセスを持つシステムは、静的な知識だけでなく、最新の情報にアクセスできる動的なシステムとなります。プログラミング環境へのアクセスは、システムに計算能力と実行能力を与えます。これらの拡張は、システムの可能性を大きく広げると同時に、新たな課題も生み出します。
3. サンプリング戦略の重要性
3.1 様々なサンプリング手法の比較
サンプリング手法は、プロンプトとモデルからなる最小限のシステムにおいて、モデルに「話させる」ための重要な要素です。プロンプトが入力され、モデルがこれを処理した後、どのように出力を生成するかを決定するのがサンプリング手法です。
最も基本的な手法として、greedy decodingがあります。これは、これまでに生成された内容を条件として、次のトークンとして最も確率の高いものを選択する方法です。これはデフォルトの生成方法として考えられがちですが、決して特権的な方法ではなく、多くの選択肢の一つに過ぎません。
また、top-pサンプリングという手法があります。これは、モデルの分布に従って最も確率の高いトークンの集合からサンプリングを行う方法です。beam searchはより探索的な手法で、複数の生成候補を並行して探索します。
さらに、トークンの多様性を確保するための手法もあります。これは生成されるテキストの多様性を確保するための高レベルな制約として機能します。より高度な制約として、生成される内容が有効なJSONフォーマットに従うことを要求するような方法も存在します。
この分野の文献を見ると、革新的なアイデアに満ちています。例えば、モデルの勾配を利用して、順方向・逆方向の情報フローについてより多くの情報を得る手法や、論理やコンピュータプログラミング環境のための文法に従った出力を保証する手法があります。最近の論文では、タスクに応じてモデルが創造的になったり制約的になったりするように、適応的に温度パラメータを見つけるためにモデルにパラメータを追加するという革新的なアプローチも提案されています。
これらの手法は、モデルが本質的に持っていない「話す」という能力を実現するための重要なステップです。サンプリング手法の選択は、システム全体の振る舞いに大きな影響を与えます。そのため、選択したモデルとプロンプトと複雑な相互作用を起こすことを認識しておく必要があります。
3.2 多数決完了戦略の事例
私はここで、より広い意味でのサンプリングと生成について、多数決完了戦略という興味深いパターンを紹介したいと思います。これは、現在のテクノロジーと研究において頻繁に目にするパターンの単純な例です。
例えば、難しい推論タスクを含むプロンプトがあるとします。モデルに一段階で回答を生成させることもできますが、それは難しすぎるかもしれません。その代わりに、モデルに推論の道筋を生成させ、その後で回答を生成させることができます。さらに、複数の異なる推論の道筋を生成させることで、異なる回答が導き出される可能性があります。
この過程を複数回繰り返すことで、回答の分布が得られます。そして、最終的な出力として、異なる推論の道筋から最も多く生成された回答を採用するという方法を取ることができます。これにより、モデルは探索と推論を生成の過程で行い、最終的な回答を出す前により深い考察を行うことができます。
これは厳密にはサンプリング戦略ではありませんが、ユーザーからはこれらの中間ステップを隠し、単純に入力に対する回答をサンプリングしているように見せることができます。これは、推論の道筋が他の回答を導き、さらにその回答が新たな推論の道筋を生み出すといった、より複雑な探索が可能な方法の単純な例に過ぎません。
このアプローチの集大成として、OpenAIの4.0モデルの発表があります。これらのモデルは明らかに、最終的な回答を生成する前に多くの推論時の作業を行っています。OpenAIはこれらを企業秘密として扱っているため詳細は公開されていませんが、小規模なモデルを使って同様の振る舞いを探求することは可能です。この分野は今後の研究文献でさらに発展していくことが予想されます。
4. プロンプトエンジニアリングの課題
4.1 GPT-2からGPT-3への進化
このインコンテキスト学習の起源は、2019年のGPT-2の論文に遡ります。この論文で、Radfordらは画期的な発見を報告しました。彼らは「言語モデルは、パラメータやアーキテクチャの修正なしに、ゼロショット設定でダウンストリームタスクを実行できることを実証する」と述べています。
具体的な例として、要約タスクについて、「記事の後にtldrを追加し、100トークンを生成する」という手法を示しました。実は私は2019年にこの論文を初めて読んだとき、その意味を正しく理解できませんでした。このような方法が機能するということに対する認知的バイアスが強すぎて、きっとどこかにtldrというトークンが要約を生成するように微調整された方法が隠されているのだろうと考えていました。しかし今では、彼らが書いたことはまさにその通りだったことがわかります。単にインコンテキスト学習に依存することで要約が可能になったのです。これは本当に驚くべき発見でした。
その論文では、翻訳、質問応答、テキスト補完、読解力テストなども試みられました。タスクによって性能にばらつきはありましたが、ほとんどの場合で有意な結果が得られました。
そして、わずか1年後、私たちはGPT-3を手にすることになります。GPT-2の12億パラメータから1,750億パラメータへと飛躍的な規模の拡大を遂げ、このスケーリングが何をもたらすのかについての驚くべき探求が行われました。
GPT-3の論文は、このスケーリングが可能にする複雑なインコンテキスト学習の探求に満ちています。例えば、質問応答では、文脈となる文章とともに、回答が文脈の部分文字列であるべきということを示すデモンストレーションを数例プロンプトに含めます。そして驚くべきことに、モデルはこの振る舞いを模倣して、文脈から適切な部分を抽出して回答することを学習したのです。
彼らは、文脈や指示、それに続くデモンストレーションのリスト、そして最後にターゲットというような一般的なパターンを確立し、これを質問応答から読解、機械翻訳まで、様々なタスクに適用しました。例えば、「文字をアンスクランブルして単語を作り、その単語を書いてください」という指示を与え、いくつかの例を示すことで、少なくともGPT-3の時点では、求める振る舞いに近い結果を得ることができました。
これは、現代のAIシステム開発における新しいテンプレートを確立したのです。それは非常にエキサイティングな発展でしたが、同時に新たな課題も生まれることになります。
4.2 プロンプトの微細な変更による大きな性能差
プロンプトエンジニアリングに長く取り組んでいると、その過程で心が折れそうになる経験をすることがあります。このことを端的に示す研究があります。BerkeleyとWashington大学のグループによる「プロンプト設計における表層的な特徴に対する言語モデルの感度の定量化」という論文です。副題は「あるいは、プロンプトのフォーマットについて心配し始めた顛末」というもので、プロンプト選択に対するモデルの驚くべき感度を示しています。
この論文では、llama-27bをはじめとする様々なモデルを調査していますが、その中でも特に印象的な例を紹介します。タスク280は指示に従うタスクでしたが、2つのプロンプトフォーマットを用意しました。これらは「passage」と「answer」という単語の後のコロンの有無だけが異なっていました。この微細な違いが、同じモデルの性能に80ポイントもの差をもたらしたのです。
この現象は論文の中で様々なタスクにわたって繰り返し観察されています。このことは、間違ったプロンプト戦略を使うことで、どんなモデルでも恣意的に性能を低く見せることができることを示しています。しかし、今日の本質的な教訓は、これらのタスクにおいてモデルを評価することの意味を問うことさえ意味をなさないということです。この問題は、モデルとプロンプト戦略の組み合わせとしてのみ意味を持つのです。これこそがシステム思考なのです。
したがって、「このモデルをどう評価するか」という問いを放棄し、代わりに「自分の目標に対して最適なプロンプトとモデルの組み合わせは何か」を考えるべきです。これがシステム設計における重要な視点の転換なのです。
4.3 モデルとプロンプトの密接な関係性
このモデルとプロンプトの密接な関係性について、さらに興味深い事例を紹介したいと思います。あるTwitterユーザーが「面白い発見だけど、エージェントの一部でツール呼び出しに古いGPT-4を使っていたのを4.0に更新したら、すぐに動作が壊れてしまった」と投稿しました。別のユーザーも「3.5から4.0 miniに移行した時に、まるで新しいプロジェクトを始めるかのように、プロンプトエンジニアリングをやり直す必要があった」と同様の経験を共有しています。
これは、モデルとプロンプトが不可分に結びついていることを示しています。私たちは英語でプロンプトを書いていますが、実際にはこれは言語モデルという一種の異質な存在とコミュニケーションを取ろうとする試みなのです。私たちの理解がシステムの性能に直接反映されると考えることで、自分自身を欺いてしまう可能性があります。私たちはこの状況から抜け出したいと思うかもしれませんが、まずはこの2つが不可分に結びついているという事実を認識することが第一歩です。
面白い事実として、このツイートの投稿者は私の自然言語理解コースの卒業生で、DSPiプログラミングライブラリのファンでもあることを、Petraが後で教えてくれました。
さらに興味深い事例として、Appleのインテリジェンスプロンプトの発見があります。これらはOSと共に配布されるシステムファイルの中に含まれていたものです。これらのプロンプトを読むと、Appleインテリジェンスモデルに意図した振る舞いをさせるために、彼らが経なければならなかった開発サイクルを垣間見ることができます。プロンプトには、モデルに望む動作を実現するための特別な要請のようなものが満載でした。
これらのプロンプトは、彼らが出荷したモデルと非常に密接に結びついていることがわかります。このことは、これらのプロンプトが英語で書かれているにもかかわらず、特定のモデルとペアになることを意図したコンパイル済みバイナリのようなものだと考えるべきだということを示しています。これは再びシステム思考を示すものであり、プロンプトをシステムコンポーネントとしてモデルから切り離して考えることはできないということを示しています。
5. DSPiライブラリの提案
5.1 従来のAI開発の教訓
AIの発展において、いくつかの重要な教訓が得られてきました。これらは、モジュラーシステム設計、データ駆動型の最適化、そして汎用アーキテクチャの採用です。これらの時代を経て検証された教訓は、特にディープラーニング時代において、現在の大規模言語モデルに至るまでの急速な進歩を可能にした重要な要素でした。
これらの基本原則は、TorchやTheano、Chainer、特にPyTorchなどのライブラリにうまく具現化されました。これらのライブラリはこれらのコンセプトを体現し、より迅速な開発を可能にしました。
しかし、現在の状況は少し奇妙です。私たちは多くのプロンプトテンプレートを使用し、手作業でプロンプトを調整し、完全なモデル依存性を得ています。これは先ほどの事例で見たように、時間をかけて手作業で調整されたプロンプト戦略が、特定のモデルと密接に結びついてしまうという状況です。
これは私にとって悲劇的です。なぜなら、これらの時代を経て検証された教訓が、私たちをここまで導いてきたにもかかわらず、新しいAIシステム開発のモードに入ったとたんに、それらを忘れてしまったかのように見えるからです。
特に懸念されるのは、6ヶ月後に振り返ってみると、プロンプトテンプレートを中心にシステムを設計してしまったために、どんな変更も不可能で、意図しない結果を全体に及ぼしてしまうという状況に陥ることです。さらに、誰かが「もうClaudeは使えない、OpenAIのモデルかllamaモデルを使わなければならない」と言った時に、全てが壊れてしまい、ゼロからプロンプトテンプレートを書き直さなければならないという恐ろしい瞬間が訪れます。
これは必ず避けなければならない失敗のパターンです。すでにプロンプトテンプレートに深く入り込んでしまっている場合は、何とかしてそこから抜け出す必要があります。しかし、もし今始めるのであれば、適切なソフトウェアシステムとしてこれらを表現する方法を選ぶべきです。そして、その一つの選択肢としてDSPiがあるのです。
5.2 プロンプトエンジニアリングからの脱却
DSPiは、プロンプトエンジニアリングから抜け出し、言語モデルプログラミングへと移行するためのプログラミングライブラリです。これは、プロンプト、言語モデル、サンプリング戦略を持つことがソフトウェアシステムを設計することだという洞察を具現化したものです。私たちは、人工知能とソフトウェアエンジニアリングの中核的な洞察をこの新しいAIシステム開発のモードにもたらしたいと考えています。
DSPiを使用した例を紹介しましょう。最上部では、この例で使用するハイレベルなツールをセットアップします。ここではturboをモデルとして、Wikipediaのインデックス、そして必要に応じて他のツールを設定できます。そして、DSPiで質問応答を行う最小限のシステムは、「dspi predict question to answer」という1行のコードで実現できます。
この1行のコードが実際に使用される際、システムの内部では言語モデルとの通信用のプロンプトにコンパイルされます。ここで重要なのは、私が書いたコードと、実際に言語モデルに送られるプロンプトの間に大きな違いがあるということです。コンパイルされたプロンプトは、設定したモデルの特性に密接に結びついており、上部で設定したツールに応じて異なる形になる可能性があります。
より複雑な例として、複数の文章から証拠を集めて質問に答えるためのマルチホップ質問応答プログラムを書くこともできます。これはほとんどがPythonコードで、PyTorchの設計原則に密接に結びついています。このアプローチにより、開発したいシステムの種類を自由にコードで表現できます。
さらに重要な点として、このプログラムを最適化できます。最終的なステップとして、ラベル付きの例を使用してプログラムを最適化し、選択したツールに依存せず、適切なプロンプト戦略を見つけることができます。下部に示したオプティマイザーは、指示とfew-shotデモンストレーションの両方を同時に最適化することができます。これらはプロンプトの成功に不可欠な要素であり、最適化をオプティマイザーに任せることで、時代を経て検証されたデータ駆動型最適化の教訓に立ち返ることができます。
5.3 システム最適化の実験結果
システム的なアプローチの重要性を示すために、オリジナルのDSPi論文からいくつかの実験結果を共有したいと思います。この評価では、プログラム、オプティマイザー、言語モデルの組み合わせによって完全なシステムを定義しました。モデルとしては、サイズと種類の異なるturboとllama-23bを使用しました。
最もベーシックなベースラインシステムとして、質問から直接回答を生成する単純なシステムを構築し、few-shotデモンストレーションをランダムに選択するオプティマイザーを使用しました。この結果、turboで34%、llama-2で27.5%の正解率（exact match）を得ました。
次に、検索拡張生成（RAG）という単純なDSPiプログラムを実装したところ、すでに性能の向上が見られました。さらに、ブートストラップfew-shot最適化を導入しました。これは、DSPiプログラムを使って完全な例（検索された文章を含む）を生成し、それらを望ましい振る舞いの例としてプロンプトに含めるものです。この結果、ベースラインから大きく向上し、turboで42%、llama-2で38%の正解率を達成しました。
また、ReAct（Reflection-Action）エージェントというアプローチも試しました。これは、タスクの解決方法について考え、部分に分解するという興味深い提案です。このタスクでは成功率は低かったものの、システム思考の力を示す良い例となりました。ここでも、人間が慎重に作成した推論プロンプトよりも、単純なブートストラップで得られたプロンプトの方が性能が高かったことは注目に値します。これは、データ駆動型の最適化の重要性を示しています。
最後に、マルチホップ推論を行うプログラムを実装しました。これは複数の文章から証拠を集めて回答を提供するように設計されたものです。この結果、最も優れたシステムが実現され、turboでは34%から54.7%へ、llama-2では27.5%から50%へと大幅な性能向上を達成しました。
これらの結果は、プロンプト戦略とオプティマイザーを考慮したインテリジェントなシステム設計の重要性を示すだけでなく、小規模モデルの可能性も示しています。実際、小規模なllama-2モデルでの性能向上がより顕著であり、ほぼturboと同等の性能まで達することができました。これは、システム設計の工夫により、小規模モデルから最大限の性能を引き出せることを示す重要な発見です。
6. 小規模モデルの重要性
6.1 企業での使用実態
Theory Venturesのアナリストによるレポートから、非常に興味深い洞察が得られています。「Small But Mighty AI（小さいけれども強力なAI）」と題されたこのレポートには、企業での実際のモデル使用状況が示されています。特に注目すべき点は、企業におけるモデルの使用の77%が130億パラメータ以下の規模のモデルだという事実です。
これは、見出しを飾る最大規模のモデルではなく、むしろはるかに小規模なモデルが実際のビジネスで使用されているということを示しています。このような状況が生まれている理由を理解するには、企業が実際に直面している制約を考える必要があります。
レイテンシー（応答時間）はその重要な要因の一つです。このレポートに含まれるレイテンシーの数値は非常に示唆的です。もし産業システムで作業している場合、約18ミリ秒程度のレイテンシーが望ましい値となります。しかし、レイテンシーが50ミリ秒を超え、さらには750ミリ秒に達するようなケースでは、実際の運用で深刻な問題が発生します。
このレイテンシーの問題は、最終的にはコストの問題に直結します。高いレイテンシーを持つシステムの運用は、組織が得られる利益に比べてコストが高くなりすぎる可能性があります。素晴らしいソリューションを持っていたとしても、組織の他の部分と比較して使用コストが高すぎれば、それは単に非現実的なものとなってしまいます。
これらの要因が、企業に小規模モデルの選択を促す圧力となっています。しかし、これらの小規模モデルから最大限の性能を引き出すためには、私たちが設計するシステムについて、より深く考える必要があります。これは、先ほどのDSPiの実験結果でも示されたように、適切なシステム設計により、小規模モデルでも大規模モデルに匹敵する性能を実現できる可能性があることを示しています。
6.2 レイテンシーと実用性の関係
産業システムでの実際の使用を考えると、レイテンシーの数値は極めて重要な意味を持ちます。望ましい応答時間は約18ミリ秒程度ですが、50ミリ秒を超えるレイテンシー、特に750ミリ秒に達するような場合、実務上の深刻な問題が発生します。
このレイテンシーの問題は、ある種の頭痛の種となります。そして、このような頭痛は最終的にコストの問題へと変換されます。コストが高すぎる場合、組織の他の部分と比較して得られる利益が見合わないという結論に達することがあります。素晴らしいソリューションを持っていたとしても、使用コストが高すぎれば、それは単なる非現実的な選択肢となってしまいます。
このような実用性の観点から、小規模なモデルを選択せざるを得ない状況が生まれています。しかし、ここで重要なのは、小規模モデルから最大限の性能を引き出すためには、システムとしての設計を慎重に考える必要があるということです。
DSPiの実験結果が示すように、適切なシステム設計により、小規模モデルでも大規模モデルに匹敵する性能を実現できる可能性があります。実用的なシステム設計においては、レイテンシー、コスト、性能の三つのバランスを取りながら、システムとしての最適化を図ることが重要です。つまり、モデルの規模を単純に大きくすることではなく、システムとしての効率性を追求することが、実用的なAIソリューションの鍵となるのです。
7. システムレベルでの考察
7.1 ツールアクセスの影響
ツールアクセスを考えるとき、システム設計の観点から考えを整理するために、いくつかの問いを投げかけてみたいと思います。
まず、「どちらがより信頼できるか」という問いです。今日のウェブの全てのスナップショットを埋め込んで凍結された巨大な言語モデルと、最新のウェブ検索エンジンと連携する小規模な言語モデル、どちらがより信頼できるでしょうか。
次に、「どちらが好ましいか」という一般的な問いを考えてみましょう。中央集権的なサービスを介して、文脈のない自動補完を行う巨大な言語モデルと、あなたの個人のチャット履歴を使用して、ローカルで自動補完を行う小規模なモデル、どちらを選びますか。
さらに、「どちらがより危険か」という問いです。データベースやウェブへのアクセスを持たないGPT-4と、ウェブサイトにログインするように指示調整され、ウェブへのアクセスツールを持つ100億パラメータの言語モデル、どちらがより危険でしょうか。
これらの問いは、ツールアクセスがシステムの性質を根本的に変えうることを示しています。モデルサイズだけでなく、システムとしてどのような機能を持つかが、実際の影響を決定づけるのです。
これは、システムの拡張性と柔軟性の重要性を示すとともに、新たな可能性と課題を提起します。例えば、Webアクセスを持つシステムは、常に最新の情報にアクセスできる一方で、制御が難しく、予期せぬ行動を取る可能性も高まります。このバランスをどう取るかは、システム設計における重要な課題となります。
7.2 信頼性と危険性の比較検討
先ほどの問いかけをさらに深く考察してみましょう。「どちらがより危険か」という問いを改めて検討すると、データベースやウェブへのアクセスを持たないGPT-4と、ウェブサイトにログインするように指示調整され、ウェブへのアクセスツールを持つ100億パラメータの言語モデル、この比較は非常に示唆的です。
ここで重要なのは、モデルの規模だけでなく、システムとしてどのような機能を持つかが、実際の影響を決定づけるということです。Webアクセスを持つシステムは、その規模に関係なく、予期せぬ行動を取る可能性があります。特に、ウェブサイトへのログイン機能やツール使用の目標が与えられた場合、システムは私たちの予想を超えた行動を取る可能性があります。
また、2026年にどのようなシステムが主流になるかという予測も重要です。パラメータの中で数学、検索、推論などを全て行う巨大な基盤モデルが主流となるのか、それとも複数のモデルとツールが協調して動作するシステムが主流となるのか。私の予測では、後者のアプローチがより現実的で有望です。
システムレベルでのリスク評価においては、個々のコンポーネントの性能だけでなく、それらの相互作用や、システム全体としての振る舞いを考慮する必要があります。例えば、Webアクセス権限を持つシステムは、常に最新の情報にアクセスできる一方で、その情報の信頼性や使用方法の制御が困難になります。
このように、システムの信頼性と危険性を評価する際には、モデルの規模や性能といった単一の指標ではなく、システム全体としての機能と制約、そしてそれらの相互作用を総合的に考慮する必要があります。これは、今後のAIシステムの設計と規制において重要な視点となるでしょう。
8. 社会的影響と将来の展望
8.1 法規制の課題
最近の法規制の動きについて、カリフォルニア州のSB147という法案を例に考えてみましょう。この法案はニューサム知事によって拒否されましたが、その内容と拒否の理由は非常に示唆的です。
SB147は多くのことを規制しようとしましたが、その主要な特徴の一つは、モデルのサイズに基づく規制でした。特に、訓練に1億ドル以上のコストがかかり、訓練中に10の26乗フロップスの計算を実行したモデルを特別に規制対象としようとしました。つまり、本当に巨大な規模のモデルを対象としていたのです。一方で、より小規模なモデルは基本的に規制対象外とされていました。
ニューサム知事は、この法案を拒否する理由として非常に興味深い指摘をしています。彼は、「より小規模な特化型モデルが、法案が対象としていたモデルと同等かそれ以上に危険になる可能性がある」と述べました。私には、この指摘が非常に賢明に思えます。
これは本質的に、小規模なモデルを複雑なシステムに組み込むことで、システムとして予想外の振る舞いをする可能性があるという観察です。確かに、そのようなシステムは生産的にもなりうるのですが、ウェブにアクセスできず単にディスク上に置かれているだけの高価なモデルよりも、より危険になる可能性があります。
この決定は、将来の法規制はモデルではなく、システムを中心に考えるべきだということを示唆しています。つまり、単にモデルの規模や訓練コストといった指標だけでなく、システムとしての機能や影響力を総合的に評価する必要があるということです。これは法規制の観点からも、システム思考の重要性を示す例といえるでしょう。
8.2 研究評価方法の再考
研究と評価の観点から考えると、特に比較評価の方法について考え直す必要があります。現在、Hugging Faceのチャットボットアリーナや、スタンフォードのHELMなど、様々なリーダーボードが存在し、異なる言語モデルのランク付けを試みています。しかし、これらのエントリーは名目上は個々のモデルとしてリストアップされていますが、実際にはモデル単体を評価することはできません。
なぜなら、評価の裏では必ずプロンプト戦略、モデル、生成のための手順という最小限のシステムが動作しているからです。これは私のF1レースカーの類推で言えば、単なる車輪付きエンジンのレースを実施しているようなものです。もし車輪付きエンジンのレースを実施したいのであれば、それはそれで意味のあることかもしれません。しかし、私たちは自分たちが何をしているのかについて、より明確に認識する必要があります。
私たちが本当にすべきことは、これらの言語モデルをより大きなシステムの重要なコンポーネントとして捉え直し、リーダーボードの評価をシステム全体に関するものへと再編成することです。もし望むのであれば、言語モデルを重要なコンポーネントとして特別な位置づけにすることもできますが、全ての要素が協調して働く様子を評価することが重要です。なぜなら、これこそが現実世界でこれらの技術が展開される際の姿だからです。
このアプローチの転換は、単なる評価方法の変更以上の意味を持ちます。これは、AIシステムの開発と評価の方法論全体を、より現実的で実用的な方向へと導くものです。システムレベルでの評価により、実際の使用環境により近い形での性能評価が可能となり、より意味のある比較と改善の指針が得られるでしょう。
8.3 2025年以降のAIシステムの発展予測
過去5年程度を振り返り、AIの進歩を推進してきた異なるスケーリングの側面について考察してみましょう。2020年のGPT-3の論文から始まった教師なし学習のスケーリングの時代は、単に巨大な言語モデルにウェブ上のすべてのデータを模倣させることから始まりました。確かに現在でも、このプロセスのスケーリングはある程度の成果を示していますが、これだけではAIで見られる全体的な進歩を説明できません。
2022年頃から、特にChatGPTによって示された第二のスケーリングの波は、指示による微調整（instruct fine-tuning）のスケーリングでした。これは、優秀な人間のチームが良質な入出力ペアを作成し、それを使ってモデルを更新することで、特定のスキルを獲得させるというものです。これも現在も成果を上げ続けていますが、万能薬ではありません。
これは最近、私が最初に言及した第三のテーマ、生成のためのサンプリングのスケーリングにつながっています。2024年以降、ユーザーのクエリに対する回答を生成する過程で、非常に洗練された形の推論時処理や検索を行う手法が登場しています。
そして、2025年以降について私が予測するのは、システムのスケーリングの時代です。変革的な進歩は、完璧に良好な言語モデル（場合によっては小規模なものでも）に、生産的な方法で様々なツールへのアクセスを与え、システムとして本当に有能にすることで実現されるでしょう。
これは、高負荷のサービスを考えた場合、特に重要になります。小規模なモデルでも、適切なシステム設計によって大きな成果を上げることができます。2025年以降は、このようなシステムレベルでの革新が、AIの進歩を牽引していくと予測しています。
私の皆さんへの提案は、LLM思考から完全なシステム思考への移行です。これにより、あなたの仕事がより生産的になり、2025年以降に予測される大きな進歩につながっていくと信じています。
9. Q&A セッション
9.1 技術的質問への回答
DSPiに関する技術的な教育について、いくつかの優れたアプローチがあります。DSPiにはDiscordコミュニティがあり、多くのチュートリアルが用意されています。オープンソースプロジェクトに参加する素晴らしい方法の一つは、イシューを報告したり、PRを作成したりすることです。これにより、コミュニティに自己紹介し、積極的な貢献を始めることができます。
最初のステップとしては、Discordに参加することをお勧めします。ここでは活発な議論が行われており、人々が取り組んでいるプロジェクトの種類を知ることができます。中には、チームを組んで活動している人たちもいますので、そういったチームに参加することも可能です。このコミュニティは非常にオープンな環境です。
研究コミュニティも同様にオープンです。YouTubeには、私が今日触れた様々なプロンプト戦略、エージェント、ツールの使用など、多くのテーマについて、コース全体に相当するような素晴らしいコンテンツがあります。
ただし、産業界での動向を理解することは残念ながら徐々に難しくなってきています。企業は意思決定や研究革新のレベルでさえ、その詳細を非公開にする傾向が強まっています。開発者としては、オープンな情報とリソースを最大限活用しながら、実際の開発経験を通じて技術的な理解を深めていく必要があります。
9.2 ビジネスリーダーへの提言
組織内でジェネレーティブAIの戦略を策定するリーダーに向けて、いくつかのアドバイスを提供したいと思います。最も重要なのは、早い段階で成功がどのように見えるのか、そしてどのようなテストを行うのかを考えることです。これにより、明確な目標を持ったガイド付きのプロセスとなります。
システムの設計にあたっては、達成したい目標と、現在のAI時代における既知のリスクのバランスを取る必要があります。つまり、単にモデルを選択するのではなく、システム全体として何を実現したいのか、そのために必要な要素は何か、そしてそれらをどのように組み合わせるのかを慎重に検討する必要があります。
特に、レイテンシーやコストの制約を考慮すると、小規模なモデルを選択せざるを得ない場合が多いでしょう。しかし、これは必ずしも制限ではなく、むしろ機会として捉えることができます。適切なシステム設計により、小規模なモデルでも大きな価値を生み出すことが可能です。
また、プロンプトテンプレートから始めることは、短期的には生産的に見えるかもしれませんが、長期的には柔軟性を失う可能性があります。代わりに、最初からプロパーなソフトウェアシステムとして表現することを検討してください。これにより、将来的な変更や拡張に対してより強靭なシステムを構築することができます。
リスク管理の観点からは、システムの振る舞いを継続的にモニタリングし、予期せぬ動作が発生していないかを監視することが重要です。特に、外部ツールやWebアクセスを持つシステムの場合、その影響範囲は予想以上に広がる可能性があることを認識しておく必要があります。
