Perplexity Decider

আমরা Decider v1.3 ও Decider Flash v1.3 প্রকাশ করছি, যেগুলো আমাদের আগের সিদ্ধান্ত মডেল v1, v1.1, v1.2 ও Flash v1.2-এর উত্তরসূরি।

Decider Flash v1.3 হলো Decider v1.3 থেকে ডিস্টিল করা একটি ছোট মডেল। দুটি মডেলই Apache লাইসেন্সের অধীনে Hugging Face-এ, OpenRouter-এর মাধ্যমে এবং Perplexity Decisions API-তে পাওয়া যাচ্ছে।

Perplexity Decider অনুপ্রাণিত হয়েছে TypeSafe AI-এর System One Model Jev থেকে। এটি ক্রমযুক্ত বা ক্রমহীন লেবেলসহ বাইনারি ও মাল্টি-ক্লাস শ্রেণিবিন্যাস সমর্থন করে এবং এমন সম্ভাবনা ফেরত দেয়, যা অ্যাপ্লিকেশনগুলো ইনপুট শ্রেণিবদ্ধ, রাউট, র‍্যাংক ও মূল্যায়ন করতে ব্যবহার করতে পারে।

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

এই পোস্টে আমরা ব্যাখ্যা করছি কীভাবে Decider-কে ট্রেনিং দিই ও মূল্যায়ন করি, এবং Perplexity-তে অভ্যন্তরীণভাবে এটি কীভাবে ব্যবহার করি তা তুলে ধরছি।

সিদ্ধান্ত মডেল কী?

সিদ্ধান্ত মডেল হলো একটি সাধারণ-উদ্দেশ্য ক্লাসিফায়ার। আপনি এটিকে একটি ইনপুট এবং একগুচ্ছ প্রশ্ন দেন, যার প্রতিটির সঙ্গে সম্ভাব্য উত্তরগুলো থাকে। প্রতিটি প্রশ্নের জন্য এটি উত্তরগুলোর ওপর একটি সম্ভাবনা বণ্টন ফেরত দেয়। এটি ৩ ধরনের প্রশ্ন সমর্থন করে:

• হ্যাঁ / না: বাইনারি সিদ্ধান্ত।
• বহুনির্বাচনী: কাস্টম মাল্টি-ক্লাস লেবেল।
• স্কোর: ক্রমানুসারে সাজানো স্তর।

সিদ্ধান্ত মডেল বিস্তৃত পরিসরের শ্রেণিবিন্যাস ও স্কোরিং কাজ সমর্থন করে:

• আউটপুট বিচার: বিশ্বস্ততা, মান ও নিরাপত্তা মূল্যায়ন করা।
• রাউটিং: কাঠিন্য অনুযায়ী অনুরোধগুলোকে ছোট বা বড় মডেলে পাঠানো।
• মডারেশন ও নিরাপত্তা: টুল আউটপুটে ক্ষতিকর কনটেন্ট, ফিশিং ও প্রম্পট ইনজেকশন শনাক্ত করা।
• ফিল্টারিং ও ট্যাগিং: বিপুল পরিমাণ কনটেন্ট সংগঠিত করা।
• রিট্রিভাল ও রির‍্যাংকিং: প্রাসঙ্গিকতা অনুযায়ী সার্চ ফলাফল স্কোর করা।

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

ট্রেনিং

জেনারেটিভ LLM-কে সিদ্ধান্ত মডেলে রূপান্তর

আমরা শক্তিশালী জেনারেটিভ LLM ব্যাকবোন অভিযোজিত করে Decider তৈরি করি। এই অভিযোজন ব্যাখ্যা করতে প্রথমে আমরা বর্ণনা করছি একটি অনুরোধ কীভাবে উপস্থাপিত হয়। নিচে যেমন দেখানো হয়েছে, একটি অনুরোধে থাকে একটি শেয়ার করা কনটেক্সট (স্টেট) এবং কয়েকটি প্রশ্ন। সব প্রশ্নই স্টেটটি পুনরায় ব্যবহার করবে।

যেমন, একটি ডকুমেন্ট ও তার সারাংশ দেওয়া থাকলে একটি অনুরোধেই জানতে চাওয়া যায় সারাংশটি ডকুমেন্টকে বিশ্বস্তভাবে উপস্থাপন করে কি না, এবং এটি বিশেষজ্ঞ নাকি সাধারণ পাঠকের জন্য লেখা। স্টেটের পরে প্রতিটি প্রশ্ন ব্লকে একটি প্রশ্ন ও তার সম্ভাব্য উত্তরগুলো থাকে, যার প্রতিটিকে A, B বা C-এর মতো একটি পূর্বনির্ধারিত লেবেল টোকেন দেওয়া থাকে। একটি বিশেষ <|marker|> টোকেন নির্দেশ করে কোথা থেকে মডেলের পূর্বাভাস পড়তে হবে। এই অবস্থানে একটি শেখা লিনিয়ার আউটপুট লেয়ার (ডিসিশন হেড) হিডেন স্টেটকে প্রশ্নের উত্তর অপশনগুলোর স্কোরে রূপান্তর করে, যা পরে সম্ভাবনায় রূপান্তরিত হয়।

বড় করুন

আমরা বেস মডেল থেকে আউটপুট লেয়ার ইনিশিয়ালাইজ করি, যা সাধারণত পুরো ভোকাবুলারি থেকে পরবর্তী টোকেনের স্কোর দেয়, এবং শুধু A, B বা C-এর মতো পূর্বনির্ধারিত অপশন টোকেনের সংশ্লিষ্ট সারিগুলো রাখি। এরপর এই ছাঁটাই করা লেয়ারকে ট্রেনিং দেওয়া হয় যাতে এটি <|marker|> টোকেনের হিডেন স্টেটকে উত্তরের স্কোরে রূপান্তর করে। এই পদ্ধতিতে সব শ্রেণিবিন্যাস প্রশ্নই কভার হয়, কারণ সেগুলোর প্রতিটিকে বহুনির্বাচনী প্রশ্ন হিসেবে উপস্থাপন করা যায়।

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

v1.3-এ আমরা locate চালু করছি, যা পূর্বনির্ধারিত অপশন থেকে বাছাই না করে স্টেট থেকে টেক্সট এক্সট্র্যাক্ট করে। একটি locate প্রশ্ন বলে দেয় কী খুঁজতে হবে — “অবস্থান”-এর মতো ছোট লেবেল অথবা “চাকরিটি যে শহরে, সেই শহরের নাম এক্সট্র্যাক্ট করো।”-এর মতো নির্দেশনা ব্যবহার করে। মডেলটি স্টেট থেকে হুবহু মিলে যাওয়া টেক্সট এবং এর শুরু ও শেষের ক্যারেক্টার অবস্থান ফেরত দেয়। কোনো মিল না পেলে এটি একটি খালি তালিকা ফেরত দেয়।

বড় করুন

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

দ্বিমুখী অ্যাটেনশন: মডেলকে দুই দিকেই পড়তে দেওয়া

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

দ্বিমুখী অ্যাটেনশন আরেকটি ডিজাইন-সিদ্ধান্তের প্রশ্ন সামনে আনে: স্টেট ও প্রশ্নগুলো কীভাবে পরস্পরের সঙ্গে মিথস্ক্রিয়া করবে? আমরা তিনটি অ্যাটেনশন প্যাটার্ন বিবেচনা করেছি, যেগুলোর পারফরম্যান্স, উত্তরের স্থিতিশীলতা ও ক্যাশ পুনর্ব্যবহারের ওপর ভিন্ন ভিন্ন প্রভাব রয়েছে:

