Photon: স্ক্র্যাচ থেকে একটি রিট্রিভাল এবং র‍্যাঙ্কিং ইঞ্জিন তৈরি করা

ভূমিকা

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

এই চ্যালেঞ্জগুলি কাটিয়ে উঠতে, আমরা একটি নতুন ইন-হাউস রিট্রিভাল এবং র‍্যাঙ্কিং ইঞ্জিন Photon তৈরি করেছি। এটি স্ক্র্যাচ থেকে AI-প্রথমে সার্চ পরিকাঠামো তৈরি করার আমাদের দৃষ্টিভঙ্গি চালিয়ে যাচ্ছে, যেমনটি আমরা পৃষ্ঠা রেকর্ড পরিবেশনের জন্য আমাদের বিতরণ করা কি-ভ্যালু স্টোর CobbleDB এবং আমাদের Search API-এর সাথে করেছি।

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

Photon এখন আমাদের সার্চ পাইপলাইন পরিচালনা করে এবং আমাদের Search API-এর জন্য একটি নতুন ফাস্ট প্রিসেটের ভিত্তিও বটে, যার p50-এ 160 ms এবং p95-এ 230 ms একক-সার্চ-কল লেটেন্সি রয়েছে। ছয়টি পাবলিক বেঞ্চমার্ক জুড়ে, ফাস্ট প্রিসেটটি ডিফল্ট প্রিসেটের তুলনামূলক সামগ্রিক টাস্ক কোয়ালিটি বজায় রেখে প্রতি টাস্কে আনুমানিক মডেল-প্লাস-সার্চ খরচ ৬৮% কমিয়েছে। আমরা আজ এটি রিলিজ করছি যাতে ডেভেলপাররা এই উন্নতিগুলি অ্যাক্সেস করতে পারেন।

বড় করুন

বড় করুন

রিট্রিভাল এবং র‍্যাঙ্কিং ইঞ্জিন কী প্রয়োজন

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

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

যেখানে আমাদের পূর্ববর্তী সিস্টেম কম পড়েছিল

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

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

২. খারাপ টেল লেটেন্সি। প্রোডাকশন ট্রাফিকে, পুরানো সিস্টেমের p99 রেসপন্স টাইম ছিল প্রায় 800 ms। ডেটাসেট উপলব্ধ RAM অতিক্রম করেছে, তাই আমরা এটিকে সম্পূর্ণ মেমরিতে রাখতে ml_lock ব্যবহার করতে পারিনি। নন-রেসিডেন্ট ডেটা অ্যাক্সেস করা প্রধান পেজ ফল্ট ট্রিগার করতে পারে, অপারেটিং সিস্টেম ডিস্ক থেকে পড়ার সময় কোয়েরি এক্সিকিউশন স্তব্ধ করে দেয়।

ইঞ্জিনটি পর্যায়ক্রমে মেমরি থেকে ফ্লাশ করা ছোট ইনডেক্সগুলির সাথে এর প্রধান ডিস্ক ইনডেক্স একত্রিত করে। এই ডিস্ক ইনডেক্স ফিউশন প্রক্রিয়ার সময়, পেজ ফল্টের সংখ্যা আরও বেশি বেড়ে যায়, p99 লেটেন্সি 10-15 মিনিটের জন্য প্রায় 1.2 s এ পৌঁছে যায়। ক্যাচগুলি ওয়ার্ম আপ হওয়ার সাথে সাথে পেজ ফল্ট এবং লেটেন্সির ফ্রিকোয়েন্সি উভয়ই হ্রাস পেয়েছে, যা নির্দেশ করে যে কোল্ড রিড স্পাইকগুলিতে একটি প্রধান অবদানকারী ছিল। ডেটা প্রিলোড করা এবং ইনডেক্স ওয়ার্ম আপ করা স্পিকগুলি হ্রাস করেছে কিন্তু উচ্চ টেল লেটেন্সি পর্যাপ্তভাবে সমাধান করেনি।

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

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

সার্চ স্ট্যাকে Photon যেখানে মানানসই

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

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

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

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

বড় করুন

আমাদের ওয়ার্কফ্লোর জন্য Photon ডিজাইন করা

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

রিট্রিভাল এবং র‍্যাঙ্কিংয়ের জন্য ডেটা রিপ্রেজেন্টেশন

রিট্রিভাল এবং র‍্যাঙ্কিং ডকুমেন্ট ডেটা আলাদাভাবে অ্যাক্সেস করে। লেক্সিক্যাল রিট্রিভাল কোয়েরি টার্ম দিয়ে শুরু হয় এবং সেগুলিকে ধারণ করে এমন নথি খুঁজে বের করে। র‍্যাঙ্কিংয়ের তখন টার্ম ফ্রিকোয়েন্সি এবং পজিশন সহ প্রতিটি নির্বাচিত নথি সম্পর্কে বিস্তারিত তথ্যের প্রয়োজন হয়।

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

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

