バーナード・マーフィー、フリーランス著者兼アドバイザー。
生成AIの導入が停滞していると感じていますか？あなただけではありません。最近の報告によると、生成AIプロジェクトの95%が停滞または期待に届いていないとされています。
その根本原因として、効果的なプロンプト作成を含むツールと組織的な導入に関する学習ギャップが挙げられています。これはユーザーの不満の原因として過小評価されており、導入の停滞に大きく寄与していると私は考えます。
私たちは、人間の専門家に話しかけるのと同じように、自然言語でツールを操作できることを期待しています。適切な質問が有用な回答につながるはずだと考えます。しかし、リーダーたちは、自分が何を望んでいるかを知ることと、それを明確に伝えることは別のスキルであることを認識しています。この違いは、生成AIにプロンプトを与える際に増幅されます。
私は半導体/システム業界の複数のクライアントのマーケティングコンテンツを開発・促進しており、この業界でも他と同様に生成AIの取り組みが一般的です。詳細な技術とアプリケーションの研究でコンテンツを裏付けているため、独自の視点を持っています：私の業界は生成AIを使用するだけでなく、それが動作するハードウェアも構築しています。
適切なプロンプトを見つける険しい道
シンプルな目標を持つ短い一行のプロンプトは一般的に成功します。しかし、実際のアプリケーションでは、ツールを誘導するために指示を追加しようとして、プロンプトが数行や段落以上に及ぶと、問題やフラストレーションが生じることがあります。これは一般的な経験です。
関連性が高く広く引用されている研究では、プロフェッショナルのグループがチャットボットとどのように対話して、ベジタリアン天ぷらの調理法を案内する能力を向上させたかを調査しました。参加者は教育、研究、プログラミングなど様々な専門分野から集められ、AIの経験は誰も持っていませんでした。重要なのは、参加者がプロンプトを通じてボットを誘導し、正確で明確かつユーザーフレンドリーな指示を提供することを目指したことです。
研究結果は示唆に富んでいます。参加者のプロンプト試行は機会主義的でした：プロンプトを試し、うまくいかなければ、いくつかのアドホックな変更を試みる。それでもうまくいかなければ、ボットはその要求を処理できないと判断する。論文では、プロンプトの代替案を体系的に探索するアプローチがより効果的だと示唆していますが、ほとんどのカジュアルユーザーはそのような詳細な特性評価に必要な時間と労力を正当化するのに苦労するでしょう。
AIと話すことが人と話すことと異なる理由
他の発見は、人間同士のやり取りと人間とAIのやり取りの重要な違いを浮き彫りにしています。参加者は直接的な指示（例：これをしなさい、それを変えなさい）を好みましたが、これは私たちのほとんどにとって非常に自然なアプローチです。しかし、生成AIは直接的な指示よりも例から効果的に学ぶことが知られています。教師も例の価値を強調し、ストーリーテラーも「説明するより示せ」と言います。参加者は例を使うよう促されましたが、直接的な指示を続け、結果は良くありませんでした。
人間とAIのやり取りにおけるもう一つの重要な違いは、生成AIが「これをするな」などの否定的表現の扱い方を知らないことです。これはコア技術の根本的な制限であり、より多くのトレーニングで対処される可能性は低いでしょう。コマンドを複数回繰り返すことは生成AIでは効果的であることが証明されていますが、参加者はこのアプローチを他の人間とのやり取りで学んだ経験と衝突するため拒否しました。
この研究から私が得た教訓は、効果的なプロンプトスキルは生成AIの成功的な使用に不可欠ですが、それらは直感的ではない行動に依存しているということです。これらのスキルは学び、頻繁に強化する必要があります。
プレイブック、前進への道
エージェント型メソッドは比較的新しい概念で、複数のデータソースと分析を活用することで複雑なリクエストに対応する方法を提供します。一見すると、複雑な一連の目標に対応することでプロンプトの問題が悪化するように思えます。
プレイブックの背後にある考え方は、特定の目標に対する最適なプロンプト作成のプラクティスを学び、カプセル化することで、日常のユーザーがその複雑さの多くをバイパスできるようにすることです。この考え方を社内のクラウドソース学習と組み合わせることで、複数のアプリケーションにわたるプレイブック開発を加速し、好循環でプロンプトスキルを向上させることができると私は主張します。私が最も精通している分野である電子設計からの例を使用します。
プレイブックを実践に活かす
デバッグ—製造前の半導体設計テストで露呈した機能エラーを分離して割り当てること—は継続的な設計タスクであり、かなりの専門知識を必要とし、設計リソースの最大30%を消費します。この領域は自動化に抵抗してきており、効果的であるためには多様なデータソースとローカルな専門知識の組み合わせが必要です。エージェント型プレイブックは魅力的な潜在的解決策です。
デバッグ用のエージェント型ソリューションについてあるアーリーステージベンチャーとの対話で、彼らはこのプレイブック方式に基づいて構築しています。まず、望むことを説明するプロンプトから始めます。エージェントがこれについて考え、より詳細なプロンプトを返し、「これがあなたが確認してほしいことですか？」と尋ねます。
この自然言語フィードバックを必要に応じて微調整し、そこから完全な分析を開始できます。この新しいプロンプトはプレイブックですが、あなたが望むことを言うことと、AIがこの洗練されたプロンプトをどのように理解するかのギャップを管理する必要があります。プレイブックが期待通りに機能するかもしれませんし、期待ほどではないかもしれません。
今、複数のユーザーがそれぞれ独自のプロンプトに取り組み、一部は他よりも良い結果を出していると想像してください。成功したプレイブックは人気を博し、一部はこれらの成功に基づいて構築し、他は既知の成功を例として使用します。彼らは何がうまくいき、何がうまくいかないかについてアイデアを交換します。成功したプレイブックのライブラリが成長し、集団全体がより効果的にプロンプトを作成する方法を学びます。
結論は？エージェント型システム、プレイブック、チーム学習が導入のこの障害を排除できるということです。
