Prompt Engineering Toolkit

Hola a todos. Soy Manoj Sureddy. Trabajo como ingeniero de software en Uber. Lidero el equipo de automatización de soporte al cliente y chatbots de IA generativa. Hoy voy a hablar sobre cómo construimos un conjunto de herramientas de ingeniería de prompts que te permite usar soluciones basadas en LLM a gran escala. Con el advenimiento de chatGBT y otros modelos LLM, ha habido una explosión en el uso de IA generativa en varios productos de múltiples empresas, y esa ha sido la misma tendencia para nosotros.

Y seamos sinceros, los LLM son increíbles, pero cuando los usas en producción, no tanto, porque tenemos que lidiar con muchas complejidades que vienen con soluciones tan inteligentes. Principalmente, el flujo de trabajo general de desarrollar cualquier prompt es muy ad hoc y manual por naturaleza, porque tienes que iterar, realizar muchas pruebas y errores en estos prompts. Y en la mayoría de los casos de uso, estarás manteniendo estos prompts en código, Google Docs o cualquier cuaderno aleatorio, esencialmente.

Así que no hay una forma clara de descubrir qué hacen estos prompts. Y además, la reutilización de estos prompts es algo que es muy escasa en varias empresas. Así que, principalmente, digamos que si una técnica específica de ingeniería de prompts o ajuste de prompts funcionó bien para el prompt A, aplicarla directamente en el prompt B es prácticamente rehacer la mayoría de los elementos que has hecho. Básicamente, prueba y error y todos los otros mecanismos de prueba que tienes que hacer con eso. Aparte de esto, descubrir qué técnicas funcionaron bien y cómo podemos aprender de otros ingenieros que construyeron tipos similares de prompts es algo que no existe en la mayoría de los flujos de trabajo aquí.

Y también, a medida que el prompt crece, se vuelve cada vez más frágil y no determinista porque conduce a muchas alucinaciones y todos los otros efectos secundarios de usar elementos. Y con esta creciente complejidad, la velocidad de ingeniería también disminuye. ¿Te suena familiar? Sí. Para asegurarnos de que el desarrollo de prompts sea menos caótico, el desafío para nosotros es traer orden a este caos.

Para asegurarnos de que el desarrollo de prompts sea lo más organizado posible y podamos traer ese orden al caos, como estábamos hablando en la diapositiva anterior, ahí es donde entra en juego el conjunto de herramientas de ingeniería de prompts. Proporciona a los desarrolladores un marco claro sobre cómo crear, versionar y probar prompts. Guarda estos prompts como plantillas, lo que te permite reutilizarlos en varios casos de uso junto con otras soluciones basadas en LLM como RAG o Qshort y Zeroshort example-based prompting.

Y cómo puedes inyectar dinámicamente esos ejemplos en estos prompts.

Piénsalo como React para prompts. Estructurado, componible y comprobable por naturaleza. Los desarrolladores pueden centrarse principalmente en la lógica, mientras que tenemos el boilerplate repetido y los conjuntos de datos dorados y otros ejemplos principales disponibles para ellos, que podrían reutilizar de otros repositorios como tal. También integramos con control de versiones y pipeline CI-CD para que puedas ejecutar evaluaciones automatizadas en estas plantillas de prompts tan pronto como se comprometan. Esto te permite identificar regresiones así como desviaciones de la solución original de una manera más orientada a métricas.

Vamos a entrar en una de las plantillas y ver cómo funciona. Así que si ves aquí, la plantilla aquí contiene un nombre, descripción, instrucciones del sistema y parámetros del modelo. Ahora, este es un bot de preguntas y respuestas simple donde te pedimos que respondas las preguntas. Es muy rudimentario por naturaleza. Verás que el modelo que estamos usando es llama, y hemos establecido la temperatura a 0.5 y el máximo de tokens a 100. Ahora puedes ejecutar rápidamente este prompt y ver cómo se ejecuta.

Bueno, está respondiendo sobre pingüinos. ¿Cómo está sucediendo esto? Así que vamos a la prueba. Aquí puedes ver que el conjunto de herramientas de prompts te proporciona un cliente donde puedes pasar un conjunto de mensajes. Cada uno puede ser una conversación del usuario, y aquí el usuario está pidiendo datos curiosos sobre pingüinos. Y el modelo llama ha devuelto la respuesta. Ahora digamos que estás usando un modelo llama, y quieres cambiar a Gemma. No necesitas crear diferentes integraciones como tal. Este conjunto de herramientas se integra con casi todos los modelos a través de su API gateway. Para esta demostración, estoy usando un gateway público común, pero puedes usar cualquiera de tus API gateways para hacer esto.

Entonces, si ves aquí, está usando Gemma, y tiene el mismo prompt. Pero si ves, hay una plantilla adicional aquí. Este tipo de plantillas pueden permitirte inyectar ejemplos, o inyectar parámetros adicionales de consultas basadas en rag o pocos ejemplos cortos que mantienes, lo que enriquece tu prompt. Puedes realizar la misma ejecución, y prácticamente devuelve el resultado en esto, y las pruebas son similares.

