Verifica las afirmaciones de auto-mejora de la IA con reejecuciones de semilla fija
Una reejecución con semilla fija en un benchmark público separa las mejoras reproducibles de los éxitos reportados por el proveedor.
Estás leyendo una publicación de un proveedor: su agente mejoró un modelo y el número parece bueno. El tiempo de NanoGPT Speedrun autodeclarado por AutoTrust fue de 24.90 segundos, frente al récord de junio de Recursive de 75.36 segundos.
AutoTrust declaró que sus resultados de NanoGPT Speedrun y Time-to-GPT-2 aún no habían sido revisados por los mantenedores del benchmark. Considera la afirmación como no verificada hasta que una reejecución con semilla fija en un benchmark público con un objetivo publicado diga lo contrario.
Una startup de unos 10 investigadores dedicó septiembre a generar resultados en evaluaciones públicas de IA que mejora la IA. AutoTrust AI informó que su sistema de investigación agéntico ScienceGuru produjo resultados en cuatro benchmarks públicos para probar IA de auto-mejora.
- Elige un benchmark público con un objetivo publicado, un conjunto de validación fijo y una especificación de hardware.
- Bloquea la semilla y registra el log de ejecución antes de que el agente comience.
- Ejecuta N reejecuciones en hardware comparable, registrando la pérdida final, el tiempo transcurrido y los fallos.
- Compara el resultado con el registro público, no con la narrativa del proveedor.
- Etiqueta la afirmación como verificada, no verificada o no comparable.
Elige un benchmark con un objetivo publicado
El objetivo debe ser un número que puedas comprobar, no un puesto en un ranking que puede cambiar. AutoTrust informó que ScienceGuru terminó primero en Autoresearch@Home y fue el envío validado líder en NanoPath de MedARC al momento de publicarse. Un puesto es útil, pero no es un objetivo fijo. Para una prueba de tipo speedrun, el objetivo debe ser un valor de pérdida, donde menor es mejor, o un umbral de tiempo hasta alcanzar esa pérdida. El repositorio modded-nanogpt describe el NanoGPT speedrun como la ruta más rápida para alcanzar una pérdida de entropía cruzada de 3.28 en datos de validación de FineWeb usando ocho GPU NVIDIA H100. El objetivo de pérdida de 3.28 en FineWeb se eligió para coincidir con la reproducción de GPT-2 de llm.c de Andrej Karpathy, que según el repositorio alcanza esa pérdida en 45 minutos.
Preferir un benchmark donde puedas descargar el conjunto de validación e inspeccionar el script de puntuación. La página debe mostrar el objetivo, el conjunto de datos, el número de GPU y la regla de parada. Un puesto por sí solo es débil; pregunta en qué se basa antes de gastar cómputo.
Bloquea la semilla y el hardware
Registra la semilla aleatoria antes de que el agente comience. El log de ejecución debe indicar la semilla, la arquitectura del modelo, la configuración del optimizador, el tamaño del lote y la condición de parada. Un agente que elige su propia semilla tras un mal resultado no está haciendo una reejecución. Un log ausente significa detenerse y solicitarlo antes de gastar cómputo.
Usa hardware comparable: misma clase de GPU, mismo número de GPU, misma memoria y mismo stack de software que la afirmación original. Un hardware no coincidente significa marcar la comparación como no comparable. Una máquina más rápida puede hacer que un agente débil parezca ingenioso; una más lenta puede hacer que un agente fuerte parezca perezoso.
Tratar una captura de pantalla del proveedor como una ejecución es el fallo más común. Puede ocultar la semilla, la regla de parada o el hardware. Pide el log de ejecución, no el montaje de momentos destacados.
Ejecuta la reejecución contra el registro público
Ejecuta la misma tarea con la semilla bloqueada en hardware comparable, más de una vez cuando el cómputo lo permita. Registra la pérdida final, el tiempo transcurrido y el número de reejecuciones. Un resultado que no alcanza el objetivo no ha sobrevivido. Una reejecución con fallo es un resultado, no una casualidad.
Compara el resultado con el registro público, no con la narrativa del proveedor. Un ranking público es útil cuando indica la regla de validación y el estado del envío. El estado sin revisar importa: un resultado que aún no ha sido revisado es un punto de partida, no una prueba concluida. Hasta que la revisión esté completa, la afirmación necesita el mismo escrutinio de semilla fija que aplicarías a cualquier otro resultado.
Etiqueta la afirmación, no al proveedor
Escribe el resultado con una de tres etiquetas: verificada, no verificada o no comparable. Verificada requiere que la reejecución con semilla fija alcance el objetivo publicado en hardware comparable. No verificada cubre un objetivo no alcanzado o un log de ejecución ausente. No comparable cubre diferencias de hardware, semilla o regla de parada respecto a la afirmación original.
Mantén la etiqueta asociada a la afirmación, no a la empresa. Un sistema puede ser bueno en un benchmark y débil en otro. Un proveedor puede ser honesto sobre un resultado y descuidado sobre otro. La reejecución con semilla fija te da una forma clara de decir cuál es cuál.
Mantén la evidencia en un solo lugar: afirmación, benchmark, semilla, hardware, resultado, etiqueta. Eso hace que la siguiente evaluación sea más rápida y menos emocional. Cuando alguien pregunte por qué rechazaste la afirmación, muestra el registro.
