「従来のソフトウェア開発では、機能の深さやユーザーのニーズに基づいて、新製品の v1、v2、v3 を計画していました。AI システムを使用すると、レンズが変わります。 代わりに、各バージョンは、システムがどれだけの主体性を持っているか、そしてどれだけのコントロールを放棄しても構わないかによって定義されます。 まず、制御が高く、エージェンシーが低い一連の機能(下の画像のバージョン1)を特定します。 これらは小さく、テスト可能で、観察しやすいものでなければなりません。そこから、一度に 1 つのバージョンずつ、徐々にエージェンシーを増やすことで、これらの機能が時間の経過とともにどのように進化するかを考えます。目標は、高い最終状態を、評価、反復、向上構築できる初期の動作に分解することです。 たとえば、最終目標が社内のカスタマーサポートを自動化することである場合、v1 (バージョン 1) を単にチケットを適切な部門にルーティングするだけでスコープを設定し、システムが可能な解決策を提案する v2 に移行し、v3 でのみ人間によるフォールバックで自動解決できるようにするという高度な管理方法を開始することです。 さらにいくつかの例を示します。 マーケティングアシスタント v1: プロンプトからメール、広告、またはソーシャルコピーの下書きを作成する v2: マルチステップのキャンペーンを構築して実行する v3: チャネル全体でのキャンペーンの起動、A/B テスト、自動最適化 コーディングアシスタント v1: インライン補完と定型スニペットを提案する v2: 人間によるレビューのためにより大きなブロック (テストやリファクタリングなど) を生成する v3: スコープ付き変更を適用し、pull request (PR) を自律的に開く GitHub Copilot や Cursor などのツールがどのように進化したかを追ったことがあるなら、これはまさに彼らが使用したプレイブックです。ほとんどのユーザーは現在のバージョンしか表示しませんが、基盤となるシステムは徐々にそのはしごを登っていきました。最初に完了し、次にブロック、次に PR を行い、各ステップは使用、フィードバック、イテレーションを通じて獲得されます。」 詳細はこちら:
Lenny Rachitsky
Lenny Rachitsky20時間前
他の製品のようにAI製品を構築することはできません。 AI 製品は本質的に非決定論的であり、エージェンシーとコントロールの間のトレードオフを常に交渉する必要があります。 チームがこれらの違いを認識しないと、製品は予期しない障害に直面し、追跡できない大規模で複雑なシステムのデバッグに行き詰まり、製品に対するユーザーの信頼は静かに損なわれます。 @OpenAI、@Google、@Amazon、@Databricksを含む企業での50+のAI実装でこのパターンが展開されるのを見た後、Aishwarya Naresh RegantiとKiriti Badamは、継続的キャリブレーション/継続的開発(CC/CD)フレームワークというソリューションを開発しました。 この名前は、継続的インテグレーション/継続的デプロイメント(CI/CD)への言及ですが、その名前とは異なり、動作が非決定論的であり、エージェンシーを獲得する必要があるシステムを対象としています。 このフレームワークは、次の方法を示します。 - 高度な制御、低エージェンシーの機能から始める - 実際に機能する評価システムを構築する - ユーザーの信頼を損なうことなくAI製品を拡張 AI システムの独自性を認識し、より意図的で安定した信頼できる AI 製品の構築を支援するように設計されています。 彼らは初めてそれを公開しています。
40.58K