El Prompt como libro de reglas: guiar a los agentes de LLM más allá de las instrucciones básicas

En nuestro viaje de integración de grandes modelos lingüísticos (LLM) con API tradicionales, hemos visto cómo las instrucciones se convierten en los nuevos "documentos API", que describen lo que puede hacer una herramienta. Al principio, todo parece muy sencillo. Le das al LLM acceso a algunas herramientas, las describes y voilà, ¡tienes un agente inteligente! Pero como muchos de nosotros estamos descubriendo, hay una diferencia crucial entre un LLM que puede utilizar una herramienta y un LLM que utiliza una herramienta de forma inteligente o eficaz en un contexto más amplio. Esto aborda directamente los retos que vimos con nuestro sencillo Asistente de Calendario.

Aquí es donde a menudo nos encontramos con lo que yo llamo el síndrome del "becario entusiasta". Su agente LLM, al igual que un becario entusiasta pero inexperto, sigue diligentemente las instrucciones explícitas de sus herramientas. Sin embargo, puede carecer del juicio experimentado de un empleado con experiencia que considera intuitivamente reglas no declaradas, factores humanos sutiles o el "mejor resultado global". Los actuales LLM son excepcionalmente buenos comprendiendo y ejecutando lo que se les dice, pero no captan de forma inherente el contexto tácito o el "por qué" matizado que hay detrás de una tarea y que a menudo dicta el verdadero éxito.

Esto significa que, como desarrolladores, nuestro papel evoluciona. Ya no nos limitamos a describir las funciones de la herramienta, sino que elaboramos meticulosamente reglas dentro de nuestras indicaciones, guiando al LLM a través de complejos procesos de toma de decisiones.

Caso práctico: El asistente de calendario "considerado

Volvamos a nuestra herramienta "Asistente de Calendario" de la Parte 2. Imaginemos que nuestro agente principal de LLM tiene acceso a las dos funciones principales que hemos definido:

1. CreateMeeting(attendees, subject, startTime, duration, location): Programa una reunión.
2. FindFreeTime(attendees, duration, timeWindow): Busca ranuras disponibles.

Nuestros avisos iniciales para estas herramientas se encargan de la interpretación básica y están configurados para respetar el horario laboral estándar de la empresa, por ejemplo, de lunes a viernes, de 8:00 a 18:00, hora local, para cada empleado.

Ahora, un usuario, jefe de equipo en Londres, hace la siguiente petición: "Necesitamos una sesión de estrategia crítica de una hora para el proyecto Atlas a principios de la semana que viene. Los participantes seremos yo mismo, María (también residente en Londres) y Ben (residente en Edimburgo). Esto requiere una preparación importante por parte de todos los asistentes. Por favor, prográmala en nuestra sede de Londres".

El agente "becario entusiasta" se pone manos a la obra. Consulta los calendarios utilizando FindFreeTime y descubre que el lunes a las 8:30 AM GMT está técnicamente "libre" para todo el mundo dentro de su horario laboral estándar definido.

• Procede a llamar: CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

Técnicamente, se ha programado una reunión. Pero, ¿es un buen resultado? Considera las implicaciones:

1. No se tienen en cuenta los desplazamientos: Para Ben, residente en Edimburgo, una reunión en persona a las 8:30 de la mañana en Londres es muy problemática. Tendría que viajar muy temprano el lunes por la mañana o, lo que es más probable, tendría que viajar el domingo por la tarde. El agente, al fijarse únicamente en las "horas laborables disponibles de 8 a 6" del calendario, no tuvo en cuenta en absoluto las dificultades logísticas y el impacto personal de una reunión a primera hora de la mañana que requería un desplazamiento importante. No diferenció una franja horaria de 8:30 de la mañana para un asistente local de otra para un asistente remoto que necesita estar físicamente presente.
2. Tiempo de preparación pasado por alto: El usuario declaró explícitamente que se trata de una "sesión de estrategia crítica" que requiere una "preparación importante". Programarla a primera hora de la mañana del lunes (8:30 AM) implícitamente presiona a los asistentes a utilizar su tiempo personal del fin de semana para prepararse si quieren estar listos para un comienzo tan temprano.

Este es el momento en el que, como desarrollador, te das cuenta de que el agente realizó su tarea basándose en la disponibilidad explícita del calendario, pero pasó por alto factores humanos implícitos cruciales y consideraciones prácticas. Le faltó criterio para garantizar un resultado realmente eficaz y considerado.

Codificación de la "experiencia" y la "consideración" en los avisos

Para elevar a nuestro "becario" a la categoría de "asistente experimentado", tenemos que integrar una lógica más sofisticada en el programa. guía del agente principal (o las instrucciones generales que sigue al orquestar las herramientas). Esto va más allá de la mera descripción de FindFreeTime o CreateMeeting herramientas en sí. Tenemos que decirle al agente cómo comportarse con más consideración.

Esto implica a menudo dar instrucciones al agente para que busque y utilice lo que podemos considerar una "tercera herramienta" o una capa adicional de información y lógica. En este caso, se trata de ubicación de los asistentes, contexto del viaje y naturaleza de la reunión. Nuestro agente podría necesitar implícitamente (o explícitamente a través de otra herramienta como GetUserProfile(email)) acceder o inferir:

• Lugar de trabajo principal de cada asistente.
• El tipo de reunión (por ejemplo, presencial o virtual).
• Las implicaciones de la importancia y el momento de la reunión (por ejemplo, "reunión crítica el lunes por la mañana").

