Hosszú ügynöki körök a kontextusablakon belül

Egy modell egyszerre csak annyit tud olvasni — ez a kontextusablaka. A Mythex ügynöke hosszú munkát végez: sok fájlt olvas, parancsokat futtat, és behatárolt feladatokat ad át al-ügynököknek. Három módon romlott el a hosszú munka: az al-ügynökök addig nőttek, amíg a modell minden kérést el nem utasított, egy al-ügynök korán megállt, mert azt hitte, nincs elég helye, a tokenszámlálásunk pedig erősen pontatlan volt orosz, kínai és japán szövegen. Íme, mit változtattunk.

Először néhány fogalom

• A tokenek azok a darabok, amelyeket a modell olvas. A korlátok és a költségek ezekben mérődnek, nem karakterben vagy szóban.
• A kontextusablak az a legtöbb, amit a modell egyetlen kérésben el tud olvasni. Mi emellett saját, alacsonyabb keretet is megadunk minden kérésre, hogy a költségek és a sebesség ésszerű maradjon.
• Az eszközeredmények azok, amiket az ügynök az eszközeitől kap vissza: egy beolvasott fájl tartalma, egy lefuttatott parancs kimenete. Hosszú munkában ezek teszik ki a küldött anyag nagy részét.
• Egy al-ügynök egy segítő, amelyet a fő ügynök egy önálló feladatra indít, például „ellenőrizd ezeket a fejezeteket a jegyzetek alapján”. Egyetlen utasítást kap, majd sok eszközhíváson keresztül önállóan dolgozik.

1. probléma: az al-ügynökök addig nőttek, amíg a modell el nem utasította őket

Minden lépésben az ügynök elküldi a modellnek az eddigi beszélgetést. Ha az túl nagy lett, a kódunk megvágta — de csak egy felhasználói üzenet elejénél, így egy eszközhívás és az eredménye sosem vált szét. Megtartotta az első üzenetet, hozzáadott egy megjegyzést, hogy a korábbi beszélgetés meg lett vágva, és a legfrissebb teljes köröket tartotta meg, amelyek beleférnek.

Az al-ügynöknek pontosan egy felhasználói üzenete van: az utasítása. Nem volt hol vágni. Így minden lépésben a teljes előzményét elküldte, és az egyre nőtt, míg a kérés már nagyobb lett, mint amit a modell egyáltalán elfogad — kb. egymillió token. Egy tesztben 8 ilyen al-ügynökből mind a 8-at elutasították.

A javítás: előbb a régi eszközeredmények törlése

A kérések most három lépésben férnek bele a keretbe, és mindegyiket csak akkor próbáljuk, ha az előző nem volt elég:

1. A legrégebbi eszközeredmények törlése. A tartalmukat egy rövid megjegyzés váltja fel: az eredményt a beszélgetés modellkorláton belül tartása érdekében törölték, és az ügynök szükség esetén újra futtathatja az eszközt. Egy órával ezelőtt beolvasott fájl általában a legnagyobb és legkevésbé hasznos dolog a kérésben, és a fájl továbbra is újra beolvasható. A legújabb eredmények teljesek maradnak.
2. Teljes felhasználói körök megtartása. Ahogy eddig: az első üzenet, egy megjegyzés, és a legújabb teljes körök, amelyek beleférnek.
3. Teljes eszközkörök megtartása. Egy hosszú körön belül — ez az egyetlen fajta, amivel egy al-ügynök dolgozik — megtartjuk az első üzenetet, egy megjegyzést, és a legújabb teljes „eszközt hívok, megkapom az eredményét” köröket.

Ez csak azt szabályozza, mi megy el. Az ügynök mentett előzménye mindent megtart. Ugyanebben a tesztben 0 az elutasított, és mind a 8 befejezte.

Törlés kötegekben, hogy a gyorsítótár működjön

A modellszolgáltatók újra felhasználhatják egy kérés elejének munkáját, ha az azonos az előzővel — ez a prefix-gyorsítótár. Ha minden hívásban eggyel többet törölnénk, a kérés eleje minden hívásban megváltozna, és a gyorsítótár sosem segítene.

