AI ஏஜென்ட் ஒருங்கிணைப்புக்கான சிறந்த நடைமுறைகள்: தோல்விகள், ஒப்புதல்கள் மற்றும் மறுமுயற்சிகளைக் கையாளுதல்

AI ஏஜென்ட் ஒருங்கிணைப்பு எவ்வாறு செயல்படுகிறது என்பதை இந்த வழிகாட்டி விளக்குகிறது, மையப்படுத்தப்பட்ட, பரவலாக்கப்பட்ட மற்றும் படிநிலைக் கட்டமைப்புகளை ஒப்பிடுகிறது, மேலும் புரொடக்‌ஷனில் தோல்விகள், ஒப்புதல்கள் மற்றும் மறுமுயற்சிகளைக் கையாள்வதற்கான ஏழு சிறந்த நடைமுறைகளை உள்ளடக்குகிறது.

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

ஒரே திட்டத்தில் பல ஏஜென்ட்கள் பணியாற்றுவது மிகவும் திறமையானதாகத் தோன்றுகிறது. ஒன்று பணியைத் திட்டமிடுகிறது, மற்றொன்று வடிவமைப்பைக் கையாளுகிறது, மூன்றாவது குறியீட்டை எழுதுகிறது. தோல்வியடையும் வரை அது நன்றாகவே செயல்படுகிறது. நீங்கள் விரும்புவதை விட அடிக்கடி தோல்விகள் ஏற்படுகின்றன.

இத்தகைய தோல்விகளைத் தடுக்கக் கவனமான பணிப்பாய்வுப் பொறியியல் தேவை. எனவே, ஆர்கெஸ்ட்ரேட் செய்யப்பட்ட பணிப்பாய்வுகளை நம்பகமற்றதாக்குவது எது என்பதை விரிவாகப் பார்த்து, உற்பத்திச் சூழலில் நம்பகத்தன்மைக்கான ஆர்கெஸ்ட்ரேஷன் சிறந்த நடைமுறைகளை ஆராய்வோம்.

AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷன் என்றால் என்ன?

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

எளிமையாகச் சொன்னால், ஒரு ஆர்கெஸ்ட்ரேஷன் அடுக்கு ஓர் இலக்கைச் சிறிய பணிகளாகப் பிரிக்கிறது, சார்புகளைக் கண்காணிக்கிறது, சரியான ஏஜென்ட்களிடம் செயலாக்கத்தை ஒப்படைக்கிறது, பகிரப்பட்ட சூழலை நிர்வகிக்கிறது, வெளியீடுகளை ஒன்றிணைக்கிறது.

AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷன் எவ்வாறு செயல்படுகிறது: செயலாக்க இயந்திரத்தின் உள்ளே

ஒரு ஆர்கெஸ்ட்ரேட்டரிடம் பணியை வழங்கிய பிறகு என்ன நடக்கிறது என்பதைப் பார்ப்போம்.

Perplexity-இன் Computer பயிலரங்கிலிருந்து ஓர் எடுத்துக்காட்டைக் கவனியுங்கள்: Salesforce, Snowflake, மின்னஞ்சல், நாள்காட்டி, சமீபத்திய செய்திகள் ஆகியவற்றிலிருந்து பெறப்பட்ட தகவல்களைப் பயன்படுத்தி ஒரு கணக்கு நுண்ணறிவு டாஷ்போர்டை உருவாக்குதல்.

  1. இலக்கைப் புரிந்துகொண்டு பணியைத் திட்டமிடுங்கள். ஆர்கெஸ்ட்ரேட்டர் கோரப்பட்ட விளைவிலிருந்து தொடங்கி, அதை வெளிப்படையான சார்புகளுடன் கூடிய பணிகளாகப் பிரிக்கிறது. நமது டாஷ்போர்டு எடுத்துக்காட்டில், வெவ்வேறு மூலங்களிலிருந்து தகவல்களைச் சேகரித்து, அவற்றை முழுமையான வெளியீடாக மாற்றுவது இதில் அடங்கும். எந்தப் படிகள் மற்றவற்றைச் சார்ந்துள்ளன, எவை சுயாதீனமாக இயங்கலாம் என்பதைத் திட்டமிடல் கூறு தீர்மானிக்கிறது.
  2. பணிகளைப் பொருத்தமான ஏஜென்ட்களுக்கு வழிப்படுத்துங்கள். சார்புகள் பூர்த்தியான பணிகளை ஆர்கெஸ்ட்ரேட்டர் அடையாளம் கண்டு, சிறப்பு ஏஜென்ட்கள் அல்லது மாடல்களிடம் பணியை ஒப்படைக்கிறது. சார்ந்திருக்கும் பணிகள் அவற்றின் முன்தேவைகளுக்காகக் காத்திருக்கின்றன. Perplexity Computer பல முன்னணி மாடல்களைப் பயன்படுத்தி, பணிப்பாய்வின் வெவ்வேறு பகுதிகளை அந்தப் பணிகளுக்கு ஏற்ற அமைப்புகளுக்கு வழிப்படுத்துகிறது. இது சுயாதீனப் பணிகள் இணையாக இயங்கவும் அனுமதிக்கிறது.
  3. கட்டுப்படுத்தப்பட்ட சூழல்களுக்குள் கருவி அழைப்புகளைச் செயல்படுத்துங்கள். இணையத் தேடல், API-கள், இணைக்கப்பட்ட பயன்பாடுகள், கோப்புச் செயல்பாடுகள் அல்லது குறியீட்டுச் செயலாக்கம் போன்ற கருவிகள் மூலம் ஏஜென்ட்கள் தங்கள் சூழலுடன் தொடர்புகொள்கின்றன. செயலாக்க அடுக்கு இந்தச் செயல்களை இயக்கி, முடிவுகளை ஏஜென்ட்களிடம் திருப்பி அனுப்புகிறது.
  4. ஏஜென்ட்களுக்கு இடையே முடிவுகளையும் சூழலையும் கடத்துங்கள். ஓர் ஏஜென்ட் தன் பணியை முடித்தவுடன், அடுத்துவரும் ஏஜென்ட் தொடர்வதற்குத் தொடர்புடைய வெளியீடு தேவை. ஒரு கைமாற்றுப் பதிவில் பணி ID, வெளியீட்டுக் குறிப்பு, ஸ்கீமா பதிப்பு, மூல மெட்டாடேட்டா ஆகியவை இருக்கலாம். அடுத்தடுத்த படிகளுக்குத் தேவையான சூழலைப் பராமரித்தபடி ஆர்கெஸ்ட்ரேட்டர் இந்தக் கைமாற்றங்களை ஒருங்கிணைக்கிறது. முக்கியமாக, மற்ற ஒவ்வொரு ஏஜென்டின் பணியின் முழு வரலாற்றையும் ஏஜென்ட்கள் தங்கள் சொந்தச் சூழல் சாளரங்களில் சுமந்து செல்ல வேண்டியதில்லை.
  5. ஏஜென்ட் சூழலிலிருந்து தனியாகச் செயலாக்க நிலையைப் பதிவுசெய்யுங்கள். ஏஜென்ட்கள் பணிகளைத் தொடங்கும்போது, முடிக்கும்போது அல்லது அவற்றில் தோல்வியடையும்போது, செயலாக்க இயந்திரம் பணி நிலைகள், செயலாக்க முயற்சிகள், வெளியீட்டுக் குறிப்புகள், மீதமுள்ள பணிகள் ஆகியவற்றுடன் ஒரு நிலையான பணிப்பாய்வுப் பதிவைப் புதுப்பிக்கிறது. உரையாடல் வரலாற்றிலிருந்து பணிப்பாய்வை மீண்டும் உருவாக்க LLM-ஐச் சார்ந்திருக்காமல், முன்னேற்றத்தைக் கண்காணிக்கவும் இடையூறுகளுக்குப் பிறகு மீண்டும் தொடரவும் இந்தப் பதிவு ஆர்கெஸ்ட்ரேட்டருக்கு உதவுகிறது.
  6. முடிவுகளைச் சரிபார்த்து, அடுத்து என்ன நடக்க வேண்டும் என்பதைத் தீர்மானியுங்கள். ஒரு பணி திரும்பும்போது, அதன் வெளியீடு எதிர்பார்க்கப்படும் ஒப்பந்தத்தைப் பூர்த்தி செய்கிறதா, அடுத்த பணியின் சார்புகள் நிறைவேறியுள்ளனவா என்பதை ஆர்கெஸ்ட்ரேஷன் அடுக்கு சரிபார்க்கிறது. சிக்கல் கண்டறியப்பட்டால், திருத்தத்துக்காகப் பணிப்பாய்வு முந்தைய படிக்குத் திரும்பலாம் அல்லது இடைநிறுத்தப்படலாம். இல்லையெனில், அது நிறைவை நோக்கித் தொடர்கிறது.

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

AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷனை எப்போது பயன்படுத்த வேண்டும்?

பணியின் வெவ்வேறு பகுதிகளுக்குத் தனித்துவமான நிபுணத்துவம் தேவைப்படும்போது, சுயாதீனப் பணிகள் இணையாக இயங்க முடியும்போது, அல்லது அடுத்த படியை முன்கூட்டியே தீர்மானிக்க முடியாதபோது பல ஏஜென்ட் ஆர்கெஸ்ட்ரேஷனைக் கருத்தில் கொள்ளுங்கள்.

எனவே, மூன்று சூழ்நிலைகளில் ஆர்கெஸ்ட்ரேஷன் உதவியாக இருக்கும்:

  • பணிகளுக்கு வெவ்வேறு சிறப்பு நிபுணத்துவங்கள் தேவை. எடுத்துக்காட்டாக, ஒரு குறியீட்டுத் திட்டத்துக்குத் திட்டமிடல், வடிவமைப்பு, மேம்பாடு, மதிப்பாய்வு ஆகியவற்றுக்கான தனித்தனி ஏஜென்ட்கள் பயனளிக்கலாம்.
  • சுயாதீனப் பணிகள் இணையாக இயங்க முடியும். ஒரே ஏஜென்ட் அனைத்தையும் வரிசையாக முடிப்பதற்குப் பதிலாக, பல ஏஜென்ட்கள் ஒரே நேரத்தில் பணியாற்றி, தங்கள் முடிவுகளை ஒரு ஆர்கெஸ்ட்ரேட்டரிடம் திருப்பி அனுப்பலாம்.
  • சிக்கல் திறந்தநிலையானது. முன்வரையறுக்கப்பட்ட வரிசையைப் பின்பற்றுவதற்குப் பதிலாக, ஏஜென்ட்கள் வெவ்வேறு அணுகுமுறைகளை ஆராயவும், முடிவுகளை எடுக்கவும், ஒத்துழைக்கவும் வேண்டியிருக்கலாம்.

அவை தவிர, ஆர்கெஸ்ட்ரேஷன் என்பது விலையுயர்ந்த ஒரு போக்கு மட்டுமே. அதிக ஏஜென்ட்கள் என்றால் அதிக ஒருங்கிணைப்பும், அதிக டோக்கன் செலவுகளுக்கான வாய்ப்பும் ஆகும்.

“நான் வழக்கமாக எளிமையான வழியில் தொடங்கி, அங்கிருந்து கட்டமைப்பேன். படிகள் நமக்குத் தெரிந்து, அவை மீண்டும் மீண்டும் செய்யக்கூடியவையாக இருந்தால், அது பெரும்பாலும் ஒரு பணிப்பாய்வாக இருக்கும். ஏஜென்ட்களுக்கு வெவ்வேறு பொறுப்புகள், அனுமதிகள் அல்லது பயனர்கள் இருக்கும்போது மட்டுமே பல ஏஜென்ட்களை அறிமுகப்படுத்துவதற்கான காரணத்தை நான் காண்கிறேன்,” என்கிறார் Josh Spilker, AirOps-இன் தேடல் சந்தைப்படுத்தல் தலைவர்.

அப்போதும்கூட, கூடுதல் மாடல் அழைப்புகள், கைமாற்றங்கள், தாமதம், தோல்விப் புள்ளிகள் ஆகியவற்றுடன் நன்மைகளை ஒப்பிட்டுப் பாருங்கள்.

AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷன் கட்டமைப்புகளும் அவற்றின் சாதக பாதகங்களும்

ஏஜென்ட் ஒருங்கிணைப்பைக் கட்டமைப்பதற்கான மூன்று பொதுவான வழிகள் — மையப்படுத்தப்பட்ட, பரவலாக்கப்பட்ட, படிநிலை ஆர்கெஸ்ட்ரேஷன். சரியான கட்டமைப்பைத் தேர்ந்தெடுப்பது ஒரே கேள்வியைச் சார்ந்துள்ளது: பணியை யார் கட்டுப்படுத்துகிறார்கள், ஏஜென்ட்கள் ஒன்றுக்கொன்று எவ்வாறு ஒருங்கிணைகின்றன?

மையப்படுத்தப்பட்ட ஆர்கெஸ்ட்ரேஷன்

மையப்படுத்தப்பட்ட ஆர்கெஸ்ட்ரேஷனில், ஒரே ஆர்கெஸ்ட்ரேட்டர் செயல்முறையை நிர்வகிக்கிறது. அது பணியைப் பிரித்து, சிறப்பு ஏஜென்ட்களிடம் பணியை ஒப்படைத்து, அவற்றின் முன்னேற்றத்தைக் கண்காணித்து, அவற்றின் முடிவுகளை ஒன்றிணைக்கிறது.

சாதக பாதகம்: மையப்படுத்தப்பட்ட ஒருங்கிணைப்பு, செயலாக்கத்தைக் கண்காணிப்பதையும் ஒரே கட்டுப்பாட்டுப் புள்ளியில் பொதுவான விதிகளைப் பயன்படுத்துவதையும் எளிதாக்குகிறது. இருப்பினும், ஆர்கெஸ்ட்ரேட்டர் ஒரு தடைப்புள்ளியாக மாறக்கூடும்; அமைப்பு மீட்டெடுப்பை ஆதரிக்காவிட்டால், அதன் தோல்வி முழுப் பணிப்பாய்வையும் தடைப்படுத்தலாம்.

பரவலாக்கப்பட்ட ஆர்கெஸ்ட்ரேஷன்

பரவலாக்கப்பட்ட ஆர்கெஸ்ட்ரேஷனில், ஒவ்வொரு முடிவையும் எடுக்க ஒரே மேலாளரைச் சார்ந்திருப்பதற்குப் பதிலாக, ஏஜென்ட்கள் மிகவும் நேரடியாக ஒருங்கிணைகின்றன. அவை செய்திகளைப் பரிமாறிக்கொள்ளலாம், பகிரப்பட்ட நிலையைப் படிக்கலாம், தங்கள் அடுத்த படிகளைச் சுயாதீனமாகத் தீர்மானிக்கலாம்.

