Gráficos de tareas atómicas: Planificación del trabajo de los agentes como un gráfico de dependencias
Cómo el marco Atomic Task Graph descompone las tareas de los agentes en nodos tipados, simula planes y repara únicamente los subgrafos fallidos para ayudar a que los modelos abiertos pequeños puedan competir.
Fuentes: This New AI Framework Turned 7B Models Into GPT-4 Competitors (Without Any Training)
La mayoría de los intentos por hacer que los agentes de LLM sean más fiables comienzan con un modelo más grande. El marco Atomic Task Graph (ATG), propuesto por investigadores de la Universidad de Tsinghua y la Universidad de Tecnología del Sur de China, parte de otro enfoque: modifica la forma en que el agente estructura su trabajo. Según el artículo, modelos de código abierto de 7B y 8B integrados con ATG superaron a GPT-4 al ejecutar un bucle ReAct estándar en dos pruebas bien conocidas para agentes, sin ningún tipo de ajuste fino, aprendizaje por refuerzo ni actualización de pesos. A continuación: por qué las cadenas de razonamiento lineal fallan, cómo ATG las reemplaza con un grafo de dependencias y qué ideas puede tomar prestadas para sus propios agentes.
Por qué los bucles lineales de agentes fallan en tareas largas
Considere una solicitud como “generar un informe de ventas de 2024 con gráficos”. Un agente típico al estilo ReAct trata esto como una larga secuencia de pasos, cada uno dependiente del anterior.
Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report
La cadena funciona bien siempre y cuando cada paso tenga éxito. Los problemas comienzan cuando alguno de ellos falla. Si la consulta a la base de datos falla, todos los pasos posteriores se basan en datos incompletos o incorrectos.
Database query
↓
Everything after it becomes wrong
En ese punto, el agente puede reiniciar desde el principio o seguir adelante con lo que tiene. Muchos eligen la segunda opción, lo cual es una fuente principal de alucinaciones: el modelo inventa datos plausibles para llenar los vacíos, y cada decisión posterior hereda ese error.
El contexto sigue creciendo
El segundo problema es cómo estos agentes mantienen el estado. Después de cada acción, el pensamiento, la llamada a la herramienta y la observación se añaden todos a un registro que sigue creciendo sin cesar.
User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
Con el tiempo, el modelo analiza páginas enteras de historial. El contexto se vuelve caótico y los errores iniciales permanecen visibles, por lo que siguen influyendo en las decisiones posteriores. Al igual que en un juego de telégrafo, cada ronda distorsiona ligeramente el plan hasta que este se desvía de la realidad.
La idea central: un grafo en lugar de una cadena
ATG reemplaza la secuencia única por un grafo de tareas. Cada nodo representa una unidad de trabajo, y cada arista registra una dependencia entre dos unidades.
Report
/ \
Analysis Charts
/ \
Database Statistics
La estructura hace visible la independencia: los trabajos no relacionados ya no esperan, y un fallo en una rama no invalida a sus ramas hermanas.
Cómo ATG construye y ejecuta el grafo
El framework funciona en cinco etapas.
1. Descomposición recursiva en tareas atómicas
Todo comienza con la solicitud del usuario.
Create sales report
ATG divide ese objetivo en subtareas.
Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary
Luego sigue dividiendo cualquier subtarea que siga siendo demasiado amplia, como el paso de análisis.
Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends
La descomposición se detiene cuando cada nodo hoja corresponde a una única invocación de herramienta, por ejemplo:
SQL query
Python calculation
Matplotlib chart
Markdown writer
Esos nodos hoja son las tareas atómicas: unidades lo suficientemente pequeñas como para que dividirlas aún más no tenga sentido. La regla de detención es importante: un nodo vago deja demasiado espacio para la improvisación, mientras que una consulta SQL tiene un resultado claro y verificable.
2. Entradas y salidas explícitas para cada nodo
Cada nodo cuenta con una interfaz, similar a la firma de una función. En lugar de una instrucción como “realizar el análisis”, el planificador describe qué consume y qué produce el nodo.
def analyze_sales(data):
return summary
El fragmento es ilustrativo, no código de framework, pero muestra el contrato. Dado que el grafo depende únicamente de ese contrato, un nodo puede ser intentado nuevamente o reemplazado por otra herramienta sin que sus vecinos se den cuenta, misma propiedad que hace que el código modular sea mantenible.
3. Ejecución paralela de ramas independientes
Un agente secuencial ejecuta las tareas una tras otra, incluso cuando algunas de ellas no están relacionadas.
Task A
↓
Task B
↓
Task C
Si B y C solo necesitan el resultado de A y no el uno del otro, ATG puede expresarlo directamente.
Task A
/ \
Task B Task C
\ /
Task D
B y C pueden ejecutarse al mismo tiempo, con D esperando a ambos. El artículo informa sobre rutas de ejecución notablemente más cortas en todas las pruebas de rendimiento que evaluó, lo cual se deriva naturalmente de convertir pasos independientes en pasos paralelos.
4. Una prueba preliminar antes de usar herramientas reales
Antes de ejecutar cualquier cosa, ATG simula internamente todo el plan, preguntándole esencialmente al modelo si dicho plan funcionaría si se llevara a cabo tal como está escrito. La simulación busca:
- pasos que faltan
- la herramienta incorrecta asignada a un nodo
- dependencias erróneas entre nodos
- diferencias en las interfaces, donde la salida de un nodo no coincide con la entrada del siguiente
- rutas de ejecución que en realidad no se pueden completar
- violaciones de las restricciones de la tarea
Es el equivalente en entornos automatizados a ejecutar pruebas antes del despliegue, y es económico porque no se utiliza ninguna herramienta externa. Sin embargo, la calidad de la verificación depende únicamente del modelo que la ejecuta: el modelo que elaboró el plan puede tener puntos ciegos, por lo que debe considerarse como un filtro y no como una garantía.
5. Reparación dirigida del subgrafo dañado
La etapa más distintiva es la forma en que ATG maneja los fallos en tiempo de ejecución. Tomemos un gráfico simple:
Database
↓
Analysis
↓
Charts
↓
Report
Supongamos que el nodo de análisis falla. Un agente convencional suele reaccionar descartando su progreso y comenzando de nuevo.
Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over
ATG, en cambio, mantiene el mismo gráfico y congela cada nodo que ya haya generado un resultado válido. El diagrama a continuación se muestra idéntico al original intencionadamente: la estructura no cambia, solo el nodo de análisis se marca para ser reprocessado mientras que los nodos de base de datos, gráfico e informe permanecen igual.
Database
↓
Analysis
↓
Charts
↓
Report
Solo se regenera el subgráfico que falló, y una vez que tiene éxito, el gráfico continúa con el nuevo resultado.
Database
↓
New Analysis
↓
Charts
↓
Report
Se trata de una compilación incremental aplicada a la planificación. Tenga en cuenta que si el análisis reparado produce números diferentes, los nodos posteriores que lo utilizan deben ejecutarse nuevamente; lo que se ahorra son los procesos anteriores y las ramas no relacionadas.
Por qué contextos más pequeños significan menos alucinaciones
En un bucle ReAct, cada paso tiene acceso a toda la historia. En ATG, cada nodo recibe únicamente las entradas que declara su interfaz, por lo que hay menos ruido y menos posibilidades de que se introduzcan errores anteriores.
El artículo cuantifica esto en ALFWorld:
- con ReAct, el 42.86% de las trayectorias contenían acciones alucinadas
- con ATG, esa cifra bajó al 12.14%
Eso representa una reducción relativa de aproximadamente el 72%, lograda sin cambiar el modelo subyacente.
Lo que muestran las pruebas de rendimiento
La evaluación utilizó tres modelos abiertos:
- Mistral 7B
- Gemma 7B
- Llama 3 8B
y tres pruebas de referencia para agentes:
- ALFWorld
- WebShop
- ScienceWorld
La comparación principal enfrenta a Llama 3 8B con ATG contra GPT-4 con ReAct. En ALFWorld, el modelo base GPT-4 obtuvo:
GPT-4 + ReAct
41.24
mientras que el modelo pequeño con ATG obtuvo:
Llama 3 8B + ATG
63.65
En WebShop, el modelo base GPT-4 alcanzó:
GPT-4 + ReAct
64.34
y Llama 3 8B con ATG alcanzó:
Llama 3 8B + ATG
68.36
Estos son los números reportados en el artículo. Las cifras de GPT-4 corresponden a un modelo base con ReAct, por lo que la comparación muestra cuánto puede compensar la estructura la diferencia de tamaño del modelo, y no que un modelo de 8B sea en general más potente que GPT-4.
Por qué esta idea resuena con los ingenieros de software
La estrategia habitual de la industria ha sido escalar modelos, clústeres y presupuestos. ATG plantea cómo organizar el trabajo de manera mejor, lo cual es más una cuestión de ingeniería de software que de aprendizaje automático. Esto recuerda a Git, gráficos de dependencias, sistemas de compilación, programadores de tareas, optimización de compiladores y sistemas distribuidos. La mayoría de los programas dejaron de ser estrictamente secuenciales hace tiempo; los agentes están alcanzando ese nivel.
Un ejemplo concreto: crear un sitio web
Si se pide a un agente que cree un sitio web, uno lineal tiende a generar un plan como este:
Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy
Un planificador al estilo ATG, en cambio, podría generar un árbol de componentes independientes:
Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests
Cada ramificación puede desarrollarse por separado. Si el CSS falla, solo se regenerará el nodo correspondiente al CSS. Parece obvio, pero la mayoría de los agentes actuales no funcionan de esta manera. Los patrones defensivos relacionados se tratan en una arquitectura contra la acumulación de alucinaciones en grafos de agentes.
Cuando un grafo de tareas no vale la pena
La planificación, la simulación y el registro de nodos añaden carga adicional. Para tareas que implican dos o tres llamadas a herramientas, un bucle ReAct simple es más sencillo. El grafo resulta útil cuando las tareas son largas, parcialmente independientes y costosas de reiniciar, y solo si el planificador las descompone de manera adecuada: un grafo deficiente ejecutado eficientemente sigue siendo un plan deficiente.
Puntos clave
- Los bucles lineales permiten que un paso fallido dañe todo lo que sigue, y los transcritos cada vez más extensos amplifican los errores iniciales.