A continuaciónSiguiente guía
Turning OpenAPI Specs into LLM Tools
Técnico
GUÍA Técnica
Diseño de herramientas para agentes LLM
Diseñar herramientas para agentes LLM significa escribir los nombres, descripciones, esquemas de parámetros, resultados y mensajes de error que lee un modelo de lenguaje para decidir qué función llamar y cómo llamarla.
Escuche esta guíaNarrado por IA · ~3 min
En esta pagina4 minutos de lectura
Descripción general
El modelo nunca ve su código, solo este texto, por lo que una descripción vaga o un esquema descuidado produce llamadas incorrectas con la misma confiabilidad que un error.
Buceo profundo
La definición de una herramienta tiene cuatro partes de las que depende el modelo: un nombre, una descripción en lenguaje natural, un esquema de entrada (normalmente un esquema JSON) y el texto que devuelve la herramienta. Cada uno funciona como un aviso. El modelo decide si llamar a una herramienta haciendo coincidir el objetivo del usuario con las descripciones y completa los argumentos utilizando nombres de parámetros, tipos, enumeraciones y ejemplos. Los buenos nombres son específicos y agrupados. Prefijos como github_create_issue y jira_create_issue mantienen las herramientas separadas cuando un agente se conecta a muchos servicios. Las buenas descripciones dicen qué hace la herramienta, cuándo usarla, cuándo no y qué devuelve, de la misma manera que informaría a un nuevo colega. Los parámetros deben decir lo que significan: user_id es mejor que id, y una enumeración de valores permitidos supera a una cadena de texto libre que el modelo tiene que adivinar. Los resultados importan tanto como los insumos. Devolver miles de filas o ID internos sin procesar llena la ventana contextual y oculta la información importante. Las mejores herramientas devuelven campos legibles, paginan o truncan de forma predeterminada y, a veces, ofrecen un modo conciso o detallado. Los mensajes de error deben indicarle al modelo qué salió mal y qué intentar a continuación, porque el modelo los leerá y actuará en consecuencia. Un error común es creer que más herramientas significa un agente más capaz. Cada definición toma contexto en cada paso y las herramientas superpuestas dificultan la selección. La precisión tiende a disminuir a medida que la lista de herramientas crece, especialmente cuando las herramientas se parecen. No se aplica ningún límite universal. Muchos profesionales empiezan a ver problemas entre decenas de herramientas, y las soluciones habituales son consolidar herramientas, cargarlas según demanda o dividir el trabajo entre agentes especializados. Otra idea errónea es que las herramientas deberían reflejar una API existente uno a uno. Los agentes generalmente obtienen mejores resultados con menos herramientas de alto nivel diseñadas en torno a las tareas que las personas realmente realizan.
Implementación en el mundo real
Un agente de soporte tenía dos herramientas, search_orders y get_order. Cambiarles el nombre a pedidos_search_by_customer y pedidos_get_by_id y decir en cada descripción cuándo usar el otro reduce la cantidad de llamadas enviadas a la herramienta incorrecta.
Una herramienta de calendario que incluía un campo de fecha de texto libre seguía mostrando "el próximo martes". Cambiar el esquema para requerir una cadena de fecha ISO 8601 con un ejemplo en la descripción eliminó toda una clase de fallas de análisis.
Una herramienta de base de datos que solía devolver un 'Error 1064' sin formato ahora devuelve 'La columna creada_fecha no existe'. Columnas de fecha disponibles: creado_en, actualizado_en.' El agente soluciona su consulta en el siguiente intento en lugar de darse por vencido.
Un equipo expuso 60 envoltorios de puntos finales casi duplicados a un agente. Fusionarlos en una docena de herramientas a nivel de tareas, como Schedule_meeting en lugar de list_users, find_free_slots y create_event call, hizo que el agente fuera más rápido y económico de ejecutar.
El futuro del diseño de herramientas para agentes LLM
El diseño de herramientas se está convirtiendo en su propia disciplina, con guías publicadas por proveedores de modelos y convenciones compartidas que se difunden a través de protocolos como el Model Context Protocol. Algunas plataformas ahora pueden buscar y cargar definiciones de herramientas a pedido, lo que alivia la presión de mantener listas cortas, aunque las descripciones aún tienen que ser lo suficientemente claras para encontrarlas y elegirlas. También se están utilizando modelos para criticar y reescribir descripciones de herramientas basadas en transcripciones de evaluaciones. Es poco probable que la regla básica cambie: el modelo sólo puede utilizar una herramienta en la medida en que su interfaz la explique, por lo que los nombres claros, los esquemas estrictos y los errores útiles seguirán siendo fundamentales.
Poniéndolo en práctica
Por qué es importante
- Costo y presupuesto. Las decisiones de arquitectura impulsan el rendimiento y los costos operativos durante años.
- Decisiones más claras. La educación técnica ayuda a los equipos a elegir la pila adecuada, no sólo la más nueva.
- control de calidad. Mejores opciones de ingeniería reducen los incidentes de confiabilidad en la producción.
cuidado con
- La optimización de un punto de referencia puede ocultar debilidades más amplias del sistema.
- Los costos de infraestructura y mantenimiento a menudo se subestiman.
- Las brechas de seguridad y observabilidad pueden crecer a medida que los sistemas se vuelven más complejos.
Próximos pasos
- Defina objetivos de latencia, calidad y costos antes de la implementación.
- Comparación en condiciones realistas de carga y datos.
- Monitoreo de instrumentos para detectar errores, deriva e impacto para el usuario.
- Prepare rutas de reversión y respuesta a incidentes antes de escalar.
Sigue explorando
Boletín gratuito
Recibe el resumen diario de IA
Tres noticias verificadas sobre IA cada mañana de lunes a viernes, explicadas con claridad. Gratis para siempre y sin anuncios.
Un correo cada día laborable. Date de baja con un clic. Nunca vendemos ni compartimos tu dirección.
Ponte a prueba
Take the Designing Tools for LLM Agents quiz
Corrección inmediata en cada respuesta y un certificado para compartir, con un ID verificable, cuando apruebas un curso.
Apoya la educación gratuita sobre IA. AI Understanding es una organización sin fines de lucro 501(c)(3): sin anuncios ni muros de pago, nunca. Hacer una donación
Preguntas frecuentes
¿Qué es el diseño de herramientas para agentes LLM?
Diseñar herramientas para agentes LLM significa escribir los nombres, descripciones, esquemas de parámetros, resultados y mensajes de error que lee un modelo de lenguaje para decidir qué función llamar y cómo llamarla. El modelo nunca ve su código, solo este texto, por lo que una descripción vaga o un esquema descuidado produce llamadas incorrectas con la misma confiabilidad que un error.
¿Qué utiliza realmente el modelo para decidir cómo llamar a una herramienta?
El modelo nunca ve la implementación. Funciona sólo desde la interfaz de texto: el nombre, la descripción, el esquema de entrada y lo que sea que la herramienta envíe.
¿Por qué un agente podría utilizar prefijos como github_create_issue y jira_create_issue?
El espacio de nombres le dice al modelo a qué servicio pertenece una herramienta. Eso importa cuando varios servicios ofrecen acciones similares.
¿Qué diseño de parámetros tiene más probabilidades de producir argumentos correctos?
Las enumeraciones y los nombres descriptivos eliminan las conjeturas. El modelo elige entre opciones válidas en lugar de inventar un formato.
¿Qué hace que un mensaje de error de herramienta sea bueno?
El modelo lee el error y decide qué hacer a continuación. Un mensaje que nombra el problema y una solución le permite recuperarse en la siguiente llamada.
¿Por qué agregar muchas herramientas puede reducir el rendimiento del agente?
Cada definición se envía con cada solicitud, que utiliza contexto. Las herramientas de apariencia similar también dificultan que el modelo elija la correcta.
sigue aprendiendo
Guías relacionadas
Más guías seleccionadas para este tema.