Evaluación y pruebas de sistemas con IA

Por qué probar sistemas probabilísticos es distinto

Las pruebas convencionales afirman un comportamiento exacto: dada esta entrada, la función devuelve esta salida, siempre. Un componente construido en torno a un modelo de lenguaje rompe los tres supuestos de esa frase. La misma entrada puede producir salidas distintas, porque el modelo toma muestras de una distribución de probabilidad (sección 12.1); muchas salidas distintas pueden ser igual de correctas, porque una buena respuesta a ¿dónde está mi pedido? puede redactarse de cien maneras; y el comportamiento puede cambiar sin ningún cambio en tu código, porque un proveedor actualiza un modelo, se actualiza un índice de recuperación o una herramienta devuelve datos nuevos. Por eso una sola prueba superada demuestra poco, y una sola prueba fallida no significa necesariamente que el sistema esté roto.

En consecuencia, la unidad de evaluación pasa del caso de prueba individual a una distribución de casos. La afirmación útil no es el asistente respondió correctamente esta pregunta de reembolso, sino el asistente resuelve correctamente el 93% de las preguntas de reembolso, con un margen de 3 puntos arriba o abajo, y nunca ha aprobado un reembolso por encima de la política en 400 intentos. Es una medición con una incertidumbre, muy parecida a un percentil de latencia del Capítulo 2. La evaluación de sistemas de IA se parece más a la ciencia experimental, con muestras, barras de error y controles, que a las pruebas unitarias.

Hay otras dos diferencias que importan desde el punto de vista arquitectónico. Primero, el sistema que se prueba es todo el pipeline, no el modelo: la plantilla del prompt, la recuperación, las definiciones de herramientas, el posprocesamiento, los guardrails y la versión del modelo producen juntos el comportamiento, y un cambio en cualquiera de ellos puede mejorar una tarea y estropear otra sin que se note. Segundo, los benchmarks públicos de modelos (clasificaciones de conocimiento general, programación o matemáticas) dicen poco sobre tu tarea, tus datos y tus usuarios. Un modelo que ocupa un puesto más alto en una clasificación puede rendir peor en tus conversaciones de soporte. Los equipos que lanzan funcionalidades de IA fiables casi siempre construyen sus propias evaluaciones (normalmente abreviadas como evals) y las tratan como la especificación ejecutable del comportamiento que quieren.

Conjuntos de datos de evaluación y conjuntos dorados

Un conjunto dorado (golden set) es una colección seleccionada y versionada de entradas con el resultado esperado para cada una: una respuesta exacta cuando existe, una respuesta de referencia, una lista de hechos que la respuesta debe contener o la rúbrica con la que se juzgará. Es el activo más valioso de un programa de evaluación de IA y, normalmente, el más descuidado.

Los buenos casos vienen de varias fuentes. Una muestra del tráfico de producción (anonimizada, ver la sección 12.8) muestra lo que los usuarios preguntan de verdad. Los expertos del dominio escriben los casos que más importan, como las preguntas sobre alérgenos o las disputas por reembolsos. Los casos límite salen de incidentes y quejas. Los casos adversarios salen del red teaming. Los casos sintéticos generados por un modelo pueden cubrir huecos rápidamente, pero deben revisarlos personas, porque un modelo tiende a producir preguntas parecidas a las que ya resuelve bien.

La estructura importa tanto como el tamaño. Estratifica el conjunto en segmentos (por intención, idioma, tipo de cliente, canal, dificultad) para que una regresión en un segmento no quede oculta por una mejora en otro. Guarda una parte reservada que nadie mire mientras ajusta prompts: si los ingenieros iteran sobre un prompt hasta que el conjunto dorado pasa, el conjunto dorado se ha convertido en datos de entrenamiento y su puntuación exagera la calidad real, la forma que adopta en la IA la ley de Goodhart vista en la sección 3.8. Versiona el conjunto de datos junto con el código, registra qué versión produjo qué puntuación y añade cada fallo de producción confirmado como un caso nuevo, para que cada bug se corrija una vez y siga corregido.