• সবকিছু সবকিছু দেখে (v1.2): পূর্ণ দ্বিমুখী অ্যাটেনশন দিয়ে স্টেট ও সব প্রশ্ন একসঙ্গে প্রসেস করা হয়। স্টেটের ওপর গণনা শেয়ার করা হয়, কিন্তু অন্য কী কী জিজ্ঞেস করা হচ্ছে তার ওপর নির্ভর করে একটি প্রশ্নের উত্তর বদলে যেতে পারে।
• বিচ্ছিন্ন প্রশ্ন (v1.3): স্টেট সব প্রশ্নের প্রতি অ্যাটেন্ড করে, আর প্রতিটি প্রশ্ন শুধু স্টেট ও নিজের টোকেনগুলোর প্রতি অ্যাটেন্ড করে। শেয়ার করা স্টেটের মাধ্যমে প্রশ্নগুলো তবুও পরোক্ষভাবে একে অপরকে প্রভাবিত করতে পারে, তবে ফলাফল বেশি স্থিতিশীল থাকে।
• সম্পূর্ণ ক্যাশযোগ্য: স্টেট কেবল নিজের ওপর অ্যাটেনশন প্রয়োগ করে, আর প্রতিটি প্রশ্ন স্টেট ও নিজস্ব টোকেনগুলোর ওপর অ্যাটেনশন প্রয়োগ করে। স্টেটটি প্রশ্ন-নিরপেক্ষ এবং প্রম্পট ক্যাশিংয়ের সুবিধা নিতে বিভিন্ন অনুরোধে পুনরায় ব্যবহারযোগ্য। আমরা এটি ডিফল্টভাবে ব্যবহার করি না, কারণ বেশ কিছু টাস্কের ক্ষেত্রে স্টেটকে প্রশ্নগুলো দেখতে দেওয়া খুবই গুরুত্বপূর্ণ, তবে সামান্য ফাইন-টিউনিংয়ের মাধ্যমেই একটি মডেলকে এই পদ্ধতিতে নিয়ে আসা যায়।

শক্তিশালী পারফরম্যান্স ও স্থিতিশীলতার কারণে শেষ পর্যন্ত আমরা বিচ্ছিন্ন প্রশ্নের পদ্ধতিটি বেছে নিয়েছি।

বড় করুন

ট্রেনিং রেসিপি

উভয় আকারের মডেলের জন্যই প্রশিক্ষণ তিনটি ধাপে সম্পন্ন হয়। আমরা প্রথমে Qwen3.8-27B-ভিত্তিক বড় মডেলটিকে বড় ডেটাসেটে ক্রস-এনট্রপি ব্যবহার করে প্রশিক্ষণ দিই, তারপর সেটিকে ছোট Qwen3.5-4B মডেলে ডিস্টিল করি।

প্রথম পর্যায় হলো জেনারেলিস্ট ট্রেনিং, যেখানে আমরা বড় আকারের কর্পোরায় মডেলটিকে পুরোপুরি ফাইন-টিউন করি। এই পর্যায়ে আমরা কেবল সেই ডেটাই গ্রহণ করি যা সামগ্রিকভাবে মডেলকে সাহায্য করে এবং কোনো নির্দিষ্ট বেঞ্চমার্কের জন্য নির্দিষ্ট নয়; তাই আমরা সব বেঞ্চমার্কের ট্রেনিং স্প্লিট বাদ দিই।

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

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

টেক্সটের উভয় পর্যায়ে আমরা তিনটি রানের গড় ওয়েট ব্যবহার করি, যার প্রতিটিতে আলাদা র‍্যান্ডম সিড ব্যবহার করা হয়েছে। আমরা দেখেছি, এতে সমন্বিত মডেলের পারফরম্যান্স ও দৃঢ়তা বাড়ে।

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

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

তথ্য এক্সট্র্যাক্ট করার সক্ষমতা যোগ করা

locate ফিচারটি সাধারণ অনুরোধের উত্তর দেওয়ার ধরন না বদলেই টেক্সট থেকে নেমড এনটিটির মতো তথ্য এক্সট্র্যাক্ট করে। এর জন্য আমরা একটি অতিরিক্ত ট্রেনিং পর্যায় যোগ করেছি: Decider-এ আমরা একটি নতুন বিশেষ টোকেন <|locate|>, একটি স্প্যান হেড এবং একটি LoRA অ্যাডাপ্টার যুক্ত করি।

