GPT-4o Mini es el último y más rentable modelo de OpenAI, y es uno de los modelos con mejor rendimiento en su rango de precios. Sin embargo, la pregunta sigue siendo: ¿qué tan bueno es este modelo para crear agentes, específicamente Generación Aumentada por Recuperación (RAG) agentica?

En esta sección, exploraremos el rendimiento de GPT-4o Mini en comparación con el modelo Anthropic Cloud 3.5 Sonnet, que es una opción popular para RAG agentica. Utilizaremos un conjunto de datos práctico, el conjunto de datos de incrustaciones de Airbnb de MongoDB, para probar las capacidades de estos modelos.

El conjunto de datos contiene varias columnas de metadatos, y preprocesaremos los datos para crear una entrada adecuada para la canalización RAG. Utilizaremos Llama Index para configurar la implementación de RAG, aprovechando sus capacidades agenticas.

Para el LLM o agente, utilizaremos tanto GPT-4o Mini como Cloud 3.5 Sonnet, y para el VectorDB, nos basaremos en ChromaDB. Recorreremos el proceso de configuración, incluida la instalación de las bibliotecas requeridas, la configuración de las variables de entorno y la configuración de los modelos LLM y de incrustación.

Para comenzar, primero debemos configurar las bibliotecas y variables de entorno requeridas. Instalaremos los paquetes necesarios, incluidos Llama Index, OpenAI y ChromaDB.

A continuación, configuraremos las variables de entorno, incluida la clave API de OpenAI y el token de Hugging Face (si es necesario).

Luego configuraremos el modelo de lenguaje (LLM) y los modelos de incrustación. Para el LLM, utilizaremos el modelo GPT-4 OM Mini. Para las incrustaciones, utilizaremos el modelo OpenAI TextEmbedding3 small, que nos permite personalizar el tamaño de la incrustación para reducir los costos de cálculo y almacenamiento.

Después de configurar los modelos, pasaremos a cargar y procesar los datos. Utilizaremos el conjunto de datos de incrustaciones de Airbnb de MongoDB, centrándonos en los primeros 2,000 puntos de datos para mantener el tiempo de procesamiento y los costos manejables.

Eliminaremos las incrustaciones de texto existentes y crearemos nuestros propios vectores de incrustación utilizando las incrustaciones de OpenAI. También extraeremos los metadatos relevantes del conjunto de datos, como el nombre de la lista, el resumen, las reglas de la casa, el tipo de propiedad, el tipo de habitación y el número de dormitorios y camas. Estos metadatos se utilizarán para enriquecer el texto que el LLM verá durante el proceso de recuperación.

Para preparar los datos para el almacén de vectores, dividiremos el texto en fragmentos de 5,000 caracteres y crearemos nodos que contengan el texto, los vectores de incrustación y los metadatos. Finalmente, configuraremos el almacén de vectores ChromaDB para almacenar los nodos, que se utilizarán como la base de conocimiento para el flujo de trabajo RAG (Generación Aumentada por Recuperación) agentica.

Para incrustar el conjunto de datos de Airbnb, primero convertimos el conjunto de datos en una lista de documentos JSON. Luego creamos una plantilla de metadatos que incluye información importante como el nombre de la lista de Airbnb, el resumen, las reglas de la casa, el tipo de propiedad, el tipo de habitación, el tipo de dormitorio, el número de dormitorios y el número de camas. Estos metadatos se agregan al texto que se incrustará.

A continuación, dividimos el texto en fragmentos de 5,000 caracteres para asegurarnos de que cada vector de incrustación pueda capturar la información relevante. Luego calculamos las incrustaciones utilizando el modelo OpenAI TextEmbedding3 small, que nos permite personalizar el tamaño de la incrustación para reducir los costos de cálculo y almacenamiento.

Después de calcular las incrustaciones, las almacenamos en un almacén de vectores ChromaDB, que servirá como la base de conocimiento de nuestro agente. Creamos una clase QueryEngineToolClass que proporcionará al agente acceso al almacén de vectores, permitiéndole recuperar los fragmentos de texto más relevantes en función de la consulta del usuario.

Al preprocesar los datos, crear una plantilla de metadatos y configurar el almacén de vectores, hemos preparado el conjunto de datos de Airbnb para su uso con el agente Llama Index. Este proceso garantiza que el agente tenga acceso a la información necesaria para proporcionar respuestas precisas e informativas a las consultas de los usuarios.

Para comenzar, primero debemos configurar las bibliotecas y variables de entorno requeridas. Instalaremos los paquetes necesarios, incluidos Llama Index, ChromaDB y los modelos de OpenAI.

A continuación, configuraremos nuestros modelos LLM y de incrustación. Para el LLM, utilizaremos el modelo GPT-4 OM Mini, y para las incrustaciones, utilizaremos el modelo OpenAI TextEmbedding3 small.

Luego cargaremos y preprocesaremos el conjunto de datos de Airbnb, eliminando las incrustaciones de texto existentes y creando nuestros propios fragmentos de texto enriquecidos con metadatos. Estos fragmentos se incrustarán y almacenarán en un almacén de vectores ChromaDB.

Para crear la herramienta del motor de consultas, utilizaremos la clase QueryEngine de Llama Index, que proporcionará acceso al almacén de vectores y nos permitirá recuperar los k mejores fragmentos más similares para una consulta dada. Definiremos esta herramienta como parte de la base de conocimiento del agente.

Finalmente, crearemos el agente trabajador, que combina el LLM y la herramienta del motor de consultas, lo que nos permite interactuar con el agente y recuperar las mejores listas de Airbnb para una ubicación dada.

