Agent API-এর প্রতিটি এফোর্ট লেভেলে উন্নতি

Perplexity Agent API-এর এফোর্ট লেভেলগুলো ডেভেলপারদের প্রতিটি টাস্কের জন্য খরচ, গতি ও গবেষণার গভীরতার ভারসাম্য বেছে নিতে দেয়। আজ থেকে প্রতিটি এফোর্ট লেভেলে প্রতি কোয়েরির খরচ কম, আর গবেষণার মান আগের চেয়ে বেশি বা অপরিবর্তিত। সবচেয়ে বিস্তৃত ও পূর্ণাঙ্গ গবেষণার জন্য নতুন ultra লেভেল এখন উপলভ্য। যেকোনো অনুরোধ নাম দিয়ে লেভেল নির্বাচন করলে, যেমন effort="fast", স্বয়ংক্রিয়ভাবে হালনাগাদ কনফিগারেশন পায়।

একটি গবেষণা এজেন্ট তৈরি করা মানে প্রতিটি টাস্কের জন্য খরচ, গতি ও গভীরতার সঠিক ভারসাম্য বেছে নেওয়া। Agent API-এর এফোর্ট লেভেলগুলো ব্যবহারকারীর হয়ে এই সিদ্ধান্ত নেয়। প্রতিটি লেভেল একটি সমন্বিত কনফিগারেশন, যা নির্দিষ্ট ধরনের টাস্কের জন্য মডেল, ধাপের বাজেট, সার্চ সেটিংস ও টুল নির্ধারণ করে। Perplexity প্রতিটি লেভেলকে সময়ের সঙ্গে মূল্যায়ন ও হালনাগাদ করে, যাতে বর্তমান খরচে বা তার চেয়ে কম খরচে সেরা গবেষণা দেওয়া যায়।

এই উন্নতিগুলো এসেছে দুই ধরনের পরিবর্তন থেকে। বাজেট, কনটেক্সট ব্যবস্থাপনা ও এক্সট্র্যাকশন প্রতিটি রানের খরচ কমিয়েছে, আর দক্ষতা, মডেল নির্বাচন ও সমান্তরাল এজেন্ট উত্তরের মান বাড়িয়েছে বা বজায় রেখেছে।

BrowseComp ও DSQA-তে medium-এর পারফরম্যান্স ৫৫% থেকে বেড়ে ৭৭% হয়েছে, আর খরচ কমেছে প্রায় ৯০%। BrowseComp ও DSQA হলো পাবলিক গবেষণা বেঞ্চমার্ক; WANDR হলো দীর্ঘ, একাধিক সত্তা-সংক্রান্ত গবেষণা টাস্কের জন্য Perplexity-র নিজস্ব বেঞ্চমার্ক। xhigh এজেন্টিক কাজ করে, যেমন স্যান্ডবক্সে কোড চালানো, দীর্ঘ টুল-ব্যবহারের লুপ বজায় রাখা এবং একসঙ্গে অনেক উৎস নিয়ে কাজ করা। আগস্ট ২০২৬-এর কনফিগারেশনের খরচের প্রায় ২৫%-এ চলেও xhigh তার WANDR স্কোর ৭৬.৫%-এ ধরে রেখেছে।

একটি গভীর গবেষণা অনুরোধ উত্তর দেওয়ার আগে কয়েক ডজন সার্চ চালাতে, শত শত পৃষ্ঠা পড়তে এবং প্রমাণ যাচাই করতে পারে। এসব কাজের প্রতিটি কনটেক্সটে টোকেন এবং বিলে ডলার যোগ করে। সীমা না থাকলে এজেন্ট এমন সব কাজ করতে থাকে, যা উত্তরের মান না বাড়িয়েই খরচ বাড়ায় এবং কনটেক্সট ভারী করে তোলে। এই খরচের বেশির ভাগের পেছনে রয়েছে পাঁচটি বিষয়:

