Evaluaciones

docs.scrimba.com

Cambias un prompt, lo pruebas una vez, la respuesta se ve mejor, y lo despliegas, luego una semana después los usuarios encuentran los casos que silenciosamente empeoraste. Una evaluación (abreviado eval) es la solución: una prueba repetible de si tu función de IA funciona, un conjunto de entradas emparejadas con lo que se parece a una buena salida, calificadas de la misma manera cada vez para que puedas saber si un cambio realmente ayudó. Un modelo es una caja negra probabilística que responde la misma pregunta de manera diferente en cada ejecución, por lo que medir es la única forma de saber, y esa disciplina es gran parte de lo que separa una demostración de un producto.

Por qué inspeccionar a simple vista falla

Verificar las respuestas de tu IA a mano se siente bien al principio. Ejecutas un prompt, lees la respuesta, y se ve bien, así que continúas. El problema es que tres cosas silenciosamente trabajan en tu contra, y ya las has conocido a todas.

Aquí están las tres:

• La salida varía. El mismo prompt puede dar diferentes respuestas en cada ejecución, así que un buen resultado no promete que el siguiente también será bueno.
• Los cambios causan regresiones. Una edición de prompt que arregla un caso a menudo rompe otro en el que no estabas mirando.
• No escala. Puedes leer cinco respuestas. No puedes leer quinientas cada vez que cambias una línea.

Nada de esto significa que hiciste algo mal. Significa que inspeccionar a simple vista es la herramienta equivocada para un trabajo de este tamaño, y hay una forma más tranquila de hacerlo.

JunoPor qué inspeccionar a simple vista falla Leer respuestas a mano se desmorona por tres razones, todas enraizadas en cómo funciona el modelo: la salida varía de una ejecución a otra, los edits silenciosamente rompen casos en los que no estabas mirando, y no puedes mantenerte al día a mano una vez que hay cientos de respuestas. No es un problema de disciplina, es la herramienta equivocada para el tamaño del trabajo. La buena noticia es que la solución es amigable, y viene a continuación.

Inspeccionar una respuesta a simple vista te dice casi nada, y la razón está en cómo funciona el modelo. Porque la salida es no determinística (el mismo prompt puede dar diferentes respuestas en cada ejecución), una respuesta única es una muestra de tamaño uno. No puede decirte la tasa de aprobación, la fracción de casos que salen bien, porque necesitas muchas ejecuciones sobre los mismos casos para estimar qué tan a menudo realmente funciona.

Las regresiones se esconden por una razón relacionada. Arregla un caso a mano y no tienes registro de los otros, así que el próximo edit puede romper algo que dejaste de mirar. La única forma de verlo es un conjunto fijo de casos calificados de la misma manera cada vez, por lo que una caída se muestra como un número en lugar de una sorpresa en producción.

Hay un problema humano además de las matemáticas. La revisión manual se desvía entre personas y entre estados de ánimo: la misma respuesta se lee bien el lunes y débil el viernes. Así que el movimiento es convertir "se ve bien" en una tasa de aprobación medida sobre un conjunto fijo de casos. Convierte una vibra en un número sobre los mismos casos.

JunoPor qué inspeccionar a simple vista falla Una respuesta es una muestra de tamaño uno, así que te dice que el modelo funcionó una vez, no con qué frecuencia funciona. Para ver una tasa de aprobación real ejecutas muchos casos; para atrapar regresiones fijas ese conjunto de casos y lo calificar de la misma manera cada vez. La revisión manual también se desvía con el revisor, así que el trabajo es reemplazar "se ve bien" con un número medido.

La verificación puntual no falla porque seas negligente. Falla porque tiene sesgo de selección incorporado: miras los casos que esperas que funcionen, así que el comportamiento que nunca verificas es el que retrocede frente a los usuarios. La métrica que no rastreas es exactamente la que se mueve.

Sin una puntuación base, cada cambio de calidad es una historia que te cuentas a ti mismo. No puedes atribuir un cambio a una edición específica, y no puedes dividir un conjunto de cambios para encontrar cuál cayó la tasa de aprobación (la fracción de tus casos que salen correctos), porque nunca mediste el antes. "Se ve mejor" sobrevive porque nada lo contradice.

