Los LLM interactúan de forma diferente. En lugar de limitarse a cotejar los datos con un esquema, un LLM lee una descripción en lenguaje llano sobre lo que puede hacer una herramienta u otro sistema. Como desarrollador, tengo que exponer la información que un LLM que llama puede leer, consumir y, en última instancia, utilizar para entender cómo operar mi interfaz. No le das al LLM un esquema estricto. En su lugar, proporciona una descripción que incluye el propósito de la herramienta, las entradas y los resultados esperados.
El LLM utiliza su comprensión lingüística para averiguar cómo utilizar la herramienta basándose en esta descripción. Es como pasar de comprobar un formulario rígido a comprender instrucciones verbales. Esto es más flexible, especialmente para tareas menos estructuradas, pero significa que la interacción depende de la interpretación, que puede ser menos predecible que los formatos estrictos. Esta metodología se utiliza en muchos ámbitos, desde el Protocolo de Contexto de Modelo (MCP) hasta el Kit de Desarrollo de Agentes de código abierto de Google, como mencioné en mi último blog.
Los "Prompts" son los nuevos "API Docs"
Así pues, para los LLM, el "contrato API" o documentación es esencialmente la indicación que se escribe para describir la herramienta o capacidad. En lugar de escribir anotaciones de código o archivos de esquema, los desarrolladores ahora escriben descripciones claras y detalladas que le dicen al LLM:
- Para qué sirve: La función principal de la herramienta.
- Lo que necesita: Las entradas necesarias, tal vez con ejemplos o sugerencias de formato.
- Lo que devuelve: El resultado o la acción esperada.
- Cualquier norma: Restricciones o directrices importantes.
Esto significa que la ingeniería de instrucciones se está convirtiendo en una habilidad crucial. Para que estos sistemas funcionen, es imprescindible que los equipos de desarrollo puedan escribir instrucciones que los LLM puedan entender y seguir con fiabilidad.
Ejemplo sencillo: Una herramienta "Asistente de calendario" para un LLM
Imaginemos una herramienta más dinámica, como un asistente de calendario, y describámosla para un LLM:
Descripción general de la herramienta: "Esta es una herramienta de asistente de calendario. Puede programar nuevas reuniones y encontrar franjas horarias disponibles para un grupo de personas."
Función 1: CrearReunión Prompt: Nombre de la herramienta: CreateMeeting. Descripción: Programa una nueva reunión en el calendario. Entradas obligatorias: attendees (una lista de direcciones de correo electrónico), subject (texto para el título de la reunión), startTime (la fecha y hora en que debe comenzar la reunión; trate de interpretar tiempos relativos como "mañana a las 15.00 horas" o "el próximo lunes por la mañana"), y duration (texto que describe la duración, por ejemplo, "1 hora", "30 minutos"). Entrada opcional: ubicación (texto, por ejemplo, "Sala de conferencias B" o un enlace de videollamada). Responde con un mensaje de confirmación que incluye los detalles finales de la reunión o un error si falla la programación (por ejemplo, conflicto de horario, asistentes no válidos). Si la hora de inicio o la duración son ambiguas, pide aclaraciones al usuario antes de continuar. Asume que las horas están en la zona horaria local del usuario a menos que se especifique lo contrario.
Cómo podría utilizarlo el LLM (tras interpretar la solicitud del usuario): CrearReunión(asistentes=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")
Función 2: FindFreeTime Prompt: Nombre de la herramienta: FindFreeTime. Descripción: Busca franjas horarias comunes disponibles para un grupo de personas dentro de un marco temporal especificado. Datos necesarios: attendees (una lista de direcciones de correo electrónico) y duration (texto que describe la duración deseada de la reunión, por ejemplo, "1 hora"). Entrada opcional: timeWindow (texto que describe cuándo buscar, por ejemplo, "la semana que viene", "este viernes por la tarde", "en los próximos 3 días"; por defecto, la semana laboral actual si no se especifica). Responde con una lista de horas de inicio disponibles (fecha y hora) o un mensaje indicando que no se han encontrado franjas horarias comunes. Sea específico sobre el intervalo de fechas que se busca si se utiliza una ventana relativa como "la próxima semana". Asume que las horas están en la zona horaria local del usuario a menos que se especifique lo contrario.
Cómo podría utilizarlo el LLM (tras interpretar la solicitud del usuario): FindFreeTime(asistentes=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")
Aquí, los avisos guían al LLM sobre cómo manejar listas, interpretar entradas potencialmente difusas como fechas y duraciones, e incluso cuándo pedir aclaraciones. Esto se acerca más a cómo funcionan las interacciones de las herramientas LLM en el mundo real.
El reto: Ambigüedad y precisión (Preparando el terreno para la tercera parte de esta serie)
La primera vez que creas una herramienta como ésta, como desarrollador, piensas: '¡Esto es increíble! Escribir estos agentes es pan comido". Y entonces, como suele ocurrir en la vida de un desarrollador, la realidad te golpea en la cara...
Mientras que las indicaciones del Asistente de Calendario intentan manejar algunas imprecisiones (como "mañana a las 15:00"), basarse en descripciones en lenguaje natural puede introducir nuevas y emocionantes formas de que tu software haga algo que realmente no esperabas.
Considere estos ejemplos:
- Solicitud conflictiva de CreateMeeting:
- Usuario: "Reserva una reunión de 2 horas para mí y Charlie este viernes por la tarde, pero asegúrate de que sea antes de las 14:00".
- Problema: "viernes por la tarde" suele implicar horas posteriores a las 12 PM o a la 1 PM. "Antes de las 14:00" crea un conflicto potencial o una ventana muy estrecha (por ejemplo, de 13:00 a 14:00). La consulta no indica explícitamente al LLM cómo manejar las restricciones conflictivas dentro de un único parámetro como la hora. ¿Debe dar prioridad a "por la tarde" o a "antes de las 14 horas"? ¿Debe presentar el conflicto al usuario?
- Solicitud vaga de FindFreeTime:
- Usuario: "Encuentra tiempo para una charla rápida con Dave la semana que viene".
- Problema: ¿Qué es un "chat rápido"? El parámetro de duración necesita algo más específico como "15 minutos" o "30 minutos". La solicitud actual requiere una duración y no especifica un valor predeterminado o cómo manejar términos vagos como "chat rápido". El LLM podría fallar o tener que adivinar.
- Suposiciones implícitas en FindFreeTime:
- Usuario: "Busca una hora para la reunión de equipo del próximo miércoles".
- Problema: ¿Quién es "el equipo"? El LLM necesita la lista de asistentes (direcciones de correo electrónico). La solicitud lo requiere, pero la petición del usuario depende de que el LLM conozca el contexto de "el equipo". Un buen flujo de interaccion podria involucrar que el LLM pregunte, "¿Quien esta en el equipo?" si la lista de asistentes no es proporcionada o inferida de la historia de la conversacion. Aqui es donde el agente que llama podria llamar a otro agente para averiguar quien es "el equipo".
- Zonas horarias no especificadas:
- Usuario (en Londres): "Programa una reunión con Priya (en Nueva York) para mañana a las 9 AM".
- Problema: ¿son las 9 de la mañana, hora de Londres, o las 9 de la mañana, hora de Nueva York? Los avisos actuales incluyen una suposición básica ("Asumir que las horas están en la zona horaria local del usuario a menos que se especifique lo contrario"), pero manejar correctamente las zonas horarias es complejo. ¿Y si el usuario no lo especifica y los asistentes están en zonas diferentes? La herramienta necesita una lógica sofisticada para gestionar las zonas horarias o instrucciones mucho más explícitas sobre cómo solicitar y confirmar la información de la zona horaria si hay varias ubicaciones implicadas. Una simple suposición podría dar lugar a errores de programación.
Estos ejemplos demuestran que, incluso con indicaciones correctas, la ambigüedad en las solicitudes de los usuarios, la información contradictoria o las suposiciones no expresadas (como las zonas horarias) pueden dar lugar a errores, acciones incorrectas o bucles de aclaración frustrantes. La eficacia de la interacción LLM-API depende directamente de la calidad e integridad de las instrucciones que describen las capacidades y limitaciones de la herramienta. No sólo debe abarcar el camino correcto, sino también cómo manejar imprecisiones, información faltante, conflictos potenciales y detalles contextuales como las zonas horarias.
Volverse complejo: cuando hablan varios agentes de IA (transición a temas más profundos)
Describir una sola herramienta con precisión es una cosa, pero se vuelve mucho más complicado cuando hay varios agentes de IA que intentan trabajar juntos. ¿Cómo se escriben las instrucciones para que el agente A entienda claramente lo que el agente B puede y no puede hacer, y cómo gestiona la ambigüedad? ¿Cómo se coordinan? ¿Cómo asegurarse de que trabajan juntos de forma fiable y sin problemas inesperados causados por la forma en que interpretan las instrucciones de los demás? Averiguar cómo definir estas interacciones de forma clara y fiable utilizando el lenguaje es un gran reto al que nos enfrentamos a medida que estos sistemas evolucionan.
Vea cómo Akamai puede potenciar sus cargas de trabajo de IA a escala. Hable con nuestros expertos hoy mismo.
Comentarios