சாதக பாதகம்: மையத் திட்டமிடல் கூறுக்காகக் காத்திருக்காமல் ஏஜென்ட்கள் செயல்பட முடியும் என்பதால், இந்த அணுகுமுறை ஆய்வு சார்ந்த பணிகளுக்கும் சுயாதீனப் பங்களிப்புகளுக்கும் பயனுள்ளதாக இருக்கிறது. ஆனால் ஏஜென்ட்கள் முரண்படும்போது, பகிரப்பட்ட தகவலைப் புதுப்பிக்கும்போது, அல்லது சீரான முடிவை எட்ட வேண்டியிருக்கும்போது ஒருங்கிணைப்பு கடினமாகிறது.

படிநிலை ஆர்கெஸ்ட்ரேஷன்

படிநிலை ஆர்கெஸ்ட்ரேஷன் மேலாளர் அணுகுமுறையைப் பல நிலைகளுக்கு விரிவுபடுத்துகிறது. உயர்நிலை ஆர்கெஸ்ட்ரேட்டர் கீழ்நிலை ஆர்கெஸ்ட்ரேட்டர்களிடம் பொறுப்பை ஒப்படைக்கிறது; அவை தங்களுக்குரிய சிறப்பு ஏஜென்ட் குழுக்களை ஒருங்கிணைக்கின்றன.

விற்பனை, நிதி, சட்டக் குழுக்களை உள்ளடக்கிய ஒரு நிறுவனப் பணிப்பாய்வைக் கற்பனை செய்யுங்கள். உயர்நிலை ஆர்கெஸ்ட்ரேட்டர் ஒவ்வொரு பணி ஓட்டத்தையும் துறை சார்ந்த ஒருங்கிணைப்பாளரிடம் ஒப்படைக்கலாம். அந்த ஒருங்கிணைப்பாளர்கள் பின்னர் தங்கள் சொந்தச் சிறப்பு ஏஜென்ட்களை நிர்வகித்து, ஒருங்கிணைந்த முடிவுகளைத் தெரிவிப்பார்கள்.

ஒரே ஆர்கெஸ்ட்ரேட்டர் திறம்பட நிர்வகிக்க முடியாத அளவுக்குப் பணிப்பாய்வுகள் விரிவாக இருக்கும்போது இந்தக் கட்டமைப்பு உதவும்.

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

இந்தக் கட்டமைப்புகள் எவ்வாறு ஒப்பிடப்படுகின்றன:

அளவுகோல்

மையப்படுத்தப்பட்டது

பரவலாக்கப்பட்டது

படிநிலை

செயலாக்கப் பொறுப்பு

ஒரே ஆர்கெஸ்ட்ரேட்டர் பணி ஒப்படைப்பைக் கட்டுப்படுத்துகிறது

ஏஜென்ட்கள் சக ஏஜென்ட்கள் அல்லது பகிரப்பட்ட நிலை மூலம் ஒருங்கிணைகின்றன

பொறுப்பு ஆர்கெஸ்ட்ரேஷன் நிலைகள் முழுவதும் பகிர்ந்தளிக்கப்படுகிறது

நிலைச் சீர்மை

ஒரே கட்டுப்பாட்டுப் புள்ளி மூலம் ஒருங்கிணைப்பது எளிது

வெளிப்படையான ஒத்திசைவும் முரண்பாடு கையாளுதலும் தேவை

கிளைகளுக்குள்ளும் கிளைகளுக்கு இடையேயும் ஒருங்கிணைப்பு தேவை

தோல்வித் தனிமைப்படுத்தல்

மையக் கட்டுப்பாட்டாளர் ஒரு முக்கியமான சார்புநிலையாக மாறக்கூடும்

தனிப்பட்ட ஏஜென்ட்கள் சுயாதீனமாகத் தோல்வியடையலாம், ஆனால் பகிரப்பட்ட உள்கட்டமைப்பு முக்கியமானதாகவே இருக்கும்

மீட்டெடுப்புக்காக வடிவமைக்கப்பட்டிருந்தால், தோல்விகளைக் கிளைகளுக்குள்ளேயே கட்டுப்படுத்தலாம்

கொள்கை அமலாக்கம்

பொதுவான கட்டுப்பாடுகளை மையமாக அமல்படுத்தலாம்

பங்கேற்பாளர்கள் அனைவரிடமும் கொள்கைகள் சீராக அமல்படுத்தப்பட வேண்டும்

கட்டுப்பாடுகளை உலகளாவிய மற்றும் டொமைன் நிலைகளில் பயன்படுத்தலாம்

செயல்பாட்டுச் சிக்கல்

பொதுவாகக் குறைவு

அதிக ஒருங்கிணைப்புச் சிக்கல்

பல ஆர்கெஸ்ட்ரேஷன் அடுக்குகளால் அதிக சிக்கல்

வரிசைமுறை, இணையான மற்றும் ஒப்படைப்பு அடிப்படையிலான செயல்படுத்தல்

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

இவை மூன்று செயல்படுத்தல் முறைகள்:

  • வரிசைமுறை பணிப்பாய்வுகள்: ஏஜென்ட்கள் முன்கூட்டியே வரையறுக்கப்பட்ட வரிசையில் செயல்படுகின்றன; ஒரு ஏஜென்ட்டின் முடிவு அடுத்த ஏஜென்ட்டின் உள்ளீடாகிறது.
  • இணையான செயல்படுத்தல்: சுயாதீன ஏஜென்ட்கள் ஒரே நேரத்தில் செயல்படுகின்றன.
  • ஒப்படைப்பு அடிப்படையிலான செயல்படுத்தல்: பணி முன்னேறும்போது கட்டுப்பாடு நிபுணத்துவ ஏஜென்ட்களுக்கு இடையே மாறுகிறது. அடுத்த படியைக் கையாள வேறொரு ஏஜென்ட் சிறப்பாகத் தயாராக இருக்கும்போது இது பயனுள்ளதாக இருக்கும்; இருப்பினும், ஒவ்வொரு ஒப்படைப்பும் தொடர்வதற்குத் தேவையான தகவல்களைப் பாதுகாக்க வேண்டும்.

இந்த முறைகள் ஒன்றையொன்று விலக்குபவை அல்ல; அவை ஆர்கெஸ்ட்ரேஷன் கட்டமைப்புகளுடன் ஒன்றுக்கு ஒன்று பொருந்துவதும் இல்லை. உங்கள் பணிப்பாய்வின் சார்புகள், ஒருங்கிணைப்புத் தேவைகள் மற்றும் ஏற்கத்தக்க செயல்பாட்டுச் சுமையை ஆதரிக்கும் மிக எளிய கட்டமைப்பைத் தேர்வுசெய்வதே இலக்கு.

பொதுவான AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷன் தோல்விகள்