La iteración basada en vibras también se ajusta demasiado. Sigues reescribiendo los mismos puñados de ejemplos, ajustas hasta que se vean bien, y silenciosamente entrenas tu prompt a ese pequeño conjunto privado mientras el tráfico real se va a otro lado. La revisión manual no puede ver ese cambio de distribución, porque las nuevas entradas son las que no estás escribiendo. Un conjunto de evaluación versionado con una puntuación rastreada es la única forma de decir que un cambio ayudó en lugar de sentirse mejor, y es la diferencia entre iterar y adivinar.

JunoPor qué inspeccionar a simple vista falla He desplegado en vibras y luego vi cómo el único camino que nunca verifiqué puntualmente iluminó los registros de errores, ese es el sesgo de selección haciendo su trabajo. Sin línea base significa sin atribución y sin bisección: no puedes probar qué edit movió el número si nunca tuviste un número. Mantén un conjunto versionado y una puntuación rastreada, o te estás ajustando demasiado a los cinco ejemplos que sigues reescribiendo mientras el tráfico real se va a un lugar que no puedes ver.

Construye un conjunto de evaluación

Un conjunto de evaluación es una lista de casos de prueba. Cada caso tiene una entrada y lo que se parece a una buena salida para ella. Empieza pequeño. Diez a veinte casos que cubran tus situaciones comunes más algunos casos límite complicados son mucho más útiles que ninguno, y puedes crecer el conjunto mientras encuentras nuevas fallas en la realidad.

eval_set = [
    {"input": "La comida estaba fría y llegó tarde.", "expected": "NEGATIVA"},
    {"input": "¡La mejor comida de mi vida!", "expected": "POSITIVA"},
    {"input": "Estuvo bien, nada especial.", "expected": "NEUTRA"},
    # ...agrega casos reales y casos límite mientras los descubres
]

Cuando un usuario reporta una respuesta mala, agrégala al conjunto con la salida que debería haber dado. Tu conjunto de evaluación luego se convierte en una memoria creciente de cada error que nunca quieres cometer de nuevo, de la misma manera que un bug que arreglas se convierte en una prueba que mantienes.

JunoConstruye un conjunto de evaluación Un conjunto de evaluación es una lista de casos de prueba: una entrada, y lo que se parece a una buena respuesta. Comienza con diez a veinte que cubran tus situaciones cotidianas y algunos complicados. Cada vez que un usuario encuentra una respuesta mala, agrégala con la respuesta que debería haber dado, y tu conjunto silenciosamente recuerda cada error que nunca quieres repetir.

Un conjunto de evaluación es tu colección de casos de prueba, cada uno una entrada emparejada con la salida que aceptarías como buena. El número que importa no es el tamaño, es la cobertura. Un conjunto de veinte casos bien elegidos supera a cincuenta desechables cada vez.

Apunta a cubrir tres cosas: el camino común que tus usuarios realmente golpean, los límites de decisión donde dos etiquetas se sientan cerca una de la otra (los casos ambiguos justo en la línea), y los modos de falla conocidos que ya has visto fallar. Las entradas seleccionadas amistosamente hacen que tus puntuaciones se vean bien y no te dicen nada, así que mantén el conjunto representativo del tráfico real.

Cada bug que un usuario reporta se convierte en un caso permanente en el conjunto. Eso lo convierte en un conjunto de regresión: un bug arreglado se mantiene arreglado porque el caso que lo expuso ahora se ejecuta cada vez. Cuando tus salidas esperadas son estructuradas en lugar de texto libre, como una etiqueta o un campo JSON, puedes calificar con comparación de coincidencia exacta, que es limpia e inequívoca, ve salida estructurada.

Mantén una porción retenida separada sobre la que nunca ajustes. Si ajustas el prompt hasta que pases los casos exactos que estás mirando, te estás calificando a ti mismo en las respuestas que ya estudiaste, y la puntuación deja de significar algo.

