কোড জেনারেশন হিসেবে সার্চের পুনর্চিন্তা

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

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

এই দুনিয়ায় সার্চকে নিজেই এজেন্টিক হতে হবে, যার বিল্ডিং ব্লকগুলো এজেন্ট হার্নেসের মধ্যে সরাসরি SDK হিসেবে অ্যাক্সেসযোগ্য হবে। আমরা Perplexity-এর নতুন রেফারেন্স সার্চ আর্কিটেকচার হিসেবে Search as Code (SaC)-এর সাথে পরিচয় করিয়ে দিচ্ছি।

Perplexity-এর সার্চ স্ট্যাক আমাদের অ্যাপ্লিকেশন এবং API প্ল্যাটফর্ম জুড়ে প্রতি সেকেন্ডে হাজার হাজার কুয়েরি পরিবেশন করে। ২০২৫ সালের সেপ্টেম্বর মাসে, আমরা আমাদের সার্চ সিস্টেমের প্রথম আর্কিটেকচারাল ওভারভিউ প্রকাশ করেছি। এই সিস্টেমগুলোর মধ্যে ধ্রুবক উদ্ভাবন Search API, Agent API, এবং Computer-এর মতো নতুন অফারগুলোর লঞ্চকে সমর্থন করেছে, যেখানে সেলফ-ইম্প্রুভমেন্ট লুপগুলো সার্চ স্ট্যাককে অপ্টিমাইজ করছে যাতে প্রতিদিন ব্যবহারকারীদের আরও ভালোভাবে সেবা দেওয়া যায়।

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

প্রথাগত সার্চ আর্কিটেকচার একটি একক নির্দিষ্ট সিস্টেম প্রকাশ করে যা মডেলগুলো ধারাবাহিকভাবে কল করে, অন্যদিকে Search as Code এমন পরমাণুকৃত সার্চ প্রিমিটিভ প্রকাশ করে যা এজেন্টরা জেনারেট করা কোডের মাধ্যমে কম্পোজ করে।

তবুও আজ এই পদ্ধতিটি প্রতি মাসে আরও বেশি অপ্রাসঙ্গিক হয়ে উঠছে। ব্যবহারকারীরা AI-এর কাছে একক-শট বিশ্লেষণের চেয়ে অনেক বেশি কিছু দাবি করে। তারা আশা করে যে এজেন্টরা ঘণ্টা বা এমনকি দিন ধরে শেষ থেকে শেষ পর্যন্ত (end-to-end) কাজগুলো সম্পন্ন করবে। এই কাজগুলো জটিল, উন্মুক্ত এবং তাদের তথ্যের চাহিদার দিক থেকে অত্যন্ত পরিবর্তনশীল হতে পারে, এবং মনোলিথিক আর্কিটেকচারগুলো এই চাহিদার ভারে ভেঙে পড়ছে।

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

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

এই চাহিদা পূরণের জন্য, আমরা আমাদের পণ্য জুড়ে একটি নতুন সার্চ আর্কিটেকচার নিয়ে আসছি: Search as Code (SaC)। এই নতুন আর্কিটেকচারটি মডেলগুলোকে কেবল এর চূড়ান্ত আউটপুট ব্যবহারের পরিবর্তে সরাসরি সার্চ স্ট্যাকের ভিতরে প্রবেশ করার ক্ষমতা দেয়। মূল ধারণাটি সহজ: আমরা সার্চ স্ট্যাকের উপাদানগুলোকে একটি SDK-এর মধ্যে প্রিমিটিভ হিসেবে প্রকাশ করি। সার্চ প্রয়োজন এমন যে কোনো অনুরোধের জন্য, একটি মডেল সেই নির্দিষ্ট অনুরোধের জন্য তৈরি একটি রিট্রিভাল পাইপলাইনে অন-ডিমান্ড এই প্রিমিটিভগুলোকে একত্রিত করে।

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

