நீண்ட agent turns-ஐ context window-க்குள் வைத்திருத்தல்

ஒரு மாதிரி ஒரே நேரத்தில் படிக்கக்கூடியது குறைவு — அதன் context window. Mythex-இன் agent நீண்ட வேலைகளைச் செய்கிறது: பல கோப்புகளைப் படிப்பது, commands இயக்குவது, வரையறுக்கப்பட்ட வேலைகளை sub-agents-க்குக் கொடுப்பது. நீண்ட வேலை உடைந்த மூன்று வழிகளைக் கண்டோம்: sub-agents மாதிரி எல்லா requests-ஐயும் மறுக்கும் அளவுக்கு வளர்ந்தன; ஒரு sub-agent இடம் தீர்ந்துவிட்டதாக நினைத்து சீக்கிரம் நின்றது; ரஷ்ய, சீன, ஜப்பானிய உரைக்கு எங்கள் token எண்ணிக்கை மிகத் தவறாக இருந்தது. நாங்கள் மாற்றியவை இங்கே.

முதலில் சில சொற்கள்

• Tokens என்பவை மாதிரி படிக்கும் துண்டுகள். வரம்புகளும் செலவுகளும் எழுத்துகளிலோ சொற்களிலோ அல்ல, இவற்றிலேயே எண்ணப்படுகின்றன.
• Context window என்பது ஒரு request-இல் மாதிரி ஒரே நேரத்தில் படிக்கக்கூடிய அதிகபட்சம். செலவும் வேகமும் நியாயமாக இருக்க, ஒவ்வொரு request-க்கும் நாங்களும் ஒரு குறைந்த budget-ஐ அமைக்கிறோம்.
• Tool results என்பது agent அதன் கருவிகளிடமிருந்து திரும்பப் பெறுபவை: அது படித்த கோப்பின் உள்ளடக்கம், அது இயக்கிய command-இன் வெளியீடு. நீண்ட வேலையில், அனுப்பப்படுவதில் பெரும்பகுதி இவைதான்.
• Sub-agent என்பது ஒரு தனித்த பணிக்காக main agent தொடங்கும் உதவியாளர், உதாரணமாக “இந்த அத்தியாயங்களை குறிப்புகளுடன் சரிபார்”. அதற்கு ஒரே ஒரு அறிவுறுத்தல் கிடைக்கும், பின்னர் அது தானாகவே பல கருவி அழைப்புகள் வழியாக வேலை செய்கிறது.

பிரச்சனை 1: மாதிரி மறுக்கும் அளவுக்கு sub-agents வளர்ந்தன

ஒவ்வொரு படியிலும், agent இதுவரை உள்ள உரையாடலை மாதிரிக்கு அனுப்புகிறது. அது மிகப் பெரியதானபோது, எங்கள் குறியீடு அதை வெட்டியது — ஆனால் ஒரு user message-இன் தொடக்கத்தில் மட்டுமே, ஒரு கருவி அழைப்பும் அதன் முடிவும் ஒருபோதும் பிரியக்கூடாது என்பதற்காக. அது முதல் message-ஐ வைத்துக்கொண்டது, முந்தைய உரையாடல் வெட்டப்பட்டது என்ற குறிப்பைச் சேர்த்தது, பொருந்திய புதிய முழு turns-ஐ வைத்துக்கொண்டது.

ஒரு sub-agent-க்கு சரியாக ஒரே ஒரு user message உண்டு: அதன் அறிவுறுத்தல். வெட்ட இடமே இல்லை. ஆகவே அது ஒவ்வொரு படியிலும் முழு வரலாற்றையும் அனுப்பியது; அது ஒவ்வொரு முறையும் வளர்ந்தது, மாதிரி ஏற்கும் அளவுக்கு — சுமார் பத்து லட்சம் tokens — மிகப் பெரியதாகும் வரை. அப்படிப்பட்ட 8 sub-agents சோதனையில், 8-உம் மறுக்கப்பட்டன.

தீர்வு: முதலில் பழைய tool results-ஐ அழி

இப்போது requests மூன்று படிகளில் பட்ஜெட்டுக்குள் பொருந்துகின்றன; முந்தையது போதாவிட்டால் மட்டுமே அடுத்தது முயற்சிக்கப்படும்:

1. பழைய tool results-ஐ அழிக்கவும். அவற்றின் உள்ளடக்கம் ஒரு சிறிய குறிப்பால் மாற்றப்படுகிறது: தொடர்பு மாதிரியின் சாளரத்துக்குள் வைத்திருக்க முடிவு அழிக்கப்பட்டது; agent-க்கு தேவைப்பட்டால் கருவியை மீண்டும் இயக்கலாம். ஒரு மணி நேரத்துக்கு முன் படித்த கோப்பு பொதுவாக கோரிக்கையில் உள்ள மிகப் பெரிய, குறைந்த பயனுள்ள பகுதி; அந்தக் கோப்பு இன்னும் அங்கேயே இருக்கிறது, மீண்டும் படிக்கலாம். புதிய முடிவுகள் முழுமையாக இருக்கும்.
2. முழு user turns-ஐ வைத்திரு. முன்பு போலவே: முதல் message, ஒரு குறிப்பு, பொருந்தும் புதிய முழு turns.
3. முழு tool rounds-ஐ வைத்திரு. ஒரு நீண்ட turn-க்குள் — sub-agent-க்கு உள்ள ஒரே வகை அது — முதல் message, ஒரு குறிப்பு, “ஒரு கருவியை அழை, அதன் முடிவைப் பெறு” என்ற புதிய முழு rounds-ஐ வைத்திரு.

இது அனுப்பப்படுவதை மட்டுமே வடிவமைக்கிறது. Agent-இன் சேமிக்கப்பட்ட வரலாறு எல்லாவற்றையும் வைத்திருக்கிறது. அதே சோதனையில், 8-இல் 0 மறுக்கப்பட்டன; 8-உம் முடிந்தன.

Cache வேலை செய்ய தொகுதிகளாக அழித்தல்

Model providers ஒரு request-இன் தொடக்கத்தை, அது கடைசி request-உடன் அப்படியே ஒத்தால் மீண்டும் பயன்படுத்தலாம் — prefix cache. ஒவ்வொரு அழைப்பிலும் ஒரு முடிவை மேலும் அழித்தால், request-இன் தொடக்கம் ஒவ்வொரு முறையும் மாறும்; cache ஒருபோதும் உதவாது.

ஆகவே பழைய முடிவுகள் ஒவ்வொன்றாக அல்ல, நான்கு நான்காக அழிக்கப்படுகின்றன. அழிக்கப்பட்ட பகுதி பல அழைப்புகளுக்கு ஒரேபோல் இருக்கும். குறிப்பை விட பெரிதாக இல்லாத முடிவு விடப்படுகிறது: அதை அழிப்பதால் கிட்டத்தட்ட எதுவும் சேமிக்கப்படாது, ஆனால் request-இன் தொடக்கம் மாறிவிடும். எவ்வளவு முழுமையாக இருக்கும் என்பது எண்ணிக்கையால் அல்ல அளவால் முடிவாகிறது: பட்ஜெட்டின் கால் பங்கில் பொருந்தும் புதிய முடிவுகள் இருக்கும், குறைந்தது ஒன்றாவது எப்போதும் இருக்கும். ஒரு முந்தைய பதிப்பு நிலையான ஆறு முழுமையாக வைத்தது; அது குறுகிய command வெளியீட்டுக்கு சரியாக இருந்தது, ஆனால் நீண்ட கோப்பு வாசிப்புகளில் பட்ஜெட்டின் பெரும்பகுதியை பழைய முடிவுகளுக்கே விட்டது.

மறுப்புகள் இப்போது அதைச் சொல்கின்றன

மாதிரி தவறானது என்று நிராகரிக்கும் request இனி மீண்டும் முயற்சிக்கப்படாது; அதே request-ஐ மீண்டும் அனுப்பினால் அதே பதில்தான் வரும். உரையாடல் மாதிரிக்கு மிக நீளமாக இருந்தால், நபருக்கு இது தெரியும்: “இந்த உரையாடல் ஒரே முறையில் படிக்கக்கூடியதற்கு மிக நீளமாகிவிட்டது. அடுத்த படிக்கு புதிய chat-ஐத் தொடங்குங்கள் — இதுவரை கட்டப்பட்ட அனைத்தும் அப்படியே இருக்கும்.” அது நபர் செயல்பட வேண்டிய விஷயம், சேவை தடை அல்ல; அதனால் அது எங்களை எழுப்பாது.

பிரச்சனை 2: இடம் “சேமிக்க” agent நின்றது

40 நீண்ட அத்தியாயங்களைப் படிக்கக் கேட்கப்பட்ட ஒரு sub-agent, இடம் சேமிக்க வேண்டும் என்று சொல்லி 2-இல் நின்றது. 400,000 tokens பட்ஜெட்டில் அது சுமார் 100,000 tokens மட்டுமே பயன்படுத்தியிருந்தது.

