ஒரு AI ஏஜென்ட்டை (AI agent) உருவாக்குவது என்பது ஒரு சாட்போட்டிற்கு (chatbot) ப்ராம்ப்ட் (prompt) கொடுப்பதற்குச் சமம் என்று நான் முன்பு நினைத்தேன். நீங்கள் கேள்வியை சரியாகக் கேட்டால், மாடல் பதிலளிக்கும், அவ்வளவுதான் என்று நினைப்பீர்கள். ஆனால் நான் சில பயன்பாடுகளை (applications) வெளியிட்ட பிறகு, நிஜ நிலை மிகவும் கடினமாக இருந்தது. ஒரு LLM என்பது ஒரு ஏஜென்ட் அல்ல. ஒரு LLM அடுத்த டோக்கனை (token) மட்டுமே கணிக்கிறது. அந்த லூப் (loop) தான் ஒரு ஏஜென்ட்டை உருவாக்குகிறது.

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

ஏஜென்சி (Agency) உருவாகும் சுழற்சி

இந்த லூப் என்பது வெறும் தத்துவார்த்தக் கோட்பாடு அல்ல. இது உங்கள் சார்பாகச் செயல்படும் எந்தவொரு அமைப்பின் செயல்பாட்டுத் துடிப்பு (operational heartbeat). நடைமுறையில் இது எப்படி இருக்கும் என்பதை இங்கே காணலாம்:

  • சிந்தித்தல் (Think): மாடல் இலக்கைப் பற்றிச் சிந்தித்து அதற்கு என்ன தேவை என்பதைத் தீர்மானிக்கிறது. ஒரு பயனர், "நான் நாளை போர்ட்லேண்டிற்கு (Portland) குடை எடுத்துச் செல்ல வேண்டுமா?" என்று கேட்கிறார் எனில், அதற்கு வானிலை அறிக்கை மற்றும் ஒரு இடம் தேவை என்பதை மாடல் அடையாளம் காணும்.
  • செயல்படுதல் (Act): மாடல் ஒரு கருவியைப் (tool) பயன்படுத்துகிறது. அது "Portland" என்பதைத் தீர்மானிக்க ஒரு geocoding API-ஐ அழைக்கலாம், பின்னர் அந்த ஆயத்தொலைவுகளைக் (coordinates) கொண்டு ஒரு வானிலை முனையத்தைத் (weather endpoint) தொடர்பு கொள்ளலாம்.
  • கவனித்தல் (Observe): மாடல் கருவியின் வெளியீட்டை (output) வாசிக்கிறது. API ஒரு JSON வானிலை அறிக்கையைத் தந்ததா, அல்லது 403 பிழையைத் தந்ததா, அல்லது ஒரு HTML பராமரிப்புப் பக்கத்தைக் காட்டுகிறதா?
  • புதுப்பித்தல் (Update): பார்த்தவற்றின் அடிப்படையில், மாடல் தனது திட்டத்தை மாற்றியமைக்கிறது. Geocoder, Portland, Oregon என்பதற்குப் பதிலாக Portland, Maine என்று பதிலளித்தால், மாடல் அதைத் தெளிவுபடுத்த வேண்டும். API வேலை செய்யவில்லை என்றால், அது மாற்று ஆதாரத்திற்கு மாறலாம் அல்லது பயனரிடம் கேட்கலாம்.
  • மீண்டும் சிந்தித்தல் (Think Again): புதிய சூழலுடன் (context) சுழற்சி மீண்டும் தொடங்குகிறது.

இது நீங்கள் ஒருமுறை எழுதிவிட்டு மறந்துவிடும் ஐந்து தனித்தனி செயல்பாடுகள் அல்ல. இது இலக்கை அடையும் வரை அல்லது ஒரு கட்டாய நிறுத்தம் ஏற்படும் வரை இயங்கிக்கொண்டே இருக்கும் ஒரு தொடர்ச்சியான இயந்திரம். மாடல் ஒரு ஸ்கிரிப்ட் போல குறியீட்டை (code) மட்டும் இயக்கவில்லை. அது உலகின் நிலையைப் பற்றிச் சிந்தித்து, ஒரு செயலைத் தேர்ந்தெடுத்து, அதன் விளைவைப் படித்து, அடுத்து என்ன செய்ய வேண்டும் என்று தீர்மானிக்கிறது. ஒரு fancy autocomplete-க்கும் வேலையை முடிக்கும் ஒரு ஏஜென்ட்டுக்கும் இடையிலான வித்தியாசம் இதுதான்.