ইনভার্টেড ইনডেক্স

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

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

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

বড় করুন

একটি কাজ বাজেটের মধ্যে তালিকা অতিক্রম করা

সম্ভাব্য প্রাসঙ্গিক নথি খুঁজে পেতে ক্যান্ডিডেট নির্বাচনের জন্য পোস্টিং তালিকা অতিক্রম করার প্রয়োজন হয়। প্রতিটি তালিকা নিঃশেষ করে স্ক্যান করা ব্যয়বহুল, তাই Photon একটি WAND-এর মতো অ্যালগরিদম ব্যবহার করে যা অন্যদের মিলের হিসাব করার সময় শুধুমাত্র কিছু তালিকা অতিক্রম করে।

অ্যালগরিদম তালিকাগুলিকে দুটি গ্রুপে ভাগ করে। ড্রাইভিং তালিকাগুলি ট্রাভার্সাল এগিয়ে নিয়ে যায় এবং ক্যান্ডিডেট ডকুমেন্ট প্রস্তাব করে। প্রোব তালিকাগুলি সেই ক্যান্ডিডেটদের স্কোরে অবদান রাখে কিন্তু নিজেরা ক্যান্ডিডেট তৈরি করে না।

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

নির্বাচন তখন তিনটি ধাপে এগিয়ে যায়:

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

অ্যালগরিদম আরও র‍্যাঙ্কিংয়ে ব্যবহার করার জন্য প্রাসঙ্গিক নথির একটি ক্যান্ডিডেট সেট তৈরি করে।

বড় করুন

Docblob

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

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

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

বড় করুন

ব্যাচড রিড এবং মেমরির সাথে কাজ করা

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

বড় করুন

ওভারল্যাপিং ডিস্ক ওয়েট

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

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

ড্রাইভ অ্যাক্সেসের সংখ্যা হ্রাস করা

রিড জমা দেওয়ার আগে, Photon ইন-মেমরি ক্যাচে সম্পূর্ণ ব্যাচ চেক করে। শুধুমাত্র অনুপস্থিত রেকর্ডের জন্য অনুরোধ ডিস্কে যায়; পঠিত ডেটা তখন ক্যাচ পপুলেট করে।

ক্যাচটি ব্যাচড রিডের জন্য ডিজাইন করা হয়েছে। বিশেষ করে:

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

এই অপ্টিমাইজেশনগুলি আমাদের যত্ন নেওয়া ওয়ার্কলোডের কার্যক্ষমতার ক্ষতি না করেই লেটেন্সি কমায়।

পরিবেশন থেকে আলাদাভাবে ইনডেক্স তৈরি এবং আপডেট করা

Photon-এ, ইনডেক্স তৈরি এবং কোয়েরি পরিবেশন বিভিন্ন নোডে চলে। ইনডেক্সারগুলি ডেটাকে প্রস্তুত স্টোরেজ স্ট্রাকচারে রূপান্তর করে, যখন সার্ভিং নোডগুলি সেগুলি পড়ে এবং রিট্রিভাল ও র‍্যাঙ্কিং করে। ফলস্বরূপ, ইনডেক্স তৈরি CPU-এর জন্য সার্চ কোয়েরির সাথে প্রতিযোগিতা করে না, এবং এই কাজগুলির জন্য সম্পদগুলি স্বাধীনভাবে স্কেল করা যেতে পারে।

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

বড় করুন

প্রস্তুতি এবং বিতরণ করা বিল্ডিং

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

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

একটি নতুন সংস্করণ মোতায়েন করা

মোতায়েন করার আগে, কন্ট্রোলার চেক করে যে নতুন ইনডেক্স প্রস্তুত কিনা। ডেটা অসম্পূর্ণ হলে, মোতায়েন স্বয়ংক্রিয়ভাবে অবরুদ্ধ হয়।

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

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

বড় করুন

আমাদের সার্চ স্ট্যাকের মধ্যে মাইগ্রেশন এবং ভ্যালিডেশন

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

লোড পরীক্ষা এবং মূল্যায়ন

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

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

প্রোডাকশনে পরিমাপ করা উন্নতি

আমাদের প্রোডাকশন ওয়ার্কফ্লোতে, p99 প্রতিক্রিয়া সময় পুরানো সিস্টেমে প্রায় 800 ms থেকে Photon-এ প্রায় 65 ms-এ নেমে এসেছে। এই পরিমাপ Photon-এর ভেতরের সমস্ত পর্যায় কভার করে, কিন্তু উচ্চ-স্তরের সার্চ স্ট্যাকে পরবর্তী পর্যায়গুলি বাদ দেয়। আমরা আর ইনডেক্স সংস্করণ স্যুইচ করার সাথে পূর্বে যুক্ত লেটেন্সি স্পাইকগুলি লক্ষ্য করি না।

