Vector database কী?

একটা vector database একটাই প্রশ্নের উত্তর দেয়, খুব দ্রুত

একে একটা সংখ্যার তালিকা দিন আর এটা সেই সংরক্ষিত তালিকাগুলো ফিরিয়ে দেয় যেগুলো এটার সবচেয়ে কাছাকাছি। এটাই পুরো ইন্টারফেস।

এই তালিকাগুলোকে বলা হয় এমবেডিং। একটা এমবেডিং মডেল একটা অনুচ্ছেদ, একটা পণ্যের বিবরণ বা একটা ছবিকে কয়েকশো থেকে কয়েক হাজার সংখ্যায় রূপান্তরিত করে, এমনভাবে বসিয়ে যাতে একইরকম অর্থ একে অপরের কাছাকাছি পড়ে, আর what are embeddings in AI দেখায় কীভাবে। একটা vector database হলো সেই জায়গা যেখানে এই তালিকাগুলো থাকে, যখন আপনার কাছে অনেকগুলো জমে যায়। এটা প্রতিটাকে একটা ID আর কিছু মেটাডেটাসহ সংরক্ষণ করে, তাদের উপর একটা ইনডেক্স তৈরি করে, আর নিয়ারেস্ট নেইবার সার্চের উত্তর দেয়: "এই তো একটা কোয়েরি ভেক্টর, আমাকে সবচেয়ে কাছের দশটা দাও।"

কঠিন অংশটা হলো "দ্রুত" শব্দটা। 1,536টা সংখ্যার একটা কোয়েরিকে দশ লাখ সংরক্ষিত ভেক্টরের সঙ্গে তুলনা করা মানে 150 কোটি গুণন, আর প্রতিটা কিস্ট্রোকে এটা করা স্কেল করে না। তাই vector database গুলো অ্যাপ্রক্সিমেট নিয়ারেস্ট নেইবার ইনডেক্স ব্যবহার করে, সবচেয়ে সাধারণটা হলো HNSW, Malkov আর Yashunin-এর 2016 সালের একটা পেপার থেকে আসা একটা গ্রাফ স্ট্রাকচার, যা পুরো দশ লাখের বদলে মাত্র কয়েকশো প্রার্থী যাচাই করে আর প্রায় প্রতিবারই সঠিক উত্তর দেয়। এই "প্রায়"টাই হলো লেনদেন: সামান্য রিকল হারিয়ে হাজার গুণ গতি পাওয়া।

আপনার আগের ডেটাবেস শব্দ মেলায়; একটা vector database অর্থ মেলায়

একটা রিলেশনাল ডেটাবেস এমন রো খুঁজে বের করে যাদের ভ্যালু মেলে: WHERE customer_id = 4127। একটা ফুল-টেক্সট ইনডেক্স এমন ডকুমেন্ট খুঁজে বের করে যাতে শব্দ আছে: refund AND policy। একটা vector database এমন আইটেম খুঁজে বের করে যাদের অর্থ কাছাকাছি: "how do I get my money back" কোয়েরিতে "Returns and refunds" শিরোনামের অনুচ্ছেদটা আসে, যদিও দুটোর মধ্যে একটা শব্দও মেলে না।

শেষ সারিটা দেখায় ক্যাটাগরিটা কতটা অস্পষ্ট। pgvector সাধারণ Postgres-এ ভেক্টর কলাম আর একটা HNSW ইনডেক্স যোগ করে, আর Elasticsearch 2019 সালের ভার্সন 7.0 থেকে ভেক্টর ফিল্ড আর 2022 সালের 8.0 থেকে HNSW সার্চ বহন করে আসছে। একটা "vector database" প্রায়ই আপনি যে ডেটাবেস এমনিতেই চালান তার ভেতরের একটা সক্ষমতা, নতুন কোনো পণ্য নয়, আর স্ট্যান্ডঅ্যালোন পণ্যগুলো স্কেল আর অপারেশনাল গুণমানে প্রতিযোগিতা করে, Postgres যা করতে পারে না এমন কিছু করে নয়।

চ্যাট-উইথ-ইওর-ডকুমেন্টস আসলে শেষে একটা মডেলসহ একটা ভেক্টর সার্চ

রিট্রিভাল-অগমেন্টেড জেনারেশন, যা what is RAG খুঁটিয়ে দেখায়, তাতে একটা সার্চ ধাপ আর একটা লেখার ধাপ থাকে। vector database হলো সার্চ ধাপটা।

1. প্রতিটা ডকুমেন্টকে কয়েকশো থেকে হাজার টোকেনের অনুচ্ছেদে ভাগ করুন।
2. প্রতিটা অনুচ্ছেদ এমবেড করুন আর ভেক্টরগুলো, অনুচ্ছেদের টেক্সট আর এর সোর্সসহ, vector database-এ সংরক্ষণ করুন।
3. যখন একটা প্রশ্ন আসে, সেটাকে এমবেড করুন আর ডেটাবেসকে সবচেয়ে কাছের অনুচ্ছেদগুলো চান।
4. সেই অনুচ্ছেদগুলো প্রশ্নসহ ভাষা মডেলের হাতে দিন, আর ওকে উত্তর লিখতে দিন।

