எனது AI முகவர்கள் எங்கள் குழுவின் சாட்டில் (team chat) முடிவுகளைப் பதிவிட்டன. ஒரு மனிதர் அதற்குப் பதிலளித்தார், ஆனால் முதல் செய்தியைப் பார்க்காமலேயே இரண்டாவது முகவர் அதில் குதித்தார். இந்தத் தொடர்ச்சியான நிகழ்வுகள் சூழல் விடுபடுதல் (missed context), ஒரே வேலையைத் திரும்பத் திரும்பச் செய்தல் மற்றும் நேரடித் தவறுகளை உருவாக்கின. தற்போதுள்ள மெமரி சர்வர் (memory server) மற்றும் கண்காணிப்பு அடுக்குடன் (monitoring stack) ஒரு இலகுவான முகவர் இடையேயான தகவல் தொடர்பு நெறிமுறையை (Inter-Agent Communication Protocol - IACP) இணைத்த பிறகு, தேவையற்ற உரையாடல்கள் நின்றன மற்றும் பணிப்பாய்வு (workflow) சீரானது.

இந்தத் பிரச்சனை ஏன் முக்கியமானது

தயாரிப்புச் சூழலில் (Production), AI முகவர்கள் இனி தனிமைப்படுத்தப்பட்ட சோதனைகள் அல்ல; அவை தரவைச் சேகரிக்கவும், குறியீட்டை உருவாக்கவும் அல்லது வரிசைப்படுத்தல்களைத் (deployments) தூண்டவும் பயன்படும் மைக்ரோ-சர்வீஸ்கள் (micro-services) போலச் செயல்படுகின்றன. ஒவ்வொரு முகவரும் மனிதர்களுடன் மட்டுமே பேசும்போது, ஒன்றோடொன்று மேலெழுந்து வரும் பொறுப்புகள் ஒரு மறைமுகமான 'ரேஸ் கண்டிஷனாக' (race condition) மாறுகின்றன. ஒரு சாதாரண Slack செய்தி பாதிப்பற்றதாகத் தோன்றலாம், ஆனால் டெவலப்பர்கள் முரண்பட்ட வெளியீடுகளைத் தீர்க்கப் பல நிமிடங்களை வீணடிக்கிறார்கள், இரண்டு பாட்கள் ஒரே களஞ்சியத்தை (repository) திருத்தும்போது பைப்லைன்கள் முடங்குகின்றன, மேலும் ஆட்டோமேஷனில் மீதமுள்ள நம்பிக்கை குறைகிறது.

விடுபட்ட இணைப்பு: நிகழ்நேரப் பகிரப்பட்ட நிலை

பெரும்பாலான குழுக்கள் முகவர்களை ஒரு ப்ராம்ப்ட்டைப் (prompt) பெற்று முடிவைத் தரும் "பிளாக் பாக்ஸ்கள்" (black boxes) போலக் கருதுகின்றன; அந்த ப்ராம்ப்ட்டிலேயே தேவையான அனைத்து சூழலும் இருப்பதாக அவை assumption செய்கின்றன. ஆனால் உண்மையில், முகவர்கள் ஒரு பகிரப்பட்ட பணிப்பகுதியைப் பகிர்ந்து கொள்கின்றன, அங்கு நிலை (state) தொடர்ந்து மாறிக்கொண்டே இருக்கும்: ஒரு களஞ்சியம் (repository) லாக் செய்யப்பட்டிருக்கலாம், ஒரு சேவை முடங்கியிருக்கலாம் அல்லது முந்தைய பகுப்பாய்வு இப்போதுதான் முடிந்திருக்கலாம். ஒரு பிராட்காஸ்ட் (broadcast) நுட்பம் இல்லாமல், ஒவ்வொரு பாட்டும் பழைய தகவல்களைக் கொண்டே (stale snapshot) செயல்படுகிறது.

தற்போதுள்ள கருவிகளின் அடிப்படையில் IACP-ஐ உருவாக்குதல்

