メインコンテンツにスキップ
ブログコンピュート新しいツールキットLLM、プロンプト、基本的なツール操作

新しいツールキットLLM、プロンプト、基本的なツール・インタラクション

新しいツールキット_LLMs_プロンプトと基本的なツールとの対話

LLMの相互作用は異なる。LLMは単にデータをスキーマと照合するのではなく、ツールや他のシステムができることを平易な言葉で記述したものを読み取る。開発者としては、呼び出されたLLMが私のインターフェースの操作方法を理解するために読み、利用し、最終的に利用できるような情報を公開しなければならない。LLMに厳密なスキーマを与えるわけではありません。その代わり、ツールの目的、入力、期待される結果を含む説明を提供する。

LLMは言語理解を使って、この説明に基づいてツールの使い方を理解する。それは、厳格な書式をチェックすることから、口頭による指示を理解することになるようなものだ。これは、特にあまり構造化されていないタスクの場合、より柔軟であるが、相互作用が解釈に依存することを意味し、厳密なフォーマットよりも予測可能性が低くなる可能性がある。この方法論は、モデル・コンテキスト・プロトコル(MCP)からグーグルのオープンソース・エージェント開発キットまで、様々なものに使われているのがわかるだろう

プロンプトは新しい "APIドキュメント"

つまり、LLMにとって "APIコントラクト "やドキュメンテーションとは、基本的にツールやケイパビリティを説明するために書くプロンプトのことだ。コード注釈やスキーマファイルを書く代わりに、開発者はLLMに伝える明確で詳細な説明を書くようになった:

  • 何をするかツールの主な機能。
  • 必要なもの必要な入力、おそらく例やフォーマットのヒント。
  • 何を返すか:期待される出力や行動。
  • ルール重要な制約やガイドライン

これは、プロンプト・エンジニアリングが極めて重要なスキルになりつつあることを意味する。これらのシステムが機能するためには、開発チームがLLMが確実に理解し、行動できるような指示を書けることが不可欠だ。

簡単な例:LLMのための「カレンダー・アシスタント」ツール

カレンダーのアシスタントのような、よりダイナミックなツールを思い浮かべて、LLMのために説明してみよう:

ツール全体の説明"これはカレンダーアシスタントツールです。新しいミーティングをスケジュールしたり、グループの空いている時間帯を見つけることができます。"

機能1:CreateMeeting プロンプト ツール名: CreateMeeting.説明カレンダーに新しい会議をスケジュールします。必要な入力 attendees (メールアドレスのリスト)、 subject (会議タイトルのテキスト)、 startTime (ミーティングを開始する日時。「明日の午後3時」や「来週の月曜日の朝」のように相対的な時間を解釈するようにしてください)、そして duration (長さを表すテキスト、例:「1時間」、「30分」)。オプション入力:場所(「会議室B」やビデオ通話リンクなどのテキスト)。最終的な会議の詳細を含む確認メッセージ、またはスケジューリングに失敗した場合はエラーで応答します(時間の競合、無効な出席者など)。開始時間や期間が曖昧な場合は、処理を進める前にユーザーに説明を求める。特に指定がない限り、時間はユーザーのローカルタイムゾーンを想定しています。

LLMがどのようにそれを使用するか(ユーザーの要求を解釈した後): CreateMeeting(出席者=)["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")

関数2:FindFreeTime プロンプト ツール名: FindFreeTime.説明指定された時間枠内で、グループで共通して利用可能な時間帯を検索します。必要な入力 attendees (メールアドレスのリスト)と duration (例:「1時間」)。オプション入力: timeWindow (「来週」、「今週金曜日の午後」、「今後3日以内」など、いつ探すかを記述するテキスト。指定がない場合のデフォルトは現在の勤務週)。利用可能な開始時間のリスト(日付と時間)、または共通のスロットが見つからなかったことを示すメッセージを返します。来週」のような相対的なウィンドウが使用されている場合は、検索される日付範囲を特定してください。特に指定がない限り、時間はユーザーのローカルタイムゾーンであると仮定する。

LLMがどのようにそれを使用するか(ユーザーの要求を解釈した後): FindFreeTime(出席者=)["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")

ここでは、プロンプトはLLMがリストをどのように扱うか、日付や期間のような潜在的にあいまいな入力をどのように解釈するか、さらにはどのようなときに説明を求めるかをガイドする。これは実際のLLMツールとのやりとりに近い。

課題曖昧さとプロンプトの正確さ(このシリーズのパート3への舞台設定)

開発者として初めてこのようなツールを作ると、『これはすごい!このようなエージェントを書くのは、まったく楽なことだ。そして、開発者の人生でよく起こるように、現実があなたを直撃する...。

