¿Qué es OpenAI Codex?

Cuando OpenAI presentó Codex, lo hizo con un número que casi nunca se cita entero. En el artículo «Evaluating Large Language Models Trained on Code», publicado el 7 de julio de 2021 por Mark Chen y otros cincuenta y siete autores, el modelo resuelve el 28,8% de los problemas de programación de su banco de pruebas.

Y unas líneas después aparece el otro número: si se le deja generar cien intentos por problema, resuelve el 70,2%.

Los dos son ciertos, están en el mismo resumen, y la distancia entre ellos es lo más útil que puede aprenderse de este sistema. Porque uno de los dos solo sirve si usted tiene algo que no siempre tiene.

Qué es Codex, con lo que consta

Es un modelo de lenguaje de OpenAI ajustado sobre código fuente público, capaz de traducir una instrucción en lenguaje natural a código y de completar el que uno está escribiendo. El artículo lo enlaza con el producto que casi todo el mundo conoce: «una versión de producción distinta de Codex impulsa GitHub Copilot».

Esa frase merece atención por sí sola: una versión de producción distinta. Lo que se midió en el artículo no es exactamente lo que corre en el editor de nadie. Es una precisión honesta del propio fabricante, y del tipo que conviene buscar siempre: las cifras publicadas describen el modelo del laboratorio, no necesariamente el producto que usted paga.

Cómo se mide «sabe programar»

Para medirlo construyeron un banco de pruebas nuevo, HumanEval, con el propósito de «medir la corrección funcional al sintetizar programas a partir de docstrings»: se le da la descripción de una función y se comprueba si el código que escribe pasa las pruebas.

Esa definición es más exigente de lo que parece y conviene retenerla. No se evalúa si el código «se parece» al que escribiría un humano, ni si compila: se ejecuta y se comprueba que hace lo que se pedía. Es una elección metodológica excelente, porque el parecido superficial es exactamente lo que un modelo de lenguaje sabe fabricar sin entender nada.

Para situar el 28,8%, el mismo artículo da los puntos de comparación: GPT-3, sin ajuste sobre código, resolvió el 0%. GPT-J, el 11,4%. Es decir, el ajuste específico sobre código no mejoró un poco el resultado: lo creó de la nada.

Los dos números, y por qué solo uno es suyo

Aquí está la capacidad. El 28,8% es lo que acierta al primer intento. El 70,2% es lo que acierta si se le permiten cien y se elige el que funciona.

Y ahí está la letra pequeña: para elegir el que funciona hace falta saber cuál funciona. En el experimento eso es trivial, porque existen las pruebas automáticas que deciden. En su trabajo, puede que no.

Si usted tiene una batería de pruebas que verifica el resultado, el 70,2% está a su alcance: genera varias soluciones, las ejecuta, se queda con la que pasa. Si no la tiene, ese número no existe para usted; lo suyo es el primer intento, o peor, porque tendrá que revisar a mano cien candidatos y decidir cuál está bien — que es justamente el trabajo que quería ahorrarse.

Generalice, porque esta forma de dato está por todas partes: cualquier cifra del tipo «el mejor de N intentos» presupone en silencio que existe alguien capaz de decidir cuál es el mejor. Ese alguien se llama verificador, y es lo que de verdad hay que preguntar. Cuando lea «acierta el 90% de las veces», la pregunta no es de dónde sale el 90%, sino quién decidió que había acertado — y si ese juez estará disponible el día que lo use usted.

El cero de GPT-3 dice más que el 28,8

Vuelva un momento a ese 0%. GPT-3 era, en su momento, uno de los modelos de lenguaje más potentes que existían, entrenado con cantidades enormes de texto de internet —que incluye muchísimo código—. Y resolvió cero problemas.

No es que fuera flojo programando: es que no programaba. La capacidad no estaba latente esperando a que alguien la despertara con la instrucción adecuada. Hubo que construirla, entrenando específicamente sobre código.

Eso desmiente una intuición muy cómoda y muy extendida: la de que un modelo grande y general «sabe de todo un poco» y basta con pedírselo bien. La especialización no es un ajuste fino de presentación: es la diferencia entre cero y algo. Y tiene un coste — datos específicos, entrenamiento específico, evaluación específica — que alguien paga.

Guárdelo para la próxima vez que le ofrezcan un modelo general como solución a un problema muy concreto. La pregunta correcta no es si el modelo es potente, sino si alguien ha hecho el trabajo de especializarlo y si puede enseñar la medición.

Cómo medirlo en su propio código

La metodología del artículo se puede copiar en una tarde y vale mucho más que cualquier comparativa.

Coja veinte tareas reales de su propio historial —de las que ya tienen pruebas escritas, que las hay—. Pásele a la herramienta la descripción tal como estaba redactada, sin mejorarla para que le salga bien. Ejecute lo que devuelva contra las pruebas que ya existían. Cuente cuántas pasan al primer intento.

Ese porcentaje es su 28,8%, y es el único que le sirve para decidir. Si le sale muy por encima del publicado, revise si las tareas que eligió eran las fáciles; si le sale muy por debajo, ya sabe que su dominio no se parece al banco de pruebas — que es exactamente lo que necesitaba averiguar antes de comprar nada.

Lo que el modelo NO hace, aunque se repita mucho

Hay una idea muy extendida que conviene desmontar, porque cambia decisiones: Codex no aprende de usted mientras lo usa.

Los pesos de un modelo se fijan al terminar el entrenamiento y no se modifican por conversar con él. Que parezca adaptarse dentro de una sesión es otra cosa: se le está pasando su código como contexto, y al cerrar la sesión ese contexto desaparece. Nada de lo que usted escribió ha modificado el modelo.

La distinción importa por dos motivos muy prácticos. Uno: no espere que mejore con sus costumbres por el mero uso; si quiere que conozca su base de código, hay que dárselo cada vez o montar un sistema que lo recupere. Dos, y más serio: si el sistema no aprende de sus datos, tampoco los está incorporando por el hecho de usarlo — lo cual no significa que no se almacenen en otro sitio. Eso último no lo decide la arquitectura, lo decide el contrato del servicio, y es donde hay que mirar.

Dónde falla, según quien lo construyó

El propio artículo declara sus límites, y son de los que se reconocen al usarlo: el modelo muestra «dificultad con docstrings que describen cadenas largas de operaciones y al ligar operaciones a variables».

Traducido a la práctica: acierta bien con encargos de un paso —«ordena esta lista», «valida este correo»— y se degrada cuando la instrucción encadena varias condiciones que dependen unas de otras. Es exactamente la frontera entre autocompletar y programar, y estaba declarada por los autores desde el primer día.

Por dónde seguir, sin intermediarios

El artículo original es público y gratuito, y su sección de limitaciones y de impactos sociales es más interesante que la de resultados. HumanEval, el banco de pruebas, se publicó junto al trabajo, así que cualquiera puede reproducir la medición en lugar de creérsela.

La capacidad que se lleva de aquí es preguntar siempre quién hace de juez: un «acierta el 70%» sin verificador no es un resultado que usted pueda usar, es un resultado que alguien pudo comprobar en su laboratorio.