புதிய தளத்தை உருவாக்குவதற்குப் பதிலாக, உரையாடல் வரலாற்றைச் சேமிக்கும் மெமரி சர்வர் மற்றும் முகவர்களின் ஆரோக்கியத்தைக் கண்காணிக்கும் கண்காணிப்புத் தொகுப்பை (monitoring suite) நான் விரிவுபடுத்தினேன். இந்த நெறிமுறை ஐந்து உறுதியான திறன்களைச் சேர்க்கிறது:

  • கட்டமைக்கப்பட்ட அடையாளம் (Structured Identity) – ஒவ்வொரு வெளிச்செல்லும் செய்தியும் claude@greenmac:8f3a2c போன்ற ஒரு தனித்துவமான அடையாளத்தைக் கொண்டுள்ளது. இந்த வடிவம், செய்தியை யார் அனுப்பியது மற்றும் எந்த இன்ஸ்டன்ஸ் (instance) என்பதைக் கேட்பவருக்கு உடனடியாகத் தெரிவிக்கிறது, இதனால் "பாட் X என்று சொல்கிறது" போன்ற தெளிவற்ற நிலைகளைத் தவிர்க்கலாம்.

  • வரலாற்றுத் தகவல் சேர்த்தல் (History Injection) – ஒரு பதில் அளிப்பதற்கு முன், ஒரு பாட் மற்ற முகவர்களின் செய்திகள் உட்பட சமீபத்திய சாட் பகுதியை எடுத்துக்கொண்டு, அதைத் தனது ப்ராம்ப்ட்டின் முன்னால் சேர்க்கிறது. இதனால் சூழல் (context) ஒருபோதும் தொலைந்து போவதில்லை, மேலும் அதன் சக முகவர்கள் ஏற்கனவே என்ன பங்களித்துள்ளார்கள் என்பதைப் புரிந்துகொண்டு செயல்பட மாடலுக்கு முடிகிறது.

  • நிலை மாற்றங்கள் (State Transitions) – முகவர்கள் அடிக்கடி ஹார்ட் பீட்களை (heartbeats) அனுப்புவதை நிறுத்துகின்றன. அதற்குப் பதிலாக, அவற்றின் உள்நிலை மாறும்போது அவை ஒரு நிலை மாற்றத்தைப் பதிவிடுகின்றன—working, blocked, அல்லது idle. இதன் மூலம் பயனர்கள் உடனடியாகச் செயல்பட முடியும், உதாரணமாக, ஒரு முகவர் idle என்று அறிவித்த பின்னரே அடுத்த சார்ந்த பணியைத் தொடங்கலாம்.

  • ஆலோசனைக் குத்தகை (Advisory Leases) – ஒரு முகவருக்கு ஒரு வளத்தின் (resource - ஒரு repo, ஒரு API endpoint, அல்லது ஒரு compute node) மீதான பிரத்யேக அணுகல் தேவைப்படும்போது, அது ஒரு TTL (time-to-live) காலத்துடன் ஒரு குத்திகையை (lease) கோருகிறது. முகவர் செயலிழந்தால், அந்த குத்தகை தானாகவே காலாவதியாகி, வளத்தை மற்றவர்களுக்காக விடுவிக்கிறது; இது இரண்டு பாட்கள் ஒரே வளத்திற்காகப் போராடுவதைத் தடுக்கிறது.

  • இன்பாக்ஸ் முறை (Inbox Mechanism) – ஒரு முகவரின் இன்பாக்ஸில் படிக்கப்படாத செய்திகள் இருந்தால், ஒரு "நிறுத்தக் கருவி" (stop hook) அதன் பணிப்பாய்வை நிறுத்திவிடும். முகவர் தனது தற்போதைய பணியை முடிப்பதற்கு முன் அந்தச் செய்திகளைச் செயலாக்க வேண்டும், இது நிலுவையில் உள்ள ஒருங்கிணைப்பு சமிக்ஞைகள் புறக்கணிக்கப்படாமல் இருப்பதை உறுதி செய்கிறது.

இந்தக் கூறுகள் அனைத்தும் இணைந்து, ஒவ்வொரு பங்கேற்பாளரையும் ஒரே நிலையில் வைத்திருக்கும் ஒரு எளிய, கண்காணிக்கக்கூடிய தகவல் தொடர்பு அடுக்கை உருவாக்குகின்றன.

இதை அலட்சியப்படுத்தும் குழுக்களுக்கான பாதிப்புகள்

ஒரு குழுத் தொடர்ச்சியாகத் தற்காலிக ப்ராம்ப்ட்கள் மற்றும் கைமுறை கண்காணிப்பையே நம்பியிருந்தால், மறைமுகச் செலவுகள் அதிகரிக்கும்:

  • ஒரே வேலையைத் திரும்பத் திரும்பச் செய்தல் (Duplicated effort) – இரண்டு முகவர்கள் ஒரே மாதிரியான அறிக்கைகளை உருவாக்கி, கணினித் திறன் (compute cycles) மற்றும் கிளவுட் செலவுகளை வீணடிக்கலாம்.
  • வளங்களுக்கான போட்டி (Resource contention) – ஒரு கோட் பேஸில் (codebase) ஒரே நேரத்தில் செய்யப்படும் மாற்றங்கள், மனிதத் தலையீடு தேவைப்படும் மெர்ஜ் கான்ஃபிக்ட்ஸ்களை (merge conflicts) உருவாக்கும்.
  • செயல்பாட்டு அபாயம் (Operational risk) – காலாவதியான நிலையை வைத்துச் செயல்படும் ஒரு முகவர், மற்றொரு முகவர் ஏற்கனவே ஒரு மாற்றத்தைத் திரும்பப் பெற முயலும் (rollback) போது, ஒரு புதிய வரிசைப்படுத்தலை (deployment) மேற்கொள்ள முயற்சி செய்யலாம், இது சேவையைச் சீர்குலைக்கும்.