Photon পুরানো সিস্টেমের কন্টেন্ট নোডের চেয়ে প্রায় ২০% কম সমতুল্য সার্ভিং মেশিন ব্যবহার করে প্রতি নথিতে প্রায় ২.৫ গুণ বেশি ডেটা সংরক্ষণ করে। মাইগ্রেশনের পরে, আমরা পুরানো সিস্টেমের বাইরে র‍্যাঙ্কিংয়ের গুণমান উন্নত করতে এই অতিরিক্ত ডেটা ব্যবহার করেছি।

Photon মেমরিতে যে পরিমাণ ডেটা রাখতে হবে তাও কমিয়ে দেয়। ml_lock সহ RAM-এ একই Photon ডেটাসেট পিন করার জন্য Photon বর্তমানে যা ব্যবহার করে তার আনুমানিক ৪.৬ গুণ বেশি রেসিডেন্ট মেমরির প্রয়োজন হবে।

ফাস্ট Search API প্রিসেটের মূল্যায়ন

আমরা আমাদের Search API-এর জন্য একটি নতুন ফাস্ট প্রিসেটের ভিত্তি হিসাবে Photon ব্যবহার করেছি, যা লেটেন্সি-সংবেদনশীল ওয়ার্কফ্লোর জন্য ডিজাইন করা হয়েছে। আমাদের পরিমাপ অনুযায়ী, ফাস্ট প্রিসেটের জন্য একক-সার্চ-কল লেটেন্সি p50-এ 160 ms এবং p95-এ 230 ms, অন্যান্য Search API প্রদানকারীদের স্ব-রিপোর্ট করা নম্বরের চেয়ে কম বা তুলনামূলক, যদিও রিপোর্ট করা টেল পার্সেন্টাইলগুলি আলাদা।

আমরা ছয়টি এজেন্টিক বেঞ্চমার্কে ফাস্ট প্রিসেটের মূল্যায়ন করেছি: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 এবং SEAL-Hard। এই মূল্যায়ন জুড়ে, পরীক্ষিত কনফিগারেশনগুলির মধ্যে এটির সর্বনিম্ন অনুমানিত মোট মডেল-প্লাস-সার্চ খরচ এবং সর্বোচ্চ সামগ্রিক টাস্ক স্কোর ছিল।

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

বড় করুন

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

উপসংহার

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

Photon Perplexity-এর পণ্য জুড়ে দ্রুত অনুসন্ধান সক্ষম করেছে এবং Search API-তে আমাদের নতুন ফাস্ট প্রিসেটের ভিত্তি প্রদান করে। মাইগ্রেশনের পরে, p99 রিট্রিভাল-অ্যান্ড-র‍্যাঙ্কিং লেটেন্সি প্রায় 800 ms থেকে কমে 65 ms হয়েছে। আমাদের কমপ্যাক্ট ডেটা ফরম্যাটগুলি আমাদের প্রতি নথিতে ২.৫ গুণ বেশি ডেটা সংরক্ষণ করতে দেয়, যা রিট্রিভাল এবং র‍্যাঙ্কিংকে সমৃদ্ধ ডকুমেন্ট তথ্য অ্যাক্সেস করতে দেয়।

ফাস্ট প্রিসেটটি p50-এ 160 ms এবং p95-এ 230 ms-এর একক-সার্চ-কল লেটেন্সি প্রদান করে। মূল্যায়িত ছয়টি এজেন্টিক বেঞ্চমার্ক জুড়ে, এটি ডিফল্ট প্রিসেটের তুলনায় প্রতি টাস্কে আনুমানিক মডেল-প্লাস-সার্চ খরচ ৬৮% কমিয়েছে এবং তুলনামূলক সমষ্টিগত টাস্ক কোয়ালিটি বজায় রেখেছে। এই ফলাফলগুলি আমাদের সার্চ ওয়ার্কলোডগুলির চারপাশে ডিজাইন করা পরিকাঠামোর ব্যবহারিক সুবিধাগুলি প্রদর্শন করে, Perplexity-এর পণ্য এবং আমাদের API-এর সাহায্যে তৈরি ডেভেলপার উভয়ের জন্যই।

আমরা Photon-এর কার্যক্ষমতা এবং স্টোরেজ দক্ষতা উন্নত করা চালিয়ে যাচ্ছি। আমাদের লক্ষ্য হল আমাদের ওয়ার্কলোড বৃদ্ধির সাথে সাথে অনুসন্ধান দ্রুত রেখে একই হার্ডওয়ারে একটি বড় ইনডেক্স এবং সমৃদ্ধ ডকুমেন্ট ডেটা সমর্থন করা।

উদ্ধৃতি

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}