திறந்த-எடை (open-weight) பெரிய மொழி மாதிரிகள், பொறியியல் குழுக்கள் AI உள்கட்டமைப்பைப் பற்றி சிந்திக்கும் முறையை மாற்றியமைத்துள்ளன. வழங்குநர் வன்பொருள் (hardware), மாதிரி எடைகள் (model weights) மற்றும் வெளியீட்டு அட்டவணையைத் தீர்மானிக்கும் மூடிய API-களைப் போலல்லாமல், திறந்த-எடை மாதிரிகள் அந்த முடிவுகளை உங்களிடமே ஒப்படைக்கின்றன. மாதிரி எங்கு இருக்க வேண்டும், அது எவ்வாறு மாற்றியமைக்கப்பட வேண்டும் (tuned), மற்றும் எப்போது—அல்லது எப்பொழுதாவது—புதிய செக்பாயிண்டிற்கு (checkpoint) மாற வேண்டும் என்பதை நீங்களே முடிவு செய்கிறீர்கள். அந்த அளவிலான உரிமை மிகவும் சக்தி வாய்ந்தது, ஆனால் அதே சமயம் ஒருங்கிணைப்புப் பணி (integration work) முழுமையாக உங்கள் பொறுப்ப becomes.

நீங்கள் OpenAI-ன் GPT-4 அல்லது Anthropic-ன் Claude போன்ற நிர்வகிக்கப்படும் API-யிலிருந்து வருகிறீர்கள் என்றால், நல்ல செய்தி என்னவென்றால், பல திறந்த-எடை ஹோஸ்டிங் வழங்குநர்களும் அனுமான இயந்திரங்களும் (inference engines) இப்போது ஒரே மொழியைப் பேசுகின்றன: HTTP POST, JSON payloads மற்றும் bearer token authentication. இதன் செயல்பாடுகள் உங்களுக்குப் பரிச்சயமானதாகத் தோன்றலாம், ஆனால் விவரங்கள் மிகவும் முக்கியமானவை; ஏனெனில் வழங்குநரை விட, நம்பகத்தன்மை, செலவுக் கட்டுப்பாடு மற்றும் செயல்பாட்டுத் தன்மையை (behavior shaping) உறுதி செய்யும் பொறுப்பு உங்களுடையது.

API அழைப்பின் அடிப்படைகள்

இதன் மையப்பகுதி ஒரு POST கோரிக்கை (request) ஆகும். Authorization header-இல் ஒரு நிலையான bearer token மூலம் நீங்கள் அங்கீகாரம் பெறுகிறீர்கள். இதன் body ஒரு JSON object ஆகும், மேலும் அதன் மிக முக்கியமான புலம் messages array ஆகும். அந்த array பரிச்சயமான சாட் வடிவமைப்பைப் பின்பற்றுகிறது: system, user, மற்றும் assistant ஆகிய பொறுதிகள் (roles) மாறி மாறி வரும்.

நடைமுறையில் ஒரு குறைந்தபட்ச கோரிக்கை அமைப்பு இவ்வாறு இருக்கும்:

  • Authorization header-ஐ Bearer <your-token> என அமைக்கவும்.
  • குறைந்தபட்சம் ஒரு model அடையாளம் மற்றும் messages பட்டியல் கொண்ட JSON payload-ஐ அனுப்பவும்.
  • நீங்கள் தீர்மானிக்கப்பட்ட (deterministic) அல்லது ஆக்கபூர்வமான (creative) கட்டுப்பாட்டை விரும்பினால், max_tokens மற்றும் temperature-ஐச் சேர்க்கவும்.

