Microsoft-ന്റെ Foundry ടീം അതിന്റെ ഏജന്റ് ഫ്രെയിംവർക്കിൽ OpenTelemetry അടിസ്ഥാനമാക്കിയുള്ള ട്രേസിംഗ് (tracing) ചേർത്തു. ഇത് വികർത്താക്കൾക്ക് (developers) വൈവിധ്യമാർന്ന LLM അധിഷ്ഠിത ഏജന്റുകൾക്കിടയിലുള്ള എൻഡ്-ടു-എൻഡ് എക്സിക്യൂഷൻ കാണാൻ സഹായിക്കുന്നു.

മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങൾക്ക് ലോഗ് ഫയലുകൾ മാത്രം മതിയാകാത്തത് എന്തുകൊണ്ട്

ഒരു സാധാരണ AI അധിഷ്ഠിത ഇൻസിഡന്റ്-റെസ്പോൺസ് ഡ്രില്ലിൽ (incident-response drill), ഒരു കമാൻഡർ ഏജന്റ് പല സ്പെഷ്യലിസ്റ്റ് ഏജന്റുകളെയും നിയന്ത്രിക്കുന്നു: ഒന്ന് ലോഗുകൾ വിശകലനം ചെയ്യുന്നു, മറ്റൊന്ന് മെട്രിക് വ്യതിയാനങ്ങൾ (metric anomalies) കണ്ടെത്തുന്നു, മൂന്നാമത്തേത് ലക്ഷണങ്ങളെ റൺബുക്കുകളുമായി (runbooks) പൊരുത്തപ്പെടുത്തുന്നു, കൂടാതെ ഒരു റൂട്ടർ ഓരോ ഉപ-ദൗത്യത്തിനും അനുയോജ്യമായ ലാംഗ്വേജ് മോഡൽ തിരഞ്ഞെടുക്കുന്നു. ഓരോ സ്പെഷ്യലിസ്റ്റ് ഏജന്റും വ്യത്യസ്ത മോഡലുകൾ—ഉദാഹരണത്തിന്, ഒരു “gpt-5-mini” വേരിയന്റ്—ഉപയോഗിച്ചേക്കാം, കൂടാതെ അവയുടെ സ്വന്തം ടൂളുകളും ഉപയോഗിച്ചേക്കാം. എന്തെങ്കിലും പിഴവ് സംഭവിക്കുമ്പോൾ, ഓരോ ഘടകവും എന്താണ് ചെയ്തതെന്ന് കാണിക്കുന്ന ഒറ്റപ്പെട്ട ലോഗുകൾ മാത്രമേ എഞ്ചിനീയർമാർക്ക് ലഭിക്കുന്നുള്ളൂ; എന്നാൽ അവ എങ്ങനെ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന കാഴ്ചപ്പാട് അവർക്ക് ലഭിക്കുന്നില്ല.

ഒരു ഏകീകൃതമായ ട്രേസ് (unified trace) ഇല്ലാതെ, ഏജന്റുകൾ തമ്മിലുള്ള കൈമാറ്റത്തിനിടയിൽ യഥാർത്ഥ പ്രശ്നം (root cause) മറഞ്ഞിരിക്കുന്നു. കമാൻഡർ അയക്കുന്ന ഒരു റിക്വസ്റ്റ് ലോഗ്-റീഡർ ശരിയായി കൈകാര്യം ചെയ്തേക്കാം, എന്നാൽ മെട്രിക് സ്പെഷ്യലിസ്റ്റ് ആ ഡാറ്റ തെറ്റായി വ്യാഖ്യാനിക്കുകയും തെറ്റായ റൺബുക്ക് നിർദ്ദേശിക്കുകയും ചെയ്തേക്കാം. ഇത്തരമൊരു ശൃംഖല കൈകൊണ്ട് ഡീബഗ് (debug) ചെയ്യുന്നത് സമയമെടുക്കുന്നതും തെറ്റുകൾ സംഭവിക്കാൻ സാധ്യതയുള്ളതുമാണ്.

OpenTelemetry എങ്ങനെ വർക്ക്ഫ്ലോയെ ഒന്നിപ്പിക്കുന്നു

OpenTelemetry രണ്ട് പ്രധാന ആശയങ്ങൾ നിർവചിക്കുന്നു: traces, spans. ഒരു റിക്വസ്റ്റ് ആരംഭിക്കുന്നത് മുതൽ അവസാന പ്രതികരണമെന്ന (final response) വരെ പിന്തുടരുന്ന ഒരു തനതായ തിരിച്ചറിയൽ അടയാളമാണ് (unique identifier) ഒരു ട്രേസ് (trace). ഒരു ട്രേസിനുള്ളിലെ ഓരോ പ്രവർത്തനവും—ഉദാഹരണത്തിന്, ഒരു ലാംഗ്വേജ് മോഡലിലേക്കുള്ള കോൾ അല്ലെങ്കിൽ ഒരു ടൂൾ ഉപയോഗിക്കുന്നത്—ഒരു സ്പാൻ (span) രേഖപ്പെടുത്തുന്നു.

