# "¿No es DiSE sólo Voyager?" - ¿Por qué la estructura supera a la brillantez 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. ## Introducció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](https://arxiv.org/abs/2305.16291) (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](https://arxiv.org/abs/2302.04761) (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](/blog/elevatorpitch) para el panorama general, a continuación, explorar la serie "Cooking with DiSE": [Parte 2 sobre Aprendizajes Graduados](/blog/blog-article-cooking-dise-part2-apprenticeships) y [Parte 3 sobre los LLM poco fiables](/blog/blog-article-cooking-dise-part3-untrustworthy-gods). 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. [TOC] ## Lo que hizo bien Voyager y Toolformer Dos artículos de 2023 cambiaron la forma en que pensamos sobre los agentes y herramientas de LLM: ### Voyager: Los agentes pueden generar herramientas 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: - Construir una biblioteca creciente de habilidades con el tiempo - Componer habilidades simples en comportamientos complejos - Evite el olvido catastrófico a través de la recuperación basada en incrustación Y funcionó en Minecraft, con GPT-4. ### Toolformer: Los agentes pueden aprender cuándo usar herramientas [Toolformer](https://arxiv.org/abs/2302.04761) (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. 1. Insertar llamadas de herramientas potenciales en texto ("¿tal vez debería usar una calculadora aquí?") 2. En realidad ejecutar esas herramientas 3. Mantenga los ejemplos donde las herramientas ayudaron, descarte donde no lo hicieron 4. Afinar los ejemplos de éxito 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. ### Cómo DiSE combina ambos (y va más allá) DiSE toma información de ambos documentos, pero aborda sus lagunas: **Desde la Voyager:** - • Generar artefactos de código reutilizables - • Almacénelos para su recuperación futura - Pero añádase: Los arneses de prueba objetivo, no sólo "¿funciona en Minecraft?" - Pero añádase: Modelos alineados en lugar de GPT-4 para todo - Pero añádase: Mutación y evolución, no sólo almacenamiento **De Toolformer:** - • Aprender de los resultados objetivos - • Generar datos de capacitación automáticamente - Pero añádase: Evolución del tiempo de ejecución, no sólo aprendizaje del tiempo de entrenamiento - Pero añádase: Generar las herramientas en sí, no sólo aprender a llamarlos - Pero añádase: El ciclo de vida completo - las herramientas pueden ser mejoradas, no sólo usadas **La genealogía de DiSE:** Piensa en DiSE como el nieto de ReAct, Reflexión, Toolformer y Voyager. Cada antepasado contribuyó con algo crucial: ```mermaid graph TB ReAct[ReAct 2022:
Reason + Act
Step-by-step thinking] --> DiSE Reflexion[Reflexion 2023:
Self-critique loops
Try → Reflect → Retry] --> DiSE Toolformer[Toolformer 2023:
Learn from outcomes
Self-generated training data] --> DiSE Voyager[Voyager 2023:
Generate reusable tools
Code as memory] --> DiSE DiSE[DiSE 2024:
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:** - **Reactuar** → Razonamiento estructurado con bucles de observación de acción - **Reflexión** → Auto-mejoramiento a través de la reflexión (pero LLM se juzga a sí mismo) - **Toolformer** → Aprender de los resultados reales, no sólo indica - **Voyager** → Generar y almacenar artefactos de código reutilizables **Lo que DiSE añade:** - Arneses de ensayo objetivos (no autojuzgamiento LLM) - Evolución del tiempo de ejecución (no sólo el tiempo de entrenamiento) - Ejecución de modelos por niveles (más barato → caro sólo cuando es necesario) - Ciclo de vida completo de la herramienta (nacimiento → mutación → herencia → muerte) - bucles de retroalimentación de optimización de costes - Registro de herramientas estatales (un poco de la arquitectura REST de Fielding - herramientas como recursos abordables con estado) 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**. ### La arquitectura del Voyager ```mermaid 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. ## Lo que hizo retroceder a la Voyager La Voyager no solo usaba GPT-4 para la generación de código, sino que confiaba en GPT-4 para: - **Planificación** - Desglosando los objetivos de alto nivel en subtareas - **Evaluación** - Decidir si una habilidad funcionó correctamente - **Descomposición** - La determinación de las capacidades existentes para combinar - **Nombre** - Crear identificadores descriptivos para el almacenamiento - **Selección** - Elegir la habilidad correcta de las incrustaciones - **Juicio de calidad** - Decidir lo que es "suficientemente bueno" 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. ### El problema de los costos Digamos que quieres ejecutar un sistema al estilo Voyager para tareas del mundo real: - GPT-4 Turbo: ~0,01 dólares por tokens de entrada de 1K, ~0,03 dólares por tokens de salida de 1K - Generación típica de habilidades: entrada ~2K + salida 1K = $0,05 - 100 habilidades con 3 intentos de reintentar cada una = ~300 llamadas = **$15** - Eso es sólo la compilación inicial de la biblioteca 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. ## ¿Por qué el DiSE no era posible en 2023 (pero es ahora) 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. ## Diferencia del núcleo de DiSE 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. ### DiSE Architecture ```mermaid 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 ## Por qué DiSE no necesita GPT-4 (la mayoría de las veces) 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: - ¿Corre? - ¿Resuelve la tarea? - ¿Es más rápido que antes? - ¿Pasa la suite de pruebas? 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](/blog/semantic-search-with-onnx-and-qdrant) - no necesitas el modelo más grande cuando tienes la arquitectura adecuada. El proceso de refinamiento se convierte en **evolucionaria, no autorregresiva**. ### Ejemplo real: Algoritmos de clasificación Digamos que quieres que tu agente implemente una clasificación eficiente. **Enfoque de la Voyager:** 1. GPT-4 genera la implementación de QuickSort 2. GPT-4 evalúa si "parece correcto" 3. GPT-4 lo ejecuta en el medio ambiente 4. Si falla, GPT-4 sugiere correcciones 5. Costo: ~ 0,20-0,30 dólares por intento **Enfoque DiSE:** 1. Triage: "implementar la clasificación eficiente" → enrutado a nivel general 2. Qwen 2.5 Coder 7B genera 5 variantes (QuickSort, MergeSort, HeapSort, variaciones) 3. La suite de pruebas ejecuta los 5 contra: - Pruebas de corrección (salida ordenada, estabilidad, cajas de bordes) - Parámetros de rendimiento (tiempo, memoria) - Análisis estático (complejidad, calidad del código) 4. Variante de mejor rendimiento entra en el registro con métricas 5. Costo: ~0,002-0,005 dólares 6. Las futuras solicitudes de "ordenación" recuperan esta implementación probada 7. Si alguien más tarde necesita "ordenación estable", el optimizador puede mutar el código existente en lugar de empezar desde cero. 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. ## Lo que esto significa en la práctica He estado experimentando con principios similares en [El sistema RAG de mi blog](/blog/rag-primer) y [características de inteligencia semántica](/blog/semantidintelligence). 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](/blog/the-war-on-404) Con la búsqueda semántica, no usé GPT-4 para comprobar cada enlace. 1. Utiliza simples solicitudes HEAD para comprobar la validez del enlace (sin LLM) 2. Vuelve a la búsqueda semántica cuando se rompen los enlaces (modelo ONNX) 3. Sólo implica un LLM si la búsqueda semántica falla (raramente necesaria) La costosa inteligencia está en el diseño, no en la ejecución. ## La pregunta clave 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. ## Consecuencias prácticas Si usted está construyendo sistemas alimentados por LLM hoy en día, el enfoque de DiSE sugiere: ### 1. Construir la evaluación en primer lugar No generes código y esperes que funcione. Escribe pruebas que definan "obras". [mi Entity Framework migraciones](/blog/efmigrationstherightway) - las pruebas se ejecutan, o no, no se necesita juicio LLM. ### 2. Usar niveles agresivamente Recargue tareas simples a modelos baratos. Reserve modelos caros para problemas realmente difíciles. Su billetera se lo agradecerá. ### 3. Track What Works Almacenar no sólo el código, sino: - ¿Para qué se generó? - ¿Qué modelo lo creó? - ¿Qué tan bien funcionó - Con qué frecuencia se reutiliza Estos metadatos se convierten en datos de entrenamiento para su lógica de enrutamiento. ### 4. Abrazar la evolución 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](/blog/usingumamidataforwebsitestats), mejorar en función del uso real. ## Por qué la estructura importa más de lo que crees 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: - Pídale a GPT-4 que depura - Espero que entienda el problema. - Pagar $0.05 por el privilegio En DiSE, el fallo desencadena: - Análisis de errores estructurados (lo que falló, por qué, lo que se esperaba) - Generación de variantes a partir de alternativas de trabajo - La escalada sólo si el problema es realmente novedoso - Aprender para futuros fracasos similares El sistema se pone **más inteligente sobre lo que no sabe**. ## El futuro es híbrido 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: - Modelos baratos para patrones comunes - Modelos caros para problemas novedosos - Lógica no LLM para todo lo demás (pruebas, métricas, validación) - Sistemas de memoria que realmente aprenden de los resultados Estamos viendo este patrón por todas partes: - [Sistemas RAG](/blog/rag-architecture) combinación de recuperación + generación - [Flujos de trabajo de agentes múltiples](/blog/workflowsystem-part1-introduction) con componentes especializados - [Búsqueda semántica](/blog/semantic-search-in-action) usando incrustaciones + recalificación La magia no es tener un modelo brillante. **modelo correcto en el momento adecuado** con la **contexto adecuado**. ## Conclusión 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**: - Variación deliberada - Evaluación objetiva - Sucesiones sistemáticas - Aprendizaje estructural 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. --- ## Por qué DiSE es diferente - **No necesita afinación.** - Funciona con cualquier LLM a través de API - **No necesita GPT-4 para todo.** - La ejecución por niveles reduce los costos - **No alucina la evaluación** - Arneses de ensayo objetivos, no juicio LLM - **No tira el código.** - Cada artefacto es almacenado, versionado, rastreado - **No olvida el trabajo pasado.** - RAG + estadísticas de uso = memoria institucional - **No teme el fracaso.** - La utiliza como presión de selección para la evolución --- ## Lectura adicional **Papeles:** - [Voyager: Un agente con cuerpo abierto con modelos de lenguaje grande](https://arxiv.org/abs/2305.16291) - El papel original - [ToolFormer](https://arxiv.org/abs/2302.04761) - Enseñar a los LLM a utilizar herramientas - [Reactuar](https://arxiv.org/abs/2210.03629) - Razonamiento + Patrón de actuación - [Árbol de los Pensamientos](https://arxiv.org/abs/2305.10601) - Solución deliberada de problemas **En este blog:** - [Construcción de un sistema RAG](/blog/rag-primer) - Recuperación híbrida + arquitectura de generación - [Búsqueda semántica con ONNX y Qdrant](/blog/semantic-search-with-onnx-and-qdrant) - Incrustaciones sin APIs costosas - [La guerra del 404](/blog/the-war-on-404) - Enfoque por niveles para la fijación de enlaces - [Uso de Ollama para los LLM locales](/blog/reanimation) - Self-hosting modelos más pequeños - [Construyendo un Abogado Serie GPT](/blog/building-a-lawyer-gpt-for-your-blog-part1) - Serie multi-partes sobre RAG + LLMs **Herramientas:** - [Ollama](https://ollama.ai/) - Ejecutar Llama, Qwen y otros modelos locales - [LiteLLM](https://github.com/BerriAI/litellm) - API unificada para más de 100 proveedores de LLM - [LangChain](https://www.langchain.com/) - Marco para aplicaciones LLM (aunque tiendo a evitar marcos pesados)