ஏன் அனைத்து பிரேம்வொர்க்குகளும் (Frameworks) ஒரே மாதிரியாகத் தோன்றுகின்றன

நீங்கள் LangGraph, CrewAI அல்லது AutoGen ஆகியவற்றைப் பயன்படுத்தியிருந்தால், அவை அனைத்தும் ஒன்றோடொன்று கலப்பதைப் போலத் தோன்றுவதை நீங்கள் கவனித்திருக்கலாம். LangGraph ஓட்டத்தை (flow) நோட்கள் (nodes) மற்றும் எட்ஜ்களின் (edges) ஒரு நிலையான வரைபடமாக (persistent graph) மாதிரியாக்குகிறது. CrewAI ஏஜென்ட்களைப் பொறுப்புகள் (roles) மற்றும் குழுக்களாக (crews) ஒழுங்கமைக்கிறது. AutoGen பல ஏஜென்ட்கள் இடையிலான உரையாடல்களை ஒருங்கிணைக்கிறது. வெவ்வேறு பொதியிடல் (packaging), ஆனால் ஒரே எலும்புக்கூடு (skeleton).

இவை அனைத்தும் இந்த ஒரே லூப்பிங் கொள்கையை (looping principle) அடிப்படையாகக் கொண்டு வடிவமைக்கப்பட்டுள்ளதால் ஒரே மாதிரியாகத் தோன்றுகின்றன. LangGraph, கருவி அழைப்புகள் மற்றும் மாடல் அனுமானங்களுக்கு இடையிலான நிலை மாற்றங்களாக (state transitions) இந்தச் சுழற்சியைத் தெளிவாகக் கட்டமைக்கிறது. CrewAI இந்த லூப்பை பொறுப்பு அடிப்படையிலான ஏஜென்ட்களுக்குள் சுருக்குகிறது, ஆனால் ஒவ்வொரு குழு உறுப்பினரும் திட்டமிடுதல், செயல்படுதல் மற்றும் கவனித்தல் ஆகிய சுழற்சியையே மேற்கொள்கிறார்கள். AutoGen பல்வேறு நபர்களுக்கு இடையே செய்திகளைப் பரிமாறுகிறது, இருப்பினும் ஒவ்வொரு முறையும் உருவாக்குதல், செயல்படுத்துதல், பிரதிபலித்தல் மற்றும் வழிநடத்துதல் ஆகியவற்றின் மாறுபாடாகவே உள்ளது.

இந்த பிரேம்வொர்க்குகள் லூப்பில் கவனம் செலுத்துகின்றன, ஏனெனில் அங்கேயே ஏஜென்சி (agency) வாழ்கிறது. அடிப்படையான மாடல் GPT-4, Claude அல்லது ஒரு fine-tuned open-weight மாடலாக இருக்கலாம். லூப் இல்லையென்றால், உங்களிடம் மிகவும் விலையுயர்ந்த ஒரு வாக்கியத்தை முழுமையாக்கும் கருவி மட்டுமே இருக்கும். லூப் இருந்தால், பல முயற்சிகளுக்குப் பிறகும் ஒரு இலக்கை நோக்கித் தொடர்ந்து செயல்படக்கூடிய ஒரு அமைப்பைப் பெறுகிறீர்கள்.

உண்மையான வேலை எப்போது தொடங்குகிறது

லோக்கல் டெமோக்கள் (Local demos) மாயாஜாலமாகத் தோன்றும். ஆனால் தயாரிப்பு நிலையில் (Production), அந்த மாயாஜாலம் குழப்பங்களுடன் மோதும். நீங்கள் புரோட்டோடைப்பிங் (prototyping) நிலையைத் தாண்டிச் சென்றவுடன், AI சிக்கல்களைத் தீர்ப்பதை நிறுத்திவிட்டு, சிஸ்டம்ஸ் இன்ஜினியரிங் (systems engineering) சிக்கல்களைத் தீர்க்கத் தொடங்குவீர்கள்.

