# "Eikö DiSE ole vain Voyager?" - Miksi rakenne voittaa Brilliancen? 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. ## Johdanto "Tämä kuulostaa Voyagerilta, mutta lisää askeleita." Jos olet seurannut LLM:n johtamaa agenttitutkimusta, olet luultavasti kuullut siitä. [Voyager](https://arxiv.org/abs/2305.16291) (Wang et al., 2023) - järjestelmä, joka opetti GPT-4:n pelaamaan Minecraftia luomalla uudelleenkäytettävän koodin "taidot" - ja [Työkalunmuokkain](https://arxiv.org/abs/2302.04761) (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](/blog/elevatorpitch) Isoa kuvaa varten tutustu sitten "Cooking with DiSE" -sarjaan: [Osa 2 – Tutkinnon suorittaneiden oppisopimuskoulutus](/blog/blog-article-cooking-dise-part2-apprenticeships) sekä [3 osa: Epäluotettavat LLM-yhdisteet](/blog/blog-article-cooking-dise-part3-untrustworthy-gods)Tä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. [TOC] ## Voyagerin ja työkalumuokkaajan menestys Kaksi vuoden 2023 paperia muutti, miten ajattelemme LLM:n agentteja ja työkaluja: ### Voyager: Agentit voivat luoda 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: - Kasvavan osaamiskirjaston rakentaminen ajan myötä - Muodosta yksinkertaiset taidot monimutkaisiksi käytöiksi - Vältä katastrofaalista unohtamista upottamalla pohjalle Ja se toimi, tavallaan, Minecraftissa, GPT-4:n kanssa. ### Työkalunmuokkaaja: Agentit voivat oppia, milloin käyttää työkaluja [Työkalunmuokkain](https://arxiv.org/abs/2302.04761) (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. 1. Lisää tekstiin mahdollisia työkalukutsuja ("ehkä minun pitäisi käyttää laskinta tässä?") 2. Suorita itse nuo työkalut 3. Pidä esimerkit siitä, missä työkalut auttoivat, heitä pois sieltä, missä ne eivät auttaneet 4. Hienosanaisesti onnistuneista esimerkeistä 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. ### Miten DiSE yhdistää molemmat (ja menee pidemmälle) DiSE ottaa näkemyksiä molemmista papereista, mutta korjaa niiden aukkoja: **Voyagerilta:** - - Säilytä ne tulevaa hakua varten - Mutta lisää: Objektiivinen testivaljaat, ei vain "Toimiiko se Minecraftissa?" - Mutta lisää: Tiered mallit sijaan GPT-4 kaikkeen - Mutta lisää: Mutaatio ja evoluutio, ei vain varastointi **Työkalumuokkaimesta:** - Opettele objektiivisista tuloksista - - Mutta lisää: Runtime evolution, ei vain koulutus-ajan oppiminen - Lisää: Luo itse työkalut, älä vain opettele soittamaan niille - Mutta lisää: Täysi elinkaari - työkaluja voidaan parantaa, ei vain käyttää **DiSE:n sukututkimus:** Ajattele DiSEä ReActin, Refleksion, Toolformerin ja Voyagerin lapsenlapsena. ```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 ``` **Perintö:** - **Toistuva toiminta** → Strukturoitu päättely toiminnan havainnointisilmukoilla - **Refleksi** → Itsekehittyneisyys pohdinnan kautta (mutta LLM-tuomarit itse) - **Työkalunmuokkain** → Opettele todellisista tuloksista, älä vain yllytä - **Voyager** → Luo ja tallenna uudelleenkäytettäviä koodiesineitä **DiSE lisää:** - Objektiiviset testivaljaat (ei LLM:n itsearviointi) - Runtime evolution (ei vain harjoitusaikaa) - Tiered model implementation (halpa → kallista vain tarvittaessa) - Työkalun koko elinkaari (syntymä → mutaatio → perintö → kuolema) - Kustannusten optimointipalautesilmukat - Stateful työkalurekisteri (hieman Fieldingin REST-arkkitehtuuria - työkalut valtion osoittamina resursseina) 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**. ### Voyagerin arkkitehtuuri ```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 ``` 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. ## Mikä pisti Voyagerin takaisin Voyager ei käyttänyt vain GPT-4:ää koodin tuottamiseen, vaan hän luotti GPT-4:ään: - **Suunnittelu** - Korkean tason tavoitteiden jakaminen alatehtäviin - **Arviointi** - Päättää, toimiiko taito oikein - **Hajoaminen** - Selvitetään, mitkä nykyiset taidot yhdistetään - **Nimeäminen** - Luodaan kuvaustunnisteita tallennukseen - **Valinta** - Oikean taidon valitseminen upotuksista - **Laadun arviointi** - Päättää, mikä on tarpeeksi hyvää. 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. ### Kustannusongelma Tehdään lautasliinamatematiikkaa ja sanotaan, että haluat pyörittää Voyager-tyylistä järjestelmää tosimaailman tehtävissä: - GPT-4 Turbo: 0.01 per 1K-syötepoletit, 0.03 per 1K-lähtöpoletit - Tyypillinen taitosukupolvi: ~2K syöte + 1K ulostulo = 0,05 dollaria - 100 taitoa, joista 3 yrittää uudelleen kukin = ~300 puhelua = **$15** - Se on vain alkuperäinen kirjastorakennus. 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. ## Miksi DiSE ei ollut mahdollinen vuonna 2023 (mutta on nyt) 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 talous saatiin vihdoin kiinni. **Tämä on tekninen ongelma.** Tekniikassa on aina kyse ajoituksesta. ## DiSE:n ydinero 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ä. ### DiSE-arkkitehtuuri ```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 ``` 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 ## Miksi DiSE ei tarvitse GPT-4:ää (suurin osa ajasta) Koska **jokaista luotua koodiyksikköä käsitellään esineenä**, ei nopea vastaus. Sitä ei arvioida "näyttääkö hyvältä?", se arvioidaan seuraavasti: - Toimiiko se? - Ratkaiseeko se tehtävän? - Onko se nopeampi kuin ennen? - Läpäiseekö se koesviitin? 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](/blog/semantic-search-with-onnx-and-qdrant) - isointa mallia ei tarvita, kun arkkitehtuuri on oikea. Parannusprosessista tulee **evolutionaarista, ei autoregressiivista**. ### Todellinen esimerkki: Algoritmeja lajitellaan Tehdään tästä konkreettista ja sanotaan, että haluat agenttisi toteuttavan tehokkaan lajittelun. **Voyager-lähestymistapa:** 1. GPT-4 tuottaa QuickSort-toteutuksen 2. GPT-4 arvioi, näyttääkö se "oikealta" 3. GPT-4 pyörittää sitä ympäristössä 4. Jos se epäonnistuu, GPT-4 ehdottaa korjauksia 5. Kustannukset: 0.20-0.30 yritystä kohti **DiSE-lähestymistapa:** 1. Triage: "Toteuta tehokas lajittelu" → ohjattu yleistasolle 2. Qwen 2.5 Coder 7B tuottaa 5 varianttia (QuickSort, MergeSort, HeapSort, variaatiot) 3. Testisarja kulkee kaikkia viittä vastaan: - Oikaisutestit (erilaiset ulostulot, stabiilius, reunakotelot) - Suorituskyvyn viitearvot (aika, muisti) - Staattinen analyysi (monimutkaisuus, koodin laatu) 4. Parhaiten suoriutunut variantti menee rekisteriin metrien avulla 5. Kustannukset: 0,002–0,005 6. Tulevia pyyntöjä "korjata" hakea tämä todistettu toteutus 7. Jos joku myöhemmin tarvitsee "stabiilia lajittelua", optimoija voi muuttaa olemassa olevaa koodia sen sijaan, että aloittaisi alusta Halpa malli voi tutkia ratkaisutilaa. Testit tekevät valinnan. Kallis malli tulee mukaan vain, jos kaikki viisi versiota epäonnistuvat. ## Mitä tämä merkitsee käytännössä Olen kokeillut samoja periaatteita. [blogini RAG-järjestelmä](/blog/rag-primer) sekä [semanttisen älykkyyden piirteitä](/blog/semantidintelligence). Malli on johdonmukainen: **Käytä suurinta mallia arkkitehtuuripäätöksissä, ei toteutuksessa.** Kun rakensin [katkennut linkinkäsittelijä](/blog/the-war-on-404) Semanttisella hakuvaralla en käyttänyt GPT-4:ää jokaisen linkin tarkistamiseen. Järjestelmä: 1. Käyttää yksinkertaisia HEAD-pyyntöjä tarkistaakseen linkin pätevyyden (ei LLM:ää) 2. Vetää takaisin semanttiseen hakuun, kun linkit katkeavat (ONNX-malli) 3. LLM on käytössä vain, jos semanttinen etsintä epäonnistuu (harvemmin tarvitaan) Kallis älykkyys on suunnittelussa, ei teloituksessa. ## Avainkysymys 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. ## Käytännöllisiä vaikutuksia Jos rakennat tänään LLM-käyttöisiä järjestelmiä, DiSE-lähestymistapa ehdottaa seuraavaa: ### 1. Rakenna arviointi ensin Älä luo koodia ja toivo, että se toimii. Kirjoita testejä, jotka määrittelevät "teoksia". [My Entity Framework -siirtymät](/blog/efmigrationstherightway) LLM-tuomiota ei tarvittu. ### 2. Käytä tasoja aggressiivisesti Reitti yksinkertaisia tehtäviä edullisille malleille. Varaa kalliit mallit aidosti vaikeisiin ongelmiin. Lompakkosi kiittää sinua. ### 3. Seuraa, mikä toimii Säilytä koodin lisäksi: - Mihin se on luotu? - Mikä malli sen loi? - Kuinka hyvin se suoriutui - Kuinka usein sitä käytetään uudelleen Tästä metadatasta tulee reitityslogiikan koulutusdataa. ### 4. Syleile evoluutiota Ä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ä](/blog/usingumamidataforwebsitestats), parantaa perustuen todelliseen käyttöön. ## Miksi rakenne on tärkeämpi kuin luuletkaan Voyagerin ja DiSE:n ero ei ole vain kustannus. **mitä tapahtuu, kun asiat epäonnistuvat**. Voyagerissa epäonnistuminen tarkoittaa: - Pyydä GPT-4:ää vianetsintään - Toivottavasti se ymmärtää ongelman - Maksa etuoikeudesta 0,05 dollaria DiSE:ssä epäonnistuminen laukaisee: - Strukturoitu virheanalyysi (mikä epäonnistui, miksi, mitä odotettiin) - Työvaihtoehdoista poikkeava sukupolvi - Eskalointi vain, jos ongelma on aidosti uusi - Oppiminen samanlaisista epäonnistumisista tulevaisuudessa Järjestelmä saa **fiksumpi siitä, mitä se ei tiedä**. ## Tulevaisuus on hybridi 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ä: - Halvat mallit yhteisille kuvioille - Kalliita malleja uusille ongelmille - Muu kuin LLM-logiikka kaikkeen muuhun (testit, mittarit, validointi) - Muistijärjestelmät, jotka todella oppivat tuloksista Tämä kuvio näkyy kaikkialla: - [RAG-järjestelmät](/blog/rag-architecture) Reklamaation ja sukupolven yhdistäminen - [Usean agentin työnvirrat](/blog/workflowsystem-part1-introduction) joissa on erikoiskomponentteja - [Semanttinen etsintä](/blog/semantic-search-in-action) uppoumien käyttö + uudelleenjärjestäminen Taikuutta ei ole siinä, että on yksi nerokas malli, vaan siinä, että on **oikea malli oikeaan aikaan** • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • **oikea konteksti**. ## Päätelmät 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**: - Tahallinen vaihtelu - Objektiivinen arviointi - Järjestelmällinen perintö - Rakenteellinen oppiminen 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. --- ## Miksi diSE on erilainen - **Ei tarvitse hienosäätöä** - Toimii minkä tahansa LLM:n kanssa API:n kautta - **Ei tarvitse GPT-4:ää kaikkeen** - Tiloittainen toteutus pitää kustannukset alhaisina - **Se ei hallusinoi arviointia** - Objektiiviset testivaljaat, ei LLM-tuomio - **Ei heittele koodia pois** - Jokainen esine on tallennettu, versioitu, jäljitetty - **Ei unohda menneitä töitä** - RAG + käyttötilastot = laitosmuisti - **Ei pelkää epäonnistumista** - Käyttää sitä evoluution valintapaineena --- ## Lisää luettavaa **Paperit:** - [Voyager: Open-Ended Embient Agent with Large Language Models](https://arxiv.org/abs/2305.16291) - Alkuperäinen lehti - [Menneisyystyökalu](https://arxiv.org/abs/2302.04761) - LLM:ien opettaminen työkalujen käyttöön - [Toistuva toiminta](https://arxiv.org/abs/2210.03629) - Perustelut + käyttäytymismalli - [Ajatusten puu](https://arxiv.org/abs/2305.10601) - Tahallinen ongelmanratkaisu **Tässä blogissa:** - [RAKENNEJÄRJESTELMÄN RAKENTAMINEN](/blog/rag-primer) - Hybridihaku + sukupolven arkkitehtuuri - [Semanttinen haku ONNX:llä ja Qdrantilla](/blog/semantic-search-with-onnx-and-qdrant) - Upotat ilman kalliita API-rajapintoja - [Sota 404.](/blog/the-war-on-404) - Määritetty lähestymistapa yhteyden kiinnittämiseen - [Ollaman käyttö paikallisissa LLM:issä](/blog/reanimation) - Itseohjautuvat pienemmät mallit - [Asianajaja GPT-sarjan rakentaminen](/blog/building-a-lawyer-gpt-for-your-blog-part1) - Moniosaiset sarjat RAG + LLM:t **Työkalut:** - [Ollama](https://ollama.ai/) - Suorita Llama-, Qwen- ja muita malleja paikallisesti - [LiteLLM](https://github.com/BerriAI/litellm) - Yhdistetty API 100+ LLM-toimittajille - [LangChain](https://www.langchain.com/) - Kehys LLM-sovelluksille (vaikka yleensä vältän raskaita kehyksiä)