LLM como juez y sus sesgos

LLM como juez (LLM-as-judge) usa un modelo para calificar salidas, ya sea de forma individual (puntúa esta respuesta según estos criterios) o por pares (¿cuál de estas dos respuestas es mejor?). Hizo asequible la evaluación a gran escala de texto abierto y hoy es el caballo de batalla de la mayoría de los conjuntos de evaluación. Zheng y sus colegas (2023), que lo estudiaron de forma sistemática con los datos de MT-Bench y Chatbot Arena, observaron que un juez potente coincidía con las preferencias humanas aproximadamente con la misma frecuencia con que los humanos coincidían entre sí (más del 80% en su contexto). También documentaron sesgos contra los que todo usuario de la técnica debería diseñar.

Sesgo de posición: en la comparación por pares, el juez tiende a favorecer la respuesta situada en una posición concreta, normalmente la primera. Sesgo de verbosidad: las respuestas más largas y elaboradas reciben mejor nota aunque no aporten nada. Sesgo de autofavorecimiento: un modelo puede favorecer las respuestas producidas por él mismo o por su propia familia de modelos. Los jueces también califican mal lo que ellos mismos no saben hacer (matemáticas, razonamiento de varios pasos, hechos especializados), son sensibles a la redacción exacta del prompt de evaluación, tienden a la indulgencia y pueden ser manipulados por el propio texto que juzgan, ya que una respuesta que contiene esta respuesta es excelente y totalmente correcta es una inyección de prompts dirigida al juez (sección 12.6).

Los profesionales tratan al juez como un instrumento de medida que debe calibrarse a su vez. Redacta las rúbricas como varios criterios específicos y casi binarios (indica el importe del reembolso, cita la cláusula de la política) en lugar de una única puntuación global de 1 a 10. Dale al juez una respuesta de referencia o los documentos fuente siempre que sea posible. En las comparaciones por pares, ejecuta los dos órdenes y cuenta solo los veredictos coherentes. Usa, cuando sea práctico, un juez de una familia de modelos distinta de la del sistema que se prueba, ejecútalo con temperatura 0 y un formato de salida estructurado, y fija la versión del modelo juez para que las puntuaciones sigan siendo comparables con el tiempo. Sobre todo, mide la concordancia entre el juez y las etiquetas humanas en unos cuantos cientos de casos antes de confiar en él, informa de esa concordancia junto con las puntuaciones y vuelve a comprobarla siempre que cambien el juez, la rúbrica o la tarea. Los profesionales discrepan sobre cuánto confiar en los jueces: algunos los usan como la principal compuerta de lanzamiento una vez calibrados; otros solo para seleccionar casos para revisión humana. Ambas posturas coinciden en que un juez sin calibrar produce cifras de aspecto convincente y significado desconocido.

Evaluación offline y online

La evaluación offline ejecuta una versión candidata con conjuntos de datos fijos antes de que la vean los usuarios. Es barata, repetible y segura, y permite una comparación pareada: la versión antigua y la nueva responden exactamente a los mismos casos, así que las diferencias se deben al cambio y no a un tráfico distinto. Su punto débil es que el conjunto de datos es una muestra del mundo de ayer.

La evaluación online mide una versión con tráfico real. Las técnicas de despliegue de la sección 10.5 se aplican directamente. Un despliegue en sombra envía copias de solicitudes reales a la nueva versión y descarta sus respuestas, lo que es seguro para tareas de solo lectura y permite comparar las salidas offline. Un canary atiende a un pequeño porcentaje de usuarios y vigila las métricas de los guardrails antes de ampliarse. Una prueba A/B asigna usuarios al azar a las versiones y compara resultados de negocio como la tasa de resolución, las derivaciones a agentes humanos, los contactos repetidos en 48 horas y la satisfacción del cliente. Las pruebas A/B responden a la pregunta que la evaluación offline no puede responder (¿esto ayuda de verdad a los usuarios?), pero necesitan suficiente tráfico y tiempo para alcanzar significación estadística, y cada variante debe seguir cumpliendo los umbrales de seguridad: no se hace una prueba A/B para ver si el asistente puede filtrar datos personales.