Search as Code (SaC) বিভিন্ন ধরনের বেঞ্চমার্ক জুড়ে এজেন্টিক সার্চের কর্মক্ষমতার সীমানাকে এগিয়ে নিয়ে যায়।

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

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

বিশ্বের প্রথম সার্চ ইঞ্জিনগুলো মানব ব্যবহারকারীদের জন্য তৈরি করা হয়েছিল। এই ব্যবহারকারীরা একটি অনুমানযোগ্য অভিজ্ঞতার আশা করতেন, যা সাধারণত প্রাসঙ্গিকতা-র‍্যাঙ্ক করা নথির একটি নির্দিষ্ট সংখ্যা নিয়ে গঠিত হতো। ব্যবহারকারীরা সার্চ প্রক্রিয়াটিকে মাইক্রোম্যানেজ করতে চাননি; তারা একটি কুয়েরি প্রবেশ করাতে এবং একটি দরকারী ফলাফল খুঁজে পেতে চেয়েছিলেন।

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

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

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

প্রথাগত সার্চ সিস্টেমগুলো এজেন্টিক ওয়ার্কফ্লোকে মডেল-দৃশ্যমান টার্ডের মাধ্যমে সার্চ সিকোয়েন্স করতে বাধ্য করে। মডেলগুলোকে বিভিন্ন কুয়েরি প্যারামিটার জুড়ে বারবার একই সার্চ পাইপলাইন কল করতে হয় এবং মডেল কনটেক্সটে সমস্ত ফলাফল প্রবর্তন করতে হয়।

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

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

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

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

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

AI-এর ফাংশন কলিং এবং MCP যুগের সময় এই চ্যালেঞ্জগুলো নিয়ে খুব বেশি কিছু করা যায়নি। যখন প্রতিটি সার্চ অপারেশনের জন্য LLM ইনফারেন্সে নিজস্ব রাউন্ডট্রিপের প্রয়োজন হয়, তখন ডেভেলপাররা স্বাভাবিকভাবেই সেই রাউন্ডট্রিপে যতটা সম্ভব কাজ সেরে ফেলতে পছন্দ করেন। এর অর্থ হলো এন্ড-টু-এন্ড সার্চ পাইপলাইন যা মডেল দ্বারা সরাসরি ব্যবহারের জন্য সম্পূর্ণ প্রক্রিয়াজাত ফলাফল সেট ফিরিয়ে দেয়।

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

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

সার্চ আর্কিটেকচারের পরবর্তী প্রজন্ম একটি মূল নীতির ওপর নির্ভর করবে: AI এজেন্টদের দ্বারা সার্চ নেটিভভাবে প্রোগ্রামেবল হওয়া উচিত। কোনো এজেন্টকে পূর্বনির্ধারিত সার্চ পাইপলাইনের একটি সেটের মধ্যে সীমাবদ্ধ রাখা যাবে না। বরং, বিভিন্ন স্তরের বিমূর্ততায় ডিজাইন করা কম্পোজেবল বিল্ডিং ব্লক ব্যবহার করে নির্দিষ্ট কাজের যে পাইপলাইন প্রয়োজন, তা তৈরি করতে সক্ষম হতে হবে।

আমাদের নতুন Search as Code (SaC) আর্কিটেকচার এই নীতিটিকে মূর্ত করে। SaC-এ, ফাংশন কলিং বা MCP ইন্টারফেসের মাধ্যমে একটি রিট্রিভাল অপারেশনও পাঠানো হয় না। পরিবর্তে সমস্ত অপারেশন মডেল-জেনারেটেড পাইথন কোডের মাধ্যমে অর্কেস্ট্রেট করা হয়। সবচেয়ে সহজ সার্চ প্রয়োজনের জন্য, এই কোডে উচ্চ-স্তরের সার্চ এন্ডপয়েন্টে কিছু অনুরোধ থাকতে পারে। কিন্তু জটিল কাজের জন্য, কোডটি যত জটিল প্রয়োজন তত জটিল হতে পারে, যার মধ্যে শর্তসাপেক্ষ এক্সিকিউশন, অ্যাসিনক্রোনি, প্যারালালিজম এবং কম-স্তরের প্রিমিটিভের বিস্তৃত পরিসরে কল অন্তর্ভুক্ত থাকে।