ഒരു ഏജന്റ് ഒരു റിക്വസ്റ്റ് സ്വീകരിക്കുമ്പോൾ, അത് റിക്വസ്റ്റിന്റെ മെറ്റാഡേറ്റിൽ (metadata) നിന്ന് ഇൻകമിംഗ് ട്രേസ് ഐഡി (Trace ID) എടുക്കുകയും അതേ ഐഡി സ്വീകരിക്കുന്ന ഒരു ചൈൽഡ് സ്പാൻ (child span) നിർമ്മിക്കുകയും ചെയ്യുന്നു. ചൈൽഡ് സ്പാൻ അതിന്റെ സ്റ്റാർട്ട് ടൈം, ഡ്യൂറേഷൻ, അറ്റ്രിബ്യൂട്ടുകൾ (മോഡൽ പേര്, ഉപയോഗിച്ച ടൂൾ), എന്തെങ്കിലും പിഴവുകൾ എന്നിവ രേഖപ്പെടുത്തുന്നു. ഓരോ ഡൗൺസ്ട്രീം ഏജന്റിനും ഈ പ്രക്രിയ ആവർത്തിക്കപ്പെടുന്നു, ഇത് മൊത്തത്തിലുള്ള ദൗത്യത്തിന്റെ ലോജിക്കൽ ഫ്ലോ പ്രതിഫലിപ്പിക്കുന്ന ഒരു ട്രീ (tree) നിർമ്മിക്കുന്നു.

കസ്റ്റം കീ-വാല്യൂ ജോഡികൾക്കായി (key-value pairs) ഉപയോഗിക്കുന്ന ഒരു ലഘുവായ സംവിധാനമായ Baggage-ഉം OpenTelemetry പിന്തുണയ്ക്കുന്നു. ട്രേസിന്റെ തുടക്കത്തിൽ തന്നെ ഒരു “drill-id” അല്ലെങ്കിൽ മറ്റ് ബിസിനസ്സ് വിവരങ്ങൾ ബാഗേജിൽ (baggage) ചേർക്കുന്നതിലൂടെ, എല്ലാ ഡൗൺസ്ട്രീം സ്പാനുകളും ആ ഐഡന്റിഫയർ സ്വയമേവ സ്വീകരിക്കുന്നു. ഒരു സ്പാൻ പ്രോസസ്സർ പിന്നീട് ഈ ബാഗേജിനെ സാധാരണ അറ്റ്രിബ്യൂട്ടുകളാക്കി മാറ്റുന്നു, ഇത് ഒരു പ്രത്യേക ഇൻസിഡന്റ് ഡ്രില്ലുമായി ബന്ധപ്പെട്ട എല്ലാ സ്പാനുകളെയും എളുപ്പത്തിൽ ക്വറി (query) ചെയ്യാൻ സഹായിക്കുന്നു.

പുതിയ ട്രേസിംഗ് സർഫേസ് എങ്ങനെയിരിക്കും

ഇൻസ്ട്രുമെന്റേഷൻ (instrumentation) സജ്ജമാക്കിയതോടെ, Azure Monitor (അല്ലെങ്കിൽ ഏതെങ്കിലും OpenTelemetry-അനുയോജ്യമായ ബാക്കെൻഡ്) ഒരു വിഷ്വൽ ഹൈരാർക്കി (visual hierarchy) പ്രദർശിപ്പിക്കുന്നു:

  • Agent name / ID – ഏത് ഘടകമാണ് പ്രവർത്തനം നടത്തിയത് എന്ന് കാണിക്കുന്നു.
  • Tool usage – ഏത് എക്സ്റ്റേണൽ സർവീസോ ഫംഗ്ഷനോ ആണ് വിളിച്ചതെന്ന് രേഖപ്പെടുത്തുന്നു.
  • Model version – ഉപയോഗിച്ച കൃത്യമായ LLM രേഖപ്പെടുത്തുന്നു, ഇത് മോഡൽ അപ്‌ഗ്രേഡിന് ശേഷമുള്ള മാറ്റങ്ങൾ (regressions) നിരീക്ഷിക്കാൻ സഹായിക്കുന്നു.
  • Token consumption – മോഡലിലേക്ക് എത്ര ടോക്കണുകൾ അയച്ചു എന്നും എത്ര ടോക്കണുകൾ ലഭിച്ചു എന്നും രേഖപ്പെടുത്തുന്നു, ഇത് ചിലവ് നിയന്ത്രിക്കാൻ ടീമുകളെ സഹായിക്കുന്നു.
  • Latency / duration – മോഡൽ ഇൻഫറൻസിലോ (model inference) ടൂൾ I/O-യിലോ തടസ്സങ്ങൾ (bottlenecks) എവിടെയാണെന്ന് വ്യക്തമാക്കുന്നു.

