Pitkät agenttivuorot konteksti-ikkunan sisällä

Malli voi lukea kerrallaan vain rajatun määrän — sen konteksti-ikkunan. Mythexin agentti tekee pitkää työtä: lukee monia tiedostoja, ajaa komentoja ja antaa rajatut työt aliagenteille. Löysimme kolme tapaa, joilla pitkä työ hajosi: aliagentit kasvoivat, kunnes malli kieltäytyi jokaisesta pyynnöstä; aliagentti pysähtyi aikaisin, koska se luuli, ettei tilaa ollut enää; ja tokenlaskentamme oli rajusti väärä venäjän, kiinan ja japanin tekstille. Tässä on mitä muutimme.

Ensin muutama termi

• Tokenit ovat paloja, joita malli lukee. Rajat ja kustannukset lasketaan niissä, ei merkeissä tai sanoissa.
• Konteksti-ikkuna on enimmäismäärä, jonka malli voi lukea yhdessä pyynnössä. Lisäksi asetamme oman, alemman budjetin jokaiselle pyynnölle, jotta kustannukset ja nopeus pysyvät kohtuullisina.
• Työkalutulokset ovat sitä, mitä agentti saa takaisin työkaluiltaan: lukemansa tiedoston sisällön tai ajamansa komennon tulosteen. Pitkässä työssä ne ovat suurin osa lähetetystä.
• Aliagentti on apulainen, jonka pääagentti käynnistää itsenäiselle tehtävälle, esimerkiksi „tarkista nämä luvut muistiinpanoja vasten”. Se saa yhden ohjeen ja työskentelee sen jälkeen monien työkalukutsujen kautta itsenäisesti.

Ongelma 1: aliagentit kasvoivat, kunnes malli kieltäytyi niistä

Jokaisessa vaiheessa agentti lähettää mallille keskustelun tähän asti. Kun se kasvoi liian suureksi, koodimme leikkasi sitä — mutta vain käyttäjäviestin alussa, jotta työkalukutsu ja sen tulos eivät koskaan jakautuneet. Se säilytti ensimmäisen viestin, lisäsi huomautuksen, että aiempaa keskustelua on leikattu, ja piti uusimmat kokonaiset vuorot, jotka mahtuivat.

Aliagentilla on täsmälleen yksi käyttäjäviesti: sen ohje. Leikkauskohtaa ei ollut. Joten se lähetti koko historiansa joka vaiheessa, ja historia kasvoi joka kerta, kunnes pyyntö oli suurempi kuin malli hyväksyy lainkaan — noin miljoona tokenia. Testissä, jossa oli 8 tällaista aliagenttia, kaikki 8 kieltäytyivät.

Korjaus: tyhjennä vanhimmat työkalutulokset ensin

Pyynnöt mahtuvat nyt budjettiin kolmessa vaiheessa, ja kutakin kokeillaan vain, jos edellinen ei riittänyt:

1. Tyhjennä vanhimmat työkalutulokset. Niiden sisältö korvataan lyhyellä huomautuksella: tulos tyhjennettiin, jotta keskustelu mahtuu mallin kontekstiin, ja agentti voi ajaa työkalun uudelleen tarvittaessa. Tunnin takainen tiedoston luku on yleensä pyynnön suurin ja vähiten hyödyllinen osa, ja tiedosto on edelleen luettavissa uudelleen. Uusimmat tulokset säilyvät kokonaisina.
2. Säilytä kokonaiset käyttäjävuorot. Kuten ennenkin: ensimmäinen viesti, huomautus ja uusimmat täydet vuorot, jotka mahtuvat.
3. Säilytä kokonaiset työkalukierrokset. Yhden pitkän vuoron sisällä — ainoa tyyppi, jonka aliagentilla on — säilytetään ensimmäinen viesti, huomautus ja uusimmat täydet kierrokset „kutsu työkalua, saa tulos”.

Tämä muokkaa vain sitä, mitä lähetetään. Agentin tallennettu historia säilyttää kaiken. Samassa testissä 0 kahdeksasta kieltäytyi, ja kaikki kahdeksan valmistui.

Tyhjennys erissä, jotta välimuisti toimii

Mallien palveluntarjoajat voivat käyttää uudelleen pyynnön alun, jos se on identtinen edelliseen — tätä kutsutaan etuliitevälimuistiksi. Jos tyhjentäisimme yhden tuloksen lisää joka kutsulla, pyynnön alku muuttuisi joka kerta eikä välimuistista olisi hyötyä.