Search as Code (SaC) আর্কিটেকচারটি মডেল, কম্পিউট স্যান্ডবক্স এবং Perplexity-এর সার্চ অবকাঠামোর উপরে অবস্থিত একটি এজেন্টিক সার্চ SDK-এর সমন্বয়ে গঠিত একটি স্ট্যাকের ওপর নির্ভর করে।

SaC-এ তিনটি নিবিড়ভাবে যুক্ত স্তর রয়েছে:

মডেলগুলো কন্ট্রোল প্লেন হিসেবে কাজ করে। তারা ব্যবহারকারীর (বা প্যারেন্ট এজেন্টের) নির্দেশ নিয়ে যুক্তি তৈরি করে, নির্দেশটিকে কাজগুলোতে বিভক্ত করে, প্রতিটি কাজের জন্য কোন রিট্রিভাল এবং প্রসেসিং পাইপলাইন প্রয়োজন তা সিদ্ধান্ত নেয় এবং সেই পাইপলাইনগুলো বাস্তবায়নের জন্য কোড জেনারেট করে।

কম্পিউট স্যান্ডবক্সগুলো একটি সুরক্ষিত কোড এক্সিকিউশন রানটাইমের মাধ্যমে নির্ধারক বা ডার্মিনিস্টিক কম্পিউট প্রদান করে। তারা মডেলগুলোর জন্য কন্ট্রোল ফ্লো, ব্যাচিং, রিট্রাই, ফিল্টারিং, জয়েনিং, অ্যাগ্রিগেশন এবং অন্যান্য নির্ধারক অপারেশন বাস্তবায়নের ক্যানভাস প্রদান করে।

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

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

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

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

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

স্যান্ডবক্সগুলো SaC পাইপলাইন সংজ্ঞায়িত এবং চালানোর জন্য সুরক্ষিত পরিবেশ প্রদান করে। তারা পৃথক সার্চ প্রিমিটিভের সাথে মিথস্ক্রিয়া সহজতর করার জন্য এজেন্টিক সার্চ SDK-তে অ্যাক্সেস প্রদান করে মডেল-জেনারেটেড কোড চালায়।

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

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

টার্ন জুড়ে ইন্টারমিডিয়েট স্টেট পরিচালনার জন্য আমরা দুটি পদ্ধতি বিবেচনা করেছি:

পারসিস্টেন্ট ফাইলসিস্টেম + এক্সপ্লিসিট সার্ড (serde): স্যান্ডবক্সগুলো মডেলগুলোর টার্ন জুড়ে ব্যবহারের জন্য পারসিস্টেন্ট ফাইলসিস্টেম প্রকাশ করতে পারে। ইন্টারমিডিয়েট স্টেট পারসিস্ট করতে ইচ্ছুক মডেলগুলো একটি টার্নের জন্য জেনারেটেড কোডের মধ্যে একটি সিরিয়ালাইজেশন ধাপ অন্তর্ভুক্ত করতে পারে, সাথে পরবর্তী টার্নের মধ্যে (মডেলের নিজের পরিদর্শনের জন্য বা ডাউনস্ট্রিম ব্যবহারের জন্য) একটি ডিসিরিয়ালাইজেশন ধাপ অন্তর্ভুক্ত করতে পারে। ফাইলসিস্টেম পদ্ধতিটি মডেলগুলোকে সরাসরি এবং স্পষ্টভাবে নিয়ন্ত্রণ করতে দেয় কীভাবে ইন্টারমিডিয়েট স্টেট টার্ন জুড়ে পৌঁছে দেওয়া হয়। এটি মডেল দ্বারা ব্যবহৃত তথ্যের স্পষ্ট সনাক্তকরণ এবং স্থায়িত্ব প্রয়োগ করে ট্রেসেবিলিটি নিশ্চিত করে। একটি নেতিবাচক দিক হলো সার্ড কোড জেনারেট করার কারণে লেটেন্সি এবং কনটেক্সট ওভারহেড হয়, যদিও সু-ডিজাইন করা ইউটিলিটি ফাংশন এই ওভারহেড কমাতে পারে।

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

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

