AI Engineering - Capítulo 3 - Metodología de Evaluación

A continuación, se presenta un resumen detallado de los puntos principales del texto, respetando estrictamente la cronología y las secciones originales de la autora:

Capítulo 3: Metodología de Evaluación

La rápida adopción de la IA ha introducido riesgos graves de fallos catastróficos, como abogados presentando pruebas alucinadas o lo chatbots dando información falsa a pasajeros, haciendo del control de calidad y la evaluación una prioridad crítica. Para muchos equipos, desarrollar un pipeline de evaluación es el mayor obstáculo en la construcción de aplicaciones de IA. La evaluación debe tratarse sistemáticamente para identificar probables puntos de fallo, ya que ninguna métrica puede hacer robusto un sistema sin visibilidad de sus debilidades específicas.

Desafíos de Evaluar Modelos Fundacionales

Evaluar modelos fundacionales presenta dificultades únicas en comparación con los modelos tradicionales de Machine Learning (ML):

Nivel de inteligencia: A medida que la IA alcanza mayor inteligencia, evaluar sus resultados requiere experiencia especializada en el dominio (por ejemplo, evaluar matemáticas de nivel de doctorado) y un tiempo significativo para la verificación de datos.
Naturaleza abierta: El ML tradicional compara resultados contra un conjunto cerrado de categorías esperadas, pero los modelos fundacionales abiertos tienen innumerables respuestas correctas posibles, lo que socava el uso de verdades absolutas (ground truths) estáticas.
Limitaciones de caja negra: Sin acceso a la arquitectura del modelo o datos de entrenamiento, los desarrolladores solo pueden evaluar modelos observando sus resultados. Los benchmarks públicos (como GLUE o MMLU) también son inadecuados porque se saturan rápidamente a medida que los modelos alcanzan puntuaciones perfectas.
Alcance en expansión: Evaluar modelos de propósito general no solo requiere medir tareas conocidas, sino también descubrir nuevas capacidades que pueden superar los límites humanos.

A pesar del crecimiento exponencial en la investigación sobre evaluación y repositorios en GitHub, la inversión en herramientas de evaluación se queda muy atrás respecto al modelado, entrenamiento y orquestación. Esto obliga a muchos desarrolladores a depender de métodos inadecuados o ad hoc, como evaluar resultados “a ojo” o basarse en el boca a boca.

Entendiendo las Métricas de Modelado de Lenguaje

Dado que los modelos fundacionales dependen en gran medida de los componentes del modelo de lenguaje, su rendimiento en tareas derivadas está muy correlacionado con las métricas centrales de modelado de lenguaje.

Entropía: Esta métrica calcula la información promedio que lleva cada token. Un lenguaje con menor entropía es más predecible porque sus tokens conllevan menos información nueva.
Entropía Cruzada (Cross Entropy): Mide la dificultad a la que se enfrenta un modelo de lenguaje al predecir el siguiente token en un conjunto de datos específico. Combina matemáticamente la entropía verdadera de los datos de entrenamiento con la divergencia de la distribución aprendida por el modelo. Los modelos se entrenan para minimizar su entropía cruzada.
Bits-per-Character (BPC) y Bits-per-Byte (BPB): Debido a que diferentes modelos utilizan distintos métodos de tokenización, BPC y BPB estandarizan las mediciones de entropía cruzada para representar la eficiencia de compresión.
Perplejidad (Perplexity - PPL): Siendo el exponencial de la entropía cruzada, la perplejidad mide la incertidumbre del modelo al predecir el siguiente token. Una perplejidad más baja indica una mayor precisión. Se espera que caiga cuando los datos están muy estructurados o la longitud del contexto es mayor, y que aumente con vocabularios más grandes. Aunque la perplejidad actúa como indicador de las capacidades de un modelo, las técnicas posteriores al entrenamiento como el Finetuning Supervisado (SFT) y Aprendizaje por Refuerzo a partir de la Retroalimentación Humana (RLHF) tienden a reducir la entropía y aumentar la perplejidad. También es muy útil para detectar contaminación de datos (los datos de entrenamiento memorizados muestran baja perplejidad) e identificar texto anormal.

Evaluación Exacta

La evaluación exacta produce juicios inequívocos, centrándose en la corrección objetiva.

Corrección Funcional: Evalúa si un sistema ejecuta la función prevista, lo que la convierte en la métrica de rendimiento definitiva. Puede evaluarse automáticamente en tareas como la generación de código, donde el código se ejecuta contra casos de prueba para calcular una puntuación pas@k, o en bots de juegos con objetivos medibles.
Mediciones de Similitud frente a Datos de Referencia: Para tareas en las que la corrección funcional automatizada es imposible, los resultados generados se comparan con datos de referencia creados por humanos o IA (ground truths).
- Coincidencia exacta (Exact match): Una puntuación binaria que verifica si la respuesta generada coincide perfectamente con una referencia. Solo funciona en tareas simples y cortas como trivia o matemáticas, fracasando por completo en traducciones de textos abiertos y complejos.
- Similitud léxica: Mide la superposición física de texto a través del cruce difuso (distancia de edición) o la superposición de n-gramas (BLEU, ROUGE). Sus inconvenientes incluyen puntuaciones bajas cuando generaciones válidas simplemente no coinciden con las referencias seleccionadas, y el hecho de que optimizar puntuaciones léxicas no equivale a lograr la corrección funcional.
- Similitud semántica: Mide la superposición de significado en lugar de la ortografía. Requiere transformar el texto en vectores numéricos llamados embeddings, y luego calcular la distancia entre los vectores usando similitud coseno (ej. BERTScore).
Introducción a los Embeddings: Los embeddings son representaciones numéricas de menor dimensión que capturan la esencia de los datos en bruto, típicamente de tamaños entre 100 y 10.000 elementos. Los buenos algoritmos de embedding garantizan que conceptos similares tengan vectores más cercanos. Modelos multimodales avanzados, como CLIP e ImageBind, generan espacios de embeddings conjuntos donde diferentes modalidades (como imágenes y texto) pueden compararse directamente.

