Järjestelmäni, DiSE, on itsekehittyvä, itsekehittyvä, ohjelmistotekniikan pohjatyövirran rakentaja. Se tuottaa testaavia koodiesineitä, arvioi niitä objektiivisesti ja kehittää niitä ajan mittaan ilman jatkuvaa ihmisen valvontaa. Mutta eikö Voyager, tuo vaikuttava Minecraft-botti vuodelta 2023, jo tehnyt tämän luomalla uudelleenkäytettäviä taitoja? Eikä Toolformer jo todistanut, että LLM:t voisivat oppia käyttämään työkaluja mittaamalla tuloksia? Jos meillä on jo agentteja, jotka kirjoittavat omia työkalujaan ja oppivat käyttämään niitä, emmekö ole jo ratkaisseet itse kehittäviä tekoälyä?
Spoiler: Ei, ja sen ymmärtäminen, miksi on tärkeää, jos rakentaa jotain, mitä pitää pyörittää tuotannossa.
"Tämä kuulostaa Voyagerilta, mutta lisää askeleita."
Jos olet seurannut LLM:n johtamaa agenttitutkimusta, olet luultavasti kuullut siitä. Voyager (Wang et al., 2023) - järjestelmä, joka opetti GPT-4:n pelaamaan Minecraftia luomalla uudelleenkäytettävän koodin "taidot" - ja Työkalunmuokkain (Schick et al., 2023) - joka opetti LLM:t käyttämään työkaluja mittaamalla todellisia tuloksia. Molemmat olivat vaikuttavia, vaikutusvaltaisia ja laajalti tunnettuja.
Ensi silmäyksellä DiSE (Directed Synthetic Evolution) voi näyttää Voyager + Toolformerilta, jolla on tuore maalipinta. Mutta se on kuin sanoisi, että tuotantotietokanta on vain laskentataulukko, jossa on enemmän askelia. Erolla on merkitystä, jos välittää mittakaavasta, kustannuksista ja itse asiassa lähettää jotain.
Uusi DiSE:ssä? Katso Hissihittini Isoa kuvaa varten tutustu sitten "Cooking with DiSE" -sarjaan: Osa 2 – Tutkinnon suorittaneiden oppisopimuskoulutus sekä 3 osa: Epäluotettavat LLM-yhdisteetTässä viestissä keskitytään erityisesti siihen, miten DiSE:n arkkitehtuuri eroaa Voyagerista ja Toolformerista.
Tässä viestissä kerrotaan, mitä Voyager ja Toolformer saivat kohdalleen, missä he osuivat rajoihin ja miksi DiSE:n arkkitehtuuri ratkaisee ongelmia, joihin kumpikaan ei pystynyt yksin tarttumaan.
Kaksi vuoden 2023 paperia muutti, miten ajattelemme LLM:n agentteja ja työkaluja:
Voyager esitteli ratkaisevan oivalluksen:
LLM:t voivat luoda omat uudelleenkäytettävät työkalunsa.
Sen sijaan, että Voyager olisi koodannut kaikki Minecraftin toiminnot, hän käytti GPT-4:ää kirjoittaessaan toimintoja lennolla. Jokaisesta onnistuneesta toimesta tuli vektoritietokantaan tallennettu uudelleenkäytettävissä oleva taito.
"Toimintosi käytetään uudelleen monimutkaisempien toimintojen rakentamiseen. Siksi siitä pitäisi tehdä yleiskäyttöinen ja käyttökelpoinen."
Tämä oli tärkeää. Ensimmäistä kertaa agenttijärjestelmä käsitteli työkalusukupolvea todellinen ohjelmistotekniikka Voyager osoitti, että agentit voivat:
Ja se toimi, tavallaan, Minecraftissa, GPT-4:n kanssa.
Työkalunmuokkain (Schick et al., 2023) omaksui erilaisen lähestymistavan. Sen sijaan, että se olisi luonut työkaluja, se opetti LLM:ille milloin soittaa olemassa oleviin työkaluihin.
Näppärä bitti: Toolformer tuotti omat harjoitustietonsa.
Tämä loi malleja, jotka oppivat työkalun käytöstä objektiiviset tulokset Laskimen API, joka palauttaa oikean vastauksen, on parempi kuin sellainen, joka ei kaipaa LLM-arviota.
DiSE ottaa näkemyksiä molemmista papereista, mutta korjaa niiden aukkoja:
Voyagerilta:
-
Työkalumuokkaimesta:
DiSE:n sukututkimus:
Ajattele DiSEä ReActin, Refleksion, Toolformerin ja Voyagerin lapsenlapsena.
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
Perintö:
DiSE lisää:
Toolformer todisti, että voit kouluttaa malleja työkalujen käyttöön mittaamalla todellisia tuloksia. Voyager todisti, että agentit voivat rakentaa omia työkalukirjastojaan. Refleksit todistivat heijastussilmukoiden toimivan. ReAct todisti järjestelmällisen päättelyn.
DiSE kysyy: Mitä jos yhdistäisimme kaikki nämä oivallukset, mutta tekisimme siitä niin halpaa, että se toimisi tuotannossa ja olisi tarpeeksi älykäs parantaakseen itseään ajan myötä?
Ja kyllä, sielläkin on ripaus Roy Fieldingin REST-arkkitehtuuria - työkalut ovat statistisia resursseja, joissa on URI-tietoja, metatietoja ja versiointia. Jokainen työkalu on osoitettavissa, välimuistissa ja se voidaan säveltää muiden kanssa. Työkalurekisteri ei ole vain vektoritietokanta, vaan se on RESTful-varasto, jossa resursseilla (työkaluilla) on tilaa (käyttötilastot, suoritusmittarit, versiohistoria), joka vaikuttaa siihen, miten ne kerätään ja kehitetään.
Se ei ole koulutusta, ei ainutkertaista sukupolvea. ohjattu evoluutio.
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
Ongelmana on, että jokainen päätös - suunnittelu, arviointi, vianetsintä, sommittelu - menee saman rajamallin läpi. Kun joka askeleella tarvitaan nerokkuutta, tarvitaan GPT-4 (tai vastaava) kaikkialla.
Voyager ei käyttänyt vain GPT-4:ää koodin tuottamiseen, vaan hän luotti GPT-4:ään:
Kun malli tekee kaiken, sen pitää olla rajatason nerokas joka kerta.
Juuri siksi Voyager ei skaalautunut Minecraftia pidemmälle, ja siksi sen pyörittäminen tuotannossa maksaisi omaisuuden.
Tehdään lautasliinamatematiikkaa ja sanotaan, että haluat pyörittää Voyager-tyylistä järjestelmää tosimaailman tehtävissä:
Lisää nyt hakukyselyt, kokoonpanoyritykset, vianetsintäsyklit. Voit helposti katsoa satoja dollareita yhden agentin rakentaa maltillinen taitokirjasto.
Vertailun vuoksi voidaan todeta, mitä porrastettu lähestymistapa voi maksaa:
Tehtävä Voyager (GPT-4) DiSE (Tried) Säästöt |------|-----------------|---------------|---------| Triage/reititys 0,05 dollaria 0,001 dollaria (Llama 3,1 8B) 98 prosenttia Alkusukupolvi 0,05 dollaria 0,002 dollaria (Qwen 2,5 Coder) 96 prosenttia Arviointi $0.05 $0 (staattiset testit) $0 100 € Ekskalointi (10 %) 0,05 dollaria 0,05 dollaria (GPT-4o) 0 % | Tehtäväkohtainen keskiarvo | $0.20 | $0.016 | 92% |
Kun kutsutaan vain kallista mallia aidosti vaikeiksi ongelmiksi, talous muuttuu dramaattisesti.
Voyager, Toolformer ja Refleksion eivät olleet epäonnistumisia, vaan ne vain osuivat hetkensä tekniseen ja taloudelliseen kattoon.
Kolme rajoitusta esti edistystä vuonna 2023:
Rajoitus (2023) Seuraukset Mikä muuttui (2024–2025) |-------------------|-------------|--------------------------| GPT-4 oli ainoa luotettava päättelymoottori. Yksi malli joutui tekemään kaiken. Tiered-mallistot – GPT-4o + Qwen + DeepSeek + Llama Paikalliset uppoumat olivat heikkoja tai käyttämättä jääneitä, nouto oli kallista, BGE / Arctic / MiniLM on consumer GPUs Ei jäsenneltyjä arviointivaljaita LLM:n arvioimat LLM:t käyttävät nyt koodia puhtaana konttien kautta.
Voyager ja Toolformer eivät voineet kehittyä.
He voivat soittaa vain malleille tai hienovaraisille malleille. He eivät voineet jakaa kognitiota koko järjestelmään. Valintapainetta ei pystytty kohdistamaan.
He ratkaisivat "Voimmeko?" Kysymys.
DiSE ratkaisee "Miten parannamme jatkuvasti?" Kysymys.
En siksi, että olisin älykkäämpi kuin Wang tai Schick, vaan siksi, että laitteistot, työkalut ja taloustiede ovat vihdoin päässeet jyvälle.
Tämä on tekninen ongelma. Tekniikassa on aina kyse ajoituksesta.
DiSE:n avainajatus on yksinkertainen mutta syvällinen:
Rakenne korvaa loiston.
Sen sijaan, että DiSE odottaisi yhden mallin tekevän kaiken täydellisesti, se jakaa ongelman orkesterijärjestelmään. Se ei oleta mallien osaavan koodata. Sen sijaan se luo painetta, palautetta ja muistia Mallit voivat siis parantaa koodia iteratiivisesti sen sijaan, että ne loisivat sen täydellisesti ensimmäisellä yrityksellä.
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
Ero on karu:
Valmius Voyager DiSE |------------|---------|------| Koodeksin laatiminen GPT-4 Tiered multi-LLM -putkisto Arviointi GPT-4 -tuomio Muut kuin LMM-testit, mittarit Työkalujen uudelleenkäyttö Liitännät vain kirjaamoon, jossa metatiedot + tunnisteet + käyttötilastot Parannus GPT-4 ehdottaa korjaustoimenpiteitä Eskalaatio- ja mutaatioputkistoihin Muisti Vektori DB RAG + ryhmittely + evoluution seuranta Kokoelma GPT-4 -suunnitelmat Workflow -kaavion suunnittelu Kustannusten hallinta Ei priorisointia + varalogiikkaa
Koska jokaista luotua koodiyksikköä käsitellään esineenä, ei nopea vastaus.
Sitä ei arvioida "näyttääkö hyvältä?", se arvioidaan seuraavasti:
Halpa LLM (Qwen 2.5 Coder 7B, Llama 3.1 8B) voi tuottaa viisi versiota. Testit valitsevat parhaat. Vahvempi malli tulee mukaan vain heikompien epäonnistuessa.
Ajan myötä järjestelmä oppii, mitkä mallit ovat hyviä mihinkin verkkotunnuksiin. semanttinen hakutoteutus - isointa mallia ei tarvita, kun arkkitehtuuri on oikea.
Parannusprosessista tulee evolutionaarista, ei autoregressiivista.
Tehdään tästä konkreettista ja sanotaan, että haluat agenttisi toteuttavan tehokkaan lajittelun.
Voyager-lähestymistapa:
DiSE-lähestymistapa:
Halpa malli voi tutkia ratkaisutilaa. Testit tekevät valinnan. Kallis malli tulee mukaan vain, jos kaikki viisi versiota epäonnistuvat.
Olen kokeillut samoja periaatteita. blogini RAG-järjestelmä sekä semanttisen älykkyyden piirteitä. Malli on johdonmukainen:
Käytä suurinta mallia arkkitehtuuripäätöksissä, ei toteutuksessa.
Kun rakensin katkennut linkinkäsittelijä Semanttisella hakuvaralla en käyttänyt GPT-4:ää jokaisen linkin tarkistamiseen. Järjestelmä:
Kallis älykkyys on suunnittelussa, ei teloituksessa.
Jokainen järjestelmä esittää erilaisen kysymyksen:
Toolformer kysyy:
Voiko LLM oppia käyttämään työkaluja mittaamalla, mikä työkalu kutsuu oikeasti avuksi?
Voyager kysyy:
Voiko LLM luoda uudelleenkäytettävän koodin, joka auttaa tulevissa tehtävissä?
DiSE kysyy:
Voiko järjestelmä tuottaa työkaluja, arvioida niitä objektiivisesti, kehittää niitä todellisten tulosten perusteella ja tehdä kaiken tämän riittävän tehokkaasti, jotta ne toimivat tuotannossa?
Työkalumuokkain todistettu tuloslähtöinen oppiminen. Voyager osoittautui tuotettuja työkaluja voidaan käyttää uudelleen. DiSE todistaa työkalut voivat kehittyä jatkuvasti rikkomatta pankkia.
Työkalumuokkain on harjoitusaika. Voyagerilla on flash. DiSE: infrastruktuuri.
Yksi osoittaa, että tuloksista voi oppia. Yksi näyttää, että voit luoda työkaluja. Toinen rakentaa laitteita jatkuvaan evoluutioon.
Jos rakennat tänään LLM-käyttöisiä järjestelmiä, DiSE-lähestymistapa ehdottaa seuraavaa:
Älä luo koodia ja toivo, että se toimii. Kirjoita testejä, jotka määrittelevät "teoksia". My Entity Framework -siirtymät LLM-tuomiota ei tarvittu.
Reitti yksinkertaisia tehtäviä edullisille malleille. Varaa kalliit mallit aidosti vaikeisiin ongelmiin. Lompakkosi kiittää sinua.
Säilytä koodin lisäksi:
Tästä metadatasta tulee reitityslogiikan koulutusdataa.
Älä odota täydellisyyttä ensimmäisellä yrityksellä. Luo variantteja, testaa niitä, pidä voittajat, mutatoi hyvät mutta ei täydelliset.
Näin lähestyn kehitystä tässä blogissa - iteroida julkisesti, oppia todellisesta liikenteestä, parantaa perustuen todelliseen käyttöön.
Voyagerin ja DiSE:n ero ei ole vain kustannus. mitä tapahtuu, kun asiat epäonnistuvat.
Voyagerissa epäonnistuminen tarkoittaa:
DiSE:ssä epäonnistuminen laukaisee:
Järjestelmä saa fiksumpi siitä, mitä se ei tiedä.
En usko, että näemme puhtaan "yksi malli tekee kaiken" -järjestelmän voittavan tuotannossa. Taloustiede ei toimi, ja vikatilat ovat liian vaikeaselkoisia.
Sen sijaan näemme DiSE:n kaltaisia hybridijärjestelmiä:
Tämä kuvio näkyy kaikkialla:
Taikuutta ei ole siinä, että on yksi nerokas malli, vaan siinä, että on oikea malli oikeaan aikaan • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • oikea konteksti.
Voyager oli majakka, joka osoitti, että agentit oppivat koodin avulla.
Seuraava askel ei ollut enää yllyttävä, vaan se on saavuttamassa rajansa.
Seuraava askel on ohjattu synteettinen evoluutio:
DiSE ei yritä olla fiksumpi yhdelläkään laukauksella. Se yrittää olla parempi seuraava Laukauksia.
Evoluutio alkaa tästä erosta.
Ja toisin kuin biologinen evoluutio, meidän ei tarvitse odottaa miljoonia vuosia nähdäksemme tuloksia.
Paperit:
Tässä blogissa:
Työkalut:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.