GPT-4o Miniは、OpenAIの最新で最も費用対効果の高いモデルであり、その価格帯では最高のパフォーマンスを発揮しています。しかし、この模型がエージェントの作成、特に能動的な検索支援型生成(RAG)に適しているかどうかは疑問が残ります。

このセクションでは、GPT-4o Miniの性能をAnthropicのCloud 3.5 Sonnetモデルと比較します。Cloud 3.5 Sonnetは能動的RAGに人気のモデルです。実践的なデータセットであるAirbnbのエンベディングデータセット(MongoDB提供)を使って、これらのモデルの機能を検証します。

このデータセットには様々なメタデータ列があり、RAGパイプラインに適したインプットを作成するためにデータを前処理します。Llama Indexを使ってRAG実装を設定し、その能動的な機能を活用します。

LLMまたはエージェントには、GPT-4o MiniとCloud 3.5 Sonnetの両方を使用し、ベクトルDBにはChromaDBを使用します。セットアッププロセスを説明し、必要なライブラリのインストール、環境変数の設定、LLMおよびエンベディングモデルの構成について説明します。

この環境を設定した後、データのロードと処理の手順に入ります。ここでは、RAGパイプラインに必要なデータ構造を作成します。これには、データをpandasデータフレームに変換し、既存のテキストエンベディングを削除し、エンベディングプロセスで使用するメタデータテンプレートを作成することが含まれます。

最後に、ChromaDBを使ってベクトルストアを設定し、エージェントが使用できるクエリエンジンツールを定義します。次に、エージェントワーカーを作成し、チャット機能を使ってインタラクションを行い、GPT-4o MiniとCloud 3.5 Sonnetのパフォーマンスを比較します。

このセクションを終えると、能動的RAGの文脈におけるGPT-4o Miniの機能と、より強力なCloud 3.5 Sonnetモデルとの比較について、より深い理解が得られるはずです。

始めるには、まず必要なライブラリと環境変数を設定する必要があります。Llama Index、OpenAI、ChromaDBなどの必要なパッケージをインストールします。

次に、OpenAIのAPIキーやHugging Faceのトークン(必要な場合)などの環境変数を設定します。

その後、LLM(Language Model)とエンベディングモデルを設定します。LLMには、GPT-4 OM Miniモデルを使用します。エンベディングには、計算とストレージのコストを削減するために、OpenAIのTextEmbedding3 smallモデルを使用します。

モデルの設定が完了したら、データのロードと処理に移ります。MongoDBのAirbnbエンベディングデータセットを使用し、処理時間とコストを管理するため、最初の2,000データポイントに焦点を当てます。

既存のテキストエンベディングを削除し、OpenAIのエンベディングを使って独自のエンベディングベクトルを作成します。また、リスト名、概要、ハウスルール、物件タイプ、部屋タイプ、ベッドルームの数、ベッドの数などの関連メタデータを抽出します。このメタデータは、検索プロセス中にLLMが参照する情報を豊かにするために使用されます。

ベクトルストアの準備として、テキストを5,000文字のチャンクに分割し、テキスト、エンベディングベクトル、メタデータを含むノードを作成します。最後に、ChromaDBベクトルストアを設定して、ノードを格納します。これがアクティブRAG(検索支援型生成)ワークフローのナレッジベースとして使用されます。

Airbnbデータセットをエンベディングするために、まずデータセットをJSONドキュメントのリストに変換します。次に、Airbnbリスティングの名称、概要、ハウスルール、物件タイプ、部屋タイプ、ベッドルームタイプ、ベッドルームの数、ベッドの数などの重要な情報を含むメタデータテンプレートを作成します。このメタデータはエンベディングされるテキストに追加されます。

その後、各エンベディングベクトルが関連情報を適切にキャプチャできるよう、テキストを5,000文字のチャンクに分割します。次に、計算とストレージのコストを削減するために、カスタマイズ可能なサイズのエンベディングを提供するOpenAIのTextEmbedding3 smallモデルを使ってエンベディングを計算します。

エンベディングの計算が完了したら、ChromaDBベクトルストアに保存します。これがエージェントのナレッジベースとして機能します。QueryEngineToolClassを作成し、ベクトルストアへのアクセスを提供します。これにより、エージェントはユーザーのクエリに最も関連性の高いテキストチャンクを検索できるようになります。

データの前処理、メタデータテンプレートの作成、ベクトルストアの設定により、AirbnbデータセットをLlama Indexエージェントで使用できるように準備しました。このプロセスにより、エージェントがユーザーのクエリに正確で有益な回答を提供するために必要な情報にアクセスできるようになります。

始めるには、まず必要なライブラリと環境変数を設定する必要があります。Llama Index、ChromaDB、OpenAIモデルなどの必要なパッケージをインストールします。

次に、LLMとエンベディングモデルを設定します。LLMにはGPT-4 OM Miniモデルを、エンベディングにはOpenAIのTextEmbedding3 smallモデルを使用します。

その後、Airbnbデータセットをロードして前処理します。既存のテキストエンベディングを削除し、メタデータ付きのテキストチャンクを作成します。これらのチャンクをエンベディングし、ChromaDBベクトルストアに保存します。