<|locate|>-এর এমবেডিং আমরা ইনিশিয়ালাইজ করি <|marker|> থেকে, যা আগের ট্রেনিং পর্যায়গুলোতে শেখা হয়েছে। আমরা শুধু এই নতুন এমবেডিং, স্প্যান হেড এবং LoRA অ্যাডাপ্টারগুলো ট্রেন করি, আর মূল ব্যাকবোনের ওয়েট ও ডিসিশন হেড ফ্রোজেন রাখি। অনুরোধ করা প্রতিটি ফিল্ড নিজস্ব একটি <|locate|> টোকেন পায়।

স্প্যান হেড <|locate|>-এর রিপ্রেজেন্টেশনের সঙ্গে স্টেট-টোকেন রিপ্রেজেন্টেশনগুলো ব্যবহার করে স্কোর নির্ধারণ করে যে মিলে যাওয়া স্প্যানগুলো কোথায় শুরু ও শেষ হয় এবং কোন শুরু-শেষ জোড়াগুলো একসঙ্গে যায়। এই স্কোরগুলোর জন্য ফিল্ড-নির্দিষ্ট থ্রেশহোল্ড অনুমান করতে এটি <|locate|> টোকেনের রিপ্রেজেন্টেশনও ব্যবহার করে। নির্বাচিত স্প্যানগুলো মূল টেক্সটে ক্যারেক্টার অবস্থান হিসেবে ফেরত দেওয়া হয়।

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

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

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

মূল্যায়ন

আমরা Hugging Face Decision Index, Vals AI-এর ClaimBench এবং Artificial Analysis Decision Index-এর বাহ্যিক বেঞ্চমার্কে Decider v1.3 ও Decider Flash v1.3 মূল্যায়ন করি।

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

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

কোয়েরি শ্রেণিবিন্যাস

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

একটি ফ্রন্টিয়ার LLM দিয়ে স্বাধীনভাবে পুনরায় লেবেল করা রেফারেন্সসহ ৬৩টি শ্রেণিবিন্যাস কাজে Decider v1.3 গড়ে ৯১.৬% নির্ভুলতা অর্জন করেছে, যা আমাদের প্রোডাকশন ক্লাসিফায়ারের চেয়ে ৬.৫৪ পার্সেন্টেজ পয়েন্ট বেশি। Decider Flash v1.3-ও প্রোডাকশন বেসলাইনকে ছাড়িয়ে গেছে, আর Decider v1.3 ছাড়িয়ে গেছে Jev 1.14-কে।

বড় করুন

ডোমেইনভিত্তিক শ্রেণিবিন্যাস

সাতটি ডোমেইনে সিদ্ধান্ত মডেলের শ্রেণিবিন্যাস পারফরম্যান্স মূল্যায়নের জন্য আমরা পাবলিক ডেটাসেট থেকে একটি ডোমেইনভিত্তিক মূল্যায়ন স্যুট তৈরি করেছি: দাবি যাচাই (৬টি কাজ), স্বাস্থ্যসেবা (৭), সাইবার নিরাপত্তা (৮), প্রোগ্রামিং (১৬), সরকার (৭), আইন (৯) এবং অর্থ (৯)।

যেমন, “একটি Python প্রোগ্রামের টাইম কমপ্লেক্সিটি বিচার করো”, অথবা “বার্ষিক আর্থিক প্রতিবেদন ব্যবহার করে নির্ধারণ করো, কোম্পানির সীমাবদ্ধতামুক্ত নগদ অর্থ আগামী বারো মাসের মধ্যে পরিশোধযোগ্য ঋণের মূল অংশ কভার করে কি না”। সাতটি ডোমেইনেই Decider v1.3 এগিয়ে আছে; অর্থ ডোমেইনে এটি Jev 1.14-কে সর্বোচ্চ ১২.৯ পার্সেন্টেজ পয়েন্ট এবং আইনে ৯.৩ পয়েন্ট ছাড়িয়ে গেছে। অর্থ, প্রোগ্রামিং ও আইনে Decider Flash v1.3 Jev 1.14-এর চেয়ে পিছিয়ে আছে, আর অন্যান্য ডোমেইনে প্রায় সমান পারফরম্যান্স দেখায়।