এজেন্ট হার্নেসকে চালিতকারী মডেলগুলো SaC-এর কন্ট্রোল প্লেন হিসেবে কাজ করে: প্রতিটি কাজের চাহিদা মেটাতে এজেন্টিক সার্চ SDK-এর বিল্ডিং ব্লক থেকে গতিশীলভাবে সার্চ পাইপলাইন একত্রিত করা, তারপরে স্যান্ডবক্স এক্সিকিউশনের জন্য কোড হিসেবে সেই পাইপলাইনগুলো প্রেরণ করা।

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

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

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

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

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

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

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

আমরা আমাদের পরীক্ষার স্যুইটের মধ্যে একটি বাস্তব-বিশ্বের কাজের ওপর ভিত্তি করে একটি কেস স্টাডি উপস্থাপন করি। এই কাজটি একটি এজেন্টকে ২০২৩-২০২৫ সালের ২০০টিরও বেশি উচ্চ-তীব্রতার CVE শনাক্ত এবং বৈশিষ্ট্যযুক্ত করতে বলে। প্রতিটি রেকর্ডে প্রভাবিত ভেন্ডরের নিজস্ব অ্যাডভাইজরি উদ্ধৃত করতে হবে, প্রোডাক্ট এবং ফিক্স সংস্করণটির নাম দিতে হবে এবং দেখাতে হবে যে ফিক্স সংস্করণটি নির্দিষ্ট CVE-এর সাথে যুক্ত।

SaC-এর উত্তর নির্ভুলতায় ১০০% স্কোর করেছে, অ-SaC বেসলাইনের তুলনায় মোট টোকেন ব্যবহার ৮৫.১% কমে গেছে (২৮৮.৭K টোকেন থেকে ৪২.৯K টোকেনে)। সেকশন ৪-এ আরও বিস্তারিতভাবে আলোচনা করা পরীক্ষিত অ-Perplexity সিস্টেমগুলো সবই ২৫%-এর কম স্কোর করেছে।

SaC-এর প্রোগ্রামেবিলিটি কীভাবে মডেলকে কার্যকর কৌশল বাস্তবায়ন করতে দেয় তা চিত্রিত করার জন্য আমরা ট্র্যাজেক্টোরি থেকে তিনটি স্ট্যালাইজড কোড ব্লক উপস্থাপন করি।

python

# Part 1 of 3: fan out over official advisory formats.
templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

এই প্রথম ব্লকটি বিশুদ্ধ অর্কেস্ট্রেশন। জেনারেটেড প্রোগ্রামটি কুয়েরি প্ল্যানে সরাসরি সোর্স-ক্লাস নিয়ম এনকোড করে শুরু হয়: শুধুমাত্র ভেন্ডরের মালিকানাধীন অ্যাডভাইজরি ফর্ম্যাটগুলো প্রাসঙ্গিক। NVD, MITRE, CVE Details, খবরের গল্প, CERT পেজ এবং তৃতীয় পক্ষের ডাটাবেসসহ অ-ভেন্ডর উৎসগুলো কাঠামোগতভাবে সুযোগের বাইরে। সঠিক-বাক্যাংশ সীমাবদ্ধতাগুলো সার্চকে এমন পৃষ্ঠার দিকে ঠেলে দেয় যার সূচীকৃত টেক্সটে ইতিমধ্যে ডাউনস্ট্রিম প্রয়োজনীয় সুনির্দিষ্ট CVE বিবরণ রয়েছে।

