Evaluaciones y supervisión escalable

El problema de la supervisión

Toda técnica de este curso asume que alguien puede juzgar si una respuesta es buena: un etiquetador en RLHF, un dataset de preferencias en DPO, un modelo guiado por principios en CAI. Esa suposición se debilita a medida que los modelos resuelven tareas más largas y especializadas:

• ¿Cómo evalúa un etiquetador una demostración matemática de diez páginas?
• ¿Cómo revisa un humano cada acción de un agente que ejecuta cientos de pasos?
• ¿Cómo detectamos un error sutil en un dominio que el evaluador no domina?

La supervisión escalable (scalable oversight) es el área que busca métodos para que la supervisión siga siendo confiable cuando la tarea supera la capacidad del supervisor de verificarla directamente. Esta lección cubre las herramientas actuales de medición (evals, red teaming) y las propuestas de supervisión (debate, weak-to-strong), con sus límites.

Evaluaciones (evals)

Una eval es un procedimiento sistemático para medir una propiedad del modelo. Conviene distinguir dos familias:

Evals de capacidades. ¿Qué puede hacer el modelo? Benchmarks de razonamiento, código, conocimiento de dominio, tareas agénticas de varios pasos. En seguridad interesan especialmente las capacidades que podrían habilitar daño serio (por ejemplo, asistencia en dominios de riesgo o capacidad de operar de forma autónoma), porque informan qué salvaguardas necesita un despliegue.

Evals de alineación o comportamiento. ¿Qué tiende a hacer el modelo? Honestidad, sycophancy, seguimiento de instrucciones, rechazo apropiado (sin sobre-rechazar), consistencia de valores, comportamiento bajo presión o en escenarios ambiguos.

Problemas metodológicos que aparecen una y otra vez:

• Contaminación. Si los ítems del benchmark aparecieron en el preentrenamiento, el puntaje mide memoria, no capacidad.
• Saturación. Los benchmarks se "llenan" rápido; uno que discriminaba entre modelos hace dos años hoy puede no discriminar nada.
• Sensibilidad al formato. Pequeños cambios de prompt pueden mover mucho los resultados. Un buen reporte incluye varianza, no solo el promedio.
• Elicitación. Una eval de capacidades mide un piso, no un techo: con mejor prompting, herramientas o fine-tuning, el modelo puede rendir más. Para decisiones de seguridad, subestimar capacidades es el error más costoso.

Red teaming

El red teaming consiste en buscar activamente fallas: inputs que hacen que el modelo se comporte mal. Tiene varias modalidades:

• Humano. Expertos (en seguridad, en dominios específicos) o colaboradores diversos intentan provocar comportamientos indeseados. Es caro pero encuentra fallas creativas.
• Automatizado. Un modelo atacante genera prompts para provocar fallas en el modelo objetivo, y un clasificador evalúa si lo logró. Perez et al. (2022) mostraron que este enfoque escala y descubre categorías de fallas difíciles de anticipar.
• Adversarial optimizado. Ataques basados en búsqueda o gradientes que encuentran sufijos o perturbaciones que vulneran las salvaguardas (jailbreaks). Zou et al. (2023) mostraron sufijos adversariales que se transferían entre modelos.

Podemos formalizar el red teaming automatizado como un problema de optimización del atacante:

$$\max_{\pi_{\text{red}}} \; \mathbb{E}_{p \sim \pi_{\text{red}}}\Big[ C\big(p, \pi_{\text{target}}(p)\big) \Big] + \alpha \, \mathcal{H}(\pi_{\text{red}})$$

donde $C$ es un clasificador que detecta salidas problemáticas y el término de entropía $\mathcal{H}$ premia la diversidad de ataques. Sin ese término, el atacante colapsa en un único exploit.

El red teaming tiene una asimetría importante: encontrar una falla prueba que existe; no encontrar fallas no prueba que no existan.

Debate

