De generar planes a decidir el siguiente paso: cómo AutoResearch cierra el ciclo de investigación sin inventar éxitos

AutoResearch conecta el descubrimiento de problemas, la generación de planes, los experimentos en enjambre y la validación independiente en un proceso de investigación capaz de avanzar de forma continua. En una tarea de reparación de Django, elevó el resultado de las pruebas oficiales de funcionalidad nueva de 2/7 a 7/7, manteniendo aprobadas las 203/203 pruebas de regresión. En tres experimentos de Kaggle también distinguió entre alcanzar el objetivo, quedarse cerca y llegar a una meseta, y utilizó esas evidencias para continuar, cambiar de dirección o detenerse.

AutoResearch es un sistema automatizado de investigación. Observa continuamente artículos, proyectos de código abierto, debates de la comunidad y anomalías técnicas; identifica problemas que merece la pena estudiar; organiza varios modelos para convertir ideas en experimentos; y deja que los resultados externos decidan el siguiente paso.

El proceso aborda un fallo más difícil de detectar que una invención: el código existe y las pruebas locales realmente pasan, pero el sistema confunde «esta parte es correcta» con «el problema completo está resuelto».

Figura 1 | Que todas las pruebas locales estén en verde solo demuestra que han pasado las comprobaciones cubiertas. La evaluación independiente descubre carencias críticas que todavía no estaban cubiertas.

En una tarea real de reparación de Django, GPT-5.6 superó 716 pruebas de migration y 39 pruebas del optimizer, pero obtuvo 0/7 en las pruebas oficiales de funcionalidad nueva. AutoResearch tampoco resolvió el problema completo en la primera ronda: las pruebas locales estaban en verde y el resultado oficial era solo 2/7. La diferencia apareció después del fallo. El sistema siguió reformulando el problema a partir de los resultados externos y avanzó por 2/7, 4/7 y 7/7 hasta que pasaron tanto las pruebas de funcionalidad nueva como las de regresión.

1. Cuatro acciones forman el ciclo principal de investigación

Figura 2 | Encontrar un problema, forjar una idea verificable, ejecutar el experimento y dejar que la evidencia decida. Estas cuatro acciones forman el ciclo principal de AutoResearch.

El ciclo principal de AutoResearch contiene cuatro acciones consecutivas:

1. Descubrir un problema: extraer de la información abierta fenómenos, resultados o contradicciones no resueltas que puedan rastrearse.
2. Formar una idea verificable: reescribir la señal como una hipótesis de investigación con criterios de éxito, límites de recursos y condiciones de fracaso.
3. Organizar experimentos en enjambre: distribuir la planificación, la implementación, la ejecución y la revisión entre roles que colaboran.
4. Dejar que la evidencia decida: los resultados externos determinan si se itera, se cambia de dirección o se detiene el trabajo.

Un fallo no cierra automáticamente el flujo. Se convierte en la entrada de la siguiente ronda y obliga al sistema a estrechar el límite del problema o cambiar la ruta experimental.

2. Encontrar un problema que merezca investigarse antes de intentar responder

AutoResearch sigue arXiv, Hugging Face Daily Papers, OpenReview y GitHub Trending, además de Reddit, Hacker News, blogs de investigación, medios tecnológicos en chino y Twitter/X. Los canales difieren mucho en formato, significado de la popularidad y densidad informativa. Después de recopilar los datos, hay que normalizarlos, filtrar su calidad y eliminar duplicados dentro del lote y entre días.

Un modelo de primera etapa decide rápidamente si cada elemento contiene una observación que pueda convertirse en un tema de investigación. Los candidatos conservados pasan a modelos más capaces para una selección adicional según novedad, viabilidad técnica, recursos necesarios y método de evaluación. Cuando hay suficientes candidatos, el sistema vuelve a ordenarlos y selecciona las semillas de investigación que deben entrar primero en Idea Forge.

Este embudo comprime un flujo abierto de información en un pequeño conjunto de candidatos que justifican invertir recursos experimentales. Cada problema conserva una fuente explícita, por lo que los planes posteriores pueden contrastarse con la observación original.

3. Idea Forge convierte señales en planes experimentales

Una semilla de investigación es solo un fenómeno o problema del mundo exterior. Idea Forge también selecciona una línea de investigación existente de la base de conocimiento y combina ambas piezas para crear planes candidatos. Las líneas actuales incluyen fusión multimodal, gestión de tokens visuales, razonamiento de modelos grandes y cómputo en tiempo de prueba (test-time compute), y memoria de agentes.

Gemini, GPT y Claude proponen y revisan de forma independiente las ideas candidatas. Sus antecedentes de entrenamiento y preferencias de juicio son diferentes: algunos reaccionan más a la novedad, otros se centran en la viabilidad técnica y otros detectan antes carencias de recursos o evaluación. Antes de entrar en ejecución, un plan candidato debe superar cuatro comprobaciones:

