信頼できるビジネスコンテキストを、本番環境に対応したドメイン特化型のAIエージェントに変換する方法をご紹介します。
によって Megan Tupper による投稿
• Genieエージェントは、1つのプロンプトから信頼できるビジネスコンテキストをドメイン特化型のAIエージェントに変換します。Unity Catalogによってガバナン スされた構造化データ、ドキュメント、ファイルを横断して推論できます。
• エージェントの回答が不十分であったり一貫性がなかったりする原因のほとんどは、プロンプトではなくコンテキストの不足にあります。信頼できるデータ、定義、ドキュメントにエージェントをグラウンディングさせることで、Genieエージェントはプロンプトを常に微調整する必要性をなくします。
• 1つの焦点を絞ったユースケースから始めることで、エージェントのテストと信頼が容易になります。最初のバージョンのスコープ設定とベンチマークを行うことで、チームはより多くのナレッジ、ツール、定期的なワークフローを追加して拡張できる、信頼性の高い基盤を得ることができます。
一般的なエージェントに収益について尋ねると、財務部門が実際に管理しているテーブルではなく、最初に見つかった収益テーブルを取得してしまう可能性が高くなります。まずプロンプトを修正しようと思うかもしれません。しかし、本当の問題はプロンプト自体ではなく、エージェントがリクエストを解釈するために必要なビジネスコンテキストを欠いていることにあります。
DatabricksのGenieエージェントは、構造化データだけでなくドキュメントやファイルも推論して業務を自動化できる、ドメイン特化型のエージェントをキュレートできるようにすることで、このコンテキストの問題を解決します。 たとえば、営業案件データエージェントはガバナンスされたCRMテーブルからパイプラインのリスクを明らかにし、物 流管理エージェントはサプライチェーンデータ全体で出荷を追跡して遅延を警告し、製品ライン検索エージェントは社内カタログから詳細な製品の質問に答えることができます。以前は、Genieエージェントの作成には手動での構成が必要でした。現在では、Unity Catalogのコンテキストとユーザーの会話を活用し、Genie OneやGenie Codeを使用して、たった1つのプロンプトで効果的なGenieエージェントを迅速に立ち上げることができます。
1つのプロンプトから始めて、わずか数分で最初のエージェントを作成できます。多くの場合、プロンプトはエージェントの期待される成果を説明し、関連する情報ソースをGenieに指示するだけで十分です。
次の例を考えてみましょう。「インシデントのランブックとサービスヘルスのデータを使用して、サポートエンジニアが本番環境のインシデントを調査するのを支援するエージェントを作成してください。」
プロンプトはシンプルですが、Genieが開始するのに十分な情報を提供します。問題を特定し、エージェントが使用すべきソースを指示しています。
もちろん、エージェントの品質はコンテキストの品質に依存します。Genieエージェントは、Unity Catalogですでにガバナンスされているデータ、ドキュメント、ファイルを推論するため、実際の作業はそれらの信頼できるソースをキュレートするこ とです。これらが整えば、Genieはそれらをエージェントに組み立てることができます。ITエージェントの場合、そのコンテキストにはFAQ、サポートドキュメント、インシデントランブック、システムインベントリ、サービスデータなどが含まれるでしょう。データエージェントの場合、ガバナンスされたテーブル、メトリックの定義、ダッシュボード、データ品質ルール、社内ドキュメントなどが含まれる可能性があります。
コンテキストは構造化データに限定されません。Genieエージェントは、Unity Catalogボリュームに保存されているPDF、Word文書、プレゼンテーション、画像などの非構造化データを推論することもできます。誰かが質問すると、エージェントは最も関連性の高いファイルコンテンツを取得し、ガバナンスされたテーブルと一緒に推論して回答を生成します。この際、常に質問した人の権限が使用されます。つまり、インシデント調査エージェントは実際のランブックのPDFを利用でき、製品ライン検索エージェントは実際の製品ドキュメントから情報を取得できます。
Genieエージェントは複雑でマルチステップのワークフローをサポートできますが、最適なスタート地点は通常、繰り返しの分析や作業を必要とする、焦点を絞った分かりやすい課題です。ユースケースを絞り込むことで、エージェントが正しいソースに基づいており、期待通りに動作するかどうかを確認しやすくなり、スコープ設定やベンチマークがより有意義になります。
先ほどのインシデント調査エージェントを例にとってみましょう。展開する前に、根本原因がすでに判明している過去のいくつかのインシデントに対して実行し、正しい結論に達するかどうかだけでなく、そこに到達するために正しいランブックやサービスヘルスデータを引用しているかどうかも確認します。もし古いランブックや間違ったサービスに依存している場合は、それはプロンプトを書き直す必要があるのではなく、キュレートすべきコンテキストがあることを示しています。
Genieエージェントには、このための組み込みのベンチマークが含まれています。テスト質問のセットを定義し、それぞれに期待される回答を設定して実行することで、エージェントの精度スコアを取得できます。変更を加えるたびにそのベンチマークを再実行することで、エージェントが「良くなった気がする」という曖昧な感覚を、追跡可能な測定可能な数値に変換できます。また、モニタータブにはユーザーが送信した実際の質問やフィードバックが表示されるため、拡張する際に見つかった新たなギャップをベンチマークに反映させることができます。
最初のユースケースが稼働したら、さらに多くのナレッジやデータソースを追加できます。拡張するたびに、すでにテスト済みのバージョンをベースに構築していくことができます。たとえば、営業案件データエージェントは、パイプラインのリスクを明らかにする段階から、取 引概要のドラフト作成やセグメント別の勝率に関する質問への回答へと発展させることができます。物流管理エージェントは、遅延の警告から、ルート変更の推奨や配送業者のパフォーマンスの経時的な監視へと拡張できます。製品ライン検索エージェントは、カタログの質問への回答から、製品の比較やドキュメントが不足している箇所の特定へと移行できます。
適切なスタート地点としては、製品FAQからの質問への回答、一般的な本番環境インシデントの調査、クラウドコストの変動の説明、定義されたデータパイプラインの監視などが挙げられます。ユースケースや部門を超えた共通点は、各エージェントが1つの明確なタスクから始まるということです。
1つのプロンプトによるエージェント作成は、ドキュメントやドメインの専門知識に代わるものではありません。チームがそれらの投資を、人々がセルフサービスで利用できるものへと迅速に変換するための手段を提供するにすぎません。土台が優れているほど、エージェントも優れたものになります。メトリックビュー、ドメイン、認定など、キュレートされたUnity Catalogのセマンティクスこそが、一貫性のある信頼できる回答を生成するためにプロンプトが実際に利用するものです。
プロンプトはプロセスを開始しますが、エージェントの品質は依然としてその背後にあるナレッジとシステムに依存します。ここでデータやITのリーダーが違いを生み出します。ガバナンスされ、明確に定義されたコンテキストへの投資こそが、エージェントの品質に直接反映されるのです。
効果的なエージェントは、明確なビジネスニーズと、それに対処するために必要な信頼できるコンテキストから始まります。
最も早く効果を実感する方法は、1つの焦点を絞ったユースケースから始めることです。例：
Genieエージェントを使用すると、既存のデータ、ドキュメント、ワークフローを1つのプロンプトからドメイン特化型のエージェントに変換し、時間の経過とともにスコープ設定、ベンチマーク、拡張を行うことができます。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします 。