பதில் (response) ஒரு choices array மற்றும் ஒரு usage object உடன் வரும். அந்த usage தொகுப்பைத் தவிர்க்காதீர்கள். அதில் prompt_tokens, completion_tokens மற்றும் மொத்த எண்ணிக்கை ஆகியவை உள்ளன. நீங்கள் சொந்தமாக ஹோஸ்ட் செய்கிறீர்கள் என்றால், ஒரு குறிப்பிட்ட பயனர் தொடர்பு எவ்வளவு செலவுமிக்கது என்பதைக் கண்டறிய இது உங்களுக்கு உதவும் சமிக்ஞையாகும். நீங்கள் ஒரு மூன்றாம் தரப்பு inference வழங்குநருக்குப் பணம் செலுத்துகிறீர்கள் என்றால், இது உங்கள் பில்லிங் தரவாகும். எதுவாக இருந்தாலும், முதல் நாளிலிருந்தே இதைப் பதிவு (log) செய்யுங்கள்.

Streaming மற்றும் அதை ஏன் பயன்படுத்த வேண்டும்

ஒரு சிறிய உரைத் துண்டு தோன்றுவதற்கு முன்னால், மூன்று வினாடிகள் வரை ஒரு லோடிங் ஸ்பின்னரை (loading spinner) பார்த்துக் கொண்டிருக்க யாருக்கும் பிடிக்காது. Streaming அதைச் சரிசெய்கிறது. மாதிரி முழுமையான பதிலை முடிக்கும் வரை காத்திருப்பதற்குப் பதிலாக, சர்வர் டோக்கன்களை (tokens) அவை உருவாக்கப்படும்போதே வெளியிடுகிறது. உங்கள் கிளையண்ட் Server-Sent Events அல்லது chunked HTTP பதில்களைப் பெற்று, வார்த்தைகள் வரும்போதே அவற்றைத் திரையில் காட்ட முடியும்.

உங்கள் JSON payload-இல் stream: true என்ற flag-ஐ அமைப்பதன் மூலம் streaming-ஐ இயக்கலாம். கிளையண்ட் பக்கத்தில், நீங்கள் பொதுவாக ஸ்ட்ரீமை வரி வரியாகப் பகுப்பாய்வு செய்து (parse), data: முன்னொட்டுகளைக் (prefixes) கவனிப்பீர்கள். இணைப்பானது ஸ்ட்ரீமிங்கின் இடையில் துண்டிக்கப்பட்டால், மீண்டும் இணைக்க அல்லது non-streaming முறையில் மீண்டும் முயற்சிக்கத் தயாராக இருங்கள். உங்கள் சாட் ஆப்பின் உணரப்படும் தாமதம் (perceived latency) வியக்கத்தக்க வகையில் குறையும், மேலும் பயனர்கள் சிஸ்டம் அவர்களின் கோரிக்கையை மொத்தமாகச் செயலாக்குவதற்குப் பதிலாக, அவர்களுடன் சேர்ந்து சிந்திப்பதாக உணர்வார்கள்.

நிஜ உலகப் பணிப்பாய்வுகளுக்கான Function Calling

வெறும் உரையை (plain text) மட்டும் வழங்கும் மாதிரி பயனுள்ளது, ஆனால் கருவிகளை (tools) அழைக்கக்கூடிய மாதிரி மிகவும் பயனுள்ளது. Function calling மூலம் கிடைக்கக்கூடிய செயல்பாடுகளை விவரிக்கும் ஒரு JSON ஸ்கீமாவை (schema)—உதாரணமாக, search_orders அல்லது update_profile—உங்களால் வரையறுக்க முடியும், மேலும் மாதிரி எப்போது அவற்றைப் பயன்படுத்த வேண்டும் என்பதைத் தீர்மானிக்கும். பயனரிடம் அடுத்தடுத்த கேள்விகளைக் கேட்பதற்குப் பதிலாக, உரையாடலில் இருந்து எடுக்கப்பட்ட வாதங்களுடன் (arguments) ஒரு கட்டமைக்கப்பட்ட ஃபங்க்ஷன் அழைப்பை (function call) அது வெளியிடும்.

உதாரணமாக, ஒரு பயனர் "எனது கடைசி ஆர்டர் என்ன?" என்று கேட்டால், உங்கள் ஸ்கீமா limit அளவுருவுடன் (parameter) ஒரு get_recent_orders செயல்பாட்டை வரையறுக்கலாம். மாதிரி ஒரு tool call-ஐத் தரும், உங்கள் backend உங்கள் தரவுத்தளத்தில் (database) அந்த வினவலைச் செயல்படுத்தும், பின்னர் அதன் முடிவை ஒரு function response message ஆக மாதிரிக்குத் திருப்பி அனுப்புவீர்கள். அதன் பிறகு மாதிரி ஒரு இயல்பான மொழிப் பதிலைத் தொகுத்து வழங்கும்.