¿Cómo puede un juez débil supervisar a agentes fuertes? Irving, Christiano y Amodei (2018) propusieron AI safety via debate: dos copias de un modelo debaten sobre una pregunta frente a un juez (humano o modelo más débil). Cada una intenta convencer al juez de su respuesta y puede señalar errores en los argumentos de la otra.

La intuición es que refutar es más fácil que construir: el juez no necesita resolver la pregunta, solo evaluar el punto más disputado que los debatientes le presentan. El paper argumenta, por analogía con la teoría de complejidad, que el debate con juez polinomial puede, en el límite idealizado, decidir problemas mucho más difíciles que los que el juez resolvería solo.

Hay evidencia empírica inicial y mixta: algunos trabajos (por ejemplo, Khan et al., 2024) reportan que, en tareas de comprensión de textos donde el juez no tiene acceso al texto completo, el debate entre modelos más persuasivos ayuda a jueces no expertos a acertar más que sin debate. Pero sigue siendo abierto si estas ventajas se sostienen en tareas más complejas y cuando los debatientes pueden ser deshonestos de formas sutiles.

Generalización weak-to-strong

Burns et al. (2023) plantearon una analogía empírica del problema futuro: hoy los humanos supervisan modelos más débiles que ellos en muchas tareas; en el futuro podríamos supervisar modelos más fuertes. ¿Podemos estudiar eso ahora?

Su configuración: usar un modelo débil (pequeño) como supervisor para fine-tunear un modelo fuerte (grande). Las etiquetas del débil tienen errores. La pregunta es si el fuerte reproduce los errores del débil o generaliza más allá de ellos.

Definieron la métrica PGR (performance gap recovered, brecha de rendimiento recuperada):

$$\text{PGR} = \frac{\text{rend}(\text{fuerte entrenado con débil}) - \text{rend}(\text{débil})}{\text{rend}(\text{fuerte con etiquetas reales}) - \text{rend}(\text{débil})}$$

$\text{PGR} = 1$ significa que la supervisión débil fue tan buena como la real; $\text{PGR} = 0$, que el fuerte solo imitó al débil.

Hallazgos principales: el modelo fuerte generaliza más allá de su supervisor de forma consistente (PGR positivo), pero lejos de recuperar toda la brecha, especialmente en tareas como reward modeling. Técnicas simples (como una pérdida auxiliar de confianza que deja al modelo fuerte discrepar del débil) mejoran el PGR en varios escenarios. Los autores son explícitos en que la analogía tiene limitaciones (por ejemplo, el modelo fuerte de hoy no "intenta" engañar al supervisor).

Problemas abiertos

Para cerrar el curso, un mapa honesto de lo que no está resuelto:

1. Honestidad verificable. ¿Cómo sabemos que el modelo reporta lo que "cree" y no lo que creemos que queremos oír? Las técnicas de interpretabilidad y de eliciting latent knowledge atacan esto, sin solución general aún.
2. Robustez adversarial. Las salvaguardas actuales mejoran año a año, pero no hay garantías fuertes contra adversarios con suficiente esfuerzo.
3. Supervisión de agentes. Trayectorias largas con herramientas multiplican los puntos de falla y hacen difícil la revisión humana paso a paso.
4. Evaluar la evaluación. ¿Cómo validamos que una eval mide lo que dice medir, sobre todo para propiedades como "engaño" o "intención"?
5. Valores y legitimidad. Más allá de lo técnico: ¿qué preferencias optimizamos, de quién, y con qué proceso de decisión?

Ninguno de estos problemas tiene una solución única. El campo avanza combinando defensas en capas (defense in depth): entrenamiento con preferencias, principios explícitos, interpretabilidad, evals, red teaming, monitoreo en despliegue y supervisión humana en los puntos de mayor riesgo. Ninguna capa es suficiente sola; juntas reducen la probabilidad de fallas no detectadas.