நீங்கள் செயற்கை நுண்ணறிவு (artificial intelligence) மூலம் உருவாக்கத் தொடங்கும்போது, அனைவரும் ஒரே விஷயத்தையே பெரிதும் வலியுறுத்துகிறார்கள்: அதுதான் 'மாதிரி' (model). சரியான மாதிரியைத் தேர்ந்தெடுத்துவிட்டால், மற்ற அனைத்தும் தானாகவே சரியாகிவிடும் என்று அவர்கள் கூறுகிறார்கள். எனது சொந்தச் சோதனைகளில் சில வாரங்கள் கழித்து, அது உண்மையல்ல என்பதை என்னால் சொல்ல முடிகிறது. கிடைக்கக்கூடிய பெரிய மொழி மாதிரிகளுக்கு (large language models) இடையே சரியானதைத் தேர்ந்தெடுப்பது முக்கியம்தான், ஆனால் அது வேலையில் இருபது சதவீதம் மட்டுமே. மீதமுள்ள எட்டும் அமைப்பியல் சார்ந்த வேலைகள் (systems work). அது குழாய் அமைப்புகளைப் போன்ற அடிப்படை வேலைகள், நுணுக்கமான கலை மற்றும் இடைவிடாத சோதனைகளை உள்ளடக்கியது. இந்த உணர்தல் எனக்கு ஆரம்பத்திலேயே கிடைத்துவிட்டது, அது அதன் பிறகு நான் அணுகும் ஒவ்வொரு திட்டத்தையும் மாற்றியமைத்துள்ளது.
மாதிரி என்பது வெறும் தொடக்கமே
தொடக்கநிலையாளர்கள் ஏன் மாதிரிகளைப் பற்றி இவ்வளவு ஆவலோடு இருக்கிறார்கள் என்பதைப் புரிந்துகொள்வது எளிது. புதிய வெளியீடுகள் சிறந்த தர்க்கம் (reasoning), பெரிய சூழல் சாளரங்கள் (context windows) மற்றும் தெளிவான வெளியீடுகளைத் தருவதாகக் கூறுகின்றன. அந்த முன்னேற்றங்கள் உண்மையானவைதான், ஆனால் அவை பொதுவான நோக்கங்களுக்கானவை. ஒரு அதிநவீன மாதிரி (state-of-the-art model) உங்கள் நிறுவனத்தின் ரீஃபண்ட் கொள்கையைத் தானாகவே தெரிந்து கொள்ளாது. நீங்கள் எப்படிச் செய்ய வேண்டும் என்று சொல்லாதவரை, அது உங்கள் மொபைல் செயலிக்கான பதில்களைத் துல்லியமாக வடிவமைக்காது. அது தானாகவே எங்கிருந்தோ நேரடி இருப்புத் தரவுகளை (live inventory data) எடுக்க முடியாது.
இதை நான் கடினமான முறையில் கற்றுக்கொண்டேன். எனது முதல் முன்மாதிரி (prototype) ஒரு திறமையான மாதிரியைப் பயன்படுத்தியது, அது அழகான மற்றும் நம்பிக்கையான பத்திகளை உருவாக்கியது, ஆனால் அவை அவ்வப்போது முற்றிலும் தவறாக இருந்தன. அந்த மாதிரி தொனியில் (tone) தேர்ச்சி பெற்றிருந்ததால், உரை தொழில்முறை ரீதியாகத் தோன்றியது, ஆனால் அதற்கு தற்போதைய தகவல்களை அணுகும் வசதி இல்லை. நான் தரவுப் பாதைகள் (data pipelines) மற்றும் சூழல் ஊசி (context injection) பற்றிச் சிந்திக்க வேண்டிய இடத்தில், மாதிரி அளவீடுகளை (model benchmarks) ஒப்பிடுவதிலேயே பல நாட்களைச் செலவிட்டேன். மாதிரி பழுதாகவில்லை; அதைச் சுற்றியுள்ள அமைப்பே முழுமையடையாமல் இருந்தது. நீங்கள் வெறும் விளக்கக்காட்சிகளிலிருந்து (demos) மக்கள் உண்மையில் நம்பிப் பயன்படுத்தும் மென்பொருளுக்கு மாறும்போது, இந்த வேறுபாடுதான் மிக முக்கியமானது.
ப்ராம்ப்ட்கள் (Prompts) என்பவை குறியீடு (Code), பரிந்துரைகள் அல்ல
உயர்தர ப்ராம்ப்ட்கள் (prompts) எந்தவொரு நம்பகமான AI பயன்பாட்டிற்கும் இதயமாக அமைகின்றன. ஆரம்பத்தில், நான் ப்ராம்ப்ட்களைத் தேடல் வினவல்களைப் (search queries) போலக் கருதினேன்—சுருக்கமானவை, இயல்பானவை மற்றும் நம்பிக்கையானவை. நான் ஒரு மாதிரியிடம் "இதைச் சுருக்கவும்" அல்லது "உதவியாக இருங்கள்" என்று கேட்டுவிட்டு, சிறந்த முடிவிற்காகக் காத்திருப்பேன். முடிவுகள் பயனுள்ளது மற்றும் தேவையற்றது எனத் தாறுமாறாக மாறிக்கொண்டே இருந்தன, அதற்குக் காரணம் என்னவென்றே எனக்குத் தெரியவில்லை.
இப்போது நான் ப்ராம்ப்ட்களை லேசான நிரல்களாக (lightweight programs) கருதுகிறேன். ஒரு நல்ல ப்ராம்ப்ட் அதன் பங்கினை வரையறுக்கிறது, வெளியீட்டு வடிவத்தைக் குறிப்பிடுகிறது, தேவைப்படும்போது உதாரணங்களைச் சேர்க்கிறது மற்றும் எல்லைகளை வகுக்கிறது. எனக்கு JSON வேண்டுமென்றால், நான் JSON-ஐக் கேட்டு அதன் ஸ்கீமாவைக் (schema) காட்டுகிறேன். எனக்குச் சுருக்கமான பதில் வேண்டுமென்றால், அதன் நீளத்தைக் கட்டுப்படுத்தி, முன்னுரையைத் தவிர்க்கச் சொல்கிறேன். மீண்டும் மீண்டும் திருத்துவது (Iteration) முக்கியம். நான் ப்ராம்ப்ட்கள் மற்றும் அவற்றின் வெளியீடுகளின் பதிவை வைத்துக்கொண்டு, ஒவ்வொரு முறையும் ஒரு மாறியை (variable) மட்டும் மாற்றிச் சோதிப்பேன். ஒரு ப்ராம்ப்ட்டில் உள்ள ஒரு தெளிவற்ற உரிச்சொல் (adjective), முழு பணிப்பாய்வின் (workflow) செயல்பாட்டையும் மாற்றக்கூடும். அந்தத் துல்லியம் முறையான அணுகுமுறையைக் கோருகிறதே தவிர, யூகங்களை அல்ல.
தவறான உள்ளீடு, தவறான வெளியீடு (Garbage In, Garbage Out)
நம்பகமான தரவு மீட்டெடுப்பு (data retrieval) என்பது பல AI திட்டங்கள் அமைதியாகத் தோல்வியடையும் இடமாகும். மாதிரிகளுக்குத் தனிப்பட்ட அல்லது தற்போதைய தரவுகளை அணுகுவதற்கு, Retrieval-Augmented Generation அல்லது RAG என்பது ஒரு தரப்படுத்தப்பட்ட முறையாக மாறியுள்ளது. இதன் கருத்து எளிமையானது: தொடர்புடைய ஆவணங்களைப் பெற்று, அவற்றை மாதிரியின் சூழல் சாளரத்தில் (context window) திணித்து, உண்மைகளின் அடிப்படையில் மாதிரி சிந்திப்பதைத் தூண்டுவது. ஆனால் நடைமுறையில் இது மிகவும் சிக்கலானது.
தொடர்பற்ற முடிவுகளைத் தொடர்ந்து வழங்கிக் கொண்டிருந்த ஒரு எளிய அறிவுத் தளத்தை (knowledge base) சரிசெய்ய நான் நேரத்தைச் செலவிட்டேன். மாதிரி சரியாக இருந்தது, ஆனால் தரவு மீட்டெடுப்பு அடுக்கு (retrieval layer) தோல்வியடைந்தது. எனது தரவுத் துண்டுகள் (chunks) மிகவும் சிறியதாகவும், சூழல் அற்றதாகவும் இருந்தன. நகல் தலைப்புகளைச் (duplicate headers) சுத்தப்படுத்தாமல் எனது எம்பெடிங்குகள் (embeddings) உருவாக்கப்பட்டன. ஒற்றுமைத் தேடல் (similarity search), தொழில்நுட்ப ரீதியாக நெருக்கமான ஆனால் தவறான கேள்விக்கு விடையளிக்கும் உரையைத் தேடிக் கண்டது. இதைச் சரிசெய்ய, தரவுத் துண்டாக்குதல் உத்தி (chunking strategy), மெட்டாடேட்டா வடிகட்டிகள் (metadata filters) மற்றும் மறுவரிசைப்படுத்தும் படிநிலை (re-ranking step) ஆகியவற்றை மீண்டும் சிந்திக்க வேண்டியிருந்தது. தரவு மீட்டெடுப்பு நிலைபெற்றவுடன், மாதிரியின் பதில்கள் உடனடியாக மேம்பட்டன. பாடம் தெளிவாக இருந்தது: ஒரு சிறந்த மாதிரியைக் கொண்டு மோசமான தரவு மீட்டெடுப்பைச் சரிசெய்ய முடியாது. நீங்கள் தரவுப் பாதையை (pipeline) சரியாக உருவாக்க வேண்டும்.
நீங்கள் அளவிடாத ஒன்றைத் தரம் உயர்த்த முடியாது
தொடர்ச்சியான மதிப்பீடு (evaluation) என்பது சோதனைகளையும் தயாரிப்புகளையும் வேறுபடுத்தும் பழக்கமாகும். நான் தொடங்கியபோது, உணர்வுப்பூர்வமாக (vibe) மதிப்பீடு செய்தேன். ஐந்து வெளியீடுகளைப் படித்துவிட்டு, திருப்தி அடைந்து அடுத்த கட்டத்திற்குச் செல்வேன். ஒரு பயனர் ஆறாவது கேள்வியைக் கேட்டு ஏதோ விசித்திரமான பதிலைப் பெறும் வரை இது வேலை செய்யும்.
இப்போது ஒவ்வொரு அம்சத்திற்கும் (feature) சிறிய மதிப்பீட்டுத் தொகுப்புகளை உருவாக்குகிறேன். உண்மையான பயனர் வினவல்களைச் சேகரித்து, எதிர்பார்க்கப்படும் நடத்தையை அடையாளப்படுத்தி, அவற்றிற்கு எதிராகத் தானியங்கி சோதனைகளைச் செய்கிறேன். தரவு விலகல் (drift) குறித்து நான் கவனமாக இருக்கிறேன்: கடந்த மாதம் வேலை செய்த ஒரு ப்ராம்ப்ட், மாதிரி புதுப்பிக்கப்பட்ட பிறகு அல்லது அடிப்படைத் தரவுகள் மாறிய பிறகு அதன் செயல்திறன் குறையலாம். நான் பாணியின் மதிப்பீட்டை (style evaluation) உண்மைத் துல்லியத்திலிருந்து (factual accuracy) பிரிக்கிறேன். தொழில்முறைத் தோற்றத்துடன் இருப்பது நல்லது; ஆனால் சரியாக இருப்பது கட்டாயமானது. இந்தச் சுழற்சி இல்லாமல், நீங்கள் நம்பிக்கையின் அடிப்படையில் மென்பொருளை வெளியிடுகிறீர்கள், ஆனால் நம்பிக்கை என்பது ஒரு சோதனை உத்தி அல்ல.
இயந்திரத்தின் எல்லைகளைத் தெரிந்து கொள்ளுங்கள்
மாதிரியின் (model) வரம்புகளைப் புரிந்துகொள்வது, நான் அளவுக்கு அதிகமாக வாக்குறுதி அளிப்பதிலிருந்தும், எதிர்பார்த்ததை விடக் குறைவானவற்றை வழங்குவதிலிருந்தும் என்னை விடுவித்துள்ளது. இந்த அமைப்புகளுக்கு உண்மையான கட்டுப்பாடுகள் உள்ளன. சூழல் சாளரங்கள் (context windows) முன்பை விடப் பெரியதாக இருந்தாலும், அவற்றுக்கும் ஒரு உச்சவரம்பு உள்ளது; அவற்றை முழுமையாக நிரப்புவது அதன் ஓரங்களில் செயல்திறனைக் குறைக்கிறது. மாதிரிகள் தவறான தகவல்களை உருவாக்குகின்றன (hallucinate), குறிப்பாகப் பயிற்சித் தரவு குறைவாக உள்ள குறிப்பிட்ட தலைப்புகளில் இது அதிகம் நடக்கும். துல்லியமான கணிதத் திறனிலும், சில வகையான பல படிநிலை தர்க்கங்களிலும் (multi-step logic) அவை சிரமப்படுகின்றன. அவை சொற்றொடர் அமைப்பிற்கு (phrasing) மிகவும் உணர்திறன் கொண்டவை.
செலவு மற்றும் வேகமும் வரம்புகளே. பத்து வினாடிகளில் ஒரு சிறந்த உரைநடையை உருவாக்கும் மாதிரி, நிகழ்நேர அரட்டை இடைமுகத்தில் (real-time chat interface) பயன்படுத்த முடியாததாக இருக்கலாம். நான் இப்போது அம்சங்களை (features) ஆரம்பத்திலேயே தாமத வரவுத் திட்டங்களுடன் (latency budgets) ஒப்பிட்டுப் பார்க்கிறேன். ஒரு பணிக்கு ஒரு வினாடிக்கும் குறைவான பதில் தேவைப்பட்டால், நான் பதில்களை முன்கூட்டியே கணக்கிடலாம் (precompute), தீவிரமாகத் தற்காலிக சேமிப்பைப் (cache) பயன்படுத்தலாம், அல்லது முதல் வரைவிற்கு ஒரு சிறிய மாதிரியையும், அதைச் செம்மைப்படுத்த மட்டும் ஒரு பெரிய மாதிரியையும் பயன்படுத்தலாம். கட்டுப்பாடுகளுக்குள் செயல்படுவது என்பது ஒரு நிலையான பொறியியல் முறை. AI-யும் இதற்கு விதிவிலக்கல்ல.
நிஜமான மனிதர்களுக்காக உருவாக்குதல்
நான் தற்போது LLM பயன்பாடுகள் மற்றும் மென்பொருள் பொறியியலை ஒரு எளிய இலக்குடன் படிக்கிறேன்: மக்கள் ஒவ்வொரு நாளும் பயன்படுத்தும் கருவிகளை உருவாக்குவது. இது கேட்பதற்குத் தெளிவாகத் தோன்றலாம், ஆனால் ஒரு சிறந்த முன்மாதிரிக்கும் (prototype) தினசரி பயன்பாட்டுத் கருவிக்கும் இடையிலான இடைவெளி மிகப்பெரியது. ஒரு டெமோவில் (demo) நாற்பது வினாடித் தாமதத்தையும், நீளமான பதிலையும் தாங்கிக்கொள்ள முடியும். ஆனால் ஒரு கூட்டத்திற்கு முன்னதாக ஒரு பணியை முடிக்க முயற்சிக்கும் ஒருவரால் அதைத் தாங்க முடியாது.
தினசரி பயன்பாட்டுத் கருவிகளுக்குப் பிழை கையாளுதல் (error handling), மாற்று வழிமுறைகள் (fallbacks) மற்றும் மாதிரி நிச்சயமற்ற நிலையில் இருக்கும்போது தெளிவான பயனர் இடைமுகம் (UI) தேவை. அவை புதிய பணிப்பாய்வுகளை (workflows) திணிப்பதற்குப் பதிலாக, ஏற்கனவே உள்ளவற்றுடன் ஒருங்கிணைக்கப்பட வேண்டும். நான் இப்போது விளிம்பு நிலைச் சூழல்களைப் (edge cases) பற்றிச் சிந்திக்கிறேன்: மாதிரி பதிலளிக்க மறுக்கும்போது, சூழல் (context) நிரம்பி வழியும் போது அல்லது API காலாவதியாகும் (time out) போது என்ன நடக்கும்? AI மென்பொருளை வெளியிடுவது என்பது வெறும் நம்பிக்கையை மட்டும் சார்ந்திருப்பது அல்ல, அந்த கேள்விகளுக்குக் குறியீடுகள் (code) மூலம் பதிலளிப்பதாகும்.
நாம் கற்றுக்கொண்டதை பகிர்ந்து கொள்வோம்
இதே பாதையில் பயணிக்கும் பிற மென்பொருள் உருவாக்குநர்களுடன் இணைய நான் விரும்புகிறேன். இந்தத் துறை மிக வேகமாக நகர்கிறது, மேலும் சிறந்த நடைமுறைகள் (best practices) இன்னும் எழுதப்பட்டு வருகின்றன. யாருக்கும் எல்லா விடைகளும் தெரிவதில்லை. நீங்கள் prompt வடிவமைப்புடன் போராடிக்கொண்டிருந்தாலும், retrieval pipelines-ஐக் கையாண்டாலும் அல்லது பெரிய அளவில் வெளியீடுகளை எவ்வாறு மதிப்பீடு செய்வது என்பதைக் கண்டறிய முயன்றாலும், இந்தப் பிரச்சனைகளை இணைந்து தீர்ப்பது சிறந்தது.
நாம் கற்றுக்கொண்டதை பகிர்ந்து கொள்வோம். மெருகேற்றப்பட்ட மாநாட்டு உரைகளாக அல்லாமல், அந்தச் சிக்கலான இடைப்பகுதியைப் பகிர்ந்து கொள்வோம். முறிந்த பணிப்பாய்வுகள் (broken pipelines), இறுதியாகச் சரியாக வேலை செய்த prompt மாற்றங்கள், வெளியீட்டிற்கு முன் பிழையைக் கண்டறிந்த மதிப்பீட்டுத் தேர்வுகள் என அனைத்தையும் பகிர்வோம். அந்த நுணுக்கமான, நேர்மையானப் பரிமாற்றமே தனிப்பட்ட சோதனைகளை ஒரு பொதுவான அறிவுத் தொகுப்பாக மாற்றுகிறது.
உண்மையான பாடம்
நீங்கள் AI மேம்பாட்டில் காலடி எடுத்து வைப்பவர் என்றால், தேடுவதில் குறைந்த நேரத்தைச் செலவிடுங்கள்