கருவித் தோல்விகள் (Tool failures) தவிர்க்க முடியாதவை. APIs காலாவதியாகலாம் (time out). அவை தவறான JSON தரவைத் தரலாம். அவை HTML-இல் பொதி செய்யப்பட்ட 500 பிழைகளைத் தரலாம். உங்கள் லூப் ஒவ்வொரு கருவியின் வெளியீட்டையும் குருட்டுத்தனமாக நம்பினால், உங்கள் ஏஜென்ட் வெற்றியைப் பற்றித் தவறாகக் கற்பனை செய்யக்கூடும் (hallucinate) அல்லது குழப்பத்தில் சிக்கிக்கொள்ளும். உங்களுக்கு ஒவ்வொரு வெளியீட்டிற்கும் (return payload) மறுமுயற்சி தர்க்கம் (retry logic), சர்க்யூட் பிரேக்கர்கள் (circuit breakers) மற்றும் ஸ்கீமா சரிபார்ப்பு (schema validation) ஆகியவை தேவைப்படும்.

நினைவகம் (Memory) காலாவதியாகிவிடும். பயனரின் விருப்பமான தரவுத்தளம் PostgreSQL என்பதை உங்கள் ஏஜென்ட் நினைவில் வைத்திருக்கும், ஆனால் உள்கட்டமைப்பு குழு நேற்று இரவு ஒரு புதிய கிளஸ்டருக்கு (cluster) மாறியிருக்கலாம். சூழலை (context) புதுப்பிப்பதற்கோ அல்லது காலாவதியாக்குவதற்கோ ஒரு வழிமுறை இல்லையென்றால், ஏஜென்ட் செயலிழந்த முனையங்களுக்கு (dead endpoints) நம்பிக்கையுடன் கட்டளைகளை வழங்கும். நினைவகத்திற்கு நேர முத்திரைகள் (timestamps), நம்பிக்கைப் புள்ளிகள் (confidence scores) மற்றும் தன்னைத்தானே செல்லாததாக்கும் திறன் தேவை.

முடிவில்லா லூப்கள் (Infinite loops) அமைதியான கொலையாளி. ஒரு ஏஜென்ட் இணையத்தைத் தேடுகிறது, பயனுள்ள ஒன்றைக் கண்டறியவில்லை, தேடலைச் சற்றே மாற்றியமைக்கிறது, மீண்டும் தேடுகிறது, எதையும் கண்டறியவில்லை, மேலும் மீண்டும் மீண்டும் செய்கிறது. அதிகபட்ச சுழற்சி வரம்பு (maximum iteration ceiling) அல்லது பொருத்தமான நகல் கண்டறிதல் (semantic duplicate detection) இல்லையென்றால், பயனர் காத்திருக்கும் நேரத்தில் அது டோக்கன்களையும் பணத்தையும் வீணடிக்கும். நீங்கள் பாதுகாப்பு வளையங்களை (guardrails) உருவாக்க வேண்டும்: மறுமுயற்சிகளுக்கான வரம்புகள், விலகல் சரிபார்ப்புகள் (divergence checks) மற்றும் மனிதத் தலையீட்டிற்கான வழிகள் (human escalation paths).

தேவையற்ற தரவுகள் பகுத்தறிவை மூழ்கடித்துவிடுகின்றன. Retrieval-Augmented Generation குழாய்கள் (pipelines) பெரும்பாலும் தொடர்பற்ற ஐம்பது பத்திகள் கொண்ட ஆவணங்களை context window-க்குள் கொட்டிவிடுகின்றன. இதனால் அந்த agent இரைச்சலால் திணறி, தவறான கருவியைத் தேர்ந்தெடுக்கிறது அல்லது ஒரு அளவுருவை (parameter) தவறாகக் கற்பனை செய்கிறது. மாதிரி (model) மீட்டெடுக்கப்பட்ட உரையைப் பார்ப்பதற்கு முன்பே, வடிகட்டுதல் (filtering), வரிசைப்படுத்துதல் (ranking) மற்றும் சுருக்கமான தொகுப்பு (summarisation) ஆகியவை அவசியமாகும்.