எளிய கவனக்குறைவுகள் முதல் சிக்கலான தடைகள் வரை, ஆர்கெஸ்ட்ரேஷனில் எதுவும் தவறாகப் போகலாம். சில நேரங்களில், ஒட்டுமொத்தப் பணிப்பாய்வு தோல்வியடையும்போதும் ஒரு ஏஜென்ட் தன் வேலையைச் சரியாகச் செய்வதுபோலத் தோன்றலாம். நடைமுறையாளர்களின் அனுபவங்களின் அடிப்படையில், நம்பகத்தன்மையற்ற ஆர்கெஸ்ட்ரேட் செய்யப்பட்ட பணிப்பாய்வுகளுக்குக் காரணமான சில பொதுவான தவறுகளைத் தொகுத்துள்ளோம் — இவற்றில் கவனமாக இருங்கள்:

  • தகவல் இழப்புள்ள ஏஜென்ட் ஒப்படைப்புகள். ஒரு ஆர்கெஸ்ட்ரேட்டர் சுருக்கப்பட்ட செயல்திட்டத்தை ஒரு நிபுணத்துவ ஏஜென்ட்டுக்கு அனுப்புகிறது, ஆனால் அந்தச் சுருக்கத்தில் கட்டுப்பாடுகள், சார்புகள் அல்லது செயல்படுத்தல் விவரங்கள் விடுபடுகின்றன.
  • முன்கூட்டிய fan-in செயல்படுத்தல். அனைத்து மேல்நிலை (upstream) பணிகளும் முடிவதற்கு முன்பே, கீழ்நிலை (downstream) ஏஜென்ட் ஒன்று முடிவுகளைத் திரட்டத் தொடங்குகிறது.
  • நிர்ணயமற்ற பகிர்வு-நிலைப் புதுப்பிப்புகள். தெளிவாக வரையறுக்கப்பட்ட இணைப்பு (merge) விதிமுறைகள் இல்லாமல், இணையான ஏஜென்ட்கள் ஒரே நிலை விசைகளில் (state keys) எழுதுகின்றன. ஃபிரேம்வொர்க் புதுப்பிப்புகளை எவ்வாறு கையாள்கிறது என்பதைப் பொறுத்து, இது எழுதியவை இழக்கப்படுதல், நகல் தரவு, வரிசையைச் சார்ந்த வெளியீடு அல்லது முரண்படும் மாற்றங்களுக்கு வழிவகுக்கலாம்.
  • செக்பாயிண்ட் மற்றும் பக்கவிளைவு முரண்பாடு. ஒரு பணி வெளிப்புறச் செயல்பாட்டைச் செய்கிறது, ஆனால் வொர்க்கர் தோல்வியடைவதற்கு முன் அதன் வெற்றிகரமான செயல்படுத்தல் நீடித்த முறையில் பதிவு செய்யப்படுவதில்லை. மீட்பின்போது, ஆர்கெஸ்ட்ரேட்டர் முடிக்கப்படாத பணியைக் கண்டு அதை மீண்டும் இயக்குகிறது.
  • மனித ஒப்புதலுக்குப் பின் மீண்டும் தொடங்கும்போது ஏற்படும் போட்டி நிலைகள் (race conditions). செயல்படுத்தலை இடைநிறுத்தி மீண்டும் தொடங்குவது அதற்கே உரிய ஒத்திசைவுச் சிக்கல்களை ஏற்படுத்துகிறது.
  • பணிப்பகிர்வுச் சுழற்சிகள் மற்றும் மறுமுயற்சிப் பெருக்கம். பொறுப்புகள் ஒன்றுடன் ஒன்று மேற்பொருந்துவதாலோ, சார்புகள் சுழல்வடிவில் இருப்பதாலோ, நிறைவு நிபந்தனைகள் தெளிவற்றதாக இருப்பதாலோ ஏஜென்ட்கள் வேலையைத் திரும்பத் திரும்ப ஒன்றுக்கொன்று ஒப்படைக்கின்றன.
  • அறிவுறுத்தல்-நிலைக் கட்டுப்பாடுகளைச் செயல்படுத்தல் பாதுகாப்பாகத் தவறாகக் கருதுதல். சில வளங்களை அணுக வேண்டாம் அல்லது முக்கியமான செயல்களைச் செய்ய வேண்டாம் என்று ஒரு ஆர்கெஸ்ட்ரேட்டர் ஏஜென்ட்களிடம் சொல்லலாம், ஆனால் மாடல் அறிவுறுத்தல்கள் இயக்க முறைமை அனுமதிகள், நெட்வொர்க் கட்டுப்பாடுகள் அல்லது அங்கீகார எல்லைகளை அமல்படுத்துவதில்லை. தீங்கிழைக்கும் அறிவுறுத்தல்கள் இல்லாவிட்டாலும், நியாயமான இலக்குகளைப் பின்தொடரும்போது ஏஜென்ட்கள் ஏன் பாதுகாப்பு எல்லைகளைக் கடக்கக்கூடும் என்பதை Perplexity-இன் பாதுகாப்புப் பொறியியல் ஆய்வு எடுத்துக்காட்டுகிறது

இந்தத் தோல்விகள் எவ்வளவு வேறுபட்டவை என்பதைக் கவனியுங்கள். முன்கூட்டிய ஷெட்யூலர் மாற்றம் அல்லது தெளிவற்ற வெளிப்புற எழுதுதல் ஆகிய இரண்டுமே தவறான விளைவை ஏற்படுத்தலாம், ஆனால் அவை செயல்படுத்தல் வாழ்க்கைச் சுழற்சியின் வெவ்வேறு பகுதிகளில் தோன்றுகின்றன. அதனால்தான் நம்பகமான ஆர்கெஸ்ட்ரேஷனுக்கு ப்ராம்ப்ட்களை மேம்படுத்துவதையோ மறுமுயற்சிகளைச் சேர்ப்பதையோ விட அதிகம் தேவைப்படுகிறது.

உற்பத்திச் சூழலில் நம்பகத்தன்மைக்கான 7 AI ஏஜென்ட் ஆர்கெஸ்ட்ரேஷன் சிறந்த நடைமுறைகள்

1. வெளிப்படையான பணி ஒப்பந்தங்கள், ஏற்பு அளவுகோல்கள் மற்றும் நிறுத்த நிபந்தனைகளை வரையறுங்கள்

தெளிவற்ற இலக்குகளும் தெளிவில்லாத நிறைவு வரையறையும் (definition of done) பெரும்பாலும் ஏமாற்றமளிக்கும் ஏஜென்ட் உருவாக்கிய முடிவுகளுக்கு வழிவகுக்கின்றன. இதற்கான தீர்வு ஒரு ப்ராம்ப்ட் ஒப்பந்தம் (ஒரு ஏஜென்ட்டுக்கான வேலை வரம்பு): செயல்படுத்தல் தொடங்குவதற்கு முன்பே இலக்கு, கட்டுப்பாடுகள், வெளியீட்டு வடிவம் மற்றும் தோல்வி நிபந்தனைகளை ஒப்புக்கொள்ளுங்கள்.

எடுத்துக்காட்டாக, இடையிடையே தோல்வியடையும் ஒருங்கிணைப்புச் சோதனையைச் சரிசெய்யும் பொறுப்புள்ள ஏஜென்ட்டுக்கான ஒப்பந்தத்தை இப்படி வரையறுக்கலாம்:

  • இலக்கு: நிலையற்ற (flaky) checkout API ஒருங்கிணைப்புச் சோதனையின் காரணத்தைக் கண்டறிந்து சரிசெய்தல்.
  • உள்ளீடுகள்: சோதனை மூலக் குறியீடு, CI தோல்விப் பதிவுகள், சமீபத்திய கமிட்கள் மற்றும் தொடர்புடைய பயன்பாட்டுக் குறியீடு.
  • கட்டுப்பாடுகள்: சோதனைகளை முடக்கவோ, assertion-களைத் தளர்த்தவோ, தொடர்பில்லாத பயன்பாட்டு நடத்தையை மாற்றவோ கூடாது.
  • எதிர்பார்க்கப்படும் வெளியீடு: ஒரு குறியீட்டு பேட்ச், மூலக் காரணத்தின் விளக்கம் மற்றும் சோதனை இயக்க முடிவுகள்.
  • ஏற்பு அளவுகோல்கள்: முன்பு தோல்வியடைந்த சோதனை தொடர்ச்சியான 10 இயக்கங்களிலும் வெற்றிபெறுகிறது, மேலும் தொடர்புடைய ரிக்ரெஷன் சோதனைத் தொகுப்பும் வெற்றிபெறுகிறது.
  • தோல்வி நிபந்தனைகள்: மூலக் காரணத்தைக் கண்டறிய முடியவில்லை, சரிசெய்தல் புதிய ரிக்ரெஷன்களை ஏற்படுத்துகிறது, அல்லது தேவையான சோதனைச் சூழல் கிடைக்கவில்லை.