ধাপ 1 আর 2 একবারই ঘটে, যখন ডকুমেন্ট যোগ করা হয়। ধাপ 3 আর 4 প্রতিটা প্রশ্নেই ঘটে। ভাষা মডেল কখনো পুরো সংগ্রহটা দেখে না; এটা দেখে সেই পাঁচ বা দশটা অনুচ্ছেদ যেগুলো ডেটাবেস বেছে নিয়েছে। এই কারণেই উত্তরটা সার্চের মতোই ভালো: যদি সবচেয়ে কাছের ভেক্টরটা ভুল অনুচ্ছেদ হয়, মডেল আত্মবিশ্বাসের সঙ্গে ভুল প্রশ্নের উত্তর দেয়, যাকে what is an AI hallucination একটা আবিষ্কার নয় বরং একটা রিট্রিভাল ব্যর্থতা হিসেবে ধরে।

কখন এটা দরকার, আর কখন পুরো ফাইল পাঠানো ভালো

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

300,000-টোকেনের একটা রিপোর্টে, কয়েকশো পাতা, দুটো ডিজাইনের দাম হিসাব করুন, দশটা প্রশ্ন করে, প্রতি প্রশ্নে পাঁচটা 1,000-টোকেনের অনুচ্ছেদ রিট্রিভ করে। প্রতিবার পুরো ফাইল পাঠানো মানে 30 লাখ ইনপুট টোকেন। প্রতি প্রশ্নে 1,000 টোকেনের পাঁচটা অনুচ্ছেদ রিট্রিভ করা মানে 50,000। AI model cost index-এর তালিকা মূল্যে, যা OpenRouter থেকে 2026-08-20 তারিখে আনা, ব্যবধানটা প্রতিটা মডেলে 60 গুণ। প্রম্পট ক্যাশিং, যেখানে প্রোভাইডার এটা দেয়, একই ফাইল আবার পড়ার জন্য তালিকা মূল্যের এক-দশমাংশ থেকে অর্ধেক পর্যন্ত বিল করে, যা ব্যবধানটা প্রায় 6 থেকে 30 গুণে নামিয়ে আনে। রিট্রিভাল তবুও জেতে, কম ব্যবধানে।

পুরো-ফাইল ডিজাইনটা সেই টাকার বিনিময়ে কিছু দেয় যখন ফাইলটা বাজেটে ধরে: 60 পাতার একটা চুক্তি, প্রায় 40,000 টোকেন, মডেলকে এমন প্রশ্নের উত্তর দিতে দেয় যার জন্য পুরো ডকুমেন্ট একসাথে দরকার, যেমন "এখানে কি ক্লজ 14-এর সাথে কোনো কিছু বিরোধিতা করে", যা রিট্রিভাল জিজ্ঞাসা করতে পারে না কারণ এটা কখনো ক্লজ 14 আর সেই বিরোধিতাটা একই ব্যাচে দেখে না। এখান থেকে যে নিয়মটা বের হয়ে আসে: একটা ডকুমেন্ট, বা হাতেগোনা কয়েকটা, পুরোটা যায়; একটা লাইব্রেরি vector database দিয়ে যায়। দুয়ের মাঝে, আপলোডটা বিষয় অনুযায়ী ভাগ করুন যাতে মডেল যেই অংশটুকু দরকার সেটাই পায়।

Whizi নিজে টেক্সট পাঠায়, একটা 40,000-টোকেনের টার্ন পর্যন্ত

Whizi আপনার চ্যাটের জন্য কোনো vector database চালায় না। যখন আপনি একটা ফাইল সংযুক্ত করেন, document upload পথটা টেক্সট বের করে আর প্রম্পট টেক্সট হিসেবে মডেলে পাঠায়, প্রতি টার্নে একটা স্থির 40,000-টোকেন বাজেট পর্যন্ত; এর চেয়ে লম্বা আপলোড কাটা হয়, সাথে একটা টোস্ট আর মেসেজের ভেতরে একটা মার্কার সেটা জানিয়ে। প্রজেক্ট ফাইলও একইভাবে কাজ করে: projects ফিচার সর্বোচ্চ 10টা ফাইল পিন করে আর প্রতিটা মেসেজে তাদের টেক্সট প্রম্পটে পুনর্গঠন করে, প্রতি ফাইলে 32,000 ক্যারেক্টার আর পুরো প্রজেক্ট ব্লকে 1,20,000 ক্যারেক্টারে সীমাবদ্ধ।

সীমাগুলোই ডিজাইনের প্রান্ত। 32,000 ক্যারেক্টারের বেশি একটা পিন করা ফাইল কাটা হয়, 40,000-টোকেনের টার্ন বাজেটের বেশি একটা অ্যাটাচমেন্ট কাটা হয়, আর একটা প্রজেক্ট একটা ফোল্ডার, খোঁজযোগ্য লাইব্রেরি নয়। এই লেনদেনটা ইচ্ছাকৃত: এমন একটা চুক্তি বা প্রবন্ধের জন্য যা টার্ন বাজেটে ধরে, টেক্সট হাজির থাকা সার্চ করার চেয়ে ভালো, আর যেই পরীক্ষাটা গুরুত্বপূর্ণ, মডেলকে সে যেই অনুচ্ছেদ ব্যবহার করেছে তা উদ্ধৃত করতে বলা, সেটা কাজ করে কারণ অনুচ্ছেদটা সেখানেই আছে। হাজার হাজার ডকুমেন্টের জন্য, একটা vector database সঠিক টুল আর একটা চ্যাট অ্যাপ ভুল একটা।

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