বড় করুন

রিট্রিভাল ও রির‍্যাংকিং

সার্চ হলো Perplexity-র মূল ভিত্তি। আমাদের মডেলগুলোর রির‍্যাংকিং পারফরম্যান্স মূল্যায়নের জন্য আমরা রিট্রিভাল কাজের একটি বিস্তৃত স্যুট বজায় রাখি। প্রতিটি কাজের জন্য আমরা প্রথমে একগুচ্ছ এমবেডিং মডেল ব্যবহার করে প্রতিটি কর্পাস থেকে শীর্ষ ৫০টি প্রার্থী ডকুমেন্ট রিট্রিভ করি। এরপর Decider দিয়ে এই প্রার্থীদের রির‍্যাংক করি এবং একটি শক্তিশালী রির‍্যাংকার বেসলাইন Qwen3-Reranker-8B-এর সঙ্গে এর পারফরম্যান্স তুলনা করি।

আমরা জিরো-শট, পয়েন্টওয়াইজ সেটিংয়ে Decider মূল্যায়ন করি: মডেলটি প্রতিটি কোয়েরি–ডকুমেন্ট জোড়াকে আলাদাভাবে সরাসরি স্কোর করে এবং প্রাসঙ্গিকতা অনুযায়ী ডকুমেন্টগুলোর র‍্যাংক নির্ধারণ করে। ৭২টি রিট্রিভাল কাজে Decider v1.3 গড়ে ৮৩.৯৯ nDCG@10 অর্জন করেছে, যা Qwen3-Reranker-8B-এর চেয়ে ১.৮১ পয়েন্ট এবং Jev 1.14-এর চেয়ে ২.২৪ পয়েন্ট বেশি।

BEIR বেঞ্চমার্কে দুটি মডেলই nDCG@10-এ Qwen3-Reranker-8B-কে যথাক্রমে ৮.৭৮ ও ৭.০৫ পয়েন্ট ব্যবধানে ছাড়িয়ে গেছে। Jev 1.14-এর তুলনায় Decider v1.3-এর স্কোর ১.৩৩ পয়েন্ট বেশি, আর Flash সংস্করণের স্কোর ০.৪ পয়েন্ট কম।

বড় করুন

বহুভাষিক শ্রেণিবিন্যাস

ইংরেজির বাইরে সিদ্ধান্ত মডেল মূল্যায়ন করতে আমরা একটি বহুভাষিক শ্রেণিবিন্যাস বেঞ্চমার্ক তৈরি করেছি, যাতে ৮টি পাবলিক ডেটাসেট থেকে নেওয়া ১৯টি ভাষাভিত্তিক কাজ এবং আটটি ভাষায় ৪৬,৪৮৪টি উদাহরণ রয়েছে: জার্মান, স্প্যানিশ, ফরাসি, ইতালীয়, রুশ, জাপানি, কোরীয় ও চীনা। বেঞ্চমার্কটিতে রয়েছে ইনটেন্ট শনাক্তকরণ, বিষয় শ্রেণিবিন্যাস, সেন্টিমেন্ট বিশ্লেষণ, ন্যাচারাল ল্যাঙ্গুয়েজ ইনফারেন্স, প্যারাফ্রেজ শনাক্তকরণ, আপত্তিকর ভাষা শনাক্তকরণ এবং ব্যাকরণগত গ্রহণযোগ্যতা।

প্রতিটি কাজকে সমান গুরুত্ব দিয়ে আমরা প্রতিটি ভাষার কাজগুলোর গড় নির্ভুলতা উপস্থাপন করছি। আটটি ভাষাতেই Decider v1.3 Jev 1.14-কে ছাড়িয়ে গেছে, আর Decider Flash v1.3 ছাড়িয়েছে ছয়টিতে; কাজপ্রতি গড় নির্ভুলতা Decider v1.3-এর ৮৮.১৬% এবং Decider Flash v1.3-এর ৮৬.৫০%, যেখানে Jev 1.14-এর ৮৫.৪১%।

