El loop gana: Ralph, RLM y autoresearch como estrategia de cómputo en tiempo de inferencia

Hay un patrón que se repite en los proyectos de IA más interesantes de 2026: la solución no es un pipeline más sofisticado. Es un loop más simple ejecutado más veces.

Ralph, RLM y autoresearch llegaron de comunidades distintas, atacan problemas distintos, pero convergen en la misma intuición: si le das a un modelo la oportunidad de intentarlo de nuevo, mejora. No porque el modelo sea diferente, sino porque el cómputo adicional en tiempo de ejecución hace el trabajo que antes intentábamos resolver con arquitecturas más complejas.

El principio compartido: test-time compute scaling

Antes de ver cada herramienta por separado, vale entender qué tienen en común.

Durante años, la estrategia dominante para mejorar el rendimiento de un modelo fue el preentrenamiento: más datos, más parámetros, más horas de cómputo antes del despliegue. El costo ocurría una vez; la mejora quedaba fija en los pesos del modelo.

El test-time compute scaling invierte esa lógica. En lugar de gastar más en entrenamiento, se gasta más en inferencia. El mismo modelo, con más oportunidades de razonar, corregir o iterar, alcanza resultados que antes requerían modelos más grandes.

Ralph, RLM y autoresearch son implementaciones concretas de esta idea, cada una en un dominio diferente.

Ralph: el loop de Bash más productivo del año

La implementación central de Ralph cabe en una línea:

while :; do cat PROMPT.md | claude-code ; done

Cada iteración arranca con contexto fresco. No hay acumulación de historial entre sesiones: el modelo lee el estado actual del sistema de archivos, las pruebas que pasaron o fallaron, el historial de Git, y decide qué hacer a continuación. Los aprendizajes de sesiones anteriores no viven en el contexto del modelo sino en AGENTS.md, un archivo que el agente puede leer y modificar.

Esta separación es deliberada. El contexto fresco evita que el modelo quede atrapado en los errores de razonamientos anteriores. El archivo de memoria persiste lo que importa sin contaminar la ventana de atención.

Los primeros experimentos con Ralph fueron reveladores, y no siempre de la manera esperada. En las primeras corridas documentadas por la comunidad, alrededor de 3 de cada 10 iteraciones desperdiciaban tokens por completo: el modelo elegía una dirección equivocada o entraba en un ciclo sin salida. El culpable en la mayoría de los casos era el prompt inicial, no el loop. Una vez que los usuarios refinaron PROMPT.md para incluir criterios de éxito explícitos y ejemplos del estado deseado, la tasa de iteraciones productivas subió considerablemente.

Ralph no es una solución lista para usar en cualquier tarea. Brilla cuando el objetivo es verificable y el espacio de soluciones es mecánico: migraciones de framework, ampliación de cobertura de pruebas, refactorizaciones repetitivas. En tareas ambiguas o que requieren juicio arquitectónico, el loop puede ser costoso sin producir convergencia.

RLM: recursión dentro del loop

RLM (Recursive Language Model) opera a una escala diferente. Su problema de origen es el context rot: los modelos degradan su rendimiento conforme crece el input, y ninguna ventana de contexto de 1M de tokens resuelve el problema de fondo.

La solución de RLM es dejar que el modelo escriba código Python para leer selectivamente el corpus en lugar de intentar digerirlo de un jalón. El texto masivo vive en variables del REPL; el modelo genera código que filtra, extrae y, cuando necesita razonar sobre un fragmento, se llama a sí mismo de forma recursiva mediante llm_query().

El benchmark OOLONG, diseñado para medir la comprensión real sobre documentos extensos, mostró algo que vale resaltar: GPT-5-mini con RLM superó por más del doble a GPT-5 solo. El modelo más pequeño, con acceso recursivo inteligente al corpus, venció al modelo más grande procesando todo de golpe. Es el argumento empírico más claro del año a favor del test-time compute sobre el escalado de parámetros.

La implementación tiene sus propias restricciones. La profundidad de recursión óptima en la mayoría de los casos es uno. Ir más profundo acumula errores en lugar de refinar la respuesta. Y el pre-filtrado con regex antes de llamar al LLM marca la diferencia entre un sistema eficiente y uno que gasta tokens innecesariamente.

autoresearch: el loop en tiempo de entrenamiento

autoresearch de Karpathy lleva la misma lógica al entrenamiento mismo. El sistema opera con un presupuesto de cinco minutos: durante ese tiempo, el agente intenta resolver un problema, hace commit de lo que funciona, y ejecuta un reset si el intento falla. Luego comienza el siguiente ciclo.

Es un loop de commit y reset aplicado al entrenamiento. Cada iteración de cinco minutos es un experimento autocontenido. Los que funcionan se acumulan; los que no, se descartan sin costo adicional.

La limitación más obvia es estructural: el sistema corre en una sola máquina. El presupuesto de cinco minutos es suficiente para tareas acotadas, pero descarta automáticamente cualquier experimento que requiera más tiempo o más recursos. Esto no es solo una restricción técnica sino una decisión de diseño: mantener cada iteración breve y verificable es lo que hace que el sistema funcione. Un presupuesto más largo introduciría experimentos más complejos, más difíciles de descartar, y el loop perdería su disciplina.

Para investigación reproducible y experimentos rápidos de arquitectura, autoresearch ofrece una cadencia que los flujos de trabajo manuales no pueden igualar. Pero para problemas que requieren entrenamiento largo o hardware distribuido, el modelo actual no escala.

Lo que estos tres proyectos cambian

El patrón que comparten no es accidental. Refleja un cambio en cómo la comunidad está pensando el rendimiento de los sistemas de IA.

La complejidad de un pipeline no es una virtud. Un loop simple con criterios de éxito claros, ejecutado suficientes veces, converge hacia soluciones que un sistema más elaborado de un solo paso no alcanza. El cómputo en tiempo de ejecución hace el trabajo que antes le asignábamos al tamaño del modelo o a la sofisticación de la arquitectura.

Esto tiene consecuencias prácticas para cualquiera que esté construyendo sobre modelos de lenguaje. Antes de agregar una capa más al pipeline, vale preguntarse si el mismo modelo con más iteraciones llegaría al mismo resultado por menos esfuerzo de ingeniería.

La respuesta, según Ralph, RLM y autoresearch, es que frecuentemente sí.