JunoConstruye un conjunto de evaluación La cobertura supera al tamaño crudo: golpea el camino común, los límites ambiguos entre etiquetas, y los fallos que ya has visto. Convierte cada bug reportado en un caso permanente para que el conjunto funcione como un conjunto de regresión. Mantén una porción retenida sobre la que nunca ajustes, o te estás calificando a ti mismo en las respuestas que estudiaste.

Trata el conjunto de evaluación como un activo que versiones justo al lado del prompt, porque los dos se mueven juntos y un cambio de prompt puede silenciosamente cambiar lo que cuenta como una buena respuesta. La calidad de etiqueta del conjunto es el techo en tu métrica: un valor "esperado" incorrecto tapa tu puntuación y silenciosamente te enseña la lección equivocada, así que curar etiquetas cuidadosamente importa tanto como recopilar casos.

Protégete contra fugas de prueba. Si ajustas hasta que pasas el conjunto exacto que reportas, el número es teatro. Retén una porción que no mires mientras iteras, y rótala con el tiempo para que no lentamente filtre en tu bucle de ajuste de todas formas.

Observa el balance de clases. Un conjunto que es noventa por ciento positivos claros reportará un número halagador mientras oculta cada fallo en el diez por ciento que realmente importa, así que muestrea para que los casos difíciles y raros lleven peso real. Extrae casos de registros de producción en lugar de imaginación, ya que el tráfico real expone fraseologías que nunca inventarías en tu escritorio.

Acepta que el conjunto se pudre. A medida que el producto se desplaza, los casos antiguos dejan de reflejar lo que los usuarios envían y nuevos modos de falla aparecen que el conjunto nunca ha visto. Curarlo es trabajo continuo, no una construcción de una sola vez.

JunoConstruye un conjunto de evaluación El conjunto es un activo que versiones al lado del prompt, y su calidad de etiqueta es el techo duro en tu métrica, un valor esperado malo tapa toda la puntuación. Retén una porción y rótala, o tu número reportado es teatro. Observa el balance de clases, muestrea casos reales de registros, y asume que el conjunto se pudre a medida que el producto se mueve, así que curarlo nunca realmente termina.

Cómo calificar

Diferentes tareas necesitan diferentes calificaciones, así que el primer paso es emparejar la verificación con el tipo de respuesta que esperas.

• Coincidencia exacta funciona cuando hay una respuesta correcta: una etiqueta de clasificación, un campo extraído, un sí o no. Comparas la salida con el valor esperado directamente.
• Calificación basada en criterios funciona cuando no hay una respuesta única correcta, como un resumen o una respuesta. Verificas si la salida cumple con las condiciones: ¿El resumen menciona el hecho clave? ¿Está bajo 50 palabras? ¿Es el tono educado?
• LLM como juez usa una segunda llamada de modelo para calificar la salida contra tus criterios. Escala a preguntas de calidad borrosa que una verificación simple no puede capturar, pero el juez en sí es un modelo, así que puede estar equivocado, y lo verificas contra el juicio humano de vez en cuando.

# calificación de coincidencia exacta sobre el conjunto de evaluación
def run_evals(eval_set, classify):
    passed = 0
    for test in eval_set:
        output = classify(test["input"])
        if output == test["expected"]:
            passed += 1
        else:
            print(f'FAIL: "{test["input"]}" -> got {output}, wanted {test["expected"]}')
    print(f"{passed}/{len(eval_set)} passed")

Coincidencia exacta es el lugar más amigable para comenzar, y se ajusta al trabajo de clasificación y extracción de capítulos anteriores perfectamente. La idea de LLM como juez funciona porque detectar si una respuesta cumple un estándar a menudo es una predicción más fácil de lo que fue producir la respuesta, de la misma manera que revisar un ensayo es más fácil que escribir uno. Pero el juez es otro predictor con los mismos defectos, así que trata sus puntuaciones como una estimación útil, dale una rúbrica clara, y verifica sus calificaciones contra las tuyas en una muestra de vez en cuando.

