AI Engineering - Capítulo 4 - Evaluar los Sistemas de IA

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 4 - Evaluar los Sistemas de IA

Un modelo solo es útil si funciona para sus propósitos previstos, por lo que debe ser evaluado en el contexto de su aplicación. Este capítulo se divide en tres partes: criterios de evaluación, selección de modelos y el desarrollo de una tubería (pipeline) de evaluación.

Criterios de Evaluación

El “desarrollo impulsado por la evaluación” consiste en definir los criterios de éxito antes de construir la aplicación, garantizando así un retorno de inversión claro. Los criterios generales se dividen en cuatro categorías:

Capacidad de dominio específico: Se refiere a las habilidades inherentes que necesita un modelo (ej. entender latín o escribir código). Se evalúa típicamente mediante tareas cerradas, como las preguntas de opción múltiple (MCQs), que son fáciles de verificar frente a una línea base aleatoria. Sin embargo, los MCQs son sensibles a pequeños cambios en los prompts y están diseñados para probar clasificación y conocimiento, no la capacidad real de generación. Para código, se utilizan evaluaciones exactas como la corrección funcional, la eficiencia o el uso de memoria.
Capacidad de generación: Históricamente, las tareas de procesamiento de lenguaje natural (NLP) medían la “fluidez” y la “coherencia”, pero con la evolución de los modelos fundacionales, los textos generados ya son casi indistinguibles de los humanos, por lo que estas métricas han perdido protagonismo. En su lugar, surgen nuevas prioridades:
- Consistencia factual: Evalúa las alucinaciones del modelo. Puede ser local (el resultado se evalúa frente a un contexto proporcionado de forma explícita) o global (el resultado se evalúa frente al conocimiento general). Métodos de evaluación incluyen el uso de IA como juez, la auto-verificación (ej. SelfCheckGPT), la verificación aumentada por conocimiento usando motores de búsqueda (ej. SAFE de Google) y modelos de clasificación de implicación textual (NLI). Existen benchmarks como TruthfulQA diseñados para medir esto.
- Seguridad: Abarca la detección de lenguaje inapropiado, recomendaciones dañinas, discurso de odio, violencia, estereotipos y sesgos ideológicos o políticos. Para medirlos, se emplean jueces de IA de propósito general o clasificadores de toxicidad especializados y más económicos, apoyados en benchmarks como RealToxicityPrompts y BOLD.
Capacidad para seguir instrucciones: Determina qué tan bien el modelo respeta el formato esperado (ej. JSON) o las restricciones impuestas (ej. longitud, prohibición de ciertas palabras). Benchmarks como IFEval automatizan la verificación de estas reglas, mientras que otros como INFOBench utilizan jueces de IA para evaluar pautas de estilo o contenido más amplias. Un caso de uso fundamental aquí es el juego de roles (roleplaying), común en asistentes y videojuegos, donde la evaluación es más subjetiva y requiere medir si la IA mantiene tanto el estilo como el conocimiento estricto del personaje.
Costo y latencia: La evaluación requiere optimización de Pareto para equilibrar la calidad del modelo con su costo y velocidad. La latencia (tiempo hasta el primer token, tiempo total) puede mitigarse optimizando prompts o estableciendo condiciones de parada. El costo escala linealmente si se usan APIs (pago por token), pero el costo por token puede disminuir dramáticamente al escalar si se alojan modelos propios en hardware dedicado.

Selección del Modelo

El proceso de selección implica equilibrar atributos estrictos (hard attributes, como licencias o políticas de privacidad) y atributos flexibles (soft attributes, como precisión o toxicidad). El flujo de trabajo ideal consta de cuatro pasos: filtrar por atributos estrictos, acotar opciones usando benchmarks públicos, ejecutar experimentos con una tubería privada y monitorear en producción.

Construir versus Comprar (Open Source vs. APIs Comerciales)

Esta decisión inicial reduce significativamente el grupo de candidatos. Se debe analizar bajo siete ejes:

Privacidad de datos: Las políticas estrictas impiden enviar datos a APIs externas, lo que obliga a alojar modelos propios.
Linaje de datos y derechos de autor: La falta de transparencia sobre con qué datos se entrenó un modelo comercial genera riesgos de propiedad intelectual, aunque las APIs suelen ofrecer contratos que protegen al usuario, a diferencia del open source.
Rendimiento: Aunque la brecha se cierra, los modelos comerciales propietarios suelen tener el mejor rendimiento porque sus desarrolladores los monetizan en lugar de liberarlos.
Funcionalidad: Las APIs comerciales ofrecen escalabilidad inmediata y funciones out-of-the-box (como llamadas a funciones), pero a menudo restringen el acceso a datos útiles como los logprobs o limitan el finetuning.
Costo de API vs. costo de ingeniería: Escalar el uso de APIs es costoso financieramente, pero alojar un modelo requiere un inmenso talento, tiempo y esfuerzo de ingeniería.
Control, acceso y transparencia: Los modelos propietarios sufren de censura estricta (guardrails), cambios de versión opacos y límites de tasa (rate limits). Los modelos de código abierto garantizan acceso permanente y control total.
Despliegue local (On-device): Solo posible con modelos de código abierto.