முகவர்கள் தங்களின் அடையாளம், நிலை மற்றும் வளக் கோரிக்கைகளை எவ்வாறு அறிவிக்க வேண்டும் என்பதை முறைப்படுத்துவதன் மூலம், IACP ஒரு கனமான ஆர்கெஸ்ட்ரேஷன் இன்ஜின் (orchestration engine) இல்லாமலேயே இந்த அபாயங்களைக் குறைக்கிறது.

எதிர் கருத்து: கூடுதல் சுமை

வரலாற்றுத் தகவல்களைச் சேர்ப்பதும், குத்திகைகளை (leases) நிர்வகிப்பதும் தாமதத்தையும் (latency) கூடுதல் குறியீட்டுப் பாதைகளையும் உருவாக்கும் என்று விமர்சகர்கள் வாதிடுகின்றனர். ஒரு முகவர் ஒரு குறுகிய பணியை மட்டுமே கையாளும் சூழலில், இந்த நெறிமுறையின் நன்மைகள் மிகக் குறைவாக இருக்கலாம். இருப்பினும், இந்தச் செயலாக்கம் ஏற்கனவே உள்ள மெமரி மற்றும் கண்காணிப்பு சேவைகளையே பயன்படுத்துவதால், கூடுதல் சுமை மிகக் குறைவுதான். முகவர்களுக்கு இடையேயான குழப்பங்களை ஏற்கனவே அனுபவித்து வரும் குழுக்களுக்கு, இந்தத் தீர்வானது தெளிவாகச் சாதகமானது.

அடுத்து கவனிக்க வேண்டியவை

இந்த நெறிமுறை இன்னும் ஒரு முன்மாதிரி (prototype) நிலையிலேயே உள்ளது, ஆனால் அதன் மாடுலர் (modular) தன்மை எந்தவொரு மொழி சாராத (language-agnostic) முகவர் கட்டமைப்போடும் ஒருங்கிணைக்க வழிவகை செய்கிறது. சாத்தியமான அடுத்த கட்டங்கள் பின்வருமாறு:

  • மென்பொருள் உருவாக்குநர்கள் மைய தர்க்கத்தை (core logic) மாற்றாமல் ஐந்து ஹூக்குகளையும் (hooks) சேர்க்கும் வகையில் ஒரு எளிமையான SDK-ஐ வெளியிடுதல்.
  • நிலை மாற்றங்கள் (state transitions) மற்றும் லீஸ் சுழற்சியை (lease churn) காட்சிப்படுத்தும் அளவீடுகளைக் கண்காணிப்புத் தொகுப்பில் (monitoring suite) சேர்ப்பதன் மூலம், குழுக்கள் தடைகளைக் (bottlenecks) கண்டறிய உதவ முடியும்.
  • அதிகப் போக்குவரத்து உள்ள சூழல்களில், மற்றவற்றை விட குறிப்பிட்ட ஏஜெண்ட்களின் லீஸ்களுக்குத் தானாகவே முன்னுரிமை அளிக்கும் கொள்கை அடுக்குகளைப் (policy layers) பரிசோதித்தல்.

இந்த விரிவாக்கங்கள் வரவேற்பைப் பெற்றால், இணையச் சேவைகளுக்கு (web services) HTTP எவ்வாறு ஒரு தரநிலையாக மாறியதோ, அதேபோல IACP மல்டி-ஏஜென்ட் தயாரிப்பு குழாய்களுக்கான (multi-agent production pipelines) ஒரு நடைமுறைத் தரநிலையாக (de-facto standard) மாறக்கூடும்.

முக்கியக் கருத்து: யார் பேசுகிறார்கள், சமீபத்திய உரையாடல் எப்படி இருக்கிறது, ஒரு ஏஜெண்டின் நிலை எப்போது மாறுகிறது, ஒரு வளத்தை (resource) யார் வைத்திருப்பார்கள் மற்றும் நிலுவையில் உள்ள செய்திகள் ஏதேனும் உள்ளனவா போன்ற சில எளிமையான நடைமுறைகள்—AI ஏஜெண்டுகள் ஒன்றையொன்று புரிந்து கொள்ளாமல் பேசுவதைத் தடுத்து, ஒரு சத்தமான அரட்டை அறையை ஒரு நம்பகமான ஒருங்கிணைப்புச் சேனலாக (coordination channel) மாற்றும்.