Երկար agent-ի քայլերը պահել context window-ի սահմաններում

Մոդելը կարող է կարդալ միայն որոշակի քանակով միաժամանակ՝ իր context window-ը։ Mythex-ի agent-ը կատարում է երկար աշխատանք․ կարդում է բազմաթիվ ֆայլեր, գործարկում հրամաններ, սահմանափակ առաջադրանքներ է փոխանցում ենթա-agent-ներին։ Գտանք երկար աշխատանքը կոտրելու երեք եղանակ․ ենթա-agent-ները աճում էին այնքան, որ մոդելը մերժում էր յուրաքանչյուր հարցում, մի ենթա-agent վաղաժամ կանգ էր առնում, քանի որ կարծում էր, թե տեղ չունի, և մեր թոքենների հաշվարկը լրջորեն սխալ էր ռուսերեն, չինարեն և ճապոներեն տեքստի համար։ Ահա, թե ինչ փոխեցինք։

Նախ մի քանի տերմին

• Թոքեններ են այն կտորները, որոնք մոդելը կարդում է։ Սահմանաչափերն ու ծախսերը հաշվվում են դրանցով, ոչ թե նիշերով կամ բառերով։
• Context window-ը այն առավելագույնն է, որ մոդելը կարող է կարդալ մեկ հարցումում։ Մենք նաև սահմանում ենք մեր սեփական, ավելի ցածր բյուջե յուրաքանչյուր հարցման համար, որպեսզի ծախսերն ու արագությունը մնան ողջամիտ։
• Գործիքների արդյունքները այն են, ինչ agent-ը ստանում է իր գործիքներից. կարդացած ֆայլի բովանդակությունը, գործարկած հրամանի ելքը։ Երկար աշխատանքում դրանք ուղարկվող բովանդակության մեծ մասն են։
• Ենթա-agent-ը օգնական է, որ գլխավոր agent-ը սկսում է ինքնուրույն առաջադրանքի համար, օրինակ՝ «ստուգիր այս գլուխները նշումների դեմ»։ Այն ստանում է մեկ հրահանգ և հետո իր վրա աշխատում է բազմաթիվ գործիքային կանչերով։

Խնդիր 1. ենթա-agent-ները աճում էին այնքան, որ մոդելը մերժում էր դրանք

Յուրաքանչյուր քայլում agent-ը մոդելին ուղարկում է մինչ այդ եղած զրույցը։ Երբ դա դառնում էր չափազանց մեծ, մեր կոդը այն կտրում էր, բայց միայն օգտատիրոջ հաղորդագրության սկզբում, որպեսզի գործիքի կանչը և նրա արդյունքը երբեք չբաժանվեին։ Պահում էր առաջին հաղորդագրությունը, ավելացնում մի նշում, որ նախորդ զրույցը կտրվել է, և պահում նորագույն ամբողջական հերթափոխերը, որոնք տեղավորվում էին։

Ու ենթա-agent-ն ունի ճիշտ մեկ օգտատիրոջ հաղորդագրություն՝ իր հրահանգը։ Կտրելու տեղ չկար։ Այն ուղարկում էր ամբողջ պատմությունը յուրաքանչյուր քայլում, աճելով ամեն անգամ, մինչև հարցումը դառնում էր ավելի մեծ, քան մոդելը ընդհանրապես ընդունում է՝ մոտ մեկ միլիոն թոքեն։ Փորձարկումում 8 այդպիսի ենթա-agent-ից բոլոր 8-ը մերժվեցին։

Լուծում. նախ մաքրել հին գործիքների արդյունքները

Հարցումները այժմ տեղավորվում են բյուջեի մեջ երեք քայլով՝ յուրաքանչյուրը միայն այն դեպքում, եթե նախորդը բավարար չէր.