ஆனால் இன்னொரு முக்கியமான பகுதியும் உள்ளது: ஏஜென்ட் எப்போது நிறுத்த வேண்டும்?

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

நம் CI எடுத்துக்காட்டுக்குத் திரும்புவோம். பின்வரும் நிறுத்த நிபந்தனைகளை வரையறுக்கலாம்:

  • வெற்றி: சரிசெய்தல் தொடர்ச்சியான 10 சோதனை இயக்கங்களிலும் தொடர்புடைய ரிக்ரெஷன் தொகுப்பிலும் வெற்றிபெறுகிறது.
  • மறுசெயல் வரம்பு: ஏஜென்ட் அதிகபட்சம் இரண்டு சாத்தியமான சரிசெய்தல்களை மட்டுமே முயற்சிக்கலாம்.
  • செயல்படுத்தல் பட்ஜெட்: சிக்கல் தீர்க்கப்படாமல் இருந்தாலும், 60 நிமிடங்களுக்குப் பிறகு ஏஜென்ட் நிறுத்த வேண்டும்.
  • பணிப்பகிர்வு வரம்பு: ஏஜென்ட் ஒரே ஒரு நிபுணத்துவ ஏஜென்ட்டுக்கு மட்டும் வேலையைப் பகிர்ந்தளிக்கலாம்; அதற்கு மேல் துணை ஏஜென்ட்களுக்குப் பணிப்பகிர்வு கிடையாது.
  • பகுதியளவு நிறைவு: இரண்டு முயற்சிகளும் தோல்வியடைந்தாலோ நேர வரம்பு காலாவதியானாலோ, ஏஜென்ட் தன் கண்டுபிடிப்புகள், முயற்சித்த மாற்றங்கள் மற்றும் சோதனை முடிவுகளைத் திருப்பி அனுப்புகிறது.
  • தடைபட்ட செயல்படுத்தல்: சோதனைச் சூழல் கிடைக்கவில்லை என்றால், ஏஜென்ட் வெற்றி எனக் கூறுவதற்குப் பதிலாக நிறுத்திவிட்டுத் தடையைப் பற்றி அறிக்கை அளிக்கிறது.

2. ஆர்கெஸ்ட்ரேட்டர்களை எளிமையாக வைத்து, கட்டமைக்கப்பட்ட ஒப்படைப்புகளை அமல்படுத்துங்கள்

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

எனவே ஆர்கெஸ்ட்ரேட்டர்கள் தங்கள் வேலையைச் செய்யட்டும்; உறுதியான ஆர்ட்டிஃபேக்ட்களைக் குறிப்பிடுவதன் மூலம் ஒப்படைப்புகளை அமல்படுத்துங்கள்: அசல் பணி, தொடர்புடைய உள்ளீடுகள், வெளியீட்டு ஆர்ட்டிஃபேக்ட்கள், செயல்படுத்தல் நிலை மற்றும் தீர்க்கப்படாத சிக்கல்கள்.

இந்த எடுத்துக்காட்டைக் கவனியுங்கள்: status: completed என்பது முழுப் பணிப்பாய்வையும் அல்ல, ஏஜென்ட்டுக்கு ஒதுக்கப்பட்ட வேலையை மட்டுமே குறிக்கிறது. சோதனைகள் இன்னும் pending நிலையில் இருப்பதால், ஆர்கெஸ்ட்ரேட்டர் இறுதி முடிவை அங்கீகரிக்கக் கூடாது.

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. பணிப்பாய்வு நிலையை நீடித்துச் சேமித்து, சூழல் வளர்ச்சியைக் கட்டுப்படுத்துங்கள்

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

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

எனவே செயல்படுத்தல் நிலையை ஏஜென்ட்டின் பணிச் சூழலிலிருந்து தனியாக வையுங்கள். பணி நிலைகள், செயல்படுத்தல் முயற்சிகள், முடிக்கப்பட்ட படிகள் மற்றும் ஆர்ட்டிஃபேக்ட் குறிப்புகளை நீடித்த சேமிப்பகத்தில் சேமியுங்கள். அதே நேரத்தில், முழுச் செயல்படுத்தல் வரலாற்றையும் சூழல் சாளரத்தில் திணிப்பதற்குப் பதிலாக, ஏஜென்ட்டின் தற்போதைய பணிக்குத் தொடர்புடைய அறிவுறுத்தல்கள், உள்ளீடுகள் மற்றும் முடிவுகளை மட்டும் ஏற்றுங்கள்.

4. தோல்விகளைக் கருத்தில் கொள்ளும் மறுமுயற்சிகளையும் மீட்டெடுக்கக்கூடிய கருவிச் செயல்படுத்தலையும் வடிவமையுங்கள்

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

நேரமுடிவு (timeout) என்றால் செயல்பாடு தோல்வியடைந்தது என்று அவசியம் பொருளாகாது. அதனால்தான், அடுத்து என்ன நடக்க வேண்டும் என்று முடிவு செய்வதற்கு முன் பிழைகளை வேறுபடுத்த வேண்டும்:

  • தற்காலிகப் பிழைகள் (429, 503): வரம்புக்குட்பட்ட exponential backoff மற்றும் jitter உடன் மீண்டும் முயலுங்கள்; Retry-After வழங்கப்பட்டால் அதை மதியுங்கள்.
  • சரிபார்ப்பு அல்லது அனுமதிப் பிழைகள் (400, 403): அதே கோரிக்கையை மீண்டும் அனுப்புவதற்குப் பதிலாக, நிறுத்துங்கள் அல்லது அடிப்படைச் சிக்கலைச் சரிசெய்யுங்கள்.
  • தெளிவற்ற விளைவுகள் (சாத்தியமான எழுதுதலுக்குப் பிறகு நேரமுடிவு): மீண்டும் முயல்வதற்கு முன், செயல்பாடு வெற்றியடைந்ததா என்று சரிபாருங்கள்.

குறிப்பு: மீண்டும் முயலக்கூடிய பிழைகளுக்கும் வரம்புகள் தேவை. ஒவ்வொரு கருவி அழைப்புக்கும் நேரமுடிவை அமையுங்கள், மறுமுயற்சிகளின் எண்ணிக்கையையும் மொத்த மறுமுயற்சி நேரத்தையும் வரம்பிடுங்கள், மேலும் உள்ளமைந்த ஏஜென்ட்கள் ஒரே செயல்பாட்டைத் திரும்பத் திரும்பத் தொடங்க முடியாதபடி ஒட்டுமொத்தப் பணிப்பாய்வுக் காலக்கெடுவை அமல்படுத்துங்கள். ஒரு சார்பு மீண்டும் மீண்டும் தோல்வியடைந்தால், கோரிக்கைகளைத் தற்காலிகமாக நிறுத்த circuit breaker-ஐப் பயன்படுத்துங்கள்.

