La evaluación de los resultados generados por IA es fundamental para crear aplicaciones sólidas de modelos de lenguaje grandes porque permite dividir aplicaciones complejas de IA en etapas simples con control de errores incorporado.
Es relativamente sencillo evaluar los resultados generativos en un modo supervisado, donde evaluadores humanos pueden calcular o insinuar las “respuestas correctas”.
Al mismo tiempo, en muchas aplicaciones prácticas de LLM, el enfoque supervisado es demasiado restrictivo y se necesitan evaluaciones capaces de abordar preguntas abiertas. La forma más sencilla de crear un evaluador no supervisado es pedirle a un LLM que se evalúe a sí mismo. Sin embargo, no se comprende bien la capacidad de los modelos generativos para detectar errores en su propia producción.
Demostramos que la calidad de las autoevaluaciones se puede mejorar con una autorreflexión iterativa. De manera similar a la técnica de la “Cadena de pensamiento”, este método intercambia el cálculo de la inferencia por la solidez del resultado final.
Enlace al cuaderno de Google Colab con ejemplos:
https://colab.research.google.com/drive/1q_dChQBMbnUXZ377JVwYsjvn7lZ_7qlZ?usp=sharing
Al crear canales de procesamiento utilizando modelos de lenguaje grandes, el problema que se menciona a menudo es la calidad de los resultados generados. Si existe un buen proceso de evaluación, puede resaltar casos de desempeño deficiente y desencadenar ajustes en el LLM, ajustes rápidos, derivación a agentes humanos, o todas estas acciones a la vez.
A continuación se muestra un flujo de trabajo típico que utiliza evaluaciones para la capacitación: un LLM revisa el conjunto de datos de entrada y cualquier discrepancia de salida detectada por el evaluador se utiliza para generar datos sintéticos para ajustar el modelo. La aplicación se implementa solo cuando se cumplen las métricas de calidad objetivo.
El uso de evaluadores LLM en producción es muy similar, excepto que las discrepancias detectadas generalmente se envían a un agente humano para garantizar que el flujo de trabajo pueda continuar a pesar de generar un indicador de error.
Sin embargo, formar un buen evaluador de LLM no es trivial. La complejidad de este problema surge de dos restricciones prácticas:
Primeroes muy deseable minimizar la participación humana en las evaluaciones. Por ejemplo, imagine un chatbot interactuando con un usuario y sin un patrón coloquial común de puntos suspensivos (usando una palabra en lugar de la oración completa):
Bot: ¿Es eso correcto?
Usuario: correcto
Bot: Lo siento, no entendí eso. Por favor inténtalo de nuevo.
Usuario: si es correcto
Dada esta sección de diálogo, un humano debería resaltar fácilmente las deficiencias en la respuesta del chatbot y sugerir un curso de ajuste. Sin embargo, para encontrar este problema, un evaluador tendría que leer el diálogo completo (que puede ser muy largo). Este enfoque no funciona a escala, lo que significa que debemos esforzarnos por evaluación sin humanos.
Segundoel proceso de juzgar el resultado del LLM sin conocer la “verdad fundamental” es comparable en complejidad a la tarea original. Esto significa que un LLM de última generación puede (como máximo) emplear a un evaluador con capacidades similares (muy probablemente él mismo), lo que plantea preguntas sobre la validez de dicha evaluación.
Si observamos los LLM bien estudiados en la actualidad, notaremos que se centran principalmente en casos de uso supervisados o semisupervisados.
Si el conjunto de datos de entrenamiento viene con respuestas “verdaderas”, la evaluación se vuelve trivial e incluso puede impulsar marcos de optimización como DSPy. Lo mismo ocurre cuando se prueba una aplicación LLM empresarial con casos históricos manejados por agentes humanos, donde la “verdad sobre el terreno” equivale a los juicios de esos agentes.
Otra oportunidad para comparar el resultado con la “verdad básica” se presenta cuando el resultado del LLM se puede verificar formalmente por sí solo, como un código de computadora que se puede compilar y probar. A pesar de que un programa de computadora se puede escribir de muchas maneras diferentes, el código correcto debe pasar las pruebas independientemente de la ruta de implementación elegida.
Los casos en los que el resultado generativo no se puede verificar formalmente generalmente requieren agregar un humano al ciclo. Por ejemplo, RLHF se puede utilizar para calificar los resultados de LLM de acuerdo con las preferencias humanas ordinales y así dirigir la red hacia políticas complicadas y matizadas.
Mientras tanto, hay muchos casos de evaluación abiertos en los que no se puede implementar un enfoque de “verdad sobre el terreno” y el RLHF es demasiado largo o demasiado costoso. Esto explica el interés por las técnicas de autoevaluación no supervisadas.
Entonces, suponiendo que tengamos una pregunta de evaluación de LLM abierta que normalmente requeriría participación humana, como “¿Cómo puede mejorar este chatbot?”- ¿Qué se puede hacer para automatizar?
Se puede construir un arnés de evaluación económico si asumimos que los grandes modelos de lenguaje contemporáneos con ricas representaciones semánticas son inherentemente capaces de autoevaluarse. Esto significa que puede simplemente pedirle al modelo que evalúe su propio resultado o usar otro LLM para la misma tarea para evitar la contaminación cruzada en sus conjuntos de entrenamiento.
Desafortunadamente, una implementación ingenua de la autoevaluación del LLM puede fracasar. Hay dos posibles razones para esto.
La primera razón es el más obvio: un No se garantiza que LLM produzca resultados coherentes sobre temas que no se reflejan en su conjunto de capacitación. o inaccesible para herramientas de recuperación (como la búsqueda web). Por ejemplo, considere este fragmento de mapa de Google, que muestra una ciudad no incorporada llamada Mineral en California y una pequeña masa de agua (Martín Arroyo) que lo atraviesa.
La ciudad de Mineral no tiene su propia página de Wikipedia, y la mayoría de los LLM no utilizan datos SIG en su formación, por lo que cuando se les pregunta qué arroyo pasa por la ciudad, un LLM puede alucinar fácilmente:
arroyo del molino es un cuerpo de agua real que bordea el lugar designado por el censo (mucho más grande) del que Mineral forma parte. Sin embargo, arroyo del molino no pasa por la ciudad de Mineral propiamente dicha, por lo que la respuesta de GPT-4o es incorrecta.
Intuitivamente, se siente como una falla en la inferencia simple de LLM debido a que el tema está fuera del conjunto de conocimientos e inaccesible a través de herramientas comunes (como la búsqueda web) no debería ser fácilmente autodetectable.
El segundo La razón para fallar en las autoevaluaciones es algo más sutil y está impulsada por naturaleza probabilística de los resultados del LLM. Es fácil de demostrar en los casos en que la evaluación debe incluir múltiples observaciones. Por ejemplo, considere este diálogo entre el usuario y el chatbot:
Bot: Soy un chatbot para ayudarte a encontrar el mejor plan de telefonía móvil.
Usuario: Necesito al menos 500 Gb de datos y un precio inferior a 50 dólares
Bot: El plan “Ultimate Freedom” ofrece acceso ilimitado a Internet por $79,99
Usuario: Esto realmente podría funcionar.
Bot: ¿Quieres cambiar el plan actual?
Usuario: ¿“Ultimate Freedom” es sólo nacional? ¿Puedo tener roaming internacional?
Bot: Lo siento, no entendí eso. Por favor inténtalo de nuevo.
Usuario: Ya terminé por ahora. Por favor no realice ningún cambio.
Bot: Soy un chatbot para ayudarte a encontrar el mejor plan de telefonía móvil.
Si le pedimos repetidamente a un LLM que enumere las mejoras que se pueden realizar en el bot según este cuadro de diálogo, notaremos que la lista de resultados no es estable entre ejecuciones. Una versión puede verse así:
{["Ensure the bot can handle follow-up questions after suggesting a plan.",
"Improve bot's recognition of farewell messages.",
"Make sure the bot can assist with additional features or package inquiries."]}
Mientras que otro puede verse así:
{["Ensure the bot can switch contexts and answer follow-up questions.",
"Enable the bot to recognize when a conversation ends.",
"Improve the bot's ability to provide options for additional services",
"Support input about cost limitations, e.g. users stating a desired price."]}
Aunque existe una superposición significativa entre estas dos respuestas, está claro que en ninguno de los casos se generó una lista exhaustiva de sugerencias (similar a la que produciría un experto humano).
Una vez que describimos los modos de falla típicos para las evaluaciones, puede parecer que usar un LLM para juzgarse a sí mismo es una mala idea. Después de todo, esto suena como pedirle a un estudiante diligente que vuelva a verificar sus propias respuestas. Dado que un buen estudiante no comete muchos errores tipográficos, volver a verificar simplemente refleja el conocimiento existente y no debería resultar en mejoras.
Sin embargo, aquí es donde nuestra intuición sobre los LLM puede fallar terriblemente.
De hecho, la mayoría de los LLM son capaces de realizar una autoevaluación correctiva, incluso cuando el tema se encuentra fuera de su base de conocimientos..
Para ilustrar este fenómeno, volvamos al ejemplo de GPT-4o alucinando sobre el cuerpo de agua que cruza la localidad de Mineral., CALIFORNIA. Curiosamente, esta alucinación en particular puede disiparse durante la autoevaluación:
Entonces, ¿dónde está la magia?
En este ejemplo, el LLM no tiene el conocimiento ni las herramientas para obtener la respuesta correcta, por lo que alucina con la finalización “más plausible”. Sin embargo, cuando se le pide que se evalúe, llega a la conclusión de que los hechos a los que tiene acceso no corroboran lo dicho anteriormente. Aunque GPT-4o no sabe la respuesta correcta, puede descartar la incorrecta.
Un modelo más sofisticado (como GPT-4o1) puede ser un poco más difícil de tratar de la misma manera porque tiende a producir respuestas más matizadas:
En lugar de alucinar una finalización sobre el tema que no puede verificar, GPT-4o1 puede optar por responder la pregunta que nunca se hizo, como “¿Qué cuerpo de agua principal corre cerca de Mineral, CA?. Esta evasión significa que una autoevaluación directa del tipo “evaluar como verdadero o falso”puede fallar.
Sin embargo, una forma más deliberada de solicitar una autoevaluación aún puede tener éxito, incluso si requiere varias iteraciones:
Esta capacidad de los LLM para autorreflexionar de forma iterativa es, por supuesto, bien conocida y, en cierto modo, se da por sentada en aplicaciones como la generación de código. Aquí simplemente estamos extendiendo la misma técnica a la autoevaluación.
La misma idea de reflexión iterativa también es aplicable a las tareas de LLM que tienden a producir resultados incompletos. Si revisamos el ejemplo del diálogo del bot y permitimos que un LLM repita una lista memorizada de mejoras, observaremos que el modelo rara vez está “satisfecho” con el resultado en el primer intento.
En otras palabras, si formulamos un mensaje como este:
iterative_prompt = """
Consider the following dialog between the user and the chatbot.
The bot's goal is to suggest a cheaper mobile plan based on the information the user provides.
The user's responses are not guaranteed to be consistent or coherent at all times.This dialog was evaluated by an LLM and this evaluation is provided below.
You job is to assess the quality of evaluation and respond with "success"=True and repeat the original action list if there is nothing significant to add.
If there is something missing in evaluation, respond with "success"=False and a new list of action items to create better user experience integrating the old list with new suggestions. Make sure the list items are unique and not repetitive.
"""
Luego, normalmente se necesitarían entre 2 y 4 pasadas por la lista de mejoras hasta que el LLM converja en las recomendaciones y declare que la tarea de evaluación fue exitosa:
🍩
success='False' action_items=['Enable bot to understand user inquiries about add-on packages related to international calls.', "Improve bot's understanding to handle informal or casual goodbyes such as 'byebye'."]
🍩
success='False' action_items=['Enable bot to understand user inquiries about add-on packages related to international calls.', "Improve bot's understanding to handle informal or casual goodbyes such as 'byebye'.", "Enhance the bot's capability to suggest plans that are closer to the user's budget, such as recommending plans around $10 instead of $14 when the user specifies a $10 budget."]
🍩
success='False' action_items=['Enable bot to understand user inquiries about add-on packages related to international calls.', "Improve bot's understanding to handle informal or casual goodbyes such as 'byebye'.", "Enhance the bot's capability to suggest plans that are closer to the user's budget, such as recommending plans around $10 instead of $14 when the user specifies a $10 budget.", 'Ensure the bot confirms if the user is interested in plans without inclusive international minutes given their travel habits.', 'Add functionality for the bot to suggest alternative communication methods like VoIP for international calls if budget constraints are strict.', "Improve the bot's ability to suggest plans that balance cost with user requirements, such as considering travel habits and required features."]
🍩
success='True' action_items=['Enable bot to understand user inquiries about add-on packages related to international calls.', "Improve bot's understanding to handle informal or casual goodbyes such as 'byebye'.", "Enhance the bot's capability to suggest plans that are closer to the user's budget, such as recommending plans around $10 instead of $14 when the user specifies a $10 budget.", 'Ensure the bot confirms if the user is interested in plans without inclusive international minutes given their travel habits.', 'Add functionality for the bot to suggest alternative communication methods like VoIP for international calls if budget constraints are strict.', "Improve the bot's ability to suggest plans that balance cost with user requirements, such as considering travel habits and required features."]
Después de este “calentamiento” inicial sobre un diálogo, podemos alimentar el modelo con más diálogos de muestra y ver qué sucede.
De manera similar a lo que haría un evaluador humano, el modelo GPT-4o considera que no vale la pena producir muchas muestras de diálogo para producir nuevas recomendaciones (solo una ejecución del modelo es suficiente); sin embargo, algunas pueden desencadenar una deliberación mucho más larga:
El resultado final será una lista bastante exhaustiva de recomendaciones para mejorar el chatbot:
Final recommendations: ["Improve the bot's ability to avoid repetitive greetings and restarts when the user's input is vague or repeated, creating a more fluid conversation flow.",
"Enhance the bot's active listening skills to acknowledge user needs and concerns before suggesting starting over, to better handle user dissatisfaction.",
"Include a function allowing users to ask follow-up questions for more details about the suggested plan, such as data overage charges and roaming fees.",
"Develop a mechanism for the bot to detect and correct minor typographical errors and currency symbol mismatches in user inputs.",
"Provide alternative suggestions that might not fit all criteria but offer significant savings or benefits in other areas based on the provided user data.",
"Implement a feedback system enabling users to rate the accuracy or helpfulness of the plan suggestion provided, allowing for iterative improvements.",
"Incorporate a bot training mechanism to ensure it can handle responses that are non-standard in format or include extraneous details not directly related to the plan.",
"Add the ability for the bot to suggest seeking human assistance when complex queries or dissatisfaction arise that the bot cannot resolve.",
"Enhance the bot's language processing capabilities to accurately interpret various phrasings and informal expressions from the user.",
"Increase the bot's capability for dynamic clarification requests, creating a smoother interaction flow.",
"Refine the bot's ability to verify user information effectively to reduce misunderstandings and user frustration.",
"Improve the bot's handling of unrealistic and inconsistent user inputs to guide the conversation back to relevant queries.",
"Integrate a process for flagging nonsensical data entries and guide the user toward providing accurate information.",
"Provide clearer explanations or breakdowns of the suggested plan's features, especially if different from the user's mentioned requirements.",
"Improve response to questions unrelated to starting new calculations to avoid redundant loops."]
Algunas notas técnicas sobre este ejemplo:
- Para simplificar, hemos combinado la evaluación y la generación en un solo mensaje que se basa en Resultados estructurados de OpenAI para producir el resultado deseado.
- La limitación inherente de la memorización es un requisito para procesar muestras de forma secuencial. Esto puede llevar algún tiempo en un conjunto de datos extenso y también nos impide utilizar inferencias baratas a través de llamadas por lotes.
Para mejorar aún más el rendimiento, podemos aprovechar el hecho de que la mayoría de las muestras de un conjunto de datos no generan nuevos conocimientos. Esto significa que podemos producir la lista inicial de recomendaciones iterando sobre un pequeño subconjunto de muestras de forma secuencial y servir el resto del conjunto de datos en paralelo a través de Biblioteca de cadena de datos (o en un lote con API abierta de IA) para marcar los casos “interesantes” y reducir entre un 30% y un 50% los presupuestos de tiempo (o gastos) según sus preferencias.
Los LLM pueden y deben utilizarse para evaluaciones no supervisadas (incluidas las autoevaluaciones). La letra pequeña es que requiere un enfoque bien pensado, que a menudo resulta en una forma iterativa de mejorar y refinar los juicios.
Aquí hay un enlace a la implementación de muestra en Google Colab:
https://colab.research.google.com/drive/1q_dChQBMbnUXZ377JVwYsjvn7lZ_7qlZ?usp=sharing