Ezért a legrégebbi eredményeket négyesével töröljük, nem egyesével. A törölt rész így több hívás alatt is ugyanaz marad. Az olyan eredményt, amely alig nagyobb a megjegyzésnél, érintetlenül hagyjuk: a törlése szinte semmit nem spórolna, és mégis megváltoztatná a kérés elejét. Azt, hogy mi marad teljes, méret határozza meg, nem darabszám: a legújabb eredmények maradnak, amelyek a keret egynegyedébe férnek, és mindig legalább egy. Egy korábbi verzió fixen hat teljes eredményt tartott meg, ami rövid parancskimenetnél jó volt, de hosszú fájlolvasásnál a keret nagy részét a régi eredményekre hagyta.

A visszautasítások most megmondják, mi a helyzet

Az érvénytelennek jelölt kérést a modell már nem próbáljuk újra; ugyanazt a kérést újraküldve ugyanazt a választ kapnánk. Ha a beszélgetés túl hosszú a modellnek, a személy ezt látja: „Ez a beszélgetés túl hosszú ahhoz, hogy a modell egyszerre elolvassa. Kezdj új csevegést a következő lépéshez — az eddig épített minden megmarad.” Ez a személy dolga, nem kimaradás, ezért nem riasztja az ügyeletet.

2. probléma: az ügynök „helyet spórolni” akart megállni

Egy al-ügynök, amelyet 40 hosszú fejezet beolvasására kértek, 2 után megállt, azzal, hogy helyet akar spórolni. Kb. 100 000 tokent használt el egy 400 000 tokenes keretből.

Nem tudhatta, hogy a régi eredmények most automatikusan törlődnek helyette. Ezért megmondtuk neki. Az ügynök utasításai most leírják: ha a beszélgetés a modell által kezelhető méret fölé nő, a legrégebbi eszközeredmények törlődnek, a legújabbak teljesek maradnak — tehát ne állj meg egy hosszú feladat közepén helyet spórolni; menj tovább, és ha kell, olvass újra egy fájlt, amely törlődött.

Az a javítás, amelyet a modell nem lát, a modell szemszögéből nem javítás. A mechanizmus csak akkor segít, ha az ügynök megbízik benne.

3. probléma: a tokeneket úgy számoltuk, mintha minden angol lenne

A tokeneket tokenizáló nélkül becsültük: karakterek osztva néggyel. Ez angolra jó átlagos becslés, más írásrendszereknél nem az. Az oroszban körülbelül 2,2 karakter jut egy tokenre, a kínaiban vagy japánban nagyjából egy.

Az orosz fejezeteket olvasó al-ügynök így kb. 640 000 tokenes kérést küldött, miközben a becslésünk szerint a 400 000-es keret alatt volt. A becslés ugyanúgy túllőhetett volna a modell kemény határán is.

A becslés most írásrendszer szerint számol: a sima ASCII négy karakter/token, a kínai, japán és koreai egy karakter/token, minden más — cirill, görög, arab, ékezetes betűk, emoji — kettő. Szándékosan magasra téved. Egy orosz fejezeten most 43 423 tokent becsül, miközben a mért érték kb. 44 600; korábban 25 023-at mondott. Mivel egy üzenet megírás után sosem változik, a becslését egyszer számoljuk ki és megjegyezzük, nem minden lépésben újra.

Mit vittünk ebből magunkkal

• A vágást oda tedd, ahol a méret van. Az ügynöki munkában ez az eszközeredmény, nem a felhasználói üzenet.
• Mondd meg az ügynöknek a saját biztonsági hálóit. Különben olyan korlátok köré tervez, amelyek már nem érvényesek.
• A „karakter ÷ 4” angol feltételezés. Bármi, ami többnyelvű felhasználók tokenjeit számolja, írásrendszer szerint kell számoljon, vagy valódi tokenizálót kell használjon.
• Vigyázz a gyorsítótárra. Egy kérés, amely minden hívásban az elején változik, többe kerül és lassabb.

Ha saját appodba építesz AI-funkciókat, az mi az LLM és a hogyan használj LLM API-kat útmutatóink az elejétől fogva lefedik a kontextusablakot és a tokeneket. Az al-ügynökök működéséről a Mythexben a al-ügynök dokumentáció ad többet.