பெரிய மொழி மாதிரிகள் (Large Language Models) பற்றிய எந்தவொரு தொழில்நுட்ப விவாதத்திலும் ஐந்து நிமிடங்கள் செலவிடுங்கள், நீங்கள் ஒரே கேள்வியைக் கேட்பீர்கள்: எந்த மாதிரி சிறந்தது? ஒரு அடிப்படை மாதிரியைத் தேர்ந்தெடுப்பது என்பது ஒரு AI தயாரிப்பு வாழ்வா அல்லது சாவா என்பதைத் தீர்மானிக்கும் ஒரே முடிவு என்பது போல, குழுக்கள் பெஞ்ச்மார்க் லீடர்போர்டுகள் (benchmark leaderboards), பாராமீட்டர் எண்ணிக்கை (parameter counts) மற்றும் கான்டெக்ஸ்ட் விண்டோ அளவுகள் (context window sizes) ஆகியவற்றைக் குறித்துத் தீவிரமாக விவாதிக்கிறார்கள். அது உண்மையல்ல. உண்மையான உற்பத்தி அமைப்புகளில் (production systems), மாதிரியை விட அதைச் சுற்றியுள்ள ஹார்னஸ் (harness) மிக முக்கியமானது.
ஹார்னஸ் இல்லாத ஒரு மாதிரி என்பது வெறும் உரை உருவாக்கி (text generator) மட்டுமே. ஒரு ஹார்னஸ் அந்த உருவாக்கித் திறனை பயனர்களுக்கோ அல்லது முக்கியமான வணிகத் தர்க்கங்களுக்கோ (business logic) பயன்படுத்தக்கூடிய வகையில் நம்பகமானதாகவும், கண்காணிக்கக்கூடியதாகவும் மற்றும் பாதுகாப்பானதாகவும் மாற்றுகிறது.
ஹார்னஸ் உண்மையில் என்ன?
மூல மாதிரி எடைகளுக்கும் (raw model weights) உங்கள் இறுதிப் பயனருக்குக் கிடைக்கும் மதிப்பிற்கும் இடையில் இருக்கும் அனைத்தும் ஹார்னஸ் ஆகும். இதில் பிராம்ட் மேலாண்மை (prompt management), தகவல் மீட்டெடுப்பு குழாய்கள் (retrieval pipelines), வெளியீட்டு சரிபார்ப்பு (output validation), கருவி ஒருங்கிணைப்பு (tool orchestration), மதிப்பீட்டுத் தொகுப்புகள் (evaluation suites), லாகிங் (logging), மாற்றுத் தர்க்கம் (fallback logic), செலவுக் கட்டுப்பாடுகள் (cost controls) மற்றும் கருத்துத் தெரிவிக்கும் வழிமுறைகள் (feedback mechanisms) ஆகியவை அடங்கும். மாதிரியை ஒரு இயந்திரமாகவும் (engine), ஹார்னஸை அந்த இயந்திரத்தின் அடித்தளம் (chassis), பிரேக்குகள், ஸ்டீயரிங் மற்றும் டேஷ்போர்டு ஆகியவையாகவும் கற்பனை செய்து கொள்ளுங்கள். மோசமாக உருவாக்கப்பட்ட கட்டமைப்பில் ஒரு சக்திவாய்ந்த இயந்திரம் இருந்தால், அது முதல் வளைவிலேயே விபத்துக்குள்ளாகும்.
மிகவும் பல குழுக்கள் ஒருங்கிணைப்பை (integration) ஒரு ஒற்றை API அழைப்பாகவே கருதுகிறார்கள். அவர்கள் ஒரு பயனர் சரத்தை (user string) நேரடியாக chat.completions.create-க்கு அனுப்பிவிட்டு, அதன் முடிவை திரையில் காட்டிவிட்டு, அதை ஒரு தயாரிப்பு என்று அழைக்கிறார்கள். இது ஒரு டெமோவிற்கு (demo) வேலை செய்யும். ஆனால் தெளிவற்ற நிலை (ambiguity), எதிர்ப்புத் தாக்குதல் உள்ளீடுகள் (adversarial input), பல படிநிலைத் தர்க்கம் (multi-step reasoning) அல்லது வெளிப்புற அமைப்புகளுடனான இணைப்பு தேவைப்படும்போது அது தோல்வியடையும். பொறியியல் ஒழுக்கம் (engineering discipline) என்பது ஹார்னஸில் தான் உள்ளது. பிழைகளை நீங்கள் அதில் தான் பிடிக்கிறீர்கள், தவறான தகவல்களை உருவாக்குவதிலிருந்து (hallucinations) மீண்டு வருகிறீர்கள், மேலும் ஒரு பயனுள்ள AI ஒரு ஸ்கீமாவை (schema) தவறாகப் புரிந்துகொள்வதால் தற்செயலாக ஒரு தரவுத்தளப் பதிவை (database record) நீக்கிவிடாமல் இருப்பதை உறுதி செய்கிறீர்கள்.
பெஞ்ச்மார்க்குகள் முக்கியமானவற்றைத் தவிர்க்கின்றன
பொது பெஞ்ச்மார்க்குகள் பரந்த அறிவை அளவிடுகின்றன, உங்கள் குறிப்பிட்ட சிக்கலை அல்ல. ஒரு மாதிரி மருத்துவ உரிமக் கேள்விகளில் 90-வது சதவீத மதிப்பெண்ணைப் பெறலாம், ஆனால் உங்கள் நிறுவனத்தின் டிக்கெட்-ரூட்டிங் (ticket-routing) பணிப்பாய்வில் முற்றிலும் தோல்வியடையலாம்; ஏனெனில் அது உங்கள் சுருக்கங்கள் (abbreviations), உங்கள் விளிம்பு நிலை நிகழ்வுகள் (edge cases) அல்லது ஒரே வாக்கியத்தில் மூன்று மொழிகளில் எழுதும் உங்கள் பயனர்களுக்கு எதிராக ஒருபோதும் சோதிக்கப்படவில்லை.
ஹார்னஸ் அந்த இடைவெளியை நிரப்புகிறது. ஒரு முறையான மதிப்பீட்டு ஹார்னஸ், மற்றவர்களின் தரப்படுத்தப்பட்ட சோதனையை அல்லாமல், உங்கள் உண்மையான உற்பத்தி பிராம்ட்களை (production prompts) உங்கள் உண்மையான எதிர்பார்க்கப்படும் வெளியீடுகளுடன் இயக்கிப் பார்க்கிறது. நீங்கள் ஒரு மாதிரி வழங்குநரிடமிருந்து மற்றொருவருக்கு மாறும்போது ஏற்படும் பின்னடைவுகளை (regressions) அது கண்காணிக்கிறது. பேரழிவை ஏற்படுத்தும் தவறான புரிதல்களுக்குக் காரணமான அந்த 2 சதவீத உள்ளீடுகளை அது வெளிச்சத்திற்குக் கொண்டு வருகிறது. இது இல்லையென்றால், நீங்கள் எதையும் தெரியாமல் பயணிக்கிறீர்கள். இது இருந்தால், நீங்கள் ஒரு சிறிய, மலிவான மாதிரியைப் பயன்படுத்தியும் ஒரு பெரிய மாதிரியை விடச் சிறப்பாகச் செயல்பட முடியும், ஏனெனில் தோல்வி முறைகளை நீங்கள் கண்டறிந்து, அவற்றை சூழல் ஊசி (context injection) அல்லது பின்-செயலாக்க விதிகள் (post-processing rules) மூலம் சரிசெய்துள்ளீர்கள்.
பாதுகாப்பு ஹார்னஸில் உள்ளது, எடைகளில் (Weights) இல்லை
கட்டுப்பாடுகள் இல்லையென்றால் திறன்கள் ஆபத்தானவை. உலகின் புத்திசாலித்தனமான மாதிரிக்குக் கூட உற்பத்தி API-கள், வாடிக்கையாளர் தரவு அல்லது இயக்கக்கூடிய குறியீடு (executable code) ஆகியவற்றிற்கு நேரடி, இடைத்தரகர் இல்லாத அணுகல் இருக்கக்கூடாது. மாதிரி எதைத் தொட அனுமதிக்கப்படுகிறது மற்றும் செயல்படுத்தப்படுவதற்கு முன் கோரிக்கைகள் எவ்வாறு சரிபார்க்கப்படுகின்றன என்பதை ஹார்னஸ் வரையறுக்கிறது.
ஒரு எளிய உதாரணத்தைக் கருதுங்கள்: ஆர்டர் நிலை (order status) மற்றும் ரீஃபண்ட் (refund) ஆகியவற்றைச் சரிபார்க்கக்கூடிய ஒரு ஆதரவு முகவர் (support agent). மாதிரி இயற்கையான மொழியில் செயல்களைப் பரிந்துரைக்கிறது. ஹார்னஸ் அந்தப் பரிந்துரைகளை கட்டமைக்கப்பட்ட API அழைப்புகளாக மாற்றுகிறது, பயனர் அனுமதிகளைச் சரிபார்க்கிறது, கோரப்பட்ட பயனர் கணக்கில் ஆர்டர் ஐடி உள்ளதா என்பதைச் சரிபார்க்கிறது, ரேட் லிமிட்களை (rate limits) அமல்படுத்துகிறது மற்றும் ஒரு குறிப்பிட்ட வரம்பிற்கு மேலான ரீஃபண்ட்களுக்குத் தெளிவான மனித உறுதிப்படுத்தலைத் தேவைப்படுத்துகிறது. மாதிரி முன்மொழிகிறது. ஹார்னஸ் அனுமதிக்கிறது. "மாதிரி இப்போது புத்திசாலியாகிவிட்டது" என்பதற்காக இந்த அடுக்குகளில் எதையாவது நீக்குவது என்பது, ஒரு விலையுயர்ந்த பொறுப்புத் தன்மையை (liability) உருவாக்குவதாகும்.
உள்ளடக்கப் பாதுகாப்பிற்கும் (content safety) இதுவே பொருந்தும். அடிப்படை மாதிரிகள் தீங்கு விளைவிக்கும், சார்பான அல்லது பிராண்டிற்குப் பொருந்தாத வெளியீடுகளை உருவாக்கலாம். ஒரு ஹார்னஸ் வெளியீட்டு வகைப்படுத்திகள் (output classifiers), மாற்றியமைக்கப்பட்ட பிராம்ட்களுடன் கூடிய மறுமுயற்சி கொள்கைகள் (retry policies) மற்றும் தணிக்கைப் பதிவுகளுக்கான (audit trails) லாகிங் ஆகியவற்றைச் செயல்படுத்துகிறது. அடிப்படை மாதிரி வழங்குநர் இதைத் துல்லியமாகத் தீர்க்கும் வரை காத்திருப்பது ஒரு உத்தியல்ல; அது உங்கள் நற்பெயரை வைத்து நீங்கள் எடுக்கும் ஒரு சூதாட்டம்.
ஒரு உற்பத்தி ஹார்னஸின் கட்டமைப்பு (Anatomy)
நீங்கள் நீண்ட காலத்திற்கு உருவாக்கப் போகிறீர்கள் என்றால், உங்கள் ஹார்னஸ் மற்ற எந்தப் பின்னணி அமைப்பையும் (backend system) போலவே கவனமாக வடிவமைக்கப்பட வேண்டும். பொம்மைகளையும் கருவிகளையும் வேறுபடுத்தும் கூறுகள் இங்கே உள்ளன.
மதிப்பீடு மற்றும் பின்னடைவு சோதனை (Evaluation and regression testing). ஒவ்வொரு பயன்பாட்டிற்கும் (deployment) முன்னும் தானாகவே இயங்கும் உண்மையான பயனர் வினவல்கள் மற்றும் எதிர்பார்க்கப்படும் நடத்தைகளின் தொகுப்பு உங்களுக்குத் தேவை. உங்கள் பிராம்ட் டெம்ப்ளேட்டை மாற்றினாலோ அல்லது மாதிரிகளை மாற்றினாலோ, துல்லியம் மேம்பட்டதா மற்றும் நீங்கள் ஒரு முக்கியமான பணிப்பாய்வை உடைத்துவிட்டீர்களா என்பதை சில நிமிடங்களில் நீங்கள் பார்க்க வேண்டும்.
கண்காணிப்பு மற்றும் தடயமறிதல் (Observability and tracing). LLM அழைப்புகள் நிச்சயமற்றவை மற்றும் செலவு மிகுந்தவை. மீட்டெடுப்பு (retrieval), ப்ராம்ப்ட் உருவாக்கம் (prompt construction), மாடல் அனுமானம் (model inference) மற்றும் பின்-செயலாக்கம் (post-processing) ஆகியவற்றின் மூலம் ஒவ்வொரு கோரிக்கையையும் நீங்கள் கண்காணிக்க வேண்டும். ஒரு பயனர் தவறான முடிவைப் புகாரளிக்கும் போது, அதை உருவாக்கிய துல்லியமான சூழல் (context) மற்றும் ப்ராம்ப்ட்டை நீங்கள் மீண்டும் உருவாக்க முடி deve.
சூழல் பொறியியல் (Context engineering). பெரும்பாலான உற்பத்தித் தோல்விகள் மாடலின் முட்டாள்தனத்தால் அல்ல, மாறாகத் தவறான சூழலால் (context) ஏற்படுகின்றன. உங்கள் ஹார்னஸ் (harness) தரவுத் துண்டாக்கல் உத்திகள் (chunking strategies), மீட்டெடுப்பு வரிசைப்படுத்துதல் (retrieval ranking), டோக்கன் வரவு (token budgets) மற்றும் மறுவரிசைப்படுத்தும் தர்க்கத்தை (re-ranking logic) நிர்வகிக்கிறது. சிறந்த முறையில் மீட்டெடுக்கப்பட்ட சூழலைக் கொண்ட ஒரு சாதாரண மாடல், மோசமான சூழலைக் கொண்ட ஒரு அதிநவீன (frontier) மாடலை கிட்டத்தட்ட எப்போதும் தோற்கடிக்கும்.
கருவி பயன்பாடு மற்றும் பாதுகாப்பு வளையங்கள் (Tool use and guardrails). மாடல் அழைக்கக்கூடிய எந்தவொரு செயல்பாடும் ஸ்கீமா சரிபார்ப்பு (schema validation), அனுமதிச் சரிபார்ப்பு (permission checks) மற்றும் தூய்மைப்படுத்துதல் (sanitization) ஆகியவற்றின் மூலம் செல்ல வேண்டும். ஹார்னஸ் பார்சிங் பிழைகளை (parsing errors) கனிவாகக் கையாள வேண்டும். மாடல் ஒரு அளவுருவை (parameter) தவறாகக் கற்பனை செய்தால் (hallucinates), ஹார்னஸ் அதைச் செயல்படுத்தாமல் நிராகரிக்க வேண்டும்.
செலவு மற்றும் தாமதக் கட்டுப்பாடுகள் (Cost and latency controls). ஒவ்வொரு வினாவிற்கும் மிகப்பெரிய மாடல் தேவையில்லை. ஹார்னஸில் உள்ள ஒரு ரூட்டிங் அடுக்கு (routing layer) வரும் கோரிக்கைகளை வகைப்படுத்தி, எளிமையான கேள்விகளைச் சிறிய, வேகமான மாடல்களுக்கு அனுப்பலாம், அதே நேரத்தில் சிக்கலான பணிகளுக்காக அதிக செலவு பிடிக்கும் பகுத்தறிவுத் திறனை (reasoning) ஒதுக்கி வைக்கலாம். பொதுவான பதில்களைத் தற்காலிக சேமிப்பில் (caching) வைப்பது தேவையற்ற அனுமானங்களைத் தவிர்க்கிறது.
பின்னூட்ட சுழற்சிகள் (Feedback loops). ஹார்னஸ் thumbs-up, thumbs-down, திருத்தங்கள் மற்றும் தொடர் கேள்விகள் போன்ற மறைமுக சமிக்ஞைகளைப் பிடிக்க வேண்டும். இந்தத் தரவு ப்ராம்ப்ட் மேம்பாடு (prompt refinement), ஃபைன்-டியூனிங் (fine-tuning) அல்லது மதிப்பீட்டுத் தொகுப்பு விரிவாக்கம் (evaluation set expansion) ஆகியவற்றிற்குப் பயன்படுத்தப்படுகிறது. மாடல் தானாகவே உற்பத்தியிலிருந்து கற்றுக்கொள்வதில்லை; ஹார்னஸ் தான் அந்தப் பாடங்களைச் சேகரிக்க வேண்டும்.
மாடல்கள் ஒரு commodity. ஹார்னஸ்கள் ஒரு பாதுகாப்பு அரண் (Moats).
அடிப்படை மாடல் அடுக்கு (foundation model layer) வேகமாகச் சுருங்கி வருகிறது. விலைகள் குறைகின்றன, திறன்களுக்கு இடையிலான இடைவெளியை open weights குறைத்து வருகின்றன, மேலும் வழங்குநர்களுக்கு இடையிலான மாற்றச் செலவுகள் (switching costs) ஒவ்வொரு காலாண்டிலும் குறைந்து வருகின்றன. இரண்டு ஆண்டுகளில், நீங்கள் தேர்ந்தெடுத்த குறிப்பிட்ட மாடலை மூன்று மலிவான மாற்றுகளுடன் எளிதாக மாற்ற முடியும். நீடித்திருக்கும் பொறியியல் முதலீடு என்பது அதைச் சுற்றி நீங்கள் உருவாக்கும் உள்கட்டமைப்பு (infrastructure) ஆகும்.
இதை உணர்ந்த நிறுவனங்கள் தங்களின் மிக அரிதான வளமான—திறமையான பொறியியல் நேரத்தை—சிஸ்டம்ஸ் இன்டக்ரேஷன் அடுக்கில் (systems integration layer) கவனம் செலுத்துகின்றன. அவை தங்கள் துறை சார்ந்த பிரத்யேக மதிப்பீட்டுத் தரவுத் தொகுப்புகளை (proprietary evaluation datasets) உருவாக்குகின்றன. அவை பல ஆண்டுகால நிறுவன அறிவு சார்ந்த மீட்டெடுப்பு குழாய்களை (retrieval pipelines) உருவாக்குகின்றன. தீர்ப்புத் தேவைப்படும் இடங்களில் மனிதர்களைத் தொடர்பில் வைத்திருக்கும் (humans in the loop) தொடர்பு முறைகளை அவை வடிவமைக்கின்றன. அது பாதுகாப்பானது (defensible). ஒரு சிறந்த API endpoint அல்ல.
இதன் பொருள் உங்கள் சாலை வரைபடம் (roadmap) மற்றொரு நிறுவனத்தின் வெளியீட்டுச் சுழற்சிக்கு அடிமையாக இருக்கக்கூடாது என்பதாகும். ஒரு வலுவான ஹார்னஸ், அடிப்படை மாடல்களை மிகக் குறைந்த சிரமத்துடன் மாற்ற அனுமதிக்கிறது. ஒரு புதிய பதிப்பு வரும்போது, உங்கள் மதிப்பீட்டுத் தொகுப்பை (eval suite) இயக்கி, பின்னடைவுகளைச் (regressions) சரிபார்த்து, எண்கள் மேம்பட்டால் மாற்றிக்கொள்ளலாம். ஹார்னஸ் இல்லையென்றால், சமீபத்திய மாடல் மாற்றப் பட்டியல் (changelog) உங்கள் தேவைகளைப் பூர்த்தி செய்யும் என்று நீங்கள் பிரார்த்தனை செய்துகொண்டே இருக்க வேண்டியிருக்கும்.
உண்மையான கருத்து (The Real Takeaway)
மாடல் தேர்வை முதன்மையான மூலோபாய முடிவாகக் கருதுவதை நிறுத்துங்கள். அது ஒரு கொள்முதல் (procurement) சார்ந்த விஷயம். மாடல் வெளியீடுகளைப் பாதுகாப்பாகவும், நிலையானதாகவும் மற்றும் கண்காணிக்கக்கூடியதாகவும் வணிக முடிவுகளாக மாற்றும் இயந்திரத்தை உருவாக்குவதே மூலோபாயப் பணியாகும். மாடலை வாங்குங்கள், ஆனால் ஹார்னஸை உருவாக்குங்கள். AI பயன்பாட்டின் அடுத்த கட்டத்தில் வெற்றி பெறும் குழுக்கள், ஒரு சாதாரண மாடலில் கட்டமைக்கப்பட்ட நம்பகமான அமைப்பு, ஒரு சிறந்த மாடலில் கட்டமைக்கப்பட்ட கட்டுப்பாடற்ற அமைப்பை எப்போதும் தோற்கடிக்கும் என்பதைப் புரிந்துகொண்டவர்களாக இருப்பார்கள்.