Vanhimmat tulokset tyhjennetään siksi neljä kerrallaan. Tyhjennetty osa pysyy sitten samana useiden kutsujen ajan. Tulosta, joka ei ole paljon huomautusta suurempi, ei kosketa: sen tyhjentäminen säästäisi lähes ei mitään ja muuttaisi silti pyynnön alkua. Se, mikä säilyy kokonaisena, päätetään koon eikä lukumäärän perusteella: uusimmat tulokset, jotka mahtuvat neljännekseen budjetista, säilyvät, ja aina vähintään yksi. Aiempi versio säilytti kiinteästi kuusi kokonaista tulosta. Se sopi lyhyelle komennon tulosteelle, mutta pitkillä tiedostojen luvuilla suurin osa budjetista jäi vanhoille tuloksille.

Hylkäykset kerrotaan nyt

Mallin virheellisenä hylkäämää pyyntöä ei enää yritetä uudelleen; saman pyynnön lähettäminen antaisi saman vastauksen. Jos keskustelu on liian pitkä mallille, käyttäjä näkee: „Tämä keskustelu kävi liian pitkäksi, jotta malli voisi lukea sen kerralla. Aloita uusi chat seuraavaa vaihetta varten — kaikki tähän mennessä rakennettu säilyy.” Tämä on käyttäjän toimi, ei katkos, joten se ei hälytä meitä.

Ongelma 2: agentti pysähtyi „säästämään tilaa”

Aliagentti, jonka piti lukea 40 pitkää lukua, pysähtyi kahden luvun jälkeen ja sanoi haluavansa säästää tilaa. Se oli käyttänyt noin 100 000 tokenia 400 000 tokenin budjetista.

Sillä ei ollut tapaa tietää, että vanhat tulokset tyhjennettäisiin sen puolesta. Kerroimme sen siis. Agentin ohjeissa lukee nyt, että kun keskustelu kasvaa yli sen, mitä malli ottaa vastaan, vanhimmat työkalutulokset tyhjennetään ja uusimmat säilyvät kokonaisina — joten älä pysähdy pitkän tehtävän kesken säästämään tilaa; jatka, ja lue tiedosto uudelleen, jos tarvitset tyhjennettyä sisältöä.

Korjaus, jota malli ei näe, ei ole korjaus mallin näkökulmasta. Mekanismi auttaa vain, jos agentti luottaa siihen.

Ongelma 3: tokenien laskeminen ikään kuin kaikki olisi englantia

Arvioimme tokenit ilman tokenizeria: merkit jaettuna neljällä. Se on järkevä peukalosääntö englannille, mutta ei muille kirjoitusjärjestelmille. Venäjä on noin 2,2 merkkiä per token, kiina ja japani noin yksi.

Aliagentti, joka luki venäjänkielisiä lukuja, lähetti pyynnön, jossa oli noin 640 000 tokenia, vaikka arviomme sanoi sen olevan alle 400 000 tokenin budjetin. Arvio olisi yhtä helposti voinut työntää pyynnön mallin kovan rajan yli.

Arvio laskee nyt kirjoitusjärjestelmän mukaan: tavallinen ASCII neljällä merkillä per token, kiina, japani ja korea yhdellä, ja kaikki muu — kyrillinen, kreikka, arabia, aksentilliset kirjaimet, emojit — kahdella. Se on tarkoitettu erehtymään ylöspäin. Yhdellä venäjänkielisellä luvulla se arvioi nyt 43 423 tokenia, kun mitattu määrä oli noin 44 600; aiemmin se sanoi 25 023. Koska viesti ei muutu kirjoittamisen jälkeen, sen arvio lasketaan kerran ja muistetaan, eikä joka vaiheessa uudelleen.

Mitä opimme

• Leikkaa siellä, missä koko oikeasti on. Agenttityössä se on työkalutuloksissa, ei käyttäjäviesteissä.
• Kerro agentille sen omista turvaverkoista. Muuten se suunnittelee rajojen ympärille, jotka eivät enää päde.
• „Merkit jaettuna neljällä” on englantilainen oletus. Kaiken, mikä laskee tokeneita monikielisille käyttäjille, täytyy laskea kirjoitusjärjestelmän mukaan tai käyttää oikeaa tokenizeria.
• Huomioi välimuisti. Pyyntö, joka muuttuu alusta joka kutsulla, maksaa enemmän ja on hitaampi.

Jos rakennat tekoälyominaisuuksia omaan sovellukseesi, oppaamme mikä LLM on ja miten LLM-rajapintoja käytetään kattavat kontekstin ikkunat ja tokenit alusta alkaen. Lisää siitä, miten aliagentit toimivat Mythexissä, on aliagenttien dokumentaatiossa.