Why Production LLM Agents Blow Up Their Bills – The Hidden Token Bloat

உங்கள் LLM-ஆல் இயங்கும் ஏஜென்ட் (agent) ஒரு டெமோவில் (demo) சிறப்பாகச் செயல்படலாம், ஆனால் சில முறைகளுக்குப் பிறகு அதன் வேகம் குறைந்து, கட்டணம் (bill) மிக அதிகமாக உயரக்கூடும். இதற்குப் பின்னால் இருக்கும் மறைமுகக் காரணம் ஒரு நிலையற்ற மாடல் (flaky model) அல்ல—அதுதான் 'டோக்கன் டிரிஃப்ட்' (token drift). அதாவது, மாடல் ஒவ்வொரு முறையும் செயலாக்க வேண்டிய பிராம்ப்ட் (prompt) படிப்படியாக அதிகரித்துக் கொண்டே செல்வதாகும்.

ஒவ்வொரு உரையாடலும் மாடலின் உள்ளீட்டு சூழலில் (input context) கூடுதல் உரையைச் சேர்க்கும்போது டோக்கன் டிரிஃப்ட் ஏற்படுகிறது. உரையாடல் வரலாறு, டூல் ஸ்கீமாக்கள் (tool schemas), API பதில்கள் மற்றும் பெறப்பட்ட ஆவணங்கள் என அனைத்தும் சேர்ந்து கொண்டே வருவதால், அடுத்தடுத்த அழைப்புகள் (calls) அதிகப்படியான தரவுகளைக் (payload) கொண்டு வருகின்றன. உள்ளீட்டு டோக்கன்களின் எண்ணிக்கைக்கு ஏற்ப மாடலின் செயலாக்க நேரமும் விலையும் அதிகரிப்பதால், செலவு நேரியல் முறையில் (linearly) இல்லாமல் இருபடி முறையில் (quadratically) உயர்கிறது.

ஏன் இந்தத் பிரச்சனை டெமோக்களில் தெரியாமல் தயாரிப்புச் சூழலில் (production) மட்டும் தெரிகிறது?

உண்மையான பயன்பாடுகள் (deployments) அனைத்தையும் சேமித்து வைக்கின்றன: பயனரின் ஒவ்வொரு சொல்லும், ஒவ்வொரு டூல் வெளியீடும், பெறப்பட்ட அறிவின் ஒவ்வொரு பகுதியும் அப்படியே இருக்கும். தாமதம் (latency) அதிகரிப்பதும், இன்வாய்ஸ் (invoice) வந்து சேருவதும் வரை இந்தத் திரட்டல் மறைந்தே இருக்கும்.

டோக்கன் டிரிஃப்ட்டின் பொதுவான காரணங்கள்

• மீண்டும் மீண்டும் வரும் டிரான்ஸ்கிரிப்ட்கள் (Repeated transcripts) – பழைய செய்திகளைச் சுருக்குவதற்குப் பதிலாக அல்லது நீக்குவதற்குப் பதிலாக, ஒவ்வொன்றையும் பிராம்ப்ட்டில் வைத்திருப்பது.
• கனமான டூல் ஸ்கீமாக்கள் (Heavy tool schemas) – ஒவ்வொரு முறையும் டூல் திறன்களுக்கான பெரிய JSON வரையறைகளை (definitions) அனுப்புவது.
• அதிகப்படியான டூல் முடிவுகள் (Bulky tool results) – ஏஜென்ட்டிற்குத் தேவையானதை விட அதிகமான தரவுகளைக் கொண்ட முழுமையான API பதில்கள் அல்லது டேட்டாபேஸ் வரிசைகளை (database rows) சேர்ப்பது.
• RAG வீக்கம் (RAG bloat) – பல ஆவணத் துண்டுகளைச் சேர்க்கும் Retrieval-augmented generation (RAG) முறை, இதில் சில துண்டுகள் காலாவதியானதாகவோ அல்லது தேவையற்றதாகவோ இருக்கலாம்.
• இரட்டிப்பான நினைவகம் (Duplicated memory) – ஒரு சுருக்கம் (summary), ஒரு ஸ்டேட் ஆப்ஜெக்ட் (state object) மற்றும் மூல டிரான்ஸ்கிரிப்ட் ஆகிய மூன்றையும் ஒன்றாகச் சேர்ப்பது, இது ஒரே தகவலை மூன்று முறை மீண்டும் சொல்கிறது.

இவை ஒவ்வொன்றும் புதிய பகுத்தறிவுத் திறனை (reasoning power) வழங்காமல், பிராம்ப்ட் அளவை மட்டுமே அதிகரிக்கின்றன.

டோக்கன் பட்ஜெட்டை எவ்வாறு கட்டுப்பாட்டில் வைத்திருப்பது?

1. அடுக்குமுறை சூழல் வடிவமைப்பை (layered context design) பின்பற்றுங்கள்