JunoCómo calificar Elige la verificación que se ajuste a la respuesta: coincidencia exacta cuando hay una respuesta correcta, criterios cuando hay varias buenas, y un segundo modelo como juez para calidad borrosa. Coincidencia exacta es el inicio más gentil, y se alinea perfectamente con la clasificación y extracción que ya practicaste. Pero el juez es un modelo también, así que mira sus calificaciones tú mismo de vez en cuando.

Empareja el calificador con la tarea, luego ve por el más barato que aún capture lo que te importa. Un calificador es el código o la llamada de modelo que decide si una salida pasó, y la elección equivocada o pierde fallas reales o marca respuestas que estaban bien.

Coincidencia exacta es para etiquetas y campos extraídos: comparas la salida con el valor esperado y el resultado es determinista, así que puedes confiar en él. Se empareja naturalmente con salida estructurada, ya que un modelo que retorna un esquema fijo te da algo limpio para comparar en lugar de prosa libre.

Los criterios programáticos cubren el terreno medio de forma barata: verificar la longitud, confirmar que una cadena requerida esté presente, validar que el JSON se analice, ejecutar una regex. Estos se ejecutan en milisegundos sin una llamada de modelo, así que úsalos para cualquier cosa semi-estructurada antes de que gastes dinero en un juez.

LLM como juez es para calidad de extremo abierto, donde un resumen o una respuesta tiene muchas formas buenas y sin objetivo exacto. Necesita una rúbrica escrita para que el juez aplique un estándar consistente, más una verificación de calibración donde comparas sus calificaciones a tus propias etiquetas en una muestra. Recuerda que un calificador es código que también tienes que confiar: un calificador inestable te entrega una puntuación confiadamente equivocada.

JunoCómo calificar Usa el calificador más barato que aún atrape lo que importa: coincidencia exacta para etiquetas y campos, verificaciones programáticas para longitud o JSON válido o una cadena requerida, y un juez de modelo solo para calidad de extremo abierto. Coincidencia exacta se empareja bien con salida estructurada porque un esquema fijo te da algo limpio para comparar. Sea lo que sea que elijas, el calificador es código que también confías, así que uno inestable te entrega una puntuación confiadamente equivocada.

LLM como juez es el calificador que se rompe de las formas más interesantes, así que planifica sus sesgos antes de apoyarte en él. Un juez favorece respuestas más largas, elige la primera opción al comparar un par, y recompensa el texto que se lee como su propio estilo, y sus puntuaciones absolutas están mal calibradas, así que un 8 de una ejecución no es un 8 de la siguiente.

Trata el juez como un modelo que estás evaluando por derecho propio. Fija y versiona el modelo juez, porque se desplaza cuando se actualiza y tus puntuaciones se mueven con él. Dale una rúbrica apretada con algunos ejemplos de anclaje, luego mide el acuerdo juez-versus-humano en una muestra etiquetada para que sepas cuánto confiar en él.

Donde puedas, pide una comparación por pares ("¿es A o B mejor?") en lugar de una puntuación absoluta de 1 a 10; los juicios relativos generalmente son más confiables que pedirle a un modelo que golpee un número calibrado. Fija el juez, rúbrica apretado, verifica contra humanos.

Ten cuidado con la circularidad y la factura. La misma familia de modelos calificando su propia salida comparte sus puntos ciegos, así que una falla que el generador cometió es una falla que el juez probablemente perderá, y calificar cada caso a escala es una segunda factura de modelo además de la primera.

JunoCómo calificar El juez tiene opiniones que no pediste: le gustan las respuestas largas, la primera opción, y prosa que suena como ella misma, y sus puntuaciones absolutas vagan entre ejecuciones. Fija y versiona, entrégale una rúbrica apretada con anclajes, y rastrear con qué frecuencia está de acuerdo con un humano, porque ahora estás calificando el calificador. Apóyate en comparaciones por pares sobre un solitario 1-a-10, y mantente consciente de que un modelo calificando su propia familia comparte sus puntos ciegos y duplica la factura.

Ejecútalas en cada cambio

Un conjunto de evaluación es solo útil si realmente lo ejecutas. Trata tus prompts como código: antes de desplegar un cambio a un prompt, un modelo, o tu recuperación, ejecuta las evaluaciones y compara la puntuación con lo que era antes. Si el número bajó, causaste una regresión, incluso si tu única prueba manual sucedió a verse bien.

