GPT-4o Mini est le dernier et le plus rentable des modèles d'OpenAI, et c'est l'un des modèles les plus performants dans sa gamme de prix. Cependant, la question reste de savoir à quel point ce modèle est bon pour créer des agents, en particulier des agents de génération augmentée par la recherche (RAG) ?

Dans cette section, nous explorerons les performances de GPT-4o Mini par rapport au modèle Anthropic Cloud 3.5 Sonnet, qui est un choix populaire pour la RAG agentique. Nous utiliserons un jeu de données pratique, le jeu de données d'embeddings Airbnb de MongoDB, pour tester les capacités de ces modèles.

Le jeu de données contient diverses colonnes de métadonnées, et nous prétraiterons les données pour créer une entrée adaptée au pipeline RAG. Nous utiliserons Llama Index pour mettre en place l'implémentation de la RAG, en tirant parti de ses capacités agentiques.

Pour le LLM ou l'agent, nous utiliserons à la fois GPT-4o Mini et Cloud 3.5 Sonnet, et pour le VectorDB, nous nous appuierons sur ChromaDB. Nous passerons en revue le processus de configuration, y compris l'installation des bibliothèques requises, la configuration des variables d'environnement et la configuration des modèles LLM et d'embeddings.

Après avoir configuré l'environnement, nous nous plongerons dans les étapes de chargement et de traitement des données, où nous créerons les structures de données nécessaires pour le pipeline RAG. Cela inclut la conversion des données en un DataFrame pandas, la suppression des embeddings de texte existants et la création d'un modèle de métadonnées à utiliser dans le processus d'embeddings.

Enfin, nous configurerons le magasin de vecteurs à l'aide de ChromaDB et définirons l'outil de moteur de requête qui sera disponible pour l'agent. Nous créerons ensuite le worker agent et interagirons avec lui à l'aide de la fonction de chat, en comparant les performances de GPT-4o Mini et de Cloud 3.5 Sonnet dans les tâches de RAG agentique.

À la fin de cette section, vous aurez une meilleure compréhension des capacités de GPT-4o Mini dans le contexte de la RAG agentique et de la façon dont il se compare au modèle plus puissant Cloud 3.5 Sonnet.

Pour commencer, nous devons d'abord configurer les bibliothèques et les variables d'environnement requises. Nous installerons les packages nécessaires, notamment Llama Index, OpenAI et ChromaDB.

Ensuite, nous configurerons les variables d'environnement, y compris la clé API OpenAI et le jeton Hugging Face (si nécessaire).

Nous configurerons ensuite le modèle de langage (LLM) et les modèles d'embeddings. Pour le LLM, nous utiliserons le modèle GPT-4 OM Mini. Pour les embeddings, nous utiliserons le petit modèle OpenAI TextEmbedding3, qui nous permet de personnaliser la taille des embeddings afin de réduire les coûts de calcul et de stockage.

Après avoir configuré les modèles, nous passerons au chargement et au traitement des données. Nous utiliserons le jeu de données d'embeddings Airbnb de MongoDB, en nous concentrant sur les 2 000 premiers points de données pour garder le temps de traitement et les coûts gérables.

Nous supprimerons les embeddings de texte existants et créerons nos propres vecteurs d'embeddings à l'aide des embeddings OpenAI. Nous extrairons également les métadonnées pertinentes du jeu de données, telles que le nom de la liste, le résumé, les règles de la maison, le type de propriété, le type de chambre, et le nombre de chambres et de lits. Ces métadonnées seront utilisées pour enrichir le texte que le LLM verra pendant le processus de recherche.

Pour préparer les données pour le magasin de vecteurs, nous diviserons le texte en morceaux de 5 000 caractères et créerons des nœuds contenant le texte, les vecteurs d'embeddings et les métadonnées. Enfin, nous configurerons le magasin de vecteurs ChromaDB pour stocker les nœuds, qui seront utilisés comme base de connaissances pour le workflow de RAG agentique.