বাজেট বরাদ্দ। নির্ধারিত বাজেটের এজেন্টদের ধাপ ফুরিয়ে যেতে পারে এবং টাস্ক চূড়ান্ত করার আগেই রান আগেভাগে শেষ হয়ে যেতে পারে। অন্যদিকে, নির্দিষ্ট বাজেট ছাড়া এজেন্টরা চূড়ান্ত উত্তরের মান না বাড়িয়েই খরচ বাড়িয়ে চলতে থাকতে পারে।
কনটেক্সটের অতিরিক্ত ভার। সার্চ ফলাফল ও ফেচ করা পৃষ্ঠাগুলো প্রমাণ বহন করে, কিন্তু নিয়ন্ত্রণ না করলে কনটেক্সট উইন্ডো দ্রুত অপ্রাসঙ্গিক তথ্যে ভরে যেতে পারে। কনটেক্সট উইন্ডোর খরচ এক ধাপ থেকে আরেক ধাপে বয়ে চলে, এবং অতিরিক্ত ভারী উইন্ডো এজেন্টের পারফরম্যান্স কমিয়ে দিতে পারে।
ওয়ার্কফ্লো নির্বাচন। ভিন্ন ভিন্ন টাস্কের জন্য ভিন্ন পদ্ধতি দরকার। একটি তথ্য খোঁজা, একাধিক ধাপের (মাল্টি-হপ) প্রশ্ন এবং বহু উৎসের বিস্তৃত জরিপ—প্রতিটির জন্য আলাদা ওয়ার্কফ্লো প্রয়োজন। নিজের ওপর ছেড়ে দিলে মডেল প্রায়ই একটি কম কার্যকর ওয়ার্কফ্লো বেছে নেয়। এজেন্টের প্রম্পটে প্রতিটি উপলভ্য কৌশল বিস্তারিত লিখে দিলেও এ সমস্যার সমাধান হয় না। অতিরিক্ত নির্দেশনাগুলো প্রতিটি ধাপে টোকেন হিসেবে বহন করতে হয়, এবং সময়ের সঙ্গে মডেল প্রতিটি নির্দেশনা কম নির্ভরযোগ্যভাবে অনুসরণ করে।
মডেল নির্বাচন। বড় মডেলে বদল করলেই অতিরিক্ত খরচের সমানুপাতিক উন্নত পারফরম্যান্স না-ও মিলতে পারে। নতুন মডেলগুলো আসে আলোচিত শিরোনাম ও প্রকাশিত বেঞ্চমার্ক স্কোর নিয়ে। তবে বেঞ্চমার্কের উন্নতি ডেটা দূষণে প্রভাবিত হতে পারে বা মডেলের ওভারফিটিং প্রতিফলিত করতে পারে। বাস্তব টাস্কে মূল্যায়ন ছাড়া মডেল বদল করলে মান না বাড়িয়েই খরচ বাড়তে পারে।
মাল্টি-এজেন্ট স্কেলিং। একটি এজেন্ট প্রতি রানে সীমিত সংখ্যক উৎস সার্চ করতে, পড়তে ও বিশ্লেষণ করতে পারে। একাধিক এজেন্ট সমান্তরালে চালালে সবচেয়ে কঠিন টাস্কগুলোতে মান বাড়ে, তবে খরচও বাড়ে এবং সঠিকভাবে পরিচালনা না করলে জটিলতা তৈরি হয়।

এসব চ্যালেঞ্জের প্রতিটি সমাধান করে পারফরম্যান্স না কমিয়েই প্রতিটি এফোর্ট লেভেলের খরচ কমানো গেছে।

প্রতিটি এফোর্ট লেভেলের একটি নির্দিষ্ট গবেষণা বাজেট আছে, যার তিনটি উপাদান:

ধাপের সীমা: এজেন্ট কতগুলো টার্ন নিতে পারবে তার সংখ্যা
টুল কল: একটি অনুরোধে মোট টুল কলের সংখ্যার ঊর্ধ্বসীমা। একটি ধাপেই একসঙ্গে একাধিক টুলে একাধিক কল করা যায়, তাই শুধু ধাপের সীমা দিয়ে একটি ধাপের মধ্যে কতগুলো কাজ হবে তা নিয়ন্ত্রণ করা যায় না।
বাজেট রিমাইন্ডার: কত ধাপ বাকি আছে সে সম্পর্কে নিয়মিত বিজ্ঞপ্তি, যাতে এজেন্ট অগ্রাধিকার ঠিক করতে পারে এবং টাস্কের মাঝপথে বাজেট ফুরিয়ে না ফেলে উত্তর লেখার জন্য জায়গা রাখতে পারে।

বাজেটই মূল ট্রেডঅফ: বেশি ধাপ মানে ভালো উত্তর, আর প্রতিটি ধাপেই খরচ হয়। openai/gpt-6-luna-এর ক্ষেত্রে ধাপের সীমা ১ থেকে ১৫-তে বাড়ালে BrowseComp + DSQA-তে নির্ভুলতা ৪১% থেকে ৮০%-এ ওঠে, আর প্রতি কোয়েরির খরচ ০.০০১৭ ডলার থেকে বেড়ে ০.০১৫২ ডলার হয়—অর্থাৎ প্রায় ২ গুণ স্কোরের জন্য প্রায় ৯ গুণ খরচ।

শুধু ধাপের সীমা দিয়ে গবেষণার খরচ নিয়ন্ত্রণ করা যায় না। একই পাঁচ ধাপের বাজেটে openai/gpt-6.1-terra openai/gpt-6-luna-এর চেয়ে বেশি টুল কল করে, কারণ বেশি সক্ষম মডেলগুলো একটি ধাপেই একাধিক কল করার প্রবণতা রাখে। এফোর্ট লেভেলগুলো টুল কল ও ধাপ—দুটোরই ঊর্ধ্বসীমা নির্ধারণ করে। এই মডেলগুলোর ক্ষেত্রে টুল-কলের ঊর্ধ্বসীমা ধাপের সীমার মতোই গুরুত্বপূর্ণ।

প্রতিটি এফোর্ট লেভেল এই সীমাগুলো সমন্বয় করে, তবে অনুরোধটি পূরণ করতে এজেন্টকেও জানতে হয় তার হাতে আর কত ধাপ ও কাজ বাকি আছে। এই তথ্য না থাকলে এজেন্টের ধাপ বা কাজ ফুরিয়ে যেতে পারে, ফলে গবেষণা শেষ হওয়ার আগেই তাকে উত্তর দিতে বাধ্য হতে হয়। রানের শুরুতেই বাজেট জানিয়ে দেওয়া হয়, এবং এজেন্ট সীমার কাছাকাছি পৌঁছালে রিমাইন্ডার আসে, যাতে ফলাফল যাচাই ও উপস্থাপনের সুযোগ থাকে। high-এর ক্ষেত্রে রিমাইন্ডারগুলো ধাপের বাজেট ও টুল-কলের বাজেট—দুটোই কভার করে।

বাজেট রিমাইন্ডারসহ একটি এবং রিমাইন্ডার ছাড়া একটি—এই দুটি এজেন্টকে একটি BrowseComp টাস্কে পরীক্ষা করা হয়েছিল, যেখানে তিনজন অভিনয়শিল্পীর জীবনী দেখে ১৯৯০-এর দশকের একটি টিভি সিরিজ শনাক্ত করতে হতো। রিমাইন্ডারসহ এজেন্টটি বাজেটের ৪০টি ধাপের মধ্যে ১৩টি ব্যবহার করে সঠিক উত্তর খুঁজে পেয়েছে। বাজেট রিমাইন্ডার ছাড়া এজেন্টটি ৪০টি ধাপই ব্যবহার করেছে এবং সঠিক উত্তর খুঁজে পায়নি। সেই এজেন্টের লুপ অপ্রত্যাশিতভাবে শেষ হয়ে যায়, এবং মডেলটি অবশিষ্ট গবেষণা বাজেট সম্পর্কে অবগত ছিল না। রিমাইন্ডার এজেন্টদের মনোযোগ ধরে রাখে এবং অবশিষ্ট রিসোর্স কার্যকরভাবে অগ্রাধিকার দিয়ে ব্যবহার করতে সাহায্য করে।