• Revisión cruzada: tres modelos lo juzgan de manera independiente, y una idea necesita al menos dos votos para continuar.
• Comprobación de vigencia: se excluyen modelos anticuados, fechas antiguas y formulaciones técnicas obsoletas.
• Comprobación de consenso de conocimiento: el plan debe usar realmente la línea de conocimiento seleccionada, no unir términos de moda de forma mecánica.
• Plan por etapas: la primera etapa utiliza un piloto de bajo coste que decide rápidamente la dirección; las posteriores amplían el experimento, incorporan ablaciones y completan la evaluación.

La votación mayoritaria sirve para exponer puntos ciegos pronto. El plan final todavía debe concretarse en una hipótesis medible, un presupuesto explícito y experimentos capaces de decidir el éxito o el fracaso.

4. Del plan al experimento: cómo colabora el enjambre

Figura 3 | Tras la revisión cruzada y la planificación, una semilla entra en un flujo colaborativo de planificación, implementación, ejecución, revisión y evaluación externa.

Durante la ejecución, AutoResearch divide el trabajo en unidades consecutivas. Un rol de coordinación mantiene el estado global; un rol de planificación transforma el objetivo en un diseño experimental falsable; un rol de implementación escribe el código; un rol de ejecución lo ejecuta y organiza los resultados; y los revisores buscan omisiones desde perspectivas diferentes.

Las tareas sencillas pueden usar menos roles, mientras que las complejas pueden añadir un Subcoder, un Monitor o un validador independiente. Los nombres de los roles no determinan el resultado. Lo importante es que planificación, implementación, ejecución y revisión ya no estén comprimidas en una sola respuesta del modelo.

Los planes, el código, los registros experimentales y las observaciones de revisión permanecen en un espacio de trabajo persistente. El ciclo sigue procesando las unidades incompletas hasta que las métricas externas y las condiciones de parada permiten cerrarlo. Los resultados pueden refutar el plan y los revisores pueden equivocarse. La recomendación de terminar emitida por un rol no puede cerrar el flujo. Los resultados reproducibles y los criterios de éxito independientes deciden si se continúa y cuándo se detiene.

5. Validación del sistema I: llevar un objetivo de investigación hasta un resultado verificable

AutoResearch empleó un protocolo experimental similar en tres problemas de Kaggle: comenzar con un piloto de bajo coste para validar la dirección y diseñar el experimento principal a partir del resultado. Cada etapa tiene un criterio de éxito, revisión de código, registro de ejecución y decisión de parada. Los tres problemas usan respectivamente accuracy, raíz del error cuadrático medio logarítmico (RMSLE) y F1 como métricas principales, con la dirección definida por la competición oficial de Kaggle [1][2][3].

Figura 4 | Un mismo protocolo produce tres desenlaces: Titanic alcanza el objetivo, House Prices se aproxima y Disaster Tweets llega a una meseta. Cada gráfico tiene una escala vertical independiente y no debe compararse numéricamente entre tareas.

5.1 Titanic: un control estricto aísla el valor de la ingeniería de variables

La primera etapa utilizó nueve variables básicas para establecer una línea base. La accuracy de Gradient Boosting con validación cruzada de cinco particiones fue 0.8272. La segunda etapa añadió Title, FamilySize, IsAlone, intervalos de edad e intervalos de tarifa, entre otras variables.

Control y Treatment utilizaron la misma semilla aleatoria, las mismas particiones de datos y el mismo modelo. Control conservó las variables básicas; Treatment incorporó el conjunto ampliado. Control reprodujo por completo el resultado de la primera etapa, mientras que Treatment alcanzó 0.8428 y superó el objetivo de 0.8300. La principal diferencia entre ambas condiciones fue el conjunto de variables, por lo que el resultado respalda que la ingeniería de variables produjo la mejora de esta ronda.

5.2 House Prices: identificar los cambios responsables de la mayor parte de la mejora

El objetivo era reducir el RMSLE de validación cruzada de cinco particiones por debajo de 0.1200. El sistema creó primero una línea base Ridge con una muestra pequeña y después cambió únicamente el objetivo de predicción aplicando log1p a los precios. El RMSLE bajó de 0.2008 a 0.1566. Añadir unas pocas variables derivadas produjo 0.1563, lo que mostró que seguir acumulando variables aportaba muy poco.

En el experimento completo, la familia de modelos cambió de un modelo lineal a LightGBM y redujo el resultado a 0.1258. Las variables ampliadas y las interacciones alcanzaron finalmente 0.1251. No se logró el objetivo, pero los experimentos localizaron las fuentes dominantes de mejora: la transformación del objetivo y el cambio de familia del modelo explicaron casi todo el avance, mientras que las variables adicionales tuvieron un efecto marginal. El sistema dejó de ampliar mecánicamente el espacio de ajuste.

5.3 Disaster Tweets: una meseta activa la parada

El objetivo era alcanzar un F1 de 0.8350. El sistema empezó con TF-IDF y regresión logística, estableció una línea base léxica de 0.7680 y después probó SBERT, ajuste fino de DistilBERT y conjuntos de votación blanda. El mejor resultado fue 0.8049.