বড় করুন

NER, PII ও এক্সট্র্যাকটিভ QA

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

আমরা NER ও PII মূল্যায়ন করি এক্স্যাক্ট-স্প্যান F1 দিয়ে, যেখানে অনুমিত স্প্যানগুলোকে রেফারেন্সের সীমানার সঙ্গে হুবহু মিলতে হয়। এক্সট্র্যাক্টিভ QA-তে ক্যারেক্টার-লেভেল F1 ব্যবহার করা হয়, যা উত্তরের টেক্সট আংশিক মিলে গেলে আংশিক কৃতিত্ব দেয়; অন্যদিকে স্ট্রাকচার্ড এক্সট্র্যাকশনে ফিল্ড অ্যাকুরেসি ব্যবহার করা হয়, অর্থাৎ সঠিকভাবে এক্সট্র্যাক্ট করা ফিল্ডের অনুপাত। CV পার্সিংয়ের ক্ষেত্রে আমরা NER ও PII-এর এক্স্যাক্ট-স্প্যান F1 স্কোরের গড় নিই।

আমরা আমাদের মডেলগুলোকে বিভিন্ন আকারের সাধারণ-উদ্দেশ্য এক্সট্র্যাকশন মডেলের সঙ্গে তুলনা করেছি: GLiNER large v2.5 (0.5B), Liquid d1 (2B) এবং Cloudflare-এর Clairic (অপ্রকাশিত)। Decider v1.3-এর গড় স্কোর ৬৯.০ (প্রতিটি কাজের প্রাথমিক মেট্রিক অনুযায়ী) এবং Decider Flash v1.3-এর ৬৩.৬, যেখানে Liquid d1-এর ৪৩.৩, Clairic-এর ৪১.৫ এবং GLiNER large v2.5-এর ৩৩.৬। প্রতিটি ক্যাটাগরিতেই দুটি Decider মডেল এগিয়ে।

বড় করুন

ইমেজ ক্লাসিফিকেশন

v1 থেকেই Decider নেটিভভাবে ভিশন কাজ সমর্থন করে। টেক্সটের বাইরে এর পারফরম্যান্স মূল্যায়ন করতে আমরা পাঁচটি কাজের একটি বেঞ্চমার্ক স্যুট তৈরি করেছি, যার বিশেষ মনোযোগ ডকুমেন্ট শ্রেণিবিন্যাসে — ইনভয়েস, চিঠি ও জীবনবৃত্তান্তসহ। স্যুটটিতে স্যাটেলাইট ছবির শ্রেণিবিন্যাস, টেক্সচার শ্রেণিবিন্যাস, পোষা প্রাণীর জাত শ্রেণিবিন্যাস এবং প্রাণী গণনাও রয়েছে।

পাঁচটি ভিজ্যুয়াল কাজে Decider v1.3 গড়ে ৭৬.৯৯% নির্ভুলতা অর্জন করেছে, যা Jev 1.14-এর চেয়ে ১.৪৭ পার্সেন্টেজ পয়েন্ট বেশি। Decider Flash v1.3 অর্জন করেছে ৭২.৭৭%, যা দেখায় যে ছোট মডেলেও ভিজ্যুয়াল শ্রেণিবিন্যাসের সক্ষমতা রয়েছে।

বড় করুন

বাস্তব জগতের সিদ্ধান্ত অনুরোধ

Perplexity Decision API চালুর প্রথম ১৮ দিনে জমা পড়া অনুরোধগুলো থেকে আমরা ডুপ্লিকেটমুক্ত ও PII-মাস্ক করা ১০ লাখ অনুরোধের নমুনা নিয়েছি। প্রতিটি অনুরোধে একই স্টেট নিয়ে একাধিক প্রশ্ন থাকতে পারে বলে নমুনাটিতে মোট ২৩,১৮,৮৮৭টি আলাদা প্রশ্ন রয়েছে। গবেষণার জন্য ব্যবহারকারীর সুস্পষ্ট অনুমতি নিয়েই সব অনুরোধ অন্তর্ভুক্ত করা হয়েছে।

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