দীর্ঘ সময় ধরে চলা গবেষণা টাস্ক মডেলের কনটেক্সট উইন্ডোকে সার্চ ফলাফল, ফেচ করা পৃষ্ঠা ও মধ্যবর্তী নোটে ভরিয়ে ফেলে। উইন্ডো পূর্ণ হয়ে গেলে এজেন্টকে কাজ থামাতে হয়।

কমপ্যাকশন কনটেক্সট উইন্ডো পূর্ণ না করেই দীর্ঘ রানগুলো সচল রাখে। কনটেক্সট একটি নির্দিষ্ট সীমা ছাড়িয়ে গেলে এজেন্ট এ পর্যন্ত করা কাজের জায়গায় একটি সংক্ষিপ্ত সারাংশ বসায়—কী পাওয়া গেছে এবং কী বাকি আছে—তারপর কাজ চালিয়ে যায়।

কমপ্যাকশন সবসময় কনটেক্সটে তিনটি জিনিস রেখে দেয়: সিস্টেম প্রম্পট, মূল অনুরোধ এবং এজেন্ট ইতিমধ্যে লোড করেছে এমন যেকোনো দক্ষতা। প্রতিটি কমপ্যাকশনের পর এজেন্ট দুটি সংক্ষিপ্ত নির্দেশনা পায়। প্রথম নির্দেশনাটি হলো, ‘টাস্ক শেষ না হওয়া পর্যন্ত কাজ চালিয়ে যাও।’ এর ফলে এজেন্ট সারাংশটিকে থামার জায়গা হিসেবে ধরে নেয় না। দ্বিতীয় নির্দেশনাটি এজেন্টকে জানায় এ পর্যন্ত কতবার কমপ্যাকশন হয়েছে, যাতে সে অবশিষ্ট গবেষণা টাস্কগুলোর পরিকল্পনা করতে পারে। দীর্ঘ রানেও মূল লক্ষ্য ও পরিকল্পনা চোখের সামনে থাকে, আর মান না কমিয়েই দীর্ঘ লুপের খরচ কমে।

এজেন্ট যে প্রতিটি পৃষ্ঠা পড়ে, তা তার কনটেক্সটে যুক্ত হয় এবং পরবর্তী প্রতিটি ধাপে এজেন্টকে তা বহন করতে হয়। একটি ওয়েব পৃষ্ঠায় প্রশ্নের সঙ্গে সম্পর্কহীন তথ্যও থাকে, যেমন নেভিগেশন, বয়লারপ্লেট এবং অন্যান্য কনটেন্ট।

এজেন্টকে পুরো পৃষ্ঠা দেওয়ার বদলে fetch_url প্রথমে একটি এক্সট্র্যাকশন ধাপ চালায়। পৃষ্ঠার টেক্সট এজেন্টের বর্তমান টাস্কসহ একটি ছোট মডেলে পাঠানো হয়। মডেলটি শুধু প্রাসঙ্গিক অংশগুলো হুবহু উদ্ধৃত করে ফেরত দেয়, যাতে এজেন্ট সেগুলোকে সূত্র হিসেবে উল্লেখ করতে পারে। একটি মূল্যায়নের সময় ৫,৫৬১ টোকেনের একটি পৃষ্ঠা কমে ২৯৩ টোকেনে দাঁড়ায়, ফলে আরও প্রাসঙ্গিক কনটেক্সটের জন্য জায়গা খালি হয়।

fetch_url টুলে এক্সট্র্যাকশন ব্যবহার করে high এফোর্ট লেভেলে প্রতি কোয়েরিতে ইনপুট টোকেন প্রায় ৫০% কমেছে। এক্সট্র্যাকশন বেঞ্চমার্ক পারফরম্যান্সও উন্নত করেছে: প্রতি কোয়েরিতে ০.০৭৩ ডলার খরচে ৮৮.০% অর্জিত হয়েছে, যেখানে এক্সট্র্যাকশন ছাড়া প্রতি কোয়েরিতে ০.০৯৪ ডলারে তা ছিল ৮৩.৫%।

