Anthropic resume formas sencillas y eficaces de construir inteligencias eficientes

En el último año, hemos trabajado con equipos que crean agentes LLM (Large Language Model) en múltiples sectores. De forma sistemática, hemos constatado que las implementaciones más exitosas no utilizan marcos complejos ni bibliotecas especializadas, sino que se construyen con patrones sencillos y componibles.

En este post, compartiremos nuestras experiencias trabajando con clientes y creando agentes nosotros mismos, y ofreceremos a los desarrolladores consejos prácticos para crear agentes eficientes.

Inteligente/agente/Agente tiene el mismo significado en el texto siguiente.

¿Qué es un agente?

"Agente" puede definirse de muchas maneras. Algunos clientes definen los agentes como sistemas totalmente autónomos que pueden funcionar de forma independiente durante largos periodos de tiempo, utilizando diversas herramientas para realizar tareas complejas. Otros lo utilizan para describir implementaciones más prescriptivas que siguen flujos de trabajo predefinidos. En Anthropic, nos referimos a estas variantes colectivamente como Sistemas agenciadosPero hay un reto arquitectónico flujo de trabajo responder cantando actuar en nombre de algn. en un puesto de responsabilidad Se hicieron importantes distinciones:

• flujo de trabajo es un sistema que orquesta LLM y herramientas a través de rutas de código predefinidas.
• actuar en nombre de algn. en un puesto de responsabilidad es un sistema en el que el LLM dirige dinámicamente sus propios procesos y el uso de herramientas para mantener el control sobre cómo se realizan las tareas.

A continuación analizamos con más detalle estos dos sistemas agenciados. En el Apéndice 1 ("Agentes en la práctica"), describimos dos ámbitos en los que el uso de estos sistemas por parte de los clientes ha sido especialmente valioso.

Cuándo (y cuándo no) utilizar proxies

Al crear aplicaciones con LLM, recomendamos buscar la solución más sencilla posible y añadir complejidad sólo cuando sea necesario. Esto puede significar no construir sistemas agenciados. Los sistemas apoderados a menudo compensan la latencia y el coste con un mejor rendimiento de las tareas, por lo que es necesario considerar si esta compensación merece la pena.

Los flujos de trabajo proporcionan previsibilidad y coherencia para tareas bien definidas cuando se requiere una mayor complejidad, mientras que los agentes funcionan mejor cuando se requiere flexibilidad y un escalado de decisiones basado en modelos. Sin embargo, para muchas aplicaciones, la optimización de una única llamada LLM, combinada con la recuperación y los ejemplos contextuales suele ser suficiente.

Cuándo y cómo utilizar el marco

Existen varios marcos que facilitan la implantación de sistemas agenciados, entre ellos:

• LangGraph De LangChain;
• Amazon Bedrock's Marco del agente de IA.;
• Remacheun constructor de flujos de trabajo LLM GUI de arrastrar y soltar;
• VitelaOtra herramienta de interfaz gráfica para crear y probar flujos de trabajo complejos.

Estos marcos facilitan el proceso de desarrollo al simplificar las tareas estándar de bajo nivel, como llamar a los LLM, definir y analizar herramientas y enlazar llamadas. Sin embargo, tienden a añadir capas adicionales de abstracción que pueden ocultar las pistas y respuestas subyacentes, dificultando la depuración. Esto también puede inclinar la balanza a favor de una mayor complejidad, cuando en realidad una configuración más simple puede ser suficiente.

Recomendamos que los desarrolladores utilicen primero la API LLM directamente: muchos patrones pueden implementarse con unas pocas líneas de código. Si utiliza un framework, asegúrese de comprender el código subyacente. Las suposiciones falsas sobre la lógica subyacente del framework son una fuente común de errores de cliente.

Consulte nuestro libro de cocina para ver algunos ejemplos de aplicación.

Building blocks, flujos de trabajo y agentes

En esta sección, exploraremos patrones comunes de sistemas agenciados que vemos en entornos de producción. Empezaremos con el bloque de construcción base, Enhanced LLM, y luego iremos aumentando gradualmente la complejidad, desde simples flujos de trabajo combinatorios hasta agentes autónomos.

Building Blocks: LLM Mejorado