কাজের মিশ্রণ অসম: তথ্য নিষ্কাশনে ৪,২৫,৪০২টি প্রশ্ন, ডোমেইন শ্রেণিবিন্যাসে ৪,০৯,৫৬৪টি এবং সেন্টিমেন্ট বিশ্লেষণে ৩,৪৪,১৫৮টি। এই তিন ক্যাটাগরি মিলে নমুনার প্রশ্নগুলোর ৫০.৮%।

বিচারকদের সঙ্গে সর্বোচ্চ মিল অর্জন করেছে Decider v1.3 — ৯৩.৯৮%; তুলনায় Decider v1.2-এর ৯৩.৬৮% এবং Jev 1.14-এর ৯৩.৩৫%। ডোমেইন শ্রেণিবিন্যাস ও সেন্টিমেন্ট বিশ্লেষণে Decider v1.3 ও Jev 1.14 প্রায় সমানে সমান, ব্যবধান যথাক্রমে ০.৩৪ ও ০.০৭ পার্সেন্টেজ পয়েন্ট। প্রাসঙ্গিকতা র‍্যাংকিংয়ে Jev ০.৬৯ পয়েন্টে এগিয়ে, অন্যদিকে Decider v1.3 তথ্য নিষ্কাশনে (নমুনায় সবচেয়ে সাধারণ কাজ) ০.৯৩ পয়েন্ট এবং ইনটেন্ট ও রাউটিংয়ে ১.২১ পয়েন্ট এগিয়ে।

বড় করুন

নিচের চার্টে একই ১০ লাখ প্রোডাকশন অনুরোধ চালানোর রিপোর্ট করা খরচের তুলনা দেখানো হয়েছে। প্রতিটি অনুরোধে একাধিক প্রশ্ন থাকতে পারে, তাই এখানে একক হলো অনুরোধ, আলাদা আলাদা প্রশ্ন নয়।

বড় করুন

দৃঢ়তা

আমরা ৩৭২টি বহুনির্বাচনী প্রশ্নে লেবেল সংবেদনশীলতা মূল্যায়ন করেছি, প্রতি মডেলে ৪,৭৮৮টি অনুরোধ পাঠিয়ে। প্রতিটি প্রশ্নের অর্থ অক্ষুণ্ণ রেখে আমরা অপশনের ক্রম বদলেছি, উত্তরের টেক্সটে লেবেল নতুন করে বরাদ্দ করেছি এবং লেবেলের নাম বদলেছি; তারপর যাচাই করেছি মডেলের অর্থগত উত্তর বদলেছে কি না। ফ্লিপ রেট যত কম, স্থিতিশীলতা তত বেশি।

প্রতিটি রূপান্তরের ক্ষেত্রে Decider v1.3 মাত্র ০.২৭% প্রশ্নে উত্তর বদলেছে, যেখানে Jev 1.14-এর ক্ষেত্রে তা ছিল ২.৬৯–৪.৮৪%। সার্ভিংয়ের সময় ফলাফলের তারতম্য মাপতে আমরা একই ইনপুট বারবারও দিয়েছি: Decider v1.3-এ কোনো পরিবর্তন দেখা যায়নি, অথচ Jev 1.14 ১.৮৮% প্রশ্নে উত্তর বদলেছে।

বড় করুন

আমরা যেভাবে Decider ব্যবহার করি

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

স্ব-উন্নয়নশীল নিরাপত্তা নিয়ম

অভ্যন্তরীণভাবে আমরা ইতিমধ্যেই আমাদের নিরাপত্তা নীতিমালা উন্নত করতে Decider ব্যবহার করছি।

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

