നിങ്ങളുടെ ഏജന്റുകൾ ശരിയാണ്, പക്ഷേ അവ തമ്മിലുള്ള കൈമാറ്റമാണ് (handoff) ശരിയല്ലാത്തത്.
മിക്ക മൾട്ടി-ഏജന്റ് ഡെമോകളും കാണിക്കുന്നത് ഒരു വേഷം കെട്ടിയ ഒറ്റ ഏജന്റിനെയാണ്. ഏജന്റ് A ഒരു ജോലി ചെയ്യുന്നുവെന്നും തുടർന്ന് ഏജന്റ് B മറ്റൊരു ജോലി ചെയ്യുന്നുവെന്നും അവ കാണിക്കുന്നു. എന്നാൽ ഏജന്റ് B-ക്ക് ആവശ്യമായ കാര്യങ്ങൾ നൽകുന്നതിൽ ഏജന്റ് A പരാജയപ്പെട്ടാൽ എന്ത് സംഭവിക്കുമെന്ന് അവ കാണിക്കുന്നില്ല.
ഈ വർഷം ഞാൻ മൂന്ന് മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങൾ പ്രൊഡക്ഷനിൽ എത്തിച്ചു. ഏജന്റുകൾ ആയിരുന്നില്ല പ്രയാസകരമായ ഭാഗം. അവ തമ്മിലുള്ള കൈമാറ്റങ്ങളായിരുന്നു (handoffs).
ഒരു കൈമാറ്റം എന്നത് വെറും ടെക്സ്റ്റ് കൈമാറുന്നതിനേക്കാൾ ഉപരിയാണ്. നിങ്ങൾ ഇവ നിയന്ത്രിക്കേണ്ടതുണ്ട്:
- സ്കീമ അലൈൻമെന്റ് (Schema alignment): ഏജന്റ് B ഓരോ തവണയും ഏജന്റ് A-യുടെ ഔട്ട്പുട്ട് പാഴ്സ് (parse) ചെയ്യണം.
- ഫെയിലർ പ്രൊപ്പഗേഷൻ (Failure propagation): ഒരു ഏജന്റ് പരാജയപ്പെടുമ്പോൾ അത് സിസ്റ്റത്തിന് അറിയണം.
- കോൺടെക്സ്റ്റ് ഹൈജീൻ (Context hygiene): ഓരോ കൈമാറ്റവും നിങ്ങളുടെ വിൻഡോയിൽ അനാവശ്യമായ വിവരങ്ങൾ (noise) കൂട്ടിച്ചേർക്കുന്നു.
ഏജന്റുകളെ ഒരു നൂലുകൊണ്ട് ബന്ധിപ്പിച്ചിരിക്കുന്ന ബ്ലാക്ക് ബോക്സുകളായി കാണുന്നതാണ് ഏറ്റവും വലിയ തെറ്റ്. നിങ്ങൾ ഏജന്റ് A-യ്ക്ക് ഒരു പ്രോംപ്റ്റ് നൽകുന്നു, ഒരു റിസൾട്ട് ലഭിക്കുന്നു, അത് ഏജന്റ് B-യിലേക്ക് തള്ളുന്നു. ഇത് തകരാറിലാകുന്നത് വരെ പ്രവർത്തിക്കും. എന്നാൽ അത് തകരാറിലാകുമ്പോൾ, എന്തുകൊണ്ടാണ് അങ്ങനെ സംഭവിച്ചതെന്ന് നിങ്ങൾക്ക് മനസ്സിലാക്കാൻ കഴിയില്ല.
സാധാരണയായി സംഭവിക്കുന്ന ഈ മൂന്ന് പരാജയ രീതികൾ ഒഴിവാക്കുക:
സൈലന്റ് ട്രങ്കേഷൻ (Silent truncation): ഏജന്റ് A അമിതമായ ഡാറ്റ ഉൽപ്പാദിപ്പിക്കുന്നു. ഏജന്റ് B അതിന്റെ അവസാനം മുറിച്ചുമാറ്റുന്നു. തുടർന്ന് ഏജന്റ് B ഭാഗികമായ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുകയും നിങ്ങൾക്ക് അർത്ഥശൂന്യമായ ഫലം നൽകുകയും ചെയ്യുന്നു. ഓരോ ഘട്ടത്തിലും നിങ്ങളുടെ ടോക്കൺ കൗണ്ട് (token counts) അളക്കുക.
സ്കീമ ഡ്രിഫ്റ്റ് (Schema drift): നിങ്ങൾ ഏജന്റ് A-യുടെ പ്രോംപ്റ്റിൽ മാറ്റം വരുത്തുന്നു. ഇപ്പോൾ അത് മറ്റൊരു ഫോർമാറ്റിൽ റിസൾട്ട് നൽകുന്നു. പഴയ ഫോർമാറ്റ് പ്രതീക്ഷിക്കുന്നതിനാൽ ഏജന്റ് B തകരാറിലാകുന്നു. പ്രോംപ്റ്റുകളെ മാത്രം ആശ്രയിക്കുന്നതിന് പകരം Pydantic പോലുള്ള സ്ട്രക്ചേർഡ് ഔട്ട്പുട്ട് (structured output) ഉപയോഗിക്കുക.
റേസ് കണ്ടീഷൻസ് (Race conditions): നിങ്ങൾ ഒരേസമയം അഞ്ച് വർക്കർമാരെ പ്രവർത്തിപ്പിക്കുന്നു. മൂന്നെണ്ണം പൂർത്തിയാകുന്നു, എന്നാൽ രണ്ടെണ്ണം ഇപ്പോഴും പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്നു. നിങ്ങളുടെ അഗ്രഗേറ്റർ (aggregator) ഭാഗികമായ ഡാറ്റ ഉപയോഗിച്ച് നേരത്തെ തന്നെ തുടങ്ങുന്നു. ഇത് ടെസ്റ്റുകളിൽ പ്രവർത്തിക്കുമെങ്കിലും പ്രൊഡക്ഷനിൽ പരാജയപ്പെടും. എല്ലാ ടാസ്ക്കുകളും പൂർത്തിയാകുന്നത് വരെ കാത്തിരിക്കാൻ ഒരു ബാരിയർ (barrier) ഉപയോഗിക്കുക.
എന്റെ ആദ്യത്തെ സിസ്റ്റം ബുദ്ധിപരമായിരുന്നു എന്നാൽ അലങ്കോലപ്പെട്ടതായിരുന്നു. അത് ഡൈനാമിക് റൂട്ടിംഗും (dynamic routing) ഇംപ്ലിസിറ്റ് ഹാൻഡ്ഓഫുകളും (implicit handoffs) ഉപയോഗിച്ചിരുന്നു. യഥാർത്ഥ ട്രാഫിക് വന്നതുവരെ അത് പ്രവർത്തിച്ചു, എന്നാൽ പിന്നീട് നിശബ്ദമായി പരാജയപ്പെട്ടു.
എന്റെ രണ്ടാമത്തെ സിസ്റ്റം കാണാൻ ഭംഗിയില്ലെങ്കിലും കൃത്യമായിരുന്നു. ഓരോ കൈമാറ്റത്തിലും ഒരു ടൈപ്പ്ഡ് കോൺട്രാക്റ്റ് (typed contract) ഉപയോഗിച്ചിരുന്നു. ഓരോ പരാജയവും വ്യക്തമായിരുന്നു. ഓരോ ഏജന്റും ഐസൊലേറ്റഡ് (isolated) ആയിരുന്നു.
എന്റെ നിലവിലെ സിസ്റ്റം ഇവ രണ്ടിനെയും സംയോജിപ്പിക്കുന്നു. ഇത് രണ്ടാമത്തെ പതിപ്പിന്റെ അച്ചടക്കം ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും വിരസമായ കോഡുകളെ ഒരു ഫ്രെയിംവർക്കിന് (framework) പിന്നിൽ ഒളിപ്പിക്കുന്നു.
നിങ്ങൾ മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങൾ നിർമ്മിക്കുകയാണെങ്കിൽ, കാണാൻ ഭംഗിയില്ലാത്തതും എന്നാൽ കൃത്യവുമായ പതിപ്പിൽ നിന്ന് തുടങ്ങുക. ആദ്യം ബുദ്ധിപരമാകാൻ ശ്രമിക്കരുത്. പ്രൊഡക്ഷനിൽ അത് ശരിയായി പ്രവർത്തിപ്പിക്കുക, അതിനുശേഷം അതിനെ മനോഹരമാക്കുക.
കൈമാറ്റ പ്രശ്നം (handoff problem) എളുപ്പമാകില്ല. പക്ഷേ, അത് നിങ്ങളെ അത്ഭുതപ്പെടുത്തുന്നത് നിങ്ങൾ അവസാനിപ്പിക്കും.
സ്രോതസ്സ്: https://dev.to/mrclaw207/your-agents-are-fine-the-handoff-between-them-isnt-2dij
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi