நான் ஏன் ஒரு தனி AI வழங்குநரை மட்டும் நம்பியிருப்பதை நிறுத்தினேன்
நான் ஒரு சமூக மன்றத்திற்காக (community forum) ஒரு நிகழ்நேர (real-time) சாட்போட்டை உருவாக்கினேன். நான் OpenAI API-ஐ மட்டுமே பயன்படுத்தினேன். அது எளிமையாகத் தோன்றியது.
மூன்று வாரங்களுக்குப் பிறகு, அதிகப்படியான பயன்பாடு இருந்த நேரத்தில் (peak hours) எனக்கு 5xx பிழை (error) ஏற்பட்டது. எனது சாட்போட் செயலிழந்தது. பயனர்கள் கோபமடைந்தனர். தயாரிப்பு பயன்பாடுகளுக்கு (production apps) ஒரே ஒரு வழங்குநரை மட்டும் நம்பி இருக்க முடியாது என்பதை நான் உணர்ந்தேன்.
ஒரே ஒரு வழங்குநருடன் நான் பல சிக்கல்களை எதிர்கொண்டேன்:
- விகித வரம்புகள் (Rate limits)
- காலாவதி நேரங்கள் (Timeouts)
- முழுமையான சேவைத் தடங்கல்கள் (Complete outages)
நான் மற்ற வழங்குநர்களை முயற்சி செய்தேன், ஆனால் அவை அனைத்தும் வெவ்வேறு வடிவங்களையும் (formats) அங்கீகார முறைகளையும் (authentication methods) கொண்டிருந்தன. எனது குறியீடு (code) switch-case கூற்றுகளின் (statements) குழப்பமாக மாறியது.
எனக்கு ஒரு அமைப்பு தேவைப்பட்டது:
- வெவ்வேறு வழங்குநர்களைத் தரப்படுத்துவதற்கு (Standardize)
- ஒன்று தோல்வியடையும் போது தானாகவே மீண்டும் முயற்சிப்பதற்கு (Retry automatically)
- பதில்களைச் சேமித்து வைப்பதற்கு (Cache responses)
- விற்பனையாளர் சார்ந்த சார்புநிலையைத் தவிர்க்க (Avoid vendor lock-in)
மூன்றாம் தரப்பு நூலகங்கள் (third-party libraries) மிகவும் கடினமானவை என்பதால் நான் அவற்றைத் தவிர்த்தேன். அதற்குப் பதிலாக, ஒரு எளிய வடிவமைப்பைப் பயன்படுத்தி ஒரு தனிப்பயனாக்கப்பட்ட ஃபேல்பேக் (custom fallback) அமைப்பை உருவாக்கினேன்.
முதலில், அனைத்து வழங்குநர்களுக்கும் பொதுவான ஒரு இடைமுகத்தை (common interface) உருவாக்கினேன். இது எந்தவொரு AI மாதிரியும் (model) ஒரே குறியீட்டுடன் செயல்பட அனுமதிக்கிறது.
அடுத்து, நான் ஒரு router class-ஐ உருவாக்கினேன். இந்த வகுப்பு வழங்குநர்களை வரிசைப்படி முயற்சிக்கிறது. தோல்விகளை நிர்வகிக்க இது exponential backoff மற்றும் எளிய caching முறையைப் பயன்படுத்துகிறது.
அதன் தர்க்கம் (logic) இதோ:
- AI வழங்குநர்களுக்கான ஒரு abstract base class-ஐ வரையறுக்கவும்.
- OpenAI மற்றும் பிற வழங்குநர்களுக்கான குறிப்பிட்ட வகுப்புகளை (classes) செயல்படுத்தவும்.
- உங்கள் வழங்குநர் பட்டியலைச் சுழற்சி செய்ய (loop) ஒரு router-ஐப் பயன்படுத்தவும்.
- ஒரு வழங்குநர் தோல்வியடைந்தால், router காத்திருந்து அடுத்தவரை முயற்சிக்க வேண்டும்.
சமீபத்திய மூன்று சேவைத் தடங்கல்களின் போது இந்த அமைப்பு எனது திட்டத்தைக் காப்பாற்றியது. இது வெளிப்படையாகவும் எளிமையாகவும் உள்ளது.
நீங்கள் AI மூலம் உருவாக்குகிறீர்கள் என்றால், இந்த விஷயங்களை நினைவில் கொள்ளுங்கள்:
- தயாரிப்பு சூழலில் (production) உள்ளூர் அகராதிக்கு (local dictionary) பதிலாக caching செய்ய Redis-ஐப் பயன்படுத்தவும்.
- உங்கள் செலவைக் கண்காணிக்க செலவு கண்காணிப்பை (cost tracking) சேர்க்கவும்.
- வேகமான பதிலंसाठी asynchronous ஆதரவைச் செயல்படுத்தவும்.
- விகித வரம்புகளை (rate limits) சிறப்பாகக் கையாள "Retry-After" தலைப்புகளைப் (headers) பகுப்பாய்வு செய்யவும்.
உங்கள் திட்டம் சிறியதாக இருந்தால், அதைத் தேவையில்லாமல் சிக்கலாக்க வேண்டாம் (over-engineer). ஆனால் உங்கள் சேவைச் செயல்பாட்டு நேரத்தைப் (uptime) பொறுத்திருந்தால், ஒரு ஃபேல்பேக் (fallback) அமைப்பை உருவாக்குங்கள்.
உங்கள் திட்டங்களில் வழங்குநர் நம்பகத்தன்மையை எவ்வாறு கையாளுகிறீர்கள்? நீங்கள் ஒரு ஃபேல்பேக் அடுக்கைப் (fallback layer) பயன்படுத்துகிறீர்களா அல்லது ஒரு விற்பனையாளரை மட்டும் நம்பியிருக்கிறீர்களா?