This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Monday, 24 November 2025
Mijn systeem, DiSE, is een zelf-optimaliserende, zelf-assemblerende, software engineering geaarde workflow bouwer. Het genereert testbare code artefacten, evalueert ze objectief, en evolueert ze in de loop van de tijd zonder constante menselijke begeleiding. Maar hier is het ding: heeft Voyager niet dat indrukwekkende Minecraft bot van en-klaar doen dit door het genereren van herbruikbare vaardigheden? En heeft Toolformer al bewezen dat LLMs kunnen leren om tools te gebruiken door het meten van resultaten? Als we al agenten die hun eigen tools schrijven en leren wanneer ze te gebruiken, hebben we niet al opgelost het probleem van zelf-verbeterende AI-agenten?
Spoiler: Nee. En begrijpen waarom het belangrijk is als je iets bouwt dat in productie moet draaien.
"Dit klinkt als Voyager maar met meer stappen."
Als je LLM-gedreven agent onderzoek hebt gevolgd, heb je waarschijnlijk gehoord van Voyager (Wang et al., 2023) - het systeem dat GPT-4 leerde Minecraft spelen door herbruikbare code "vaardigheden" te genereren - en Gereedschapsvormer (Schick et al., 2023) - die LLM's leerde om tools te gebruiken door het meten van de werkelijke resultaten. Beide waren indrukwekkend, invloedrijk en breed geciteerd.
Op het eerste gezicht lijkt DiSE (Directed Synthetic Evolution) misschien op Voyager + Toolformer met een frisse laag verf. Maar dat is hetzelfde als zeggen dat een productiedatabase slechts een spreadsheet is met meer stappen. Het onderscheid is belangrijk als je om schaal, kosten, en eigenlijk iets verzendt.
Nieuw bij DiSE? Check out mijn lift pitch voor het grote plaatje, verken dan de serie "Cooking with DiSE": Deel 2 over afgestudeerde leerlingplaatsen en Deel 3 over onbetrouwbare LLM's. Dit artikel richt zich specifiek op hoe DiSE's architectuur verschilt van Voyager en Toolformer.
Dit bericht legt uit wat Voyager en Toolformer goed hadden, waar ze grenzen raakten, en waarom DiSE's architecturale aanpak problemen oplost die ook niet alleen aangepakt konden worden.
Twee papers uit 2023 veranderden hoe we denken over LLM agenten en tools:
Voyager introduceerde een cruciaal inzicht:
LLM's kunnen hun eigen herbruikbare tools genereren.
In plaats van elke actie in Minecraft hard te coderen, gebruikte Voyager GPT-4 om functies op de vlieg te schrijven. Elke succesvolle actie werd een herbruikbare vaardigheid opgeslagen in een vector database. De prompt was expliciet:
"Uw functie wordt hergebruikt voor het bouwen van complexere functies. Daarom moet u het generiek en herbruikbaar maken."
Dit was belangrijk. Voor het eerst, een agent systeem behandeld gereedschap generatie als echte software-engineering Voyager liet zien dat agenten:
Het werkte in Minecraft, met GPT-4.
Gereedschapsvormer (Schick et al., 2023) nam een andere aanpak. In plaats van het genereren van tools, leerde het LLM's wanneer bestaande tools moeten worden aangeroepen.
Het slimme stukje: Toolformer heeft zijn eigen trainingsgegevens gegenereerd.
Dit creëerde modellen die geleerd tool gebruik van objectieve resultaten in plaats van menselijke annotatie. Een rekenmachine API die het juiste antwoord teruggeeft is beter dan een die dat niet doet - geen LLM oordeel nodig.
DiSE haalt inzichten uit beide papers maar pakt hun hiaten aan:
Van Voyager:
Van Toolformer:
DiSE's genealogie:
Denk aan DiSE als het kleinkind van ReAct, Reflexion, Toolformer en Voyager. Elke voorvader droeg iets cruciaals bij:
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
De erfenis:
Wat DiSE toevoegt:
Toolformer bewees dat je modellen kon trainen om tools te gebruiken door echte uitkomsten te meten. Voyager bewees dat agenten hun eigen gereedschapsbibliotheken konden bouwen. Reflexion bewees reflectie loops werk. ReAct bleek gestructureerd redeneren te helpen.
DiSE vraagt: Wat als we al deze inzichten combineerden, maar het goedkoop genoeg maakten om in productie te lopen en slim genoeg om zichzelf na verloop van tijd te verbeteren?
En ja, er is een vleugje Roy Fielding's REST architectuur daar ook - tools zijn stateful resources met URI's, metadata en versiering. Elke tool is adresseerbaar, cacheable en kan worden samengesteld met anderen. Het gereedschapsregister is niet alleen een vectordatabase; het is een RESTful store waar resources (tools) status hebben (gebruiksstatistieken, performance metrics, versiegeschiedenis) die invloed heeft op hoe ze worden opgehaald en geëvolueerd.
Dat is geen training, dat is geen eenmalige generatie. gerichte evolutie.
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
Zie je het probleem? Elke beslissing - planning, evaluatie, debugging, compositie - gaat door hetzelfde grensmodel. Wanneer je bij elke stap briljantheid nodig hebt, heb je overal GPT-4 (of equivalent) nodig.
Voyager gebruikte niet alleen GPT-4 voor code generatie. Het vertrouwde op GPT-4 voor:
Als het model alles doet, moet het altijd briljant zijn.
Daarom ging de Voyager niet verder dan Minecraft... en daarom zou het produceren een fortuin kosten.
Stel dat je een Voyager-systeem wilt gebruiken voor echte taken.
Voeg nu zoekopdrachten, compositie pogingen, debugging cycli. Je bent gemakkelijk op zoek naar honderden dollars voor een enkele agent om een matige vaardigheid bibliotheek te bouwen.
Ter vergelijking, hier is wat een gedifferentieerde aanpak zou kunnen kosten:
Taak Voyager (GPT-4) DiSE (Tiered) Besparingen |------|-----------------|---------------|---------| Triage/routing - $0.05 - $0.001 (Llama 3.1 8B) Initial generation (Qwen 2.5 Coder) ($0.05) ($0.002 (Qwen 2.5 Coder)) Evaluatie $0.05 $0 (static tests) Escalatie in één keer $0.05 $0.05 (GPT-4o) | Gemiddelde per taak | $0.20 | $0.016 | 92% |
Wanneer je alleen het dure model voor echt harde problemen noemt, verandert de economie dramatisch.
Voyager, Toolformer en Reflexion waren geen mislukkingen. Ze raakten gewoon het technische en economische plafond van hun moment.
Drie beperkingen geblokkeerde vooruitgang in 2023:
Wat is er veranderd? (2024.2025) |-------------------|-------------|--------------------------| GPT-4 was het enige betrouwbare redeneermotortje Eén model moest alles doen . . Ge Tiered model stacks - GPT-4o + Qwen + DeepSeek + Llama Locale inbeddingen waren zwak of ongebruikt Retrieval was duur BGE / Arctic / MiniLM op de consument GPU's LLM beoordeeld LLM LLM's draaien nu code schoon via containerized exec
Dus Voyager en Toolformer konden niet evolueren.
Ze konden alleen modellen of fine-tune modellen noemen. Ze konden geen cognitie verspreiden over een systeem. Ze konden geen selectiedruk uitoefenen.
Zij hebben de "Kunnen we dat?" Vraag.
DiSE lost de "Hoe blijven we verbeteren?" Vraag.
Niet omdat ik slimmer ben dan Wang of Schick - maar omdat de hardware, gereedschap en economie eindelijk ingehaald.
Dit is een technisch probleem. En techniek is altijd een kwestie van timing.
Het belangrijkste idee achter DiSE is eenvoudig maar diepgaand:
De structuur vervangt schittering.
In plaats van te verwachten dat één model alles perfect doet, verspreidt DiSE het probleem over een orkestratiesysteem. Het gaat er niet van uit dat modellen "weten hoe te coderen" zijn. In plaats daarvan creëert het druk, feedback en geheugen dus modellen kunnen code iteratief verbeteren in plaats van het perfect te genereren bij de eerste poging.
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
Het verschil is grimmig:
Voyager DiSE |------------|---------|------| Codegeneratie GPT-4 Geplaatste multi-LLM-pijpleiding Evaluatie GPT-4 oordeel Niet-LLM-tests, metrics Inbeddingen alleen inbeddingen met metadata + tags + gebruiksstatistieken Verbetering GPT-4 stelt fixes voor Escalatie en mutatieleidingen Geheugen Vector DB . . . . . + clustering + evolution tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . De samenstelling van de GPT-4 plannen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kostenbeheersing Geen Prioritering + terugvallogica
Omdat elke eenheid van gegenereerde code wordt behandeld als een artefact, geen snelle reactie.
Het wordt niet beoordeeld door "ziet dit er goed uit?" - het wordt beoordeeld door:
Een goedkope LLM (Qwen 2.5 Coder 7B, Llama 3.1 8B) kan vijf varianten genereren. Tests selecteren het beste. Een sterker model raakt alleen betrokken als zwakkere falen.
Na verloop van tijd leert het systeem welke modellen goed zijn voor welke domeinen. semantische zoekimplementatie - je hebt het grootste model niet nodig als je de juiste architectuur hebt.
Het verfijningsproces wordt evolutionair, niet autoregressief.
Stel dat je wilt dat je agent efficiënt sorteert.
Voyager benadering:
DiSE-benadering:
Het goedkope model kan de oplossingsruimte verkennen. De tests doen de selectie. Het dure model wordt alleen betrokken als alle 5 varianten falen.
Ik heb geëxperimenteerd met soortgelijke principes in het RAG-systeem van mijn blog en semantische inlichtingenfuncties. Het patroon is consistent:
Gebruik het grootste model voor architectuurbeslissingen, niet voor uitvoering.
Toen ik bouwde de breuklink handler Met semantische fallback heb ik niet elke link met GPT-4 gecontroleerd.
De dure intelligentie zit in het ontwerp, niet in de uitvoering.
Elk systeem stelt een andere vraag:
Toolformer vraagt:
Kan een LLM leren wanneer ze tools moet gebruiken door te meten welke tool calls eigenlijk helpen?
Voyager vraagt:
Kan een LLM herbruikbare code genereren die helpt bij toekomstige taken?
DiSE vraagt:
Kan een systeem instrumenten genereren, ze objectief evalueren, ze ontwikkelen op basis van echte resultaten, en dit alles efficiënt genoeg doen om in productie te werken?
Toolformer bewezen Op resultaten gebaseerde leerwerkzaamheden. Voyager heeft bewezen Generated tools kunnen worden hergebruikt. DiSE bewijst tools kunnen continu evolueren zonder de bank te breken.
Toolformer is trainingstijd. Voyager is flits. DiSE is infrastructuur.
Men laat zien dat je kunt leren van uitkomsten. Men laat zien dat je tools kunt genereren. De andere bouwt machines voor continue evolutie.
Als je vandaag LLM-aangedreven systemen bouwt, suggereert de DiSE-aanpak:
Maak geen code en hoop dat het werkt. Schrijf tests die "werken" definiëren. migraties in het kader van mijn entiteit Geen LLM-oordeel nodig.
Route eenvoudige taken naar goedkope modellen. Reserveer dure modellen voor echt harde problemen. Uw portemonnee zal u bedanken.
Niet alleen de code opslaan, maar:
Deze metadata worden trainingsgegevens voor uw routing logica.
Verwacht geen perfectie bij de eerste poging. Genereer varianten, test ze, houd de winnaars, muteren de goede maar-niet-perfecte degenen.
Dit is hoe ik de ontwikkeling op deze blog - itereren in het openbaar, leren van het echte verkeer, verbeteren op basis van het werkelijke gebruik.
Het verschil tussen Voyager en DiSE gaat niet alleen over kosten. Wat gebeurt er als dingen falen?.
In Voyager betekent falen:
In DiSE, falen triggers:
Het systeem krijgt slimmer over wat het niet weet.
Ik denk niet dat we pure "single model does everything" systemen gaan zien winnen in de productie. De economie werkt niet, en de falende modi zijn te ondoorzichtig.
In plaats daarvan zien we hybride systemen zoals DiSE:
We zien dit patroon overal:
De magie is niet in het hebben van een briljant model. rechts model op het juiste moment met de juiste context.
Voyager was een baken, waaruit bleek dat agenten konden leren door code te genereren.
De volgende stap was niet meer aansporing. Die aanpak is het bereiken van zijn grenzen.
De volgende stap is gerichte synthetische evolutie:
DiSE probeert niet slimmer te zijn in één schot. Het probeert beter te zijn op de volgende Geschoten.
Dat verschil is waar evolutie begint.
En in tegenstelling tot biologische evolutie, hoeven we geen miljoenen jaren te wachten om resultaten te zien.
Papieren:
Op deze blog:
Hulpmiddelen:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.