Google-ன் AI architecture guide மற்றும் Anthropic-ன் engineering blog ஆகியவை "ReAct" loop-ஐத் தன்னாட்சி முகவர்களுக்கான (autonomous agents) ஒரு முறையாக விவரிக்கின்றன. ஒரு மாடலிடம் கட்டுப்பாட்டை ஒப்படைப்பதற்கு முன், டெவலப்பர்கள் செலவு (cost), தாமதம் (latency) மற்றும் பிழை அபாயம் (error risk) ஆகியவற்றைக் கருத்தில் கொள்ள வேண்டும் என்று அவை குறிப்பிடுகின்றன. தவறான முகவரைத் தேர்ந்தெடுப்பது கிளவுட் பட்ஜெட்களை (cloud budgets) கரைப்பதோடு, உற்பத்தி அமைப்புகளில் (production systems) கண்டறிவதற்கு கடினமான தோல்விகளையும் ஏற்படுத்தும் என்பதால் இந்த அறிவுரை முக்கியமானது.
நடைமுறையில் ReAct loop எப்படி இருக்கும்
இந்த லூப் மூன்று நிலைகளைக் கொண்டது:
- சிந்தனை (Thought) – மாடல் தற்போதைய பணி குறித்துச் சிந்தித்து அடுத்த கட்டத்தைத் தேர்ந்தெடுக்கிறது.
- செயல் (Action) – இது ஒரு வெளிப்புறக் கருவியையோ (உதாரணமாக, ஒரு code-search API) அழைக்கிறது அல்லது இறுதிப் பதிலைத் தருகிறது.
- கவனிப்பு (Observation) – இது கருவியின் வெளியீட்டைப் படித்து, அதன் முடிவை நினைவகத்தில் சேமித்து, அடுத்த சிந்தனைக்கு (Thought) உள்ளீடாக வழங்குகிறது.
Anthropic இந்த முழு கட்டமைப்பையும் "autonomous agent" என்று அழைக்கிறது; Google அதன் முக்கிய சுழற்சியை "ReAct" என்று பெயரிடுகிறது. இந்த வேறுபாடு நுட்பமானது ஆனால் முக்கியமானது: ஒரு பாரம்பரிய பணிப்பாய்வில் (traditional workflow) டெவலப்பரின் குறியீடு (code) வரிசையைத் தீர்மானிக்கிறது, ஆனால் ஒரு முகவரில் (agent) மாடல் அதைத் தீர்மானிக்கிறது.
எப்போது மாடலைச் செயல்பாட்டை வழிநடத்த அனுமதிக்க வேண்டும்
திறந்தநிலைத் சிக்கல்கள் (Open-ended problems) ReAct பாணி முகவர்களுக்கு மிகவும் பொருத்தமானவை. ஒவ்வொரு சாத்தியமான கிளையையும் (branch) முன்கூட்டியே பட்டியலிட முடியாவிட்டால், ஒரு முகவர் அதைத் துரிதமாக ஆராய முடியும். பொதுவான பயன்பாட்டுத் தேவைகள்:
- Code-fix bots – இவை ஒரு களஞ்சியத்தை (repository) ஸ்கேன் செய்து, தோல்வியடையும் சோதனையைக் கண்டறிந்து, பில்ட் (build) வெற்றி பெறும் வரை மீண்டும் மீண்டும் திருத்தங்களை (patches)ச் செய்கின்றன.
- ரோபோடிக் நேவிகேஷன் (Robotic navigation) – இதில் ஒரு வாகனம் திட்டமிடப்படாத தடைகளுக்கு ஏற்பச் செயல்பட வேண்டும் மற்றும் பாதைகளை உடனுக்குடன் மாற்றியமைக்க வேண்டும்.
இத்தகைய சூழல்களில், எத்தனை முறை சுழற்சி (iterations) நடக்கும் என்பது தெரியாது, மேலும் ஒரு பாதையை முன்கூட்டியே குறியீடாக (hard-coding) அமைப்பது பலவீனமானதாக இருக்கும்.
பணிப்பாய்வு (Workflow) எப்போது சிறந்தது
படிநிலைகள் கணிக்கக்கூடியதாக இருந்தால், ஒரு வழக்கமான பைப்லைன் (conventional pipeline) சிறந்ததாக இருக்கும். நிலையான வரிசைகள்:
- குறைந்த செலவு (Cheaper) – டஜன் கணக்கான முறை இயங்கக்கூடிய ஒரு மல்டி-டர்ன் லூப்பை விட, ஒரு ஒற்றை API அழைப்பு செலவு குறைவானது.
- வேகமானது (Faster) – ஒவ்வொரு சுழற்சியிலும் தாமதம் (latency) அதிகரிப்பதால், ஒரு முறை மட்டும் கேட்கும் வினவல் (one-shot query) விரைவாக முடிவடையும்.
- தணிக்கை செய்ய எளிதானது (Easier to audit) – தீர்மானிக்கப்பட்ட குறியீடு பாதைகள் (deterministic code paths) சோதனை மற்றும் இணக்கத்தை (compliance) எளிதாக்குகின்றன.
மொத்தத் தரவு சரிபார்ப்பு (bulk data validation) அல்லது வழக்கமான அறிக்கை உருவாக்கம் போன்ற அதிக அதிர்வெண் கொண்ட எளிய பணிகளைத் தன்னாட்சி முகவருக்குப் பதிலாக ஒரு பணிப்பாய்வில் (workflow) செய்வது சிறந்தது.
தன்னாட்சியின் மறைமுகச் செலவுகள்
ஒரு சிக்கல் பொருத்தமானதாகத் தோன்றினாலும் கூட, டெவலப்பர்கள் மூன்று நடைமுறைப் பின்னடைவுகளுக்காகத் திட்டமிட வேண்டும்:
- அதிக கணக்கீட்டுச் செலவு (High compute expense) – ஒவ்வொரு Thought-Action-Observation சுழற்சியும் மற்றொரு மாடல் இன்ஃபரன்ஸை (model inference) பயன்படுத்துவதால், கிளவுட் செலவு பலமடங்கு அதிகரிக்கிறது.
- கூடுதல் தாமதம் (Added latency) – மொத்தப் பதிலளிக்கும் நேரம் என்பது மாடல் மற்றும் வெளிப்புறக் கருவிகளுடனான அனைத்துத் தொடர்புகளின் (round-trips) கூட்டுத்தொகையாகும்.
- பிழைப் பெருக்கம் (Error amplification) – தவறாகப் புரிந்துகொள்ளப்பட்ட ஒரு கவனிப்பு (observation), தொடர்ச்சியான பிழைகளை உருவாக்கி, முற்றிலும் தவறான இறுதிப் பதிலைத் தரக்கூடும்.
முகவர்கள் வழங்கும் கோட்பாட்டு ரீதியான நெகிழ்வுத்தன்மையை (theoretical flexibility) இந்த காரணிகள் குறைக்கக்கூடும்.
டெவலப்பர்களுக்கான பாதுகாப்பு வழிகாட்டி (Safety playbook)
தன்னாட்சி முகவர்கள் கட்டுப்பாட்டை மீறிச் செல்வதைத் தடுக்க, மூன்று பாதுகாப்பு நடவடிக்கைகள் பரிந்துரைக்கப்படுகின்றன:
- சுழற்சிகளுக்கு வரம்பு (Cap iterations) – முகவர் முடிவில்லாமல் இயங்காமல் இருக்க, அதிகபட்ச சுழற்சிகளின் எண்ணிக்கையை வரையறுக்கவும்.
- வலிமையான கருவி இடைமுகங்களில் (tool interfaces) முதலீடு செய்யுங்கள் – முழு அமைப்பின் நம்பகத்தன்மையும், புத்திசாலித்தனமான ப்ராம்ப்டிங் தந்திரங்களை விட, தெளிவான மற்றும் நன்கு வரையறுக்கப்பட்ட API-களைச் சார்ந்தே இருக்கும்.
- तैनातीக்கு முன் சாண்ட்பாக்ஸ் (Sandbox before deployment) – கடுமையான கட்டுப்பாடுகளுடன் கூடிய தனிமைப்படுத்தப்பட்ட சூழலில் முகவர்களைச் சோதித்து, எதிர்பாராத கருவி அழைப்புகள் அல்லது கட்டுப்பாடற்ற சுழற்சிகளுக்குக் கண்காணிக்கவும்.
இந்த வழிகாட்டியைப் பின்பற்றுவதன் மூலம், பெருகிவரும் பிழைகளை முன்கூட்டியே கண்டறிவதும், செலவு வரம்புகளைக் கட்டுப்படுத்துவதும் எளிதாகும்.
நடைமுறையில் உள்ள சமநிலை (The trade-off)
ReAct பாணி முகவரா அல்லது ஸ்கிரிப்ட் செய்யப்பட்ட பணிப்பாய்வா (scripted workflow) என்பதைத் தேர்ந்தெடுப்பது, சிக்கல் திறந்தநிலைத் தன்மையுடையதா அல்லது கணிக்கக்கூடியதா என்பதையும், செலவு, தாமதம் மற்றும் பிழை அபாயம் ஆகியவற்றையும் பொறுத்தது.
சுருக்கமாகச் சொன்னால் (Bottom line): நீங்கள் தகவமைப்புத் தர்க்கம் (adaptive reasoning) தேவைப்படும்போது மற்றும் ஒவ்வொரு செயலையும் முன்கூட்டியே வரையறுக்க முடியாதபோது ReAct முகவர்கள் சிறப்பாகச் செயல்படும், ஆனால் அவை அதிக செலவு, மெதுவான பதில்கள் மற்றும் நுணுக்கமான பிழைகள் ஏற்பட அதிக வாய்ப்பைக் கொண்டுவருகின்றன. தெளிவான நிறுத்த விதிகள், வலிமையான கருவி ஒப்பந்தங்கள் மற்றும் சாண்ட்பாக்ஸ் சோதனை போன்ற ஒரு ஒழுக்கமான அணுகுமுறை, அந்த ஆற்றலை பட்ஜெட் கசிவாக மாற்றாமல், ஒரு கட்டுப்படுத்தப்பட்ட சொத்தாக மாற்றும்.