¿Ese consejo sobre en qué idioma son mejores los códigos de IA? Todo se desmorona en el trabajo real
Dan Luu repitió la afirmación popular de que los lenguajes dinámicos son más baratos para los agentes de codificación. En dos grandes tareas el efecto desapareció y el segundo benchmark más citado resultó estar superado.
Hay un consejo que dice que si desea que un agente de codificación de IA sea económico y eficaz, debe elegir un lenguaje compacto y escrito dinámicamente. El propio resumen de IA de Google lo repite. Dan Luu, un ingeniero con una larga trayectoria en desarmar afirmaciones populares, realizó sus propias pruebas. En cualquier cosa que se parezca a un trabajo real, el efecto desaparece.
La afirmación original provino de un benchmark que mide cuántos tokens, los pequeños fragmentos de texto que lee y escribe un modelo y por los que se le factura, se necesitan diferentes idiomas para resolver problemas de Rosetta Code. Encontró una brecha de 2,6 veces entre C, el peor, y Clojure, el mejor, y una ganancia aún mayor para el lenguaje de matriz J, con alrededor de 70 tokens por solución. La objeción de Luu es contundente: un problema que puedes resolver con 70 fichas no es un problema. La mayor parte del trabajo consiste en imprimir la respuesta.
Entonces construyó dos pruebas más difíciles. En el primero, a los agentes se les dio la especificación de compresión zstd y se les pidió que implementaran un decodificador funcional, sin acceso a Internet y sin poder ver las pruebas. En el segundo, se les entregó el benchmark del convertidor de documentos Pandoc y se les puntuó en pruebas que nunca habían visto. En ambos casos, no surgió ningún ganador claro entre los lenguajes estáticos y dinámicos. Con un mayor esfuerzo de razonamiento, varios lenguajes estáticos se impusieron. Los lenguajes oscuros y densos que habían parecido tan impresionantes en los problemas de los juguetes tuvieron malos resultados, lo que se ajusta a una explicación simple: los laboratorios de inteligencia artificial dedican su esfuerzo de capacitación a los lenguajes que la gente realmente usa.
¿Qué hay detrás?
La parte más útil del artículo es la autopsia de otros benchmarks citados. Una prueba ejecutó un ejecutable en una ruta que no existía, por lo que cada ejecución de Rust falló. Una ejecución posterior de Go “solucionó” este problema creando un enlace simbólico a su propio binario, lo que significó que cada prueba posterior en cada idioma ejecutaba silenciosamente el programa Go. El autor del benchmark concluyó que Rust tiene problemas porque es un lenguaje difícil. Si se recupera correctamente, Rust obtiene una puntuación perfecta. Otras dos pruebas tuvieron un error de copiar y pegar que las hizo pasar sin importar lo que hiciera el código.
Luu también es cuidadoso con su propio trabajo. Señala que solucionó más de cien errores de configuración y espera que queden más, y se niega a hacer afirmaciones sobre idiomas individuales de dos tareas. El único patrón que defenderá es débil pero consistente: los lenguajes más populares tienden a producir resultados más correctos y más baratos.
Qué significa esto para ti: No cambies de lenguaje porque un gráfico diga que un agente saldría más barato con otro. Quédate con una opción extendida y bien respaldada. En general, esta es una buena lección sobre cómo pueden fallar los bancos de pruebas de IA: un resultado llamativo en problemas minúsculos suele dejar de serlo cuando el problema adquiere un tamaño relevante. Cuando veas uno, pregunta qué dificultad tenían las tareas.
Fuentes
Fuentes: https://danluu.com/pl-tokens/
El creador de Redis ejecutó un modelo de video chino en una Mac. Los europeos no tienen licencia para usarlo
Salvatore Sanfilippo publicó h3.c, un motor C y Metal que ejecuta MiniMax H3 de forma nativa en Apple Silicon. La propia licencia del modelo excluye del despliegue local a la UE, Reino Unido, EE.UU. y Corea del Sur.