Pour embedder le jeu de données Airbnb, nous convertissons d'abord le jeu de données en une liste de documents JSON. Nous créons ensuite un modèle de métadonnées qui inclut des informations importantes telles que le nom de la liste Airbnb, le résumé, les règles de la maison, le type de propriété, le type de chambre, le type de chambre, le nombre de chambres et le nombre de lits. Ces métadonnées sont ajoutées au texte qui sera embedé.

Ensuite, nous divisons le texte en morceaux de 5 000 caractères pour nous assurer que chaque vecteur d'embeddings puisse capturer les informations pertinentes. Nous calculons ensuite les embeddings à l'aide du petit modèle OpenAI TextEmbedding3, ce qui nous permet de personnaliser la taille des embeddings afin de réduire les coûts de calcul et de stockage.

Après avoir calculé les embeddings, nous les stockons dans un magasin de vecteurs ChromaDB, qui servira de base de connaissances à notre agent. Nous créons une QueryEngineToolClass qui donnera à l'agent l'accès au magasin de vecteurs, lui permettant de récupérer les morceaux de texte les plus pertinents en fonction de la requête de l'utilisateur.

En prétraitant les données, en créant un modèle de métadonnées et en configurant le magasin de vecteurs, nous avons préparé le jeu de données Airbnb pour une utilisation avec l'agent Llama Index. Ce processus garantit que l'agent a accès aux informations nécessaires pour fournir des réponses précises et informatives aux requêtes des utilisateurs.

Pour commencer, nous devons d'abord configurer les bibliothèques et les variables d'environnement requises. Nous installerons les packages nécessaires, notamment Llama Index, ChromaDB et les modèles OpenAI.

Ensuite, nous configurerons nos modèles LLM et d'embeddings. Pour le LLM, nous utiliserons le modèle GPT-4 OM Mini, et pour les embeddings, nous utiliserons le petit modèle OpenAI TextEmbedding3.

Nous chargerons et prétraiterons ensuite le jeu de données Airbnb, en supprimant les embeddings de texte existants et en créant nos propres morceaux de texte enrichis de métadonnées. Ces morceaux seront embedés et stockés dans un magasin de vecteurs ChromaDB.

Pour créer l'outil de moteur de requête, nous utiliserons la classe QueryEngine de Llama Index, qui donnera accès au magasin de vecteurs et nous permettra de récupérer les k meilleurs morceaux les plus similaires pour une requête donnée. Nous définirons cet outil dans la base de connaissances de l'agent.

Enfin, nous créerons le worker agent, qui combine le LLM et l'outil de moteur de requête, nous permettant d'interagir avec l'agent et de récupérer les meilleures listes Airbnb pour un emplacement donné.

Les étapes clés de ce processus sont :

1. Configurer les bibliothèques et les variables d'environnement requises.
2. Configurer les modèles LLM et d'embeddings.
3. Charger et prétraiter le jeu de données Airbnb.
4. Créer le magasin de vecteurs à l'aide de ChromaDB.
5. Définir l'outil de moteur de requête et l'ajouter à la base de connaissances de l'agent.
6. Créer le worker agent en combinant le LLM et l'outil de moteur de requête.

Avec ces étapes, nous avons mis en place l'infrastructure nécessaire pour utiliser le modèle GPT-4 OM Mini pour les tâches de RAG agentique sur le jeu de données Airbnb.

Pour créer le worker agent, nous définissons d'abord les outils qui seront disponibles pour l'agent. Dans ce cas, nous utilisons la classe QueryEngineToolV2 de Llama Index, qui donne accès au magasin de vecteurs que nous avons créé précédemment.

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]

Ensuite, nous créons le worker agent à l'aide de la classe FunctionCallingAgentWorker de Llama Index. Nous fournissons la liste des outils et le modèle de langage (GPT-4 Mini dans ce cas) au worker agent.

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

Maintenant, nous pouvons utiliser la fonction chat de l'agent pour interagir avec lui. Nous pouvons fournir à l'agent une invite, et il utilisera les outils pour générer une réponse.

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

