AI உரையாடலில் விடுபட்ட ஒரு முக்கிய அம்சம்
அனைவரும் AI முகவர்களைப் (AI agents) பற்றிப் பேசிக்கொண்டிருக்கிறார்கள். எந்தவொரு தொழில்நுட்பச் செய்தியையும் பார்த்தால், ஒரு பெரிய மொழி மாதிரி (LLM) விமானங்களை முன்பதிவு செய்வது, குறியீடுகளை எழுதுவது அல்லது ஆதரவு டிக்கெட்டுகளுக்குப் பதிலளிப்பது போன்ற வியக்கத்தக்க விளக்கப்படங்களைக் (demos) காணலாம். இதன் அடிப்படைச் செய்தி தெளிவாகத் தெரிகிறது: ஒரு பயனரை LLM உடன் இணைத்தால், மந்திரம் நிகழும்.
அந்த மாயை ஐந்து நிமிட விளக்கக்காட்சிகளுக்கு (demo) அழகாக வேலை செய்யும். ஆனால் உண்மையான பயனர்கள், உண்மையான தரவுகள் மற்றும் உண்மையான பணம் உள்ளே வரும்போது அது உடைந்துவிடும். பயன்பாட்டுச் சூழலில் (production), உறவு என்பது வெறும் பயனர் ↔ LLM மட்டுமல்ல. அது பயனர் ↔ LLM கொண்ட ஒரு சிக்கலான அமைப்பு. அந்த அமைப்பில் யாரும் பேசாத பகுதி 'harness' (கட்டுப்பாட்டு கட்டமைப்பு) — அதாவது மாதிரியைச் சுற்றி அனைத்தையும் தேர்ந்தெடுக்கும், வழிநடத்தும், பாதுகாக்கும் மற்றும் ஒருங்கிணைக்கும் ஒரு சாரக்கட்டு (scaffolding). அது இல்லாமல், உங்களிடம் ஒரு தயாரிப்பு (product) இல்லை; உங்களிடம் ஒரு முன்மாதிரி (prototype) மட்டுமே உள்ளது.
ஏன் எளிய சுழற்சி தோல்வியடைகிறது
ஒரு டெமோ என்பது கட்டுப்படுத்தப்பட்ட சூழலாகும். கேள்விகள் சுருக்கமானவை, சூழல் (context) வரையறுக்கப்பட்டது, மற்றும் ஆபத்துகள் குறைவு. டெவலப்பர் ஒரு ஒற்றை API அழைப்பைச் செய்கிறார், ஒரு தெளிவான பதிலைப்பெறுகிறார், மற்றும் பார்வையாளர்கள் கைதட்டுகிறார்கள். ஆனால் பயன்பாட்டுச் சூழல் (production) குழப்பமானது. பயனர்கள் தெளிவற்ற தொடர் கேள்விகளைக் கேட்கிறார்கள். மூன்றாம் தரப்பு API-கள் காலாவதியாகின்றன (timeout). நேற்று சரியான JSON-ஐ உருவாக்கிய ஒரு மாதிரி, திடீரென்று markdown-ஐத் துப்பத் தொடங்குகிறது. சூழல் சாளரங்கள் (context windows) நிரம்பிவிடுகின்றன. மிக மோசமான நேரத்தில் விகித வரம்புகள் (rate limits) விதிக்கப்படுகின்றன.
ஒரு நேரடி prompt-response சுழற்சிக்கு (prompt-response loop) இவற்றிற்கு எந்தப் பதிலும் இல்லை. எந்த மாதிரி மாறுபாடு (model variant) ஒரு குறிப்பிட்ட பணியைக் கையாள வேண்டும் என்று அதற்குத் தெரியாது. மூன்று சுற்றுகளுக்கு முன்பு என்ன நடந்தது என்பதை அது நினைவில் கொள்வதில்லை. தோல்வியடைந்த அழைப்பை மீண்டும் முயற்சிக்கவோ, செலவுகள் அதிகரிக்கும் போது கோரிக்கைகளைக் குறைக்கவோ (throttle), அல்லது உங்கள் தரவுத்தளத்திற்குச் செல்லும் முன் வெளியீட்டைச் சுத்திகரிக்கவோ (sanitize) அதனால் முடியாது. இவை விளிம்பு நிலைச் சிக்கல்கள் (edge cases) அல்ல. இவை நிஜ உலக மென்பொருளின் வரையறுக்கும் பண்புகள். இவற்றைத் கையாள்வதே harness-ன் வேலை.
Harness உண்மையில் என்ன செய்கிறது
ஒரு மொழி மாதிரியை ஒரு புத்திசாலித்தனமான உரை உருவாக்கிடலிலிருந்து (text generator) ஒரு நம்பகமான சேவை அங்கமாக (service component) மாற்றும் பொறியியல் அடுக்காக (engineering layer) harness-ஐக் கருதவும். அதன் பொறுப்புகள் மிகவும் உறுதியானவை மற்றும் கவர்ச்சியற்றவை, அதனால்தான் அவை பெரும்பாலும் கவனிக்கப்படுவதில்லை.
தற்போதைய பணிக்குத் தேவையான மாதிரியைத் தேர்ந்தெடுத்தல். ஒவ்வொரு தொடர்பிற்கும் மிகவும் சக்திவாய்ந்த அடிப்படை மாதிரி (foundation model) தேவையில்லை. சில வேலைகளுக்குத் தூய பகுத்தறியும் திறன் (reasoning power) தேவை; மற்றவை வெறும் வேகம் மற்றும் குறைந்த செலவை மட்டுமே எதிர்பார்க்கின்றன. நன்கு கட்டமைக்கப்பட்ட ஒரு harness கோரிக்கைகளைத் புத்திசாலித்தனமாக வழிநடத்துகிறது. உதாரணமாக, ஒரு வாடிக்கையாளர் சேவை முகவர், வரும் செய்தியின் நோக்கத்தை வகைப்படுத்த (உதாரணமாக, ரீஃபண்ட் கோரிக்கை அல்லது ஷிப்பிங் கேள்வி) ஒரு வேகமான, மலிவான மாதிரியைப் பயன்படுத்தலாம். அந்த நோக்கம் ஒரு சிக்கலான கொள்கை தொடர்பான விவாதத்தைக் குறித்தால், harness அந்தப் பணியை ஒரு கனமான பகுத்தறியும் மாதிரிக்கு (heavier reasoning model) மாற்றுகிறது. பயனர் வெறும் கண்காணிப்பு இணைப்பை (tracking link) மட்டும் கேட்டால், இலகுரக மாதிரி உடனடியாகப் பதிலளிக்கும், இதனால் உங்கள் செலவு விகிதம் (burn rate) கட்டுக்குள் இருக்கும்.
தரவு ஓட்டத்தைக் கையாளுதல். உண்மையான பயன்பாடுகள் ஒரு வெற்றிடத்தில் இயங்குவதில்லை. ஒரு AI முகவர் பெரும்பாலும் ஒரு வெக்டர் ஸ்டோரில் (vector store) இருந்து ஆவணங்களைப் பெற வேண்டும், ஒரு CRM-ஐக் கேட்க வேண்டும், சமீபத்திய பயனர் செயல்பாட்டைப் படிக்க வேண்டும் மற்றும் இவை அனைத்தையும் ஒரு ஒருங்கிணைந்த பதிலாக மாற்ற வேண்டும். Harness அந்தத் தரவு உள்ளீட்டை (ingestion) நிர்வகிக்கிறது. அது சரியான சூழல் துண்டுகளைப் (context chunks) பெறுகிறது, அவை பொருத்தத்தை இழக்காமல் டோக்கன் வரம்புகளுக்குள் (token limits) அடங்குவதை உறுதி செய்கிறது, அவற்றை மாதிரிக்காக வடிவமைக்கிறது மற்றும்
இது பல தயாரிப்புக் குழுக்களைக் குழப்பும் ஒரு நிகழ்வை விளக்குகிறது. இரண்டு நிறுவனங்கள் ஒரே மாதிரியான அடிப்படை மாதிரியைக் (foundation model) கொண்டு தொடங்கலாம்—ஒரே எடைகள் (weights), ஒரே சூழல் சாளரம் (context window), ஒரே பயிற்சி முடிவுத் தேதி (training cutoff)—இருப்பினும் அவை வழங்கும் அனுபவங்கள் முற்றிலும் வேறாக இருக்கலாம். ஒன்று பலவீனமாகவும், மெதுவாகவும், விசித்திரமான மறதித் தன்மையுடனும் இருக்கும். மற்றொன்று துரிதமாகவும், நிலையானதாகவும், நம்பகத்தன்மையுடனும் இருக்கும்.
வித்தியாசம் எப்போதும் மாதிரியில் இருப்பதில்லை. அது அந்த மாதிரியைச் சுற்றி அமைக்கப்பட்ட அமைப்பில்தான் (system) உள்ளது. ஒரு குழு மாதிரியை முழுத் தயாரிப்பாகக் கருதுகிறது. மற்றொரு குழு அதை ஒரு ஒழுங்குபடுத்தப்பட்ட கட்டமைப்பிற்குள் (architecture) உள்ள ஒரு அங்கமாக மட்டுமே கருதுகிறது. அந்த ஒழுங்குமுறை இந்த 'harness' எனப்படும் கட்டுப்பாட்டு அமைப்பில்தான் உள்ளது.
ப்ராம்ப்ட்களிலிருந்து கட்டமைப்பிற்கு மாறுதல்
ஆரம்பகால AI வளர்ச்சியில், ப்ராம்ப்ட் இன்ஜினியரிங் (prompt engineering) முக்கியப் பங்கு வகித்தது. சொற்களை மாற்றுவது, உதாரணங்களைச் சேர்ப்பது மற்றும் பாத்திரங்களை நிர்ணயிக்கும் அறிவுறுத்தல்களை (role-play instructions) வழங்குவது ஆகியவை வெளியீட்டின் தரத்தை வியக்கத்தக்க வகையில் மேம்படுத்தின. அந்தத் திறன் இப்போதும் முக்கியமானதுதான், ஆனால் ஒரு போட்டித் தடையாக (competitive moat) அது குறைந்து வரும் பலன்களையே (diminishing returns) தருகிறது. ஒரு தவறான மறுமுயற்சி கொள்கை (retry policy) அல்லது பொதுத் தரவுப் பாதையில் (data pipeline) தனிப்பட்ட தகவல்கள் கசியும் சிக்கலை வெறும் ப்ராம்ப்ட்கள் மூலம் சரிசெய்ய முடியாது.
இப்போது நிகழ்ந்து வரும் உண்மையான மாற்றம் மென்பொருள் கட்டமைப்பை (software architecture) நோக்கிய நகர்வுதான். பொறியாளர்கள் ஸ்டேட் மெஷின்களை (state machines) வடிவமைக்கிறார்கள், மாதிரி அடுக்குக்கும் (model layer) பயன்பாட்டு தர்க்கத்திற்கும் (application logic) இடையே கடுமையான இடைமுகங்களை (interfaces) வரையறுக்கிறார்கள், மேலும் நிச்சயமற்ற தன்மையை (non-determinism) ஒரு முக்கியமான பொறியியல் சவாலாகக் கருதுகிறார்கள். அவர்கள் விநியோகிக்கப்பட்ட அமைப்புகள் (distributed systems) குறித்த கேள்விகளைக் கேட்கிறார்கள்: பல சுற்றுகள் கொண்ட உரையாடலில் நிலை (state) எவ்வாறு தொடர்கிறது? ஒரு கருவி (tool) கிடைக்கவில்லை என்றால் என்ன நடக்கும்? அதன் முக்கிய அங்கமே நிகழ்தகவு (probabilistic) சார்ந்ததாக இருக்கும் ஒரு அமைப்பை எவ்வாறு சோதனை செய்வது? இவைதான் ஒரு சாதாரணப் பொருளுக்கும் ஒரு பயனுள்ள கருவிக்கும் இடையிலான வித்தியாசத்தைத் தீர்மானிக்கின்றன.
தயாரிப்பிற்காக உருவாக்குதல்: கவனிப்புத்திறன் மற்றும் ஒருங்கிணைப்பு
நீங்கள் ஒரு தயாரிப்பைச் சந்தைக்குக் கொண்டுவரத் தீவிரமாக இருந்தால், அந்தத் கட்டுப்பாட்டு அமைப்பு (harness) இரண்டு முக்கியத் தகுதிகளைக் கோருகிறது: கவனிப்புத்திறன் (observability) மற்றும் ஒருங்கிணைப்பு (orchestration).
கவனிப்புத்திறன் (Observability) என்பது மாதிரி என்ன பெற்றது, அது என்ன பதிலளித்தது மற்றும் ஒவ்வொரு படிநிலையும் எவ்வளவு நேரம் எடுத்தது என்பதை உங்களால் பார்க்க முடியும் என்பதைக் குறிக்கிறது. பதினான்கு கருவி அழைப்புகள் (tool calls) வழியாக ஒரு ஏஜென்ட்டின் (agent) முடிவெடுக்கும் சுழற்சியைக் கண்காணிப்பதையும், அது எங்கே சுழலத் தொடங்கியது அல்லது அதன் இலக்கிலிருந்து எங்கே விலகியது என்பதைக் கண்டறிவதையும் இது குறிக்கிறது. அந்தத் தெளிவு இல்லையென்றால், ஒரு AI அமைப்பைச் சரிசெய்வது என்பது இருட்டில் ஒரு கார் இயந்திரத்தைச் சரிசெய்வதைப் போன்றது.
ஒருங்கிணைப்பு (Orchestration) என்பது உங்கள் வணிகத் தர்க்கம் (business logic) உங்கள் மாதிரித் தொடர்பு அடுக்கிலிருந்து (model interaction layer) தனித்து இருப்பதை உறுதி செய்வதாகும். இது உங்கள் குறியீட்டை (code) எவ்வாறு பதிப்புப்படுத்துகிறீர்களோ (versioning), அதேபோல ப்ராம்ப்ட்களையும் பதிப்புப்படுத்துவதைக் குறிக்கிறது; இதனால் ஒரு புதிய வெளியீடு அமைப்பின் செயல்பாட்டைத் தெரியாமல் மாற்றாது. தோல்வி முறைகளை (failure modes) வேண்டுமென்றே சோதிப்பதையும் இது குறிக்கிறது—ஒரு API கோரிக்கையின் நடுவே அதை நிறுத்துவது, தவறான கருவி முடிவுகளை வழங்குவது, சூழல் சாளரம் (context window) நிரம்புவதைப் போன்றவற்றைச் செய்து, அந்தத் கட்டுப்பாட்டு அமைப்பு (harness) அமைப்பைத் தாங்கிப் பிடிக்கிறதா என்று பார்ப்பது. கட்டமைப்புகள் (frameworks) வந்து போகலாம், நீங்கள் ஒரு தயார் நிலையில் உள்ள ஒருங்கிணைப்பு நூலகத்தைப் (orchestration library) பயன்படுத்தினாலும் அல்லது நீங்களே ஒன்றை உருவாக்கினாலும், அந்தப் பெயரைக் காட்டிலும் ஒழுங்குமுறைதான் முக்கியமானது.
உண்மையான பாடம்
அடிப்படை மாதிரிகள் தொடர்ந்து மேம்படும். அவை வேகமாகவும், மலிவாகவும், அதிகத் திறனுடனும் மாறும். ஆனால் ஒரு சக்திவாய்ந்த இயந்திரம் மட்டும் ஒரு உடைந்த கட்டமைப்பை (chassis) சரிசெய்யாது. அடுத்த சில ஆண்டுகளில் வெற்றி பெறும் குழுக்கள் மிகச் சிறந்த மாதிரிகளை அணுகுபவர்கள் அல்ல. மாறாக, நம்பகமான, கவனிப்புத்திறன் கொண்ட மற்றும் நன்கு ஒருங்கிணைக்கப்பட்ட ஒரு கட்டுப்பாட்டு அமைப்பை (harness) உருவாக்கியவர்களே வெற்றி பெறுவார்கள். அவர்கள் தங்கள் பயன்பாடுகளை மீண்டும் எழுதாமல் மாதிரிகளை மாற்றிக்கொள்ள முடியும். ஒவ்வொரு டோக்கனையும் (token) அந்தத் கட்டுப்பாட்டு அமைப்பு நிர்வகிப்பதால் அவர்களால் செலவுகளைக் கட்டுப்படுத்த முடியும். அவர்களின் அமைப்புகள் தோல்வியடையும் போது கூட முறையாகச் செயல்படுவதால் (fail gracefully), அவர்கள் நிம்மதியாக உறங்க முடியும்.
மாதிரியை மட்டும் தனித்துப் பார்த்து அதிலேயே மூழ்கிவிடாதீர்கள். அதை இயக்கும் அமைப்பின் (system) மீது கவனம் செலுத்துங்கள். புத்திசாலித்தனமான மாதிரிகளைச் சுற்றி புத்திசாலித்தனமான அமைப்புகளை உருவாக்கும் பொறியாளர்களுக்கே எதிர்காலம் சொந்தமானது.
This article draws on ideas originally discussed by Abdulaziz Zos in "Beyond The Model".
For more discussions on AI engineering and system design, check out the GyaanSetu learning community.