「AI POC の95% が失敗する」と主張するその研究が広まっています。これはクリックベイトのナンセンスであり、率直に言って、誰の役にも立たない。実際の数字は?誰もそれを適切に追跡していないので、誰も知りません。しかし、チームが AI システムを構築するのを何年も見てきた結果、私が知っていることは、この研究ははるかに重要な問題を覆い隠しているということです。
チームは、デモ段階を超えて生き残るPOCを設計する方法について混乱しています。プレイブックはありません。
ほとんどのAI POCは、死ぬように設計されているため、死にます。これらは使い捨てのデモとして構築されており、本番環境の現実ではなく、エグゼクティブのプレゼンテーション用に最適化されています。それらはクラウドクレジットを使い果たし、完璧な条件と完璧に構造化されたデータに依存し、実際のユーザーがそれらに触れ始めるとすぐに崩壊します。それらが崩壊しなければ、多くの場合、規模が小さいと、設計上の問題が緊張して現れたときに崩壊し、より深刻な故障につながります。
しかし、そうである必要はありません。
Dockerやその他の場所で何百ものAIプロジェクトを見た後、成功する 5%と成功しない 95%を分けるパターンを見てきました。これは、すべてのプラットフォームとMLOpsチームが初日から持っていればいいと思うプレイブックです。
新しい基盤:Remocalワークフロー
ルールに入る前に、成功するチームが AI 開発に取り組む方法における最大の変化である、 リモート ワークフロー (リモート + ローカル) について話しましょう。
AI をローカルで実行することは、単にコストを節約することだけではありませんが、それは絶対にそうします。開発者の速度を維持し、デモシアターの罠を回避することです。最高のチームが仕事をどのように構成するかは次のとおりです。
- ラップトップでローカルにテストして 、高速な反復を実現します。クラウドリソースを待つ必要はなく、予期せぬ請求も必要ありませんし、フローを殺すネットワーク遅延もありません。AI を使用した構築の性質は、プロセスを非常にインタラクティブに感じさせることです。
- 大規模なテスト、本番環境のような検証、または実際にこれらの H100が必要な場合にリモート リソースにバーストします。AI ワークロードの移動は簡単だと感じるはずです。
- 初日からコストの透明性を保ちます。選択した場合にのみリモート コンピューティングに対して料金を支払うため、各実験のコストが正確にわかります。
ゼロ日目からこのパターンを取り入れたPOCは、暴走する請求と古典的な「デモで機能した」という大惨事の両方を回避します。それらは生産上の制約が組み込まれて構築されているため、現実に基づいています。
POCサバイバルの9つのルール
1。小さく始めて、小さくとどまる
あなたの第一直感は間違っています。最大のモデル、完全なデータセット、または考えられるすべての特徴は必要ありません。ラップトップに収まるモデル、実際に検査できるデータセット、そして 1 つの文で値を説明できるほど範囲が狭いなど、すべてが一口サイズです。
早期に勝利すると、信頼が複合的に増えます。うまくいくかもしれない小さなことは、うまくいくかもしれない大きなことに勝る。
2。ゼロ日からの生産のための設計
ロギング、監視、バージョン管理、ガードレールは、後で追加する「あると便利な」ものではありません。これらは、POC が実際のシステムに成長できるかどうかを決定する基盤です。
POCに構造化されたロギングと基本的な指標(オブザーバビリティ)が最初のコミットからない場合、本番システムのプロトタイプではなく、使い捨てのデモを構築していることになります。
3。新規性ではなく、再現性とモデルの改善のために最適化
インフラストラクチャはテンプレート化する必要があります。プロンプトテストはCI/CDで行う必要があります。モデル比較は、「今回は気分が良くなった」ではなく、同族のベンチマークであるべきです。さらに、POC 設計では、既存のモデル ファミリが急速に改善され続けることを想定できますし、そうすべきです。これには、より大きなコンテキストウィンドウ、より高い精度、より低いレイテンシー、およびより少ないリソース消費が含まれます。
AI の最もセクシーな部分は、新しいアルゴリズムではなく、AI を大規模に信頼性を高める方法で問題を組み立てることを学習する方法です。
4。フィードバックループで考える
これは、アマチュアアワーと本番対応システムを分ける大きなものです。非決定論的 AI コンポーネントを決定論的ビジネスロジックから分離します。制御と検証のレイヤーを構築します。ドメイン知識は今でもあなたの魔法の材料です。
remocal セットアップでは、エージェント ループをローカルで実行して高速イテレーションを行うことができ、ツールの実行と大量のコンピューティングは必要な場合にのみリモート リソースにバーストされます。信頼性は、モデルが良い一日を過ごすことを期待することからではなく、階層化された制御から得られます。
5。感動を与えるのではなく、痛みを解決する
すべてを測定可能なビジネス上の痛みに固定します。解決するために喜んでお金を払う実際の問題を抱えた実際のユーザー。POC の主な価値提案が「これがどれほどクールかを見てください」であるなら、あなたは間違ったものを構築しています。
スライドウェアでしか見栄えがしない虚栄心のデモを殺してください。実際の時間とお金を節約する退屈なソリューションを構築します。
6。コストとリスクの認識を早期に組み込む
初日からユニットの経済性を追跡します。各リクエストの費用はいくらですか?各ユーザー?各ワークフローは?
小規模モデルと大規模モデルのベンチマーク。クラウド実行とローカル実行。「クラウドの規模」について手を振るのではなく、実際の数字でトレードオフを把握します。
7。所有権を明確にする
午前 2 時に壊れたこのものは誰が所有しているのでしょうか?SLAとは何ですか?モデルの再トレーニングの責任者は誰ですか?コンピューティングの料金は誰が負担しますか?
POC が研究室と運用チームの間の組織の空白に漂わないようにしてください。所有者、責任、ライフサイクル管理を初日から割り当てます。
8。コストを事前に管理する
リクエスト、ユーザー、ワークフローごとの透明性のあるコスト。ハード予算の上限とキルスイッチ。毎月のクラウド請求に驚きはありません。
Remocal ワークフローはこれを自然にします: デフォルトでローカル実行を使用し、意識的にお金を使うことを選択した場合にのみリモートでバーストします。コストは意図的であるため、予測可能です。
9。ゼロ日目からユーザーを巻き込む
ChatGPT のデモを見て「すべてに AI を」望んでいる経営幹部ではなく、実際のユーザーと共同設計します。精度スコアだけでなく、導入と節約時間を測定します。
最高の AI POC は、実際に作業を行う人々と一緒に構築されているため、既存のワークフローの自然な拡張のように感じられます。
なぜこれが実際に重要なのか
失敗した AI POC のほとんどにはチャンスがありませんでした。それらは大きすぎて、高すぎて、実際の問題から切り離されすぎ、日常的な使用ではなくデモの日に最適化されすぎていました。
小規模から始めて、本番環境向けに設計し、実際のユーザーを巻き込み、リモカル ワークフローを構築するというスクリプトをひっくり返すことで、出荷および拡張可能なものを構築する可能性が劇的に高まります。
AI POC の成功と失敗の違いは、モデルの洗練さではありません。それは、ゼロ日目に下す退屈なエンジニアリング上の決定です。
AI POC を使い捨てのデモとして扱うのはやめましょう。それらを生産システムの最初のドラフトとして扱います。
Jim Clark は Docker の AI 担当プリンシパル エンジニアであり、実際に本番環境に移行する AI システムの構築を支援しています。彼は過去 10 年間、AI デモと AI 製品の間のギャップを観察し、時にはそれを埋めてきました。