ஒரு முதன்மை பெரிய மொழி மாதிரியைத் தேர்ந்தெடுப்பது ஒரு மதிய நேரத்தை எடுத்துக்கொள்ளலாம். ஆனால் அது தோல்வியடையும் போது என்ன நடக்கும் என்பதை கையாள்வதே உண்மையான பொறியியல் சவாலாகும்.

ஒரு முதன்மை பெரிய மொழி மாதிரியைத் (Large Language Model) தேர்ந்தெடுப்பதற்கு ஒரு மதிய வேளை போதுமானது. ஆனால் அது தோல்வியடையும் போது என்ன நடக்கிறது என்பதை கையாள்வதே உண்மையான பொறியியல் பணி ஆகும்.

பெரும்பாலான குழுக்கள் அனைத்தும் சரியாக நடக்கும் சூழலுக்காகவே (happy path) மேம்படுத்துகின்றன. அவர்கள் சுத்தமான தரவுத்தொகுப்புகளில் துல்லியத்தை அளவிடுகிறார்கள், சிறந்த உள்ளீடுகளுக்கு ஏற்ப ப்ராம்ப்ட்களை (prompts) செம்மைப்படுத்துகிறார்கள், மற்றும் நம்பிக்கையுடன் பயன்பாட்டுக்கு (deploy) கொண்டு வருகிறார்கள். பிறகு தயாரிப்புப் பயன்பாட்டுப் போக்குவரத்து (production traffic) வருகிறது. உச்ச நேரங்களில் மாதிரி காலாவதியாகத் (timeout) தொடங்குகிறது, வெள்ளிக்கிழமை மாலைகளில் தவறான JSON-ஐத் தருகிறது, அல்லது விலை மாற்றத்திற்குப் பிறகு திடீரென மூன்று மடங்கு செலவை ஏற்படுத்துகிறது. உங்கள் கவனமாக வடிவமைக்கப்பட்ட AI அம்சம் ஒரு சுமையாக மாறுகிறது, ஏனெனில் மாதிரி உடைந்துவிடும் என்று யாரும் திட்டமிடவில்லை.

எந்தவொரு தீவிரமான மல்டி-மாடல் (multi-model) பயன்பாட்டிலும், மாற்று வழிமுறைகள் (fallback rules) என்பது ஒரு கூடுதல் சிந்தனை அல்ல. அவை முக்கிய உள்கட்டமைப்பாகும். முதன்மை மாதிரி தடுமாறும்போது உங்கள் அமைப்பு எவ்வாறு செயல்படுகிறது என்பது, பயனர்கள் தொடர்ந்து இருக்கலாமா அல்லது வெளியேறலாமா என்பதைத் தீர்மானிக்கிறது.

தெளிவான தோல்வி சிக்னல்களுடன் தொடங்குங்கள்

நீங்கள் எதற்குக் எதிர்வினையாற்றுகிறீர்கள் என்பதைத் துல்லியமாகத் தெரியாமல் ஒரு fallback உத்தியை உருவாக்க முடியாது. ஒவ்வொரு வெளிச்செல்லும் மாதிரி அழைப்பையும் (outbound model call) கண்காணிப்பதன் மூலமும், தோல்விகளைச் குறிப்பிட்ட, செயல்படுத்தக்கூடிய சிக்னல்களாகப் வகைப்படுத்துவதன் மூலமும் தொடங்குங்கள்.

ஒரு வழங்குநரின் (provider) endpoint முடங்கும்போது API timeouts-ஐக் கவனியுங்கள். விகிதக் கட்டுப்பாட்டுப் பிழைகளைக் (rate limit errors) கவனியுங்கள் — பொதுவாக HTTP 429s — இவை நீங்கள் அதிகப்படியான போக்குவரத்தை (burst traffic) உருவாக்கும்போது அல்லது மாதாந்திர வரம்புகளைத் தாண்டும்போது ஏற்படும். உங்கள் parser pipeline-ஐ முடக்கும் தவறான JSON வெளியீட்டைக் கவனியுங்கள். HTTP நிலையில் வெற்றிகரமாகத் தெரிந்தாலும், எந்தப் பயனுள்ள உள்ளடக்கமும் இல்லாத காலியான அல்லது முழுமையற்ற பதில்களைக் கவனியுங்கள். எந்தவொரு கடினமான timeout-ம் ஏற்படுவதற்கு முன்பே, சாட் அனுபவத்தைக் குறைக்கும் அதிக தாமதத்தைக் (high latency) கவனியுங்கள். பயனர் உள்ளீடு மாதிரியின் சூழல் நீளத்தைத் (context length) தாண்டும்போது ஏற்படும் overflow-ஐக் கவனியுங்கள். மேலும், தரக் குறைவு (quality regression) எனப்படும் மிக நுணுக்கமான தோல்வியைக் கவனியுங்கள்: மாதிரி பதிலளிக்கிறது, ஆனால் ஒரு வழங்குநர் தரப் பக்கப் புதுப்பிப்பிற்குப் பிறகு, அதன் பதில்கள் திசைமாறுகின்றன, தெளிவற்றதாகின்றன அல்லது வடிவமைப்புக் கட்டளைகளைப் புறக்கணிக்கின்றன.

