Mitt system, DiSE, är en självoptimerande, självmontering, programvaruteknik jordade arbetsflöde byggare. Det genererar testerbara kod artefakter, utvärderar dem objektivt, och utvecklar dem över tid utan ständig mänsklig övervakning. Men här är grejen: gjorde inte Voyager – att imponerande Minecraft bot från 2023 – redan gör detta genom att generera återanvändningsbara färdigheter? Och inte Toolformer redan bevisa att LLMs kunde lära sig att använda verktyg genom att mäta resultat? Om vi redan har agenter som skriver sina egna verktyg och lära sig när man ska använda dem, har vi inte redan löst problemet med självförbättrande AI-agenter?

Spoiler: Nej. Och förstå varför spelar roll om du bygger något som behöver köras i produktionen.

Inledning

"Det låter som Voyager men med fler steg."

Om du har följt LLM-driven agent forskning, har du förmodligen hört talas om Voyager (Wang et al., 2023) - systemet som lärde GPT-4 att spela Minecraft genom att generera återanvändbar kod "skills" - och Verktygsbildare (Schick et al., 2023) - som lärde LLMs att använda verktyg genom att mäta faktiska utfall. Båda var imponerande, inflytelserika och allmänt citerade.

Vid första anblicken, DiSE (Directed Synthetic Evolution) kan se ut som Voyager + Toolformer med ett nytt lager av färg. Men det är som att säga en produktionsdatabas är bara ett kalkylblad med fler steg. Skillnaden spelar roll om du bryr dig om skala, kostnad, och faktiskt frakta något.

Nytt för DiSE? Kolla in min hiss pitch För den stora bilden, sedan utforska "Cooking with DiSE" serien: Del 2 om utexaminerade lärlingsutbildningar och Del 3 om opålitliga LLM. Detta inlägg fokuserar specifikt på hur DiSE arkitektur skiljer sig från Voyager och Toolformer.

Detta inlägg förklarar vad Voyager och Toolformer fick rätt, var de slog gränser, och varför DiSE arkitektoniska strategi löser problem som varken kunde tackla ensam.

Vad Voyager och verktygsmakare gjorde bra ifrån sig

Två papper från 2023 förändrade hur vi tänker om LLM agenter och verktyg:

Voyager: Agenter kan skapa verktyg

Voyager introducerade en viktig insikt:

LLMs kan generera sina egna återanvändbara verktyg.

Istället för att koda alla åtgärder i Minecraft använde Voyager GPT-4 för att skriva funktioner i farten. Varje lyckad åtgärd blev en återanvändbar skicklighet lagrad i en vektordatabas. Prompten var explicit:

"Din funktion kommer att återanvändas för att bygga mer komplexa funktioner. Därför bör du göra den generisk och återanvändbar."

Detta var viktigt. För första gången, ett agentsystem behandlade verktygsgenerering som verklig programvaruteknik Voyager visade att agenter kunde:

• Bygga ett växande kompetensbibliotek över tid
• Komposiera enkla färdigheter till komplexa beteenden
• Undvik katastrofal glömska genom inbäddning-baserad hämtning

Och det fungerade, liksom, i Minecraft, med GPT-4.

Verktygsbildare: Agenter kan lära sig när de ska använda verktyg

Verktygsbildare (Schick et al., 2023) tog en annan strategi. I stället för att generera verktyg, lärde den LLMs när man ska kalla befintliga verktyg.

Den smarta biten: Toolformer genererade sina egna träningsdata. Det skulle:

1. Infoga potentiella verktygssamtal i text ("kanske ska jag använda en miniräknare här?")
2. Faktiskt köra dessa verktyg
3. Behåll exempel där verktyg hjälpte, kasta där de inte
4. Finjustera de framgångsrika exemplen

Detta skapade modeller som lärde sig verktyg använder från Måluppfyllelse snarare än mänsklig kommentar. En miniräknare API som returnerar rätt svar är bättre än en som inte - ingen LLM bedömning behövs.

