Glean-এর দাবি, AI token খরচ ৮১% কম: benchmark-টির সীমাও দেখুন

Glean ২৬ আগস্ট ২০২৬ Glean:GO সম্মেলনে নতুন enterprise AI সক্ষমতা ঘোষণার সঙ্গে Claude Cowork-এর বিপরীতে নিজস্ব benchmark প্রকাশ করেছে। Compare the Cloud-এর প্রতিবেদনে নথিভুক্ত vendor-reported ফল অনুযায়ী, Glean-এর গড় খরচ ছিল প্রতি query-তে ০.৫৮ ডলার, Claude Cowork-এর ২.৯৮ ডলারের তুলনায় ৮১% কম; evaluators আবার ৭৮% ক্ষেত্রে Glean-এর response পছন্দ করেছেন।

এই সংখ্যাগুলো স্বাধীন পরীক্ষায় যাচাই করা ফল নয়। Glean-এর পরিচালিত ১৮০টির বেশি enterprise task-এর পরীক্ষায় auto routing-সহ Glean Assistant-এর পূর্ণ stack-কে Claude Sonnet 5 ও high reasoning-এ স্থির রাখা Claude Cowork stack-এর সঙ্গে তুলনা করা হয়েছে। তাই সরাসরি সিদ্ধান্তটি হলো: Glean তার নির্ধারিত setup-এ ৮১% কম token cost দাবি করেছে; সব প্রতিষ্ঠান, ভাষা বা workload-এ একই সাশ্রয় এখনো প্রমাণিত নয়।

৮১% খরচ ও ৭৮% preference কীভাবে এসেছে

Glean-এর প্রকাশিত methodology অনুযায়ী, ১৮০টির বেশি task-এ Glean Assistant-এর গড় খরচ ছিল ০.৫৮ ডলার এবং Claude Cowork-এর ২.৯৮ ডলার; একই side-by-side মূল্যায়নে পাঁচ-পয়েন্টের scale ব্যবহার করে ৭৮% ক্ষেত্রে Glean-এর response পছন্দ করা হয়েছে। এখানে ৮১% হলো প্রতি-task token cost-এর ব্যবধান, আর ৭৮% হলো response preference—দুটি আলাদা metric।

খরচের ব্যবধান কেবল token-এর unit price থেকে আসেনি। পরীক্ষায় Glean মোট ১৩ লাখ token এবং Cowork ৪৪ লাখ token ব্যবহার করেছে—প্রায় ৭০% পার্থক্য। এর সঙ্গে Glean-এর auto routing-এ নির্বাচিত বিভিন্ন model-এর blended price যুক্ত হয়ে প্রতি-task গড় খরচের ব্যবধান ৮১%-এ পৌঁছেছে। তাই ফলটিকে “৮১% কম token” বলা ভুল; নির্ভুল ভাষা হলো ৮১% কম token cost।

Preference মূল্যায়নে কোন response সরাসরি কাজে ব্যবহারযোগ্য, কোনটি বেশি সঠিক ও পূর্ণাঙ্গ এবং কোনটির জন্য কম steering, repair বা পুনরায় prompt প্রয়োজন—এসব দেখা হয়েছে। তবে প্রকাশিত methodology grader-এর সংখ্যা, graderদের পারস্পরিক সম্মতির হার, confidence interval বা প্রতিটি task বিভাগের sample size জানায় না। ফলে ৭৮% ফলটির statistical uncertainty স্বাধীনভাবে হিসাব করা যায় না।

এটি model বনাম model পরীক্ষা নয়

তুলনার দুই পাশে একই configuration ছিল না। Glean Assistant task-এর ধরন ও জটিলতা অনুযায়ী model এবং reasoning level বদলাতে পেরেছে। অন্যদিকে Claude Cowork পুরো পরীক্ষায় Claude Sonnet 5 ও high reasoning-এ স্থির ছিল। তাই benchmark থেকে কোনো একক Glean model, Claude Sonnet 5-এর চেয়ে ৮১% সস্তা—এমন সিদ্ধান্ত টানা যায় না।

দুই system-এর data-access ব্যবস্থাও এক ছিল না। Glean তার native ও MCP connector ব্যবহার করেছে। Cowork-এর জন্য Google Drive, Gmail, Google Calendar, Slack, Atlassian Rovo, Linear, Intercom ও Sigma-এর ready-made MCP connector এবং Salesforce, GitHub ও GCP-এর local MCP server বসানো হয়েছিল। ফলটি তাই model ছাড়াও retrieval, pre-indexed context, connector coverage, agent harness এবং routing-এর সম্মিলিত প্রভাব মাপে।