La réponse de l'agent inclura le processus de réflexion et la réponse finale. Dans ce cas, la réponse de l'agent GPT-4 Mini n'est pas aussi détaillée ou perspicace que la réponse de l'agent Anthropic 3.5 Sonnet.

Pour comparer les performances, nous pouvons également essayer une invite différente, comme "Quelle est la pire liste Airbnb à Miami ?". L'agent Anthropic 3.5 Sonnet fournit une réponse plus réfléchie et nuancée, reconnaissant les limites de la base de connaissances et fournissant des informations générales sur les différences entre les locations de vacances à New York et à Miami.

Dans l'ensemble, la mise en œuvre du worker agent à l'aide de Llama Index est simple, mais les performances de l'agent dépendent des capacités du modèle de langage sous-jacent. Le modèle Anthropic 3.5 Sonnet semble mieux adapté aux workflows agentiques par rapport au modèle GPT-4 Mini.

Dans cette section, nous comparons les performances de GPT-4o Mini et de Cloud 3.5 Sonnet en tant qu'agents dans un workflow pratique de RAG (Génération Augmentée par la Recherche) agentique à l'aide du jeu de données d'embeddings Airbnb de MongoDB.

Les principales conclusions sont :

1. GPT-4o Mini en tant qu'agent : Bien que GPT-4o Mini soit un modèle capable, il a du mal avec le workflow agentique. Le processus de réflexion du modèle n'est pas bien articulé, et les réponses manquent du niveau de détail et de précision attendu d'un agent efficace.

2. Cloud 3.5 Sonnet en tant qu'agent : En revanche, Cloud 3.5 Sonnet démontre des performances supérieures en tant qu'agent. Il reformule les invites de manière efficace, utilise l'outil de base de connaissances pour rassembler les informations pertinentes et fournit des réponses détaillées et précises, même lorsque la base de connaissances ne contient pas d'informations spécifiques sur le sujet demandé.

3. Importance des LLM puissants pour les workflows agentiques : La comparaison met en évidence l'importance d'utiliser un LLM plus puissant et capable, comme Cloud 3.5 Sonnet, pour les workflows agentiques. La capacité de l'agent à comprendre le contexte, à reformuler les invites et à générer des réponses de haute qualité est cruciale pour une exécution efficace des tâches et une interaction utilisateur réussie.

En résumé, bien que GPT-4o Mini soit un modèle rentable, il peut ne pas être le meilleur choix pour les workflows agentiques qui nécessitent un agent plus sophistiqué et articulé. Cloud 3.5 Sonnet, en revanche, démontre des performances supérieures dans ce cas d'utilisation, illustrant les avantages de l'utilisation d'un LLM plus capable pour les applications basées sur les agents.

La comparaison entre GPT-4o Mini et le modèle Anthropic Cloud 3.5 Sonnet pour les tâches de RAG (Génération Augmentée par la Recherche) agentique met en évidence l'importance des capacités du modèle lorsqu'il s'agit de workflows basés sur les agents. Bien que GPT-4o Mini soit un modèle capable et rentable, il est en deçà dans les aspects agentiques de la tâche, comme le démontrent sa reformulation d'invite simpliste et ses réponses moins détaillées.

En revanche, le modèle Anthropic Cloud 3.5 Sonnet fait preuve d'un comportement agentique plus robuste et sophistiqué. Il reformule efficacement les invites, rassemble les informations pertinentes à partir de la base de connaissances et fournit des réponses détaillées et perspicaces, même face à une requête sur un emplacement absent du jeu de données.

Cette comparaison souligne la nécessité de bien prendre en compte les capacités du modèle lors de la conception de workflows basés sur les agents. Bien que GPT-4o Mini puisse convenir à certaines tâches, les applications agentiques plus complexes peuvent nécessiter l'utilisation d'un modèle plus puissant et spécialisé, comme Anthropic Cloud 3.5 Sonnet, pour atteindre le niveau de performance et d'expérience utilisateur souhaité.