6.3 Construya un conjunto de evaluación

Este es el ejercicio calificado central del capítulo. La regla que enseña:

Antes de confiarle una tarea a un agente, construya el conjunto de evaluación que lo mide.

Usted ya cree en esta regla para los modelos — el capítulo 3 lo hizo evaluar cada clasificador contra un conjunto de prueba reservado con verdad de referencia, y la tabla de clasificación (leaderboard) de la clase lo calificó sobre datos que usted nunca vio. Un agente es un modelo con herramientas. Misma regla, misma maquinaria: defina la tarea con precisión, reúna casos con respuestas conocidas, califique automáticamente, estudie las fallas. La diferencia es que ahora usted genera la verdad de referencia, y esta es exactamente la razón por la que los datos sintéticos con motivación física han recorrido todo el curso: mlgeo_synth le da casos de evaluación ilimitados con verdad exacta y gratuita.

Trabajamos un ejemplo de principio a fin y después usted repite el procedimiento sobre una tarea del dominio de su propio proyecto.

La tarea objetivo del agente:

Dada una serie cruda de desplazamiento GNSS diario, reporte la velocidad secular en mm/año y señale cualquier desplazamiento cosísmico.

Una nota sobre el montaje: el «agente» de este cuaderno es una función de Python que hace las veces de uno real, con modos de falla realistas, de modo que el cuaderno corre sin conexión y en CI. La especificación, el conjunto de evaluación, el calificador y el bucle son exactamente lo que usted envolvería alrededor de un agente en vivo — pero un agente LLM en vivo, muestreado, añade tres requisitos que el sustituto determinista no tiene: validar su esquema de salida antes de calificar (paso 3), correr repeticiones por caso y reportar tasas de éxito («Calificar sin verdad computable», abajo), y llevar registro del costo y la latencia. Este cuaderno construye los dos primeros; el tercero es contabilidad.

🖥️ Diapositivas — Sesión 19 (vie 13 nov)

Paso 1: Escriba la especificación de la tarea¶

La mayoría de las «fallas de agente» son fallas de especificación. Una especificación no es un deseo («analiza estos datos GNSS»); es un contrato lo bastante preciso como para que aprobar o reprobar sea computable. La nuestra, versión 1:

Note qué queda fijado: las columnas de entrada (para que el agente no pueda espiar las columnas de verdad), el esquema de salida (para que la calificación sea mecánica) y las tolerancias numéricas (para que «aprobar» no sea un estado de ánimo). Note también en qué no pensamos todavía: longitud del registro, nivel de ruido, tamaño del desplazamiento. El conjunto de evaluación está a punto de castigarnos por eso, que es justamente el sentido de construirlo.

Paso 2: Genere el conjunto de evaluación¶

Doce casos que barren la dificultad: líneas base limpias, señal estacional fuerte, baja relación señal-ruido, desplazamientos de grandes a diminutos, registros cortos y una velocidad negativa para que se pongan a prueba las convenciones de signo. Cada caso es una llamada al generador más su verdad de referencia — que conocemos porque nosotros la fijamos.

Mire C08 antes de seguir: un desplazamiento de 4 mm bajo ruido de color de nivel milimétrico es invisible a la vista. Si el agente debe estar obligado a encontrarlo es una pregunta científica genuina — y escribir el conjunto de evaluación nos forzó a planteárnosla, antes de que corriera agente alguno. El diseño de cobertura en una oración: barra cada perilla que cambie la física del problema (tamaño de la señal, ruido, longitud del registro, señales que confunden), incluya casos donde la respuesta correcta sea «no hay nada ahí», e incluya al menos un caso cerca del límite de la detectabilidad física.

Paso 3: Escriba el calificador¶