Ahora hablemos de calidad. Si el prompt falla en producción, es el fin del juego. A medida que pasas por un montón de iteraciones en tu ciclo de vida de desarrollo de prompts, las regresiones son inevitables. Así que, tienes que asegurarte de que tus iteraciones de prompts mantengan el mismo nivel de calidad que la anterior. Así que, el conjunto de herramientas de prompts te proporciona un mecanismo para evaluar tus prompts bajo dos condiciones. Principalmente, LLM como una evaluación basada en juez, que es principalmente un mecanismo de evaluación automatizado. El segundo es la evaluación con humano en el bucle.

Hablemos del primero. En el primero, usaríamos un modelo de lenguaje más grande, generalmente que ha sido evaluado por su calidad. Y luego lo ejecutamos como un juez, donde ejecuta el mismo prompt e identifica si la respuesta coincide con la respuesta de prueba. Así que en el lado derecho, si ves, hemos añadido un par de pruebas. Vamos a entrar en su funcionamiento en un minuto. Tienes el nombre de la prueba, entrada y salida. El juez LLM básicamente generaría la misma respuesta y la compararía semánticamente si es verdadera o falsa.

Estas son métricas subjetivas, enfocándose principalmente en el tono, estilo así como la corrección y concisión de la respuesta. Mientras que la evaluación con humano en el bucle detectaría los matices e intenciones así como el tono de la respuesta en sí, también señalaría casos límite y alucinaciones. Esto puede ser retroalimentado al LLM como una evaluación de juez actualizando tus conjuntos de datos dorados o tus pruebas de tal manera que las nuevas evaluaciones humanas se automatizarán. Esto ocurre como un ciclo de vida y eventualmente puedes obtener un conjunto muy robusto de casos de prueba y aún identificar cualquier caso límite usando la evaluación con humano en el bucle.

Usualmente, hacemos un muestreo de respuestas para no realizar una evaluación con humano en el bucle a gran escala. Hacemos un pequeño subconjunto del total de respuestas. Veamos cómo funciona. Has visto anteriormente que esta es la plantilla. Ahora veamos cómo se pueden añadir pruebas a ella. Aquí si ves, tenemos un par de pruebas, principalmente una prueba positiva y una negativa. He añadido un ejemplo contrario aquí.

Este prompt está resumiendo tickets de soporte al cliente. Estamos tratando de identificarlo como una respuesta corta. Estamos usando el modelo LLM aquí. Mismas restricciones de temperatura y tokens máximos. Si ves el primero, el usuario está proporcionando una reseña y básicamente la estamos resumiendo. El segundo, el usuario está agradeciendo por la entrega rápida. Lo estamos mencionando como un resultado de prueba negativo. Principalmente, solo ejecutémoslo y veamos. Si ves, la prueba 2 falló como se esperaba. Aquí estamos proporcionando el razonamiento de por qué falló.

La respuesta general de la prueba que estamos tratando de ver es una respuesta positiva, pero hemos identificado algunas negativas. Podemos señalarlas. La segunda prueba pasó porque es algo que esperábamos. Puedes ejecutar este tipo de pruebas en estas plantillas. A medida que iteras en estos prompts, puedes mantener estos casos de prueba listos. Para que puedas seguir un enfoque más orientado al desarrollo basado en pruebas. Para que tu prompt no retroceda o se desvíe de los conjuntos de datos de calidad esperados.

Ahora veamos rápidamente el evaluador. Este evaluador no hace nada más que una pequeña evaluación donde está aumentando el prompt inicial para cada prueba. Este aumentador está sustituyendo dinámicamente las respuestas en la plantilla misma. Veamos la plantilla de prueba para obtener una mejor idea de ella. Aquí, la plantilla de prueba está estableciendo principalmente una persona para el LLM. Está pidiendo, basado en el prompt de entrada y la entrada de prueba, generar una salida. Hemos dado una pequeña plantilla. Luego estamos pidiendo al LLM que devuelva verdadero o falso. Si es verdadero, no devuelvas ningún contenido. Si es falso, devuelve la razón de ello. Estamos usando prácticamente el mismo modelo y parámetros aquí. Esto es solo para fines de demostración.

Ahora, cuando entras en el evaluador, principalmente ejecutamos estas pruebas contra el LLM mismo y registramos las respuestas como se esperaba. Así es como básicamente ejecutamos estas pruebas y nos aseguramos de que cada prompt pase por este pipeline de evaluación. Automatizamos toda esta evaluación dentro de nuestro ecosistema y nos aseguramos de que los prompts no se desvíen mucho de la calidad de salida esperada. Ahora veamos qué hemos aprendido al desarrollar este toolkit. El aprendizaje principal de esto es que el drift de prompt es real. La cuestión es que cualquier pequeño cambio en tu prompt generalmente hace que se desvíe drásticamente en algunos escenarios. Tratar tus prompts como código mediante versionado y pruebas, así como revisarlos regularmente, garantizaría que mantengas el mismo nivel de calidad de producción en tus productos. La calidad del prompt generalmente mejora con la retroalimentación real de los usuarios.