この動画は、99%のエンジニアが知らないAIシステム設計における6つの重要な原則について解説している。従来の決定論的なソフトウェア工学とは根本的に異なるエージェント型AIシステムの特性を踏まえ、状態保持知能、不確実性の制御、インテリジェント障害検出、能力ベースルーティング、複雑なシステム状態管理、継続的入力検証といった新しい設計思想が必要であることを論じている。
AIシステム設計の新たな原則
みなさん、こんにちは。今日はな、私がみんなに知っておいてほしいAIシステムの6つの原則について話していくで。エージェント型システムをずっと開発してきて、そういうシステムを作っているチームとも一緒に仕事してきたんやけど、みんなが見落としがちなのがこれから説明する内容やねん。これらの原則は、100個のエージェントを使うシステムでも、たった1つのエージェントだけのシステムでも、どっちでもスケールできる原則なんや。
第1原則：状態保持知能
まず第1の原則は、状態保持知能が必要やということやねん。つまり、コンテキストの保持っちゅうのが、優れたAIアーキテクチャの核心原則なんや。これは、システム設計を学んだ時に教わったこととは全く違うんやで。昔はステートレスサービスが重要やと教わったやろ？これは要するに、何でもクリーンスタートできるようにせなあかんっちゅうことで、そうすることで簡単にスケーリングできるからやったんや。
ところがな、AIシステムっちゅうのはコンテキストが必要で、学習した行動があるんやけど、これらは再起動すると消えてしまうねん。やから新しいOpenAIのレスポンスAPIはステートフルになってるんや。コンテキストを保持するようになってて、これは意図的に追加したものなんやで。なぜなら、エージェント型ワークフローのアーキテクチャコンポーネントとして、コンテキストの保持がめちゃくちゃ重要やからや。みんながこれを理解してくれたらええのになと思うわ。なぜなら、賢い方法でコンテキストを保持できるようになったら、他のすべてが簡単になるからや。
優れたエージェント型アーキテクチャの大部分は、結局のところ優れたコンテキストエンジニアリングと優れたコンテキスト保持なんや。同じトークンを再送信する必要がないんやで。そんなことしたら無駄やからな。やから第1原則は状態保持知能や。賢いシステムが、エージェントにとって意味のある方法で状態を認識し保持するようにせなあかん。
第2原則：不確実性の制御
第2の原則は不確実性の制御やねん。我々は決定論的システムに慣れとるわな。従来のエンジニアリングでは、同じ入力に対して同じ出力が得られて、予測可能なテスティングができる。やからほとんどの品質保証はリリース前に行われるんや。新しいモデルでは、不確実性を制御せなあかん。つまり、確率論的なコアの上に、可能な限り決定論的なラッパーを本質的に配置せなあかんということや。
やからAPIをいじってLLMの温度を0に下げたり、入力を毎回同じ順序で極めて正確に定義したりせなあかん。そうすることで、クエリを実行した時に順序1、2、3で得られる結果が常に同じになるんや。これは、我々が慣れていない全く別次元のエンジニアリングやねん。従来は、プログラムが同じ入力に対して毎回同じ出力で応答するかどうかなんて考える必要なかったからな。
常にそうやったから、他のことを心配すればよかったんや。でも、もう我々は決定論的な世界に住んでへん。確率論的なコアの上に決定論的な橋を築かなあかん。我々の世界は今、確率論的なコアの上で動いてるんや。不確実性を制御する必要があることと、それが我々の基本的な役割の一部やということを、十分に理解してる人がまだ少なすぎるねん。
これによって、エンジニアの評価方法が変わる。エンジニアは、決定論的な指標だけやなくて、プロダクションで確率論的な指標がどのようなものかを理解するために、データサイエンスの観点からもっと時間を費やす必要がある。また、プロダクション後の品質保証により多くの投資が必要やねん。なぜなら、プロダクションパイプラインで発生するイベントを測定できる品質保証が必要で、それは期待に沿わないかもしれんし、エッジケースかもしれんし、何が機能して何が機能しないかについての我々の期待を破るものかもしれへんからや。
我々の世界がこれらの決定論的ブロックを構築するだけやという前提から、ローンチ後も継続的で持続的な運用が必要な確率論的システムを扱っているという前提に移行する必要がある。やから戻って測定せなあかん。注意を払わなあかん。決定論的なバグがあるからだけやなくて、モデルが時間とともにドリフトし、時間とともに異なる入力を得て、異なるモデルが交換され、コンテキスト構造でコンテキストが出現し変化するにつれて、不確実性を制御し続けることが我々の仕事やからメンテナンスせなあかん。
これらすべてのことが、決定論的な出力の世界にいた時には真実やなかった方法で、プロダクションシステムの動作を変化させるんや。これが2つ目やな。
第3原則：フェイルファスト設計
3つ目は、フェイルファスト設計やねん。昔は、何かがエラーでクラッシュして明確な障害モードがあったら、我々が仕事をしてるということやった。なぜなら、すぐにそのマイクロサービスを停止して再起動できて、システムの他の部分を徐々に引きずり下ろす必要がなかったからや。ところが今は、検出するのが困難な障害があるんや。
AIは幻覚によって失敗することがある。AIはドリフトによって失敗することもある。機能的やけど完全に間違ってることもあるねん。これは我々が慣れていない障害モードやで。インテリジェントな障害検出が必要やねん。システムの健全性だけやなくて、推論品質を監視する能力が必要や。それをどうやって測定するかは、エージェント型システムに組み込みたい推論の種類によって変わってくる。
でも測定せなあかん。プログラムが動作しない壊滅的な障害だけやなくて、発生する障害を検出できるようにせなあかん。そして、全体がダウンしたらどうなるかという観点からではなく、推論品質の劣化を検出するのが困難な場合にシステムがうまく機能する方法という観点からシステムを構築せなあかん。
フェイルファストの世界から、障害が検出しにくい微妙な障害の世界に移行してるという前提で考える必要がある。やからその世界で品質をどう監視するかについて多く考える必要があるねん。これもエンジニアにとって大きな変化やで。彼らは非常にシンプルな障害モードに慣れてて、本当にクリーンな切断があって、何かがダウンしても大きな依存関係がなくて元に戻せることを確認するのに慣れてるからな。もうそうはいかへんねん。
プロダクションで動作してて、ほとんどの決定論的指標では成功に見えても、それでも機能しないものがあり得るんや。
第4原則：能力ベースルーティング
次の原則、これは4番目やけど。均等負荷分散は古いやり方や。同じノードがあって、同じリクエストを処理する。そういうシステムを構築してきたし、基本的にどんなデバイスを使ってても同じ体験が得られるから、異なるリクエストは全部同じ方法で処理されるんや。
でももうそうやない。エージェント型システムでは、システムへの異なるリクエストが劇的に異なる計算を意味することがあるねん。何百倍もの異なる計算やで。高推論計算リクエストは何千何千何千ものトークンになることがある。一方で低推論計算リクエストは100分の1のスペースで処理できる。非常にトークン効率の良いリクエストやからな。
やから同じノードと一貫してると想定する負荷を均等に分散する方法について考えるんやなくて、能力ベースのルーティングについて考える必要がある。タスクの複雑さとAIが特定の問題領域に対して持つ信頼度に基づいてレートルートする方法について考えるんや。AIがリクエストを理解するのに多くのトークンを消費する必要があるか？複雑か？やったら、AIが何が起こってるかを理解してる場合とは違う方法でルーティングする必要がある。
非常に低推論のタスクやからな。再び、考え方を変えとるんや。一連の同じノードに大きな一貫した負荷を均等に分散することやなくて、ノードの差別化された能力を理解して、持ってる能力をどこに置くかについて本当に本当にスマートな選択をすることなんや。
どこでより賢いモデルでトークンを消費するか？これは新しいことやろ？ルーティングについて違った考え方をせなあかん。インテリジェントにルーティングすることについて考えなあかん。この問題を解決するためだけに推論器を使ってエージェント型システムを構築してる人もいるねん。
第5原則：複雑なシステム状態管理
原則5は、バイナリ健全性状態やねん。我々はシステムアップ、システムダウンに慣れとる。再びあなたに指摘したいのは、エージェント型システムでは、それほど単純やないということや。システムアップ、システムダウンもあり得るし、マルチエージェント型システムを持ってる時は、その間に多くの複雑な状態があり得るんや。インテリジェントな障害検出に至るフェイルファスト設計のアイデアについて前に話したし、推論品質を理解せなあかんということも話した。
これはその次のレベルやねん。この場合はマルチエージェントシステムで、システムがアップして部分的に機能してることがあり得るということを理解せなあかん。システムがアップしてるのに機能してないこともある。システムがアップしてるのに、エージェント間の一部のハンドシェイクが動作してないこともあるけど、それでも機能のほとんどは得られるかもしれへん。でも知能が劣化してるかもしれへんな。
何を言いたいかっちゅうと、白黒の世界から、たくさんたくさんのグレーの濃淡がある世界に移行したということや。たぶん50の濃淡のグレーやろな。そして、それが複雑な時に測定、品質、システム健全性をどうするかを把握せなあかん。そして、システムに追加するエージェントが多くなるほど、システム健全性を測定するのは複雑になるんや。
やから、あなたが通ってくる出力、それらの出力の品質を追跡し、エージェントがハンドシェイクを破ってる場所や、エージェントの推論トレースがうまく動作してない場所や、出力の劣化がある場所や、どこかでコンテキストドリフトがある場所を理解して、何が起こってるかを特定するのに十分な監査トレースを理解する必要がある。
以前よりもはるかに高い監査可能性のバーやねん。
第6原則：継続的入力検証
最後に指摘したい原則は入力検証やねん。以前は一度検証したらよかったやろ？入力を処理してる時は、ゲートウェイで検証する必要があるという感じで。マイクロサービスに入って、終わりや。今のところ順調やったんや。最近はそうやない。
最近は会話状態を通じて検証せなあかん。継続的な検証が必要やねん。AI行動は蓄積されたコンテキストに依存するということを理解せなあかん。やから進行しながら検証する必要があるし、そうしないとどこで軌道から外れてるかがわからんようになるねん。やからほぼ継続的なエッジのように考える必要がある。
会話の各ターンは、会話状態の何らかの検証を必要とする可能性のあるステップやと考える必要がある。やからそこにチェックポイントがあって、それが機能したということがわかるんや。そうしないと、これらのシステムをデバッグするのが非常に非常に困難になるからな。
もしこれらすべてが困難に聞こえるなら、そうあるべきやで。健全なエージェント型AIシステムを設計することは、従来のソフトウェアを設計することよりもはるかにはるかに困難やねん。
そして、従来のエンジニアリング原則がAI時代に機能しないことについて、非常に非常に少ない議論しかしてこなかったんや。この分析が、我々が持ってる従来の原則の一部が完全に死んでるわけやないことを理解する助けになったことを願ってる。まだ従来のソフトウェアを構築してるなら、これらはまだ良い原則やし、我々のシステムの多くはハイブリッドシステムやからな。
そして、これについて書いてる投稿は、これについてもっと深く掘り下げてる。でも時には、従来の決定論的ソフトウェアシステムとAIシステムの両方であるシステムを構築せなあかんことがある。実際、私が構築するもののほとんどは最終的にハイブリッドになるんや。やから、決定論的ソフトウェアで重要な場所ではステートレスサービスのような従来の原則を適用し、また状態保持知能というAI原則を取って、エージェント型システムの設計で重要な場所でそれを適用するのに十分賢くあらなあかん。
新しい学校が必要やねん。新しい原則が必要やねん。AIシステムが真にスケールする方法についての新しい理解が必要やねん。そして、この分析が、戦術的なヒントに基づくだけやなく、スケールする原則に基づいてシステムを実際に構築する方法について、そのような新しい原則の一部が何であるかの感覚を得る助けになったことを願ってるで。
まとめ：AIのための6原則
これが私のAIのための6つの原則やで。状態保持知能。不確実性を制御する。本当にインテリジェントな障害検出を確実に持つ。均等負荷分散だけやなく、能力に基づいてルーティングせなあかんと想定する。マルチエージェント型システム全体で判断品質と推論パターンの健全性状態を確実に持つ。非常に詳細な監査追跡を持たなあかんし、それから入力としてだけやなく、会話全体を通じて入力を検証せなあかんと想定する。
これらすべてを組み合わせたら、実際に動作するエージェント型システムを得る可能性がはるかに高くなるで。頑張ってな。
コメント