இதைச் செயல்படுத்த:

  • உங்கள் payload-இல் tools அல்லது functions array-ஐ வழங்கவும்.
  • ஒவ்வொரு கருவியையும் name, description, மற்றும் parameters ஸ்கீமாவுடன் வரையறுக்கவும்.
  • tool-calls முடிவிற்கான காரணம் அல்லது அது போன்ற சமிக்ஞைக்காகப் பதிலைச் சோதிக்கவும்.
  • உங்கள் backend-இல் கடுமையான சரிபார்ப்புடன் (strict validation) செயல்பாட்டைச் செயல்படுத்தவும். உங்கள் தரவுத்தளத்தில் சுத்திகரிக்கப்படாத (unsanitized) மாதிரி வெளியீடுகளை நேரடியாகப் பயன்படுத்த வேண்டாம்.
  • செயல்பாட்டின் முடிவை செய்தி வரலாற்றடன் (message history) இணைத்து ஒரு தொடர் கோரிக்கையை அனுப்பவும், அப்போதுதான் மாதிரி இறுதிப் பதிலைத் தர முடியும்.

இந்த முறை உருவாக்கப்படும் உரைக்கும் (generative text) மற்றும் தீர்மானிக்கப்பட்ட அமைப்புகளுக்கும் (deterministic systems) இடையிலான இடைவெளியைக் குறைக்கிறது. நீங்கள் ஒவ்வொரு கிளையையும் (branch) கடினமான குறியீடாக (hard-coding) எழுதத் தேவையில்லை; உங்கள் AI காலண்டர்களைப் படிக்கலாம், API-களைக் கோரலாம் அல்லது webhooks-களைத் தூண்டலாம்.

தயாரிப்புச் சூழலுக்கான உறுதிப்படுத்துதல் (Hardening for Production)

தயாரிப்புச் சூழலில் (production) திறந்த-எடை மாதிரிகளை இயக்குவது, எந்தவொரு விநியோகிக்கப்பட்ட அமைப்பையும் (distributed system) போலவே தோல்வி முறைகளுக்கு உங்களை உட்படுத்துகிறது, அத்துடன் சில தனித்துவமான சிக்கல்களையும் கொண்டுள்ளது. மாதிரி அனுமானம் (inference) அதிக கணக்கீட்டுத் திறன் (compute-intensive) தேவைப்படுபவை, மேலும் এন্ড்பாயிண்டுகள் (endpoints) அதிக சுமையின் கீழ் முடங்கக்கூடும். உங்கள் பயன்பாட்டை நிலையாக வைத்திருக்க இதோ சில வழிகள்.

பிழைகள் மற்றும் மறுமுயற்சிகள் (Errors and Retries)

  • 429 Too Many Requests: இது ஒரு rate-limit சமிக்ஞை (signal). exponential backoff with jitter முறையைப் பயன்படுத்தவும். ஒரு சிறிய காலதாமதத்துடன் தொடங்கி, மீண்டும் 429 பிழைகள் வரும்போது அதை இரட்டிப்பாக்கவும், ஆனால் சர்வரைத் தொடர்ந்து தாக்காமல் இருக்க சில வினாடிகளில் நிறுத்திவிடவும் (cap it).
  • 5xx Server Errors: இவை பொதுவாக தற்காலிகமானவை (transient), குறிப்பாக நீங்கள் GPU workers தொகுப்பிற்கு (pool) கோரிக்கை அனுப்பும்போது. இவற்றை மீண்டும் முயற்சிக்கவும் (retry), ஆனால் முயற்சிகளின் எண்ணிக்கைக்கு ஒரு வரம்பை (hard ceiling) நிர்ணயிக்கவும்—மூன்று என்பது ஒரு பொதுவான அளவு.
  • 4xx Client Errors: இவற்றைத் தேவையில்லாமல் மீண்டும் முயற்சிக்க வேண்டாம். 400 என்பது உங்கள் payload தவறாக இருப்பதைக் குறிக்கிறது, 401 என்பது உங்கள் token தவறானது என்பதைக் குறிக்கிறது, மற்றும் 404 என்பது அந்த endpoint-இல் model ID இல்லை என்பதைக் குறிக்கிறது. லூப் (loop) செய்வதைத் தவிர்த்து, கோரிக்கையைச் சரிசெய்யவும்.