প্রতিটি এজেন্ট গবেষণা অনুরোধের কেন্দ্রে রয়েছে ওয়েব সার্চ। এজেন্টরা কীভাবে সার্চ করে, তাতে তিনটি পরিবর্তন আনা হয়েছে:

প্রতি সার্চে আরও বেশি কনটেক্সট: প্রতিটি সার্চ এখন ২ হাজারের বদলে সর্বোচ্চ ৪ হাজার টোকেনের ফলাফল দেয়। এজেন্ট যা প্রয়োজন তা আরও দ্রুত খুঁজে পায়, ফলে সার্চের সংখ্যা ও খরচ দুটোই কমে।

নতুন স্নিপেট ইঞ্জিন: সার্চ ফলাফলে এখন কোয়েরির সঙ্গে আরও ভালোভাবে মেলে এমন স্নিপেট থাকে, ফলে অপ্রাসঙ্গিক টেক্সট এজেন্টের ওপর অতিরিক্ত বোঝা হয়ে ওঠে না।
Fast Search: প্রতি ১ হাজার অনুরোধে ১.০০ ডলারে Fast Search প্রতিটি সার্চ কলের খরচ ও লেটেন্সি দুটোই কমায়।

Perplexity Search টিম বিভিন্ন ধরনের টাস্কে রিট্রিভালের মান নিরবচ্ছিন্নভাবে উন্নত করে চলেছে। সাম্প্রতিক হালনাগাদগুলো কোড, ডেভেলপার ডকুমেন্টেশন, রেফারেন্স পৃষ্ঠা, আইনি ও নিয়ন্ত্রক কনটেন্টে উন্নতি এনেছে।

কিছু টাস্কে অনেকগুলো সার্চ সমান্তরালে চালাতে হয়; অন্যগুলোতে কয়েকটি দীর্ঘ ডকুমেন্ট মনোযোগ দিয়ে পড়তে হয়।

তবে প্রতিটি ওয়ার্কফ্লো এজেন্টের সিস্টেম প্রম্পটে লোড করলে কনটেক্সটের ভার বাড়ে এবং সহজ টাস্কে মডেলের পারফরম্যান্স কমে যেতে পারে। তাই দক্ষতাগুলোকে ধাপে ধাপে প্রকাশ (progressive disclosure) পদ্ধতিতে একটি ট্রি কাঠামোয় সাজানো হয়েছে। মডেল কাজ করার সময় প্রাসঙ্গিক দক্ষতা ও নির্দেশনা লোড করে, আর সম্পর্কহীন তথ্য কনটেক্সটের বাইরে রাখে। মডেল যতক্ষণ না সিদ্ধান্ত নেয় যে কোনো দক্ষতা টাস্কের সঙ্গে মানানসই এবং সেটি লোড করে, ততক্ষণ প্রতিটি দক্ষতার খরচ কেবল তার নাম ও বিবরণ; লোড করার পর পূর্ণ নির্দেশনা কনটেক্সটে যুক্ত হয় এবং মডেল নির্ধারিত ওয়ার্কফ্লো অনুসরণ করে।

প্রতিটি দক্ষতা কতটা অবদান রাখে তা পরিমাপ করতে একবারে একটি করে দক্ষতা সরিয়ে সেই টাস্কগুলোতে মান ও খরচ তুলনা করা হয়, যেখানে বেসলাইন এজেন্ট সংশ্লিষ্ট দক্ষতাটি লোড করেছিল। এই অ্যাবলেশনগুলো দেখায় কোন ওয়ার্কফ্লো এজেন্টকে সাহায্য করে এবং সেগুলো গবেষণার কার্যকারিতায় কী প্রভাব ফেলে।

