Holde lange agentturer innenfor kontekstvinduet

En modell kan bare lese så mye om gangen, i kontekstvinduet sitt. Mythex-agenten gjør langt arbeid: leser mange filer, kjører kommandoer og gir avgrensede oppgaver til underagenter. Vi fant tre måter lang jobb brøt sammen på. Underagenter vokste til modellen avviste hver forespørsel, en underagent stoppet tidlig fordi den trodde den var tom for plass, og tokentellingen vår var svært feil for russisk, kinesisk og japansk tekst. Her er det vi endret.

Noen begreper først

• Tokens er biter modellen leser. Grenser og kostnader telles i dem, ikke i tegn eller ord.
• Kontekstvindu er det mest en modell kan lese i én forespørsel. Vi setter også vårt eget lavere budsjett for hver forespørsel, slik at kostnader og hastighet holder seg rimelige.
• Verktøyresultater er det agenten får tilbake fra verktøyene sine: innholdet i en fil den leste, utdataene fra en kommando den kjørte. I lang jobb er de det meste av det som sendes.
• En underagent er en hjelper hovedagenten starter for en selvstendig oppgave, for eksempel «sjekk disse kapitlene mot notatene». Den får én instruksjon, og jobber så gjennom mange verktøykall på egen hånd.

Problem 1: underagenter vokste til modellen avviste dem

Hvert steg sender agenten samtalen så langt til modellen. Når den ble for stor, kuttet koden vår den, men bare i starten av en brukermelding, slik at et verktøykall og resultatet aldri ble splittet. Den beholdt første melding, la til en merknad om at tidligere samtale var kuttet, og beholdt de nyeste hele rundene som fikk plass.

En underagent har nøyaktig én brukermelding: instruksjonen sin. Det fantes ingen sted å kutte. Så den sendte hele historikken sin på hvert steg, og den vokste hver gang, til forespørselen var større enn modellen tar imot i det hele tatt, omtrent en million tokens. I en test med 8 slike underagenter ble alle 8 avvist.

Løsningen: fjern gamle verktøyresultater først

Forespørsler passer nå budsjettet i tre trinn, og hvert trinn prøves bare hvis det forrige ikke var nok:

1. Fjern de eldste verktøyresultatene. Innholdet erstattes med en kort merknad: resultatet ble fjernet for å holde samtalen innenfor modellens kontekst, og agenten kan kjøre verktøyet på nytt hvis den trenger det. En fil lest for en time siden er vanligvis det største og minst nyttige i forespørselen, og filen er fortsatt der å lese på nytt. De nyeste resultatene forblir hele.
2. Behold hele brukerrunder. Som før: første melding, en merknad, og de nyeste komplette rundene som får plass.
3. Behold hele verktøyrunder. Innenfor én lang tur, den eneste typen en underagent har, behold første melding, en merknad, og de nyeste komplette rundene med «kall et verktøy, få resultatet».

Dette former bare det som sendes. Agentens lagrede historikk beholder alt. I samme test ble 0 av 8 avvist, og alle 8 ble ferdige.

Fjerning i grupper, så hurtigbufferen fortsatt virker

Modelltilbydere kan gjenbruke arbeid på starten av en forespørsel hvis den er identisk med den forrige. Det er en prefiks-hurtigbuffer. Hvis vi fjernet ett resultat til på hvert kall, ville starten av forespørselen endre seg hvert kall, og hurtigbufferen ville aldri hjelpe.

Derfor fjernes de eldste resultatene fire om gangen, ikke ett. Den fjernede delen forblir da den samme over flere kall. Et resultat som ikke er mye større enn merknaden, lar vi være: å fjerne det ville spart nesten ingenting og likevel endret starten av forespørselen. Hvor mye som forblir helt, avgjøres av størrelse, ikke antall. De nyeste resultatene som får plass i en fjerdedel av budsjettet, blir stående, og alltid minst ett. En tidligere versjon beholdt fast seks hele. Det passet for kort kommandoutdata, men med lange filer lot det det meste av budsjettet gå til gamle resultater.

Avvisninger sier nå fra

En forespørsel modellen avviser som ugyldig, blir ikke lenger forsøkt på nytt. Å sende samme forespørsel igjen gir samme svar. Hvis samtalen er for lang for modellen, ser personen: «Denne samtalen ble for lang for modellen å lese på én gang. Start en ny chat for neste steg. Alt som er bygget så langt, består.» Det er personens sak å handle på, ikke en driftsstans, så det varsler ikke oss.

Problem 2: agenten stoppet for å «spare plass»

En underagent bedt om å lese 40 lange kapitler stoppet etter 2 og sa at den ville spare plass. Den hadde brukt omtrent 100 000 tokens av et budsjett på 400 000.

Den hadde ingen måte å vite at gamle resultater nå ville bli fjernet for den. Så vi fortalte den det. Agentens instruksjoner sier nå at når en samtale vokser forbi det modellen kan ta, fjernes de eldste verktøyresultatene og de nyeste forblir hele. Så ikke stopp en lang oppgave for å spare plass. Fortsett, og les en fil på nytt hvis du trenger det som ble fjernet.

En løsning modellen ikke kan se, er ikke en løsning fra modellens synspunkt. Mekanismen hjelper bare hvis agenten stoler på den.

Problem 3: telle tokens som om alt var engelsk

Vi estimerte tokens uten å kjøre en tokenizer, som tegn delt på fire. Det er en rimelig tommelfingerregel for engelsk. Den er ikke riktig for andre skriftsystemer: russisk går omtrent 2,2 tegn per token, og kinesisk eller japansk omtrent ett.

Så en underagent som leste russiske kapitler, sendte en forespørsel på omtrent 640 000 tokens, mens estimatet vårt sa at den var under 400 000-budsjettet. Estimatet kunne like gjerne ha satt en forespørsel over modellens harde grense.

Estimatet teller nå etter skriftsystem: vanlig ASCII til fire tegn per token, kinesisk, japansk og koreansk til ett, og alt annet, som kyrillisk, gresk, arabisk, aksenttegn og emoji, til to. Det er ment å feile oppover. På ett russisk kapittel estimerer det nå 43 423 tokens mot omtrent 44 600 målt. Før sa det 25 023. Siden en melding aldri endrer seg når den er skrevet, regnes estimatet ut én gang og huskes, i stedet for på hvert steg.

Det vi tok med oss

• Kutt der størrelsen faktisk er. I agentarbeid er det verktøyresultater, ikke brukermeldinger.
• Fortell agenten om sine egne sikkerhetsnett. Ellers planlegger den rundt grenser som ikke lenger gjelder.
• «Tegn delt på 4» er en engelsk antakelse. Alt som teller tokens for flerspråklige brukere, må telle etter skriftsystem, eller bruke en ekte tokenizer.
• Pass på hurtigbufferen. En forespørsel som endrer seg i starten på hvert kall, koster mer og går saktere.

Hvis du bygger AI-funksjoner inn i din egen app, dekker guidene våre om hva en LLM er og hvordan du bruker LLM-API-er kontekstvinduer og tokens fra starten av. Mer om hvordan underagenter fungerer i Mythex finnes i underagent-dokumentasjonen.