Google இப்போது தனது “Swarm” பல முகவர் முறையை (multi-agent pattern) AI-ஆல் இயக்கப்படும் அமைப்புகளுக்கான மிகவும் சக்திவாய்ந்த—மற்றும் மிகவும் செலவுமிக்க—வடிவமைப்பு என்று அழைக்கிறது. தயாரிப்பு-வடிவமைப்பு உதவியாளர்கள் அல்லது ஆராய்ச்சி உதவியாளர்களை உருவாக்கும் டெவலப்பர்கள், தன்னாட்சி முகவர்களுக்கிடையிலான செழுமையான, சுய-கட்டுப்பாட்டு விவாதங்களின் வாக்குறுதிக்கும், அதிக செலவு மற்றும் தாமதத்திற்கும் (latency) இடையே சமநிலையைத் தீர்மானிக்க வேண்டும்.
Swarm முறை உண்மையில் என்ன செய்கிறது
ஒரு Swarm-இல், ஒவ்வொரு சிறப்பு முகவரும் மற்ற ஒவ்வொரு முகவருடனும் நேரடியாகப் பேசுகிறது. இந்த முறை, ஒரு தனி மேற்பார்வை ஒருங்கிணைப்பாளருக்குப் பதிலாக, பணிகளை விமர்சிக்கவும், செம்மைப்படுத்தவும் மற்றும் ஒப்படைக்கவும் கூடிய சமமான முகவர்களின் (peers) ஒரு தட்டையான வலையமைப்பை (flat network) மாற்றுகிறது. ஒரு லேசான விநியோகிப்பவர் (lightweight dispatcher) செயல்முறையைத் தொடங்குகிறார், ஆனால் அவர் உரையாடலைத் தீர்மானிக்கவில்லை; ஒவ்வொரு முகவரும் ஒரு முன்மொழிவில் தொடர்ந்து பணியாற்ற வேண்டுமா அல்லது அதை ஒரு நம்பகமான சக முகவரிடம் ஒப்படைக்க வேண்டுமா என்பதைத் தாங்களே தீர்மானிக்கிறார்கள். இதன் விளைவாக, ஒரு தனி மேலாளர் கவனிக்கத் தவறும் பல்வேறு பார்வைகளை வெளிப்படுத்தும் ஒரு 'அனைவருக்கும் இடையிலான' (all-to-all) உரையாடல் உருவாகிறது.
இது பாரம்பரிய ஒருங்கிணைப்பாளியிலிருந்து எவ்வாறு வேறுபடுகிறது
ஒரு ஒருங்கிணைப்பாளர் படிநிலையின் (hierarchy) உச்சியில் அமர்ந்து, பணிகளை ஒதுக்கி முடிவுகளைச் சேகரிக்கிறார். Swarm-இல் தலைவன் யாரும் இல்லை. முகவர்கள் அடுத்த கட்டத்தைப் பற்றிப் பேச்சுவார்த்தை நடத்துகிறார்கள், மேலும் மையக் கட்டளைக்காகக் காத்திருக்காமல் அவர்களில் எவரும் ஒரு துணைப் பணியை (sub-task) எடுத்துக் கொள்ளலாம். கூகுள் இதை “மிகவும் சக்திவாய்ந்த” அம்சம் என்று அழைக்கிறது, ஏனெனில் இந்த அமைப்பு ஒரு சிக்கலை இணையாக (in parallel) ஆராய்கிறது, மேலும் ஒருவருக்கொருவர் நுண்ணறிவுகளைத் தொடர்ந்து கட்டமைக்கிறது.
Swarm எப்போது பொருத்தமானது
சவாலான சமநிலைகளை (trade-offs) அளவிட கடினமாக இருக்கும் தெளிவற்ற, பல்துறை சார்ந்த சிக்கல்களுக்கு இந்த முறை சிறப்பாகச் செயல்படுகிறது. பயனர் அனுபவம் (user experience), பொறியியல் சாத்தியக்கூறுகள் மற்றும் நிதித் தடைகளைச் சமநிலைப்படுத்த வேண்டிய ஒரு தயாரிப்பு-வடிவமைப்பு பணிப்பாய்வை (workflow) கற்பனை செய்து பாருங்கள். ஒரு ஆராய்ச்சியாளர், ஒரு பொறியாளர் மற்றும் ஒரு நிதி ஆய்வாளர்—ஒவ்வொருவரும் ஒரு முகவராகச் செயல்படும்போது—ஒரு அம்சத்தின் நன்மைகளைப் பற்றி விவாதிக்கலாம், மாற்றுகளை முன்மொழியலாம் மற்றும் ஒரு ஒற்றை விவரக்குறிப்பில் (specification) இணையலாம்; இதை ஒரு தனி ஒருங்கிணைப்பாளர் ஒருங்கிணைப்பதில் சிரமப்படலாம்.
எப்போது இதைத் தவிர்க்க வேண்டும்
தெளிவான வழிமுறையைப் பின்பற்றும் நன்கு கட்டமைக்கப்பட்ட பணிகளுக்கு Swarm-பாணி விவாதம் தேவையில்லை. ஒரு திட்டத்திற்கு குறைந்த செயல்பாட்டுச் செலவு, விரைவான முடிவுகள் அல்லது ஒரு தீர்மானிக்கப்பட்ட நிறுத்தப் புள்ளி தேவைப்பட்டால், இந்த முறையின் கூடுதல் சுமை அதன் நன்மைகளை விட வேகமாகத் தாக்கும். 'அனைவருக்கும் இடையிலான' உரையாடல் மாடல் அழைப்புகளை (model calls) பலமடங்கு அதிகரிக்கிறது, இது சாதாரண வேலைப்பளுவைச் செலவு மிகுந்த, அதிக தாமதமுள்ள செயல்பாடுகளாக மாற்றுகிறது. நேர வரம்பு, அதிகபட்ச உரையாடல் சுற்றுகள் அல்லது ஒருமித்த கருத்துத் threshold போன்ற தெளிவான வெளியேறும் விதி (exit rule) இல்லையென்றால், இந்த உரையாடல் முடிவில்லாமல் நீடிக்கக்கூடும்.
மறைமுகமான செலவுகள் மற்றும் சிக்கல்கள்
- செலவு மற்றும் தாமதம் (Latency) – முகவர்களுக்கிடையிலான ஒவ்வொரு பரிமாற்றமும் ஒரு தனி மாடல் அழைப்பைத் (model invocation) தூண்டுகிறது.
- ஒன்றிணைவதற்கான உத்தரவாதம் இல்லை – முகவர்கள் ஒரே வாதங்களை மீண்டும் மீண்டும் முன்வைத்து, ஒரு முடிவை எட்டாமல் இருக்கலாம். முட்டுக்கட்டைகளை உடைக்க இந்த அமைப்பில் ஒரு உள்ளமைக்கப்பட்ட நடுவர் (arbiter) இல்லை.
- செயல்படுத்தும் சிக்கல் – நம்பிக்கை, பணி ஒப்படைப்பு மற்றும் முடிவு நிலைமைகளை (termination conditions) நிர்வகிக்கும் தர்க்கத்தை உருவாக்குவது எளிதல்ல. டெவலப்பர்கள் அடிப்படை AI மாடல்களின் மேல் சிக்கலான ஒருங்கிணைப்பு குறியீட்டை (orchestration code) உருவாக்க வேண்டும்.
டெவலப்பர்களுக்கான மூன்று நடைமுறை விதிகள்
- முன்கூட்டியே ஒரு வெளியேறும் நிபந்தனையை வரையறுக்கவும். அது நேர வரம்பாக இருந்தாலும் சரி, அதிகபட்ச உரையாடல் சுற்றுகளாக இருந்தாலும் சரி, அல்லது தேவையான ஒருமித்த கருத்து மட்டமாக இருந்தாலும் சரி, இந்த அமைப்புக்கு ஒரு தெளிவான நிறுத்த சிக்னல் தேவை.
- அதிகப்படியான வளப் பயன்பாட்டிற்காகத் தயாராக இருக்கவும். நீங்கள் இதற்கு முன் பயன்படுத்திய எந்த ஒருங்கிணைப்பாளர் அடிப்படையிலான வடிவமைப்பை விடவும், Swarm அதிக கணக்கீட்டுத் திறனை (compute) பயன்படுத்தும் என்று எதிர்பார்க்கவும்.
- ஒரு ஒருங்கிணைப்பாளியுடன் தொடங்கவும். ஒரு தனி, நன்கு நிரலாக்கம் செய்யப்பட்ட முகவரால் வேலையைச் செய்ய முடியும் என்றால், Swarm-இன் கூடுதல் சிக்கலைச் சேர்ப்பதற்குப் பெரிய காரணமில்லை.
பார்வைகளின் முரண்பாடு
மறைந்துள்ள நுண்ணறிவுகளை வெளிக்கொணரவும், சக முகவர்களின் விமர்சனத்தின் மூலம் சுயதிருத்தம் செய்யவும் Swarm-இன் திறன், ஒரு தனி ஒருங்கிணைப்பாளர் தவறவிடக்கூடிய தீர்வுகளை உருவாக்க முடியும் என்று ஆதரவாளர்கள் கூறுகிறார்கள். ஆனால், அதிக விலை மற்றும் முடிவில்லாத விவாதச் சுழற்சிகள் ஏற்படும் அபாயம் ஆகியவற்றைக் விமர்சகர்கள் சுட்டிக்காட்டுகின்றனர். இந்த முறை ஒரு உலகளாவிய மேம்பாடு அல்ல; இது வேகம் மற்றும் செலவை விட ஆழமான பகுத்தறிவு தேவைப்படும் ஒரு குறிப்பிட்ட வகை சிக்கல்களுக்கான ஒரு சிறப்பு கருவியாகும்.
அடுத்து எதைக் கவனிக்க வேண்டும்
எளிமையான முறைகளை மதிப்பீடு செய்த பிறகு, Swarm-ஐ ஒரு இறுதித் தெரிவாக மட்டுமே கருத வேண்டும் என்று கூகுளின் ஆவணங்கள் இப்போது பரிந்துரைக்கின்றன. அதுவரை, டெவலப்பர்கள் ஒரு ஒருங்கிணைப்பாளர் மூலம் முன்மாதிரியை (prototype) உருவாக்கி, செயல்திறனை அளவிட வேண்டும், மேலும் சிக்கலின் தன்மை உண்மையிலேயே விவாதிக்கும் முகவர்களின் கூட்டத்தைக் கோரும்போது மட்டுமே Swarm முறைக்கு மாற வேண்டும்.
முழுமையான தொழில்நுட்ப விளக்கத்திற்கு, முகவர் சார்ந்த AI அமைப்பு வடிவமைப்பிற்கான (agentic AI system design) கூகுளின் அதிகாரப்பூர்வ வழிகாட்டியைப் பார்க்கவும்.