নিচের WANDR বেঞ্চমার্ক রানগুলো দেখায়, এজেন্টরা নির্দিষ্ট টাস্কের জন্য সঠিক ওয়ার্কফ্লো বেছে নিচ্ছে। একাধিক সত্তা অনুসন্ধানের প্রয়োজনীয়তার কারণে প্রতিটি টাস্কেই wide-search ও fanout নির্দেশিকা লোড হয়েছে। people-search লোড হয়েছে মাত্র ৬% টাস্কে, এবং কেবল তখনই, যখন প্রশ্নে মানুষ জড়িত ছিল।

আরেকটি WANDR টাস্ক পরীক্ষার সময় লন্ডনে ইনফারেন্স ইঞ্জিনিয়ার খুঁজতে এজেন্ট fanout প্যাটার্নসহ people-search দক্ষতাটি লোড করেছিল। এটি ৩৯টি পদের নামকে ১১৭টি কোয়েরিতে বিস্তৃত করে, তারপর প্রথম ধাপের ফলাফল একত্র করে আরও স্ক্রিনিংয়ের জন্য ৪৩টি অনন্য প্রোফাইল তৈরি করে। people-search দক্ষতাটি অপ্রাসঙ্গিক কনটেক্সট যোগ না করেই এই বিস্তারের প্রক্রিয়ায় এজেন্টকে পথ দেখিয়েছে। নিচের অংশটি এজেন্টের স্ক্রিপ্ট থেকে অভিযোজিত; হেল্পারের নামগুলো উদাহরণস্বরূপ।

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

চেকপয়েন্টিং আরেকটি ওয়ার্কফ্লো, যা দীর্ঘ সময় ধরে চলা টাস্কে এজেন্টদের সাহায্য করে। চেকপয়েন্টিং প্যাটার্নটি এসেছে ব্যাচ প্রোগ্রামিং থেকে। কোনো স্ক্রিপ্ট যখন একটি দীর্ঘ তালিকা প্রসেস করে, তখন শেষ পর্যন্ত সবকিছু মেমরিতে ধরে না রেখে প্রতিটি ফলাফল পাওয়ামাত্র ডিস্কে লিখে রাখে। স্ক্রিপ্টটি মাঝপথে ক্র্যাশ করলে বা ত্রুটির মুখে পড়লেও কিছুই হারায় না: পরের রান আগে থেকে সংরক্ষিত অংশ পড়ে যেখানে থেমেছিল সেখান থেকে কাজ চালিয়ে যায়, এবং শুধু ব্যর্থ আইটেমগুলো আবার চেষ্টা করে।

আরেকটি WANDR টাস্কে এজেন্টকে ১৮৮ জন ইঞ্জিনিয়ারের প্রোফাইল স্ক্রিন করতে হয়েছিল। কাজ চলাকালে প্রতিটি ফলাফল রেকর্ড করতে এটি চেকপয়েন্ট প্যাটার্ন লোড করে। প্রথম ধাপে ১৬০টি প্রোফাইল এক্সট্র্যাক্ট হলেও ২৮টিতে ব্যর্থ হয়। এজেন্ট স্ক্রিপ্টটি আবার চালালে আগে রেকর্ড হওয়া প্রোফাইলগুলো বাদ দিয়ে কেবল বাকি ২৮টি আবার চেষ্টা করে। চেকপয়েন্ট না থাকলে একটি খারাপ রেকর্ডের কারণেই ১৮৮টি প্রোফাইল আবার ফেচ করতে হতো।অভিযোজিত Python অংশ; ইনপুট পৃষ্ঠা, স্ক্রিনিং নির্দেশনা, স্কিমা ও ইমপোর্ট বাদ দেওয়া হয়েছে; হেল্পারের নামগুলো উদাহরণস্বরূপ।

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

চেকপয়েন্ট সফল ফলাফলগুলো রেকর্ড করে; এটি নিজে থেকে পুনরায় চেষ্টা শুরু করে না। কী-তে নির্দেশনা ও স্কিমা অন্তর্ভুক্ত থাকায় স্ক্রিনিংয়ের মানদণ্ড বদলালে পুনরায় প্রক্রিয়াকরণ শুরু হয়।