এক দিনে Decider ৭,০০০ এজেন্ট সেশন জুড়ে ১০০ কোটি টোকেন পড়েছে এবং এমন ত্রুটি শনাক্ত করেছে যার ফলে ১৪টি নিয়ম সংশোধন হয়েছে; এর মধ্যে ৬টি দুই দিনের মধ্যে অনুমোদিত হয়ে চালু হয়েছে। এক সপ্তাহের লগে পুনরায় চালিয়ে দেখা গেছে, এই সংশোধনগুলো আমাদের সবচেয়ে ব্যস্ত নিয়মের ভলিউম ৫২% কমিয়েছে, আর সম্প্রসারিত নিয়মগুলো তদন্তযোগ্য প্রকৃত অ্যাকশন প্রায় ৪০% বেশি ধরেছে।

বড় করুন

RL রোলআউট মনিটরিং

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

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

বড় করুন

পেজের মান অনুযায়ী ফিল্টারিং

ইনডেক্স করে ব্যবহারকারীদের কাছে পরিবেশনের জন্য ওয়েব পেজ ক্রল করার সময় দেখা যায়, অনেক পেজের মান এতটাই নিম্ন যে সেগুলো কোনো কাজে আসে না। এর মধ্যে রয়েছে অ্যান্টি-বট ওয়াল, CAPTCHA ও এরর পেজ, পাশাপাশি এমন ওয়েব পেজও যেগুলো ঠিকঠাক লোড হলেও কোনো কাজের তথ্য ধারণ করে না, যেমন স্প্যাম, SEO ফিলার বা শুধু নেভিগেশনের পেজ। এসব নিম্নমানের পেজ শনাক্ত করে আমাদের ইনডেক্স থেকে বাদ দিতে হয়।

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

বড় করুন

এসব অভ্যন্তরীণ ব্যবহারের বাইরেও Decider নিচের মতো ওয়ার্কফ্লোতে কাজে লাগে।

ভিজ্যুয়াল QA

Decider ছবি পড়তে পারে বলে এটি ভিজ্যুয়াল চেকার হিসেবেও কাজ করে — ওয়েব পেজ বা অ্যাপের স্টাইল পরিবর্তন পর্যালোচনা করে ত্রুটি শনাক্ত করে। কোনো পরিবর্তন চালুর আগে এটি পেজের স্ক্রিনশট দেখে কাটা পড়া টেক্সট, একটির ওপর আরেকটি চেপে বসা উপাদান বা ভাঙা লেআউট খুঁজে বের করতে পারে, অথবা এমন চার্ট চিহ্নিত করতে পারে যার ডিজাইন পাঠককে বিভ্রান্ত করতে পারে বা ব্র্যান্ড গাইড লঙ্ঘন করতে পারে।

বড় করুন

ব্রাউজার নেভিগেশন

বড় কাজের ভেতরের ছোট ছোট সিদ্ধান্তের জন্য এজেন্টরা Decider ব্যবহার করতে পারে। একটি ব্রাউজার এজেন্ট প্রতিটি ধাপে একটি স্ক্রিনশট পাঠিয়ে পেজের অবস্থা এবং প্রতিটি সম্ভাব্য অ্যাকশনের প্রত্যাশিত ফলাফল সম্পর্কে বিস্তারিত তথ্য পেতে পারে।

বড় করুন

গবেষণার কাজের পরিকল্পনা

ব্যবহারকারীদের প্রশ্নের জটিলতা অনেক ভিন্ন হতে পারে, তেমনি উত্তর খুঁজে পেতে কতটা গভীরভাবে সার্চ করতে হবে তাও ভিন্ন হয়। সার্চ শুরুর আগেই Decider এটি অনুমান করতে পারে, ফলে সহজ প্রশ্নে কম রিসোর্স ব্যয় করা যায়।

বড় করুন

শুরু করুন

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

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

দুটি মডেলই Apache লাইসেন্সের অধীনে Hugging Face-এ ডাউনলোডযোগ্য ওয়েট হিসেবে, OpenRouter-এর মাধ্যমে এবং Perplexity Decisions API-তে পাওয়া যাচ্ছে।

সাইটেশন

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}