Mbajtja e turneve të gjata të agjentit brenda dritares së kontekstit

Një model mund të lexojë vetëm aq sa mund të mbajë njëherësh: dritaren e tij të kontekstit. Agjenti i Mythex bën punë të gjata: lexon shumë skedarë, ekzekuton komanda, u jep punë të kufizuara nën-agjentëve. Gjetëm tri mënyra se si puna e gjatë prishej: nën-agjentët rriteshin derisa modeli refuzonte çdo kërkesë, një nën-agjent ndalonte herët sepse mendonte se nuk kishte më hapësirë, dhe numërimi ynë i tokenëve ishte shumë i gabuar për tekstin rus, kinez dhe japonez. Ja çfarë ndryshuam.

Disa terma së pari

• Tokenët janë copat që lexon një model. Kufijtë dhe kostot numërohen me to, jo me karaktere ose fjalë.
• Dritarja e kontekstit është sa më shumë mund të lexojë një model në një kërkesë. Ne vendosim gjithashtu një buxhet më të ulët për çdo kërkesë, që kostot dhe shpejtësia të mbeten të arsyeshme.
• Rezultatet e mjeteve janë ato që merr agjenti nga mjetet e tij: përmbajtja e një skedari që lexoi, dalja e një komande që ekzekutoi. Në punë të gjatë, ato janë pjesa më e madhe e asaj që dërgohet.
• Një nën-agjent është një ndihmës që agjenti kryesor e nis për një detyrë të pavarur, si “kontrollo këta kapituj me shënimet”. Merr një udhëzim, pastaj punon përmes shumë thirrjesh mjetesh vetë.

Problemi 1: nën-agjentët rriteshin derisa modeli i refuzonte

Çdo hap, agjenti i dërgon modelit bisedën deri atëherë. Kur ajo u bë shumë e madhe, kodi ynë e shkurtonte, por vetëm në fillim të një mesazhi përdoruesi, kështu që një thirrje mjeti dhe rezultati i saj nuk ndaheshin kurrë. Mbaji mesazhin e parë, shtonte një shënim që bisedën e mëparshme e kishte shkurtuar, dhe mbante turnet e plota më të reja që ishin brenda kufirit.

Një nën-agjent ka saktësisht një mesazh përdoruesi: udhëzimin e tij. Nuk kishte ku të priteshe. Kështu dërgonte gjithë historikun e tij në çdo hap, duke u rritur çdo herë, derisa kërkesa ishte më e madhe se ç’pranon modeli fare, rreth një milion tokenë. Në një test me 8 nën-agjentë të tillë, të 8 u refuzuan.

Rregullimi: pastro fillimisht rezultatet e vjetra të mjeteve

Kërkesat tani përshtaten me buxhetin në tre hapa, duke provuar secilin vetëm nëse më parë nuk mjaftoi:

1. Pastro rezultatet më të vjetra të mjeteve. Përmbajtja e tyre zëvendësohet me një shënim të shkurtër: rezultati u pastrua për ta mbajtur bisedën brenda kontekstit të modelit, dhe agjenti mund ta ekzekutojë mjetin përsëri nëse e ka nevojë. Një skedar i lexuar para një ore është zakonisht gjëja më e madhe dhe më pak e dobishme në kërkesë, dhe skedari është akoma aty për ta lexuar përsëri. Rezultatet më të reja mbeten të plota.
2. Mbaji turnet e plota të përdoruesit. Si më parë: mesazhi i parë, një shënim, dhe turnet e plota më të reja që përshtaten.
3. Mbaji raundet e plota të mjeteve. Brenda një turni të vetëm të gjatë, që është i vetmi lloj që ka një nën-agjent, mbaji mesazhin e parë, një shënim, dhe raundet më të reja të plota të “thirr një mjet, merr rezultatin e tij”.

Kjo ndryshon vetëm atë që dërgohet. Historiku i ruajtur i agjentit mban gjithçka. Në të njëjtin test, 0 nga 8 u refuzuan dhe të 8 e përfunduan punën.

Pastrimi në grupe, që cache-i të vazhdojë të punojë

Ofruesit e modeleve mund të ripërdorin punën në fillim të një kërkese nëse është identike me kërkesën e mëparshme, një prefix cache. Nëse pastronim edhe një rezultat më shumë në çdo thirrje, fillimi i kërkesës do të ndryshonte çdo herë dhe cache-i nuk do të ndihmonte kurrë.