• நிலையான அறிவுறுத்தல்கள் (Stable instructions) – சிஸ்டம் பிராம்ப்ட்கள் (system prompts) மற்றும் பாதுகாப்பு விதிகளைத் தொடக்கத்தில் வைத்துக்கொள்ளுங்கள்; அவற்றை ஒவ்வொரு முறையும் மீண்டும் அனுப்புவதற்குப் பதிலாக, அவற்றைக் குறிப்பிடுங்கள் (reference).
• கட்டமைக்கப்பட்ட நிலை (Structured state) – இலக்குகள், முடிவுகள் மற்றும் அடையாளங்காட்டிகளின் (identifiers) சுருக்கமான வடிவத்தைச் சேமித்து வையுங்கள், இதை ஏஜென்ட் விரைவாகப் படிக்க முடியும்.
• சுருக்கப்பட்ட வரலாறு (Compressed history) – பழைய உரையாடல்களை ஒரு சிறிய, மனிதர்கள் எளிதில் வாசிக்கக்கூடிய பத்தியாகச் சுருக்குங்கள்; ஒரு குறிப்பிட்ட வரம்பு (threshold) எட்டப்படும்போது மட்டும் புதுப்பிக்கவும்.
• சமீபத்திய உரையாடல்கள் (Recent turns) – தொடர்ச்சியைப் பேண, கடைசி சில செய்திகளை அப்படியே (verbatim) சேர்க்கவும்.

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

2. டூல் வெளியீடுகளைக் குறைக்கவும் (Trim tool outputs)

• ஏஜென்ட் உண்மையில் பயன்படுத்தும் புலங்களை (fields) மட்டும் பிரித்தெடுக்கவும்; விரிவான விளக்கங்களைத் தவிர்க்கவும்.
• பெரிய முடிவுகளுக்குப் பதிலாக ஒரு சுருக்கமான விளக்கம் அல்லது ஒரு ரெஃபரன்ஸ் ஐடியை (reference ID) பயன்படுத்தவும்; முழுமையான தரவை (payload) ஒரு டேட்டாபேஸ், கேச் (cache) அல்லது பிளாப் ஸ்டோரில் (blob store) சேமிக்கவும்.
• ஒரு டூல் பட்டியலைத் தரும்போது, தற்போதைய முடிவுக்குத் தேவையான முக்கியமான முதல் N பொருட்களை மட்டும் அனுப்பவும்.

3. புத்திசாலித்தனமான சுருக்கத்தைப் பயன்படுத்துங்கள் (Apply smart summarization)

• ஒவ்வொரு முறையும் சுருக்குவதைத் தவிர்க்கவும்; கூடுதல் செயலாக்கம் கூடுதல் சுமையைத் (overhead) தரும்.
• பழைய உரையாடல்களின் மொத்த டோக்கன் எண்ணிக்கை ஒரு குறிப்பிட்ட வரம்பைத் தாண்டும்போது மட்டும் சுருக்கத்தைப் புதுப்பிக்கவும்.
• முக்கியமான தகவல்களை—ஐடிக்கள் (IDs), தொகைகள், நேர முத்திரைகள் (timestamps)—விளக்க உரையில் (prose) இணைப்பதற்குப் பதிலாக, ஒரு கட்டமைக்கப்பட்ட சேமிப்பகத்தில் (structured store) வைத்திருங்கள்; இதனால் சுருக்கம் சுருக்கமாக இருக்கும்.

4. சரியான அளவீடுகளைக் (metrics) கண்காணிக்கவும்

• டோக்கன் பயன்பாட்டை வெறும் பயனர் கோரிக்கைக்கு (user request) மட்டும் கணக்கிடாமல், ஒவ்வொரு மாடல் அழைப்பிற்கும் (per model call) பதிவு செய்யவும். இது உள்ளீட்டுப் பக்கத்தில் மறைந்திருக்கும் வளர்ச்சியை வெளிப்படுத்தும்.
• ஒவ்வொரு முறையும் சேர்க்கப்படும் உள்ளீட்டு டோக்கன்களின் எண்ணிக்கையைக் கண்காணிக்கவும்; திடீர் உயர்வு டோக்கன் டிரிஃப்ட்டின் மூலத்தைக் காட்டும்.
• கேச் செய்யப்பட்ட டோக்கன்களை (cached tokens - முந்தைய அழைப்புகளிலிருந்து மீண்டும் பயன்படுத்தப்படுபவை) புதிதாக உருவாக்கப்பட்ட டோக்கன்களிலிருந்து பிரிக்கவும்; முந்தைய அழைப்புகளிலிருந்து வரும் டோக்கன்களே டிரிஃப்ட்டிற்கு முக்கியக் காரணம்.

பிராம்ப்ட்டை ஒரு முடிவற்ற டிரான்ஸ்கிரிப்ட்டாகப் பார்க்காமல், ஒரு வரையறுக்கப்பட்ட வளமாக (finite resource) கருதுங்கள். திட்டமிட்டு அளவிடுவதன் மூலம், சுருக்குவதன் மூலம் மற்றும் குறைப்பதன் மூலம், உங்கள் LLM ஏஜென்ட்டை வேகமாகவும், மலிவாகவும் மற்றும் தயாரிப்பு அளவிற்கேற்ப (production scale) தயார் நிலையில் வைத்திருக்க முடியும்.

சுருக்கம் (Takeaway): டோக்கன் டிரிஃப்ட் செலவுகளை அமைதியாக உயர்த்துகிறது மற்றும் ஏஜென்ட்களின் வேகத்தைக் குறைக்கிறது. உங்கள் பிராம்ப்ட்டின் வளரும் பகுதிகளைக் கண்டறிந்து, அவற்றைச் சுருக்கவும் அல்லது வெளிப்புறமாக்கவும் (externalize), மேலும் ஒவ்வொரு அழைப்பிற்கும் டோக்கன் பயன்பாட்டைக் கண்காணிக்கவும். ஒரு ஒழுக்கமான அணுகுமுறை, கணிக்க முடியாத கட்டண அதிர்ச்சிகளை (bill shocks) நிர்வகிக்கக்கூடிய, பட்ஜெட்டுக்கு ஏற்ற செயல்பாடாக மாற்றும்.