Garus aģenta gājienus saglabājam kontekstu logā

Modelis vienlaikus var nolasīt tikai noteiktu daudzumu — savu konteksta logu. Mythex aģents veic garus darbus: nolasa daudzus failus, palaiž komandas, deleģē ierobežotus uzdevumus apakšaģentiem. Mēs atradām trīs veidus, kā garie darbi sabruka: apakšaģenti auga, līdz modelis noraidīja katru pieprasījumu; apakšaģents apstājās agri, jo domāja, ka vairs nav vietas; un mūsu žetonu skaits bija stipri nepareizs krievu, ķīniešu un japāņu tekstam. Lūk, ko mainījām.

Vispirms daži termini

• Žetoni ir gabali, ko modelis nolasa. Ierobežojumi un izmaksas tiek skaitīti žetonos, nevis rakstzīmēs vai vārdos.
• Konteksta logs ir maksimālais, ko modelis var nolasīt vienā pieprasījumā. Mēs arī paredzam savu zemāku budžetu katram pieprasījumam, lai izmaksas un ātrums paliek saprātīgi.
• Rīku rezultāti ir tas, ko aģents saņem atpakaļ no saviem rīkiem: faila saturs, ko tas nolasīja, komandas izvade, ko tas palaida. Garos darbos tie ir lielākā daļa no nosūtītā.
• Apakšaģents ir palīgs, ko galvenais aģents sāk pašpietiekamam uzdevumam, piemēram, „pārbaudi šīs nodaļas pret piezīmēm”. Tas saņem vienu instrukciju un pēc tam strādā caur daudziem rīku izsaukumiem pats.

1. problēma: apakšaģenti auga, līdz modelis tos noraidīja

Katrā solī aģents nosūta modelim sarunu līdz šim. Kad tā kļuva par lielu, mūsu kods to apgrieza, bet tikai lietotāja ziņojuma sākumā, lai rīka izsaukums un tā rezultāts nekad netiktu pārgriezti. Tas saglabāja pirmo ziņojumu, pievienoja piezīmi, ka iepriekšējā saruna tika apgriezta, un paturēja jaunākos pilnos gājienus, kas ietilpa.

Apakšaģentam ir tieši viens lietotāja ziņojums: tā instrukcija. Nebija kur griezt. Tāpēc tas katrā solī nosūtīja visu savu vēsturi, augot ar katru reizi, līdz pieprasījums bija lielāks, nekā modelis vispār pieņem — ap miljonu žetonu. Testā ar 8 šādiem apakšaģentiem visi 8 tika noraidīti.

Risinājums: vispirms notīri vecos rīku rezultātus

Pieprasījumi tagad ietilpst budžetā trijos soļos, katru izmēģinot tikai tad, ja iepriekšējais nepietika:

1. Notīri vecākos rīku rezultātus. To saturs tiek aizstāts ar īsu piezīmi: rezultāts tika notīrīts, lai saruna paliktu modeļa kontekstā, un aģents var palaist rīku vēlreiz, ja tas vajag. Fails, ko nolasīja pirms stundas, parasti ir lielākais un mazāk noderīgais pieprasījuma gabals, un fails joprojām ir pieejams nolasīšanai vēlreiz. Jaunākie rezultāti paliek pilni.
2. Paturi pilnus lietotāja gājienus. Kā agrāk: pirmais ziņojums, piezīme un jaunākie pilnie gājieni, kas ietilpst.
3. Paturi pilnus rīku kārtas. Vienā garā gājienā — vienīgajā tipā, kāds apakšaģentam ir — paturi pirmo ziņojumu, piezīmi un jaunākās pilnās kārtas „izsauc rīku, saņem tā rezultātu”.

Tas maina tikai to, kas tiek nosūtīts. Aģenta saglabātā vēsture saglabā visu. Tajā pašā testā 0 no 8 tika noraidīti, un visi 8 pabeidza.

Notīrīšana partijās, lai kešatmiņa turpinātu darboties

Modeļu nodrošinātāji var atkārtoti izmantot darbu pieprasījuma sākumā, ja tas ir identisks pēdējam — prefiksa kešatmiņa. Ja mēs notīrītu vēl vienu rezultātu katrā izsaukumā, pieprasījuma sākums mainītos katru reizi, un kešatmiņa nekad nepalīdzētu.