Hur DiSE kombinerar båda (och går vidare)

DiSE tar insikter från båda papperen men tar itu med sina luckor:

Från Voyager:

• Skapa återanvändbara kodartefakter
• på Lagra dem för framtida hämtning
• ❌ Men lägg till: Objektiva testselar, inte bara "fungerar det i Minecraft?"
• ❌ Men lägg till: Nivåerade modeller istället för GPT-4 för allt
• ❌ Men lägg till: Mutation och evolution, inte bara lagring

Från verktygsbildare:

• till Lär dig av objektiva resultat
• och generera träningsdata automatiskt
• ❌ Men lägg till: Runtime evolution, inte bara utbildning-tid lärande
• ❌ Men lägg till: Skapa verktygen själva, inte bara lära sig att kalla dem
• ❌ Men lägg till: Full livscykel - verktyg kan förbättras, inte bara användas

DiSE:s släktregister:

Tänk på DiSE som barnbarn till ReAct, Reflexion, Toolformer och Voyager. Varje förfader bidrog med något viktigt:

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

Arvet:

• Återgå till handling → Strukturerat resonemang med verksamhet-observation slingor
• Omflexion → Självförbättring genom reflektion (men LLM dömer sig själv)
• Verktygsbildare → Lär dig från faktiska resultat, inte bara uppmaningar
• Voyager → Skapa och lagra återanvändbara kod artefakter

Vad DiSE tillägger:

• Objektiva testselar (inte LLM-självbedömning)
• Runtime evolution (inte bara träningstid)
• Utförande av stegvis modell (billighet → kostsam endast vid behov)
• Full verktygslivscykel (födelse → mutation → arv → död)
• Kostnadsoptimering feedback loopar
• Stateful tool register (en bit av Fieldings REST arkitektur - verktyg som adresserbara resurser med tillstånd)

Toolformer visade att du kunde träna modeller att använda verktyg genom att mäta verkliga resultat. Voyager bevisade agenter kunde bygga sina egna verktyg bibliotek. Reflexion bevisade reflektion loopar arbete. ReAct visade strukturerade resonemang hjälper.

DiSE frågar: Tänk om vi kombinerade alla dessa insikter, men gjorde det billigt nog att köra i produktion och smart nog att förbättra sig själv med tiden?

Och ja, det finns en skvätt av Roy Fielding's REST arkitektur där också - verktyg är ståtliga resurser med URIs, metadata och versionshantering. Varje verktyg är adresserbart, cacheable, och kan komponeras med andra. Verktygsregistret är inte bara en vektordatabas; det är en RESTful butik där resurser (verktyg) har tillstånd (använd statistik, prestandamått, versionshistorik) som påverkar hur de hämtas och utvecklas.

Det är inte träning, det är ingen engångsgeneration. riktad utveckling.

Voyagers arkitektur

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

Ser du problemet? Varje beslut - planering, utvärdering, felsökning, komposition - går igenom samma gränsmodell. När du behöver briljans i varje steg behöver du GPT-4 (eller motsvarande) överallt.

Vad höll Voyager tillbaka

Voyager använde inte bara GPT-4 för kodgenerering.

• Planering - Att bryta ner mål på hög nivå i deluppgifter
• Utvärdering - Bestämmer om en färdighet fungerade korrekt
• Nedbrytning - Att ta reda på vilka färdigheter som finns att kombinera
• Namngivning - Skapa beskrivande identifierare för lagring
• Urval - Välja rätt skicklighet från inbäddningar
• Kvalitetsbedömning - Bestämmer vad som är "gott nog"

När modellen gör allt måste den vara lysande på gränsnivå varje gång.

Det var därför Voyager inte klättrade bortom Minecraft och det var därför det skulle kosta en förmögenhet.

Kostnadsproblemet

Säg att du vill köra ett Voyager-system för verkliga uppgifter.