Kështu që rezultatet më të vjetra pastrohen katër nga katër, jo një nga një. Pjesa e pastruar mbetet e njëjtë për disa thirrje. Një rezultat që nuk është shumë më i madh se shënimi lihet i paprekur: pastrimi do të kursente pak dhe prapë do të ndryshonte fillimin e kërkesës. Sa mbetet i plotë vendoset nga madhësia, jo nga numri: rezultatet më të reja që përshtaten në një të katërtën e buxhetit mbeten, dhe të paktën një mbetet gjithmonë. Një version më i hershëm mbante gjashtë të plota fikse, që ishte e saktë për daljet e shkurtra të komandave, por me leximet e gjata të skedarëve linte pjesën më të madhe të buxhetit për rezultate të vjetra.

Refuzimet tani e thonë këtë

Një kërkesë që modeli e refuzon si të pavlefshme nuk riprovohet më; dërgimi i së njëjtës kërkesë përsëri jep të njëjtën përgjigje. Nëse biseda është shumë e gjatë për modelin, personi sheh: “Kjo bisedë u bë shumë e gjatë që modeli ta lexojë në një herë. Nis një chat të ri për hapin e radhës; gjithçka e ndërtuar deri tani mbetet.” Kjo është punë që duhet ta bëjë personi, jo një ndërprerje, kështu që nuk i njofton ekipin tonë të operacioneve.

Problemi 2: agjenti ndalonte për të “kursyer hapësirë”

Një nën-agjent që u kërkua të lexonte 40 kapituj të gjatë ndaloi pas 2, duke thënë se donte të kursente hapësirë. Kishte përdorur rreth 100,000 tokenë nga një buxhet 400,000.

Nuk kishte asnjë mënyrë ta dinte se rezultatet e vjetra tani do të pastroheshin për të. Kështu që ia thamë. Udhëzimet e agjentit tani thonë se kur biseda rritet përtej asaj që mund ta marrë modeli, rezultatet më të vjetra të mjeteve pastrohen dhe më të rejat mbeten të plota; prandaj mos e ndal një detyrë të gjatë për të kursyer hapësirë; vazhdo, dhe lexo sërish një skedar nëse të duhet ajo që u pastrua.

Një rregullim që modeli nuk e sheh nuk është rregullim nga pikëpamja e modelit. Mekanizmi ndihmon vetëm nëse agjenti i besonte.

Problemi 3: numërimi i tokenëve sikur çdo gjë të ishte anglisht

I vlerësonim tokenët pa ekzekutuar një tokenizues, si karaktere pjesëtuar me katër. Kjo është një rregull i arsyeshëm për anglishten. Nuk është për shkrime të tjera: rusishtja del rreth 2.2 karaktere për token, kinezishtja ose japonishtja rreth një.

Kështu që një nën-agjent që lexonte kapituj rusisht dërgonte një kërkesë prej rreth 640,000 tokenësh, ndërsa vlerësimi ynë thoshte se ishte nën buxhetin 400,000. Vlerësimi mund të kishte po aq lehtë ta shtynte një kërkesë përtej kufirit të fortë të modelit.

Vlerësimi tani numëron sipas shkrimit: ASCII i thjeshtë me katër karaktere për token, kinezisht, japonisht dhe koreanisht me një, dhe çdo gjë tjetër, si cirilikja, greqishtja, arabishtja, shkronjat me theks dhe emoji, me dy. Është krijuar të gabojë lart. Në një kapitull rus tani vlerëson 43,423 tokenë, ndërsa numërimi i matur ishte rreth 44,600; më parë thoshte 25,023. Meqenëse një mesazh nuk ndryshon kurrë pasi është shkruar, vlerësimi i tij llogaritet një herë dhe mbahet mend, në vend që të bëhet në çdo hap.

Çfarë morëm nga kjo

• Shkurto aty ku është madhësia vërtet. Në punën e agjentit, kjo janë rezultatet e mjeteve, jo mesazhet e përdoruesit.
• I thuaj agjentit për rrjetat e tij të sigurisë. Përndryshe planifikon rreth kufijve që nuk zbatohen më.
• “Karaktere ÷ 4” është një supozim për anglishten. Çdo gjë që numëron tokenë për përdorues shumëgjuhësh duhet të numërojë sipas shkrimit, ose të përdorë një tokenizues të vërtetë.
• Kujdes ndaj cache-it. Një kërkesë që ndryshon në fillim në çdo thirrje kushton më shumë dhe është më e ngadaltë.

Nëse po fut veçori AI në aplikacionin tënd, udhëzuesit tanë për çfarë është një LLM dhe si të përdorësh API-të LLM mbulojnë dritaret e kontekstit dhe tokenët që në fillim. Më shumë për mënyrën se si funksionojnë nën-agjentët në Mythex gjendet në dokumentacionin e nën-agjentëve.