Con acceso a estos "datos contextuales", tenemos que añadir una lista de instrucciones del tipo "si... entonces..." a la pregunta maestra del agente:

Fragmento revisado de la lógica del agente (conceptual):

"...Cuando se le encarga programar una reunión:

1. Reúne un contexto mejorado: Para cada asistente, determine su ubicación probable (por ejemplo, utilizando GetUserProfile(attendee_email)). Observe si la reunión se especifica como "en persona" y si los asistentes son remotos.
2. Tenga en cuenta los desplazamientos para las reuniones presenciales:
   • Si la reunión es en persona, y un asistente es remoto, y se propone una franja horaria a primera hora de la mañana (por ejemplo, antes de las 10.00, hora local del lugar de la reunión):
     • A continuación, indíqueselo al solicitante. Por ejemplo: "Ben viajará desde Edimburgo para esta reunión en persona. Para que pueda viajar cómodamente el lunes, ¿prefiere que la reunión comience a las 10:30 de la mañana o más tarde, o debería explorar opciones virtuales?".
3. Tenga en cuenta el tiempo de preparación para las reuniones críticas:
   • Si una reunión se califica de "crítica", "importante" o que requiere una "preparación significativa". y se programa para un lunes temprano (o inmediatamente después de un día festivo):
     • A continuación, pida confirmación al solicitante. Por ejemplo: "Para esta sesión crítica del lunes que requiere preparación, ¿una hora de inicio a las 8:30 de la mañana daría a todos tiempo suficiente el lunes por la mañana, o sería más adecuado un horario en torno a las 10:00 para permitir la preparación del día?".
4. Gestionar los conflictos generales de zona horaria/horario de trabajo (como se ha comentado anteriormente):
   • (Incorpore una lógica para dar prioridad a las "ventanas sociales principales", gestionar las franjas horarias fuera de éstas y pedir confirmación para las horas intempestivas en diferentes zonas horarias, si procede, incluso para las reuniones virtuales).
5. Respetar las anulaciones explícitas del usuario:
   • Si el usuario confirma explícitamente un acuerdo inconveniente (por ejemplo, "Sí, Ben está al tanto y viajará el domingo"), entonces proceda, quizá con una confirmación final: "Entendido. Programación confirmada'".

Sugerencias: De descripciones sencillas a algoritmos complejos

Como puede ver, el aviso para nuestro agente principal ha evolucionado significativamente. Ya no es sólo una lista de herramientas disponibles. Es un árbol de decisión detallado y condicional. Es un algoritmo en miniatura expresado en lenguaje natural. Esas afirmaciones "si... entonces..." se convierten en la columna vertebral del proceso de "razonamiento" del agente, guiándolo no sólo hacia una solución, sino hacia una solución mejor.

El reto -y la habilidad emergente para los desarrolladores- es prever estos posibles escollos y codificar preventivamente la "experiencia", la "política de empresa" o la "cortesía común" directamente en las instrucciones del LLM. Esto demuestra que, aunque los LLM aportan un poder increíble, la labor de un desarrollador a la hora de guiar ese poder hacia aplicaciones verdaderamente útiles y consideradas es más crucial que nunca. Se trata de transformar a ese "becario entusiasta" en un colega digital fiable y experimentado, con instrucciones cuidadosamente elaboradas.

De cara al futuro, la aspiración es que estos agentes evolucionen más allá incluso de los manuales más detallados basados en instrucciones, permitiéndoles "aprender" realmente de los resultados de sus acciones. Aunque hoy codificamos meticulosamente la experiencia, la próxima frontera son los agentes capaces de perfeccionar sus estrategias de forma autónoma. Imaginemos un agente con acceso no sólo a herramientas y datos para realizar su trabajo, sino también a información continua sobre el éxito o el fracaso de esas acciones en la consecución de los resultados empresariales deseados. Nuestro asistente de calendario, por ejemplo, si observa sistemáticamente que las invitaciones a reuniones a las 12:00 PM son rechazadas por un usuario concreto con la excusa de que "ha salido a comer", podría aprender con el tiempo a quitar prioridad o incluso evitar sugerir esa franja horaria a esa persona, sin que un desarrollador tenga que programar explícitamente una regla de "no reuniones al mediodía para el usuario X".

Ahora, extrapole esta capacidad de aprendizaje a procesos empresariales más intrincados. Un agente programado inicialmente con un conjunto de procedimientos para, por ejemplo, la incorporación de clientes o la logística de la cadena de suministro, podría, mediante la medición de indicadores clave de rendimiento y la observación de los resultados del mundo real, empezar a identificar ineficiencias o descubrir caminos más óptimos. Con el tiempo, podría ajustar sutilmente su enfoque, volver a priorizar los pasos o incluso sugerir modificaciones a los procesos fundacionales que los desarrolladores diseñaron en un principio. En el futuro, por tanto, los desarrolladores podrían no ser sólo los arquitectos iniciales de estos comportamientos de los agentes, sino también los cultivadores de sistemas en los que los agentes perfeccionan y optimizan progresivamente sus propios "algoritmos" operativos, convirtiéndose realmente en socios dinámicos y de aprendizaje en la consecución de los objetivos empresariales.

Vea cómo Akamai puede potenciar sus cargas de trabajo de IA a escala. Hable con nuestros expertos hoy mismo.