• GPT-4 Turbo: ~$0.01 per 1K inmatningspolletter, ~$0.03 per 1K utgångspolletter
• Typisk kompetensgenerering: ~2K ingång + 1K utgång = $0.05
• 100 färdigheter med 3 försök var = ~300 samtal = $15
• Det är bara den första biblioteksbyggnaden.

Lägg till hämtnings frågor, komposition försök, felsökning cykler. Du är lätt att titta på hundratals dollar för en enda agent för att bygga en måttlig skicklighet bibliotek.

För jämförelse, här är vad en stegvis strategi kan kosta:

på uppdrag av Voyager (GPT-4) |------|-----------------|---------------|---------| Tröskelvärde/routing 0.05 $ 0.001 (Llama 3.1 8B) på 98 % Initial generation på $0.05 på $0.002 (Qwen 2.5 Coder) på 96% Utvärdera på $0.05 på $0 (statiska tester) på 100% Olycka (10%) 0.05 $ 0.05 (GPT-4o) 0.0 € 0.05 | Genomsnitt per uppgift | $0.20 | $0.016 | 92% |

När man bara kallar den dyra modellen för verkligt svåra problem förändras ekonomin dramatiskt.

Varför DiSE inte var möjligt 2023 (Men är nu)

Voyager, Toolformer och Reflexion var inga misslyckanden.

Tre begränsningar blockerade framstegen 2023:

på begränsning (2023) på grund av konsekvenserna på vad som förändrades (2024–2025) |-------------------|-------------|--------------------------| GPT-4 var den enda tillförlitliga resonemangsmotorn som en modell var tvungen att göra allt i nivå med modellerna - GPT-4o + Qwen + DeepSeek + Llama Lokala inbäddningar var svaga eller oanvända på att hämta var dyrt / Arktis / MiniLM på konsument GPU:er Det finns ingen strukturerad utvärderingssele på LLM som bedöms som LLM .LLMs kör nu kod på ett rent sätt via containeriserad exec och

Så Voyager och Toolformer kunde inte utvecklas.

De kunde bara kalla modeller eller finjusterade modeller. De kunde inte sprida kognition över ett system. De kunde inte utöva urvalstryck.

De löste "Kan vi?" en fråga.

DiSE löser "Hur fortsätter vi att förbättras?" en fråga.

Inte för att jag är smartare än Wang eller Schicking - utan för att hårdvaran, verktygen och ekonomin äntligen kom ikapp.

Det här är ett ingenjörsproblem. Och ingenjörskonst är alltid en fråga om timing.

DiSE:s kärnskillnad

Nyckelidén bakom DiSE är enkel men djup:

Strukturen ersätter briljansen.

Istället för att förvänta sig att en modell ska göra allt perfekt, distribuerar DiSE problemet över ett orkestreringssystem. Det antar inte modeller "vet hur man kodar". Istället skapar det tryck, återkoppling och minne så modeller kan förbättra kod iterativt snarare än att generera det perfekt på första försöket.

DiSE-arkitektur

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

Skillnaden är skarp:

"Färdighet" Voyager "Dise" |------------|---------|------| "Kodgenerering" (GPT-4) Tierad multi-LLM-rörledning Utvärderad bedömning av GPT-4-bedömning av icke-LLM-tester, mätvärden med metadata + taggar + användningsstatistik på förbättring på GPT-4 föreslår fixas på Escalation & mutation pipelines och Memory på Vector DB på RAG + klusterering + evolutionsspårning på sammansättning på GPT-4 planer på arbetsflödesdiagramplanering på kostnadskontroll ingen prioritering + reservlogik

Varför DiSE inte behöver GPT-4 (För det mesta)

För att varje enhet av genererad kod behandlas som en artefakt, inte ett snabbt svar.

Det bedöms inte av "Ser det här bra ut?" - Det bedöms av:

• Kör den?
• Löser det uppgiften?
• Är det snabbare än förut?
• Klarar den testsviten?

En billig LLM (Qwen 2.5 Coder 7B, Llama 3.1 8B) kan generera fem varianter. Tester väljer det bästa. En starkare modell blir bara involverad när svagare misslyckas.