ഇൻസിഡന്റ്-ഡ്രിൽ ഉദാഹരണത്തിൽ, കമാൻഡറുടെ റൂട്ട് സ്പാൻ ഓരോ സ്പെഷ്യലിസ്റ്റിനും ചൈൽഡ് സ്പാനുകൾ സൃഷ്ടിക്കുന്നു, ഓരോ സ്പെഷ്യലിസ്റ്റും അതിന്റെ മോഡൽ കോളുകൾക്കായി കൂടുതൽ ചൈൽഡ് സ്പാനുകൾ സൃഷ്ടിക്കുന്നു. ഏതെങ്കിലും നോഡിൽ ക്ലിക്ക് ചെയ്താൽ അതിന്റെ മുഴുവൻ അറ്റ്രിബ്യൂട്ടുകളും കാണാൻ സാധിക്കും, അതിനാൽ ഓരോ പ്രവർത്തനത്തിന്റെയും വിശദാംശങ്ങൾ എഞ്ചിനീയർക്ക് പെട്ടെന്ന് മനസ്സിലാക്കാൻ കഴിയും.

AI അധിഷ്ഠിത പ്രവർത്തനങ്ങളിലെ പ്രാധാന്യം

  • Root-cause analysis-ന്റെ വേഗത – പിഴവുകൾ എവിടെയാണ് സംഭവിച്ചതെന്ന് കൃത്യമായ സ്പാൻ കണ്ടെത്തുന്നതിലൂടെ പ്രശ്നപരിഹാരത്തിനുള്ള സമയം (mean time to resolution) കുറയ്ക്കാൻ ടീമുകൾക്ക് സാധിക്കുന്നു.
  • ചിലവ് അറിയാനുള്ള സൗകര്യം (Cost visibility) – ടോക്കൺ എണ്ണവും ലേറ്റൻസിയും (latency) ഒരേസമയം കാണാൻ കഴിയുന്നതിനാൽ, ക്ലൗഡ് ബില്ലുകൾ വർദ്ധിക്കുന്നതിന് മുമ്പ് തന്നെ അമിതമായ ഉപയോഗം കണ്ടെത്താൻ ഫിനാൻസ് വിഭാഗത്തിന് സാധിക്കുന്നു.
  • പെർഫോമൻസ് ട്യൂണിംഗ് (Performance tuning) – ഏജന്റുകൾക്കിടയിലുള്ള ഉയർന്ന ലേറ്റൻസി ഉള്ള സ്പാനുകൾ കണ്ടെത്തുന്നതിലൂടെ, കാഷിംഗ് (caching), മോഡൽ സെലക്ഷൻ അല്ലെങ്കിൽ ടൂൾ റീഡിസൈൻ എന്നിവയിലൂടെ പ്രവർത്തനക്ഷമത വർദ്ധിപ്പിക്കാൻ സാധിക്കും.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

LangChain, OpenAI SDK അല്ലെങ്കിൽ മറ്റ് ഓർക്കസ്ട്രേഷൻ ലെയറുകളിൽ (orchestration layers) നിർമ്മിച്ച പ്രോജക്റ്റുകൾക്ക് GenAI-ക്കായി ഇതേ സെമാന്റിക് കൺവെൻഷനുകൾ (semantic conventions) സ്വീകരിക്കാവുന്നതാണ്. ഇത് ക്ലൗഡ് പ്രൊവൈഡർമാർക്കും ഓൺ-പ്രെമിസ് ഡിപ്ലോയ്മെന്റുകൾക്കും ഇടയിൽ സുഗമമായി ഒഴുകുന്ന ട്രേസുകൾക്ക് വഴിയൊരുക്കുന്നു.

സ്ഥാപനങ്ങൾക്ക് അവരുടെ ഏജന്റുകളിൽ OpenTelemetry SDK എനേബിൾ ചെയ്താൽ മതി, തുടർന്ന് ഡാറ്റ Azure Monitor-ലേക്കോ അല്ലെങ്കിൽ ഒരു ഓപ്പൺ സോഴ്സ് കളക്ടറിലേക്കോ അയക്കാം.

ചുരുക്കത്തിൽ

ചിതറിക്കിടക്കുന്ന ലോഗുകളെ ഒരു വ്യക്തമായ വിവരണമാക്കി മാറ്റുന്നതിനുള്ള ആ വിട്ടുപോയ കണ്ണിയാണ് (missing glue) മൾട്ടി-ഏജന്റ് AI സിസ്റ്റങ്ങൾക്ക് OpenTelemetry നൽകുന്നത്. വൈവിധ്യമാർന്ന LLM-കൾ, റൂട്ടറുകൾ, ടൂൾ കോളുകൾ എന്നിവയിലൂടെ ഒരു സിംഗിൾ ട്രേസ് ഐഡി (Trace ID) കൈമാറുന്നതിലൂടെ, പുതിയ ട്രേസിംഗ് ഇൻഫ്രാസ്ട്രക്ചറുകൾ നിർമ്മിക്കാതെ തന്നെ പിഴവുകൾ കണ്ടെത്താനും, ചിലവ് നിരീക്ഷിക്കാനും, പെർഫോമൻസ് മെച്ചപ്പെടുത്താനും ഡെവലപ്പർമാർക്ക് സാധിക്കുന്നു.