Context window ની અંદર લાંબા agent turns કેવી રીતે રાખવા

મોડેલ એક સમયે ફક્ત એટલું જ વાંચી શકે છે — તેની context window. Mythex નો agent લાંબું કામ કરે છે: ઘણી ફાઇલો વાંચવી, commands ચલાવવી, બંધિયાર કામો sub-agents ને સોંપવા. અમને લાંબા કામ તૂટવાના ત્રણ રસ્તા મળ્યા: sub-agents એટલા વધ્યા કે મોડેલ દરેક request નકારવા લાગ્યું, એક sub-agent વહેલું અટકી ગયું કારણ કે તેને લાગ્યું કે તેની પાસે જગ્યા ખલાસ છે, અને રશિયન, ચાઇનીઝ અને જાપાનીઝ લખાણ માટે અમારી token ગણતરી ખૂબ ખોટી હતી. અહીં અમે શું બદલ્યું છે.

પહેલા કેટલાક શબ્દો

• Tokens એ ટુકડાઓ છે જે મોડેલ વાંચે છે. મર્યાદાઓ અને ખર્ચ અક્ષરો કે શબ્દોમાં નહીં, પણ તેમાં ગણાય છે.
• Context window એ એક request માં મોડેલ વધુમાં વધુ જેટલું વાંચી શકે તે છે. અમે દરેક request માટે અમારું પોતાનું નીચલું બજેટ પણ સેટ કરીએ છીએ, જેથી ખર્ચ અને ઝડપ વાજબી રહે.
• Tool results એ છે જે agent ને તેના tools પાસેથી પાછું મળે છે: તેણે વાંચેલી ફાઇલનું content, તેણે ચલાવેલા command નું output. લાંબા કામમાં, તે મોકલાતી વસ્તુનો મોટો ભાગ હોય છે.
• Sub-agent એ એક મદદગાર છે જે મુખ્ય agent સ્વતંત્ર કાર્ય માટે શરૂ કરે છે, જેમ કે "આ પ્રકરણોને નોંધો સામે તપાસો". તેને એક સૂચના મળે છે, પછી તે પોતાની રીતે ઘણી tool calls માંથી પસાર થાય છે.

સમસ્યા 1: sub-agents એટલા વધ્યા કે મોડેલ તેમને નકારતું

દરેક પગલે, agent મોડેલને અત્યાર સુધીની વાતચીત મોકલે છે. જ્યારે તે બહુ મોટી થતી, ત્યારે અમારો કોડ તેને કાપતો — પરંતુ ફક્ત user message ની શરૂઆતમાં, જેથી tool call અને તેનું પરિણામ ક્યારેય અલગ ન પડે. તે પહેલો message રાખતો, એક નોંધ ઉમેરતો કે અગાઉની વાતચીત કાપવામાં આવી છે, અને બંધબેસતા નવા આખા turns રાખતો.

Sub-agent પાસે બરાબર એક user message હોય છે: તેની સૂચના. ત્યાં કાપવાની જગ્યા નહોતી. તેથી તે દરેક પગલે તેનો આખો ઇતિહાસ મોકલતું, દરેક વખતે વધતું, જ્યાં સુધી request મોડેલ સ્વીકારે તેના કરતાં મોટી ન થઈ જાય — લગભગ દસ લાખ tokens. 8 આવા sub-agents ની એક test માં, બધા 8 નકારાયા.

ઉકેલ: પહેલા જૂના tool results સાફ કરો

હવે requests ત્રણ પગલામાં બજેટમાં બંધબેસે છે, દરેક ત્યારે જ પ્રયાસ કરાય જો તેની પહેલાનું પગલું પૂરતું ન હોય:

1. સૌથી જૂના tool results સાફ કરો. તેમનું content એક ટૂંકી નોંધ સાથે બદલાય છે: પરિણામ મોડેલની context ની અંદર રહેવા માટે સાફ કરાયું હતું, અને agent ને જરૂર હોય તો તે tool ફરી ચલાવી શકે છે. એક કલાક પહેલાં વાંચેલી ફાઇલ સામાન્ય રીતે request માં સૌથી મોટી અને ઓછામાં ઓછી ઉપયોગી વસ્તુ હોય છે, અને ફાઇલ ફરી વાંચવા માટે હજી ત્યાં છે. સૌથી નવા પરિણામો આખા રહે છે.
2. આખા user turns રાખો. પહેલાંની જેમ: પહેલો message, એક નોંધ, અને બંધબેસતા સૌથી નવા સંપૂર્ણ turns.
3. આખા tool rounds રાખો. એક લાંબા turn ની અંદર — જ એક પ્રકાર જે sub-agent પાસે હોય — પહેલો message, એક નોંધ, અને "tool ને call કરો, તેનું પરિણામ મેળવો" ના સૌથી નવા સંપૂર્ણ rounds રાખો.

આ ફક્ત મોકલાતી વસ્તુને આકાર આપે છે. agent નો સાચવેલો ઇતિહાસ બધું રાખે છે. એ જ test માં, 8 માંથી 0 નકારાયા અને બધા 8 પૂરા થયા.

બેચમાં સાફ કરવું, જેથી caching કામ કરતું રહે

Model providers એક request ની શરૂઆતનું કામ ફરી વાપરી શકે છે જો તે છેલ્લી request જેવું જ હોય — એક prefix cache. જો અમે દરેક call પર બીજું એક result સાફ કરીએ, તો request ની શરૂઆત દરેક call બદલાતી, અને cache ક્યારેય મદદ ન કરતું.

તેથી જૂના results ચાર-ચારના બેચમાં સાફ થાય છે, એક-એક નહીં. સાફ થયેલો ભાગ પછી ઘણી calls દરમિયાન એકસરખો રહે છે. નોંધ કરતાં બહુ મોટું ન હોય એવું પરિણામ છોડી દેવાય છે: તેને સાફ કરવાથી લગભગ કંઈ બચે નહીં અને તોપણ request ની શરૂઆત બદલાય. કેટલું આખું રહે તે ગણતરીથી નહીં, કદથી નક્કી થાય છે: સૌથી નવા પરિણામો જે બજેટના એક ચતુર્થાંશમાં બંધબેસે તે રહે, અને હંમેશાં ઓછામાં ઓછું એક. એક જૂના સંસ્કરણે નિશ્ચિત છ આખા રાખ્યા હતા, જે ટૂંકા command output માટે યોગ્ય હતું, પરંતુ લાંબી ફાઇલ વાંચનો સાથે મોટાભાગનું બજેટ જૂના પરિણામોને આપી દેતું.

નકારો હવે કહે છે કે શું થયું

મોડેલ જેને અમાન્ય તરીકે નકારે તે request હવે ફરીથી પ્રયાસ થતી નથી; એ જ request ફરી મોકલવાથી એ જ જવાબ મળે છે. જો વાતચીત મોડેલ માટે બહુ લાંબી હોય, તો વ્યક્તિ જુએ છે: "વાતચીત મોડેલ એક વારમાં વાંચી શકે તેના માટે બહુ લાંબી થઈ ગઈ. આગલા પગલા માટે નવી chat શરૂ કરો — અત્યાર સુધી બનાવેલું બધું રહેશે." તે વ્યક્તિએ કરવાની બાબત છે, કોઈ outage નથી, તેથી તે અમને page કરતું નથી.

સમસ્યા 2: agent "રૂમ બચાવવા" માટે અટકી ગયો

40 લાંબા પ્રકરણો વાંચવાનું કહેવાયેલો sub-agent 2 પછી અટકી ગયો, કહેતો કે તેને રૂમ બચાવવો છે. તેણે 400,000-token બજેટ માંથી લગભગ 100,000 tokens વાપર્યા હતા.