Med tiden lär sig systemet vilka modeller som är bra för vilka domäner. Semantisk sökning genomförande - Du behöver inte den största modellen när du har rätt arkitektur.

Förfiningsprocessen blir evolutionär, inte autoregressiv.

Verkligt exempel: Sortera algoritmer

Säg att du vill att din agent ska genomföra en effektiv sortering.

Voyager närmar sig:

1. GPT-4 genererar QuickSort genomförande
2. GPT-4 utvärderar om det "ser rätt"
3. GPT-4 kör den i miljön
4. Om det misslyckas, GPT-4 föreslår korrigeringar
5. Kostnad: ~$0.20-0.30 per försök

DiSE-metoden:

1. Triage: "implementera effektiv sortering" → dirigerad till allmän nivå
2. Qwen 2.5 Coder 7B genererar 5 varianter (QuickSort, MergeSort, HeapSort, variationer)
3. Test svit kör alla 5 mot:
   • Korrekthetsprov (sorterad utgång, stabilitet, kantfall)
   • Referensvärden för prestanda (tid, minne)
   • Statisk analys (komplexitet, kodkvalitet)
4. Bästa utförande variant går in i registret med mätvärden
5. Kostnad: ~$0.002-0.005
6. Framtida förfrågningar om "sortering" hämta detta beprövade genomförande
7. Om någon senare behöver "stabil sortering", kan optimizer mutera den befintliga koden istället för att börja från början.

Den billiga modellen kan utforska lösningsutrymmet. Testerna gör valet. Den dyra modellen blir bara inblandad om alla 5 varianter misslyckas.

Vad detta innebär i praktiken

Jag har experimenterat med liknande principer i min bloggs RAG-system och Semantiska underrättelsefunktioner. Mönstret är konsekvent:

Använd den största modellen för arkitekturbeslut, inte utförande.

När jag byggde trasig länkhanterare Jag använde inte GPT-4 för att kolla alla länkar.

1. Använder enkla HEAD-förfrågningar för att kontrollera länkens giltighet (ingen LLM)
2. Faller tillbaka till semantisk sökning när länkar går sönder (ONNX modell)
3. Endast innebär en LLM om semantisk sökning misslyckas (sällsynt behövs)

Den dyra intelligensen finns i designen, inte i avrättningen.

Nyckelfrågan

Varje system ställer en annan fråga:

Toolformer frågar:

Kan en LLM lära sig när man ska använda verktyg genom att mäta vilka verktyg som faktiskt hjälper?

Voyager frågar:

Kan en LLM generera återanvändbar kod som hjälper i framtida uppgifter?

DiSE frågar:

Kan ett system generera verktyg, utvärdera dem objektivt, utveckla dem baserat på verkliga resultat, och gör allt detta tillräckligt effektivt för att köras i produktionen?

Verktygsbildare bevisad Resultatbaserade lärandearbeten. Voyager bevisade det. genererade verktyg kan återanvändas. DiSE bevisar verktyg kan utvecklas kontinuerligt utan att bryta banken.

Verktygsbildare är Utbildningstid. Voyager är blixt. DiSE är infrastruktur.

Man visar att man kan lära sig av resultaten. En visar att du kan generera verktyg. Den andra bygger maskiner för kontinuerlig evolution.

Praktiska följder

Om du bygger LLM-drivna system idag, föreslår DiSE:

1. Bygg utvärdering först

Skapa inte kod och hoppas att det fungerar. Skriv tester som definierar "verk". Som jag gör för min Entity Framework migreringar Det behövs ingen bedömning av LLM.

2. Använd nivåer Aggressivt

Route enkla uppgifter till billiga modeller. Reservera dyra modeller för verkligt svåra problem. Din plånbok kommer att tacka dig.

3. Spåra vad som fungerar

Förvara inte bara koden, utan:

• Vad det genererades för
• Vilken modell skapade den
• Hur bra det fungerade
• Hur ofta den återanvänds

