ஒவ்வொரு பெரிய மொழி மாதிரிக்கான (LLM) அழைப்பும் உங்கள் பட்ஜெட்டைப் பாதிக்கிறது மற்றும் உங்கள் பயனர்களின் பொறுமையைச் சோதிக்கிறது. ஐம்பது பேர் ஏறத்தாழ ஒரே விஷயத்தைக் கேட்டால், பாரம்பரிய உள்கட்டமைப்பு ஐம்பது தனித்தனி API கோரிக்கைகளைச் செயலாக்கச் செய்கிறது. ஏனெனில் வழக்கமான கேச்சிங் (caching) துல்லியமான எழுத்துத் தொடர்களை (strings) மட்டுமே கருத்தில் கொள்கிறது. இது “What is the capital of France?” மற்றும் “Tell me the capital city of France” ஆகியவற்றைத் தொடர்பில்லாத இரண்டு கேள்விகளாகக் கருதுகிறது. Semantic caching என்பது எழுத்துக்களுக்குப் பதிலாக நோக்கத்தைப் (intent) படிக்கிறது. இரண்டு பயனர்களும் பாரிஸையே விரும்புகிறார்கள் என்பதை இது உணர்ந்து, பதிலைத் ஒருமுறை சேமித்து வைத்து, மாதிரியை (model) மீண்டும் அழைக்காமலேயே அதைத் திரும்ப வழங்குகிறது.
துல்லியமான பொருத்தம் (Exact Match) ஏன் போதாது?
Redis, Memcached அல்லது ஒரு எளிய in-memory map என எதுவாக இருந்தாலும், சாவிகள் (keys) கணிக்கக்கூடியதாக இருக்கும்போது நிலையான கேச்சிங் சிறப்பாகச் செயல்படும். ஒரு தயாரிப்பு ஐடி (product ID), பயனர் பெயர் அல்லது URL slug ஆகியவற்றின் எழுத்துப்பிழை மாறாது. ஆனால், மொழி என்பது குழப்பமானது. பயனர்கள் வாக்கியங்களை மாற்றி அமைப்பார்கள், எழுத்துப் பிழைகள் செய்வார்கள், மரியாதையான சொற்களைச் சேர்ப்பார்கள் அல்லது சில சொற்களைத் தவிர்த்துவிடுவார்கள். ஒரு சப்போர்ட் பாட் (support bot) “how do I reset my password?” என்ற கேள்வியைப் பார்த்த பிறகு, பத்து நிமிடங்களுக்குப் பின் “forgotten password help” என்ற கேள்வியைப் பெறலாம். ஒரு துல்லியமான பொருத்தம் (exact-match) அடுக்கு, இவை இரண்டும் வெவ்வேறு பைட் வரிசைகள் (byte sequences) என்று கருதி உங்களுக்கு இருமுறை கட்டணம் வசூலிக்கும். இதைத் தினசரி ஆயிரக்கணக்கான தொடர்புகளுடன் பெருக்கினால், அந்த வீணடிப்பு மிகுந்த செலவு பெரும் பாதிப்பை ஏற்படுத்தும். Semantic caching, பொருத்தும் தர்க்கத்தை (matching logic) வெறும் உரையில் இருந்து பொருளின் இடத்திற்கு (meaning space) மாற்றுவதன் மூலம் இதைத் தீர்க்கிறது.
இது உண்மையில் எவ்வாறு செயல்படுகிறது?
கணிதப் பாடப்புத்தகங்கள் சொல்வதை விட இந்த செயல்முறை மிகவும் எளிமையானது.
கேள்வியைச் குறியீடாக்குதல் (Encoding the question). ஒரு வினவல் வரும்போது, ஒரு embedding model அதன் பொருளை ஒரு வெக்டராக (vector) சுருக்குகிறது; இது உண்மையில் மிதவைப்புள்ளி எண்களின் (floating-point numbers) ஒரு நீண்ட பட்டியல் மட்டுமே. இதை மொழிக்கான GPS ஆயத்தொலைவுகள் (coordinates) என்று நினைத்துக் கொள்ளுங்கள். ஒரே திசையைக் காட்டும் கேள்விகள்—“capital of France” மற்றும் “France’s capital city”—இந்த இடத்தில் கிட்டத்தட்ட ஒன்றின் மேல் ஒன்று அமையும். தொடர்பில்லாத தலைப்புகள் குறித்த கேள்விகள் வெகு தொலைவில் அமையும்.
வெக்டர் தேடல் (Vector search). உங்கள் கேச் (cache), ஏற்கனவே பார்த்த கேள்விகள் மற்றும் அவற்றின் பதில்களைச் சேமித்து வைத்திருக்கும், மேலும் ஒவ்வொரு ஜோடியும் அதன் சொந்த வெக்டரால் குறியிடப்பட்டிருக்கும். சிமிலாரிட்டி மெட்ரிக்ஸ் (similarity metrics) போன்ற cosine distance முறையைப் பயன்படுத்தி, வரும் வெக்டரை இந்தத் தரவுத்தளத்துடன் கணினி ஒப்பிடுகிறது. நவீன வெக்டர் ஸ்டோர்கள் (vector stores) மில்லி விநாடிகளில் மில்லியன் கணக்கான பதிவுகளைத் தேட முடியும்.
கேச் ஹிட் (Cache hit). தூரம் ஒரு குறிப்பிட்ட வரம்பிற்குள் (threshold) இருந்தால், சேமிக்கப்பட்ட பதிலைத் தகுதியானது என்று கணினி கருதும். அது அந்தப் பதிலைத் நேரடியாகத் திருப்பித் தரும். எந்த API சாவியும் பயன்படுத்தப்படாது, டோக்கன் கவுண்டரும் இயங்காது, மேலும் பயனர் விநாடிகளுக்குப் பதிலாக மில்லி விநாடிகளில் பதிலைப் பெறுவார்.
கேச் மிஸ் (Cache miss). எதுவுமே போதுமான அளவு நெருக்கமாக இல்லையென்றால், வினவல் LLM-க்குச் செல்லும். மாதிரி பதிலளித்தவுடன், கணினி புதிய வெக்டர்-பதில் ஜோடியை கேச்சில் சேமித்து வைக்கும், இதனால் அடுத்த முறை அதே போன்ற கேள்வி கேட்பவர் பயனடைவார்.
அந்த நான்கு படிநிலைச் சுழற்சி, மீண்டும் மீண்டும் வரும் நோக்கங்களை இலவசச் செயல்பாடாக மாற்றுகிறது.
உங்கள் பயன்பாட்டிற்கு (Application) இதன் பொருள் என்ன?
இதன் நன்மைகள் குறைந்த செலவுடன் மட்டும் நின்றுவிடுவதில்லை.
குறைந்த டோக்கன் செலவு (Lower token spend). வாடிக்கையாளர் சேவை உதவியாளர்கள் அல்லது நிறுவனத்தின் உள்நாட்டு அறிவுத் தேடல் பாட்களை (knowledge bots) இயக்கும் குழுக்கள், பெரும்பாலும் டோக்கன் செலவுகள் 70%-க்கும் மேல் குறைவதைக் காண்கிறார்கள். குறிப்பாக சப்போர்ட் மற்றும் FAQ பயன்பாடுகளில், மீண்டும் மீண்டும் கேட்கப்படும் கேள்விகளே போக்குவரத்தில் (traffic) பெரும்பகுதியை ஆக்கிரமிக்கின்றன. இடைமறிக்கப்படும் ஒவ்வொரு கோரிக்கையும் உங்கள் கணக்கில் சேமிக்கப்படும் பணமாகும்.
வேகமான பதில்கள் (Faster responses). ஒரு உள்ளூர் வெக்டர் தேடல் மற்றும் கேச் மீட்டல் ஐம்பது மில்லி விநாடிகளுக்கும் குறைவான நேரத்தில் இயங்கும். ஒரு ஹோஸ்டட் LLM-க்கான API அழைப்பு, மாதிரியின் அளவு மற்றும் நெரிசலைப் பொறுத்து அரை விநாடி முதல் பல விநாடிகள் வரை எடுக்கலாம். பயனர்கள் அந்த வித்தியாசத்தை உடனடியாக உணருவார்கள்.
குறைவான ரேட்-லிமிட் (rate-limit) சிக்கல்கள். சேவை வழங்குநர்கள் நிமிடத்திற்கு ஒரு குறிப்பிட்ட எண்ணிக்கையிலான கோரிக்கைகளை மட்டுமே அனுமதிக்கிறார்கள். நீங்கள் உள்ளூரிலேயே தீர்க்கும் ஒவ்வொரு வினவலும், 429 பிழையைத் தூண்டாது அல்லது அதிக செலவு பிடிக்கும் மறுமுயற்சி சுழற்சியை (retry loop) ஏற்படுத்தாது. போக்குவரத்து அதிகரிப்பிலும் (traffic spikes) உங்கள் அமைப்பு நிலையாக இருக்கும்.
உண்மையான அளவிடுதல் (Real scalability). கேச் மீண்டும் மீண்டும் வரும் சுமையை உள்வாங்குவதால், உங்கள் LLM ஒதுக்கீட்டை (quota) உயர்த்தாமலோ அல்லது பெரிய மாடல் இன்ஸ்டன்ஸ்குகளைத் தயார் செய்யாமலோ அதிக பயனர்களுக்குச் சேவை செய்ய முடியும். மாடல் ஒரு நிலையான செலவு மையமாக இருக்கும் அதே வேளையில், கேச் கிடைமட்டமாக (horizontally) விரிவடையும்.
கடினமான பணிகளைக் கையாளுவதற்கான கருவிகள்
நீங்கள் வெக்டர் பைப்லைனை (vector pipeline) ஆரம்பத்திலிருந்து உருவாக்க வேண்டிய அவசியமில்லை. பல திட்டங்கள் ஏற்கனவே embedding, சேமிப்பு மற்றும் மீட்டெடுப்பு தர்க்கங்களை (retrieval logic) பயன்படுத்தக்கூடிய அடுக்குகளாக வழங்குகின்றன.
Bifrost என்பது உங்கள் பயன்பாட்டிற்கும் மாடல் வழங்குநர்களுக்கும் இடையில் அமருவதற்காக வடிவமைக்கப்பட்ட ஒரு திறந்த மூல (open-source) AI கேட்வே ஆகும். இது மிகக் குறைந்த கூடுதல் செலவுடன் (overhead) semantic caching-ஐ வழங்குகிறது; ஏனெனில் ஒரு கேச், அது மாற்றீடு செய்யும் API அழைப்புகளை விட அதிகச் செலவைச் செய்யக்கூடாது என்பது முக்கியம். இது இருபதுக்கும் மேற்பட்ட LLM வழங்குநர்களுக்கான அணுகலை எளிதாக்குகிறது, எனவே ஒவ்வொரு மாற்றத்திற்கும் கேச்சிங் தர்க்கத்தை மீண்டும் எழுதாமல், நீங்கள் OpenAI, Anthropic அல்லது திறந்த மூல மாடல்களுக்குப் போக்குவரத்தை வழிநடத்தலாம்.
LiteLLM ஒரு உலகளாவிய API ஆகச் செயல்படுகிறது. நீங்கள் ஒரு இடைமுகத்தில் (interface) எழுதினால், அது நீங்கள் விரும்பும் எந்தவொரு பேக்எண்டிற்கும் (backend) கோரிக்கைகளை மாற்றுகிறது. அதன் கேச்சிங் மாட்யூல் (caching module), பல பயன்பாட்டு சேவையகங்களுக்கு (application servers) இடையிலான பகிரப்பட்ட கேஷ்களுக்காக Redis-ஐயும், அல்லது இலகுரக ஒற்றை-முனைய வரிசைப்படுத்தல்களுக்கு (single-node deployments) உள்ளூர் நினைவகத்தையும் (local memory) ஆதரிக்கிறது. இந்த நெகிழ்வுத்தன்மை, தங்கள் தொழில்நுட்பக் கட்டமைப்பை (stack) மறுவடிவமைப்பு செய்யாமல், முன்மாதிரியில் (prototype) இருந்து உற்பத்தி நிலைக்கு (production) மாறும் குழுக்களுக்கு இதை ஈர்க்கக்கூடியதாக மாற்றுகிறது.
LangChain உங்களுக்கு ஒரு கட்டமைப்பிற்குரிய (framework-level) அணுகுமுறையை வழங்குகிறது. நீங்கள் ஏற்கனவே LangChain மூலம் செயின்கள் (chains) மற்றும் ஏஜென்ட்களை (agents) ஒருங்கிணைத்திருந்தால், Chroma அல்லது FAISS போன்ற வெக்டர் ஸ்டோர்களை (vector stores) அடிப்படையாகக் கொண்ட தனிப்பயனாக்கப்பட்ட செமாண்டிக் கேஷ்களை (semantic caches) இதில் இணைக்க முடியும். Chroma உள்ளூர் சோதனைகளுக்கும் சிறிய தரவுத்தொகுப்புகளுக்கும் (datasets) சிறப்பாகச் செயல்படுகிறது. FAISS ஒரு தனித்த தரவுத்தள சேவையை இயக்காமலேயே, வேகமான, இன்-மெமரி (in-memory) தோராயமான தேடல் தேவைப்படும்போது சிறப்பாகச் செயல்படுகிறது.
Pinecone அல்லது Milvus போன்ற வெக்டர் தரவுத்தளங்களைப் பயன்படுத்தும் சுய-நிர்வகிக்கப்பட்ட அமைப்புகள் (Self-managed setups) முழுமையான கட்டுப்பாட்டைத் தேவைப்படும் குழுக்களுக்கு சிறந்த வழியாகும். Pinecone என்பது அளவிடுதல் (scaling) மற்றும் மறுஉருவாக்கத்தை (replication) கையாளும் ஒரு நிர்வகிக்கப்பட்ட சேவையாகும், இது செயல்பாட்டுச் சுமையைக் குறைக்கிறது. Milvus என்பது ஓப்பன் சோர்ஸ் மற்றும் Kubernetes-friendly ஆகும், உங்கள் சொந்த உள்கட்டமைப்பில் (infrastructure) தரவை வைத்திருக்க விரும்பினால் இது சிறந்தது. இங்கு கட்டமைப்பதற்கு அதிக வேலைப்பளு தேவைப்படும்—நீங்கள் எம்பெடிங்ஸ் (embeddings), வரம்புகள் (thresholds) மற்றும் நீக்கக் கொள்கைகளை (eviction policies) நீங்களே நிர்வகிக்க வேண்டும்—ஆனால் இதன் பலன் முழுமையான நெகிழ்வுத்தன்மையாகும்.
தவிர்க்க வேண்டிய கட்டமைப்புச் சிக்கல்கள் (Configuration Traps)
ஒரு செமாண்டிக் கேஷ் அதன் ட்யூனிங் (tuning) எவ்வளவு சிறப்பாக இருக்கிறதோ அவ்வளவு சிறப்பாக இருக்கும். உற்பத்தியில் (production) வெளியிடுவதற்கு முன் மூன்று விஷயங்களில் நீங்கள் கவனம் செலுத்த வேண்டும்.
Embedding தரம். அனைத்து எம்பெடிங் மாடல்களும் நுணுக்கங்களைச் சமமாகப் புரிந்துகொள்வதில்லை. ஒரு இலகுரக மாடல் “refund policy” மற்றும் “return policy” ஆகியவற்றை கிட்டத்தட்ட ஒரே வெக்டராகச் சுருக்கலாம், இது நல்லது. ஆனால் அது “battery life” மற்றும் “battery warranty” ஆகிய இரண்டையும் ஒன்றாக இணைத்துவிடக்கூடும், இது தவறான பதில்களை வழங்கும். உங்கள் லாக்ஸிலிருந்து (logs) உண்மையான வினவல் ஜோடிகளைப் (query pairs) பயன்படுத்தி உங்கள் மாடலைச் சோதிக்கவும். மோதல்கள் (collisions) ஏற்பட்டால், என்கோடிங் நேரம் சில மில்லி விநாடிகள் அதிகரித்தாலும், ஒரு வலிமையான எம்பெடிங் மாடலுக்கு மேம்படுத்தவும்.
ஒற்றுமை வரம்பு (Similarity threshold). இது "ஏறக்குறைய சரியானது" என்பதற்கான உங்கள் சகிப்புத்தன்மையாகும். இதை மிக அதிகமாக வைத்தால்—கிட்டத்தட்ட துல்லியமான வெக்டர் சீரமைப்பைக் கோரினால்—தெளிவான செமாண்டிக் பொருத்தங்களை நீங்கள் தவறவிட நேரிடும். இதை மிகத் தளர்வாக வைத்தால், “cancellation fees” பற்றி கேட்கும் பயனருக்கு “cancellation procedures” பற்றிய கேச் செய்யப்பட்ட பதில் கிடைக்கலாம், இது சங்கடமானதாகவும் பயனற்றதாகவும் இருக்கும். கோசைன் சிமிலாரிட்டிக்கு (cosine similarity) 0.85 அளவில் தொடங்கி, உங்கள் துறையில் காணப்படும் துல்லியத்தின் அடிப்படையில் மாற்றியமைக்கவும்.
கேஷ் புத்துணர்ச்சி (Cache freshness). காலாவதியான பதில்கள் நம்பிக்கையைச் சிதைக்கும். ஒரு தயாரிப்பு மறுஅறிமுகத்திற்குப் பிறகும் பழைய விலைப் திட்டத்தையே வலியுறுத்தும் ஒரு டெக் சப்போர்ட் கேஷ், பயனர்களை எரிச்சலடையச் செய்யும். ஒரு குறிப்பிட்ட காலத்திற்குப் பிறகு பதிவுகளை நீக்கும் time-to-live (TTL) கொள்கைகளைச் செயல்படுத்தவும். வேகமாக மாறும் தலைப்புகளுக்கு, TTL-களைக் குறைவாக வைத்திருக்கவும். கணித உண்மைகள் அல்லது நிறுவன வரலாறு போன்ற நிலையான துறைகளுக்கு, நீண்ட கால இடைவெளிகளை நீங்கள் அனுமதிக்கலாம். சில குழுக்கள் தலைப்புகளின் அடிப்படையில் பதிவுகளைக் குறியீடு (tag) செய்கின்றன, இதனால் மூல ஆவணங்கள் (source documentation) மாறும்போது தொடர்புடைய பதில்களை மொத்தமாகச் செல்லாததாக்க (bulk-invalidate) முடியும்.
முக்கியக் கருத்து (The Takeaway)
செமாண்டிக் கேஷிங் என்பது ஒரு மந்திரத் தீர்வு (silver bullet) அல்ல, ஆனால் ஒரு LLM பயன்பாட்டிற்கு நீங்கள் சேர்க்கக்கூடிய அதிக லாபம் தரும் மேம்படுத்தல்களில் (optimizations) இது ஒன்றாகும். இது உற்பத்தி AI வரிசைப்படுத்தல்களில் உள்ள இரண்டு மிகப்பெரிய புகார்களை நேரடியாகத் தீர்க்கிறது: செலவு மற்றும் தாமதம் (latency). Bifrost அல்லது LiteLLM போன்ற ஏற்கனவே உள்ள கருவியுடன் தொடங்கி, உண்மையான டிராஃபிக்கிற்கு எதிராக உங்கள் கேச் ஹிட் விகிதத்தை (cache hit rate) அளவிடவும், உங்கள் எம்பெடிங் மாடல் மற்றும் வரம்புகளைத் தொடர்ந்து மேம்படுத்தவும். முதல் நாளிலேயே முழுமையான துல்லியம் என்பது இலக்கல்ல; ஒரே கேள்விக்காக இரண்டு முறை டோக்கன்களை (tokens) வீணாக்குவதைத் தடுப்பதே இதன் நோக்கமாகும்.
மூலம்: Semantic Caching for LLMs: How It Works and the Tools That Do It
சமூகம்: GyaanSetu AI on Telegram