Qdrant না Weaviate—৪.৫৫ ms গতি আর ৯৯% recall ভিন্ন বিজয়ী দেয়

২০২৬ সালের স্বাধীন SIFT1M পরীক্ষায় ডিফল্ট কনফিগারেশনে Qdrant পূর্ণাঙ্গ ডেটাবেসগুলোর মধ্যে ৪.৫৫ ms মধ্যম লেটেন্সিতে দ্রুততম হলেও তার Recall@100 ছিল ৯৫.৯%; Weaviate-এর রিকল ছিল ৯৯%-এর বেশি, নির্দিষ্ট হিসাবে ৯৯.৬%। দ্রুত ভেক্টর অনুসন্ধান অগ্রাধিকার হলে Qdrant, আর সেটিং না বদলে প্রকৃত নিকটতম ফল বেশি ফেরানো জরুরি হলে Weaviate শক্তিশালী প্রার্থী।

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

স্বাধীন পরীক্ষায় আসলে কী এগিয়েছে

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

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

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

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

সমান রিকল ছাড়া গতির তুলনা অসম্পূর্ণ

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

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

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

প্রতিষ্ঠানগুলোর প্রকাশিত পরীক্ষায় পার্থক্য কোথায়

Weaviate-এর এএনএন বেঞ্চমার্কে প্রতিটি কনফিগারেশনে ১০,০০০ ফিল্টারবিহীন অনুরোধ চালিয়ে রিকলের পাশে থ্রুপুট, গড় লেটেন্সি ও শেষ প্রান্তের লেটেন্সি দেখানো হয়েছে; থ্রুপুট মাপা হয়েছে ৩০-কোর যন্ত্রে সমান্তরাল অনুরোধ দিয়ে। ইনডেক্স তৈরির ও অনুসন্ধানের পরামিতি বদলালে Weaviate-এর মানগুলো কীভাবে সরছে, তা বোঝার জন্য এই তথ্য কাজে লাগে। এটি অন্য প্রতিষ্ঠানের যন্ত্রে বা পদ্ধতিতে পাওয়া সংখ্যার সঙ্গে সরাসরি প্রতিযোগিতার ফল নয়।

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

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

ফিল্টারযুক্ত অনুসন্ধানে পরিচালনার খরচ

বাস্তব RAG অনুসন্ধানে শুধু অর্থের মিল যথেষ্ট হয় না। গ্রাহক, ভাষা, নথির ধরন বা প্রকাশের সময় দিয়ে ফল সীমিত করতে হতে পারে। এতে কত ভেক্টর পরীক্ষার যোগ্য থাকবে, তা বদলে যায়; ফিল্টারবিহীন SIFT1M ফল থেকে সেই অবস্থায় Qdrant বা Weaviate-এর আপেক্ষিক গতি নির্ণয় করা যায় না।

Qdrant-এর ফিল্টার নির্দেশনা ঘন ভেক্টর অনুসন্ধানে ব্যবহৃত তথ্যক্ষেত্রের পেলোড ইনডেক্স তথ্য যোগ করার আগে তৈরির পরামর্শ দেয়; পরিকল্পনাকারী যোগ্য ফল কম হলে সরাসরি হিসাব করে, বেশি হলে ফিল্টার সমর্থিত HNSW গ্রাফে খোঁজে। ইনডেক্স পরে যোগ করলেও ফিল্টার কাজ করে, কিন্তু গ্রাফে ওই ক্ষেত্রের অতিরিক্ত সংযোগ পেতে সেটি পুনর্গঠন করতে হয়। একাধিক কঠোর ফিল্টারে রিকল কমলে ACORN অনুসন্ধান কৌশলও ব্যবহার করা যায়।

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

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

RAG-এর জন্য কোনটি বাছবেন

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

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

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

আরও পড়ুন:

• Runway না Adobe Firefly—ভালো motion আর সহজ editing একই বিজয়ী দেয় না
• Bitwarden না 1Password—কম দাম আর সহজ family sharing একই বিজয়ী দেয় না
• ChatGPT না Gemini—এক পরীক্ষায় গতি, অন্যটিতে বাস্তব সিদ্ধান্ত এগিয়ে