તેને ખબર નહોતી કે હવે તેના માટે જૂના results સાફ થશે. તેથી અમે તેને કહ્યું. agent ની સૂચનાઓ હવે કહે છે કે જ્યારે વાતચીત મોડેલ લઈ શકે તેનાથી આગળ વધે, ત્યારે જૂના tool results સાફ થાય છે અને સૌથી નવા આખા રહે છે — તેથી લાંબું કામ રૂમ બચાવવા માટે અટકાવશો નહીં; આગળ વધતા રહો, અને સાફ થયેલું જોઈતું હોય તો ફાઇલ ફરી વાંચો.

જે fix મોડેલ જોઈ શકતું નથી તે મોડેલના દૃષ્ટિકોણથી fix નથી. આ મિકેનિઝમ ત્યારે જ મદદ કરે છે જ્યારે agent તેના પર વિશ્વાસ કરે.

સમસ્યા 3: ભાષા પ્રમાણે નહીં, જાણે બધું અંગ્રેજી હોય તેમ tokens ગણવા

અમે tokens ને tokenizer ચલાવ્યા વિના અંદાજ્યા: અક્ષરો ÷ 4. અંગ્રેજી માટે તે વાજબી rule of thumb છે. અન્ય લિપિઓ માટે નથી: રશિયન લગભગ 2.2 અક્ષરો પ્રતિ token ચાલે છે, અને ચાઇનીઝ કે જાપાનીઝ લગભગ એક.

તેથી રશિયન પ્રકરણો વાંચતો sub-agent લગભગ 640,000 tokens ની request મોકલતો, જ્યારે અમારો અંદાજ કહેતો કે તે 400,000 બજેટ કરતાં ઓછી છે. એ અંદાજ એટલી જ સરળતાથી request ને મોડેલની સખત મર્યાદા ઉપર ધકેલી શક્યો હોત.

અંદાજ હવે લિપિ પ્રમાણે ગણે છે: સાદા ASCII ચાર અક્ષર પ્રતિ token, ચાઇનીઝ, જાપાનીઝ અને કોરિયન એક, અને બાકીનું બધું — Cyrillic, Greek, Arabic, accented letters, emoji — બે. તે ઊંચું અંદાજવા માટે બનાવાયેલ છે. એક રશિયન પ્રકરણ પર તે હવે 43,423 tokens નો અંદાજ કાઢે છે, જ્યારે લગભગ 44,600 માપવામાં આવ્યા; પહેલાં તે 25,023 કહેતું. સંદેશ એકવાર લખાયા પછી ક્યારેય બદલાતો નથી, તેથી તેનો અંદાજ એકવાર ગણાય છે અને યાદ રખાય છે, દરેક પગલે ફરી નહીં.

અમે શું શીખ્યા

• કદ ક્યાં છે ત્યાં કાપો. agent ના કામમાં, તે tool results છે, user messages નહીં.
• Agent ને તેની પોતાની safety nets વિશે કહો. નહીંતર તે એવી મર્યાદાઓની આસપાસ યોજના કરે છે જે હવે લાગુ પડતી નથી.
• "અક્ષરો ÷ 4" એ અંગ્રેજી ધારણા છે. બહુભાષી વપરાશકર્તાઓ માટે tokens ગણનાર કંઈપણે લિપિ પ્રમાણે ગણવું જોઈએ, અથવા સાચું tokenizer વાપરવું જોઈએ.
• Cache નું ધ્યાન રાખો. દરેક call પર આગળના ભાગે બદલાતી request વધુ ખર્ચાળ અને ધીમી હોય છે.

જો તમે તમારી પોતાની app માં AI સુવિધાઓ બનાવતા હો, તો અમારી guides LLM શું છે અને LLM APIs કેવી રીતે વાપરવા શરૂઆતથી context windows અને tokens આવરી લે છે. Mythex માં sub-agents કેવી રીતે કામ કરે છે તે વિશે વધુ sub-agents docs માં છે.