Esto es lo que convierte la ingeniería de prompts de adivinanza en algo que puedes iterar con confianza. Cambia algo, mídelo, mantén lo que puntúa más alto, y desecha lo que puntúa más bajo. Es el mismo bucle que hace que el software ordinario sea confiable, ahora aplicado a las partes borrosas de una característica de IA.

Si la puntuación bajó, causaste una regresión. Una única prueba manual afortunada no anula el conjunto, así que deja que el número sea el desempatador cada vez.

JunoEjecútalas en cada cambio Un conjunto de evaluación solo ayuda si lo ejecutas, así que hazlo un hábito: antes de cualquier cambio se despliegue, ejecuta las evaluaciones y verifica la puntuación contra la última vez. Si bajó, esa es una regresión para arreglar, no un fluke para desechar. Cambia, mide, mantén lo que puntúa más alto, y estás iterando en lugar de adivinando.

Conecta la ejecución de evaluación en tu bucle de desarrollo para que cierre cambios de la manera que un conjunto de pruebas cierra una fusión. Un cambio a un prompt, un modelo, o tu recuperación (el paso que extrae documentos de apoyo) no se despliego hasta que hayas ejecutado el conjunto y comparado la puntuación con la ejecución anterior. El número, no tu intuición después de una prueba manual, decide si el cambio es una mejora.

Cambia una variable a la vez. Si editas el prompt e intercambias el modelo en el mismo paso, un movimiento en la puntuación tiene dos posibles causas y no puedes atribuirlo a ninguno. Aísla el cambio, ejecuta el conjunto, lee el resultado, luego muévete al siguiente.

Lee la diferencia por caso, no solo la puntuación agregada (el número único promediado entre cada caso). Un total estable puede ocultar un caso que se arregló y uno que se rompió al mismo tiempo, que se neta a cero mientras tu comportamiento silenciosamente se desplaza. Mirar qué casos se voltearon te dice qué tu cambio realmente hizo.

Rastrea la puntuación con el tiempo para que la mejora sea visible y las regresiones destaquen. Un historial registrado convierte "esto se ve mejor" en una línea en la que puedes apuntar, y hace que una caída repentina sea rápida de rastrear hasta el cambio que la causó.

JunoEjecútalas en cada cambio Cierra cambios en la puntuación de la manera que cierras una fusión en pruebas: sin ejecución, sin despliegue. Cambia una variable por paso para que un movimiento de puntuación tenga una causa, y lee la diferencia por caso, ya que un total plano puede ocultar un caso arreglado y uno roto. Registra la puntuación con el tiempo para que las ganancias sean visibles y las regresiones destaquen.

Hazlo una puerta real, no un ritual. Pon un umbral de puntuación en CI para que un cambio que cae por debajo de la barra falle la construcción en lugar de depender de que alguien recuerde mirar. Y re-ejecuta el conjunto en cada cambio de versión de modelo, porque el mismo prompt se desembarca diferentemente en nuevos pesos; fija la versión de modelo que probaste contra y re-evalúa antes de que adoptes uno nuevo.

Sostén dos trampas en mente. Primero, el conjunto de evaluación (tu colección fija de casos de prueba con resultados esperados) es un proxy, no la verdad fundamental, así que afinar duro contra él se ajusta demasiado: subes la puntuación mientras el comportamiento real se estanca. Mantén expandiendo y rotando el conjunto para que estés midiendo la tarea, no memorizando la prueba.

Segundo, las evaluaciones sin conexión no son la imagen completa. Emparéjalas con señales en línea, tráfico de producción muestreado, retroalimentación del usuario, tasas de quejas, y alimenta fallas reales de nuevo en el conjunto como nuevos casos.

Porque la salida es no determinística, la misma entrada puede puntuar diferente entre ejecuciones. Ejecuta suficientes muestras por caso y juzga contra una tolerancia en lugar de perseguir ruido de ejecución única; una oscilación de un punto entre ejecuciones es la medición respirando, no una regresión. Establece la barra en un nivel que sobreviva esa varianza, o pasarás tu semana investigando fantasmas. He hecho exactamente eso, más de una vez.