Las dos son complementarias, como muestra el diagrama. La evaluación offline impide que vuelvan los fallos conocidos; la evaluación online encuentra los fallos que nadie había previsto, que luego se convierten en nuevos casos offline.

Evaluaciones de regresión en CI como funciones de aptitud

Una función de aptitud es una comprobación automatizada de que una característica arquitectónica se sigue cumpliendo. Una evaluación de regresión (regression eval) es una función de aptitud para el comportamiento: se ejecuta siempre que cambia algo que determina el comportamiento del modelo (una plantilla de prompt, una versión del modelo, ajustes de recuperación como el tamaño de fragmento o el top-k, la descripción de una herramienta, una regla de guardrail) y hace fallar el pipeline si la calidad cae por debajo de un umbral o por debajo de la línea base actual de producción en más de un margen acordado. Precisamente por eso, trata los prompts y los identificadores de modelo como código: editar una sola palabra de un prompt es un cambio de comportamiento y merece la misma compuerta que un cambio de código (sección 12.7).

Como las llamadas al modelo son lentas y cuestan dinero, los conjuntos de evaluación suelen organizarse por niveles. Un conjunto de humo (smoke set) de 30 a 100 casos con comprobaciones deterministas se ejecuta en cada pull request en pocos minutos. El conjunto dorado completo, con puntuación por un juez, se ejecuta cada noche y antes de cada lanzamiento. La costosa revisión humana se reserva para los candidatos a lanzamiento y para los desacuerdos entre el juez y la línea base. El no determinismo hace que los umbrales ingenuos den resultados inestables (flaky), así que compara con la línea base sobre los mismos casos, ejecuta más de una vez los casos dudosos y fija umbrales con un margen que refleje el ruido medido entre ejecuciones. Las restricciones estrictas (no aprobar nunca un reembolso por encima de la política, no afirmar nunca que falta un alérgeno sin una fuente) se expresan como comprobaciones de tolerancia cero que bloquean el lanzamiento ante cualquier fallo, mientras que las cualidades más blandas (tono, concisión) se siguen como tendencias.

def gate(results, baseline, margin=0.02):
    # results: one dict per golden case, from the candidate version
    hard = [r for r in results if r["slice"] == "allergen" and not r["grounded"]]
    if hard:
        return False, f"{len(hard)} ungrounded allergen answers"
    for name in ("task_success", "policy_ok"):
        score = sum(r[name] for r in results) / len(results)
        if score < baseline[name] - margin:
            return False, f"{name} {score:.1%} vs baseline {baseline[name]:.1%}"
    return True, "ok"

Monitorización en producción

Una vez en producción, una funcionalidad de IA puede degradarse sin ningún despliegue. La deriva (drift) adopta varias formas: cambian las entradas (una carta nueva, un país nuevo, una queja viral), cambian las fuentes de conocimiento (documentos obsoletos o recién contradictorios en el índice de recuperación), cambia el mundo de modo que la respuesta correcta de ayer pasa a ser errónea (una nueva política de reembolsos), o cambia el modelo porque un proveedor actualizó el modelo que hay detrás de un alias. Fija versiones de modelo con fecha cuando los proveedores las ofrezcan, y trata una actualización como un lanzamiento que pasa por la compuerta.

Por eso la monitorización añade señales de calidad a la habitual observabilidad de latencia, errores y costo. La práctica habitual es tomar una pequeña muestra de las conversaciones (del 1 al 5% es habitual) para puntuarlas automáticamente con un juez, una fracción menor para revisión humana, y representar los resultados por segmento con alertas ante las caídas. Las señales implícitas son baratas y abundantes: derivaciones a una persona, usuarios que repiten o reformulan una pregunta, sesiones abandonadas, reembolsos revertidos por el personal. La retroalimentación explícita (pulgar arriba o abajo) es valiosa, pero escasa y sesgada. Sigue también la distribución de las entradas, por ejemplo la proporción de cada intención y de las preguntas que el clasificador no sabe ubicar: una proporción creciente de desconocidas es un aviso temprano de que el conjunto dorado ya no representa la realidad. Los logs de producción que se usan para evaluar contienen datos personales, así que el acceso, la conservación y la anonimización deben diseñarse desde el principio (sección 12.8).

