এআই ও অটোমেশন

AgentCore Evaluations-এ framework বদলালেও eval আর ভাঙবে না

|লেখক: QUASA সম্পাদকীয় দল|5 মিনিটের পাঠ| 1
AgentCore Evaluations-এ framework বদলালেও eval আর ভাঙবে না

AWS ২৬ আগস্ট ২০২৬ Amazon Bedrock AgentCore Evaluations-এর framework-agnostic workflow প্রকাশ করেছে। AWS-এর প্রকাশিত workflow অনুযায়ী, Strands Agents ও LangGraph-এর পাশাপাশি OpenAI Agents SDK, LlamaIndex, Google ADK এবং Claude Agent SDK থেকে আসা উপযুক্ত telemetry একই evaluation layer-এ score করা যায়।

এর ফলে framework বদলালেই evaluation suite ভেঙে যাওয়ার কথা নয়—যদি নতুন stack-ও নির্ধারিত OpenTelemetry বা OpenInference contract মেনে সম্পূর্ণ trace পাঠায়। ITECS-এর ২৮ আগস্টের স্বাধীন পর্যালোচনা একই সীমা চিহ্নিত করেছে: এটি AgentCore Evaluations-এর নতুন launch নয়, বরং ২৬ আগস্ট প্রকাশিত বিস্তৃত framework-independent operation; arbitrary trace স্বয়ংক্রিয়ভাবে কাজ করবে না।

ছয়টি named framework, একই evaluation workflow

ছয়টি supported agent framework-এর structured telemetry একই AgentCore Evaluations workflow-তে score হচ্ছে

Named support-এর বর্তমান তালিকায় রয়েছে Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK এবং Claude Agent SDK। প্রতিটির instrumentation একই attribute ব্যবহার করে না; AgentCore span-এর scope.name দেখে কোন framework-specific handling বা কোন semantic convention প্রয়োগ করতে হবে তা নির্ধারণ করে।

  • Strands Agents ও LangGraph: আগে থেকে থাকা named integration বহাল আছে।
  • OpenAI Agents SDK, LlamaIndex, Google ADK ও Claude Agent SDK: সংশ্লিষ্ট OpenTelemetry বা OpenInference instrumentation দিয়ে বিস্তৃত support-এর অংশ হয়েছে।
  • Custom বা অন্য framework: স্বীকৃত prefix, span classifier এবং content attribute মিললে generic path ব্যবহার করতে পারে।

একই evaluator ব্যবহারের অর্থ framework-এর graph, state machine বা message object এক হয়ে যাওয়া নয়। Service CloudWatch থেকে trace ও correlated event record পড়ে prompt, response এবং tool-call data-কে evaluator-এর প্রয়োজনীয় সাধারণ কাঠামোয় আনে; framework-এর নিজস্ব runtime model সরাসরি মূল্যায়ন করে না।

কোন telemetry সত্যিই evaluate হবে

একটি session গঠনের জন্য span-এ থাকা session.id সংশ্লিষ্ট runtime session-এর সঙ্গে মিলতে হয়। সেই session-এর প্রতিটি trace_id একটি user turn হিসেবে ধরা হয়; তারপর service তিনটি প্রধান role খোঁজে—invoke agent, inference এবং execute tool।

Invoke-agent span থেকে user prompt ও final response, inference span থেকে model input ও reply, আর execute-tool span থেকে tool name, arguments ও result নেওয়া হয়। Retriever, reranker, embedding, guardrail বা memory span trace-এ থাকতে পারে, কিন্তু এই তিনটি আবশ্যিক evaluation role-এর বিকল্প নয়। কোনো framework আলাদা inference span না দিলে তার documented framework-specific handling যতটুকু data দেয়, evaluator ততটুকুই পাবে।

Unified telemetry-তে content span attribute-এই থাকে। Split telemetry-তে span এবং correlated event record আলাদা log group-এ থাকতে পারে; data source শুধু span ধরলে classification সফল হলেও response-scoring evaluator prompt বা response না পেয়ে ব্যর্থ হতে পারে। অল্প সময়ের process বন্ধ হওয়ার আগে buffered telemetry export না হলেও একই সমস্যা হবে।

Generic support-এর এক পাতার compatibility map

স্বীকৃত scope prefix ও identifying attribute-সহ custom agent trace generic evaluation path-এ শ্রেণিবদ্ধ হচ্ছে

