A lo largo de la historia hemos construido aplicaciones software y nos hemos dado cuenta de que hacer un testing manual no era algo viable, si no que necesitamos automatizarlo con pruebas unitarias, pruebas de integración y pruebas end to end. Este proceso lo hemos estado automatizando para que, cada vez que se vaya a hacer un despliegue en un entorno, estemos seguros de que los nuevos cambios no han modificado el comportamiento esperado de todo lo que teníamos construido previamente.
Con los programas tradicionales de software, parece evidente construir casos de prueba ya que, normalmente los flujos que probamos son: dada una entrada y una lógica ejecutada, comprobar que una salida cumple unos criterios (por ejemplo, el número de elementos devueltos por una API es exactamente 2, el id del elemento devuelto es «12», etc.). Sin embargo, a la hora de comprobar el resultado que devuelve un modelo de lenguaje, esto no parece tan trivial.
Piensa en cuando utilizas ChatGPT: puedes lanzar la misma pregunta 2 veces y no obtener el mismo resultado. Además, el punto de utilizar Inteligencia Artificial Generativa en nuestros programas, es para no lidiar con las múltiples variaciones de respuestas que pueden existir (no queremos construir millones de if-else, si no que la IA se encargue de entender lo que pide el usuario y generar una respuesta acorde a ello). Entonces, si no sabemos cuál va a ser el resultado de un modelo de lenguaje, ¿cómo sabemos si es correcto?
Existe la posibilidad de que un humano pueda validar la respuesta del modelo manualmente, pero podemos imaginar que esto no es viable ya que es demasiado costoso.
En la actualidad existen diferentes técnicas para hacer este tipo de validaciones, pero la más conocida es LLM-as-a-judge. ¿En qué consiste? Te lo explico a continuación.
LLM as a judge
Como su nombre indica, en esta técnica lo que hacemos es utilizar otro Large Language Model (LLM, de gran modelo de lenguaje) que será el encargado de decir si la respuesta de otro LLM (el de nuestra aplicación) está respondiendo correctamente o no. ¿En base a qué? A las instrucciones que nosotros indiquemos.
En LangSmith de LangChain se nos permite configurar un evaluador. En la siguiente imagen se ve una representación de qué opciones tenemos para un evaluador, que nos ayudará a entender cómo funciona.
La intuición tras esto es muy sencilla: que sea un modelo (el juez) el que valide la respuesta de otro modelo. La ventaja de esto es que, además de que es automatizable, podemos definir el prompt del juez de múltiples formas como proporcionándole ejemplos de qué tipo de respuestas esperamos (few-shot evaluator) o simplemente dándole instrucciones de qué debe hacer.
Podemos imaginar el prompt del juez como lo siguiente:
You are assessing a chat bot RESPONSE to a user's QUERY in comparison to a REFERENCE response. A score of 1 is best and means that the response fits the criteria, whereas a score of 0 is worst and means that it did not fit the criteria.
Criteria:
<Your criteria here>
Use the examples below for reference.
{{Few-shot examples}}Imagina ahora poder aplicar el evaluador sobre las respuestas que se van generando en nuestra aplicación en producción y que se nos notifique cuando haya anomalías en las respuestas.
Atractivo, ¿verdad?
Si quieres saber más sobre el tema te recomiendo que leas este artículo de Hugging Face: https://huggingface.co/learn/cookbook/llm_judge