El componente básico del sistema agenciado es el LLM mejorado, que integra funciones mejoradas como la búsqueda, las herramientas y la memoria. Nuestro modelo actual puede utilizar estas funciones de forma proactiva, generando sus propias consultas de búsqueda, seleccionando las herramientas adecuadas y decidiendo qué información retener.

LLM mejorado

Recomendamos centrarse en dos aspectos clave de la implementación: personalizar estas funciones para adaptarlas a su caso de uso específico y asegurarse de que proporcionan una interfaz fácil de usar y bien documentada para LLM. Aunque estas mejoras pueden implementarse de varias maneras, una de ellas es utilizar nuestro Protocolo de Contexto de Modelo, publicado recientemente, que permite a los desarrolladores integrarse en el creciente ecosistema de herramientas de terceros mediante una sencilla implementación del lado del cliente.

Para el resto de este documento, asumimos que estas mejoras son accesibles con cada llamada LLM.

Flujo de trabajo: encadenamiento de avisos

La cadena de sugerencias divide la tarea en una serie de pasos, en los que cada llamada al Modelo de Lenguaje Extenso (LLM) procesa la salida del paso anterior. Puede añadir comprobaciones de procedimiento (véase "puerta" en la figura siguiente) en cualquier paso intermedio para asegurarse de que el proceso sigue por el buen camino.

Flujo de trabajo de la cadena Cue

Cuándo utilizar este flujo de trabajo:
Este flujo de trabajo es ideal cuando las tareas pueden dividirse fácil y claramente en subtareas fijas. El objetivo principal es mejorar la precisión al tiempo que se reduce la latencia racionalizando cada llamada LLM en tareas más manejables.

Ejemplos de aplicación de la cadena de señales:

• Genere textos de marketing y tradúzcalos a distintos idiomas.
• Escriba un esquema del documento, compruebe que el esquema cumple determinados criterios y, a continuación, redacte el documento basándose en el esquema.

Flujo de trabajo: Enrutamiento

El enrutamiento categoriza la entrada y la dirige a una tarea de seguimiento especializada. Este flujo de trabajo permite separar las tareas y crear avisos más especializados. Optimizar para un tipo de entrada puede degradar el rendimiento de otras entradas si no se utiliza este flujo de trabajo.

flujo de trabajo de enrutamiento

Cuándo utilizar este flujo de trabajo:
Los flujos de trabajo de enrutamiento funcionan bien cuando las tareas complejas tienen diferentes categorías que deben procesarse por separado y la clasificación puede manejarse con precisión mediante LLM o modelos/algoritmos de clasificación más tradicionales.

Ejemplos de enrutamiento aplicables:

• Dirija los distintos tipos de consultas del servicio de atención al cliente (preguntas generales, solicitudes de reembolso, asistencia técnica) a los distintos procesos, consejos y herramientas posteriores.
• Enrutar problemas sencillos/comunes a modelos más pequeños (por ejemplo Claude 3.5 Haiku), al tiempo que enruta los problemas complejos/no comunes a modelos más potentes (por ejemplo, Claude 3.5 Sonnet) para optimizar el coste y la velocidad.

Flujo de trabajo: paralelización (Parallelization)

En ocasiones, los LLM pueden procesar tareas de forma concurrente y sus resultados se agregan mediante programación. Existen dos variantes principales de flujos de trabajo paralelizados:

• Seccionamiento: Descomponer las tareas en subtareas independientes que puedan ejecutarse en paralelo.
• Votar: Ejecute la misma tarea varias veces para obtener distintos resultados.

Flujos de trabajo paralelos

Cuándo utilizar este flujo de trabajo:
La paralelización es eficaz cuando las subtareas descompuestas pueden procesarse en paralelo para ganar velocidad, o cuando se requieren múltiples perspectivas o intentos para obtener resultados de mayor confianza. Para tareas complejas con múltiples consideraciones, suele ser mejor realizar cada consideración mediante una llamada LLM independiente para procesarla, centrándose así en cada aspecto específico.

Ejemplos de aplicación de la paralelización:

• Seccionamiento:
  • Implemente protecciones en las que una instancia del modelo gestione las consultas de los usuarios y la otra los controles de contenido o solicitudes inapropiadas. Esto suele ser mejor que hacer que la misma llamada LLM gestione tanto las protecciones como la respuesta del núcleo.
  • Evaluación automatizada del rendimiento del LLM, en la que cada llamada al LLM evalúa un aspecto diferente del rendimiento del modelo en una pista determinada.
• Votar:
  • Revisión del código en busca de vulnerabilidades, comprobando el código varias veces a través de diferentes indicaciones y marcando los problemas encontrados.
  • Evaluar la inadecuación de los contenidos, utilizando varias preguntas para evaluar distintos aspectos o exigiendo distintos umbrales de sondeo para equilibrar los falsos positivos y las omisiones.

Flujo de trabajo: Orquestadores-trabajadores

En un flujo de trabajo coordinador-trabajador, el LLM central descompone dinámicamente las tareas, las delega en los LLM trabajadores y sintetiza sus resultados.

Flujo de trabajo coordinador-trabajador

Cuándo utilizar este flujo de trabajo:
Este flujo de trabajo es muy adecuado cuando la tarea es compleja y no se pueden predecir las subtareas necesarias (por ejemplo, en codificación, donde el número de archivos que hay que cambiar y la naturaleza de los cambios en cada archivo pueden depender de la tarea específica). Es similar a los flujos de trabajo paralelizados, pero la diferencia clave es su flexibilidad: las subtareas no están predefinidas, sino que las decide el coordinador basándose en entradas específicas.

Ejemplos de aplicación coordinador-trabajador:

• Productos de codificación que realizan cambios complejos en varios archivos a la vez.
• Tarea de búsqueda que consiste en recopilar y analizar información procedente de múltiples fuentes para encontrar información que pueda ser relevante.

Flujo de trabajo: Evaluador-Optimizador

En el flujo de trabajo evaluador-optimizador, una llamada al Modelo de Lenguaje Extenso (LLM) genera la respuesta, mientras que la otra proporciona la evaluación y la retroalimentación, formando un bucle.

Flujo de trabajo evaluador-optimizador

Cuándo utilizar este flujo de trabajo: El flujo de trabajo resulta especialmente eficaz cuando disponemos de criterios de evaluación claros y la optimización iterativa aporta un valor cuantificable. Dos características aplicables son, en primer lugar, que las respuestas de LLM pueden mejorarse significativamente cuando los humanos expresan su opinión y, en segundo lugar, que LLM es capaz de proporcionar dicha opinión. Esto es análogo al proceso iterativo de escritura que puede seguir un escritor humano al redactar un documento pulido.

Ejemplos de aplicabilidad del evaluador-optimizador:

• Traducciones literarias, en las que el LLM traductor puede no captar inicialmente todos los matices, pero el LLM evaluador puede aportar críticas útiles.
• Tareas de búsqueda complejas que requieren varias rondas de búsqueda y análisis para recopilar información exhaustiva, y en las que el evaluador decide si es necesario realizar más búsquedas.

Intelligentsia/Agentes

Los agentes (Agents) están apareciendo gradualmente en la producción a medida que LLM madura en capacidades clave como la comprensión de entradas complejas, el razonamiento y la planificación, el uso de herramientas de forma fiable y la recuperación de errores. Los Agentes comienzan su trabajo con instrucciones de un usuario humano o mediante discusiones interactivas. Cuando la tarea está clara, los Agentes planifican y operan de forma independiente, posiblemente volviendo al humano para obtener más información o juicio. Durante la ejecución, el agente debe obtener "información real" del entorno (por ejemplo, resultados de llamadas a herramientas o ejecución de código) en cada paso para evaluar su progreso. El agente puede detenerse en los puntos de control o cuando encuentra obstáculos para obtener información humana. Las tareas suelen terminar cuando se completan, pero a menudo incluyen condiciones de parada (por ejemplo, número máximo de iteraciones) para mantener el control.

Los agentes pueden realizar tareas complejas, pero su aplicación suele ser relativamente sencilla. A menudo no son más que grandes modelos lingüísticos basados en bucles de retroalimentación del entorno para utilizar la herramienta. Por eso, el diseño de un conjunto de herramientas y su documentación deben ser claros y estar bien pensados. En el Apéndice 2 ("Ingeniería de sugerencias para herramientas") se describen las mejores prácticas para el desarrollo de herramientas.