பழைய முடிவுகள் இப்போது அதற்காக அழிக்கப்படும் என்பது அதற்குத் தெரியாது. அதனால் அதைச் சொன்னோம். Agent-இன் அறிவுறுத்தல்கள் இப்போது சொல்கின்றன: உரையாடல் மாதிரி ஏற்கக்கூடியதைத் தாண்டும்போது, பழைய tool results அழிக்கப்படும், புதியவை முழுமையாக இருக்கும் — ஆகவே நீண்ட பணியை இடம் சேமிக்க நிறுத்தாதீர்கள்; தொடருங்கள், அழிக்கப்பட்டதை நீங்கள் தேவைப்பட்டால் மீண்டும் படியுங்கள்.

மாதிரி பார்க்க முடியாத ஒரு திருத்தம், மாதிரியின் பார்வையில் திருத்தம் அல்ல. Agent அதை நம்பினால் மட்டுமே பொறிமுறை உதவும்.

பிரச்சனை 3: எல்லாமே ஆங்கிலம் போல tokens-ஐ எண்ணுதல்

Tokenizer இயக்காமல், எழுத்துகளை நான்காக வகுத்து tokens-ஐ மதிப்பிட்டோம். ஆங்கிலத்துக்கு இது நியாயமான அளவீடு. ஆனால் மற்ற எழுத்துமுறைகளுக்கு இல்லை: ரஷ்ய மொழி ஒரு token-க்கு சுமார் 2.2 எழுத்துகள்; சீன அல்லது ஜப்பானிய ஒரு token-க்கு சுமார் ஒன்று.

ஆகவே ரஷ்ய அத்தியாயங்களைப் படிக்கும் ஒரு sub-agent சுமார் 640,000 tokens கொண்ட request-ஐ அனுப்பியது; ஆனால் எங்கள் மதிப்பீடு அது 400,000 பட்ஜெட்டுக்குக் கீழே என்று சொன்னது. அந்த மதிப்பீடு ஒரு request-ஐ மாதிரியின் கடின வரம்புக்கு மேல் தள்ளியிருக்கவும் கூடும்.

மதிப்பீடு இப்போது எழுத்துமுறையின்படி எண்ணுகிறது: எளிய ASCII ஒரு token-க்கு நான்கு எழுத்துகள், சீன, ஜப்பானிய, கொரிய ஒரு எழுத்து, மற்றவை — சிரிலிக், கிரேக்கம், அரபி, உச்சரிப்பு எழுத்துகள், emoji — இரண்டு. அது அதிகமாக மதிப்பிடும்படி வடிவமைக்கப்பட்டுள்ளது. ஒரு ரஷ்ய அத்தியாயத்தில் இப்போது அது 43,423 tokens என மதிப்பிடுகிறது; அளக்கப்பட்டது சுமார் 44,600. முன்பு அது 25,023 என்றது. ஒரு message எழுதிய பிறகு மாறாததால், அதன் மதிப்பீடு ஒரு முறை கணக்கிடப்பட்டு நினைவில் வைக்கப்படுகிறது; ஒவ்வொரு படியிலும் மீண்டும் கணக்கிடப்படுவதில்லை.

நாங்கள் கற்றது

• அளவு எங்கே உள்ளதோ அங்கே வெட்டுங்கள். Agent வேலையில் அது tool results; user messages அல்ல.
• Agent-க்கு அதன் சொந்த பாதுகாப்பு வலைகளைப் பற்றிச் சொல்லுங்கள். இல்லையென்றால், பொருந்தாத வரம்புகளைச் சுற்றி அது திட்டமிடும்.
• “எழுத்துகள் ÷ 4” ஒரு ஆங்கில அனுமானம். பல மொழி பயனர்களுக்கு tokens எண்ணும் எதுவும் எழுத்துமுறைப்படி எண்ண வேண்டும், அல்லது உண்மையான tokenizer பயன்படுத்த வேண்டும்.
• Cache-ஐக் கவனியுங்கள். ஒவ்வொரு அழைப்பிலும் தொடக்கம் மாறும் request அதிகம் செலவாகும், மெதுவாக ஓடும்.

உங்கள் சொந்த app-இல் AI அம்சங்களைச் சேர்த்தால், LLM என்றால் என்ன மற்றும் LLM APIs-ஐ எப்படிப் பயன்படுத்துவது வழிகாட்டிகள் context windows மற்றும் tokens-ஐ தொடக்கத்திலிருந்தே விளக்குகின்றன. Mythex-இல் sub-agents எப்படி வேலை செய்கின்றன என்பது பற்றி மேலும் sub-agents docs-இல் உள்ளது.