python

# Part 2 of 3: synthesize refinements for sparse vendor-years.
coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """
Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage:
{coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

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

python

# Part 3 of 3: verify CVE-to-version binding.
all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

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

আমরা পরম কর্মক্ষমতা এবং খরচ-কর্মক্ষমতা সীমানা উভয়টির ওপর ফোকাস করে একটি ব্যাপক বেঞ্চমার্ক স্যুইটে SaC-এর কার্যকারিতা মূল্যায়ন করি।

আমাদের বেঞ্চমার্ক স্যুইটে মোট পাঁচটি বেঞ্চমার্ক রয়েছে, যা বিভিন্ন ডোমেন, টাস্ক ফর্ম্যাট এবং জটিলতার স্তর জুড়ে সার্চ-নির্ভর AI ওয়ার্কফ্লো স্ট্রেস টেস্ট করার জন্য ডিজাইন করা হয়েছে। আমরা চারটি পূর্বের বেঞ্চমার্ক ব্যবহার করি: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), এবং WideSearch। প্রথম তিনটি বেঞ্চমার্কের (DSQA, BrowseComp, এবং HLE) জন্য, আমরা শীর্ষলাইন মেট্রিক হিসেবে নির্ভুলতা রিপোর্ট করি। WideSearch-এর জন্য, আমরা সারি অনুসারে F1 স্কোর রিপোর্ট করি।

আমরা নতুন বিকশিত WANDR বেঞ্চমার্কও ব্যবহার করি, যা সার্চ, কম্পিউট এবং মডেল যুক্তির যত্নশীল অর্কেস্ট্রেশনের প্রয়োজন এমন কঠিন “ওয়াইড রিসার্চ” কাজের ওপর ফোকাস করে। WANDR জ্ঞান-নিবিড় পেশাদার কাজগুলো দ্বারা অনুপ্রাণিত যা Perplexity Computer ব্যবহারকারীদের জন্য পরিচালনা করে। এটি WideSearch এবং অনুরূপ বেঞ্চমার্ক দ্বারা অনুপ্রাণিত, কিন্তু আরও জটিল কাজ এবং কাজের কাঠামোর ওপর জোর দেয়। আমরা আগামী সপ্তাহে WANDR বেঞ্চমার্ক প্রকাশ করব।

আমরা পাঁচটি এজেন্ট-ভিত্তিক সিস্টেম মূল্যায়ন করি। সমান্তরালকরণের সুবিধার পরিবর্তে অন্তর্নিহিত আর্কিটেকচারের কর্মক্ষমতা বিচ্ছিন্ন করার জন্য আমরা “সেরা-অফ-N” স্কোরের পরিবর্তে পৃথক রান বিবেচনা করি। প্রতিটি সিস্টেমের কনফিগারেশন নিচে বর্ণনা করা হয়েছে:

Perplexity (SaC): আমরা Perplexity-এর প্রোডাকশন Agent API-এর মধ্যে SaC আর্কিটেকচার মূল্যায়ন করি। GPT 5.5 (উচ্চ যুক্তি) অন্তর্নিহিত মডেল হিসেবে কাজ করে।

OpenAI: আমরা অনুসন্ধান (web_search) এবং পাইথন রানটাইম (code_interpreter) উভয় সক্ষম করে OpenAI Responses API মূল্যায়ন করি। GPT 5.5 (উচ্চ যুক্তি) অন্তর্নিহিত মডেল হিসেবে কাজ করে।

Anthropic: আমরা ২০০৬০৪০১ এজেন্ট টুলসেট এবং অটো-অনুমোদিত কমান্ড সহ Anthropic Managed Agents মূল্যায়ন করি। Opus 4.7 (উচ্চ যুক্তি) অন্তর্নিহিত মডেল হিসেবে কাজ করে।

Exa: আমরা প্রোডাকশন API-এর মাধ্যমে Exa Agent মূল্যায়ন করি, যেখানে প্রচেষ্টা উচ্চ সেট করা আছে।

Parallel: আমরা প্রোডাকশন API-এর মাধ্যমে Parallel Tasks মূল্যায়ন করি, যেখানে প্রসেসর ultra4x এ সেট করা আছে।

টেবিল ১ প্রতিটি সিস্টেমের জন্য বেঞ্চমার্ক স্কোর রিপোর্ট করে। পাঁচটি বেঞ্চমার্কের মধ্যে চারে SaC অন্যান্য সমস্ত সিস্টেমকে ছাড়িয়ে গেছে। বাকি বেঞ্চমার্কটিতে (HLE), SaC মূলত OpenAI Responses-এর সাথে প্রথম স্থানের জন্য টাই করেছে। ভূমিকা থেকে চিত্র ২ এই স্কোরগুলোকে গ্রাফিকাল আকারে ভিজ্যুয়ালাইজ করে।

বেঞ্চমার্ক	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
DSQA	0.871	0.733	0.815	0.530	0.810
BrowseComp	0.805	0.720	0.598	0.380	0.560
HLE	0.612	0.614	0.566	0.387	0.515
WideSearch	0.651	0.522	0.590	0.471	0.584
WANDR	0.386	0.130	0.152	0.057	0.126

টেবিল ১ | প্রতিটি মূল্যায়িত সিস্টেমের জন্য বেঞ্চমার্ক স্কোর। প্রতি সারির সেরা স্কোর বোল্ড করা।

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

মূল্যায়িত সিস্টেম জুড়ে WANDR স্কোর। Perplexity Agent API পরবর্তী-সেরা সিস্টেমকে ২.৫ গুণ ফ্যাক্টরে নেতৃত্ব দেয়।

পরিশেষে, আমরা একই Perplexity সার্চ অবকাঠামো ব্যবহার করে এমন একটি ঐতিহ্যগত সার্চ পাইপলাইনের বিপরীতে SaC-এর আপেক্ষিক লাভ পরিমাপ করি। চিত্র ৬ প্রতিটি বেঞ্চমার্ক জুড়ে SaC এবং অ-SaC আর্কিটেকচারের মধ্যে স্কোরের পার্থক্য রিপোর্ট করে। সার্বিকভাবে, SaC কর্মক্ষমতায় একটি যথেষ্ট বৃদ্ধি প্রদান করে, যেখানে DSQA-এ বৃহত্তম পরম লাভ (+১৯.৭৭ pp, ২৯%) এবং WANDR-এ বৃহত্তম আপেক্ষিক লাভ (+১২.০০ pp, ৪৫%) হয়েছে।

প্রতিটি বেঞ্চমার্কের বিপরীতে Perplexity বেসবলাইন বনাম SaC স্কোর, যেখানে পরম এবং আপেক্ষিক ডেল্টা টীকা দেওয়া আছে।

অনুশীলনে, ব্যবহারকারীরা খরচের তুলনায় কর্মক্ষমতা নিয়ে বেশি যত্ন নেন। তাই আমরা DSQA এবং WideSearch-এ খরচ-কর্মক্ষমতার সীমানা মূল্যায়ন করি। আমরা অন্যান্য সিস্টেমের পাশাপাশি নিম্ন, মাঝারি এবং উচ্চ মডেল যুক্তি স্তর জুড়ে SaC-এর খরচ এবং কর্মক্ষমতা মূল্যায়ন করি। চিত্র ৭ এবং ৮ প্রতি-টাস্ক দামের বিরুদ্ধে বেঞ্চমার্ক স্কোর প্লট করে, যেখানে x-অক্ষ বিপরীত করা হয়েছে যাতে আরও ডানের পয়েন্টগুলো সস্তা এবং উচ্চতর পয়েন্টগুলো ভালো কর্মক্ষমতা প্রতিনিধিত্ব করে।

DSQA স্কোর বনাম প্রতি-টাস্ক দাম। ড্যাশ করা লাইনটি SaC মডেল যুক্তির কনফিগারেশনগুলোকে সংযুক্ত করে।

DSQA-এ, তিনটি SaC সেটিংসই ওপর-ডান সীমানায় রয়েছে। নিম্ন যুক্তির সেটিংটি অন্যান্য সমস্ত সিস্টেমের চেয়ে সস্তা এবং তাদের দুটির চেয়ে ভালো পারফর্ম করে। মাঝারি যুক্তির সেটিংটি প্রতি টাস্কে $১ এর নিচে সমস্ত অ-SaC সিস্টেমকে ছাড়িয়ে গেছে। উচ্চ যুক্তির সেটিংটি একটি প্রতিযোগিতামূলক খরচে শীর্ষ কর্মক্ষমতা অর্জন করে।

WideSearch স্কোর বনাম প্রতি-টাস্ক দাম। ড্যাশ করা লাইনটি SaC মডেল যুক্তির কনফিগারেশনগুলোকে সংযুক্ত করে।

WideSearch অনুরূপ আকৃতির একটি সীমানা দেখায়। DSQA-এর মতো, নিম্ন যুক্তির সেটিংটি সমস্ত অ-SaC সিস্টেমের চেয়ে কম খরচে প্রতিযোগিতামূলক কর্মক্ষমতা অর্জন করে, যেখানে মাঝারি এবং উচ্চ উভয় যুক্তিই টাস্ক কর্মক্ষমতায় অ-SaC সিস্টেমকে ছাড়িয়ে যায়।

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

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

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

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

মডেলগুলোকে কেবল ফলাফল ব্যবহারের পরিবর্তে সার্চ প্রক্রিয়া নিয়ন্ত্রণ করার অনুমতি দেওয়ার জন্য আমরা SaC তৈরি করেছি। আমাদের ফলাফল এই নিয়ন্ত্রণের ক্ষমতা প্রমাণ করে: SaC জ্ঞান-নিবিড় এজেন্ট বেঞ্চমার্কগুলোতে পরম কর্মক্ষমতা এবং খরচ-কর্মক্ষমতা সীমানা উভয়কেই এগিয়ে নিয়ে যায়। Perplexity Computer এবং Agent API দিয়ে আজ থেকেই শুরু করে আমরা আমাদের ব্যবহারকারীদের কাছে SaC-এর ক্ষমতা আনতে উত্তেজিত। আমাদের ব্যবহারকারীদের (এবং তাদের সেবাদানকারী এজেন্টদের) কাছে সবচেয়ে শক্তিশালী এবং দক্ষ সার্চ ক্ষমতা রয়েছে তা নিশ্চিত করতে আমরা স্ট্যাকের সমস্ত স্তর জুড়ে SaC আর্কিটেকচার অপ্টিমাইজ করা চালিয়ে যাব।

BibTeX

@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}

ভূমিকা

প্রথাগত সার্চের অনমনীয়তা

অনমনীয়তা থেকে ব্যর্থতার মোডসমূহ

একটি প্রোগ্রামেবল সার্চ আর্কিটেকচার ডিজাইন করা

এজেন্টিক সার্চ SDK

স্যান্ডবক্স

মডেল

কোড অর্কেস্ট্রেটর এবং গ্যাপ ফিলার হিসেবে

কেস স্টাডি: CVE ভেন্ডর অ্যাডভাইজরি

মূল্যায়ন ফলাফল

বেঞ্চমার্ক এবং সিস্টেম

তুলনামূলক কর্মক্ষমতা

খরচ-কর্মক্ষমতার সীমানা

কম্পিউটিংয়ের একটি নতুন আর্কিটেকচারের দিকে

উদ্ধৃতি