Navegar por los Benchmarks Públicos

Los leaderboards (tablas de clasificación) públicas, como las de Hugging Face o HELM, agregan resultados de diferentes pruebas para rankear modelos. Sin embargo, la selección de qué pruebas incluir suele carecer de transparencia y las métricas muchas veces se promedian linealmente sin considerar la importancia relativa o la correlación estadística entre ellas. Además, la confiabilidad de estas tablas se ve amenazada por la contaminación de datos, que ocurre cuando el modelo ha sido entrenado inadvertida o intencionalmente con los datos de evaluación, memorizando las respuestas. Para combatirlo, se debe verificar la contaminación usando superposición de N-gramas o detectando puntuaciones de perplejidad inusualmente bajas, y los evaluadores deben mantener muestras de prueba ocultas.

Diseñar su Tubería de Evaluación

Dado que los benchmarks públicos no son totalmente confiables, es necesario diseñar una tubería propia para la aplicación específica.

Paso 1. Evaluar todos los componentes del sistema: Se debe evaluar la aplicación paso por paso (ej. extracción de texto y luego análisis de ese texto) para localizar el origen exacto de los fallos. Además, la evaluación debe realizarse tanto por “turno” individual como por “tarea” completa (ej. cuántos turnos tomó resolver un problema), siendo la evaluación por tarea la más alineada con el valor real para el usuario.
Paso 2. Crear una directriz de evaluación: Es crucial definir qué constituye una respuesta “buena” o “mala” (incluyendo lo que el modelo no debe hacer, como salir de su ámbito). Se deben establecer rúbricas de puntuación (binarias o numéricas) con ejemplos claros y validarlas con evaluadores humanos para evitar ambigüedades. Finalmente, las métricas de evaluación deben mapearse a métricas comerciales tangibles (ej. “80% de consistencia factual permite automatizar el 30% de los tickets”) para comprender su impacto en el negocio.
Paso 3. Definir métodos y datos de evaluación: Se pueden combinar métodos: clasificadores pequeños para el 100% de los datos y jueces de IA costosos para el 1%. Se deben recolectar conjuntos de datos anotados representativos de la producción y “rebanar” (slice) estos datos para analizar subgrupos; esto ayuda a detectar sesgos, encontrar áreas de mejora y evitar la paradoja de Simpson (donde métricas agregadas ocultan fallos en subgrupos). Utilizando bootstrapping, se puede estimar el tamaño de muestra necesario para que los resultados sean estadísticamente significativos y confiables. Por último, la tubería de evaluación misma debe ser evaluada: ¿Es confiable? ¿Muestra alta varianza? ¿Están correlacionadas sus métricas? ¿Es justificable su costo y latencia añadida?. El proceso debe iterarse constantemente registrando todas las variables del experimento.

Resumen

La evaluación es quizás el cuello de botella más grande para la adopción de la IA, pero una tubería robusta reduce riesgos y ahorra problemas a largo plazo. Seleccionar un modelo hoy en día es crear un tablero de clasificación privado basado en las necesidades específicas de la aplicación, combinando métodos para mitigar las limitaciones inherentes de los sistemas actuales.

Comentario Personal y Contexto Creativo (2026)

Si analizamos este capítulo desde nuestra perspectiva actual en 2026, el autor capturó perfectamente la metamorfosis de la IA: el cambio de paradigma donde la obsesión por el “mejor modelo fundacional” dejó paso a la disciplina de la Ingeniería de Sistemas de IA.

Hace unos pocos años, el mercado estaba hipnotizado por el hype de las tablas de clasificación públicas (leaderboards) y la eterna carrera armamentística entre OpenAI, Google y el ecosistema open-source. Sin embargo, el capítulo acierta de manera profética al señalar que evaluar la Inteligencia Artificial es mucho más un problema de negocio y de arquitectura de software que de ciencia de datos. La contaminación de datos (data leakage) en benchmarks que se menciona en el texto terminó por quebrar la confianza en las métricas estandarizadas. Hoy en día, ninguna corporación seria toma una decisión basada puramente en el puntaje MMLU de un modelo.

Lo más brillante de este fragmento es el concepto de Desarrollo Impulsado por la Evaluación (Evaluation-Driven Development). En la actualidad, este enfoque ha madurado hasta convertirse en el estándar absoluto en la industria. Ya no conectamos una API a una base de datos esperando que funcione; en cambio, diseñamos mallas enteras de modelos enrutados donde pequeños modelos hiper-especializados actúan como validadores implacables (los jueces de IA de los que habla el autor) evaluando la consistencia factual en milisegundos. El futuro que predijo este capítulo —donde la infraestructura de evaluación es el corazón mismo del producto— es exactamente el presente que estamos viviendo y construyendo.