クエリエンジンツールを作成するには、Llama IndexのQueryEngineツールクラスを使用します。これにより、ベクトルストアにアクセスでき、与えられたクエリに対して最も類似したトップkのチャンクを検索できます。このツールをエージェントのナレッジベースの一部として定義します。

最後に、LLMとクエリエンジンツールを組み合わせてエージェントワーカーを作成し、エージェントと対話して特定の場所に最適なAirbnbリスティングを検索できるようにします。

このプロセスの主なステップは以下の通りです:

1. 必要なライブラリと環境変数を設定する。
2. LLMとエンベディングモデルを構成する。
3. Airbnbデータセットをロードして前処理する。
4. ChromaDBを使ってベクトルストアを作成する。
5. クエリエンジンツールを定義し、エージェントのナレッジベースに追加する。
6. LLMとクエリエンジンツールを組み合わせてエージェントワーカーを作成する。

これらのステップを踏むことで、Airbnbデータセットに対する能動的RAGタスクでGPT-4 OM Miniモデルを使用するための基盤が整いました。

エージェントワーカーを作成するには、まずエージェントが利用可能なツールを定義します。今回は、前に作成したベクトルストアにアクセスできるLlama IndexのQueryEngineToolV2クラスを使用します。

query_engine_tool = QueryEngineToolV2(
    "Knowledge base",
    "Provides information about Airbnb listings and reviews, use a detailed plain text question as input to the tool.",
    self.vector_store
)
tools = [query_engine_tool]

次に、Llama IndexのFunctionCallingAgentWorkerクラスを使ってエージェントワーカーを作成します。ツールのリストとLanguageModel(今回はGPT-4 Mini)を提供します。

agent_worker = FunctionCallingAgentWorker(
    tools,
    self.llm,
    verbose=True
)
self.agent = agent_worker

これで、エージェントのchat関数を使ってエージェントと対話できるようになりました。プロンプトを提供すると、ツールを使ってレスポンスを生成します。

prompt = "Tell me the best listing for a place in New York."
result = self.agent.chat(prompt)
print(result)

エージェントのレスポンスには、思考プロセスと最終的な回答が含まれます。この場合、GPT-4 Miniエージェントのレスポンスは、Anthropic 3.5 Sonnetエージェントのレスポンスほど詳細や洞察的ではありません。

パフォーマンスを比較するために、別のプロンプト「マイアミの最悪のAirbnbリスティングは何ですか?」を試してみることもできます。Anthropic 3.5 Sonnetエージェントは、より思慮深く微妙な回答を提供し、ナレッジベースの制限を認識し、ニューヨークとマイアミの別荘レンタルの違いについての一般的な洞察を示しています。

全体として、Llama Indexを使ったエージェントワーカーの実装は簡単ですが、エージェントのパフォーマンスは基盤となるLanguageModelの機能に依存します。Anthropic 3.5 Sonnetモデルは、GPT-4 Miniモデルに比べて、能動的なワークフローにより適しているようです。

このセクションでは、実践的な能動的RAG(検索支援型生成)ワークフローにおける、GPT-4o MiniとCloud 3.5 Sonnetのパフォーマンスを比較しました。

主な知見は以下の通りです:

1. エージェントとしてのGPT-4o Mini: GPT-4o Miniは優れたモデルですが、能動的なワークフローには苦戦しています。モデルの思考プロセスが十分に明確に表現されておらず、期待される詳細さと正確さのレベルに達していないレスポンスになっています。

2. エージェントとしてのCloud 3.5 Sonnet: これに対し、Cloud 3.5 Sonnetはエージェントとしての優れたパフォーマンスを示しています。プロンプトを効果的に書き換え、ナレッジベースツールを使って関連情報を収集し、データセットに特定の情報がない場合でも詳細で正確なレスポンスを提供しています。

3. 能動的ワークフローには強力なLLMが重要: この比較は、能動的ワークフローには、Cloud 3.5 Sonnetのような、より強力で高度なLLMを使用することの重要性を示しています。コンテキストを理解し、プロンプトを書き換え、高品質のレスポンスを生成する能力は、タスクの効果的な完了とユーザーとのインタラクションに不可欠です。

要約すると、GPT-4o Miniは費用対効果の高いモデルですが、より洗練された能動的エージェントを必要とするワークフローには適していない可能性があります。一方、Cloud 3.5 Sonnetはこのユースケースで優れたパフォーマンスを示しており、エージェントベースのアプリケーションにはより高度なLLMの使用が有益であることを示しています。

GPT-4o MiniとAnthropicのCloud 3.5 Sonnetの能動的RAG(検索支援型生成)タスクの比較は、エージェントベースのワークフローにおけるモデル機能の重要性を浮き彫りにしています。GPT-4o Miniは優れたモデルでコストパフォーマンスが高いものの、エージェントの側面では不足していることが示されました。プロンプトの書き換えが単純で、レスポンスの詳細さも不足しています。

これに対し、Anthropic Cloud 3.5 Sonnetモデルは、より堅牢で洗練された能動的な振る舞いを示しています。プロンプトを効果的に書き換え、ナレッジベースから関連情報を収集し、データセットに存在しない場所についても詳細で洞察的なレスポンスを提供しています