AWS-এর generic framework specification অনুযায়ী, generic routing-এর জন্য তিনটি স্তর একসঙ্গে মিলতে হবে: স্বীকৃত scope prefix, evaluable span-এর identifying attribute এবং documented content attribute। শুধু OpenTelemetry format-এ কোনো span export করাই যথেষ্ট নয়।

  • OpenTelemetry scope: নাম শুরু হবে opentelemetry.instrumentation. দিয়ে। gen_ai.operation.name-এর invoke_agent, execute_tool ও chat value যথাক্রমে agent turn, tool execution ও inference চিহ্নিত করে; নির্দিষ্ট ক্ষেত্রে traceloop.span.kind বা llm.request.type fallback হতে পারে।
  • OpenInference scope: নাম শুরু হবে openinference.instrumentation. দিয়ে। openinference.span.kind-এর AGENT বা CHAIN, TOOL এবং LLM value তিনটি role আলাদা করে।
  • OpenTelemetry content: top-level input ও output-এর জন্য gen_ai.task.input এবং gen_ai.task.output; model message-এর জন্য gen_ai.input.messages ও gen_ai.output.messages; tool-এর জন্য gen_ai.tool.name, gen_ai.tool.call.arguments ও gen_ai.tool.call.result ব্যবহার করা যায়।
  • OpenInference content: input.value ও output.value agent বা tool content বহন করতে পারে; model message সাধারণত llm.input_messages.* এবং llm.output_messages.* attribute family থেকে নেওয়া হয়।

Recognized identifying attribute না থাকলে span বাদ যায়। Convention attribute দেওয়া সম্ভব না হলে agentcore.invocation.user_prompt এবং agentcore.invocation.agent_response দিয়ে top-level turn evaluate করা যায়, কিন্তু এতে inference বা tool trajectory পাওয়া যায় না।

HTTP, MCP ও SDK span কেন বাদ পড়ে

Agent tool span evaluation-এ থাকছে, আর HTTP, MCP ও AWS SDK infrastructure span বাদ পড়ছে

Prefix মিলে গেলেও transport এবং infrastructure instrumentation generic evaluation input নয়। বাদ পড়া scope-এর মধ্যে httpx, urllib3, urllib ও aiohttp_client-এর মতো HTTP client; Starlette ও FastAPI-এর মতো web framework; MCP instrumentation; এবং botocore-ভিত্তিক AWS SDK instrumentation রয়েছে। bedrock-agentcore ও bedrock-runtime infrastructure scope-ও এই exclusion-এর অন্তর্ভুক্ত।

এই filter network request বা SDK call-কে agent invocation, model inference কিংবা tool execution হিসেবে ভুল শ্রেণিবদ্ধ হওয়া থেকে আটকায়। তাই MCP transport span দেখা গেলেই tool-level evaluation হবে না; agent-কে আলাদা, convention-compliant execute-tool span-এ tool name, arguments ও result প্রকাশ করতে হবে।

Portability-র সীমা কোথায়

AgentCore Evaluations evaluation configuration-কে বহনযোগ্য করেছে, telemetry-র মান বা অর্থকে স্বয়ংক্রিয়ভাবে সমান করেনি। Generic path framework-এর custom data structure parse না করে extracted value-কে string হিসেবে নেয়। Prompt, response বা tool argument নিজস্ব nested envelope-এ রাখলে evaluator সেই wrapper-সহ value পেতে পারে, ফলে একই rubric চালালেও migration-এর আগের ও পরের score সরাসরি তুলনীয় নাও হতে পারে।

শিরোনামের “eval আর ভাঙবে না” প্রতিশ্রুতিটির কার্যকর সীমা তাই স্পষ্ট: নতুন framework-এ instrumentation package, স্বীকৃত scope prefix, span classifier, session.id, message content এবং প্রয়োজনীয় tool field অক্ষুণ্ণ থাকতে হবে। এই contract বজায় থাকলে একই evaluator suite framework-specific code ছাড়াই চালানো যায়; contract ভাঙলে framework-agnostic layer-এর কাছেও score করার মতো সম্পূর্ণ evidence থাকবে না।

এখন নিশ্চিত পরিবর্তনটি হলো ছয়টি named framework এবং convention-compliant custom agent-এর জন্য একটি সাধারণ evaluation পথ। নতুন instrumentation library-গুলো required field কতটা সম্পূর্ণভাবে emit করে এবং migration-এর দুই পাশে prompt, response ও tool trajectory কতটা তুলনীয় থাকে—portability-র বাস্তব ফল সেই telemetry quality-এর ওপরই নির্ভর করবে।

আরও পড়ুন:

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0