Timeouts மற்றும் செயல்முறைத் தேக்கங்கள் (Hanging Processes)

Inference செயல்முறை, வரிசைகள் (queues) சேரும்போதோ அல்லது ஒரு worker உருவாக்கும் போது (mid-generation) செயலிழக்கும்போதோ தாமதமாகலாம். எப்போதும் ஒரு request timeout-ஐ அமைக்கவும். உங்கள் HTTP client-இன் இயல்புநிலை (default) infinity ஆக இருந்தால், அதை மாற்றவும். சாதாரண completions-க்கு 30 முதல் 60 வினாடிகள் என்பது ஒரு சரியான தொடக்கப் புள்ளியாகும்; health checks-க்கு இதைவிடக் குறைவாக இருக்க வேண்டும். Timeout ஏற்பட்டால், அதை ஒரு தோல்வியாகக் கருதி, அதைப் பதிவு செய்து (log), பயனருக்கு ஒரு தெளிவான பிழைச் செய்தியைக் காட்ட வேண்டுமா அல்லது மாற்று மாடலைப் (fallback model) பயன்படுத்தி மீண்டும் முயற்சிக்க வேண்டுமா என்று முடிவு செய்யவும்.

பட்ஜெட் கட்டுப்பாடு (Budget Control)

Token எண்ணிக்கையானது நேரடியாகப் பணம் அல்லது GPU நேரமாக மாறுகிறது. ஒவ்வொரு கோரிக்கைக்கும் prompt மற்றும் completion tokens இரண்டையும் பதிவு செய்யவும். அவற்றை ஒவ்வொரு பயனர், ஒவ்வொரு அம்சம் (feature) மற்றும் ஒவ்வொரு மாடல் பதிப்பிற்கும் (model version) தனித்தனியாகக் கண்காணிக்கவும். Open-weight மாடல்கள் நீங்கள் checkpoints-களை மாற்ற அனுமதிக்கின்றன, ஆனால் ஒவ்வொரு checkpoint-க்கும் அதன் சொந்தச் செலவு மற்றும் context-window அளவு இருக்கும். பதிவுகள் (logs) இல்லையென்றால், உங்கள் தயாரிப்பின் எந்தப் பகுதி அதிகப்படியான கணினித் திறனை (compute) வீணடிக்கிறது என்பதை நீங்கள் அறிய முடியாது.

System Messages மூலம் நடத்தையை வடிவமைத்தல் (Behavior Shaping)

System message என்பது உங்கள் கட்டுப்பாட்டின் முதல் வரிசையாகும். அதன் தொனியை (tone) அமைக்கவும், கட்டுப்பாடுகளை நடைமுறைப்படுத்தவும் மற்றும் ஒவ்வொரு பயனர் உரையாடலும் மதிக்க வேண்டிய நிலையான சூழலை (static context) வழங்கவும் இதைப் பயன்படுத்தவும். Open-weight மாடல்கள் அவற்றின் fine-tuning மற்றும் system prompts ஆகியவற்றைப் பொறுத்து மாறுபட்ட முறையில் செயல்படுவதால், இந்தத் புலத்தை (field) நீங்கள் A/B test செய்ய வேண்டிய ஒரு மாறியாக (variable) கருதவும். தெளிவற்ற system prompt தெளிவற்ற பதில்களையே தரும். துல்லியமான ஒரு prompt மாடலைச் சரியான பாதையில் வைத்திருக்கும்—உதாரணமாக, உதவியாளர் (assistant) பில்லிங் மற்றும் ரிட்டர்ன் (returns) தொடர்பானவற்றை மட்டுமே கையாள வேண்டும் என்றும், மற்ற அனைத்தையும் மரியாதையுடன் மறுக்க வேண்டும் என்றும் கூறலாம்.