Agentes autónomos

Cuándo utilizar proxies: Los agentes pueden utilizarse para problemas abiertos en los que no se puede predecir el número de pasos necesarios y en los que no se pueden codificar rutas fijas.LLM puede requerir múltiples rondas de operaciones, por lo que hay que tener cierta confianza en su capacidad de toma de decisiones. La autonomía del agente lo hace muy adecuado para tareas de escalado en entornos de confianza.

La autonomía de los agentes implica mayores costes y el riesgo potencial de acumulación de errores. Recomendamos realizar pruebas exhaustivas en un entorno sandbox con las medidas de seguridad adecuadas.

Ejemplo de aplicación proxy:

Los siguientes ejemplos proceden de nuestras aplicaciones reales:

• Agente de codificación para resolver tareas de SWE-bench que implican la edición de varios archivos de acuerdo con la descripción de la tarea;
• nuestra "Realización de la referencia "Uso del ordenadorEn este caso, Claude utilizó un ordenador para completar la tarea.

Proceso de alto nivel para la codificación de agentes

Combina y personaliza estos modelos

Estos componentes no son obligatorios. Son patrones comunes que los desarrolladores pueden adaptar y combinar para diferentes casos de uso. Como con cualquier característica LLM, la clave del éxito es medir el rendimiento y repetir la implementación. Una vez más: sólo deberías considerar añadir complejidad si mejora significativamente los resultados.

resúmenes

El éxito en el campo de la modelización de grandes lenguajes (LLM) no consiste en construir el sistema más complejo, sino el que mejor se adapte a sus necesidades. Empiece con pistas sencillas, optimice mediante una evaluación exhaustiva y añada sistemas de agentes de varios pasos solo cuando las soluciones sencillas no satisfagan sus necesidades.

Al implantar los proxies, seguimos tres principios básicos:

1. Mantener el diseño de los agentes sencillez .
2. Dar prioridad a los pasos de la planificación demostrando claramente que el agente transparencia .
3. Mediante herramientas detalladas Documentación y pruebas Diseñe cuidadosamente su interfaz agente-ordenador (ACI).

Los frameworks pueden ayudarte a empezar rápidamente, pero no dudes en reducir las capas de abstracción y construir con componentes base cuando pases a producción. Siguiendo estos principios, puedes crear agentes que no solo sean potentes, sino también fiables, mantenibles y en los que confíen los usuarios.

una nota de agradecimiento

Este artículo ha sido escrito por Erik Schluntz y Barry Zhang. Este trabajo se basa en nuestro trabajo en Antrópico La experiencia de los agentes inmobiliarios y las valiosas opiniones compartidas por nuestros clientes son muy apreciadas.

Apéndice 1: Aplicaciones prácticas de los poderes

El trabajo con nuestros clientes ha revelado dos aplicaciones especialmente prometedoras de los agentes de IA que demuestran el valor práctico de los patrones descritos anteriormente. Estas aplicaciones demuestran que los agentes son más valiosos en tareas que requieren una combinación de diálogo y acción, tienen criterios de éxito claros, admiten bucles de retroalimentación y permiten una supervisión humana eficaz.

A. Atención al cliente

El servicio de atención al cliente combina la conocida interfaz de chatbot con funciones mejoradas para la integración de herramientas. Este escenario es perfecto para agentes más abiertos como:

• Apoyar interacciones que sigan de forma natural un flujo de diálogo, al tiempo que requieren el acceso a información externa y la ejecución de acciones;
• Se pueden integrar herramientas para extraer datos de clientes, historial de pedidos y artículos de la base de conocimientos;
• Las operaciones (como la emisión de reembolsos o la actualización de órdenes de trabajo) pueden gestionarse mediante programación;
• El éxito puede medirse claramente con soluciones definidas por el usuario.

Varias empresas han demostrado la viabilidad de este enfoque mediante un modelo de precios basado en el uso, que cobra únicamente por los casos resueltos con éxito, lo que demuestra la confianza en la eficacia de la agencia.

B. Agentes de programación