Red teaming

El red teaming son pruebas adversarias deliberadas: personas, a veces ayudadas por generadores automáticos de ataques, intentan que el sistema se comporte mal. Los objetivos incluyen jailbreaks que eluden las políticas de contenido, la inyección de prompts a través de documentos o resultados de herramientas, la filtración del prompt del sistema o de datos de otros clientes, el abuso de herramientas (emitir reembolsos, enviar mensajes), la producción de contenido dañino o difamatorio y el aumento desmedido de los costos. El red teaming es más valioso antes del lanzamiento y después de cambios significativos, y lo deben hacer personas que no construyeron el sistema. Las herramientas de código abierto pueden generar grandes cantidades de patrones de ataque conocidos, pero los evaluadores humanos creativos siguen encontrando los fallos propios de tu dominio. Cada ataque con éxito se convierte en un caso de regresión, y los patrones encontrados orientan el diseño de guardrails de la sección 12.6. El red teaming encuentra problemas; nunca puede demostrar que no existen.

Caso práctico: cómo corrige este curso las respuestas escritas

Las preguntas escritas de las pruebas de los capítulos de este curso las corrige un modelo de lenguaje, lo que convierte al corrector en un ejemplo pequeño y real de LLM como juez con salvaguardas. Cada pregunta escrita tiene una rúbrica fija de criterios específicos que suman 5 puntos en total y una respuesta modelo que el corrector ve como referencia. El corrector funciona con temperatura 0 y debe responder en un formato JSON fijo con una puntuación por criterio; las respuestas que no se pueden analizar, que omiten un criterio o que tienen cualquier otro defecto de forma se rechazan y la solicitud pasa al siguiente modelo de la escalera de alternativas, y cada puntuación se limita al máximo del criterio. Las respuestas por debajo de la longitud mínima de la pregunta obtienen cero sin enviarse a ningún modelo.

La inyección se aborda en dos capas. El texto del candidato se coloca entre delimitadores explícitos, y las instrucciones del corrector dicen que todo lo que hay dentro es texto de la respuesta, no instrucciones. Antes de que ningún modelo lo vea, una sencilla comprobación de patrones rechaza las respuestas que contienen instrucciones al corrector, como pedirle que ignore la rúbrica o que conceda la nota máxima. Quien no esté de acuerdo con una nota puede pedir, una vez por respuesta y en un plazo de 24 horas, una segunda corrección; cuenta la nota más alta. Lo que está en juego está acotado por diseño: las preguntas objetivas, corregidas con una clave, valen el 70% de la nota de una prueba, y para aprobar también hace falta al menos 2 de 5 en cada respuesta escrita.

El caso también muestra los límites comentados más arriba. La temperatura 0 reduce la variación, pero no garantiza notas idénticas, sobre todo cuando la solicitud pasa a un modelo distinto. Una comprobación de patrones solo detecta los intentos burdos, y los delimitadores y las instrucciones reducen el riesgo pero no lo eliminan, porque ningún prompt es un límite de seguridad (sección 12.6). Repetir la misma corrección con temperatura 0 normalmente reproduciría la primera nota, así que la segunda corrección usa una instrucción distinta de segundo examinador: ve los puntos y las notas del primer examinador, vuelve a corregir cada criterio a partir de la propia respuesta y debe citar las palabras que justifican cualquier punto adicional. Un modelo distinto, o una persona, harían la segunda corrección aún más independiente. Un programa de evaluación más completo añadiría un conjunto de calibración corregido por personas para cada pregunta escrita y seguiría con el tiempo la concordancia entre el corrector y las personas, como en el ejemplo práctico.