இந்த ஒவ்வொரு சிக்னலும் ஒரு மாறுபட்ட எதிர்வினையைத் தூண்ட வேண்டும். ஒரு timeout ஏற்பட்டால் மீண்டும் முயற்சி செய்யலாம் (retry). தவறான JSON ஏற்பட்டால் மாதிரியை மாற்றலாம் (model switch). ஒரு rate limit ஏற்பட்டால், நீங்கள் முற்றிலும் வேறொரு வழங்குநரைப் பயன்படுத்த வேண்டியிருக்கலாம்.

பணிப்பாய்வுக்கேற்ப (Workflow) மாற்று வழிமுறையைத் தேர்ந்தெடுங்கள்

ஒவ்வொரு பணிக்கும் ஒரே fallback விதியைப் பயன்படுத்துவது பேரழிவிற்கு வழிவகுக்கும். ஒரு சாட்பாட் மற்றும் பின்னணியில் இயங்கும் தரவுப் பிரித்தெடுத்தல் பணி ஆகிய இரண்டிற்கும் முற்றிலும் மாறுபட்ட தேவைகள் உள்ளன. உங்கள் பணிப்பாய்வின் அடிப்படையில் உங்கள் fallback-ஐ வடிவமைக்கவும்.

சாட்பாட்கள் (Chatbots) வேகம் மற்றும் உரையாடல் வேகத்தை எதிர்பார்க்கின்றன. பயனர்கள் சற்று பொதுவான பதில்களை ஏற்றுக்கொள்வார்கள், ஆனால் ஐந்து வினாடி தாமதத்தை மன்னிக்க மாட்டார்கள். உங்கள் முதன்மை மாதிரி மெதுவாகச் செயல்பட்டால், ஒரு வேகமான மாற்று மாதிரிக்கு மாறவும் — பெரும்பாலும் அதே மாதிரி குடும்பத்தைச் சேர்ந்த சிறிய மாடல் அல்லது மற்றொரு வழங்குநரின் வேகமான மாடல் (speed-tier offering) இதற்கென இருக்கும். உரையாடலைத் தொடர்ந்து நகர்த்தவும்.

RAG அமைப்புகள் துல்லியத்தை எதிர்பார்க்கின்றன. நீங்கள் ஏற்கனவே தரவை மீட்டெடுப்பதற்கான (retrieval) செலவைச் செலுத்திவிட்டீர்கள் — vector search, reranking, அல்லது web crawling என எதுவாக இருந்தாலும் சரி. ஒருவேில் ஜெனரேட்டர் (generator) வழங்கப்பட்ட சூழலை (context) மதிக்கத் தவறினால், அந்த வேலை அனைத்தும் வீணாகும். ஒரு மாடல் மெதுவாக இருந்தாலும், துல்லியமான அறிவுறுத்தல்களைப் பின்பற்றுவதற்கும் நீண்ட சூழலைப் புரிந்துகொள்வதற்கும் பெயர் பெற்ற மாடலுக்கு மாறவும்.

