Benchmarking GPT-4 Turbo – Un cuento con moraleja
Los benchmarks que comparan el nuevo modelo GPT‑4 Turbo de OpenAI con el GPT‑4 original sugieren que Turbo puede rendir ligeramente peor en ciertos ejercicios de programación, probablemente porque “recuerda” menos ejemplos de entrenamiento, aunque ofrece inferencia más rápida y barata y un contexto mucho más largo. Los comentaristas debaten si el éxito en conjuntos de problemas estandarizados refleja un razonamiento genuino o mera memorización, y cómo diseñar pruebas justas cuando los modelos se entrenan con vastas porciones de Internet. Otros comparten resultados del mundo real que van desde ligeras caídas de calidad hasta mejoras notables, y señalan problemas más amplios como el rigor estadístico en las evaluaciones, los cambios en los flujos de trabajo de los desarrolladores y la ética de reutilizar configuraciones de benchmarking de código abierto.
Tema general
- La discusión se centra en qué mide realmente el benchmark de Exercism en GPT‑4 frente a GPT‑4 Turbo, y si las diferencias reflejan memorización, capacidad de razonamiento o ruido.
- Muchos ven a Turbo como “más rápido pero un poco más tonto”; otros sostienen que la evidencia es débil o que Turbo en realidad es mejor en sus casos de uso.
Memorización frente a razonamiento
- Algunos interpretan los resultados así: GPT‑4 tiene memorizados más problemas del benchmark; Turbo “olvida” más, pero razona de forma similar en tareas no vistas.
- Otros argumentan que identificar problemas solo a partir del título y el esqueleto de la función a menudo puede hacerse con conocimiento general, no con memorización exacta.
- Varios comentaristas subrayan que la memorización es una parte central de la inteligencia (humana o de máquina) y no es inherentemente “hacer trampa”.
- Se plantea la preocupación de que, cuando los LLM resuelven benchmarks, quizá estén sobre todo recordando datos de entrenamiento en lugar de demostrar una capacidad amplia.
¿Pueden realmente programar los LLM?
- Hay un fuerte desacuerdo: algunos afirman que tener éxito en problemas conocidos es solo “hacer trampa”, y por tanto no prueba capacidad de programación.
- Otros aportan anécdotas de LLM que escriben con éxito tests e implementaciones para bases de código y dominios privados y novedosos.
- Varios señalan que una gran parte de la programación humana también es recuperación de patrones; por tanto, la ayuda de los LLM sigue siendo valiosa.
Diseño del benchmark y solidez estadística
- Múltiples comentarios señalan que el tamaño de la muestra (~67 preguntas) es demasiado pequeño; con intervalos de confianza binomiales, la diferencia entre GPT‑4 y Turbo es estadísticamente débil.
- La gente pide benchmarks más grandes y realistas (por ejemplo, tareas multiarchivo, programación con contexto largo) y múltiples ejecuciones para manejar la aleatoriedad.
Experiencias reportadas por usuarios
- Algunos usuarios ven a GPT‑4 superando a Turbo en SQL complejo, análisis de artículos de ML y conjuntos de datos personalizados de preguntas y respuestas visuales.
- Otros informan que Turbo es ligeramente más preciso y significativamente más rápido en tareas como convertir OCR a texto estructurado o programar al estilo Exercism mediante otras herramientas.
- El benchmark separado de Exercism de Aider (Python) supuestamente muestra que Turbo lo hace mejor que variantes anteriores de GPT‑4, contradiciendo el patrón del artículo original.
Ventanas de contexto, costes y comportamiento
- Se elogia la larga ventana de contexto de Turbo, pero varios señalan una fiabilidad degradada más allá de ~30–40k tokens.
- Surgen preguntas sobre por qué la longitud de la completación está limitada a 4.096 tokens pese al gran contexto; las respuestas sugieren restricciones de coste y latencia.
- Algunos especulan que Turbo puede ser un modelo más pequeño o destilado, intercambiando algo de calidad por velocidad e inferencia más barata.
Ética, licencias y preocupaciones de evaluación
- Hay preocupaciones sobre la contaminación de pruebas: los modelos cerrados no pueden verificarse fácilmente respecto a solapamientos con el conjunto de entrenamiento y podrían sobreajustarse a benchmarks públicos.
- Un subhilo discute la atribución en código abierto y la reutilización de código entre herramientas de benchmarking.
- Algunos critican el “nerfeado” de modelos después de que los usuarios ya han pagado, y comparan el juego con los benchmarks de LLM con la optimización de benchmarks de hardware.