1. Մաքրել ամենահին գործիքների արդյունքները։ Դրանց բովանդակությունը փոխարինվում է կարճ նշումով. արդյունքը մաքրվել է՝ զրույցը մոդելի սահմաններում պահելու համար, և agent-ը կարող է նորից գործարկել գործիքը, եթե պետք լինի։ Մեկ ժամ առաջ կարդացած ֆայլը սովորաբար հարցման ամենամեծ և ամենաքիչ օգտակար մասն է, և ֆայլը դեռ կա, որ նորից կարդացվի։ Նորագույն արդյունքները մնում են ամբողջական։
2. Պահել օգտատիրոջ ամբողջական հերթափոխերը։ Ինչպես նախկինում. առաջին հաղորդագրությունը, նշումը և նորագույն ամբողջական հերթափոխերը, որոնք տեղավորվում են։
3. Պահել գործիքային ամբողջական փուլերը։ Մեկ երկար հերթափոխի ներսում՝ միակ տեսակը, որ ունի ենթա-agent-ը, պահել առաջին հաղորդագրությունը, նշումը և նորագույն ամբողջական փուլերը «կանչիր գործիք, ստացիր արդյունքը»։

Սա միայն ձևավորում է ուղարկվողը։ Agent-ի պահված պատմությունը պահում է ամեն ինչ։ Նույն փորձարկման մեջ 8-ից 0-ը մերժվեցին, և բոլոր 8-ը ավարտեցին։

Մաքրում փաթեթներով, որ քեշը աշխատի

Մոդելի մատակարարները կարող են վերօգտագործել հարցման սկիզբը, եթե այն նույնական է վերջինին. prefix cache։ Եթե մենք յուրաքանչյուր կանչում մեկ էլ արդյունք մաքրեինք, հարցման սկիզբը յուրաքանչյուր կանչում կփոխվեր, և քեշը երբեք չէր օգնի։

Ուստի ամենահին արդյունքները մաքրում ենք չորսական փաթեթներով, ոչ թե մեկ-մեկ։ Մաքրված մասը այդ դեպքում մնում է նույնը մի քանի կանչի ընթացքում։ Արդյունքը, որ շատ մեծ չէ նշումից, թողնվում է անփոփոխ, քանի որ մաքրելը գրեթե ոչինչ չէր խնայի և դարձյալ կփոխեր հարցման սկիզբը։ Ամբողջական մնացող մասը որոշվում է չափով, ոչ քանակով. նորագույն արդյունքները, որոնք տեղավորվում են բյուջեի քառորդում, մնում են, և միշտ գոնե մեկը։ Նախորդ տարբերակը միշտ պահում էր վեց ամբողջական արդյունք, ինչը ճիշտ էր կարճ հրամանների ելքի համար, բայց երկար ֆայլերի կարդալու դեպքում թողնում էր բյուջեի մեծ մասը հին արդյունքներին։

Մերժումները հիմա ասում են դա

Հարցումը, որ մոդելը մերժում է որպես անվավեր, այլևս չի փորձվում նորից. նույն հարցումը նորից ուղարկելը կստանա նույն պատասխանը։ Եթե զրույցը չափազանց երկար է մոդելի համար, մարդը տեսնում է. «Այս զրույցը այնքան երկարացավ, որ մոդելը չի կարող այն մեկ անգամում կարդալ։ Սկսեք նոր չատ հաջորդ քայլի համար. այն ամենը, ինչ արդեն կառուցվել է, մնում է։» Դա մարդու գործն է, որ պետք է անի, ոչ թե խափանում, ուստի մեր թիմին չի զանգահարում։

Խնդիր 2. agent-ը կանգ էր առնում «տեղը խնայելու» համար

Ենթա-agent-ին խնդրել էին կարդալ 40 երկար գլուխ, և այն կանգ առավ 2-ից հետո՝ ասելով, որ ուզում է տեղը խնայել։ Այն օգտագործել էր մոտ 100,000 թոքեն 400,000 թոքենի բյուջեից։

