Llama 3.1によって強化されたエージェント:関数呼び出し機能のテスト
Llama 3.1の関数呼び出しとツール使用の機能を探索してください。LangTraceなどの観測可能性ツールを使ってLLMのパフォーマンスを監視する方法を学びます。複雑なタスク処理における、さまざまなLlamaモデルサイズの長所と短所を発見してください。
2025年1月12日
Llama 3.1の関数呼び出し機能に関する包括的なガイドでその力を引き出しましょう。この最先端の言語モデルを知的エージェントとして活用し、APIとの連携によって複雑なタスクに取り組む方法を発見してください。モデルのパフォーマンスに関する観察可能性の側面を探り、次のプロジェクトに向けた明確な判断力を身につけましょう。
Llama 3.1とMeta's Agentic Systemの機能
LangTraceによる観察可能性の設定
Llama 3.1 70BおよびLlama 3.1 8Bモデルでの関数呼び出しのテスト
並列関数呼び出しとネストされた順次関数呼び出し
Llama 3.1 8Bモデルの関数呼び出しでの課題
関数呼び出しのためのGroq社のファインチューンしたLlama 3モデル
結論
Llama 3.1とMeta's Agentic Systemの機能
Llama 3.1とMeta's Agentic Systemの機能
3.1 LLAMAの主要な機能の1つとして、Meta社が強調したのが関数呼び出しやツール使用の機能です。著者はこの機能を検証しようと試みました。
著者は最初に必要なツールやAPIを設定しました。その中には、3.1 LLAMAとの対話に最も高速なAPIの1つであるGroqAPIも含まれています。著者は70億パラメータと8億パラメータの3.1 LLAMAモデル、そして70億パラメータモデルのGroq特化ファインチューンドバージョンを試しました。
著者は単純な関数呼び出しの例から始め、並列および入れ子の関数呼び出しを含むより複雑なシナリオへと進みました。LangTraceオブザーバビリティプラットフォームを使って、実験中のトークン使用量やその他のメトリクスを追跡しました。
結果として、70億パラメータの3.1 LLAMAモデルが非常に良好なパフォーマンスを示し、並列および入れ子の関数呼び出しに効果的に対応できることが分かりました。一方、8億パラメータモデルはより複雑なタスクで苦戦し、Groq特化ファインチューンドモデルはさらに多くの情報や明確化を必要としていました。
総じて、著者は70億パラメータの3.1 LLAMAモデルが関数呼び出しやエージェントのようなユースケースに最適であると結論付けました。LangTraceオブザーバビリティプラットフォームの有用性も強調されています。
LangTraceによる観察可能性の設定
LangTraceによる観察可能性の設定
このセクションでは、LLMアプリケーション用のオープンソースのオープンテレメトリーオブザーバビリティプラットフォームであるLangTraceを設定します。LangTraceを使うことで、ローカル環境とLLMAPIの間で送受信されるリクエストとトークンの数を追跡できます。
最初に、LangTracePythonSDK、GroqPythonSDK、OpenAIPythonSDK(OpenAILLMは使用しませんが、LangTraceSDKの依存関係)などの必要なパッケージをインストールする必要があります。
その後、APIキーを設定します。この実験では厳密にはLangTraceは必要ありませんが、トークン使用量に関する貴重な洞察を提供してくれます。LangTraceは、LangChainのLangSmithと同様の機能を持ちますが、OpenAI、Groq、Cohere、Perplexityなど、より幅広いベンダーをサポートしています。
クラウドホスト版のLangTraceを使用するため、新しいアカウントとプロジェクトを作成する必要があります。APIキーが手に入ったら、ノートブックのシークレットに追加できます。
設定が完了したら、LangTraceを使ってGroqLLMAPIでの関数呼び出し実験中のトークン使用量やその他のメトリクスを観察できます。LangTraceは、交換されたトークンの数や関連するコスト(該当する場合、Groqは APIの使用料を請求しません)について詳細な情報を提供してくれます。
LangTraceを使うことで、並列および入れ子の関数呼び出しのようなアドバンスド機能をテストする際に、LLMベースのアプリケーションのパフォーマンスと効率性に関する貴重な洞察が得られます。
Llama 3.1 70BおよびLlama 3.1 8Bモデルでの関数呼び出しのテスト
Llama 3.1 70BおよびLlama 3.1 8Bモデルでの関数呼び出しのテスト
著者はまず、Meta社がLlama 3.1でエージェントシステムの周りの関数呼び出し機能をリリースしたことを強調しています。著者はシステムをローカルに設定していないため、Llama 3.1との対話に最も高速なAPIの1つであるGroqAPIを使うことにしました。
著者は70億パラメータと8億パラメータのLlama 3.1モデル、そして70億パラメータモデルのGroq特化ファインチューンドバージョンをテストしました。LLMアプリケーション用のオープンソースオブザーバビリティプラットフォームであるLangTraceを使って、ローカル環境とLLMAPIの間で交換されるリクエストとトークンの数を追跡しました。
著者は最初に単純な例から始め、モデルが「ゲームスコアを取得」する関数を使ってNBAゲームの勝者を判断する必要がある場合を検証しました。70億パラメータモデルはこのタスクを正常に実行し、著者はLangTraceデータを調べてその内部メカニズムを理解しました。
その後、ユーザーが天気、フライト、ホテル、観光地に関する情報を求める並列関数呼び出しの能力をモデルに試しました。70億パラメータモデルは最初の問題文を分解し、並列関数呼び出しを行い、包括的な回答を生成できました。一方、8億パラメータモデルはこのタスクで苦戦し、情報をハルシネーションしたり、完全な回答を提供できませんでした。
著者はさらに複雑なシナリオを導入し、ユーザーがニューヨークからロンドン、そして東京への旅行を計画したいと要求しました。この場合も70億パラメータモデルが良好なパフォーマンスを示したのに対し、8億パラメータモデルは困難に直面しました。
最後に、著者はGroq特化ファインチューンドの70億パラメータモデルをテストしましたが、このモデルは「ゲームスコアを取得」する単純な課題でさえ苦戦し、提供された関数を使うのではなく、より詳細な情報を繰り返し求めていました。
結論として、著者は並列および入れ子の関数呼び出しの面で70億パラメータのLlama 3.1モデルが最高のパフォーマンスを示したと述べています。一方、8億パラメータモデルは深刻な関数呼び出しタスクには適していません。Groq特化ファインチューンドモデルもテストで低い成績を収めました。
並列関数呼び出しとネストされた順次関数呼び出し
並列関数呼び出しとネストされた順次関数呼び出し
Llama 3.1モデル、特に70億パラメータバージョンは、並列関数呼び出しと入れ子の順次関数呼び出しを処理する能力において印象的でした。
ニューヨークからパリへの旅行計画を立てるという複雑な問題提示に対し、70億パラメータモデルは課題を分解し、必要な情報を集めるために並列関数呼び出しを行うことができました。そして、各関数からの結果を組み合わせて、旅行の詳細を包括的にまとめることができました。
また、モデルは入れ子の関数呼び出しにも対応できることを示しました。映画視聴の推奨シナリオでは、ユーザーの好みに基づいて映画を選択し、さらに適切なスナックとストリーミングプラットフォームを推奨することができました。
これに対し、小さい8億パラメータのLlama 3.1モデルはこれらの高度なユースケースで苦戦しました。並列関数呼び出しや入れ子の関数呼び出しを一貫して正確かつ完全に処理することができませんでした。モデルはしばしば情報をハルシネーションしたり、提供されたツールを効果的に活用できませんでした。
さらに、Groqの専用関数呼び出しモデルもテストで低い成績を収めました。提供された関数を適切に活用できず、ユーザーにより具体的な入力を求めていました。
全体として、70億パラメータのLlama 3.1モデルは、並列および入れ子の関数呼び出しを含む複雑な多段階タスクを処理する強力な能力を示しており、有能なエージェントシステムとしての可能性を示しています。一方、小さい8億パラメータモデルやGroq関数呼び出しモデルはこの分野でまだ改善の余地があります。
Llama 3.1 8Bモデルの関数呼び出しでの課題
Llama 3.1 8Bモデルの関数呼び出しでの課題
8億パラメータのLlama 3.1モデルは、70億パラメータモデルに比べて、より複雑な関数呼び出しタスクで大幅に苦戦しました。主な観察点は以下の通りです。
-
単純な「ゲームスコアを取得」する関数については、8億パラメータモデルは70億パラメータモデルと同様に問題なく処理できました。
-
しかし、旅行計画のような並列関数呼び出しの場合、8億パラメータモデルは失敗しました。天気、フライト、ホテル、観光地に関する包括的な情報を提供できず、しばしば情報をハルシネーションしたり、利用可能なオプションを列挙できませんでした。
-
関数セットが拡張されると、8億パラメータモデルはさらに苦戦し、要求されていない イベントや天気の詳細をハルシネーションしていました。
-
8億パラメータモデルは、映画推奨タスクの入れ子の関数呼び出しでも問題を抱えていました。提供されたツールを適切に使用できず、代わりに直接映画を提案するだけでした。
-
Groqの専用関数呼び出しモデルもテストで低い成績を収めており、提供された機能を効果的に活用するのではなく、より具体的な詳細を求めていました。
これに対し、70億パラメータのLlama 3.1モデルは、並列および入れ子の関数呼び出しを処理する能力が非常に強く、包括的かつ正確な回答を提供できました。8億パラメータモデルは、深刻な関数呼び出しやエージェントのようなタスクには向いていないようです。Groqの専用モデルもこれらのテストで低い成績でした。
これらのLLM関数呼び出しの可視化とトレースには、オープンソースのLangTraceプラットフォームが有用なツールとなりました。
関数呼び出しのためのGroq社のファインチューンしたLlama 3モデル
関数呼び出しのためのGroq社のファインチューンしたLlama 3モデル
Groq特化ファインチューンドのLlama 3モデルは、70億パラメータのLlama 3.1モデルに比べて、関数呼び出しテストで苦戦しました。主な発見点は以下の通りです。
- ウォリアーズのゲームスコアを尋ねられた際、モデルは日付や対戦相手チームなどの詳細を求めたものの、提供された「ゲームスコアを取得」する関数を使うことはできませんでした。
- 旅行計画のリクエストに対しては、旅行日程などの詳細を繰り返し求めるだけで、提供された関数を使って回答を生成することができませんでした。
- 映画鑑賞の推奨タスクでは、入れ子の関数を活用するのに苦労し、代わりに直接映画の推奨を行うことが多かった。
全体として、Groq特化ファインチューンドのLlama 3モデルは、関数呼び出しとツール使用のテストにおいて、70億パラメータのLlama 3.1モデルほどの良好なパフォーマンスを示せませんでした。70億パラメータモデルは並列および入れ子の関数呼び出しに強い能力を示しましたが、特化モデルはツールや関数の活用に困難を抱えていました。さらなる最適化やファインチューニングが必要かもしれません。
結論
結論
Groqの70億パラメータLLAMA 3.1モデルは、関数呼び出しとツール使用のテストで非常に優れた成績を収めました。並列関数呼び出しと入れ子の関数呼び出しを容易に処理し、強力なエージェントシステムとしての能力を実証しました。
これに対し、8億パラメータのLLAMA 3.1モデルはこれらの複雑なタスクで苦戦し、より大規模で高性能なモデルの重要性を浮き彫りにしました。
しかし、Groq独自の関数呼び出しモデルは期待ほどの成績を収めることができませんでした。これは、このモデルのファインチューニングプロセスが十分ではなかった可能性を示唆しています。
オブザーバビリティとトレースの目的では、オープンソースのLangTraceAIプラットフォームが非常に有用なツールであることが証明されました。実験中のトークン使用量やAPIコールの詳細な洞察を提供してくれました。
全体として、結果はLLAMA 3.1のような大規模な言語モデルの関
よくある質問
よくある質問