உங்கள் பட்ஜெட்டைத் தாண்டாமல் LLM-களை எவ்வாறு பயன்படுத்துவது
ஒரு AI டெமோவை உருவாக்குவது எளிது. ஒரு API சாவியைப் (key) பெற்று, ஒரு ப்ராம்ப்ட் (prompt) எழுதினால் அது வேலை செய்யும்.
ஆனால் அதை உண்மையான பயனர்களுக்குக் கொண்டு செல்வது வேறுபட்டது. டிராஃபிக் (traffic) வரும்போது உங்கள் செலவுகள் உயர்கின்றன. லேட்டன்சி (latency) அதிகரிக்கிறது. உங்கள் நிதித் துறை கேள்விகள் கேட்கிறது.
ஒரு டெமோவிற்கும் உண்மையான தயாரிப்பிற்கும் இடையிலான இடைவெளி பொறியியல் (engineering) ஆகும். நீங்கள் செலவு மற்றும் வேகத்தை நிர்வகிக்க வேண்டும்.
பணத்தைச் சேமிக்க உங்கள் வெளியீட்டைக் (output) கட்டுப்படுத்துங்கள்
பெரும்பாலான API-கள் ஒவ்வொரு டோக்கனுக்கும் (token) கட்டணம் வசூலிக்கின்றன. நீங்கள் அனுப்புவதற்கும், அவை பதிலுக்குத் திருப்பி அனுப்புவதற்கும் கட்டணம் வசூலிக்கப்படுகிறது. இன்புட் டோக்கன்களை விட அவுட்புட் டோக்கன்களுக்கு அதிக செலவாகும்.
உங்கள் ப்ராம்ப்ட்களை (prompts) சுருக்குவது மட்டும் போதாது. பதிலில் கவனம் செலுத்துங்கள். • JSON-ஐக் கேளுங்கள். • ஒரு வாக்கியமாகப் பதில் கேட்கவும். • அதிகபட்ச டோக்கன் வரம்பை (max token limit) நிர்ணயிக்கவும். • மாடலைச் சுருக்கமாகப் பதிலளிக்கச் சொல்லுங்கள்.
குறுகிய பதில்கள் மலிவானவை மற்றும் வேகமானவை.
அழைப்புகளின் (calls) எண்ணிக்கையைக் குறைக்கவும்
நீங்கள் செய்யாத அழைப்பே மிக மலிவானது.
- கேச்சிங் (caching) முறையைப் பயன்படுத்துங்கள். பல பயனர்கள் ஒரே மாதிரியான கேள்விகளைக் கேட்கிறார்கள். ஒரு கேச் (cache), மெதுவான API அழைப்பை ஒரு வேகமான தேடலாக (lookup) மாற்றுகிறது.
- ஒரு ரூட்டரைப் (router) பயன்படுத்துங்கள். ஒவ்வொரு பணிக்கும் உங்களுக்கு ஒரு மிகப்பெரிய மாடல் தேவையில்லை. எளிமையான வேலைகளுக்குச் சிறிய, மலிவான மாடலைப் பயன்படுத்துங்கள். கடினமான பணிகளுக்கு மட்டுமே விலையுயர்ந்த மாடலைப் பயன்படுத்துங்கள்.
பயனர் அனுபவத்தை மேம்படுத்துங்கள்
சில நேரங்களில் உங்களால் மாடலின் வேகத்தை அதிகரிக்க முடியாது. ஆனால் அது வேகமாக இருப்பது போன்ற உணர்வை நீங்கள் ஏற்படுத்த முடியும்.
- பதில்களை ஸ்ட்ரீம் (stream) செய்யுங்கள். உரை உருவாகும்போதே அதைக் காட்டுங்கள். பயனர்கள் உடனடியாகப் படிக்கத் தொடங்குவார்கள். இது காத்திருப்பு நேரத்தைக் குறைவாக உணரச் செய்யும்.
- முன்னேற்றத்தைக் காட்டுங்கள். வேலை பல நிலைகளைக் கொண்டிருந்தால், பயனருக்குத் தெரியப்படுத்துங்கள். வெறும் லோடிங் ஸ்பின்னருக்குப் (loading spinner) பதிலாக "ஆவணங்களைத் தேடுகிறது..." (Searching documents...) போன்ற செய்திகளைப் பயன்படுத்துங்கள்.
மெதுவான கோரிக்கைகளை (requests) நிர்வகிக்கவும்
சில மிக மெதுவான கோரிக்கைகள் உங்கள் தயாரிப்பையே கெடுத்துவிடும். அவை அப்படியே தொங்கிக்கொண்டிருக்க (hang) அனுமதிக்காதீர்கள்.
- கடுமையான டைம்அவுட்களை (timeouts) நிர்ணயிக்கவும். ஒரு கோரிக்கை அதிக நேரம் எடுத்தால் என்ன செய்ய வேண்டும் என்பதைத் தீர்மானிக்கவும்.
- வரம்புகளுடன் கூடிய மறுமுயற்சிகளை (retries) பயன்படுத்துங்கள். எப்போதும் மறுமுயற்சி செய்துகொண்டே இருக்காதீர்கள்.
- சர்க்யூட் பிரேக்கர்களைப் (circuit breakers) பயன்படுத்துங்கள். சேவை வழங்குநர் (provider) செயலிழந்திருந்தால், கோரிக்கைகளை அனுப்புவதை நிறுத்திவிட்டு ஒரு மாற்று வழியைக் (fallback) காட்டுங்கள்.
உங்கள் தரவைக் கண்காணிக்கவும்
நீங்கள் அளவிடாத ஒன்றைத் திருத்த முடியாது. ஒவ்வொரு கோரிக்கைக்கும் இந்த மூன்று விஷயங்களைப் பதிவு செய்யுங்கள்: • இன்புட் டோக்கன்கள் (Input tokens) • அவுட்புட் டோக்கன்கள் (Output tokens) • மொத்த லேட்டன்சி (Total latency)
இவற்றை ஒவ்வொரு அம்சத்தின் (feature) அடிப்படையிலும் கண்காணிக்கவும். உங்கள் செலவுகளில் பெரும்பகுதியை ஏற்படுத்தும் ஒரு குறிப்பிட்ட அம்சத்தைக் கண்டறிய இது உதவும்.
மாடலை ஒரு மந்திரமாகப் பார்ப்பதை நிறுத்துங்கள். அதை நீங்கள் நிர்வகிக்க வேண்டிய ஒரு மெதுவான, விலையுயர்ந்த சார்பாக (dependency) கருதுங்கள்.