প্রতিটি পরীক্ষায় মান ও কার্যকারিতা বাড়েনি। টাস্ক শুরুর আগেই এজেন্টে সব দক্ষতা আগে থেকে লোড করার বিষয়টি মূল্যায়ন করা হয়েছিল। BrowseComp ও DSQA-তে আগে থেকে লোড করায় খরচ ১৩% বেড়েছে। WANDR-এ, যেখানে দীর্ঘ গবেষণা ট্র্যাজেক্টরির কারণে সংগৃহীত কনটেন্ট ইনপুট টোকেনের বড় অংশ হয়ে ওঠে, আগে থেকে লোড করায় স্কোরও কমে যায়। এই ফলাফলগুলো ধাপে ধাপে প্রকাশ (progressive disclosure) পদ্ধতি বজায় রাখার পক্ষে সমর্থন জুগিয়েছে।

মডেলের সক্ষমতা যত এগোয়, প্রতিটি এফোর্ট লেভেলের জন্য সেরা মডেলও তত বদলায়। Perplexity একটি স্বয়ংক্রিয় গবেষণা লুপ ব্যবহার করে, যা নতুন মডেলের ঘোষণা ও প্রাপ্যতা পর্যবেক্ষণ করে। কোনো মডেল ব্যবহারযোগ্য হওয়ামাত্র মূল্যায়ন শুরু হয়।

কোনো নতুন মডেল প্রকাশিত হলে একটি স্বয়ংক্রিয় এজেন্ট সেটিকে মূল্যায়ন harness-এর মধ্য দিয়ে পরীক্ষা করে। এটি রিজনিং এফোর্ট, ধাপ ও টুল-কলের বাজেট এবং টুল কনফিগারেশনের বিভিন্ন মান যাচাই করে দেখে, এবং প্রতিটি রানকে বর্তমান এফোর্ট লেভেলগুলোর তুলনায় মান ও খরচের ভিত্তিতে স্কোর দেয়। কোনো রানে ফল খারাপ হলে এজেন্ট কারণ খুঁজে বের করে, সেটিংস সমন্বয় করে এবং আবার মূল্যায়ন চালায়। কোনো প্রার্থী মডেল কেবল তখনই বর্তমান মডেলের জায়গা নেয়, যখন সেটি একই বা কম খরচে মানের দিক থেকে এগিয়ে থাকে।

পাবলিক বেঞ্চমার্ক উপযোগী, তবে সেগুলোর স্কোর সবসময় বাস্তব জগতের টাস্কে প্রতিফলিত হয় না। যেমন, নিচের চার্টে একটি প্রার্থী মডেল দেখানো হয়েছে, যা BrowseComp-এ বেসলাইনের চেয়ে ১৩.৩ পয়েন্ট বেশি স্কোর করেছে, কিন্তু অভ্যন্তরীণ এন্টারপ্রাইজ, আইনি ও আর্থিক গবেষণা টাস্কে সংশ্লিষ্ট বেসলাইনের চেয়ে অনেক পিছিয়ে ছিল।

একটি এজেন্ট এক লুপে নির্দিষ্ট সংখ্যক উৎসই কভার করতে পারে। জটিল টাস্কের ক্ষেত্রে কয়েকটি এজেন্ট সমান্তরালে কাজ করে, প্রত্যেকে সমস্যার ভিন্ন একটি অংশ নিয়ে সমন্বয় করে।

প্রধান এজেন্ট হলো অর্কেস্ট্রেটর। এটি চাইল্ড এজেন্ট তৈরি করতে spawn_agent কল করে এবং প্রত্যেককে একটি নির্দিষ্ট, কেন্দ্রীভূত টাস্ক দেয়। প্রতিটি চাইল্ড আলাদা কনটেক্সটে নিজস্ব মডেল, টুল ও ধাপের বাজেট ব্যবহার করে নিজের গবেষণা লুপ চালায়। চাইল্ডরা তাদের ফলাফল প্যারেন্টকে জানায়, আর প্যারেন্ট কোনো চাইল্ডকে পরবর্তী দায়িত্ব দিতে পারে বা তার অগ্রগতি দেখে নিতে পারে। অর্কেস্ট্রেটর ও তার চাইল্ডরা প্রমাণ ভাগ করতে, বাধা চিহ্নিত করতে এবং পরবর্তী পদক্ষেপ ঠিক করতে পরস্পরের সঙ্গে বার্তা আদান-প্রদান করে। নতুন তথ্য আসার সঙ্গে সঙ্গে অর্কেস্ট্রেটর দায়িত্বগুলো আরও সুনির্দিষ্ট করে, এবং কাজ শেষ হলে ফলাফলগুলো একত্র করে একটি উত্তর তৈরি করে।