カレンダー・アシスタントのプロンプトは、(「明日の午後3時」のような)いくつかのあいまいさを処理しようとする一方で、自然言語記述に依存することで、ソフトウェアが、あなたが本当に予期していなかったことを行うための新しいエキサイティングな方法を導入することができます。

これらの例を考えてみよう:

  • CreateMeeting リクエストが競合しています:
    • ユーザー:「今週の金曜日の午後、私とチャーリーのために2時間のミーティングを予約してください。
    • 問題:「金曜日の午後」は通常、午後12時以降か午後1時以降を意味する。「午後2時以前」は、競合の可能性があるか、非常に狭いウィンドウ(例えば、午後1時から午後2時)を作成します。プロンプトは、時間のような1つのパラメータ内で競合する制約をどのように扱うか、LLMに明確に指示しません。午後」を優先すべきか、「午後2時以前」を優先すべきか。競合をユーザに提示すべきでしょうか?
  • 曖昧な FindFreeTime リクエスト:
    • ユーザー:「来週、デイブとちょっと話す時間を見つけてください。
    • 問題:「クイックチャット」とは何ですか?durationパラメータは、"15分 "または "30分 "のような、より具体的なものが必要です。現在のプロンプトは期間を要求しており、デフォルトや「クイックチャット」のような曖昧な用語をどのように扱うかを指定していません。LLMは失敗するか、推測しなければならないかもしれません。
  • FindFreeTime の暗黙の前提:
    • ユーザー:「来週の水曜日のチームミーティングのために、1時間見つけてください。
    • 問題:「チーム」とは誰か?LLMは出席者のリスト(メールアドレス)を必要としている。プロンプトはこれを要求していますが、ユーザーリクエストはLLMが「チーム」のコンテキストを知っていることに依存しています。出席者リストが提供されないか、会話履歴から推測できない場合、良いインタラクションフローは、LLMが "Who is on the team? "と尋ねることを含むかもしれない。この場合、通話エージェントが別のエージェントに電話して、誰が「チーム」なのかを把握することができるかもしれません。
  • 時間帯指定なし:
    • ユーザー(ロンドン):「プリヤ(ニューヨーク)とのミーティングを明日の午前9時に予約してください。
    • 問題:それはロンドン時間の午前9時ですか、それともニューヨーク時間の午前9時ですか?現在のプロンプトには基本的な仮定(「特に指定がない限り、時間はユーザーのローカルタイムゾーンであると仮定する」)が含まれていますが、タイムゾーンを正しく扱うのは複雑です。ユーザーが指定せず、出席者が異なるタイムゾーンにいる場合はどうなるでしょうか?ツールは、タイムゾーンを処理するための洗練されたバックエンドロジックか、複数の場所が関係する場合、タイムゾーン情報を要求し、確認する方法について、プロンプトでより明示的な指示が必要です。単純な思い込みは、スケジューリングミスにつながるかもしれません。

これらの例は、適切なプロンプトがあっても、ユーザー要求のあいまいさ、矛盾する情報、または(時間帯のような)明示されていない仮定が、エラー、誤ったアクション、またはフラストレーションのたまる説明ループにつながる可能性があることを示している。LLMとAPIの相互作用の有効性は、ツールの機能と制限を説明するプロンプトの品質と完全性に直接依存する。ハッピーパスだけでなく、曖昧さ、欠落している情報、潜在的なコンフリクト、タイムゾーンのようなコンテキストの詳細をどのように扱うかをカバーする必要がある。

複雑になる:複数の人工知能 エージェントが話すとき(より深い問題への移行)

一つのツールを正確に記述することは一つのことであるが、複数の人工知能 エージェントが一緒に働こうとする場合には、もっと厄介なことになる。エージェントAがエージェントBにできること、できないこと、エージェントBが曖昧さをどのように扱うかを明確に理解できるように、どのようにプロンプトを書けばよいのでしょうか?どのように調整するのか?互いの指示をどう解釈するかによって引き起こされる予期せぬ問題なしに、確実に連携できるようにするにはどうすればいいのでしょうか?言語を使ってこれらの相互作用を明確かつ確実に定義する方法を見つけ出すことは、これらのシステムが進化するにつれて私たちが直面している大きな課題です。

アカマイがお客様の人工知能 ワークロードをどのようにスケールアップできるかをご覧ください。今すぐ当社のエキスパートにご相談ください。

こちらもどうぞ...

コメント 

コメントを残す

あなたのメールアドレスは公開されません。必須項目には*印がついています。