Mecánico, basado en tolerancias, sin juicios en el momento de calificar — todo el juicio se fue a la especificación. Y una propiedad innegociable: el calificador debe sobrevivir a salidas malformadas. La falla más común de un agente LLM en vivo no es un número equivocado; es una salida que viola el esquema — una clave faltante, un número envuelto en prosa, una cadena donde va un flotante. Un calificador que lanza KeyError ante esa salida no puede registrar precisamente la falla que más necesita registrar. Por eso score_case primero valida el resultado contra el esquema de salida de la especificación y convierte cualquier violación en una falla calificada con un motivo, nunca en una excepción. (La rúbrica de calificación del final otorga puntos de solidez del calificador exactamente por este comportamiento — el ejemplo desarrollado muestra ahora para qué son esos puntos.)

Demuestre que la protección funciona antes de confiar en ella — un resultado deliberadamente malformado, del tipo que produce un agente en vivo cuando envuelve el número en prosa y olvida una clave:

Paso 4: Córralo contra el agente¶

Aquí está el agente simulado. Su estrategia es la ingenua que produce un analista apresurado (humano o artificial): un ajuste de línea recta para la velocidad, ignorando los términos estacionales y los desplazamientos, y detección de desplazamientos por barrido del mayor salto entre medias de 30 días. Sus modos de falla están plantados pero son realistas: velocidad sesgada cuando hay una señal no modelada, desplazamientos pequeños que se pierden, excursiones de ruido confundidas con desplazamientos.

Paso 5: Analice las fallas, apriete, vuelva a correr¶

Tres de doce. Sin el conjunto de evaluación, este agente se habría lanzado a producción: sus respuestas sobre cualquier serie individual parecen razonables. Lea las fallas por grupo — la tabla es el diagnóstico:

• C02, C04, C06, C10 — velocidad equivocada siempre que hay un desplazamiento. El ajuste de línea recta absorbe en la pendiente el escalón no modelado. En el registro de 2 años (C10) el sesgo llega a ~18 mm/año. Modo de falla correlacionado: las dos salidas no son independientes, así que un término del modelo que falta corrompe un número reportado.
• C07, C08 — desplazamientos pequeños que se pierden. El umbral fijo de 12 mm no puede ver escalones de 8 ni de 4 mm. La especificación nunca dijo cuál debía ser el desplazamiento mínimo detectable; el conjunto de evaluación simplemente hizo visible ese hueco.
• C05 — falsa alarma. El ruido flicker (de parpadeo) deambula lo suficiente como para que algunas medias de 30 días difieran en más de 12 mm sin sismo alguno. Los casos «sin desplazamiento» se ganan su lugar en un conjunto de evaluación: un detector solo tiene sentido si puede quedarse callado.
• C09, C11 — velocidad equivocada en registros cortos incluso sin desplazamiento. Dos años de señal estacional más ruido de color derrotan a un ajuste de línea recta.

El análisis de fallas dicta la corrección, y es tanto una corrección de la especificación como del agente. La especificación v2 añade una cláusula de método obligatoria — «estime la velocidad por mínimos cuadrados con términos anual y semianual y, si se señala un desplazamiento, una función escalón en el día detectado» — el modelo físico del capítulo 2. El agente mejorado lo implementa:

Diez de doce, y toda falla de física desapareció: se encuentran desplazamientos de hasta 4 mm (decidir con la amplitud del escalón ajustado supera al umbral sobre saltos crudos), la falsa alarma de baja relación señal-ruido desaparece, las velocidades son correctas dondequiera que el modelo sea adecuado.

Los dos sobrevivientes — C09 y C10 — son ambos registros de 2 años, y sus errores de velocidad (~1.7–2 mm/año) no son culpa del agente. La incertidumbre de la velocidad debida al ruido de color del GNSS escala aproximadamente como 1/T: dos años de ruido flicker no pueden entregar ±1.5 mm/año, sin importar quién los analice. Nuestra especificación exigía algo que los datos no pueden dar. Esto es lo segundo que atrapan los conjuntos de evaluación: las especificaciones irrazonables.