Նա չգիտեր, որ հին արդյունքները այժմ իր համար կմաքրվեն։ Ուստի մենք ասացինք դա։ Agent-ի հրահանգները այժմ ասում են, որ երբ զրույցը աճում է մոդելի կարողությունից այն կողմ, հին գործիքների արդյունքները մաքրվում են, իսկ նորագույնը մնում է ամբողջական, ուստի մի կանգնեք երկար առաջադրանքի մեջտեղում՝ տեղը խնայելու համար. շարունակեք, և եթե պետք է մաքրված բովանդակություն, նորից կարդացեք ֆայլը։

Մոդելը չտեսնող շտկումը մոդելի տեսանկյունից շտկում չէ։ Մեխանիզմն օգնում է միայն այն դեպքում, եթե agent-ը դրան վստահում է։

Խնդիր 3. թոքենները հաշվում էինք, կարծես ամեն ինչ անգլերեն լիներ

Թոքեններ էինք գնահատում առանց tokenizer գործարկելու. նիշերը բաժանած չորսի վրա։ Դա ողջամիտ կանոն է անգլերենի համար։ Այլ գրերի համար չէ. ռուսերենը մոտ 2.2 նիշ է մեկ թոքենի վրա, չինարենն ու ճապոներենը՝ մոտ մեկ։

Ուստի ռուսական գլուխներ կարդացող ենթա-agent-ը ուղարկում էր մոտ 640,000 թոքենի հարցում, մինչդեռ մեր գնահատականը ասում էր, որ այն 400,000 բյուջեից ցածր է։ Գնահատականը նույնքան հեշտ կարող էր հարցումը տանել մոդելի կոշտ սահմանից դուրս։

Գնահատականը այժմ հաշվում է ըստ գրի. սովորական ASCII՝ չորս նիշ մեկ թոքենի վրա, չինարեն, ճապոներեն և կորեերեն՝ մեկ, իսկ մնացածը՝ կիրիլիցա, հունարեն, արաբերեն, շեշտադրված տառերը, emoji՝ երկու։ Այն նախատեսված է ավելի բարձր սխալվելու համար։ Մեկ ռուսերեն գլխի վրա այն այժմ գնահատում է 43,423 թոքեն՝ մոտ 44,600 չափածի դիմաց, մինչդեռ առաջ ասում էր 25,023։ Քանի որ հաղորդագրությունը երբեք չի փոխվում գրվելուց հետո, նրա գնահատականը մեկ անգամ է հաշվվում և հիշվում, այլ ոչ թե յուրաքանչյուր քայլում։

Ինչ սովորեցինք

• Կտրեք այնտեղ, որտեղ իրական չափն է։ Agent-ի աշխատանքում դա գործիքների արդյունքներն են, ոչ օգտատիրոջ հաղորդագրությունները։
• Ասեք agent-ին իր սեփական անվտանգության ցանցի մասին։ Հակառակ դեպքում այն պլանավորում է սահմանների շուրջ, որոնք այլևս չեն գործում։
• «Նիշեր ÷ 4»-ը անգլերենի ենթադրություն է։ Ամեն ինչ, որ թոքեններ է հաշվում բազալեզու օգտատերերի համար, պետք է հաշվի ըստ գրի, կամ օգտագործի իրական tokenizer։
• Հաշվի առեք քեշը։ Հարցումը, որ յուրաքանչյուր կանչում փոխվում է սկզբից, ավելի թանկ է և ավելի դանդաղ։

Եթե ձեր սեփական հավելվածում AI գործառույթներ եք կառուցում, մեր ուղեցույցները ինչ է LLM-ը և ինչպես օգտագործել LLM API-ները context window-ները և թոքենները սկզբից են բացատրում։ Ավելին, թե ինչպես են ենթա-agent-ները աշխատում Mythex-ում, ենթա-agent-ների փաստաթղթերում է։