வெளிப்புறப் பக்கவிளைவுகளைக் கொண்ட செயல்பாடுகளுக்கு, ஒவ்வொரு தர்க்கரீதியான செயலுக்கும் ஒரு நிலையான idempotency key-ஐ ஒதுக்கி, மறுமுயற்சிகள் முழுவதும் அதையே மீண்டும் பயன்படுத்துங்கள். API சர்வர் பக்க நகல் நீக்கத்தை (deduplication) ஆதரித்தால், செயலை இருமுறை செய்யாமலேயே மீண்டும் வரும் கோரிக்கைகளை அது அடையாளம் காண முடியும். ஆதரிக்கவில்லை என்றால், correlation ID அல்லது பிற அதிகாரப்பூர்வக் குறிப்பைப் பயன்படுத்தி வெளிப்புற அமைப்பை வினவுங்கள்.

என்ன நடந்தது என்பதை உறுதிப்படுத்த முடியாதபோது, நிறுத்திவிட்டு மேல்நிலைக்குக் கொண்டு செல்லுங்கள் (escalate).

நம் CI ஏஜென்ட்டுக்கான மறுமுயற்சி லாஜிக்கின் எடுத்துக்காட்டு, போலிக்குறியீடாக (pseudocode):

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

குறியீட்டுக் குறிப்பு: ரன்களைக் கோரிக்கை ID மூலம் தேடுவதை CI API ஆதரிக்கிறது என இந்த எடுத்துக்காட்டு கருதுகிறது. request_id என்பது, வழங்குநர் idempotency-ஐ வெளிப்படையாக உத்தரவாதம் அளித்தால் மட்டுமே நகல்களைத் தடுக்கும். bounded_retry() என்பது விளக்கத்திற்கான போலிக்குறியீடு மட்டுமே. உற்பத்திச் சூழலில், மறுமுயற்சிகள் ஒவ்வொரு செயல்பாட்டுக்குமான மறுமுயற்சி பட்ஜெட் (அதிகபட்ச முயற்சிகள் அல்லது கடந்த நேரம்) மற்றும் ஒட்டுமொத்தப் பணிப்பாய்வுக் காலக்கெடு ஆகிய இரண்டாலும் வரம்பிடப்பட வேண்டும்.

பல சேவைகளில் பரவியிருக்கும் நீண்ட பணிப்பாய்வுகளுக்கு, பிந்தைய படிகள் தோல்வியடையும்போது ஈடுசெய்யும் செயல்களை ஒருங்கிணைக்க Saga முறைமையைக் கருத்தில் கொள்ளுங்கள். ஆனால் ஈடுசெய்தல் எப்போதும் முழுமையான ரோல்பேக் அல்ல என்பதை நினைவில் கொள்ளுங்கள். ஒரு டேட்டாபேஸ் புதுப்பிப்பைத் திரும்பப் பெறலாம், ஆனால் அனுப்பிய மின்னஞ்சலைத் திரும்பப் பெற முடியாது.

5. வெளிப்படையான வள பட்ஜெட்டுகளுடன் வேலையை வழிநடத்தி இணையாகச் செயல்படுத்துங்கள்

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

மாடல் தேர்வைப் பொறுத்தவரை, மாடல் திறனையும் பகுத்தறிதல் முயற்சியையும் பணியின் சிக்கலுக்கு ஏற்பப் பொருத்துங்கள் — இது எளிமையானது, ஆனால் பெரிதும் கவனிக்கப்படாதது. ரூட்டிங் விதிகளை உள்ளமைத்து மாடல்களை நீங்களே மதிப்பிடலாம், அல்லது உங்களுக்காக மாடல் தேர்வைக் கையாளும் ஆர்கெஸ்ட்ரேஷன் தளத்தைப் பயன்படுத்தலாம் என்பதைக் கவனியுங்கள்.

எடுத்துக்காட்டாக, Perplexity Computer-இன் Effort Mode, மாடலை நீங்களே தேர்ந்தெடுக்காமலேயே ஒரு பணிக்கு எவ்வளவு முயற்சி தேவை என்பதைத் தேர்வுசெய்ய உதவுகிறது. Light, Standard, High அல்லது Ultra-வைத் தேர்ந்தெடுங்கள்; Perplexity தானாகவே ஆர்கெஸ்ட்ரேட் செய்யும் மாடலையும் அதன் பகுத்தறிதல் நிலையையும் தேர்ந்தெடுக்கிறது. பின்னர் அந்த ஆர்கெஸ்ட்ரேட்டர் துணைப் பணிகளை உதவி ஏஜென்ட்களுக்குப் பகிர்ந்தளிக்கிறது; அவை வெவ்வேறு வழங்குநர்களின் மாடல்களைப் பயன்படுத்தலாம்.

Perplexity மாடல் உள்ளமைவுகளைத் தரம் மற்றும் செலவின் அடிப்படையில் மதிப்பிடுகிறது; ஒப்பிடத்தக்க முடிவுகளைத் தரும் குறைந்த செலவிலான விருப்பங்களுக்கு முன்னுரிமை அளிக்கிறது. மாடலையும் பகுத்தறிதல் நிலையையும் நீங்களே தேர்வுசெய்ய விரும்பினால், Custom கட்டுப்பாடுகளையும் பயன்படுத்தலாம்.

இணைச்செயலாக்கத்தைப் பொறுத்தவரை, வரம்பு உங்கள் உள்கட்டமைப்பு மற்றும் வெளிப்புறச் சார்புகளிலிருந்து வர வேண்டும். பகிரப்பட்ட API-களின் கோரிக்கை மற்றும் டோக்கன் விகித வரம்புகளைச் சரிபார்த்து, பின்னர் அதிகரிக்கும் ஒரே நேரச் செயலாக்கத்துடன் (concurrency) உங்கள் பணிப்பாய்வைச் சுமைச் சோதனை செய்யுங்கள். செயல்திறன் (throughput) மேம்படுகிறதா, அல்லது கோரிக்கைகள் வரிசையில் காத்திருக்கத் தொடங்குகின்றனவா, மெதுவாகின்றனவா, 429 பிழைகளைத் தருகின்றனவா என்பதைக் கவனியுங்கள்.

வளப் பயன்பாட்டைக் கணிக்கக்கூடியதாக வைத்திருக்க, வள வரம்புகளையும் திட்டமிடல் கட்டுப்பாடுகளையும் அமல்படுத்துங்கள்:

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

6. ஒப்புதல்களை அமல்படுத்தி, ஏஜென்ட் செயல்படுத்தலைத் தனிமைப்படுத்துங்கள்

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

“அளவுக்கு மீறிச் சிக்கலான மல்டி-ஏஜென்ட் அமைப்புகள் குறித்து, குறிப்பாக ஏஜென்ட்கள் ஒன்றின் வேலையை மற்றொன்று மதிப்பாய்வு செய்து அங்கீகரிக்கும்போது, எனக்குச் சந்தேகம் உண்டு. யாரும் உண்மையில் கண்டுபிடிக்காமலேயே, பல ஏஜென்ட்கள் ஒரே தவறை நம்பிக்கையுடன் அடுத்தடுத்துக் கடத்திவிடக்கூடும்,” என்று Spilker எச்சரிக்கிறார்.

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

  • அதன் அளவுருக்கள்
  • அதன் இலக்கு வளம்
  • அதன் கமிட் அல்லது நிலைப் பதிப்பு
  • மதிப்பாய்வாளரின் முடிவு