கோடிங் கருவிகள் (Coding tools) தர்க்கத்தை (logic) எதிர்பார்க்கின்றன. டெவலப்பர்கள் அழகான விளக்கங்களை விட சரியான தொடரியல் (syntax) மற்றும் செல்லுபடியாகும் API அழைப்புகளையே விரும்புகிறார்கள். முதன்மை மாதிரி தவறான செயல்பாடுகளை (hallucinating functions) உருவாக்கத் தொடங்கினால் அல்லது விளிம்பு நிலை நிகழ்வுகளைத் (edge cases) தவிர்க்கத் தொடங்கினால், குறியீட்டிற்காக (code) சிறப்பாகப் பயிற்சியளிக்கப்பட்ட மாதிரிக்கு மாறவும். தொகுக்கத் தயாராக இருக்கும் (compile-ready) வெளியீட்டிற்காக அதிக தாமதத்தை ஏற்றுக்கொள்ளலாம்.

JSON பிரித்தெடுத்தல் (JSON extraction) கட்டமைப்பை எதிர்பார்க்கிறது. கட்டமைக்கப்பட்ட உருவாக்கம் (Structured generation) மிகவும் நுணுக்கமானது. ஒரு விடுபட்ட அடைப்புக்குறி அல்லது தவறான மேற்கோள் குறி (quote) அடுத்தடுத்த தரவுத்தளச் செயல்பாடுகளைத் தடுத்துவிடும். உங்கள் முதன்மை மாதிரி ஸ்கீமா (schema) விதிகளிலிருந்து விலகிச் சென்றால், ஒருமுறை மீண்டும் முயற்சிக்கவும், பின்னர் அதிக வடிவமைப்பு நம்பகத்தன்மை கொண்ட மாதிரிக்கு மாறவும். ஆச்சரியமாக, கீழ்ப்படிதலுக்காகப் பயிற்சியளிக்கப்பட்ட சிறிய மாதிரிகள் பெரும்பாலும் இந்த குறிப்பிட்ட பணியில் பெரிய மாடல்களை விடச் சிறப்பாகச் செயல்படுகின்றன.

தானியங்கி மற்றும் தொகுப்புப் பணிகள் (Automation and batch jobs) செலவுக் கட்டுப்பாட்டை எதிர்பார்க்கின்றன. பின்னணியில் இயங்கும் வகைப்படுத்திகள் (classifiers), லாக் சுருக்கிகள் (log summarizers) மற்றும் அறிவிப்பு உருவாக்குநர்கள் தொடர்ந்து இயங்குகின்றன. உங்கள் முதன்மை மாதிரியின் விலை அதிகரிப்பு, ஒரு சாதாரண தினசரி கட்டணத்தை பட்ஜெட் நெருக்கடியாக மாற்றக்கூடும். இத்தகைய முக்கியமானதல்லாத பணிகளுக்காக ஒரு மலிவான, நிலையான மாதிரியைத் தயார் நிலையில் வைத்திருக்கவும். வெளியீட்டின் தரம் சற்று குறைந்தால், அதன் வணிகத் தாக்கம் பொதுவாகக் குறைவாகவே இருக்கும்.

மாற்றுவதற்கு முன் உங்கள் கட்டுப்பாடுகளைத் தெரிந்து கொள்ளுங்கள்

மாதிரிகளைத் தெரியாமல் மாற்றுவது புதிய சிக்கல்களை உருவாக்கும். நீங்கள் ஒரு வலிமையான மாதிரியிலிருந்து ஒரு பலவீனமான மாதிரிக்கு மாறினால், மாற்று மாதிரி நுணுக்கமான ப்ராம்ப்ட்களைத் தவறாகப் புரிந்துகொண்டு, அடுத்தடுத்த பிழைகளைத் தூண்டும் குப்பையான தரவுகளை உருவாக்கலாம். நீங்கள் ஒரு பெரிய மாதிரிக்கு மாறினால், தரப் பிரச்சினையைத் தீர்க்கலாம் ஆனால் சில மணிநேரங்களிலேயே உங்கள் பட்ஜெட்டைத் தகர்த்துவிடலாம்.

எந்தவொரு மாதிரியையும் fallback நிலைக்கு உயர்த்துவதற்கு முன், ஆறு காரணிகளைக் கொண்டு அதைச் சோதிக்கவும்.

