Los agentes de IA son el tema de moda en el ámbito de la IA hoy en día, y con razón. Estos sistemas actúan en nombre de sus usuarios, gestionando de forma autónoma tareas como realizar compras en línea, crear software, investigar tendencias empresariales o reservar viajes. Al sacar la IA generativa del entorno protegido de la interfaz de chat y permitirle actuar directamente en el mundo real, la IA agencial representa un gran avance en cuanto al poder y la utilidad de la IA. Sacar la IA generativa del entorno protegido de la interfaz de chat y permitirle actuar directamente en el mundo real representa un gran avance en cuanto al poder y la utilidad de la IA.
La IA agencial ha avanzado muy rápidamente: por ejemplo, uno de los pilares fundamentales de los agentes actuales, el protocolo de contexto del modelo (MCP), solo tiene un año de antigüedad. Como en cualquier campo en rápida evolución, existen muchas definiciones contradictorias, opiniones controvertidas y puntos de vista engañosos.
Para aclarar las cosas, me gustaría describir los componentes básicos de un sistema de IA agencial y cómo encajan entre sí: en realidad, no es tan complicado como parece. Espero que, cuando termines de leer este artículo, los agentes no te resulten tan misteriosos.
Agentes de IA: Ecosistema agencial
Existen numerosas definiciones de la palabra “agente”, pero me gusta una ligera variación de la visión minimalista del programador británico Simon Willison: un agente LLM ejecuta herramientas en un bucle para alcanzar un objetivo. El usuario le da una orden a un modelo de lenguaje grande (LLM) con un objetivo: por ejemplo, reservar una mesa en un restaurante cerca de un teatro específico. Junto con el objetivo, el modelo recibe una lista de las herramientas que tiene a su disposición, como una base de datos de ubicaciones de restaurantes o un registro de las preferencias alimentarias del usuario.
A continuación, el modelo planifica cómo alcanzar el objetivo y recurre a una de las herramientas, que proporciona una respuesta; luego, el modelo recurre a una nueva herramienta. A través de repeticiones, el agente avanza hacia el logro del objetivo. En algunos casos, las opciones de coordinación y planificación del modelo se complementan o mejoran con código imperativo. Pero ¿qué tipo de infraestructura se necesita para llevar a cabo este enfoque? Un sistema agencial necesita algunos componentes básicos:
-
- Una forma de crear el agente. Cuando se implementa un agente, no se quiere tener que programarlo desde cero. Existen varios marcos de desarrollo de agentes.
- Un lugar donde ejecutar el modelo de IA. Un desarrollador de IA con experiencia puede descargar un LLM de peso abierto, pero se necesita experiencia para hacerlo correctamente. También se necesita un hardware caro que el usuario medio no va a utilizar en su totalidad.
- Un lugar donde ejecutar el código del agente. Con los marcos establecidos, el usuario crea código para un objeto agente con un conjunto definido de funciones. La mayoría de esas funciones implican enviar indicaciones a un modelo de IA, pero el código necesita ejecutarse en algún lugar. En la práctica, la mayoría de los agentes se ejecutarán en la nube, porque queremos que sigan funcionando cuando cerramos nuestros portátiles y queremos que se amplíen y se adapten para hacer su trabajo.
- Un mecanismo para traducir entre el LLM basado en texto y las llamadas a herramientas.
- Una memoria a corto plazo para realizar un seguimiento del contenido de las interacciones de los agentes.
- Una memoria a largo plazo para realizar un seguimiento de las preferencias y afinidades del usuario a lo largo de las sesiones.
- Una forma de rastrear la ejecución del sistema, para evaluar el rendimiento del agente.
Profundicemos en cada uno de estos componentes:
Creación de agentes de IA
Pedir a un LLM que explique cómo piensa abordar una tarea concreta mejora su rendimiento en dicha tarea. Este “razonamiento en cadena” es ahora omnipresente en la IA.
El equivalente en los sistemas agénticos es el modelo ReAct (razonamiento + acción), en el que el agente tiene un pensamiento (“Usaré la función de mapa para localizar restaurantes cercanos”), realiza una acción (emite una llamada API a la función de mapa) y luego hace una observación (“Hay dos pizzerías y un restaurante indio a dos manzanas del cine”).
ReAct no es la única forma de crear agentes, pero es la base de la mayoría de los sistemas agenticos exitosos. Hoy en día, los agentes suelen ser bucles sobre la secuencia pensamiento-acción-observación.
Las herramientas disponibles para el agente pueden incluir herramientas locales y remotas, como bases de datos, microservicios y software como servicio. Las especificaciones de una herramienta incluyen una explicación en lenguaje natural de cómo y cuándo se utiliza, así como la sintaxis de sus llamadas a la API.
El desarrollador también puede indicarle al agente que, básicamente, cree sus propias herramientas sobre la marcha. Supongamos que una herramienta recupera una tabla almacenada como texto separado por comas y que, para cumplir su objetivo, el agente necesita ordenar la tabla.
Ordenar una tabla enviándola repetidamente a través de un LLM y evaluando los resultados sería un enorme desperdicio de recursos, y ni siquiera se garantiza que se obtenga el resultado correcto. En su lugar, el desarrollador puede simplemente indicar al agente que genere su propio código Python cuando se encuentre con una tarea sencilla pero repetitiva. Estos fragmentos de código pueden ejecutarse localmente junto con el agente o en una herramienta dedicada de interpretación de código seguro.
Las herramientas disponibles pueden dividir la responsabilidad entre el LLM y el desarrollador. Una vez especificadas las herramientas disponibles para el agente, el desarrollador puede simplemente indicar al agente qué herramientas utilizar cuando sea necesario. O bien, el desarrollador puede especificar qué herramienta utilizar para cada tipo de datos e incluso qué elementos de datos utilizar como argumentos durante las llamadas a funciones.
Del mismo modo, el desarrollador puede simplemente indicar al agente que genere código Python cuando sea necesario para automatizar tareas repetitivas o, alternativamente, indicarle qué algoritmos utilizar para cada tipo de datos e incluso proporcionar pseudocódigo. El enfoque puede variar de un agente a otro.
Tiempo de ejecución
Históricamente, había dos formas principales de aislar el código que se ejecutaba en servidores compartidos: la contenedorización, que era eficiente, pero ofrecía menor seguridad; y las máquinas virtuales, que eran seguras, pero conllevaban una gran sobrecarga computacional. En 2018, el servicio de computación sin servidor Lambda de Amazon Web Services (AWS) implementó Firecracker, un nuevo paradigma en el aislamiento de servidores. Firecracker crea “microVM” (micro virtual machine), con aislamiento de hardware y sus propios núcleos Linux, pero con una sobrecarga reducida (de tan solo unos pocos megabytes) y tiempos de arranque reducidos (de tan solo unos pocos milisegundos). La baja sobrecarga significa que cada función ejecutada en un servidor Lambda puede tener su propia microVM. Sin embargo, dado que la instanciación de un agente requiere la implementación de un LLM, junto con los recursos de memoria para rastrear las entradas y salidas del LLM, el modelo de aislamiento por función no es práctico. En su lugar, con el aislamiento basado en sesiones, a cada sesión se le asigna su propia microVM. Cuando la sesión finaliza, la información de estado del LLM se copia en la memoria a largo plazo y la microVM se destruye. Esto garantiza una implementación segura y eficiente de los hosts de los agentes.
Llamadas a herramientas
Al igual que existen varios marcos de desarrollo para la creación de agentes, también existen varios estándares para la comunicación entre agentes y herramientas, el más popular de los cuales —en la actualidad— es el protocolo de contexto de modelo (MCP). El MCP establece una conexión uno a uno entre el LLM del agente y un servidor MCP dedicado, que ejecuta las llamadas a herramientas, y también establece un formato estándar para el intercambio de diferentes tipos de datos entre el LLM y su servidor. Muchas plataformas utilizan el MCP de forma predeterminada, pero también son configurables, por lo que con el tiempo serán compatibles con un conjunto cada vez mayor de protocolos.
Sin embargo, a veces la herramienta necesaria no es una que tenga una API disponible. En tales casos, la única forma de recuperar datos o realizar una acción es mediante movimientos del cursor y clics en un sitio web. Existen varios servicios disponibles para realizar este tipo de uso del ordenador. Esto convierte a cualquier sitio web en una herramienta potencial para los agentes, lo que abre décadas de contenido y servicios valiosos que aún no están disponibles directamente a través de las API.
Autorizaciones
Con los agentes, la autorización funciona en dos direcciones. En primer lugar, por supuesto, los usuarios necesitan autorización para ejecutar los agentes que han creado. Pero como el agente actúa en nombre del usuario, normalmente necesitará su propia autorización para acceder a los recursos de la red. Hay varias formas de abordar el problema de la autorización. Una de ellas es mediante un algoritmo de delegación de acceso como OAuth (Open Authorization), que básicamente canaliza el proceso de autorización a través del sistema de agentes. El usuario introduce sus credenciales de inicio de sesión en OAuth y el sistema de agentes utiliza OAuth para iniciar sesión en los recursos protegidos, pero el sistema de agentes nunca tiene acceso directo a las contraseñas del usuario. En el otro enfoque, el usuario inicia sesión en una sesión segura en un servidor, y el servidor tiene sus propias credenciales de inicio de sesión en los recursos protegidos. Los permisos permiten al usuario seleccionar entre una variedad de estrategias de autorización y algoritmos para implementar esas estrategias.
Memoria y rastros
Memoria a corto plazo
Los LLM son motores de predicción de la siguiente palabra. Lo que los hace tan increíblemente versátiles es que sus predicciones se basan en largas secuencias de palabras que ya han visto, lo que se conoce como contexto. El contexto es, en sí mismo, una especie de memoria. Pero no es el único tipo que necesita un sistema agencial. Supongamos, de nuevo, que un agente está tratando de reservar un restaurante cerca de un cine y, a partir de una herramienta de mapas, ha recuperado una veintena de restaurantes en un radio de un kilómetro. No quiere volcar la información sobre todos esos restaurantes en el contexto del LLM: toda esa información superflua podría causar estragos en las probabilidades de la siguiente palabra. En su lugar, puede almacenar la lista completa en la memoria a corto plazo y recuperar uno o dos registros a la vez, basándose, por ejemplo, en las preferencias del usuario en cuanto a precio y tipo de cocina, y en la proximidad al cine. Si ninguno de esos restaurantes le convence, el agente puede volver a recurrir a la memoria a corto plazo, en lugar de tener que ejecutar otra llamada a la herramienta.
Memoria a largo plazo
Los agentes también deben recordar sus interacciones previas con los clientes. Si la semana pasada le dije al agente de reservas de restaurantes qué tipo de comida me gusta, no quiero tener que volver a decírselo esta semana. Lo mismo ocurre con mi tolerancia al precio, el tipo de ambiente que busco, etc. La memoria a largo plazo permite al agente buscar lo que necesita saber sobre conversaciones anteriores con el usuario. Sin embargo, los agentes no suelen crear memorias a largo plazo por sí mismos. En su lugar, una vez finalizada la sesión, toda la conversación pasa a un modelo de IA independiente, que crea nuevas memorias a largo plazo o actualiza las existentes. La creación de memoria puede implicar la síntesis y el “fragmentado” de LLM, en los que los documentos se dividen en secciones agrupadas por temas para facilitar su recuperación durante sesiones posteriores. Los sistemas disponibles permiten al usuario seleccionar estrategias y algoritmos para la síntesis, el fragmentado y otras técnicas de extracción de información.
Observabilidad
Los agentes son un nuevo tipo de sistema de software y requieren nuevas formas de pensar sobre la observación, la supervisión y la auditoría de su comportamiento. Algunas de las preguntas que planteamos nos resultarán familiares: si los agentes funcionan con la suficiente rapidez, cuánto cuestan, cuántas llamadas a herramientas realizan y si los usuarios están satisfechos. Pero también surgirán nuevas preguntas, y no siempre podemos predecir qué datos necesitaremos para responderlas. Las herramientas de observabilidad y rastreo pueden proporcionar una visión completa de la ejecución de una sesión con un agente, desglosando paso a paso qué acciones se llevaron a cabo y por qué. Para el creador del agente, estos rastros son clave para comprender cómo funcionan los agentes y proporcionan los datos necesarios para que funcionen mejor.
Espero que esta explicación haya desmitificado lo suficiente la IA agencial como para que estés dispuesto a intentar crear tus propios agentes.
Guía desarrollada por Marc Brooker, Distinguished Engineer en Amazon Web Services.
Puedes revisar más información relativa a noticias de tecnología | Instagram | YouTube | Suscríbete a nuestro Newsletter | Patrocina Bytes and Bits