மேலும், ஒப்புதல் நிராகரிக்கப்பட்டால், காலாவதியானால் அல்லது மேல்நிலைக்குக் கொண்டு செல்ல வேண்டியிருந்தால் என்ன நடக்கும் என்பதை வரையறுங்கள். மீண்டும் தொடங்கக்கூடிய ஃபிரேம்வொர்க்குகளுக்கு இது அவசியம்; ஏனெனில் இடைநிறுத்தப்பட்ட ஒரு நோடை மீண்டும் தொடங்கும்போது, அந்த நோடின் தொடக்கத்திலிருந்து குறியீடு மீண்டும் இயக்கப்படுகிறது. இடைநிறுத்தத்திற்கு முன் ஏற்பட்ட பக்கவிளைவுகள் மீண்டும் நிகழக்கூடும்.

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

இலக்காகக் கருதப்படும் முழுமையாகத் தன்னாட்சி கொண்ட, தொடக்கம் முதல் முடிவு வரையிலான ஏஜென்ட்கள் என்ற கருத்தையும் Spilker ஆதரிக்கவில்லை. “என்னைப் பொறுத்தவரை, தெளிவான பொறுப்புகள், வரையறுக்கப்பட்ட அனுமதிகள் மற்றும் சரியான இடங்களில் மனித மதிப்பாய்வு கொண்ட, குறிப்பிட்ட பணியில் கவனம் செலுத்தும் சில ஏஜென்ட்களை உருவாக்குவதே சிறந்த அணுகுமுறை. முழுக் கட்டுப்பாட்டை விட்டுக்கொடுக்காமலேயே செயல்திறனைப் பெறலாம்,” என்று அவர் முடிக்கிறார்.

7. வெளியீடுகளைச் சுயாதீனமாகச் சரிபார்த்து, மீட்பு நடத்தையைச் சோதியுங்கள்

உண்மையில் தோல்வியடைந்தபோது ஒரு ஏஜென்ட் Success என்று அறிக்கை அளித்ததை எப்போதாவது சந்தித்திருக்கிறீர்களா? கோபமூட்டாவிட்டாலும் எரிச்சலூட்டும் விஷயம் இது; ஏஜென்ட்டின் இறுதிச் செய்தி எங்கே தவறு நடந்தது என்று சொல்லாமல் போகலாம் என்பதால், இதைச் சரிசெய்வதும் விரைவானதல்ல.

ஆராய, செயல்படுத்தலின்போது என்ன நடந்தது என்பதைத் தடமறிந்து, முடிவுகளைச் சுயாதீனமாகச் சரிபாருங்கள். எனவே, சிக்கலைத் தனிமைப்படுத்தித் தீர்ப்பதற்குச் சிறிது நேரம் ஒதுக்குவோம்.

என்ன தவறு நடந்தது என்பதைக் கண்டறியப் பணிப்பாய்வைத் தடமறியுங்கள்

ஒரு ஏஜென்ட்டின் ப்ராம்ப்ட்களை டீபக் செய்வதற்கு முன், முழுச் செயல்படுத்தல் பாதையையும் பதிவுசெய்யுங்கள். ஏஜென்ட் அழைப்புகள், கருவி அழைப்புகள், பிழைகள் மற்றும் மறுமுயற்சிகளை ஒரே பணிப்பாய்வு இயக்கத்தின் கீழ் இணைக்கும் ஒரு ட்ரேஸ் உங்களுக்குத் தேவை.

OpenTelemetry-இன் GenAI சொற்பொருள் மரபுகள் இந்தச் செயல்பாடுகளை விவரிக்க ஒரு தரப்படுத்தப்பட்ட வழியை வழங்குகின்றன. எடுத்துக்காட்டாக, invoke_workflow பணிப்பாய்வுச் செயல்படுத்தலையும், invoke_agent ஏஜென்ட் அழைப்பையும், execute_tool கருவி அழைப்பையும் அடையாளம் காட்டுகின்றன. ஒவ்வொரு செயல்பாட்டையும் அதன் நேரம், நிலை மற்றும் தொடர்புடைய மெட்டாடேட்டாவுடன் ஒரு span-ஆகப் பதிவுசெய்யலாம்.

இந்தப் படி செயல்படுத்தல் பாதையின் ட்ரேஸை உங்களுக்கு வழங்குகிறது; இதனால் ஒரு ஏஜென்ட் எங்கே தடுமாறியது என்பதைக் கண்டறியலாம்.

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

விளக்கத்திற்கான ஒரு செயல்படுத்தல் ட்ரேஸ்.

வெளியீட்டைச் சுயாதீனமாக மதிப்பாய்வு செய்யுங்கள்

முடிந்தவரை புரோகிராம் மூலமான சரிபார்ப்புகளைப் பயன்படுத்துங்கள். வெளியீடுகளை JSON ஸ்கீமாக்களுக்கு எதிராகச் சரிபாருங்கள், யூனிட் மற்றும் ஒருங்கிணைப்புச் சோதனைகளை இயக்குங்கள், தேவையான ஆர்ட்டிஃபேக்ட்கள் உள்ளனவா என்று சரிபாருங்கள், செயல்கள் உண்மையில் வெற்றியடைந்தனவா என்பதை உறுதிப்படுத்த வெளிப்புற அமைப்புகளை வினவுங்கள்.

அகநிலை மதிப்பீடு தேவைப்படும் — எனவே புரோகிராம் மூலமான சரிபார்ப்புகளால் மதிப்பிட முடியாத — வெளியீடுகளுக்கு, ஒரு சுயாதீன மதிப்பாய்வாளர் ஏஜென்ட்டை அறிமுகப்படுத்துங்கள். ஒரு அணுகுமுறை செயல்படுத்துபவர்–மதிப்பாய்வாளர்–தீர்ப்பவர் சுழற்சி: இதில் ஒரு ஏஜென்ட் ஆர்ட்டிஃபேக்ட்டை உருவாக்குகிறது, புதிய சூழலுடன் கூடிய மதிப்பாய்வாளர் சிக்கல்களைக் கண்டறிகிறது, மீண்டும் சரிபார்ப்பு இயங்குவதற்கு முன் தீர்ப்பவர் அவற்றைச் சரிசெய்கிறது.

முடிந்த இடங்களில் மதிப்பாய்வாளரின் கண்டுபிடிப்புகளை நீங்கள் இன்னும் சரிபார்க்க வேண்டும்; மேலும் திரும்பத் திரும்ப நடக்கும் மதிப்பீடுகளுக்கு LLM அடிப்படையிலான மதிப்பீட்டாளர்களைப் பயன்படுத்தினால், மனிதர்களால் மதிப்பாய்வு செய்யப்பட்ட எடுத்துக்காட்டுகளுடன் ஒப்பிட்டு அவற்றின் தீர்ப்புகளை அளவீடு செய்யுங்கள்.

மீட்பைச் சோதிக்கத் தோல்விகளை வேண்டுமென்றே உட்செலுத்துங்கள்

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

இதைச் சோதிக்க, ஒரு சோதனைச் சூழலில் வேண்டுமென்றே பிழைகளை உட்செலுத்துங்கள்:

  • API நேர முடிவுகளை (timeout) உருவகப்படுத்துங்கள்
  • வெளிப்புற எழுதுதல்களுக்கும் செக்பாயிண்ட்களுக்கும் இடையில் வொர்க்கர்களைச் செயலிழக்கச் செய்யுங்கள்
  • தவறான வடிவத்திலான கருவி வெளியீடுகளைத் திருப்பி அனுப்புங்கள்
  • ஒப்புதல்களைக் காலாவதியாக்குங்கள்

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

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

