এআই ইঞ্জিনিয়ারিংয়ের দৃষ্টিকোণ থেকে ভেক্টর ডেটাবেস: একটি পূর্ণাঙ্গ গাইড
কৃত্রিম বুদ্ধিমত্তা বা আর্টিফিশিয়াল ইন্টেলিজেন্স (AI) এর আধুনিক যুগে ডেটাবেস আর্কিটেকচারে এক অভাবনীয় পরিবর্তন এসেছে। ঐতিহাসিকভাবে, রিলেশনাল বা NoSQL ডেটাবেসগুলো সুনির্দিষ্ট কাঠামোর (structured) ডেটা সংরক্ষণের জন্য ব্যবহৃত হয়ে আসছে। একটি সাধারণ রিলেশনাল ডেটাবেসে "apple" শব্দটি কেবল ৫টি অক্ষরের একটি সাধারণ স্ট্রিং বা শব্দগুচ্ছ; এর কোনো অন্তর্নিহিত অর্থ বা অন্য কোনো শব্দের সাথে সম্পর্ক ডেটাবেসটি বোঝে না। কিন্তু বর্তমানের ডিপ লার্নিং (Deep Learning), লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) এবং মাল্টিমোডাল এআই-এর যুগে আনস্ট্রাকচার্ড ডেটা (যেমন- টেক্সট, ছবি, জিনোমিক সিকোয়েন্স বা অডিও) নিয়ে কাজ করা অপরিহার্য হয়ে উঠেছে। এই বিশাল আনস্ট্রাকচার্ড ডেটাকে রিপ্রেজেন্ট করার জন্য এআই মডেলগুলো হাই-ডাইমেনশনাল নিউমেরিক্যাল অ্যারে বা "ভেক্টর এমবেডিং" (Vector Embedding) তৈরি করে। এই ভেক্টরগুলোকে সংরক্ষণ এবং দ্রুত অনুসন্ধান করার জন্যই উদ্ভাবন হয়েছে ভেক্টর ডেটাবেসের।
একটি ভেক্টর ডেটাবেস ডেটার গাণিতিক অবস্থান বোঝে; এটি জানে যে "apple" গাণিতিকভাবে "laptop" এর চেয়ে "fruit" এর অনেক কাছাকাছি অবস্থিত। এই ব্লগে আমরা এআই ইঞ্জিনিয়ারিংয়ের দৃষ্টিকোণ থেকে ভেক্টর ডেটাবেসের কোর আর্কিটেকচার, ইনডেক্সিং অ্যালগরিদম, কোয়ান্টাইজেশন, হাইব্রিড সার্চ এবং প্রোডাকশন স্কেলে হার্ডওয়্যার প্ল্যানিং নিয়ে বিস্তারিত আলোচনা করব।
রিলেশনাল ডেটাবেস বনাম ভেক্টর ডেটাবেস
রিলেশনাল ডেটাবেসগুলো সাধারণত B-tree ইনডেক্স ব্যবহার করে এক্সাক্ট ম্যাচ (exact match), রেঞ্জ কুয়েরি বা লজিক্যাল কন্ডিশন মিলিয়ে ডেটা খুঁজে বের করতে অত্যন্ত দক্ষ। কিন্তু হাই-ডাইমেনশনাল জিওমেট্রিক স্পেসে "এক্সাক্ট ম্যাচ" বলে কিছু নেই; এখানে কুয়েরিটি হয় "এই কুয়েরি ভেক্টরের জ্যামিতিকভাবে সবচেয়ে কাছের ভেক্টরগুলো খুঁজে বের করো"।
রিলেশনাল আর্কিটেকচারগুলো এই ধরনের কাজের জন্য উপযুক্ত নয়। সবচেয়ে কাছের ভেক্টর (Exact nearest neighbors) বের করতে হলে কুয়েরি ভেক্টরের সাথে ডেটাবেসের প্রতিটি ভেক্টরের দূরত্ব মাপতে হয়। একে ব্রুট-ফোর্স (brute-force) স্ক্যান বলা হয়। গাণিতিকভাবে এর টাইম কমপ্লেক্সিটি হলো:
O(N × d)
যেখানে N হলো মোট ভেক্টরের সংখ্যা এবং d হলো ডাইমেনশন। মিলিয়ন বা বিলিয়ন ১,৫৩৬-ডাইমেনশনাল ভেক্টরের ক্ষেত্রে এই ব্রুট-ফোর্স স্ক্যান করা অসম্ভব ধীরগতির। এই সমস্যা সমাধানে ভেক্টর ডেটাবেসগুলো Approximate Nearest Neighbor (ANN) অ্যালগরিদম ব্যবহার করে। এর ফলে নিখুঁত ফলাফলের সাথে খুব সামান্য আপস করে সার্চের গতি বহুগুণ (লগারিদমিক স্কেলে) বাড়িয়ে তোলা যায়, যা Retrieval-Augmented Generation (RAG) বা সিম্যান্টিক সার্চের জন্য অপরিহার্য।
অ্যালগরিদমিক ভিত্তি: HNSW (Hierarchical Navigable Small World)
ভেক্টর ডেটাবেসের মূল চালিকাশক্তি হলো এর ইনডেক্সিং অ্যালগরিদম। বর্তমানে ইন-মেমোরি ANN সার্চের জন্য সবচেয়ে জনপ্রিয় এবং কার্যকর অ্যালগরিদম হলো HNSW। HNSW মূলত দুটি বিখ্যাত কম্পিউটার সায়েন্স কনসেপ্টের সমন্বয়ে গঠিত: প্রোবাবিলিটি স্কিপ লিস্ট (Probability skip list) এবং স্মল-ওয়ার্ল্ড নেটওয়ার্ক (Small-world network)।
স্কিপ লিস্ট হলো এমন একটি ডেটা স্ট্রাকচার, যা একাধিক লেয়ার বা স্তরের মাধ্যমে ডেটা সাজায়। একদম নিচের স্তরে সব ডেটা থাকে, আর উপরের স্তরগুলোতে সূচকীয় হারে (exponentially) কম ডেটা থাকে। এতে সার্চ অ্যালগরিদম খুব দ্রুত অনেক ডেটা "স্কিপ" বা পার হয়ে যেতে পারে। অন্যদিকে, স্মল-ওয়ার্ল্ড নেটওয়ার্কে বেশিরভাগ নোড সরাসরি সংযুক্ত না থাকলেও, তাদের মধ্যে এমন কিছু শর্টকাট কানেকশন থাকে যার সাহায্যে খুব অল্প কয়েক ধাপে যেকোনো নোডে পৌঁছানো যায়।
HNSW এই দুটি ধারণাকে একত্রিত করে একটি মাল্টি-লেয়ার গ্রাফ তৈরি করে। যখন কোনো সার্চ কুয়েরি আসে, তখন অ্যালগরিদমটি সবচেয়ে উপরের স্তর (L_max) থেকে তার গ্রিডি রাউটিং (Greedy routing) শুরু করে। উপরের স্তরে কাঙ্ক্ষিত ভেক্টরের কাছাকাছি পৌঁছানোর পর এটি নিচের স্তরে নেমে আসে এবং আরও সূক্ষ্মভাবে সার্চ করতে থাকে। একদম নিচের স্তরে (L_0) পৌঁছালে এটি সবচেয়ে কাছের ভেক্টরগুলোকে খুঁজে পায়।
HNSW এর পারফরম্যান্স কিছু প্যারামিটারের ওপর নির্ভর করে:
- M: একটি নতুন ভেক্টর গ্রাফে যুক্ত করার সময় সর্বোচ্চ কয়টি এজ (edges) বা কানেকশন তৈরি হবে। এর মান বেশি হলে মেমোরি বেশি লাগে, তবে রিকল (recall) বা অ্যাকুরেসি বাড়ে।
- ef_construction: ইনডেক্স তৈরির সময় কতগুলো সম্ভাব্য নোড পরীক্ষা করা হবে। এর মান বেশি হলে ইনডেক্সের মান ভালো হয়, কিন্তু ইনডেক্স তৈরি হতে সময় বেশি লাগে।
- ef_search: সার্চ করার সময় কতগুলো নোড ট্র্যাক করা হবে। এটি লেটেন্সি এবং রিকল উভয়ের ওপর প্রভাব ফেলে।
তবে HNSW এর একটি বড় সমস্যা হলো ডেটা ডিলিট করা। গ্রাফের কাঠামো ঠিক রাখতে সরাসরি ডিলিট না করে অনেক ডেটাবেস "সফট-ডিলিট" (tombstoning) ব্যবহার করে, যা সময়ের সাথে সাথে মেমোরি ফ্র্যাগমেন্টেশন তৈরি করে এবং সার্চের গতি কমিয়ে দেয়।
ভেক্টর কম্প্রেশন: কোয়ান্টাইজেশন মেথডোলজি
হাই-ডাইমেনশনাল ভেক্টর প্রচুর র্যাম (RAM) দখল করে। একটি ১,৫৩৬ ডাইমেনশনের float32 ভেক্টর স্টোর করতে প্রায় ৬,১৪৪ বাইট মেমোরি লাগে। ১০০ মিলিয়ন ভেক্টরের জন্য শুধু ভেক্টর ডেটার জন্যই ৬১৪ জিবির (GB) বেশি মেমোরি প্রয়োজন। এন্টারপ্রাইজ স্কেলে এই বিশাল খরচ কমানোর জন্য কোয়ান্টাইজেশন (Quantization) বা লসি কম্প্রেশন (lossy compression) টেকনিক ব্যবহার করা হয়।
১. Scalar Quantization (SQ): এটি প্রতিটি ডাইমেনশনকে স্বাধীনভাবে float32 থেকে ৮-বিট ইন্টিজারে (int8) রূপান্তর করে, ফলে মেমোরি ৪ গুণ কমে যায়।
২. Binary Quantization (BQ): এটি প্রতিটি ডাইমেনশনকে মাত্র ১ বিটে (পজিটিভ বা নেগেটিভ) রূপান্তর করে। এতে মেমোরি ৩২ গুণ কমে যায় এবং হ্যামিং ডিস্টেন্স (Hamming distance) ব্যবহার করে সার্চ অত্যন্ত দ্রুত হয়। তবে এক্যুরেসি ধরে রাখতে এখানে রি-স্কোরিং (rescoring) প্রক্রিয়ার প্রয়োজন হয়।
৩. Product Quantization (PQ): বিলিয়ন স্কেলের ডেটাবেসের জন্য এটি সবচেয়ে বেশি ব্যবহৃত হয়। PQ একটি বড় ভেক্টরকে ছোট ছোট সাব-ভেক্টরে (sub-vectors) ভাগ করে এবং প্রতিটি সাব-ভেক্টরের জন্য k-means ক্লাস্টারিং ব্যবহার করে সেন্ট্রয়েড (centroid) বের করে। মূল ভেক্টরটির বদলে শুধুমাত্র সেন্ট্রয়েড আইডিগুলো স্টোর করা হয়, যা মেমোরি ফুটপ্রিন্টকে ১০ থেকে ১০০ গুণ পর্যন্ত কমিয়ে আনতে পারে।
সার্চ করার সময় Asymmetric Distance Computation (ADC) ব্যবহার করা হয়। এখানে কুয়েরি ভেক্টরটিকে ফুল-প্রিসিশনে রেখে ডেটাবেসের কম্প্রেসড ভেক্টরগুলোর সাথে দূরত্ব নির্ণয় করা হয় একটি প্রি-কম্পিউটেড লুক-আপ টেবিলের মাধ্যমে:
d(q, x)^2 ≈ ∑ ||q_s - C_s[b_s]||^2
এটি সার্চ স্পিড বহুগুণ বাড়িয়ে দেয় এবং কোয়ান্টাইজেশন এরর কমিয়ে রাখে।
ডিস্ক-ভিত্তিক ইনডেক্সিং এবং র্যামের সীমাবদ্ধতা জয়
HNSW ইনডেক্সকে র্যামে রাখা বাধ্যতামূলক কারণ এটি গ্রাফ ট্রাভার্স করার সময় র্যান্ডম মেমোরি এক্সেস করে। সাধারণ SSD-তে এই র্যান্ডম রিড লেটেন্সি অনেক বেশি হয়। কিন্তু মেমোরির সীমাবদ্ধতা কাটাতে আধুনিক ডেটাবেসগুলো DiskANN বা Vamana গ্রাফের মতো ডিস্ক-ভিত্তিক অ্যালগরিদম নিয়ে এসেছে।
এটি একটি তিন-স্তরের আর্কিটেকচার ব্যবহার করে: ১. মেমোরি লেয়ারে কম্প্রেসড নেভিগেশন ভেক্টর রাখা হয়। ২. ডিস্ক স্টোরেজ লেয়ারে (NVMe SSD) ফুল-প্রিসিশন ভেক্টর এবং সম্পূর্ণ গ্রাফ রাখা হয়। ৩. গ্রাফের গঠন এমনভাবে করা হয় যেন ডিস্ক থেকে পড়ার সময় সিকুয়েনশিয়াল রিড (sequential read) করা যায়, যা র্যান্ডম সিক (random seek) এড়িয়ে লেটেন্সি কমিয়ে দেয়।
অ্যাডভান্সড রিপ্রেজেন্টেশন: ColBERT এবং MRL
একটি বড় ডকুমেন্টকে মাত্র একটি সিঙ্গেল ভেক্টরে রূপান্তর করলে অনেক সময় সূক্ষ্ম তথ্য হারিয়ে যায়। ColBERT (Contextualized Late Interaction over BERT) এই সমস্যার সমাধানে টোকেন-লেভেলের এমবেডিং ব্যবহার করে। এটি পুরো ডকুমেন্টের জন্য একটি ম্যাট্রিক্স তৈরি করে এবং সার্চের সময় MaxSim অপারেটর ব্যবহার করে প্রতিটি কুয়েরি টোকেনের সাথে ডকুমেন্টের টোকেনগুলো মেলায়:
S_{q,d} = ∑ max(v_i · u_j^T)
এটি অত্যন্ত নিখুঁত হলেও স্টোরেজ এবং কম্পিউটেশন অনেক বেশি নেয়। এই লেটেন্সি কমানোর জন্য PLAID (Performance-optimized Late Interaction Driver) ইঞ্জিন তৈরি করা হয়েছে, যা সেন্ট্রয়েড ইন্টারেকশন এবং প্রুনিং ব্যবহার করে CPU এবং GPU-তে সার্চ স্পিড বহুগুণ বাড়িয়ে দেয়।
অন্যদিকে, Matryoshka Representation Learning (MRL) এমন একটি মডেল ট্রেইনিং টেকনিক, যেখানে একটি বড় এমবেডিং ভেক্টরের শুরুর দিকের ডাইমেনশনগুলোতেই সবচেয়ে গুরুত্বপূর্ণ সিম্যান্টিক ইনফরমেশন স্টোর করা হয়। এর ফলে প্রয়োজনে ভেক্টরটিকে কেটে (truncate) ছোট করে ফেললেও (যেমন ৩০৭২ থেকে ২৫৬ ডাইমেনশন) রিকল বা অ্যাকুরেসি খুব একটা কমে না। এটি স্টোরেজ এবং সার্চ লেটেন্সি উল্লেখযোগ্যভাবে কমিয়ে দেয়।
হাইব্রিড সার্চ: সিম্যান্টিক এবং মেটাডেটা ফিল্টারিং
প্র্যাকটিক্যাল এআই অ্যাপ্লিকেশনে শুধু সিম্যান্টিক সার্চ যথেষ্ট নয়; এর সাথে বিভিন্ন বুলিয়ান মেটাডেটা ফিল্টারও (যেমন- নির্দিষ্ট অথর, ডেট রেঞ্জ বা ইউজার আইডি) প্রয়োগ করতে হয়।
- Pre-filtering: আগে মেটাডেটা দিয়ে ফিল্টার করে তারপর ভেক্টর সার্চ করা হয়। ফিল্টার হওয়া ডেটার পরিমাণ মাঝারি হলে HNSW গ্রাফটি বিচ্ছিন্ন হয়ে যেতে পারে এবং সার্চ ফেইল করতে পারে।
- Post-filtering: আগে ভেক্টর সার্চ করে পরে মেটাডেটা ফিল্টার করা হয়। এতে অনেক প্রাসঙ্গিক ডেটা যা মেটাডেটা ফিল্টারে পাস হতো, তা টপ-K রেজাল্টে না আসার কারণে বাদ পড়ে যেতে পারে।
এর সমাধানে আধুনিক ডেটাবেসগুলো সিঙ্গেল-পাস ট্রাভার্সাল (single-pass traversal) ব্যবহার করে। বিশেষ করে স্ট্যানফোর্ডের ACORN (ANN Constraint-Optimized Retrieval Network) একটি নতুন পদ্ধতি নিয়ে এসেছে, যা ফিল্টার ফেল করা নোডগুলোকেও ব্রিজ হিসেবে ব্যবহার করে "টু-হপ (two-hop)" এক্সপেনশন করে, ফলে গ্রাফ কানেক্টিভিটি বজায় থাকে এবং লেটেন্সি কমে যায়।
এছাড়া সিম্যান্টিক ডেন্স ভেক্টর সার্চ এবং লেক্সিক্যাল স্পার্স সার্চের (যেমন BM25) রেজাল্ট একসাথে মেলানোর জন্য Reciprocal Rank Fusion (RRF) ব্যবহার করা হয়। RRF কোনো কাঁচা স্কোরের ওপর নির্ভর না করে শুধুমাত্র ডকুমেন্টের র্যাংকিংয়ের ওপর ভিত্তি করে নতুন স্কোর তৈরি করে:
RRFScore(d) = ∑ 1 / (k + r(d))
যেখানে k হলো একটি কনস্ট্যান্ট (সাধারণত ৬০), যা স্কোরের ভারসাম্য বজায় রাখে।
সিস্টেম আর্কিটেকচার এবং স্কেলিং
ভেক্টর ডেটাবেসের জগতে মূলত দুটি ধারা দেখা যায়:
১. পারপাস-বিল্ট আর্কিটেকচার (Purpose-built architectures): Milvus বা Qdrant এর মতো সিস্টেমগুলো একদম শুরু থেকেই বিশাল স্কেলের ভেক্টর অপারেশনের জন্য তৈরি। Milvus স্টোরেজ এবং কম্পিউট নোডগুলোকে (স্ট্রিমিং নোড, কুয়েরি নোড, ডেটা নোড) আলাদা করে অত্যন্ত হাই-থ্রুপুট ইনজেশন এবং ডিস্ট্রিবিউটেড স্কেলিং নিশ্চিত করে। Qdrant পেলোড ইনডেক্সিং এবং mmap মেমোরি ম্যানেজমেন্টের মাধ্যমে ফিল্টারিং পারফরম্যান্স ধরে রাখে।
২. রিলেশনাল ডেটাবেস এক্সটেনশন: PostgreSQL (pgvector) বা SingleStore এর মতো ট্র্যাডিশনাল ডেটাবেসগুলোতে ভেক্টর সার্চ এক্সটেনশন হিসেবে যুক্ত করা হয়েছে। এর প্রধান সুবিধা হলো বিদ্যমান ACID কমপ্লায়েন্স এবং ইউনিফায়েড ডেটা ম্যানেজমেন্ট। তবে বিলিয়ন স্কেলের ডেটার ক্ষেত্রে বা র্যামের লিমিটেশন ক্রস করলে (out-of-memory) এগুলো স্পেশালাইজড ডেটাবেসের তুলনায় পিছিয়ে পড়ে।
হার্ডওয়্যার ক্যাপাসিটি প্ল্যানিং
ভেক্টর ডেটাবেস ডিপ্লয় করার আগে মেমোরি রিকোয়ারমেন্ট ক্যালকুলেট করা একজন এআই ইঞ্জিনিয়ারের অন্যতম প্রধান কাজ।
১. Raw Vector Size: $১,০০০,০০০$ টি ১,৫৩৬-ডাইমেনশনাল float32 ভেক্টরের জন্য বেস স্টোরেজ প্রয়োজন প্রায় $৬.১৪$ জিবি (GB)।
২. HNSW Overhead: HNSW গ্রাফের এজ স্টোর করার জন্য মূল ভেক্টর সাইজের ওপর ভিত্তি করে মেমোরি লাগে। সাধারণত M=16 হলে এই ওভারহেড মূল সাইজের প্রায় ২৫% বা তার বেশি হয়।
এছাড়াও পেলোড মেটাডেটা এবং রেপ্লিকা ফ্যাক্টরের জন্য মেমোরি ক্যালকুলেট করতে হয় এবং প্রোডাকশনে OOM (Out Of Memory) ক্র্যাশ এড়াতে ২০-৩০% অতিরিক্ত স্পেস ফাঁকা রাখতে হয়।
বেঞ্চমার্কিং
ভেক্টর ডেটাবেসের পারফরম্যান্স মাপার জন্য SIFT1M (১২৮ ডাইমেনশন) বা GIST1M (৯৬০ ডাইমেনশন) এর মতো স্ট্যান্ডার্ড ডেটাসেট ব্যবহার করা হয়। মূলত তিনটি মেট্রিকের ওপর ভিত্তি করে বেঞ্চমার্কিং হয়:
- Recall@K: ট্রু নিয়ারেস্ট নেইবরের কত অংশ ডেটাবেসটি সফলভাবে খুঁজে পেয়েছে।
- QPS (Queries Per Second): একটি নির্দিষ্ট রিকল (যেমন- ০.৯৫) ফিক্সড রেখে প্রতি সেকেন্ডে কতগুলো কুয়েরি প্রসেস করা যাচ্ছে।
- Latency (p99): ৯৯% কুয়েরি প্রসেস হতে সর্বোচ্চ কত মিলি-সেকেন্ড সময় লাগছে।
উপসংহার
ভেক্টর ডেটাবেস বর্তমানে এআই ইনফ্রাস্ট্রাকচারের একটি অবিচ্ছেদ্য অংশ। এটি শুধু সাদামাটা কিছু ডিস্টেন্স ক্যালকুলেশন নয়, বরং বিশাল স্কেলে হাই-ডাইমেনশনাল ডেটা প্রসেসিং, কোয়ান্টাইজেশনের মাধ্যমে মেমোরি অপটিমাইজেশন এবং জটিল মেটাডেটা ফিল্টারিংয়ের এক অপূর্ব গাণিতিক ও ইঞ্জিনিয়ারিং সমন্বয়। একটি সফল প্রোডাকশন-গ্রেড এআই সিস্টেম তৈরি করতে হলে ডেটাসেটের ধরন, লেটেন্সি রিকোয়ারমেন্ট এবং বাজেটের ওপর ভিত্তি করে সঠিক ইনডেক্স এবং আর্কিটেকচার নির্বাচন করা অত্যন্ত জরুরি।
সচরাচর জিজ্ঞাসিত প্রশ্নাবলী
১. ভেক্টর ডেটাবেস (Vector Database) আসলে কী এবং সাধারণ ডেটাবেসের সাথে এর মৌলিক পার্থক্য কোথায়?
ভেক্টর ডেটাবেস হলো এমন এক বিশেষায়িত ডেটা ম্যানেজমেন্ট সিস্টেম যা হাই-ডাইমেনশনাল ভেক্টর এমবেডিং সংরক্ষণ, ইনডেক্সিং এবং দ্রুত অনুসন্ধান (Similarity Search) করতে সক্ষম। সাধারণ রিলেশনাল বা NoSQL ডেটাবেস টেক্সট বা সংখ্যাকে সুনির্দিষ্ট মান (Exact Match বা B-tree Range) হিসেবে বিবেচনা করে। অন্যদিকে ভেক্টর ডেটাবেস ডেটার গাণিতিক ও অর্থগত অবস্থান (Semantic Distance) পরিমাপ করে। এটি কি-ওয়ার্ড না মিলিয়ে "কুয়েরি ভেক্টরের সবচেয়ে কাছাকাছি অর্থ বহনকারী ভেক্টরগুলো" দ্রুত খুঁজে বের করে।
২. এআই অ্যাপ্লিকেশনে RAG (Retrieval-Augmented Generation)-এর জন্য ভেক্টর ডেটাবেস কেন অপরিহার্য?
লার্জ ল্যাঙ্গুয়েজ মডেল (LLM)-এর একটি বড় সীমাবদ্ধতা হলো জ্ঞানের নির্দিষ্ট কাট-অফ ডেট এবং হ্যালুসিনেশন। RAG আর্কিটেকচারে এন্টারপ্রাইজের অভ্যন্তরীণ বা লেটেস্ট ডকুমেন্টগুলোকে চাঙ্ক করে ভেক্টর এমবেডিংয়ে রূপান্তর করা হয় এবং ভেক্টর ডেটাবেসে রাখা হয়। ইউজার যখন কোনো প্রশ্ন করেন, ভেক্টর ডেটাবেস মিলিসেকেন্ডের মধ্যে সবচেয়ে প্রাসঙ্গিক কনটেক্সট খুঁজে এনে এলএলএম-কে সরবরাহ করে। ফলে এলএলএম নিজস্ব অনুমানের ওপর নির্ভর না করে সঠিক তথ্যের ওপর ভিত্তি করে বাস্তবসম্মত উত্তর জেনারেট করতে পারে।
৩. ভেক্টর ইনডেক্সিংয়ে HNSW (Hierarchical Navigable Small World) কীভাবে কাজ করে?
HNSW হলো একটি মাল্টি-লেয়ার গ্রাফ ডেটা স্ট্রাকচার যা স্কিপ লিস্ট এবং স্মল-ওয়ার্ল্ড নেটওয়ার্কের মেলবন্ধনে তৈরি। একদম শীর্ষ স্তরে অল্প কিছু নোড এবং লং-রেঞ্জ কানেকশন বা এক্সপ্রেস হাইওয়ে থাকে, যা দিয়ে কুয়েরি পয়েন্টের কাছাকাছি দ্রুত যাওয়া যায় (Greedy Routing)। এরপর অ্যালগরিদম ক্রমান্বয়ে নিচের স্তরগুলোতে নেমে এসে সূক্ষ্ম লোকাল নেইবারগুলো যাচাই করে। একদম ভিত্তি স্তর $L_0$-তে এটি নিখুঁত ও নিকটবর্তী ভেক্টরগুলোকে চিহ্নিত করে। এর ফলে সম্পূর্ণ ডেটাবেসের ব্রুট-ফোর্স স্ক্যান এড়ানো সম্ভব হয় এবং অনুসন্ধান টাইম কমপ্লেক্সিটি $O(\log N)$-এ নেমে আসে।
৪. কোয়ান্টাইজেশন কী এবং এটি কেন ভেক্টর ডেটাবেসে র্যামের খরচ কমাতে অপরিহার্য?
হাই-ডাইমেনশনাল float32 ভেক্টর প্রচুর র্যাম খরচ করে (যেমন ১০০ মিলিয়ন ভেক্টরে ৬০০+ জিবি র্যাম লাগে)। কোয়ান্টাইজেশন হলো একধরনের লসি কম্প্রেশন যা ভেক্টরের প্রিসিশন কমিয়ে র্যাম সাশ্রয় করে। Scalar Quantization (SQ) প্রতিটি ডাইমেনশনকে ৮-বিট ইন্টিজারে এনে মেমোরি ৪ গুণ কমায়। Product Quantization (PQ) বড় ভেক্টরকে সাব-স্পেসে ভাগ করে ক্লাস্টার সেন্ট্রয়েডের মাধ্যমে স্টোর করে মেমোরি ১০ থেকে ১০০ গুণ পর্যন্ত সাশ্রয় করে। এর মাধ্যমে এন্টারপ্রাইজগুলো কোটি কোটি ভেক্টর সাধারণ বাজেটের সার্ভারেই হোস্ট করতে পারে।
৫. PostgreSQL (pgvector) বনাম পারপাস-বিল্ট ডেটাবেস (Milvus, Qdrant)—কখন কোনটি বেছে নেওয়া উচিত?
যদি আপনার সিস্টেমে ভেক্টরের পরিমাণ কয়েক লাখ থেকে কয়েক মিলিয়নের মধ্যে থাকে, বিদ্যমান ডেটাবেস ইতোমধ্যে PostgreSQL হয় এবং ACID ট্রানজ্যাকশন ও একক সিস্টেম আর্কিটেকচার অগ্রাধিকার পায়, তবে pgvector সেরা পছন্দ। কিন্তু যখন আপনার স্কেল কোটি কোটি ভেক্টরে পৌঁছাবে, অত্যন্ত হাই-থ্রুপুট রিয়েল-টাইম স্ট্রিমিং প্রয়োজন হবে এবং অ্যাডভান্সড ডিস্ট্রিবিউটেড কম্পিউট-স্টোরেজ সেপারেশন দরকার হবে, তখন Milvus বা Qdrant-এর মতো পারপাস-বিল্ট ভেক্টর ডেটাবেস বেছে নেওয়া অপরিহার্য।
৬. ডিস্ক-ভিত্তিক ভেক্টর ইনডেক্সিং (DiskANN / Vamana) কীভাবে কাজ করে?
HNSW গ্রাফে ট্রাভার্সাল চলাকালীন প্রচুর র্যান্ডম মেমোরি এক্সেস লাগে, যা সাধারণ SSD-তে অত্যন্ত ধীরগতির। DiskANN এবং Vamana অ্যালগরিদম গ্রাফটিকে এমনভাবে সাজায় যাতে মেমোরিতে কেবল কম্প্রেসড নেভিগেশন ভেক্টর থাকে এবং ডিস্কের NVMe স্টোরেজে সম্পূর্ণ প্রিসিশন ভেক্টর ও গ্রাফ এজগুলো থাকে। গ্রাফ লেআউটটি সিকুয়েনশিয়াল রিড অপটিমাইজড হওয়ায় ডিস্কের র্যান্ডম সিক জনিত লেটেন্সি বহুলাংশে কমে যায় এবং কম র্যামেই টেরাবাইট স্কেলের ডেটাবেস চালানো সম্ভব হয়।
৭. হাইব্রিড সার্চ (Hybrid Search) কী এবং এতে Reciprocal Rank Fusion (RRF) কেন ব্যবহার করা হয়?
অনেক সময় ইউজার কোনো সুনির্দিষ্ট প্রোডাক্ট কোড, নাম বা পার্ট নাম্বার দিয়ে সার্চ করেন, যেখানে সিম্যান্টিক ভেক্টর সার্চ এক্সাক্ট কি-ওয়ার্ড মিস করতে পারে। হাইব্রিড সার্চ একই সাথে স্পার্স লেক্সিক্যাল সার্চ (যেমন BM25) এবং ডেন্স সিম্যান্টিক ভেক্টর সার্চ পরিচালনা করে। ভিন্ন ভিন্ন স্কেলের স্কোরগুলোকে নিরপেক্ষভাবে একত্রিত করতে Reciprocal Rank Fusion (RRF) প্রতিটি ডকুমেন্টের পজিশন বা র্যাংকিংয়ের ওপর ভিত্তি করে একটি যৌগিক স্কোর তৈরি করে, যা সার্চ রেজাল্টের নির্ভুলতা ও ব্যবহারকারীর সন্তুষ্টি বহুগুণ বাড়িয়ে দেয়।
৮. ColBERT (Late Interaction) এবং Matryoshka Representation Learning (MRL) এর সুবিধা কী?
সাধারণ সিঙ্গেল-ভেক্টর রিপ্রেজেন্টেশনে সম্পূর্ণ ডকুমেন্টের জটিল তথ্য একটিমাত্র ভেক্টরে সংকুচিত করার ফলে তথ্যের সূক্ষ্মতা নষ্ট হতে পারে। ColBERT প্রতিটি টোকেনের আলাদা এমবেডিং সংরক্ষণ করে এবং কুয়েরির সময় MaxSim অপারেটর দিয়ে সূক্ষ্ম ইন্টারঅ্যাকশন মেলায়। অন্যদিকে, Matryoshka Representation Learning (MRL)-এ ভেক্টরের শুরুর দিকের ডাইমেনশনগুলোতে মূল অর্থ সংরক্ষণ করা হয়; ফলে ৩,০৭২ ডাইমেনশনের ভেক্টরকে অনায়াসে কেটে ২৫৬ ডাইমেনশনে নামিয়ে আনলেও খুব একটা অ্যাকুরেসি নষ্ট না হয়ে স্টোরেজ ও সার্চ লেটেন্সি নাটকীয়ভাবে কমে যায়।
৯. প্রোডাকশন স্কেলে ভেক্টর ডেটাবেসের হার্ডওয়্যার সাইজিং কীভাবে হিসাব করবেন?
সাইজিং হিসাবের ফর্মুলা:
মোট র্যাম = (ভেক্টরের সংখ্যা × ডাইমেনশন × বাইট সাইজ) + HNSW গ্রাফ ওভারহেড (২৫-৫০%) + পেলোড মেটাডেটা + হেডরুম বা বাফার (২০-৩০%)
যদি ডেটাবেসে রেপ্লিকেশন চালু থাকে, তবে ফলাফলকে রেপ্লিকা সংখ্যা দিয়ে গুণ করতে হবে। এছাড়া সার্চ স্পিড অপটিমাইজেশনের জন্য মেমোরি ব্যান্ডের পাশাপাশি হাই-আইওপিএস (IOPS) সম্পন্ন NVMe SSD এবং মাল্টি-কোর সিপিইউ নির্বাচন করা বাধ্যতামূলক।
১০. এআই সিস্টেমের জন্য ভেক্টর ডেটাবেস বেঞ্চমার্কিংয়ে কোন মেট্রিকগুলো পর্যবেক্ষণ করা উচিত?
ভেক্টর ডেটাবেস মূল্যায়নে প্রধান তিনটি গোল্ডেন মেট্রিক হলো:
- Recall@K: গ্রাউন্ড ট্রুথ বা প্রকৃত নিকটবর্তী ভেক্টরের শতকরা কত ভাগ ডেটাবেস সফলভাবে খুঁজে পেয়েছে (সাধারণত ০.৯৫ বা তার বেশি রিকল টার্গেট করা হয়)।
- QPS (Queries Per Second): একটি নির্দিষ্ট রিকল নিশ্চিত রেখে সিস্টেমটি প্রতি সেকেন্ডে সর্বোচ্চ কতগুলো সমান্তরাল সার্চ রিকোয়েস্ট হ্যান্ডেল করতে পারছে।
- Latency (p99): সর্বোচ্চ ৯৯% কুয়েরির রেসপন্স টাইম কত মিলি-সেকেন্ড—যা পিক লোডের সময় সিস্টেমের স্থায়িত্ব এবং ব্যবহারকারীর রিয়েল-টাইম অভিজ্ঞতা নির্দেশ করে।
এই ইনসাইটটি কি আপনার ভালো লেগেছে?
আপনার মতামত জানান অথবা এই কৌশলগুলো আপনার ব্যবসায় কীভাবে প্রয়োগ করা যায় তা নিয়ে আলোচনার জন্য যোগাযোগ করুন।
যোগাযোগ করুন
