El muestreo repetido

El muestreo repetido es la técnica más simple para sacar más de un modelo de lenguaje sin cambiar el modelo: en lugar de pedirle una respuesta, se le piden muchas, y luego se elige una. Funciona porque los modelos generan texto con un componente de azar, de modo que dos intentos ante el mismo problema no siguen el mismo camino, y un problema que el modelo resuelve una de cada diez veces se resuelve casi seguro si se lo intenta cincuenta. Toda la dificultad está en la segunda mitad de la frase. Generar muchas respuestas es fácil y cuesta dinero; saber cuál de ellas es la buena es el problema entero, y la forma de elegir decide si el cómputo adicional se convierte en aciertos o se tira.

La versión que dio a conocer la idea es la autoconsistencia (self-consistency), propuesta en 2022 por Xuezhi Wang y sus coautores de Google. Se pide al modelo que razone paso a paso varias veces sobre el mismo problema, cada vez con un poco de azar, y se elige la respuesta final que más veces aparece. La intuición es que un problema difícil admite varios caminos de razonamiento que llegan a la misma respuesta correcta, mientras que los errores tienden a dispersarse. En los problemas escolares de matemáticas del banco GSM8K la mejora fue de casi dieciocho puntos sobre un único razonamiento, y de entre cuatro y doce en otras pruebas de aritmética y sentido común. Para una técnica que no exige entrenar nada ni escribir ningún verificador, era un resultado enorme, y la votación por mayoría se convirtió en el acompañamiento habitual de cualquier resultado publicado en razonamiento.

El trabajo que midió el límite de la idea llegó en 2024. Bradley Brown y sus coautores, de Stanford, Oxford y Google DeepMind, llevaron el número de intentos hasta los diez mil y separaron con cuidado dos cantidades. La primera es la cobertura: la proporción de problemas en los que al menos una de las respuestas generadas es correcta. La segunda es lo que se resuelve de verdad cuando hay que elegir una. La cobertura crecía de manera regular con el número de intentos durante cuatro órdenes de magnitud, siguiendo una ley casi lineal en escala logarítmica. En el banco de pruebas SWE-bench Lite, formado por incidencias reales de proyectos de código abierto, un modelo abierto pasaba de resolver el 15,9 por ciento de los problemas con un intento al 56 por ciento con doscientos cincuenta, por encima del mejor resultado publicado entonces con un solo intento, el 43. Pero en esos problemas había pruebas automáticas que decían qué parche funcionaba. En los dominios sin ese verificador, la votación por mayoría y los modelos que puntúan respuestas se estancaban a partir de unos cientos de intentos y dejaban sin aprovechar casi toda la cobertura.

La figura reproduce ese comportamiento con un modelo sencillo y deja ver por qué ocurre. La votación falla en un tipo de problema muy concreto: aquel en el que el modelo se equivoca más veces de las que acierta y, sobre todo, se equivoca siempre de la misma manera. Si en un problema el modelo acierta un treinta por ciento de las veces y da la misma respuesta errónea un cuarenta, cien intentos no ayudan: la respuesta equivocada gana la votación con más seguridad cuantos más votos hay. La votación convierte en aciertos los problemas en los que el modelo ya tiende a acertar, y deja fuera todos los demás, por mucho que la respuesta correcta aparezca entre las generadas. El deslizador de errores coincidentes controla precisamente eso: cuando los errores se dispersan, la votación funciona mejor; cuando se concentran, se hunde.

El verificador rompe esa limitación porque no necesita que la respuesta correcta sea mayoritaria, solo que aparezca. Si comprueba de verdad, como unas pruebas de programación que se ejecutan, toda la cobertura se convierte en aciertos. Si se equivoca a veces, aceptando algunas respuestas incorrectas, entonces la ventaja depende de cuántos falsos positivos cuela, y la figura muestra que basta con que el verificador dé por buenas una de cada cinco respuestas incorrectas para que, pasados unos pocos intentos, generar más deje de ayudar. En un problema que el modelo resuelve una vez de cada veinte, entre las respuestas aceptadas hay cuatro malas por cada buena, y el verificador acaba acertando una de cada cinco veces por muchas que se generen. Karl Cobbe y sus coautores de OpenAI ya lo habían planteado así en 2021, cuando entrenaron un modelo verificador para puntuar soluciones a problemas de matemáticas y mostraron que generar muchas y elegir con él ganaba a ajustar el generador; el reto, desde entonces, es construir verificadores que se equivoquen poco en dominios donde no hay nada que ejecutar.

El caso extremo de esta lógica fue AlphaCode, el sistema de DeepMind que en 2022 compitió en concursos de programación. Generaba hasta un millón de programas por problema, descartaba con los ejemplos del propio enunciado la inmensa mayoría, agrupaba los supervivientes según cómo se comportaban con entradas nuevas y enviaba solo diez. Con esa tubería, que es muestreo repetido con un verificador parcial y un poco de ingenio para no gastar los envíos en variantes del mismo programa, se situaba en torno a la mitad de la clasificación de los concursantes humanos. El modelo, por sí solo, estaba muy lejos de eso.

Para quien diseña un agente, la lección tiene una forma práctica. Antes de pedir diez respuestas, hay que preguntarse cómo se va a elegir entre ellas. Si existe una comprobación automática y fiable, compilar, ejecutar pruebas, validar un formato, contrastar un resultado con una base de datos, el muestreo repetido es probablemente la forma más barata de mejorar el resultado, más barata que un modelo más grande, y el paralelismo lo hace rápido. Si la elección depende de un juez automático, la mejora dura lo que duren sus aciertos, y hay que medir sus falsos positivos antes de fiarse. Si no hay más criterio que la mayoría, se obtendrá la ganancia de la autoconsistencia, real y modesta, y conviene pararse pronto: la figura muestra que casi toda llega con los primeros ocho o dieciséis intentos.

Hay una lectura del muestreo repetido que conviene tener presente al leer cualquier cifra de rendimiento. Un sistema que resuelve el 56 por ciento de los problemas con 250 intentos y un verificador no es un sistema que resuelva el 56 por ciento de los problemas: es un sistema que cuesta 250 veces más por problema y que necesita un verificador. La misma confusión, en la otra dirección, es la que separa en la evaluación de agentes acertar al menos una vez en k intentos de acertar las k veces, y la que hace que un evaluador-optimizador funcione en programación y fracase en casi todo lo demás. En los tres casos la pregunta es la misma, y no es cuánto sabe el modelo, sino quién comprueba lo que hace.