Mi sistema, DiSE, es un auto-optimizador, auto-ensamblador, desarrollador de flujo de trabajo basado en ingeniería de software. Genera artefactos de código testables, los evalúa objetivamente y los evoluciona con el tiempo sin supervisión humana constante. Pero esta es la cosa: ¿No lo hizo el Voyager —ese impresionante robot Minecraft de 2023— generando habilidades reutilizables? ¿Y Toolformer no demostró ya que los LLMs podrían aprender a usar herramientas midiendo resultados? Si ya tenemos agentes que escriben sus propias herramientas y aprenden cuándo usarlas, ¿no hemos resuelto ya el problema de los agentes de IA auto-impulsantes?
Spoiler: No. Y entender por qué importa si estás construyendo algo que necesita funcionar en la producción.
"Esto suena a Voyager pero con más pasos."
Punto justo. Si has estado siguiendo la investigación de agentes impulsados por LLM, probablemente has oído hablar de Voyager (Wang et al., 2023) - el sistema que enseñó a GPT-4 a jugar Minecraft mediante la generación de código reutilizable "habilidades" - y Toolformer (Schick et al., 2023) - que enseñó LLMs para utilizar herramientas mediante la medición de resultados reales. Ambos fueron impresionantes, influyentes y ampliamente citados.
A primera vista, DiSE (Directed Synthetic Evolution) podría parecerse a Voyager + Toolformer con una capa de pintura fresca. Pero eso es como decir que una base de datos de producción es sólo una hoja de cálculo con más pasos.
¿Nuevo en DiSE? Echa un vistazo mi tono del ascensor para el panorama general, a continuación, explorar la serie "Cooking with DiSE": Parte 2 sobre Aprendizajes Graduados y Parte 3 sobre los LLM poco fiables. Este post se centra específicamente en cómo la arquitectura de DiSE difiere de Voyager y Toolformer.
Este post explica lo que Voyager y Toolformer hicieron bien, donde alcanzaron los límites, y por qué el enfoque arquitectónico de DiSE resuelve problemas que ninguno de los dos podría abordar por sí solo.
Dos artículos de 2023 cambiaron la forma en que pensamos sobre los agentes y herramientas de LLM:
La Voyager introdujo una visión crucial:
Los LLM pueden generar sus propias herramientas reutilizables.
En lugar de codificar cada acción en Minecraft, Voyager usó GPT-4 para escribir funciones sobre la marcha. Cada acción exitosa se convirtió en una habilidad reutilizable almacenada en una base de datos vectorial. El prompt era explícito:
"Tu función será reutilizada para construir funciones más complejas. Por lo tanto, deberías hacerla genérica y reutilizable".
Esto era importante. Por primera vez, un sistema agente trató la generación de herramientas como Ingeniería de software real La Voyager mostró que los agentes podían:
Y funcionó en Minecraft, con GPT-4.
Toolformer (Schick et al., 2023) adoptaron un enfoque diferente. En lugar de generar herramientas, enseñó LLMs cuándo llamar a las herramientas existentes.
El bit inteligente: Toolformer generó sus propios datos de entrenamiento.
Esto creó modelos que aprendieron el uso de herramientas de resultados objetivos Una API de calculadora que devuelve la respuesta correcta es mejor que una que no lo hace - no se necesita juicio LLM.
DiSE toma información de ambos documentos, pero aborda sus lagunas:
Desde la Voyager:
De Toolformer:
La genealogía de DiSE:
Piensa en DiSE como el nieto de ReAct, Reflexión, Toolformer y Voyager. Cada antepasado contribuyó con algo crucial:
graph TB
ReAct[ReAct 2022:<br/>Reason + Act<br/>Step-by-step thinking] --> DiSE
Reflexion[Reflexion 2023:<br/>Self-critique loops<br/>Try → Reflect → Retry] --> DiSE
Toolformer[Toolformer 2023:<br/>Learn from outcomes<br/>Self-generated training data] --> DiSE
Voyager[Voyager 2023:<br/>Generate reusable tools<br/>Code as memory] --> DiSE
DiSE[DiSE 2024:<br/>Directed Synthetic Evolution]
DiSE --> G[Generate tools with tests]
DiSE --> E[Evaluate objectively]
DiSE --> M[Mutate and improve]
DiSE --> S[Store with usage stats]
DiSE --> R[Retrieve and reuse]
DiSE --> C[Tiered execution]
style ReAct stroke:#8b5cf6,stroke-width:2px
style Reflexion stroke:#ec4899,stroke-width:2px
style Toolformer stroke:#f59e0b,stroke-width:2px
style Voyager stroke:#ef4444,stroke-width:2px
style DiSE stroke:#10b981,stroke-width:3px
La herencia:
Lo que DiSE añade:
Toolformer demostró que podía entrenar modelos para usar herramientas midiendo resultados reales. Voyager demostró que los agentes podían construir sus propias bibliotecas de herramientas. La reflexión demostró que los bucles de reflexión funcionan. ReAct demostró que el razonamiento estructurado ayuda.
DiSE pregunta: ¿Qué pasa si combinamos todas estas ideas, pero lo hicimos lo suficientemente barato para funcionar en la producción y lo suficientemente inteligente como para mejorarse con el tiempo?
Y sí, hay una pizca de la arquitectura REST de Roy Fielding allí también - las herramientas son recursos estatales con URIs, metadatos y versiones. Cada herramienta es direccionable, cacheable, y puede ser compuesta con otras. El registro de herramientas no es sólo una base de datos vectorial; es una tienda RESTful donde los recursos (herramientas) tienen estado (estadísticas de uso, métricas de rendimiento, historial de versiones) que influye en cómo se recuperan y evolucionan.
Eso no es entrenamiento, no es generación única. evolución dirigida.
graph TB
subgraph Voyager["Voyager (2023)"]
A[GPT-4] --> B[Generate Code]
B --> C[Execute in Minecraft]
C --> D{Success?}
D -->|Yes| E[Store with embedding]
D -->|No| F[GPT-4 suggests fix]
F --> B
E --> G[Vector DB]
G --> H[Future retrieval]
H --> A
end
style A stroke:#ef4444,stroke-width:3px
style F stroke:#ef4444,stroke-width:3px
note1[All reasoning flows through GPT-4]
note1 -.-> A
¿Ves el problema? Cada decisión - planificación, evaluación, depuración, composición - pasa por el mismo modelo de frontera. Cuando se necesita brillo en cada paso, se necesita GPT-4 (o equivalente) en todas partes.
La Voyager no solo usaba GPT-4 para la generación de código, sino que confiaba en GPT-4 para:
Cuando el modelo hace todo, tiene que ser brillante a nivel de frontera cada vez.
Es precisamente por eso que la Voyager no escaló más allá de Minecraft y es por eso que ejecutarla en producción costaría una fortuna.
Digamos que quieres ejecutar un sistema al estilo Voyager para tareas del mundo real:
Ahora agregue consultas de recuperación, intentos de composición, ciclos de depuración. Usted está viendo fácilmente cientos de dólares para un solo agente para construir una biblioteca de habilidades moderadas.
Para comparar, esto es lo que podría costar un enfoque escalonado:
Tarea Voyager (GPT-4) DiSE (Tirado) Ahorros |------|-----------------|---------------|---------| Triage/ruteo $0.05 $0.001 (Llama 3.1 8B) 98% Generación inicial $0.05 $0.002 (Qwen 2.5 Coder) 96% Evaluación $0.05 $0 (pruebas estáticas) 100% Escalación (10%) $0,05 $0,05 (GPT-4o) 0% | Promedio por tarea | $0.20 | $0.016 | 92% |
Cuando sólo se llama al modelo caro para problemas realmente difíciles, la economía cambia dramáticamente.
La Voyager, Toolformer y Reflexión no fueron fallas. Simplemente alcanzaron el techo técnico y económico de su momento.
Tres limitaciones bloquearon el progreso en 2023:
Limitación (2023) Consecuencia Lo que cambió (2024-2025) |-------------------|-------------|--------------------------| GPT-4 fue el único motor de razonamiento confiable Un modelo tenía que hacer todo Las pilas de modelo de nivel - GPT-4o + Qwen + DeepSeek + Llama Las incrustaciones locales eran débiles o no utilizadas La recuperación era cara BGE / Ártico / MiniLM en GPUs consumidor Ningún arnés de evaluación estructurado LLM juzgado LLM LLM ahora ejecutar código limpiamente vía containerizzate exec
Así que la Voyager y Toolformer no pudieron evolucionar.
Sólo podían llamar a los modelos o a los modelos afinados. No podían distribuir la cognición a través de un sistema. No podían aplicar presión de selección.
Ellos resolvieron el problema. "¿Podemos?" pregunta.
DiSE resuelve la "¿Cómo seguimos mejorando?" pregunta.
No porque sea más inteligente que Wang o Schick, sino porque el hardware, las herramientas y la economía finalmente se han puesto al día.
Esto es un problema de ingeniería. Y la ingeniería es siempre una cuestión de tiempo.
La idea clave detrás de DiSE es simple pero profunda:
La estructura reemplaza la brillantez.
En lugar de esperar que un modelo haga todo a la perfección, DiSE distribuye el problema a través de un sistema de orquestación. No asume que los modelos "saben codificar". presión, retroalimentación y memoria por lo que los modelos pueden mejorar el código iterativamente en lugar de generarlo perfectamente en el primer intento.
graph TB
subgraph DiSE["DiSE (Distributed System)"]
A[Triage Agent] -->|Easy| B[Fast Model - Qwen/Llama]
A -->|Hard| C[Strong Model - GPT-4o]
B --> D[Test Suite]
C --> D
D -->|Pass| E[Structured Registry]
D -->|Fail| F{Worth escalating?}
F -->|Yes| G[Optimizer Agent]
F -->|No| H[Mark as failed]
G --> I[Mutation Pipeline]
I --> D
E --> J[RAG with usage stats]
J --> K[Clustering & reranking]
K --> A
end
style D stroke:#10b981,stroke-width:3px
style E stroke:#3b82f6,stroke-width:3px
style K stroke:#8b5cf6,stroke-width:3px
note2[Most tasks never hit expensive models]
note2 -.-> B
La diferencia es marcada:
Capacidad Voyager DiSE |------------|---------|------| Generación de código GPT-4 Evaluación juicio GPT-4 Pruebas no LLM, métricas Reutilización de herramientas Incrusta sólo Registro con metadatos + etiquetas + estadísticas de uso Mejora GPT-4 sugiere soluciones de escalada y mutación tuberías Memoria Vector DB RAG + agrupación + seguimiento de la evolución Composición Planes GPT-4 Planificación gráfica de flujo de trabajo Control de costes Ninguno Priorización + lógica de retroceso
Porque cada unidad de código generado se trata como un artefacto, no una respuesta rápida.
No es juzgado por "¿se ve bien esto?" - es juzgado por:
Un LLM barato (Qwen 2.5 Coder 7B, Llama 3.1 8B) puede generar cinco variantes. Las pruebas seleccionan las mejores. Un modelo más fuerte sólo se involucra cuando fallan las más débiles.
Con el tiempo, el sistema aprende qué modelos son buenos para qué dominios. implementación de búsqueda semántica - no necesitas el modelo más grande cuando tienes la arquitectura adecuada.
El proceso de refinamiento se convierte en evolucionaria, no autorregresiva.
Digamos que quieres que tu agente implemente una clasificación eficiente.
Enfoque de la Voyager:
Enfoque DiSE:
El modelo barato puede explorar el espacio de solución. Las pruebas hacen la selección. El modelo caro sólo se involucra si las 5 variantes fallan.
He estado experimentando con principios similares en El sistema RAG de mi blog y características de inteligencia semántica. El patrón es consistente:
Utilice el modelo más grande para las decisiones de arquitectura, no para la ejecución.
Cuando construí el controlador de enlace roto Con la búsqueda semántica, no usé GPT-4 para comprobar cada enlace.
La costosa inteligencia está en el diseño, no en la ejecución.
Cada sistema hace una pregunta diferente:
Toolformer pregunta:
¿Puede un LLM aprender a usar herramientas midiendo qué llamadas de herramientas realmente ayudan?
Voyager pregunta:
¿Puede un LLM generar código reutilizable que ayude en tareas futuras?
DiSE pregunta:
¿Puede un sistema generar herramientas, evaluarlas objetivamente, evolucionarlas sobre la base de resultados reales, y hacer todo esto con la suficiente eficiencia para funcionar en la producción?
Toolformer probado trabajos de aprendizaje basados en los resultados. Demostrado el Voyager herramientas generadas pueden ser reutilizadas. Prueba DiSE herramientas pueden evolucionar continuamente sin romper el banco.
Toolformer es tiempo de formación. Voyager es flash. DiSE es infraestructura.
Uno muestra que puedes aprender de los resultados. Uno muestra que puedes generar herramientas. El otro construye maquinaria para la evolución continua.
Si usted está construyendo sistemas alimentados por LLM hoy en día, el enfoque de DiSE sugiere:
No generes código y esperes que funcione. Escribe pruebas que definan "obras". mi Entity Framework migraciones - las pruebas se ejecutan, o no, no se necesita juicio LLM.
Recargue tareas simples a modelos baratos. Reserve modelos caros para problemas realmente difíciles. Su billetera se lo agradecerá.
Almacenar no sólo el código, sino:
Estos metadatos se convierten en datos de entrenamiento para su lógica de enrutamiento.
No espere la perfección en el primer intento. Generar variantes, probarlos, mantener a los ganadores, mutar los buenos pero no perfectos.
Así es como acerco el desarrollo en este blog - iterar en público, Aprender del tráfico real, mejorar en función del uso real.
La diferencia entre el Voyager y el DiSE no es sólo sobre el costo. lo que sucede cuando las cosas fallan.
En la Voyager, el fracaso significa:
En DiSE, el fallo desencadena:
El sistema se pone más inteligente sobre lo que no sabe.
No creo que vayamos a ver que los sistemas puros de "modelo único lo hace todo" ganen en la producción.
En su lugar, veremos sistemas híbridos como DiSE:
Estamos viendo este patrón por todas partes:
La magia no es tener un modelo brillante. modelo correcto en el momento adecuado con la contexto adecuado.
La Voyager era un faro que mostraba que los agentes podían aprender generando código.
El siguiente paso no fue más estimulante, ese enfoque está llegando a sus límites.
El siguiente paso es evolución sintética dirigida:
DiSE no está tratando de ser más inteligente en un solo disparo. Está tratando de ser mejor en el siguiente Shot.
Esa diferencia es donde comienza la evolución.
Y a diferencia de la evolución biológica, no tenemos que esperar millones de años para ver resultados.
Papeles:
En este blog:
Herramientas:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.