GPT-4は99.4%失敗した——だから私たちは、AIに意思決定を委ねるのをやめた
もうすぐ深夜という時間帯、私は自社のエージェントが3回連続で誤った都市への航空券を予約するのを眺めていた。
毎回違う誤った都市というわけではなく——同じ誤った都市だ。デハラードゥーンではなくデリー。ユーザーははっきりと「Dehradun」と入力していた。LLMは思考連鎖の推論の中では正しく解釈していた。それなのに、APIコールを生成する段になると、デリーの空港コードにすり替えてしまった。自信満々に。何も告げずに。3回もだ。
共同創業者も通話に参加していた。彼はこう言った。「こいつはわかっているんだ、正しい答えを。推論トレースを見てくれ。文字通りデハラードゥーンと書いてある。それなのに、別のことをするんだ。」
その夜、私は、より良いプロンプトが私たちを救ってくれるという考えを信じるのをやめた。
私たちは旅行予約向けのAIエージェントを構築していた——AmadeusやSabreのようなグローバル・ディストリビューション・システム、つまり地球上のあらゆる航空券予約を支える、メインフレーム時代の古めかしいバックエンドと対話する類のものだ。そして私たちは、2023年に他の誰もがやっていたことをやっていた。すなわち、GPT-4を薄いオーケストレーション層で包み、ツールを与え、祈るのだ。
祈りは効いていなかった。
すべてを変えた数字
あのデハラードゥーンの一件から数週間後、私はTravelPlannerベンチマークに出くわした——予算、交通手段、食事、宿泊といった現実の制約のもとで、複数日にわたる旅程計画についてLLMを試す、厳密な学術的評価だ。有能な旅行代理店なら20分でこなすような類の作業である。
GPT-4の総合成功率は——0.6%。
60%ではない。6%でもない。0.6パーセントだ。
私は3回読み返した。それから、彼らが間違いを犯していないか確かめるために方法論を引っ張り出した。間違いはなかった。世界で最も先進的な言語モデルに、予算を守り、フライトとホテルとレストランをつなぎ、基本的な時間論理に違反しない旅行の計画を頼むと——99.4%の確率で失敗するのだ。
GPT-4に現実世界の制約付きで旅行の計画を頼んだとき、成功したのは0.6%だった。同じ問題を解くニューロシンボリックなエージェントは97%を記録した。
97%を記録したシステムは、より賢いモデルを使ったわけではない。根本的に異なるアーキテクチャを使ったのだ——LLMがユーザーの要求を構造化データに翻訳し、その後、決定論的なソルバーが実際の計画を行う、というものだ。LLMは翻訳者だった。コードが頭脳だったのだ。
そのベンチマークは、私たちの苛立ちを裏づけただけではなかった。設計図を与えてくれたのだ。
なぜあなたのAIエージェントは失敗し続けるのか？
「AIエージェント」ゴールドラッシュの中で、誰も語りたがらないことがある。それは——LLMは推論しない。予測しているのだ。
GPT-4が検索APIを呼び出すことを「決める」とき、それはロジックを実行しているのではない。学習データのパターンに基づいて、統計的に最も可能性の高い次のトークンを予測しているのだ。会話の中では、その予測はたいてい十分に役立つ。だが、各ステップが前のステップの正確な出力に依存する10ステップのAPIワークフローではどうか？それは大惨事だ。
私はこれを確率の連鎖問題と呼ぶようになった。あなたのLLMが各ステップを90%の確率で正しくこなすと仮定しよう——複雑なツール利用としては寛大な見積もりだ。計算はこうなる。
- 1ステップ：成功率90%
- 5ステップ：成功率およそ59%
- 10ステップ：成功率およそ34%
航空券予約のワークフロー——検索、絞り込み、選択、価格算出、搭乗者情報の収集、PNRの作成、検証、支払い、発券——は、日常的に10ステップを超える。理論上の成功率34%では、あなたが作っているのはソフトウェアではない。スロットマシンを作っているのだ。
しかも34%は上限だ。現実世界のパフォーマンスはさらに悪い。本番環境で私たちが繰り返しぶつかった2つの現象のせいだ。
ハルシネーションの連鎖
1つ目は、私がハルシネーションの連鎖と呼ぶものだ。連鎖型のアーキテクチャでは、ステップ2の出力がステップ3の入力になる。もしLLMが早い段階で微妙な誤り——フライト到着時刻を午前2時ではなく午後2時と読み違えるといった誤り——を犯しても、その誤りは捕捉されない。伝播していくのだ。エージェントは、そのハルシネーションで生じた時刻に基づいて、誤った日付でホテルのチェックインを予約してしまう。GDSのAPIはエージェントの意図を知らず、ただその入力だけを知っている。だからリクエストを問題なく処理してしまう。エージェントは200 OKのレスポンスを見て、自らの誤りを強化してしまうのだ。
その結果、「成功した」実行トレースが、現実世界では破滅的な結果を生む。エージェントは完璧にやり遂げたと思っている。顧客は空港に着いて、そうではなかったと知るのだ。
2つ目の現象はコンテキストドリフトだ。エージェントが複数ステップの計画を進めていくにつれ、コンテキストウィンドウは中間データ——検索結果、APIレスポンス、ユーザーメッセージ——で埋まっていく。モデルのアテンション機構は、それらすべてのトークンにわたって、ますます薄く広がっていく。ステップ10に至るころには、ステップ2で正しく特定した予算制約を、事実上「忘れて」しまっている。ソフトマックス関数に支配されるアテンションスコアが、あまりに多くの無関係なトークンにわたって希釈されてしまうのだ。
私は、提携候補先へのデモの最中に、これが実際に起きるのを目の当たりにした。エージェントはステップ3で予算内のホテルを見つけた。ステップ8でレストランを選ぶころには、残りの予算をすっかり見失っていた。ユーザーの支出上限を40%も超えてしまうような店を推薦したのだ。その提携候補者は私のほうを向いてこう言った。「つまり、こいつはただ……忘れるのか？」
そう。ただ忘れるのだ。
AIがメインフレームと出会うと何が起きるのか？
なぜ私たちに異なるアプローチが必要だったのかを本当に理解するには、グローバル・ディストリビューション・システムを相手に作業するとはどういうことかを理解しなければならない。
Amadeus、Sabre、Travelport——これらは世界の航空旅行の屋台骨だ。メインフレーム時代に設計され、その時代のように振る舞う。航空券の予約は、単一のAPIコールではない。それは有限状態機械であり、並べ替えたり、飛ばしたり、近似したりすることのできない、正確な一連の操作を伴う。
認証を行い、セッショントークンを取得する。そのトークンは、以降のすべてのヘッダーで渡さなければならない——もしLLMがそれを「忘れ」たり、新しいものをハルシネーションで作り出したりすれば、トランザクション全体のコンテキストが失われる。次にフライトを検索すると、GDSは巨大なネスト構造のJSONペイロード——しばしば50KB超——を返す。そこには運賃基準コード、手荷物モデル、区間参照が含まれている。LLMは特定のofferIdをそのペイロードから抽出して、先へ進む必要がある。だがLLMは非可逆圧縮器だ。要約する。切り詰める。GDSがバイト単位での正確さを要求するデータ形式を、「親切心から」正規化してしまうのだ。
ある夜、私たちは予約の失敗のデバッグに4時間を費やした。LLMが運賃基準コードを「修正」していたのだ——小文字を大文字に変えていた。英語テキストで学習したモデルには、そのほうがより「正しく」見えたからだ。GDSはそれを、意味不明なエラーで拒否した——ERR 1209 - SEQUENCE ERROR。説明もない。提案もない。ただの壁だ。
LLMは非可逆圧縮器だ。APIコール間でデータを受け渡すとき、エンタープライズシステムが要求する暗号学的な完全性を損なうような形で、「自動修正」し「正規化」してしまう。
そして、GDSがUC（Unable to Confirm＝確認不能）のようなエラーを返すと、LLMはどうすればいいのか見当もつかない。役立つように訓練されているので、そのエラーを一時的な不具合と解釈し、まったく同じリクエストをリトライする。何度も。何度もだ。私たちは、エージェントが何千ものトークンを浪費してAPIのレート制限に達し、私たちが「デスループ（Loop of Death）」と呼ぶようになったもの——理解できない壁に繰り返し体当たりし続ける状態——にはまり込むのを見てきた。
アーキテクチャをひっくり返した夜
転機は、ある口論の最中に訪れた。
プロジェクトが始まって3か月が経っていた。私のエンジニアリングリードは、プロンプトの改善を続けたがっていた——より長いシステムメッセージ、より多くの例、思考連鎖の指示だ。「もうすぐそこまで来ている」と彼は言い続けた。「PNR作成ステップ向けにプロンプトをもっとうまく構成しさえすれば……」
私はログを引っ張り出した。前の週、テスト環境で47件の予約失敗があった。11件はデスループ。9件はハルシネーションによる空港コード。6件は、必須の「Received From」フィールドを追加する前にLLMがPNRを確定しようとしたものだった——どれだけプロンプトを工夫しても直らないように見えるシーケンスエラーだ。モデルには、学習データから吸収した以上の、時間的な順序という本質的な概念がなかったからだ。
「もうすぐなんかじゃない」と私は言った。「私たちは上限にいるんだ。問題はアーキテクチャなんだ。」
その週、私たちはすべてを書き直した。LLMにオーケストレーションを任せるのをやめた。次にどのステップが来るのかをLLMに決めさせるのをやめた。生のGDSレスポンスを与えて、正しいフィールドを抽出してくれることを期待するのもやめた。
代わりに、私たちはグラフを構築した。
私たちが何を、なぜ構築したのかについての完全な技術的解説として、私は詳細な研究論文を執筆した。アーキテクチャを深く掘り下げた内容だ。
ニューロシンボリックAIは実際どのように機能するのか？
核となる考え方は、拍子抜けするほどシンプルだ。すなわち——制御フローは言語タスクではない。
厳格なビジネスプロセスの中で次に何をするかを決めることは、トークン予測の問題であってはならない。それは条件論理の問題であるべきだ。「支払いを求める」という判断は、「フライトが選択されている」かつ「価格が確定している」場合にのみ発火すべきだ。それはブール条件であって、確率的な提案ではない。
私たちはシステムを2つの層に分割した。
このLLMがインターフェース層——翻訳者——になった。ユーザーの自然言語（「デハラードゥーンへの、あまり高くない朝のフライトが欲しい」）を構造化データへとパースする。すなわち——{origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}といった具合だ。それこそがLLMが本当に得意とすることだ。乱雑な人間の意図を理解することである。
このグラフが実行層——マネージャー——になった。その構造化データを受け取り、決定論的なコードを使ってビジネスロジックを実行する。ハードコードされたノード。型付けされた状態スキーマ。雰囲気ではなく変数を検査する条件付きエッジ。
私たちはこれを構築するのにLangGraphを使った。必要なプリミティブを与えてくれるからだ。すなわち、共有された状態スキーマ（チャット履歴ではなくデータベースに支えられたもの）、単なるPython関数であるノード、そして実際の変数値に基づいてルーティングする条件付きエッジである。
LLMはワーカーであるべきだ——データを抽出し、テキストを要約し、JSONを整形する——一方で、マネージャーはハードコードされたソフトウェアであるべきだ。この制御の反転こそが、堅牢なエージェント型システムを特徴づける本質である。
私たちのアーキテクチャでは、LLMは文字通りできない——ステップを飛ばすことは。システムが予約を試みることは物理的に不可能だ——selected_offer_idという変数が状態に投入される前には。それは、プロンプトでLLMに「そんなことをするな」と伝えたからではなく、グラフのエッジが発火しないからだ。壁を突き抜けて車を走らせようとするようなもので——コードが単純にそれを許さないのだ。
実際のシステムはどのような姿をしているのか？
誰かが「来週の火曜日にムンバイからロンドンへのフライトを予約して」と言ったとき、何が起きるのかを順を追って説明しよう。
まず、Collectorノード——LLMによって駆動される——が、その文を構造化されたフィールドへとパースする。ガイド付き生成（JSONモード）を使って、特定のスキーマを出力する。Pythonのバリデーターが、空港コードが実在するものかどうかを確認する。「ロンドン」は曖昧だ——ヒースローかガトウィックか？——ので、グラフは曖昧性解消ノードへとルーティングする。LLMは推測しない。問い合わせるのだ。
検証済みの検索条件が得られると、RetrieverノードがAmadeus APIを呼び出す。これは純粋なコードだ。LLMは関与しない。レスポンスが返ってきて、状態にキャッシュされる。そしてそのときようやく、Summarizerノード——LLM——が、上位5件の結果を人間が読めるメッセージへと変換する。ただし厳しく制約されている。キャッシュされたJSONに存在するデータしか表示できない。特典を勝手に作り出したり、価格を変えたりはできないのだ。
ユーザーが選択肢を1つ選ぶ。Selectorノードが「2番目のもの」を特定のoffer_idハッシュへと解決する。Gatekeeperノードがビジネスルールをチェックする——これは会社の方針の範囲内か？その航空会社はブラックリストに載っていないか？違反があれば、グラフは中断する。状態をデータベースに永続化し、承認リクエストを管理者に送り、待機する。数時間後、管理者が「承認」をクリックすると、グラフはその正確な状態を再読み込みし、予約ノードから再開する。
最後に、Transactorノードが、GDSが要求する正確な順序で、PNR作成のシーケンス——区間、搭乗者情報、価格算出、確定——を実行する。もしGDSが価格変更の警告（旅行業界ではよくあることだ）を返せば、そのノードは処理を止め、ユーザーに確認を求める。より高い料金で自動的に予約したりはしないのだ。
すべてのノード遷移がログに記録される。すべての判断が追跡可能だ。監査人は実行ログを読み、正確に理解できる——なぜシステムが特定のフライトを予約したのかを。トークンの寄せ集めを解釈することによってではなく、構造化された記録を読むことによって、である——Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL。
インタラクティブな図を含む完全なアーキテクチャについては、ホワイトペーパーのインタラクティブ版に書いた。
これはただの……ふつうのソフトウェアエンジニアリングではないのか？
私はこれをしょっちゅう聞かれる。「つまり、AIを使う代わりにコードを書けと言っているわけだ。革命的だね」と。
違う。私が言っているのは、AI業界は言語モデルの魔法に酔いしれるあまり、過去60年のコンピュータサイエンスを忘れてしまった、ということだ。状態機械、型付けされたスキーマ、条件分岐、トランザクションの完全性——これらは時代遅れの概念ではない。あなたの銀行が誤って別の口座に送金してしまわないのは、これらのおかげなのだ。
ニューロシンボリックなアプローチは、反AIではない。それはアーキテクチャ擁護なのだ。私たちはLLMを積極的に使う——意図の解析に、曖昧性の解消に、要約に、そして人間が何を意味しているのかを、曖昧な何かを入力したときに理解するという、本当に難しい問題への対処に。だが、車が高速道路を走っているときに、LLMにハンドルを握らせることはしない。
作業をすると口で言うだけのチャットボットを作ることもできれば、実際に作業をこなすエージェントを設計することもできる。その違いこそがグラフなのだ。
私を驚かせたコストの論点もある。純粋なLLMエージェントは高くつく——1回の呼び出しあたりの推論が高価だからではなく、失敗ループのせいだ。エージェントが新しいパラメータをハルシネーションで作り出してGDSエラーのリトライにはまり込むと、タイムアウトするまでに何千ものトークンを浪費する。1つのはまり込んだセッションだけで、APIクレジットにして5〜10ドルかかることもある。私たちのハードコードされたエラーハンドラーは、そうした失敗をトークンコストゼロで捕捉する。そして、50KBのGDSレスポンス全体ではなく、関連する5つのフィールドだけをLLMに送るので、コンテキストウィンドウの使用量をおよそ90%削減している。
だが、モデルはいずれ十分に良くなるのではないか？
そうかもしれない。GPT-6やGPT-7が、ガードレールなしで10ステップのAPIワークフローをオーケストレーションできるほど信頼できるようになるかどうか、私には本当に分からない。だが、2つのことは分かっている。
第一に、たとえモデルが劇的に進歩したとしても、確率の連鎖問題は、技術的なものではなく数学的なものだ。もしあなたのモデルが1ステップあたり99%信頼できる——並外れた達成だ——としても、10ステップのワークフローは依然として10%の確率で失敗する。エンタープライズの取引にとって、それは依然として容認できない。グラフはこれを完全に取り除く。ルーティングが確率的ではないからだ。
第二に、モデルが良くなるのを待つことは、ほとんどの企業には持てない贅沢だ。企業が必要としているのは、稼働するエージェントだ——今すぐに。監査可能であること——今すぐに。EU AI法の透明性要件を満たすこと——今すぐに。ニューロシンボリックなアプローチは、未来に賭けたりはしない。今日利用できる最良のAI能力を使いながら、実証済みのエンジニアリング原則の上に築くのだ。
アーキテクチャこそがプロダクトである
私は、投資家やエンタープライズの購買担当者と十分な数の場に居合わせてきたので、AI業界が目覚め始めていることが分かる。問いは、「誰が最も賢いモデルを持っているか？」から「誰が最も堅牢なシステムを持っているか？」へと移りつつある。カンファレンスの講演で人を魅了するデモ——制御された環境でエージェントが完璧にフライトを予約してみせるようなもの——は安上がりだ。高くつくもの、そして重要なものは、1万回目のリクエストでも、1回目と同じように確実に動くものを作ることである。
私たちは、差別化がモデルではなくなる時代に入りつつある。それはグラフになる。状態スキーマになる。エラーハンドラーになる。条件付きエッジになる。すなわち、確率的な魔法を包み込み、それが家を焼き尽くさないようにする、退屈で、厳密で、決定論的なソフトウェアエンジニアリングだ。
魔法は、プロンプトの中にあったことなど一度もない。それは常に、アーキテクチャの中にあったのだ。