La IA como Juez (LLM-as-a-judge)

También conocido como LLM-as-a-judge, este método de evaluación subjetiva utiliza modelos de IA para evaluar las respuestas de otras IA.

¿Por qué la IA como Juez? Es rápido, relativamente barato, flexible en múltiples criterios (toxicidad, exactitud, etc.) y funciona sin necesidad de datos de referencia. Los jueces de IA demuestran fuertes correlaciones con los evaluadores humanos y pueden dar explicaciones sobre sus puntuaciones.
Cómo usar la IA como Juez: La IA puede calificar una respuesta aislada, comparar una respuesta con una referencia o determinar la preferencia del usuario entre dos posibles respuestas. Los prompts estándar deben definir explícitamente la tarea, los criterios y el sistema de puntuación. Los jueces de IA funcionan mejor con clasificaciones o escalas numéricas discretas (ej. 1 a 5) que con valores continuos, y se benefician enormemente de proporcionar ejemplos (few-shot) en el prompt.
Limitaciones de la IA como Juez:
- Inconsistencia: Debido a que los modelos son probabilísticos, el mismo prompt puede arrojar distintas puntuaciones en diferentes ejecuciones.
- Ambigüedad de criterios: Los criterios integrados en herramientas de código abierto (como MLflow, Ragas y LlamaIndex) carecen de estandarización, lo que significa que una puntuación de “fidelidad” (faithfulness) de una herramienta no puede compararse con otra.
- Aumento de costos y latencia: Evaluar resultados con modelos de gran tamaño como GPT-4 duplica los costes de API e introduce graves cuellos de botella por latencia en pipelines de producción.
- Sesgos: Los jueces de IA sufren sesgo egocéntrico (favoreciendo sus propias respuestas generadas), sesgo de posición (favoreciendo la primera opción presentada) y sesgo de verbosidad (favoreciendo respuestas más largas incluso si contienen errores fácticos).
¿Qué Modelos Pueden Actuar como Jueces? Los modelos fuertes se correlacionan mejor con la preferencia humana, pero las limitaciones de coste obligan con frecuencia a los desarrolladores a utilizarlos solo para verificaciones aleatorias (spot-checking) de modelos más débiles. Los modelos también pueden autocriticarse para revisar sus propias salidas. Una alternativa muy prometedora es el uso de jueces más pequeños y especializados, como modelos de recompensa (que otorgan puntajes entre 0 y 1), jueces basados en referencia (Prometheus) o modelos de preferencia (PandaLM) entrenados específicamente para predecir la preferencia humana.

Clasificación de Modelos mediante Evaluación Comparativa

En lugar de asignar puntuaciones absolutas, la evaluación comparativa clasifica a los modelos poniéndolos a prueba entre sí y determinando cuál prefieren los usuarios.

Proceso: Se muestran a los evaluadores respuestas de múltiples modelos lado a lado para que elijan un ganador. La tasa de victoria (win rate) se calcula en base a múltiples enfrentamientos, y algoritmos como Elo o Bradley-Terry generan una clasificación predictiva, popularizada ampliamente por Chatbot Arena de LMSYS.
Desafíos de la Evaluación Comparativa:
- Cuellos de botella de escalabilidad: El número de comparaciones escala de forma cuadrática respecto a la cantidad de modelos, y la suposición de transitividad (si A > B y B > C, entonces A > C) está en debate dentro de las preferencias de IA.
- Falta de estandarización y control de calidad: Las clasificaciones apoyadas en fuentes comunitarias (crowdsourcing) padecen de datos ruidosos, de usuarios que prefieren respuestas amables pero fácticamente incorrectas, y además de la prevalencia de instrucciones elementales y sin dificultad (como “hola”) que ensucian los rankings.
- De la comparativa al rendimiento absoluto: Saber que el Modelo B vence al Modelo A no revela si el Modelo B es netamente “suficientemente bueno” para una aplicación a nivel empresarial, lo cual entorpece los estudios de costo-beneficio.
El Futuro de la Evaluación Comparativa: A pesar de las limitaciones, la evaluación comparativa permite capturar la verdadera preferencia humana sin saturarse de forma instantánea ante IAs sobrehumanas, lo cual hace que sea más difícil de burlar que una métrica estática y resulta fundamental para analizar tareas de corte subjetivo.

Resumen

A medida que aumentan los riesgos de la IA, la evaluación automatizada y sistemática es necesaria. Métricas principales como la perplejidad y la entropía cruzada sirven como fundamentos del modelado de lenguaje, mientras que las evaluaciones exactas (corrección funcional, coincidencia exacta, embeddings semánticos) ofrecen una puntuación inequívoca. Debido a que las evaluaciones exactas tienen dificultades con tareas abiertas, la IA como juez y la evaluación comparativa han aumentado en popularidad, aunque ambas deben navegar por limitaciones subjetivas, sesgos y una falta de métricas de puntuación estandarizadas.