ஒரு agent-க்கு அறிவாற்றலை விட மேலான ஒன்று தேவைப்படுகிறது. அதற்கு ஒரு அமைப்பு தேவை: நிர்வகிக்கப்பட்ட நினைவகம் (managed memory), தெளிவான நிலை கண்காணிப்பு (explicit state tracking), கடுமையான பாதுகாப்பு வளையங்கள் (strict guardrails) மற்றும் கண்காணிக்கக்கூடிய தொலைதூர அளவீடுகள் (observable telemetry). மாதிரி எவ்வளவு சிறப்பாக இருக்கிறதோ, அந்தச் சுற்றியுள்ள அமைப்பும் அவ்வளவு சிறப்பாக இருக்க வேண்டும். ஒரு பலவீனமான சுழற்சிக்குள் (brittle loop) இருக்கும் சக்திவாய்ந்த மாதிரி, வெறும் தெளிவான தோல்விகளையே உருவாக்கும்.

வேலையை முழுமையாக்குதல்

Agents-இன் உண்மையான புத்திசாலித்தனம் என்பது முதல் பதிலைத் துல்லியமாகக் கூறுவது மட்டுமல்ல. எதுவும் திட்டமிட்டபடி நடக்காத போது, நோக்கம் மற்றும் விளைவு ஆகியவற்றிற்கு இடையிலான இடைவெளியைக் கையாளுவதே அதன் புத்திசாலித்தனம். முதல் முயற்சி எளிதானது. எவரும் ஒரு happy path-ஐ உருவாக்க முடியும். ஆனால் கடினமான பகுதி நான்காவது சுழற்சியில் (iteration) வரும்; அப்போது முதன்மை API செயலிழந்து இருக்கலாம், context window சுருங்கி இருக்கலாம், பயனர் பொறுமையிழக்கலாம், இருப்பினும் அந்த agent பயனுள்ள ஒன்றை வழங்க வேண்டியிருக்கும்.

அந்த விடாமுயற்சியே ஒரு டெமோவிற்கும் (demo) ஒரு தயாரிப்பிற்கும் (product) இடையிலான வேறுபாடாகும். இது ஒவ்வொரு நிலையிலிருந்தும் கற்றுக்கொள்ளும் திறன்; இது model weights-களை நிகழ்நேரத்தில் (real time) மாற்றுவதன் மூலம் அல்ல, மாறாகத் திட்டத்தை (plan) மாற்றுவதன் மூலம் நிகழ்கிறது. உத்திகள் மாறினாலும், agent இலக்கை நிலையாக வைத்திருக்கும். இதுவே செயல்படும் லூப்பிங் கொள்கை (looping principle) ஆகும்.

எனவே, எதிர்காலம் பெரிய மாதிரிகளுக்கா அல்லது சிறந்த செயல்பாட்டுச் சுழற்சிகளுக்கா (execution loops)? அளவிடுதல் (Scale) நிச்சயமாக உதவும். ஒரு திறமையான மாதிரி ஒவ்வொரு சுழற்சியிலும் சிறப்பாகப் பகுத்தறியும். ஆனால், ஒரு சிறிய மாதிரி, இறுக்கமான, கண்காணிக்கக்கூடிய மற்றும் மீள்திறன் கொண்ட (resilient) சுழற்சிக்குள் இயங்கும்போது, அது அனைத்தையும் ஒரே முயற்சியில் செய்யச் சொல்லப்படும் ஒரு பிரம்மாண்டமான மாதிரியை விட எப்போதும் சிறப்பாகச் செயல்படும். கணிப்பைச் செயலாக மாற்றுவது இந்தச் சுழற்சிதான். அதில் முதலீடு செய்யுங்கள்.

ஆதாரம்: The Looping Principle: A Simple Mental Model for Understanding AI Agents

இது போன்ற கூடுதல் விவாதங்களுக்கு, Telegram-இல் உள்ள GyaanSetu கற்றல் சமூகத்தில் இணையுங்கள்.