Agent API পূর্বনির্ধারিত এজেন্ট রোল সমর্থন করে, এবং অর্কেস্ট্রেটর কাস্টম নির্দেশনাসহ চাইল্ড এজেন্ট তৈরি করতে পারে।

ultra এফোর্ট লেভেল একটি টাস্কে সমান্তরালে তিনটি এজেন্ট চালায়। প্রতিটি এজেন্ট স্বাধীনভাবে পুরো টাস্কটি গবেষণা করে, ফলে ভিন্ন ভিন্ন প্রমাণ পাওয়া যায়। চতুর্থ একটি এজেন্ট তাদের ফলাফল একত্র করে, পুনরাবৃত্তি বাদ দেয় এবং চূড়ান্ত উত্তর লেখে।

WANDR-এ ultra প্রতি টাস্কে ২১.৭১ ডলার খরচে ৮৫.৯% স্কোর করে। পরীক্ষিত কনফিগারেশনগুলোর মধ্যে এটিই সর্বোচ্চ স্কোর।

এফোর্ট লেভেলগুলো নিরবচ্ছিন্নভাবে মূল্যায়ন ও উন্নত করা হয়। ব্যবহারকারী যে লেভেল বেছে নেন, তা নির্ধারণ করে একটি টাস্কে কতটা গবেষণা হবে এবং কত খরচ হবে। ধাপ ও টুল-কলের বাজেট, এবং সেগুলো ফুরিয়ে আসার সময় রিমাইন্ডার, অনুরোধগুলোকে বাজেটের মধ্যে রাখে। কমপ্যাকশন, এক্সট্র্যাকশন ও উন্নত স্নিপেট কনটেক্সটকে প্রমাণের ওপর কেন্দ্রীভূত রাখে। দক্ষতাগুলো টাস্ক অনুযায়ী ওয়ার্কফ্লো মিলিয়ে দেয়, আর সমান্তরাল এজেন্টরা একটি লুপের নাগালের বাইরেও কাজ বিস্তৃত করে। একটি স্বয়ংক্রিয় মূল্যায়ন লুপ কোনো নতুন মডেলকে কেবল তখনই গ্রহণ করে, যখন সেটি একই খরচে গবেষণার মান উন্নত করে।

মূল্যায়নে নতুন মডেল ও কনফিগারেশন নিজেদের প্রমাণ করার সঙ্গে সঙ্গে প্রতিটি এফোর্ট লেভেল বিকশিত হতে থাকবে। নাম দিয়ে কোনো লেভেল কল করলে সেই উন্নতিগুলো স্বয়ংক্রিয়ভাবে যুক্ত হয়; কোনো ভার্সন পিন করলে কনফিগারেশন অপরিবর্তিত থাকে।

Agent API ব্যবহার করে দেখুন এবং নিজের ওয়ার্কলোডে এফোর্ট লেভেলগুলো তুলনা করুন। এফোর্ট লেভেলের বিস্তারিত পাবেন আমাদের Agent API এফোর্ট ডকুমেন্টেশনে।

গবেষণার খরচ

গবেষণা বাজেট নিয়ন্ত্রণ

কনটেক্সট ব্যবস্থাপনা

কমপ্যাকশন

শুধু যা দরকার, তা-ই ফেচ করা

কেন্দ্রীভূত ওয়েব সার্চ

সঠিক ওয়ার্কফ্লো নির্বাচন

মডেল নির্বাচন

মাল্টি-এজেন্ট স্কেলিং

এরপর কী