Enterprise ক্রেতার দৃষ্টিতে পূর্ণ stack-এর তুলনা অপ্রাসঙ্গিক নয়—বাস্তবে তারা model নয়, কাজ সম্পন্ন করার system কেনেন। কিন্তু এই নকশায় কোন উপাদান কতটা সাশ্রয় এনেছে তা আলাদা করা যায় না। একই model, connector ও retrieval layer রেখে routing চালু ও বন্ধ করে পরীক্ষা, অথবা প্রতিটি component বাদ দিয়ে পুনরায় চালানো ablation test ছাড়া কারণগুলো পৃথক করা সম্ভব নয়।

Task mix ফলটিকে কতটা বদলাতে পারে

Evalset-এ sales, engineering, marketing, HR ও people, product, finance এবং customer support ও success-এর কাজ রাখা হয়েছিল। Task-এর মধ্যে content drafting, source synthesis, data analysis, resource lookup, workflow automation এবং slide, spreadsheet বা HTML artifact তৈরি ছিল। বিভাগীয় subject-matter expertরা taskগুলো সংশ্লিষ্ট কাজের প্রতিনিধিত্ব করে কি না পর্যালোচনা করেছেন।

তবে এগুলো বাস্তব ব্যবহারকারীর সংরক্ষিত prompt ছিল না। গোপনীয়তার জন্য query synthetically তৈরি করে Glean-এর নিজস্ব production data-র ওপর চালানো হয়েছে; task নির্বাচন আবার বর্তমান Glean গ্রাহকদের ব্যবহার থেকে অনুপ্রাণিত। তাই বাংলা নথি, scanned PDF, স্থানীয় ERP, দীর্ঘ coding session বা কম connector-নির্ভর analysis-প্রধান কোনো প্রতিষ্ঠানের workload এই মিশ্রণের সঙ্গে নাও মিলতে পারে।

Task mix routing-এর সুবিধা সরাসরি বদলায়। সহজ কাজ বেশি থাকলে সেগুলো সস্তা model ও নিম্ন reasoning level-এ পাঠিয়ে blended cost কমানো সম্ভব। অধিকাংশ কাজ frontier model-এর উচ্চ reasoning দাবি করলে একই ব্যবধান ধরে থাকার নিশ্চয়তা নেই। প্রকাশিত aggregate average বিভাগ বা task type বদলালে খরচ কতটা ওঠানামা করে, সেই sensitivity দেখায় না।

ক্রেতার নিজস্ব pilot-এ প্রয়োজনীয় evidence

Benchmark-টি procurement hypothesis হিসেবে কাজে লাগতে পারে, কিন্তু সরাসরি budget forecast হিসেবে নয়। Reworked-এর স্বাধীন প্রতিবেদনে ফলটিকে Glean-এর argument-এর উদাহরণ বলা হয়েছে, স্বাধীন validation নয়; একই প্রতিবেদনে auto routing-কে beta এবং Glean Tau-কে “coming soon” হিসেবে বর্ণনা করা হয়েছে।

বাংলাদেশ বা বাংলা ভাষাভাষী ভারতের কোনো enterprise pilot-এ headline দাবিটি যাচাই করতে হলে তুলনার ভিত্তি এক রাখতে হবে:

• একই production-representative task set, একই নথির snapshot এবং উভয় system-এর সমতুল্য permission ও connector coverage;
• প্রতি task-এর input, output, cached ও reasoning token, নির্বাচিত model এবং বাস্তবে প্রযোজ্য billed rate;
• বিভাগ ও task type অনুযায়ী খরচ, completion rate, latency, retry এবং human correction time—শুধু সামগ্রিক average নয়;
• system-এর পরিচয় গোপন রেখে একাধিক domain expert-এর preference score, disagreement এবং ব্যর্থ task-এর হিসাব।

Routing log বিশেষভাবে গুরুত্বপূর্ণ। কত শতাংশ task কোন model ও reasoning level-এ গেছে তা না জানলে ফল পুনরুৎপাদন করা বা model-এর মূল্য বদলালে ভবিষ্যৎ খরচ অনুমান করা কঠিন। একইভাবে, সস্তা প্রথম response-এর পরে correction কিংবা দ্বিতীয় run প্রয়োজন হলে সেই খরচও পূর্ণ workflow cost-এ যোগ করতে হবে।

এখন নিশ্চিত তথ্য হলো, ২৬ আগস্ট Glean নিজস্ব ১৮০টির বেশি task-এর পরীক্ষার ফল প্রকাশ করে ৮১% কম token cost ও ৭৮% preference দাবি করেছে। প্রকাশিত নকশা একই model configuration-এর তুলনা নয় এবং কোনো স্বাধীন দল একই task ও setup-এ ফল পুনরাবৃত্তি করেছে—এমন evidence এখনো নেই। ফলে benchmark-টি routing ও pre-indexed enterprise context-এর সম্ভাব্য অর্থনৈতিক মূল্য দেখায়, সর্বজনীন cost guarantee নয়।