Denna metadata blir träningsdata för din routinglogik.

4. Omfamna evolutionen

Förvänta dig inte perfektion på första försöket. Generera varianter, testa dem, behåll vinnarna, mutera de goda men inte perfekta.

Detta är hur jag närmar mig utveckling på denna blogg - iterera offentligt, lära av verklig trafik, förbättra baserat på faktisk användning.

Varför strukturera saker och ting mer än du tror

Skillnaden mellan Voyager och DiSE handlar inte bara om kostnader. vad som händer när saker misslyckas.

I Voyager betyder misslyckande:

• Be GPT-4 att felsöka
• Hoppas den förstår problemet
• Betala $ 0,05 för förmånen

I DiSE utlöser fel:

• Strukturerad felanalys (vad som misslyckades, varför, vad som förväntades)
• Variantgenerering från arbetsalternativ
• Upptrappning endast om problemet är verkligt nytt
• Lärande för framtida liknande misslyckanden

Systemet får smartare om vad den inte vet.

Framtiden är Hybrid

Jag tror inte att vi kommer att se ren "enkel modell gör allt" system vinner i produktionen. Ekonomin fungerar inte, och misslyckande lägen är för ogenomskinliga.

Istället får vi se hybridsystem som DiSE:

• Billiga modeller för vanliga mönster
• Dyrbara modeller för nya problem
• Icke-LLM-logik för allt annat (test, mätvärden, validering)
• Minnessystem som faktiskt lär sig av resultaten

Vi ser detta mönster överallt:

• RAG-system kombinera hämtning + generering
• Fleragentarbetsflöden med specialkomponenter
• Semantisk sökning användning av sängkläder + omplacering

Magin är inte att ha en lysande modell. rätt modell vid rätt tidpunkt med Rätt bakgrund.

Slutsatser

Voyager var en fyr, det visade att agenter kunde lära sig genom att generera kod.

Nästa steg var inte mer frammanande.

Nästa steg är Riktad syntetisk utveckling:

• Avsiktlig variation
• Objektiv utvärdering
• Systematiskt arv
• Strukturellt lärande

DiSE försöker inte vara smartare på ett enda skott. Det försöker att vara bättre på nästa Skjuten.

Den skillnaden är där evolutionen börjar.

Till skillnad från biologisk utveckling behöver vi inte vänta miljoner år för att se resultat.

Varför detta är annorlunda

• Behöver inte finjusteras - Fungerar med alla LLM via API
• Behöver inte GPT-4 för allt - Nivåindelad utförande håller kostnaderna nere
• Hallucinerar inte utvärdering - Objektiva testselar, inte LLM-bedömning
• Kastar inte bort koden - Varje artefakt är lagrad, versionerad, spårad
• Glöm inte det förflutna arbetet. - RAG + användningsstatistik = institutionellt minne
• Räds inte misslyckande - Använder den som urvalstryck för evolution

Ytterligare läsning

Papper:

• Voyager: Open-Ended Empilate Agent med stora språkmodeller - Det ursprungliga papperet.
• Verktygsformare - Lära LLMs att använda verktyg
• Återgå till handling - Resonemang + skådespelarmönster
• Tankarnas träd - Överväga problemlösning

På den här bloggen:

• Att bygga ett RAG-system - Hybrid hämtning + generationsarkitektur
• Semantisk sökning med ONNX och Qdrant - Inbäddningar utan dyra API:er
• Kriget mot 404 - Indelad metod för fastställande av länkar
• Använda Ollama för lokala LLMs - Självvärdiga mindre modeller
• Bygga en advokat GPT-serie - Multi-part serie på RAG + LLMs

Verktyg:

• Ollama Ordförande - Kör Llama, Qwen och andra modeller lokalt
• Bit-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l-l. - Enhetligt API för 100+ LLM leverantörer
• Långkyckling - Ramverk för LLM-appar (även om jag tenderar att undvika tunga ramar)