அதனால்தான், பணிப்பாய்வில் பதிவுசெய்யப்பட்ட நிலை, வெளிப்புற அமைப்புகளில் ஏற்பட்ட உண்மையான மாற்றங்கள் ஆகிய இரண்டையும் நீங்கள் சரிபார்க்க வேண்டும். திட்டமிடப்படாத பக்கவிளைவுகள் எதுவும் இல்லாமல் பணிப்பாய்வு எதிர்பார்க்கப்பட்ட நிலையை அடையும்போது மட்டுமே மீட்புச் சோதனை தேர்ச்சி பெற வேண்டும்.

நீங்கள் கண்டறியும் தோல்விகளை உங்கள் பின்னடைவுச் சோதனைகளில் (regression tests) சேர்த்துக்கொள்ளுங்கள், இதனால் எதிர்கால மாற்றங்கள் அவற்றை மீண்டும் கொண்டுவராது.

இறுதியில், வெற்றி என்பது, பணிப்பாய்வு தனக்குத் தேவையான சரிபார்ப்புகளில் தேர்ச்சி பெற்றது, அதன் வெளிப்புற விளைவுகள் சரிபார்க்கப்பட்டன என்பதைக் குறிக்கிறது.

AI ஏஜென்ட் ஒருங்கிணைப்பு: அடிக்கடி கேட்கப்படும் கேள்விகள்

தனித்தனியாக இயங்கும் AI ஏஜென்ட்கள் நிறுவன அளவில் ஏன் தோல்வியடைகின்றன?

தனித்தனியாக இயங்கும் ஏஜென்ட்கள் தங்கள் தனிப்பட்ட பணிகளைச் சரியாக முடிக்கலாம், ஆனால் ஒன்றாகச் சேர்ந்து முரண்பாடான முடிவுகளைத் தரலாம். ஒரு விற்பனை ஏஜென்ட் 10:00 மணிக்கு வாடிக்கையாளர் விதிமுறைகளைப் பெறுவதாகவும், ஒரு விலை நிர்ணய ஏஜென்ட் 10:05 மணிக்குப் புதுப்பிக்கப்பட்ட விலைகளைப் பயன்படுத்தி விலைப்புள்ளியைக் கணக்கிடுவதாகவும், 10:07 மணிக்கு மாற்றப்பட்ட ஒப்பந்தத்தை ஒரு சட்ட ஏஜென்ட் சரிபார்ப்பதாகவும் கற்பனை செய்து பாருங்கள். ஒவ்வொரு ஏஜென்ட்டும் வணிகத்தின் வெவ்வேறு ஸ்னாப்ஷாட்டுடன் செயல்படுவதால், அவற்றின் வெளியீடுகள் ஒன்றுக்கொன்று முரண்படக்கூடும்.

நிறுவன அளவில் இந்தச் சிக்கல் இன்னும் தீவிரமாகிறது, ஏனெனில் தனித்தனியாகப் புதுப்பிக்கப்படும், வெவ்வேறு அனுமதிகளுடன் செயல்படும், சூழலையோ செயல்படுத்தல் நிலையையோ எப்போதும் பகிர்ந்துகொள்ளாத பல அமைப்புகளுடன் ஏஜென்ட்கள் தொடர்புகொள்கின்றன.

AI ஏஜென்ட்களில் முடிவற்ற மறுமுயற்சிச் சுழல்களை எவ்வாறு தடுப்பது?

பல நிலைகளில் வரம்புகளை அமையுங்கள்: அதிகபட்ச கருவி-அழைப்பு மறுமுயற்சிகள், அதிகபட்ச ஏஜென்ட் சுழற்சிகள் (iterations), ஒப்படைப்பு ஆழம், ஒட்டுமொத்த பணிப்பாய்வுக் காலக்கெடு. மீண்டும் முயற்சிப்பதற்கு முன் தோல்விகளை வகைப்படுத்துங்கள். தற்காலிக 429 பதில்களுக்கு, Retry-After வழங்கப்பட்டிருந்தால் அதைப் பின்பற்றுங்கள். இல்லையெனில், ஜிட்டருடன் (jitter) கூடிய வரம்புக்குட்பட்ட அடுக்குக்குறிப் பின்வாங்கலைப் (exponential backoff) பயன்படுத்துங்கள்.

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

செயலிழப்புக்குப் பிறகு AI ஏஜென்ட் பணிப்பாய்வை எவ்வாறு மீண்டும் தொடங்குவது?

மீட்பு வழிமுறை உங்கள் இயக்கச் சூழலை (runtime) பொறுத்தது. LangGraph-இல், PostgresSaver போன்ற நிலைத்திருக்கும் (persistent) checkpointer, வரைபட நிலையை ஒரு thread_id-இன் கீழ் சேமிக்கிறது, இதனால் சேமிக்கப்பட்ட நிலையிலிருந்து செயல்படுத்தலைத் தொடர முடிகிறது. Temporal-இல், மற்றொரு வொர்க்கர் ஒரு பணிப்பாய்வின் நிகழ்வு வரலாற்றை மீண்டும் இயக்குவதன் மூலம் அதை மறுகட்டமைக்க முடியும். மீண்டும் இயக்கும்போது, அது முன்பு பதிவுசெய்யப்பட்ட activity முடிவுகளை மீண்டும் பயன்படுத்துகிறது.

பணிப்பாய்வுகள் இன்னும் இயங்கிக்கொண்டிருக்கும்போது பயன்பாடு மீண்டும் வரிசைப்படுத்தப்பட்டால் (redeploy), சேமிக்கப்பட்ட நிலையும் செயல்படுத்தல் வரலாறுகளும் இனி இணக்கமாக இல்லாமல் போகலாம். Temporal இதை Worker Versioning மற்றும் பணிப்பாய்வு பேட்சிங் (patching) மூலம் கையாள்கிறது. செக்பாயிண்ட் அடிப்படையிலான அமைப்புகளில், இணக்கமற்ற மாற்றங்களை வெளியிடுவதற்கு முன் ஸ்கீமா இடம்பெயர்வுகளைத் திட்டமிட்டு, ஏற்கனவே உள்ள சேமிக்கப்பட்ட நிலைகளைக் கொண்டு மீட்பைச் சோதியுங்கள்.

AI ஏஜென்ட் ஒருங்கிணைப்பின் நம்பகத்தன்மையை எவ்வாறு சோதிப்பது?

அதே பிரதிநிதித்துவப் பணிகளைப் பலமுறை இயக்கி, pass@k (k முயற்சிகளில் குறைந்தது ஒன்றாவது வெற்றி பெறுகிறதா) என்பதையும் pass^k (k முயற்சிகள் அனைத்தும் வெற்றி பெறுகின்றனவா) என்பதையும் வேறுபடுத்திப் பாருங்கள்

ஒரே ஒட்டுமொத்த வெற்றி விகிதத்தை நம்பியிருப்பதற்குப் பதிலாக, பணி வகை மற்றும் பணிப்பாய்வுப் பதிப்பின் அடிப்படையில் முடிவுகளை அளவிடுங்கள். முதல் முயற்சி வெற்றி, மீண்டும் மீண்டும் இயக்கும்போதான நிலைத்தன்மை, p95 தாமதம், முடிக்கப்பட்ட ஒவ்வொரு பணிக்குமான செலவு, மனிதத் தலையீடு தேவைப்படும் விகிதம் ஆகியவற்றைக் கண்காணியுங்கள். வெற்றி விகிதங்களுக்கான மாதிரி அளவுகளையும் நிச்சயமின்மை இடைவெளிகளையும் தெரிவியுங்கள்.