¿Hasta dónde debe relajarse la tolerancia, entonces? No hasta lo que haga desaparecer las fallas — eso es calificar sobre una curva que usted dibujó después de ver el examen. La tolerancia es una propiedad del estimador bajo la física, y el generador es nuestro, así que podemos medirla: corra el estimador sobre muchas realizaciones nuevas sin desplazamiento para cada longitud de registro y mire la distribución de su error.

La distribución responde la pregunta. Registros de diez años: error en el percentil 95 cercano a 0.3 mm/año, así que los ±1.5 mm/año originales son holgados. Registros de dos años: el percentil 95 se sitúa cerca de 1.9 mm/año — ±1.5 nunca fue alcanzable, y una tolerancia de ±3 mm/año (unas 1.5 veces el percentil 95 medido, con margen porque 50 repeticiones fijan la cola solo de forma laxa y muestreamos una única velocidad verdadera) es lo que la física sostiene. La especificación v3 escribe esa medición dentro del contrato. La regla general: derive las tolerancias de realizaciones del estimador, no de una primera conjetura — con un generador sintético, la derivación cuesta cinco líneas.

Doce de doce — y, más importante, una traza de auditoría: sabemos cuáles capacidades fueron probadas, cuáles tolerancias sostiene la física y qué no podía hacer el agente hasta que cambió su método. Esa tabla es lo que debería significar «le confío a este agente la caracterización GNSS».

Este es el bucle guiado por la evaluación:

1. especificación → 2. conjunto de evaluación con verdad de referencia → 3. calificador → 4. corrida → 5. análisis de fallas → apretar la especificación o corregir el agente → de vuelta a 4.

Es el mismo bucle que el desarrollo de modelos del capítulo 3, con el conjunto de evaluación en el papel del conjunto de prueba oculto. Dos advertencias se transfieren con él. Primera, un conjunto de evaluación contra el que usted itera es un conjunto de validación; si lo que está en juego es alto, reserve casos nuevos (¡semillas nuevas!) para una comprobación final, exactamente como la tabla de clasificación reservaba sus datos de prueba. Segunda, la evaluación solo cubre lo que usted puso en ella — nuestro agente está validado para series de una componente con a lo sumo un desplazamiento, y afirmar más sería la extralimitación que el capítulo 7.2 le enseña a consignar con honestidad.

Calificar sin verdad computable¶

Todo lo anterior calificaba contra una verdad numérica exacta: abs(est - truth) <= tol resuelve cada caso. Muchas de las tareas que usted delegará en realidad no tienen tal número. El ejemplo más claro es aquel hacia el que se dirige este curso: el agente de revisión previa al envío que usted construirá a partir de su propia rúbrica de calidad, y cuyo trabajo es criticar un artículo antes de que usted lo envíe. Una revisión no tiene velocity_mm_yr. Su salida es un juicio, y «¿es buena esta revisión?» es a su vez un juicio.

La maquinaria de evaluación sobrevive, con tres sustituciones.

1. El calificador se vuelve una rúbrica. Descomponga «¿es buena esta revisión?» en comprobaciones binarias que un lector pueda resolver sin preguntarle a usted: nombra la falla de fuga de datos, toda crítica cita una línea, figura o número específicos, propone una corrección concreta para cada falla, no elogia un defecto. Usted construyó exactamente este tipo de rúbrica en la parte (c) de 6.2. Y el truco de la verdad plantada de este cuaderno sigue aplicando: déle al agente de revisión artículos con defectos conocidos y plantados — un fallo de fuga de datos, una cita fabricada, un umbral ajustado sobre el conjunto de prueba — y «encontró el defecto plantado» vuelve a ser una comprobación computable. La verdad de referencia para una tarea subjetiva es algo que usted diseña, no algo que encuentra.

2. Debe medir si la rúbrica se puede aplicar de forma consistente. Una rúbrica solo funciona como calificador si dos evaluadores que la aplican a la misma salida llegan a los mismos veredictos. Eso es medible: haga que dos evaluadores califiquen la misma salida (el intercambio con un compañero de la parte (c) de 6.2 produce exactamente estos datos) y calcule su acuerdo. El acuerdo porcentual crudo no basta — si la mayoría de las comprobaciones se aprueba, dos evaluadores coinciden a menudo por azar —, así que reporte el kappa de Cohen, el acuerdo corregido por azar. Cabe en cinco líneas:

Reporte ambos números. La primera pareja coincide en el 83 % de las comprobaciones y su kappa es 0.63 — consistencia real pero imperfecta. La pareja indulgente coincide en el 92 % de las comprobaciones y su kappa es 0.00: cada pizca de ese acuerdo es lo que producen por azar dos que dicen que sí a todo. Un kappa bajo es un defecto de la rúbrica antes que un defecto de los evaluadores: cada desacuerdo marca un criterio cuya redacción dos lectores resolvieron de manera distinta. Reescriba ese criterio, recalifique, vuelva a medir. Una rúbrica que dos humanos no pueden aplicar de forma consistente no está lista para entregársela a un LLM juez.

Cuando el segundo evaluador sea un modelo (como en la parte (c) de 6.2, y como será la calificación de su propio agente de revisión), añada los controles para los sesgos del juez que midió allí, aplicados en el momento de calificar:

• Orden. Califique el par como (A, B) y otra vez como (B, A); un veredicto que se voltea con la posición es sesgo de posición, no señal.
• Verbosidad. Califique cada comprobación de la rúbrica de forma independiente en vez de pedir una impresión global — la extensión infla las calificaciones holísticas mucho más de lo que infla las respuestas por comprobación.
• Cegamiento. No le diga al juez qué salida vino de su propio agente, y quite todo preámbulo autoidentificatorio antes de calificar.

3. Los veredictos únicos se vuelven tasas de éxito. agent_v2 devuelve el mismo diccionario en cada corrida; un LLM muestreado no. Corra un agente de revisión en vivo cinco veces sobre el mismo artículo y atrapará un defecto plantado en algunas corridas y lo perderá en otras. Así que la unidad de medida por caso cambia de aprobar/reprobar a una tasa de éxito con incertidumbre de muestreo. Abajo están los resultados grabados de un agente de revisión corrido N=5 veces por caso sobre seis análisis breves con defectos plantados — las transcripciones se grabaron una vez y se calificaron con rúbrica, así que esta celda corre sin conexión y en CI como todo lo demás:

Lea P04: una evaluación de una sola corrida lo habría declarado aprobado o reprobado según el azar de una moneda — corra una sola vez y despliegue, y su conclusión sobre el agente depende del sorteo. Y los errores estándar dicen qué significa una diferencia: con N=5, una tasa cercana a 0.5 acarrea ±0.22, así que una versión del agente que saca 3/5 donde otra sacó 2/5 en un caso no es evidencia de mejora. Tres consecuencias para la evaluación de su trabajo culminante: reporte tasas, no veredictos; fije N en la especificación antes de correr; y exija un margen mayor que el error estándar antes de creer que un cambio ayudó (o aumente N hasta que las barras de error se separen).

En conjunto — comprobaciones de rúbrica sobre defectos plantados, kappa entre dos evaluadores sobre la rúbrica misma, controles de orden, verbosidad y cegamiento, tasas de éxito sobre N corridas — esta es la maquinaria completa de calificación para el agente de revisión que usted construirá en el arco de lectura. Califica artículos en vez de velocidades, y eso no lo exime en nada de ser evaluado.

Opcional: la misma evaluación contra un modelo en vivo¶

Todo lo calificado en este capítulo corre sin conexión: el agente simulado y las transcripciones grabadas son la base calificada, y CI las ejecuta sin red. Si tiene el hardware y las ganas, el mismo arnés corre sin cambios contra un modelo real de pesos abiertos — OLMo 2, el modelo completamente abierto de Ai2 (pesos, datos de entrenamiento y código, todo liberado) — servido localmente por Ollama:

ollama pull olmo2               # 7B default: ~4.5 GB disk; ~8 GB RAM to run; CPU works, slowly
export MLGEO_LIVE_EVAL=1        # opt in, then launch Jupyter from the same shell

Ollama expone un punto de acceso compatible con OpenAI en http://localhost:11434/v1, así que el «agente» de abajo es una sola llamada HTTP. Le entregamos al modelo medias de 30 días de la serie (unos 120 números para un registro de 10 años) — que es deliberadamente el montaje de la mala calculadora de 6.1: un motor de texto al que se le da un problema de regresión. Espere violaciones del esquema y velocidades equivocadas. Ese es el punto pedagógico: la protección del esquema registra las salidas malformadas en vez de estrellarse, las tolerancias juzgan los números, y con una temperatura de muestreo distinta de cero usted necesitaría la maquinaria de repeticiones de la sección anterior. Un agente en vivo capaz, en cambio, escribiría y ejecutaría código sobre la serie cruda; montar eso es un ejercicio de escala de proyecto, no una celda de cuaderno.

La celda corre la evaluación en vivo solo cuando usted ha optado por ella con MLGEO_LIVE_EVAL=1 y un servidor local de Ollama tiene descargado un modelo olmo2; si no, imprime una nota y sigue adelante. No puede hacer fallar una compilación: sin la opción activada no hay llamada de red, e incluso una corrida activada que dé error degrada a un mensaje. Nada de esto se califica, y ninguna tarea lo exige.

Tarea: un conjunto de evaluación para el dominio de su proyecto¶

Repita los pasos 1 a 5 para una tarea de agente del dominio de su proyecto. Usted elige la tarea; debe ser una que de verdad delegaría. Ejemplos para calibrar el alcance: «marque la llegada de la onda P dentro de ±0.1 s» (seismogram_dataset), «clasifique la litología a partir de una fila de geoquímica y absténgase cuando haya incertidumbre» (geochem_table), «estime el valor b a partir de un catálogo de magnitudes» (gutenberg_richter_magnitudes), «señale los eventos raros en esta serie de sensor» (inject_rare_events).

Entregables, en un solo cuaderno:

1. Especificación de la tarea — entradas, esquema de salida, tolerancias y cualquier restricción de método obligatoria. Escrita primero, versionada si cambió. Tolerancias derivadas de realizaciones cuando el generador sea suyo, no adivinadas.
2. Conjunto de evaluación — al menos 10 casos de un generador de mlgeo_synth (o de su propio generador con verdad de referencia documentada), barriendo la dificultad a lo largo de al menos tres ejes, incluidos casos negativos o de «no hay nada ahí» y al menos un caso cerca del límite de detectabilidad.
3. Calificador — mecánico, corre con una sola llamada a función y devuelve una falla calificada (nunca una excepción) ante una salida del agente faltante o malformada, como en el paso 3. Basado en tolerancias donde la verdad sea computable; si la salida de su tarea es un juicio, use en su lugar comprobaciones de rúbrica sobre defectos plantados y reporte el acuerdo entre dos evaluadores (porcentaje + kappa) sobre al menos un subconjunto («Calificar sin verdad computable»).
4. Corrida + análisis de fallas — corra su agente (real o simulado), agrupe las fallas y diagnostique cada grupo: ¿limitación del agente, defecto de la especificación o imposibilidad física?
5. Redacción — media página: qué cubre el conjunto de evaluación, qué deliberadamente no cubre y qué le confiaría ahora al agente hacer sin supervisión.

Rúbrica de calificación (100 puntos):

Cada fila de la rúbrica está demostrada en el ejemplo desarrollado de arriba — el manejo de salidas malformadas que pide la solidez del calificador es el validate_result del paso 3, y la justificación de tolerancias que pide la claridad de la especificación es la medición sobre 50 realizaciones previa a la especificación v3.

Una advertencia nacida de la experiencia: la forma más común de perder puntos es un conjunto de evaluación que su agente aprueba 10/10 al primer intento. Eso no es un buen agente; es un examen fácil.