உள்கட்டமைப்பு சுதந்திரம் மற்றும் தர இறையாண்மை (Data Sovereignty)

Open-weight மாடல்களின் அமைதியான நன்மைகளில் ஒன்று அதன் உரிமை (custody) ஆகும். உங்கள் prompts மற்றும் completions உங்கள் சூழலை (environment) விட்டு வெளியேற வேண்டிய அவசியமில்லை. நீங்கள் மாடலை on-premises அல்லது ஒரு virtual private cloud-க்குள் இயக்கினால், மூன்றாம் தரப்பு தரவு செயலாக்க ஒப்பந்தங்களைத் தவிர்க்கலாம் மற்றும் பயிற்சித் தரவு (training-data) சர்ச்சைகளில் இருந்து விலகி இருக்கலாம். இது சுகாதாரம், நிதி மற்றும் தரவு கசிவு என்பது ஒரு இணக்கச் சிக்கலாக (compliance event) மாறும் எந்தவொரு துறையிலும் முக்கியமானது.

நீங்கள் ஒரு வெளிப்புற inference host-ஐப் பயன்படுத்தினாலும், open weights உங்களுக்கு இடமாற்றத் திறனை (portability) வழங்குகிறது. அந்த host விலையையோ அல்லது விதிமுறைகளையோ மாற்றினால், நீங்கள் அதே மாடல் கோப்புகளை மற்றொரு வழங்குநருக்கு மாற்றலாம் அல்லது உங்கள் நிறுவனத்திற்குள்ளேயே கொண்டு வரலாம். ஒரு நிறுவனம் மட்டுமே weights-களை வைத்திருப்பதால், நீங்கள் ஒரே ஒரு API-உடன் மட்டும் பிணைக்கப்படவில்லை (locked in).

ஒரு நடைமுறைத் தொடக்கப் புள்ளி

நீங்கள் இன்று ஒருங்கிணைக்கத் தொடங்குகிறீர்கள் என்றால், ஒரு மாடல் மற்றும் ஒரு endpoint-உடன் தொடங்குங்கள். அங்கீகாரம் (authentication), மீண்டும் முயற்சித்தல் (retries) மற்றும் token logging ஆகியவற்றைச் கையாளும் ஒரு சிறிய abstraction layer-க்குள் உங்கள் HTTP client-ஐச் சுற்றவும். அடுத்து streaming வசதியைச் சேர்க்கவும், ஏனெனில் பயனர் அனுபவத்தில் அதன் பலன் உடனடியாகத் தெரியும். பின்னர், ஒரு முக்கியமான பணிப்பாய்விற்காக (workflow)—status lookups, content moderation, அல்லது form filling—ஒரு function call-ஐ அறிமுகப்படுத்தவும். விரிவாக்கத்தைத் தொடங்குவதற்கு முன் ஒரு வாரம் காலதாமதம் (latency), பிழை விகிதங்கள் (error rates) மற்றும் token செலவைக் கண்காணிக்கவும்.

Open-weight மாடல்கள் ஒரு முழுமையாக நிர்வகிக்கப்படும் API-யை விட அதிக அமைப்பை (setup) கோருகின்றன, ஆனால் அவை வெளிப்படைத்தன்மை, நெகிழ்வுத்தன்மை மற்றும் கட்டுப்பாட்டுடன் அந்த முயற்சியைத் திருப்பித் தருகின்றன. ஒருங்கிணைப்பை கவனமாக உருவாக்குங்கள், அனைத்தையும் முறையாகக் கண்காணிங்கள் (instrument everything), அப்போதுதான் உங்கள் பயன்பாட்டிற்குத் தேவையான துல்லியமான AI அடுக்கைப் பெற முடியும்.

மூலங்கள் மற்றும் கூடுதல் வாசிப்பு