JunoEjecútalas en cada cambio Pon un umbral en CI para que un cambio malo falle la construcción, y re-evalúa en cada cambio de versión de modelo porque nuevos pesos leen el mismo prompt diferentemente. El conjunto es un proxy, así que mantén rotándolo y emparéjalo con señales en línea, o te ajustarás demasiado a tu propia prueba. Y ya que la salida es no determinística, juzga contra una tolerancia en lugar de investigar fantasmas, que sí, he hecho.

En la práctica

La función run_evals de la sección anterior es un arnés de evaluación completo, si pequeño. Lo apuntas a tu clasificador y tu conjunto de evaluación, y te dice cuántos casos pasan y te muestra exactamente cuáles fallan:

run_evals(eval_set, classify_review)
# FAIL: "Estuvo bien, nada especial." -> got POSITIVA, wanted NEUTRA
# 2/3 passed

Esa una línea fallida vale más que una docena de pruebas manuales exitosas, porque apunta a una debilidad real que ahora puedes arreglar y re-medir. El capítulo final, Seguridad y límites, cubre los riesgos para diseñar contra antes de que pongas algo de esto frente a usuarios reales.

JunoEn la práctica Un pequeño arnés como run_evals ya se paga por sí solo: te da una puntuación y los casos exactos que se rompieron. Arregla uno, ejecútalo de nuevo, mira cómo se mueve el número. A continuación, Seguridad y límites cubre qué guardar contra antes de que lleguen usuarios reales.

Un pequeño arnés de evaluación, el bit de código que ejecuta cada caso en tu conjunto de evaluación y califica la salida contra lo que esperabas, es el bucle que convierte "parece bien" en un número que puedes mover. Ejecutas el conjunto, obtienes una puntuación más una lista de fallas, arreglas la falla real más barata, lo ejecutas de nuevo.

Cada caso fallido es una unidad de trabajo con una definición clara de hecho: el caso pasa. Eso es un objetivo más agudo que "mejorar el prompt", porque puedes ver exactamente cuándo lo golpeas y exactamente cuándo retrocedes.

Antes de que algo de esto se encuentre con usuarios reales, el próximo capítulo, Seguridad y límites, cubre los riesgos que diseñas contra desde el principio.

JunoEn la práctica El arnés convierte vibras en un número que puedes mover: ejecuta el conjunto, lee la puntuación y las fallas, arregla la más barata real, re-ejecuta. Cada falla es una tarea con una definición clara de hecho, que es un objetivo más agudo que "hacerlo mejor". Luego Seguridad y límites antes de que usuarios reales lo vean.

En producción ese pequeño arnés deja de ser un script que ejecutas a mano y se convierte en parte del sistema. Crece en una puerta de CI, una verificación que bloquea un lanzamiento cuando la puntuación cae por debajo de una línea que estableces, más un panel que miras entre lanzamientos para atrapar el movimiento lento que una ejecución única nunca muestra.

Las evaluaciones sin conexión, el conjunto fijo que calificas antes de desplegar, y el monitoreo en línea, las señales que recolectas del tráfico real después, se alimentan mutuamente: las fallas de producción se convierten en nuevos casos sin conexión, y el conjunto sin conexión te dice si tu arreglo se mantuvo. Los equipos que ganan aquí no son los que tienen el prompt más ingenioso. Son los que midieron mientras todos los demás inspeccionaban a simple vista.

Esa es la disciplina. El próximo capítulo, Seguridad y límites, cubre los riesgos para diseñar contra antes de que cualquiera de esto llegue a usuarios reales.

JunoEn la práctica Madura esto y el script se convierte en una puerta de CI más un panel, con evaluaciones sin conexión y monitoreo en línea alimentándose mutuamente. He desplegado en "se ve bien para mí" y pagué por ello después, así que tómalo de mí: los equipos que ganaron midieron mientras el resto inspeccionó a simple vista. Lee Seguridad y límites antes de que lleguen usuarios reales.