El campo del desarrollo de software ha mostrado un potencial significativo para las funcionalidades LLM, evolucionando desde la finalización de código hasta la resolución autónoma de problemas. Los agentes son especialmente eficaces porque:

• Las soluciones de código pueden verificarse mediante pruebas automatizadas;
• Los agentes pueden utilizar los resultados de las pruebas como feedback para iterar sobre la solución;
• Las áreas problemáticas están claras y estructuradas;
• La calidad de la producción puede medirse objetivamente.

En nuestra implementación, el proxy ha sido capaz de resolver individualmente las descripciones de las solicitudes pull basándose en el SWE-bench Verificado Problemas reales de GitHub en la evaluación comparativa. Sin embargo, aunque las pruebas automatizadas pueden ayudar a validar la funcionalidad, la revisión manual sigue siendo vital para garantizar que la solución cumple los requisitos más amplios del sistema.

Apéndice 2: Proyecto Tooltip

No importa qué tipo de sistema de agente estés construyendo, las herramientas son probablemente una parte importante de tu agente. Las herramientas permiten a Claude interactuar con servicios externos y APIs especificando su estructura y definiciones exactas. Cuando Claude responda, si planea invocar una herramienta, incluirá en la respuesta de la API un icono bloque de uso de herramientas . Las definiciones y especificaciones de las herramientas deben ser objeto de ingeniería de indicios tanto como los indicios generales. En este apéndice describimos brevemente cómo se pueden diseñar las herramientas.

Normalmente hay varias formas de especificar la misma operación. Por ejemplo, puede especificar la edición de archivos escribiendo diff, o reescribiendo el archivo completo. Para una salida estructurada, puede devolver código en markdown o código en JSON. En ingeniería de software, estas diferencias son cosméticas y se pueden convertir entre sí sin pérdida. Sin embargo, algunos formatos son más difíciles de escribir para LLM que otros. Por ejemplo, escribir diff requiere saber cuántas líneas de la cabecera de un bloque se están cambiando antes de escribir nuevo código. Escribir código en JSON (a diferencia de markdown) requiere un escape adicional de los saltos de línea y las comillas.

A continuación se formulan recomendaciones sobre el formato de la herramienta:

• Dar al modelo suficiente Fichas "Piensa" para no estancarte en la rutina.
• Mantenga el formato cercano al texto que el modelo vería naturalmente en Internet.
• Asegúrate de que no hay "cargas adicionales" para el formato, como tener que calcular con exactitud miles de líneas de código o escapar cualquier código que escriba.

Una regla general es tener en cuenta cuánto esfuerzo se dedica a la interfaz persona-ordenador (HCI), y también planificar la creación de una buena interfaz de usuario. actuar en nombre de algn. en un puesto de responsabilidad -Se invierte el mismo esfuerzo en la interfaz informática (ACI). A continuación se ofrecen algunas sugerencias:

• Piense en términos de modelos. ¿Es obvio utilizar esta herramienta basándose en la descripción y los parámetros? Si requiere una cuidadosa reflexión, probablemente también lo sea para el modelo. Una buena definición de la herramienta suele incluir ejemplos de uso, casos límite, requisitos de formato de entrada y límites claros con otras herramientas.
• ¿Cómo puedes cambiar el nombre o la descripción de un parámetro para hacerlo más obvio? Piensa en esto como si estuvieras escribiendo notas de documentación (docstring) para los desarrolladores junior de tu equipo. Esto es especialmente importante cuando se utilizan muchas herramientas similares.
• Pruebe cómo utiliza el modelo sus herramientas: ejecute muchas entradas de muestra en nuestro banco de trabajo, observe qué errores comete el modelo e itere.
• Poka-yoke Tus herramientas. Cambia los parámetros para que sea más difícil cometer errores.

A la hora de crear agentes para SWE-bench, pasamos más tiempo optimizando las herramientas que el sistema en general. Por ejemplo, descubrimos que las herramientas que utilizaban rutas de archivo relativas eran propensas a errores cuando el agente se movía fuera del directorio raíz. Para solucionarlo, cambiamos la herramienta de modo que siempre requiriera rutas de archivo absolutas; descubrimos que el modelo no tenía ningún problema con este enfoque.