Después aumentó el número de parámetros de 66M a 125M y cambió a RoBERTa-base, cuyo mejor valor fue 0.8005 y no superó a DistilBERT. Tras 21 experimentos, el mejor resultado seguía siendo 0.8049. El modelo de mayor tamaño no aportó mejora, por lo que el sistema dejó de añadir experimentos en la misma ruta y redujo el siguiente paso a tres opciones: conseguir datos útiles, añadir recursos de entrenamiento o cambiar el enfoque de modelado.

6. Validación del sistema II: avanzar de una reparación local a una solución completa

La segunda evaluación usa django__django-16820 de SWE-bench Lite. SWE-bench aplica un parche generado por el modelo a un repositorio real y ejecuta sus pruebas para determinar si el problema está resuelto [4]. Esta tarea nació de la retirada de Meta.index_together en Django e implica que migration optimizer y autodetector trabajen de forma coordinada con RenameIndex, AddIndex, RemoveIndex y claves foráneas cíclicas. La discusión upstream de Django también registra la relación entre estas operaciones de índices y la optimización compleja de migrations [5].

Figura 5 | GPT-5.6 terminó después de que las pruebas locales pasaran y las pruebas oficiales de funcionalidad nueva dieran 0/7. AutoResearch reformuló el problema tras los resultados 2/7 y 4/7, hasta llegar a 7/7 y mantener aprobadas las 203/203 pruebas de regresión. Las dos condiciones tuvieron distinto tiempo y acceso a feedback; la comparación se limita al proceso posterior al fallo.

GPT-5.6 encontró una carencia real: CreateModel.reduce() no tenía lógica de plegado para RenameIndex(old_fields=...). Su parche pasó 39 pruebas del optimizer, 716 pruebas de migration y las 203 pruebas oficiales de regresión, pero obtuvo 0/7 en las pruebas oficiales de funcionalidad nueva. Resolvió el subproblema de RenameIndex, sin cubrir AddIndex, RemoveIndex, el autodetector ni las claves foráneas cíclicas.

AutoResearch también se centró en RenameIndex durante la primera ronda. La revisión de código encontró que faltaba un no-match guard. Después de corregirlo, pasaron 41 pruebas del optimizer, 11 pruebas de integración de squashmigrations y 719 pruebas de migration. El primer resultado oficial fue 2/7.

Los resultados externos ampliaron la perspectiva desde una sola rama de reduce() hasta la coordinación entre optimizer y autodetector. La segunda versión llegó a 4/7. La ronda siguiente siguió el modo en que el estado de los índices entra en el flujo de migration, se pliega y converge. El resultado final alcanzó 7/7 en las pruebas oficiales de funcionalidad nueva y mantuvo 203/203 en las pruebas de regresión.

7. AutoResearch automatiza decisiones de investigación

Las dos evaluaciones muestran que la capacidad central de AutoResearch se concentra en cinco partes:

1. Convertir un problema de investigación en un objeto ejecutable: una idea debe materializarse en un piloto, criterios de éxito, presupuesto de recursos, plan de ablación y entregables.
2. Colocar modelos diferentes en posiciones adecuadas: los modelos ligeros filtran muchos candidatos, los más capaces juzgan en profundidad y varias familias de modelos proponen y revisan ideas de forma independiente.
3. Hacer que el resultado de cada etapa determine la acción siguiente: alcanzar el objetivo, quedarse cerca y obtener un resultado negativo dejan evidencias y activan respectivamente la ampliación, el ajuste o la parada.
4. Entregar la autoridad de finalización a métricas independientes: el consenso interno y unas pruebas locales en verde no sustituyen un criterio de éxito completo definido de antemano.
5. Permitir que el sistema se detenga: cuando una dirección llega a una meseta o cae el retorno del esfuerzo, el sistema cierra la ruta actual y conserva el estado y las conclusiones necesarios para reiniciarla.

Los modelos proponen, implementan y cuestionan. La evidencia decide qué ocurre después.

8. El éxito es una cadena de evidencias sin interrupciones

Los modelos grandes ya generan respuestas candidatas con rapidez. AutoResearch diseña el ciclo completo que viene después de una respuesta: cómo convertir un problema en un experimento, quién revisa el resultado, cómo el fracaso reescribe el siguiente paso, qué evidencia justifica continuar y bajo qué condiciones se detiene el sistema.

Este método puede llamarse ingeniería de ciclos (Loop Engineering). El diseño abarca más que roles y prompts: incluye cómo se conserva el estado, cómo circula la evidencia y cómo se revisan los juicios. Los roles pueden equivocarse. El ciclo debe exponer esos errores e impedir que un «éxito» sin evidencia cierre el flujo.

9. Referencias

1. Kaggle. (2012). Titanic - Machine Learning from Disaster. Kaggle Getting Started Competition.
2. Kaggle. House Prices - Advanced Regression Techniques. Kaggle Getting Started Competition.
3. Kaggle. Natural Language Processing with Disaster Tweets. Kaggle Getting Started Competition.
4. Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. The Twelfth International Conference on Learning Representations.
5. Django Software Foundation. (2023). Fixed #34529, Refs #34525: Reduced index operations with Meta.indexes / index_together when optimizing migrations. django/django Pull Request #16820.