Agentic AI-യിലെ Observability

പരമ്പരാഗത microservices observability പ്രശ്നം പരിഹരിച്ചിട്ടുണ്ട്. Traces പാതകൾ കാണിക്കുന്നു. Metrics ലേറ്റൻസി (latency) കാണിക്കുന്നു. Logs കഥ വിവരിക്കുന്നു.

Agentic AI ഈ മാതൃകയെ തകർക്കുന്നു.

ഒരു ഉപയോക്താവിന്റെ ചോദ്യം guardrails, session reads, ഒന്നിലധികം LLM calls, വെബ് സെർച്ചുകൾ, reasoning loops എന്നിവയ്ക്ക് കാരണമായേക്കാം. പരാജയങ്ങൾ പലപ്പോഴും സൂക്ഷ്മമായിരിക്കും. ഒരു ടൂൾ പതുക്കെ പ്രവർത്തിച്ചേക്കാം. ഒരു context window വളരെ വലുതാകാൻ സാധ്യതയുണ്ട്. ഒരു error കാണിക്കാതെ തന്നെ ലോഡ് കൂടുമ്പോൾ ഒരു മോഡലിന്റെ പ്രവർത്തനം തകരാറിലാകാം.

ഈ സിസ്റ്റങ്ങൾ എങ്ങനെ നിരീക്ഷിക്കാമെന്ന് പരിശോധിക്കുന്നതിനായി ഞാൻ അടുത്തിടെ OpenTelemetry NBA Agent ഡെമോ പ്രവർത്തിപ്പിച്ചു. വിശ്വസനീയമായ AI agents നിർമ്മിക്കുന്നതിനെക്കുറിച്ച് ഞാൻ പഠിച്ച കാര്യങ്ങൾ ഇതാ.

Agent Observability-യുടെ മൂന്ന് തൂണുകൾ

• Traces, unit tests-നേക്കാൾ മൂല്യമുള്ളതാണ്. ഒരേ prompt തന്നെ ഓരോ തവണ ഉപയോഗിക്കുമ്പോഴും വ്യത്യസ്ത ഉത്തരങ്ങൾ നൽകിയേക്കാം. ഏജന്റ് സ്വീകരിച്ച പാത (path) മാത്രം കാണുകയല്ല, മറിച്ച് അത് എങ്ങനെയാണ് ആ ഉത്തരത്തിൽ എത്തിയത് എന്ന് നിങ്ങൾ കാണണം.

• ഉദ്ദേശ്യത്തെ (intent) പ്രവർത്തനങ്ങളുമായി (action) ബന്ധിപ്പിക്കുക. കാലാവസ്ഥയെക്കുറിച്ച് ചോദിക്കുമ്പോൾ ഒരു വാക്ക് കൊണ്ട് മറുപടി നൽകുന്നത് മതിയാകും, എന്നാൽ സാമ്പത്തിക ഉപദേശങ്ങൾക്ക് അത് പരാജയപ്പെടും. Guardrail തീരുമാനങ്ങളെയും ടൂൾ ഉപയോഗത്തെയും ഉപയോക്താവിന്റെ ഉദ്ദേശ്യവുമായി ബന്ധിപ്പിക്കേണ്ടതുണ്ട്.

• തുടക്കത്തിൽ തന്നെ baselines നിശ്ചയിക്കുക. Model updates-ഉം API മാറ്റങ്ങളും പ്രവർത്തനരീതിയെ മാറ്റിയേക്കാം. കാര്യങ്ങൾ മെച്ചപ്പെട്ടോ അതോ മോശമായോ എന്ന് അറിയാൻ ഒരു deployment-ന് മുമ്പ് തന്നെ നിങ്ങൾക്ക് metrics ആവശ്യമാണ്.

എന്തൊക്കെ അളക്കണം

നിങ്ങൾക്ക് മോഡൽ കോൾ (model call) മാത്രം നിരീക്ഷിച്ചാൽ പോരാ. നിങ്ങൾ മുഴുവൻ ഇക്കോസിസ്റ്റവും (ecosystem) instrument ചെയ്യണം.

  1. The Model Layer Operation names, provider details, token usage എന്നിവ ട്രാക്ക് ചെയ്യുക. Duration-ഉം finish reasons-ഉം നിരീക്ഷിക്കുക.

  2. Tools and MCP Servers ടൂളുകളെ microservices പോലെ പരിഗണിക്കുക. Latency, success rates, arguments എന്നിവ ട്രാക്ക് ചെയ്യുക. ഒരു ഏജന്റ് പതുക്കെയാണെങ്കിൽ, അത് പലപ്പോഴും ഒരു പതുക്കെ പ്രവർത്തിക്കുന്ന external API ആയിരിക്കാം, അല്ലാതെ LLM അല്ല.

  3. Guardrails എത്ര തവണ guardrails പ്രവർത്തിക്കുന്നുവെന്നും ഏത് വിഷയത്തിലാണ് ഇതoccurring എന്നും അളക്കുക. സുരക്ഷാ പാളികളുടെ (safety layers) ചിലവ് ന്യായീകരിക്കാൻ ഇത് നേതൃത്വത്തെ സഹായിക്കും.

  4. Memory and Sessions Context bloat ശ്രദ്ധിക്കുക. ഓരോ ടേണിലും (turn) ഇൻപുട്ട് ടോക്കൺ എണ്ണം കൂടുന്നത് വലിയ ചിലവുകൾക്ക് കാരണമായേക്കാം.

നിങ്ങളുടെ ഡാഷ്‌ബോർഡിനായുള്ള പ്രധാന മെട്രിക്സുകൾ (Key Metrics)

• Latency: Time to First Token (TTFT), end-to-end turn latency. • Cost: ആകെ ടോക്കണുകളും ഓരോ സെഷനിലും പ്രതീക്ഷിക്കുന്ന ചിലവും. • Reliability: Span kind അനുസരിച്ചുള്ള error rates (LLM vs Tool vs HTTP). • Behavior: Agent loop depth, tool call frequency.

Agentic AI എന്നത് പ്ലാനർ (planner) പ്രോബബിലിസ്റ്റിക് (probabilistic) ആയ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റമാണ്. ഏജന്റ് ലൂപ്പിന്റെ (agent loop) പൂർണ്ണരൂപം കാണാൻ സാധിച്ചില്ലെങ്കിൽ, നിങ്ങൾക്ക് അത് പ്രൊഡക്ഷനിൽ (production) പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ല.

Source: https://dev.to/archcode01/observability-in-agentic-ai-what-i-learned-after-instrumenting-a-real-llm-agent-with-opentelemetry-4h1

Optional learning community: https://t.me/GyaanSetuAi