• மாடல் திறன் (Model capability): இது உண்மையில் ப்ராம்ப்ட் (prompt) வகையை கையாள முடியுமா, அல்லது வேறு விதமாகத் தோல்வியடையுமா?
• மொழி ஆதரவு (Language support): உங்கள் மாற்று மாடல் ஆங்கிலத்தில் சிறப்பாகச் செயல்படலாம், ஆனால் இந்தி, ஸ்பானிஷ் அல்லது ஜப்பானிய மொழிகளில் தவறான தகவல்களை (hallucinate) வழங்கலாம்.
• சூழல் சாளர அளவு (Context window size): உங்கள் உள்ளீடு 50,000 டோக்கன்களாக இருந்தால், 16,000 டோக்கன் வரம்பு கொண்ட ஒரு ஃபெல்பேக் (fallback) மாடல், தகவலைத் துண்டித்து அதன் பொருளை அமைதியுமாகச் சிதைத்துவிடும்.
• தாமதம் (Latency): உங்கள் பிராந்தியத்திற்குச் சில வழங்குநர்கள் மற்றவர்களை விடத் தொடர்ச்சியாக வேகமாகச் செயல்படுகிறார்கள்.
• ஒரு கோரிக்கைக்கான செலவு (Cost per request): ஒரு குறிப்பிட்ட உச்ச வரம்பை நிர்ணயிக்கவும். அதிகப்படியான பயன்பாட்டின் போது ஃபெல்பேக் மாடலின் செலவு எவ்வளவு என்பதைத் தெரிந்து கொள்ளவும்.
• வெளியீட்டு நம்பகத்தன்மை (Output reliability): இது ஒவ்வொரு முறையும் வெளியீட்டு வடிவமைப்பைப் பின்பற்றுமா, அல்லது சில நேரங்களில் மட்டும் செயல்படுமா?

செயல்படக்கூடிய நான்கு ஃபெல்பேக் (Fallback) முறைகள்

ஒவ்வொரு தோல்விக்கும் ஒரே தீர்வு தேவையில்லை. பல்வேறு வகையான ஃபெல்பேக் கருவிகளை உருவாக்கி, அவற்றைச் சரியாகப் பயன்படுத்தவும்.

மீண்டும் முயற்சிக்கும் ஃபெல்பேக் (Retry fallback). தற்காலிக நெட்வொர்க் பிழைகள் மற்றும் குறுகிய கால வழங்குநர் முடங்கல்களுக்கு, exponential backoff முறையைப் பயன்படுத்தி அதே மாடலை மீண்டும் முயற்சிக்கவும். தவறான வெளியீடு அல்லது சூழல் அளவுக்கு அதிகமாகும் (context overflow) போது மீண்டும் முயற்சிக்க வேண்டாம் — ஒரே தவறான ப்ராம்ப்ட்டை இருமுறை அனுப்புவது அரிதாகவே உதவும்.

இணையான ஃபெல்பேக் (Equivalent fallback). உங்கள் முதன்மை வழங்குநர் முடங்கியிருக்கும் போது அல்லது வேகம் குறைக்கப்படும் போது (throttled), மற்றொரு வழங்குநரின் அதே போன்ற மாடலுக்கு மாறவும். ஒரு முன்னணி மாடலில் (frontier model) இருந்து அதே தரத்திலான மற்றொரு மாடலுக்கு மாறுவதற்கு மிகக் குறைந்த அளவே ப்ராம்ப்ட் மாற்றங்கள் தேவைப்படும் மற்றும் வெளியீட்டுத் தரத்தைப் பாதுகாக்கும்.

மலிவான ஃபெல்பேக் (Cheaper fallback). முக்கியமானதல்லாத பணிகளுக்காகக் குறைந்த செலவு கொண்ட மாடலை ஒதுக்கி வைக்கவும். மலிவான மாடல் சிரமப்பட்டால், குறைந்த மதிப்புள்ள பணிகளுக்காக பிரீமியம் டோக்கன்களை வீணாக்குவதற்குப் பதிலாக, அந்த அம்சத்தின் செயல்பாட்டைக் குறைக்கவும் (degrade gracefully).

வலிமையான ஃபெல்பேக் (Stronger fallback). இது தலைகீழாகத் தோன்றலாம், ஆனால் இது அவசியமானது. ஒரு நடுத்தரத் தர மாடல் (mid-tier model) சிக்கலான தர்க்கம், பல படிநிலை கணிதங்கள் அல்லது நுணுக்கமான சட்டப் பகுப்பாய்வு ஆகியவற்றில் தொடர்ந்து தடுமாறும்போது, அதிகத் திறன் கொண்ட மாடலுக்கு மாற்றவும் (escalate). துல்லியம் வருவாயையோ அல்லது பாதுகாப்பையோ உறுதி செய்யும் முக்கியமான பயனர் பாதைகளுக்கு மட்டும் இதைச் சிக்கனமாகப் பயன்படுத்தவும்.