Los pasos clave en este proceso son:

1. Configurar las bibliotecas y variables de entorno requeridas.
2. Configurar los modelos LLM y de incrustación.
3. Cargar y preprocesar el conjunto de datos de Airbnb.
4. Crear el almacén de vectores utilizando ChromaDB.
5. Definir la herramienta del motor de consultas y agregarla a la base de conocimiento del agente.
6. Crear el agente trabajador combinando el LLM y la herramienta del motor de consultas.

Con estos pasos, hemos configurado la infraestructura necesaria para utilizar el modelo GPT-4 OM Mini para tareas RAG agenticas en el conjunto de datos de Airbnb.

Para crear el agente trabajador, primero definimos las herramientas que estarán disponibles para el agente. En este caso, utilizamos la clase QueryEngineToolV2 de Llama Index, que proporciona acceso al almacén de vectores que creamos anteriormente.

query_engine_tool = QueryEngineToolV2(
    "Knowledge base",
    "Proporciona información sobre las listas y reseñas de Airbnb, use una pregunta de texto plano detallada como entrada a la herramienta.",
    self.vector_store
)
tools = [query_engine_tool]

A continuación, creamos el agente trabajador utilizando la clase FunctionCallingAgentWorker de Llama Index. Proporcionamos la lista de herramientas y el modelo de lenguaje (GPT-4 Mini en este caso) al agente trabajador.

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

Ahora, podemos usar la función chat del agente para interactuar con él. Podemos proporcionar al agente un mensaje, y él utilizará las herramientas para generar una respuesta.

prompt = "Dime la mejor lista para un lugar en Nueva York."
result = self.agent.chat(prompt)
print(result)

La respuesta del agente incluirá el proceso de pensamiento y la respuesta final. En este caso, la respuesta del agente GPT-4 Mini no es tan detallada o perspicaz como la respuesta del agente Anthropic 3.5 Sonnet.

Para comparar el rendimiento, también podemos probar un mensaje diferente, como "¿Cuál es la peor lista de Airbnb en Miami?". El agente Anthropic 3.5 Sonnet proporciona una respuesta más reflexiva y matizada, reconociendo las limitaciones de la base de conocimiento y brindando ideas generales sobre las diferencias entre los alquileres vacacionales en Nueva York y Miami.

En general, la implementación del agente trabajador utilizando Llama Index es sencilla, pero el rendimiento del agente depende de las capacidades del modelo de lenguaje subyacente. El modelo Anthropic 3.5 Sonnet parece ser más adecuado para flujos de trabajo agenticos en comparación con el modelo GPT-4 Mini.

En esta sección, comparamos el rendimiento de GPT-4o Mini y Cloud 3.5 Sonnet como agentes en un flujo de trabajo práctico de RAG (Generación Aumentada por Recuperación) agentica utilizando el conjunto de datos de incrustaciones de Airbnb de MongoDB.

Los hallazgos clave son:

1. GPT-4o Mini como Agente: Si bien GPT-4o Mini es un modelo capaz, tiene dificultades con el flujo de trabajo agentico. El proceso de pensamiento del modelo no se articula bien, y las respuestas carecen del nivel de detalle y precisión esperado de un agente efectivo.

2. Cloud 3.5 Sonnet como Agente: En contraste, Cloud 3.5 Sonnet demuestra un rendimiento superior como agente. Reescribe los mensajes de manera efectiva, utiliza la herramienta de la base de conocimiento para recopilar información relevante y proporciona respuestas detalladas y precisas, incluso cuando la base de conocimiento no tiene información específica sobre el tema solicitado.

3. Importancia de los LLM poderosos para los flujos de trabajo agenticos: La comparación resalta la importancia de utilizar un LLM más poderoso y capaz, como Cloud 3.5 Sonnet, para los flujos de trabajo agenticos. La capacidad del agente para comprender el contexto, reescribir los mensajes y generar respuestas de alta calidad es crucial para una ejecución de tareas efectiva y una interacción fluida con el usuario.

En resumen, si bien GPT-4o Mini es un modelo rentable, es posible que no sea la mejor opción para los flujos de trabajo agenticos que requieren un agente más sofisticado y articulado. Cloud 3.5 Sonnet, por otro lado, demuestra un rendimiento superior en este caso de uso, lo que demuestra los beneficios de utilizar un LLM más capaz para aplicaciones basadas en agentes.

La comparación entre GPT-4o Mini y el modelo Anthropic Cloud 3.5 Sonnet para tareas RAG (Generación Aumentada por Recuperación) agenticas resalta la importancia de la capacidad del modelo cuando se trata de flujos de trabajo basados en agentes. Si bien GPT-4o Mini es un modelo capaz y rentable, se queda corto en los aspectos agenticos de la tarea, como lo demuestra su reescritura de mensajes simplista y sus respuestas menos detalladas.

En contraste, el modelo Anthropic Cloud 3.5 Sonnet muestra un comportamiento agentico más sólido y sofisticado. Reescribe eficazmente los mensajes, recopila información relevante de la base de conocimiento y proporciona respuestas detalladas y perspicaces, incluso cuando se enfrenta a una consulta sobre una ubicación que no está presente en el conjunto de datos.

Esta comparación subraya la necesidad de considerar cuidadosamente las capacidades del modelo al diseñar flujos de trabajo basados en agentes. Si bien GPT-4o Mini puede ser adecuado para ciertas tareas, las aplicaciones agenticas más complejas pueden requerir el uso de un modelo más poderoso y especializado, como el Anthropic Cloud 3.5 Sonnet, para lograr el nivel de rendimiento y experiencia de usuario deseado.