インタビュー
ニクンジャ・バジャイ、TrueFoundryの共同創設者兼CEO – インタビュー・シリーズ
あなたは機械学習の研究、FacebookでのプロダクションAI、そして大規模なレコメンドシステムを経て、TrueFoundryを共同創設しました。どのような経験があなたを企業向けAIインフラストラクチャ会社を設立するきっかけとなりましたか？また、当時どのような課題が解決されていませんでしたか？
Metaでは、機械学習をソフトウェアの特殊なケースと見なし、GenAIを機械学習の特殊なケースと見なしていたため、ソフトウェアが底部に、機械学習が中間に、GenAIが上部に配置された垂直スタックを構築していました。このセットアップでは、機械学習開発者として、私が構築するモデルは、他のソフトウェアと同じ展開パターンに従うため、システムのスケーリングが非常に簡単になります。
しかし、多くの企業では、ソフトウェア、機械学習、GenAI用に並列スタックを展開していました。並列スタックを持つと、機械学習とソフトウェアの世界間のハンドオフが必要になるため、スケーリングがより複雑になります。
私たちのチームは常に、機械学習モデルの構築と機械学習インフラストラクチャの構築の交差点で働いてきました。したがって、企業に似た垂直スタックを提供し、それを企業の特定の要件に適応させることができる独自の視点を持っていました。また、2021年末には、機械学習が転換点に近づいていると仮説を立てていました。そうすると、企業はこれらのシステムを効果的に展開・スケーリングするために、垂直統合スタックが必要になるという仮説でした。TrueFoundryを設立するきっかけとなりました。そして、2022年末にChatGPTが登場したことで、AIの導入が加速しました。
AIシステムが実験から日常の運用に移行するにつれて、信頼性と故障について組織が考えるべき点は何に変わりましたか？
Gen AIの賭けは、従来の機械学習システムと比較して、はるかに高くなります。システムが本稼働に移行すると、企業は、LLMが本質的に確率的であるため、より高いレベルの不確実性と非決定性に直面することになります。LLMの上に構築されたエージェントシステムは、さらに不確実性を加えます。
また、故障は二元的ではありません。システムが単純に故障するかしないかのではなく、部分的な故障やサイレントな劣化が発生することがあります。システムは、待ち時間の増加、品質の低下、または時間の経過とともに不正な動作を示す可能性があります。多くの場合、これらの劣化は、ハードな停止よりも検出が難しく、場合によってはより深刻な被害をもたらす可能性があります。
組織は、信頼性について、単に稼働時間だけでなく、時間の経過とともに性能の劣化についても考える必要があります。
TrueFailoverは、高プロファイルのクラウドおよびAIサービスの中断の波の中で発表されました。どのような最近の出来事が、AIの信頼性が「望ましい」から「コアのアーキテクチャ要件」にシフトしたことを明らかにしましたか？
私たちのヘルスケア顧客の1社は、処方に関連するリアルタイムのタイムセンシティブなリクエストを処理していましたが、モデル故障によって引き起こされた停止に影響を受けました。彼らのワークフローは1秒あたり何千ドルもの収益を生み出していますが、停止によってこれらの重要なワークフローが中断されました。TrueFailoverの初期顧客として、私たちは迅速な回復を支援し、影響を封じ込めることができました。
このようなインシデントは、重要な質問を提起します。Gen AIシステムの賭けが高まると、回復プロセスはまだ大部分が手動で行われているのはなぜですか？これは、システムが故障が発生することを前提として設計され、自動的に自己修復できるように設計されるべきであるという考えを強化しました。信頼性も、AIスタック自体に、AIゲートウェイを使用して中央集約化されたルーティング、観測可能性、ガードレール、モデルプロバイダー全体のインテリジェントなモデル切り替えを提供することによって組み込まれる必要があります。
多くのAIの中断はまだ技術的なつまずきとして扱われています。AIシステムがダウンしたときに、経済的および人的コストが現れるのはどこでしょうか？
企業のAIは、内部ワークフローにのみ影響を与えるのではなく、顧客の認識や利益に直接影響を与えるまでに進化しています。AIシステムの本稼働用途は、顧客向けであるため、ダウンや劣化は、ビジネス、顧客、評判の面で直接的な影響を及ぼします。
AIシステムが運用ワークフローに深く組み込まれるにつれて、中断は技術的な問題ではなく、ビジネス、顧客、評判の面での結果をもたらします。
ミッションクリティカルな環境、たとえば薬局、ヘルスケア運用、またはカスタマーサポートでは、AIのダウンタイムがどのくらいのスピードで運用リスクまたは評判リスクにエスカレートする可能性がありますか？
ミッションクリティカルな環境では、エスカレーションはほぼ即時的に発生します。なぜなら、これらのシステムはリアルタイムのタイムセンシティブなワークフローをサポートしているからです。短時間の停止でも、クリティカルなプロセスを停止させ、サービス提供を遅延させ、またはダウンストリームシステムに依存する出力を中断する可能性があり、組織全体にカスケード的な運用的影響をもたらす可能性があります。
ヘルスケアなどの分野では、影響は運用的中断を超え、顧客体験やサービス成果にも及ぶ可能性があります。処方を時間通りに満たすことができない場合、患者にとって実際的な結果をもたらす可能性があります。これは、患者にとっての問題であるだけでなく、薬局やヘルスケア提供者の評判にも影響を及ぼす可能性があります。信頼が重要なミッションクリティカルな環境では、システムがオンラインのままであることが極めて重要です。これが、組織がAIシステムを故障が発生することを前提として設計し、リスクを最小限に抑えるために自動回復メカニズムを活用する必要性を認識する理由です。
あなたは多くのチームが機能性よりも継続性を優先していないと述べています。なぜ信頼性は歴史的にAIシステム設計で優先されていないのでしょうか？
これは、組織内のインセンティブに起因します。新しい機能は目に見えていて、魅力的です。デモ、機能、製品の可能性をすぐにリーダーシップが見ることができます。
一方、継続性は、すべてがうまく機能している場合、目に見えません。したがって、報奨システムは、新しい機能の開発よりもむしろ、継続性のエンジニアリングに投資することよりも、新しい機能の出荷を優先する傾向があります。結果として、組織は不釣り合いなほど機能開発に投資し、信頼性よりも機能開発を優先しています。
企業が外部モデルやAPIに依存するにつれて、AIスタックにどのような新しい脆弱性が導入される可能性がありますか？
LLMは本質的に共有リソースであり、企業はこれらを従来のインフラストラクチャと同様に所有していません。また、企業の重要なビジネスクリティカルなシステムは、完全に時間の経過とともにテストされていない外部システムで実行されています。LLM自体は急速に進化しており、モデルプロバイダーは、待ち時間やモデルパフォーマンスのわずかな低下について責任を負うことができません。なぜなら、彼らは研究を非常に迅速に進めているからです。
LLMは共有リソースであるため、他のLLMの消費者が特定のアクションを取った場合、待ち時間が急上昇する可能性があります。LLMの本質的な性質により、多くの故障点が導入されます。企業はこの新しい世界では完全な制御を持ちません。完全な制御を持ちえない場合、企業ができる最善のことは、システムの冗長性を設計して、堅牢なシステムを構築することです。
特定の製品に焦点を当てないで、組織は故障を前提としてAIアーキテクチャを再考えるべきです。どのようにすればよいのでしょうか？
組織は、分散システム設計の第一原則に戻るべきです。ソフトウェアシステムは、ネットワークコンポーネントやマシンが故障することを前提として設計され、リージョン全体がダウンすることも想定されていました。
AIシステムも同様です。モデルプロバイダーが待ち時間の問題、劣化、または停止を経験することを前提として、冗長性を組み込んで、アプリケーションがさまざまな故障シナリオで堅牢性を維持できるようにする必要があります。
AIの回復性は、クラウドインフラストラクチャの決定におけるアップタイムや冗長性と同様に、プラットフォームやベンダーの選択において決定的な要因になるでしょうか？
AIシステムが本稼働に移行するにつれて、回復性は最低限の要件となります。ベンダーがアップタイムや全体的な回復性に関するグラフやメトリクスを示すことができない場合、検討されることはありません。回復性がベンダー全体でベースラインの期待値になると、決定要因はユーザーエクスペリエンス、パフォーマンスの最適化、観測可能性、またはより高度な製品機能にシフトします。時間の経過とともに、AIゲートウェイや自動フェイルオーバー機能などのコンポーネントは、企業のAIインフラストラクチャの基盤となる要素となります。
先を見て、継続的に利用可能であることが期待されるAIの世界で、「本稼働可能」なAIとは本当に何を意味しますか？
本稼働可能なAIシステムは、観測可能、制御可能、回復可能である必要があります。これらの3つの要素がすべて満たされている必要があります。
AIが本稼働可能であるためには、モデル動作、待ち時間、エラーレート、トークン使用、ドリフト、故障パターンに関する深い可視性が必要です。強力な観測可能性がなければ、ユーザーがそれらに気付く前に劣化を検出することは非常に難しいです。
システムが制御可能であるためには、トラフィックシェーピング、レート制限、ガードレール、ポリシーの適用、モデルやプロバイダー全体のインテリジェントなルーティングが含まれます。これは、AIゲートウェイが中央集約化された制御プレーンとして機能し、ガードレールを適用し、統一的なガバナンスを提供し、パフォーマンスや信頼性が低下したときに動的にモデルを切り替えることができる場所です。
最後に、回復可能であるという点では、コンポーネントが部分的または完全に壊れる可能性があることを前提としてシステムを設計する必要があります。プロバイダーの停止、モデル品質の低下、レート制限、または悪意のあるアクターからの予期せぬ入力によって発生する可能性があります。自動フェイルオーバーと自己修復メカニズムは、アーキテクチャにネイティブである必要があり、手動のプレイブックではなく、何かが間違った後にトリガーされるものではありません。
これが私たちがTrueFoundryで目指している方向です。信頼性、中央集約化された制御、自動回復をこのように定義するベンダーは、長期的な顧客の信頼を獲得し、新しい問題が発生するにつれてそれらを解決し続けることができます。
素晴らしいインタビュー、ご興味がある読者はTrueFoundryを訪問してください。