உங்கள் கட்டமைப்பில் (Architecture) தர்க்கத்தை இணைக்கவும்

ஃபெல்பேக் தர்க்கத்தை (fallback logic) பயன்பாட்டு குறியீட்டில் (application code) உள்ள பல try-catch பிளாக்குகளில் சிதற விடாதீர்கள். ரூட்டிங்கை (routing) ஒரு உள்கட்டமைப்பாகக் கருதவும். ஒவ்வொரு மாடலுக்கும் தனித்த timeout வரம்பு, மறுமுயற்சி கொள்கை (retry policy) மற்றும் சர்க்யூட் பிரேக்கர் (circuit breaker) ஆகியவற்றைக் கொண்ட, பணி வகைகளை வரிசைப்படுத்தப்பட்ட மாடல் பட்டியல்களுடன் இணைக்கும் ஒரு மிட்ல்வேர் அடுக்கை (middleware layer) உருவாக்கவும்.

ஃபெல்பேக் நிகழ்வுகளை முதன்மையான அளவீடுகளாக (first-class metrics) கண்காணிக்கவும். பிழை விகிதங்கள் (Error rates) ஒரு மாடல் எப்போது முடங்கியுள்ளது என்பதைக் கூறும்; ஃபெல்பேக் விகிதங்கள் (fallback rates) ஒரு மாடல் அந்தப் பணிக்குத் தவறானது என்பதைத் தெரிவிக்கும். உங்கள் அமைப்பு 30 அல்லது 40 சதவீதம் ஃபெல்பேக் முறையைப் பயன்படுத்தினால், உங்கள் முதன்மை மாடல் பணிச்சுமையுடன் சரியாக ஒத்துப்போகவில்லை என்று அர்த்தம். இது உங்கள் பிழை கையாளுதலை (error handling) மட்டும் சரிசெய்ய வேண்டியதல்ல, உங்கள் மாடல் தேர்வை மறுமதிப்பீடு செய்ய வேண்டியதற்கான அறிகுறியாகும்.

தெளிவான வரவு செலவுத் திட்டங்களை (budgets) நிர்ணயிக்கவும். ஃபெல்பேக் என்பது ஒருபோதும் கட்டுப்பாடற்ற செலவாக இருக்கக்கூடாது. அதிகப்படியான பயன்பாட்டின் போது நீங்கள் ஒரு பிரீமியம் மாடலுக்கு மாறினால், நிமிடத்திற்கு எத்தனை கோரிக்கைகள் மாற்றப்படலாம் என்பதைக் கட்டுப்படுத்தவும். உங்கள் சேவையின் நேரத்தை (uptime) எவ்வளவு முக்கியமாகக் கருதுகிறீர்களோ, அதே அளவு முக்கியத்துவத்துடன் உங்கள் நிதிச் செலவையும் பாதுகாக்கவும்.

உண்மையான சோதனை

நீங்கள் ஒரு டெமோவிற்காக (demo) உருவாக்கவில்லை. API மந்தமாக இருக்கும்போது, பயனர் காத்திருக்கும்போது மற்றும் AI கட்டணம் ஏன் இருமடங்காக அதிகரித்தது என்று நிதித் குழு கேட்கும்போது, நீங்கள் அதைச் சமாளிக்கத் தயாராக இருக்க வேண்டும். ஒரு முதிர்ச்சியடைந்த ஃபெல்பேக் உத்தி தயாரிப்பைச் சிறப்பாக இயங்க வைக்கும், பயனர் அனுபவத்தைத் தொடர்ச்சியாக வைத்திருக்கும் மற்றும் உங்கள் செலவுகளைக் கணிக்கக்கூடியதாக வைத்திருக்கும்.

உங்கள் முதன்மை மாடலை கவனமாகத் தேர்ந்தெடுக்கவும். ஆனால் அது உங்களை ஏமாற்றும்போது என்ன நடக்கும் என்பதை வடிவமைக்க அதைவிட இரண்டு மடங்கு அதிக நேரத்தைச் செலவிடுங்கள்.

Source: How to Design AI Model Fallback Rules for Multi-Model Apps

Community: GyaanSetu AI on Telegram