Tāpēc vecākos rezultātus notīrām četrus vienlaikus, nevis vienu. Notīrītā daļa tad paliek tāda pati vairākos izsaukumos. Rezultāts, kas nav daudz lielāks par piezīmi, paliek neskarts: tā notīrīšana ietaupītu gandrīz neko un tomēr mainītu pieprasījuma sākumu. To, cik paliek pilns, nosaka izmērs, nevis skaits: jaunākie rezultāti, kas ietilpst ceturtdaļā budžeta, paliek, un vienmēr vismaz viens. Agrākā versija paturēja fiksētus sešus pilnus, kas bija pareizi īsai komandu izvadei, bet ar garām failu nolasīšanām atstāja lielāko daļu budžeta vecajiem rezultātiem.

Kļūdu paziņojumi tagad to saka

Pieprasījumu, ko modelis noraida kā nederīgu, vairs neatkārto; tā paša pieprasījuma nosūtīšana atkal dod to pašu atbildi. Ja saruna modelim ir par garu, persona redz: „Šī saruna bija par garu, lai modelis to nolasītu vienā reizē. Sāc jaunu tērzēšanu nākamajam solim — viss, kas līdz šim izveidots, paliek.” Tas ir personas darāms, nevis dīkstāve, tāpēc tas neizsauc mūsu trauksmi.

2. problēma: aģents apstājās, lai „taupītu vietu”

Apakšaģents, kuram lūdza nolasīt 40 garas nodaļas, apstājās pēc 2, sakot, ka grib taupīt vietu. Tas bija izmantojis aptuveni 100 000 žetonus no 400 000 žetonu budžeta.

Tas nevarēja zināt, ka vecie rezultāti tagad tam tiks notīrīti. Tāpēc mēs to pateicām. Aģenta instrukcijās tagad ir rakstīts, ka, kad saruna aug pāri tam, ko modelis var pieņemt, vecākie rīku rezultāti tiek notīrīti, un jaunākie paliek pilni — tātad neapstājies garu uzdevumu, lai taupītu vietu; turpini, un, ja vajag notīrīto, nolasi failu vēlreiz.

Labojums, ko modelis nevar redzēt, no modeļa viedokļa nav labojums. Mehānisms palīdz tikai tad, ja aģents tam uzticas.

3. problēma: žetonu skaitīšana, it kā viss būtu angliski

Žetonus mēs novērtējām, neizmantojot tokenizatoru, kā rakstzīmes dalītas ar četri. Tas ir saprātīgs aptuvens noteikums angļu valodai. Citiem rakstiem tas nav: krievu valodā ir aptuveni 2,2 rakstzīmes uz žetonu, ķīniešu vai japāņu — aptuveni viena.

Tātad apakšaģents, kas nolasīja krievu nodaļas, nosūtīja pieprasījumu ap 640 000 žetonu, kamēr mūsu novērtējums teica, ka tas ir zem 400 000 budžeta. Novērtējums tikpat viegli varēja pārsniegt modeļa cieto robežu.

Novērtējums tagad skaita pēc rakstu veida: parasts ASCII ar četrām rakstzīmēm uz žetonu, ķīniešu, japāņu un korejiešu — ar vienu, un viss pārējais — kirilica, grieķu, arābu, burti ar diakritiskajām zīmēm, emocijzīmes — ar divām. Tas ir paredzēts, lai kļūdītos uz augšu. Vienā krievu nodaļā tagad tas novērtē 43 423 žetonus pret aptuveni 44 600 izmērītiem; agrāk tas teica 25 023. Tā kā ziņojums, kad rakstīts, nekad nemainās, tā novērtējums tiek aprēķināts vienreiz un atcerēts, nevis katrā solī.

Ko no tā guvām

• Apgriez tur, kur patiesībā ir izmērs. Aģenta darbā tie ir rīku rezultāti, nevis lietotāju ziņojumi.
• Pastāsti aģentam par tā drošības tīkliem. Citādi tas plāno ap ierobežojumiem, kas vairs nav spēkā.
• „Rakstzīmes ÷ 4” ir angļu valodas pieņēmums. Jebkas, kas skaita žetonus daudzvalodu lietotājiem, jāskaita pēc rakstu veida vai jāizmanto īsts tokenizators.
• Ņem vērā kešatmiņu. Pieprasījums, kas katrā izsaukumā mainās sākumā, maksā vairāk un darbojas lēnāk.

Ja savā lietotnē ievieto MI funkcijas, mūsu ceļveži par ko ir LLM un kā izmantot LLM API no sākuma aptver konteksta logus un žetonus. Vairāk par to, kā apakšaģenti darbojas Mythex, ir apakšaģentu dokumentācijā.