DBA-দের জন্য Vector Search: আপনার ডেটাবেজে Embedding-এর আসল মানে কী

তিরিশ বছর ধরে ডেটাবেজের মানুষেরা নির্ভুল উত্তরের জগতে বাস করেছি: একটি WHERE ক্লজ হয় মেলে, নয় মেলে না। Vector search সেই আরামদায়ক নিয়মটি ভেঙে দেয় - এটি অর্থে সবচেয়ে কাছাকাছি সারিগুলো ফেরত দেয়, দূরত্ব অনুযায়ী র‌্যাংক করে, কোথাও কোনো নির্ভুল মিল ছাড়াই। এটি একই সঙ্গে এখন তৈরি হওয়া প্রতিটি গুরুতর AI সিস্টেমের স্টোরেজ স্তর - মানে এটি আমাদের জগতেই নামছে, আমরা যে ডেটাবেজগুলো চালাই তার ভেতরে একটি datatype আর একটি ইনডেক্স হয়ে। এই লেখাটি DBA-র ভাষায় অনূদিত vector search: vector-গুলো কী, ইনডেক্সগুলো কীভাবে কাজ করে, Oracle-এ SQL দেখতে কেমন, আর সেই নতুন অপারেশনাল দায়িত্বগুলো যা এখনও কারও জব ডেসক্রিপশনে লেখা হয়নি।

১. নির্ভুল মিল থেকে 'অর্থে সবচেয়ে কাছের'

একজন DBA জীবনে যত কোয়েরি টিউন করেছেন, সবগুলো একটি নির্ধারিত প্রশ্নের উত্তর দেয়: কোন সারিগুলো এই predicate পূরণ করে। Vector search উত্তর দেয় ভিন্ন প্রশ্নের: কোন সারিগুলো এই ইনপুটের অর্থের সবচেয়ে কাছে। ইনপুটটি হতে পারে একটি বাক্য, একটি সাপোর্ট টিকিট, একটি প্রোডাক্টের বর্ণনা, বা একটি ছবি - embedding মডেল যাকে সংখ্যায় রূপান্তর করতে পারে, তেমন যেকোনো কিছু।

একটি embedding আসলে নির্দিষ্ট দৈর্ঘ্যের float-এর অ্যারে - কয়েকশ থেকে কয়েক হাজার - একটি নিউরাল মডেলের তৈরি, যার একটিই গুরুত্বপূর্ণ ধর্ম: কাছাকাছি অর্থের কনটেন্ট এমন vector তৈরি করে যেগুলো একে অপরের কাছে বসে। "Customer cannot log in" আর "user locked out of account"-এ প্রায় কোনো keyword মেলে না, কিন্তু তাদের vector প্রতিবেশী। প্রতিটি সারিতে একটি vector রাখুন, আর সম্পর্কিত কনটেন্ট খোঁজা হয়ে যাবে জ্যামিতি: দূরত্ব হিসাব করুন, নিকটতমগুলো ফেরত দিন।

দূরত্ব নিজেও কয়েক রকমের - cosine similarity (vector-দের মধ্যকার কোণ, টেক্সটের প্রচলিত ডিফল্ট), Euclidean (সরলরেখা), আর dot product। যে অপারেশনাল নিয়মটি গুরুত্বপূর্ণ: ইনডেক্স যে metric দিয়ে বানানো, সেই একই metric দিয়ে কোয়েরি করুন, নইলে আপনার ইনডেক্স নিছক সাজসজ্জা।

২. এটি ডেটাবেজে এসে নামল কেন

AI সিস্টেমের প্রথম ঢেউ আসল ডেটাবেজের পাশে আলাদা, বিশেষায়িত একটি vector ডেটাবেজ জুড়ে দিয়েছিল - আর সঙ্গে সঙ্গে সেই প্রতিটি ইন্টিগ্রেশন সমস্যা নতুন করে তৈরি করেছিল যা আমাদের পেশা দশকের পর দশক ধরে সমাধান করেছে: দুই ইঞ্জিনের মধ্যে sync করা ডেটা সরে যায়, সিকিউরিটি মডেল আলাদা হয়ে পড়ে, ব্যাকআপ অসামঞ্জস্যপূর্ণ হয়, আর "অর্থ" ও "তথ্যের" প্রতিটি join নেটওয়ার্ক পার হয়।

দ্বিতীয় ঢেউ, প্রত্যাশিতভাবেই, vector-কে মূল ডেটাবেজে টেনে এনেছে। Oracle-এর AI Vector Search (23ai থেকে শুরু, 26ai প্রজন্মের কেন্দ্রে), সঙ্গে PostgreSQL ও অন্যদের সমতুল্য ফিচার - সবই একই সিদ্ধান্তের প্রতিফলন: একটি embedding আসলে আরেকটি কলাম মাত্র। যেখানে সে থাকে, সেখানকার ট্রানজ্যাকশন, privilege, অডিটিং, RMAN, Data Guard - DBA-রা আগে থেকেই যে পুরো যন্ত্রপাতি চালান - সব সে উত্তরাধিকারসূত্রে পায়, আর এক স্টেটমেন্টেই ব্যবসার ডেটার সঙ্গে JOIN করা যায়। নিয়ন্ত্রিত শিল্পের জন্য একটি বোনাসও আছে যা অসম্ভব গুরুত্বপূর্ণ: vector-গুলো (যা আপনার ডকুমেন্টের অর্থ এনকোড করে) কখনও ভবনের বাইরে যায় না - Sovereign AI-এর কেন্দ্রীয় যুক্তিটিই।

৩. SQL, হাতে-কলমে

Oracle-এ vector একটি প্রথম শ্রেণির datatype, আর similarity একটি SQL ফাংশন:

-- A table with an embedding column
CREATE TABLE support_tickets (
  ticket_id     NUMBER PRIMARY KEY,
  created_at    DATE,
  product       VARCHAR2(50),
  ticket_text   CLOB,
  ticket_vec    VECTOR(768, FLOAT32)   -- 768 dimensions
);

-- Find the 10 tickets most similar to a new one, restricted by product
SELECT ticket_id, ticket_text,
       VECTOR_DISTANCE(ticket_vec, :new_ticket_vec, COSINE) AS dist
FROM   support_tickets
WHERE  product = 'ERP'
ORDER  BY dist
FETCH  FIRST 10 ROWS ONLY;

স্টেটমেন্টটির গড়নটা খেয়াল করুন: একটি ক্লাসিক relational ফিল্টার (product = 'ERP') আর semantic র‌্যাংকিং - একই optimiser প্ল্যানে। ওই এক লাইন - relational predicate সঙ্গে similarity ordering - ডেটাবেজে vector রাখার বাস্তব যুক্তি, আর ঠিক এই প্যাটার্নেই একটি RAG পাইপলাইন প্রতিটি প্রশ্নে চলে (যে আর্কিটেকচার আমি RAG সহজভাবে লেখায় খুলে দেখিয়েছি)।

Oracle এমনকি ডেটাবেজের ভেতরেই embedding তৈরি করতে পারে, লোকালভাবে লোড করা একটি ONNX মডেল দিয়ে - SQL-এ VECTOR_EMBEDDING() - ফলে vector হওয়ার জন্য টেক্সটকে ইঞ্জিনের বাইরে যেতে হয় না।

৪. Vector ইনডেক্স: নতুন B-Tree আলোচনা

ইনডেক্স ছাড়া একটি similarity কোয়েরি প্রতিটি সারির সঙ্গে দূরত্ব হিসাব করে - একটি ফুল স্ক্যান, দশ হাজার vector-এ চলনসই, দশ কোটিতে অসম্ভব। সমাধান approximate nearest-neighbour (ANN) ইনডেক্সিং, আর এর trade-off-টি DBA-দের সত্যিই বুঝতে হবে, কারণ এটি দার্শনিকভাবে নতুন: ইনডেক্সটি প্রায়-নিশ্চিতভাবে-নিকটতম প্রতিবেশীদের ফেরত দেয়, একটি recall লক্ষ্য দিয়ে টিউন করা, বিশাল গতির বিনিময়ে।

• HNSW (Hierarchical Navigable Small World) vector-দের একটি বহুস্তর গ্রাফ বানায় - একে ভাবুন অর্থের ওপর একটি skip-list। চমৎকার কোয়েরি গতি ও recall; মেমরিতে বাস করে, তাই latency-সংবেদনশীল সার্চের ইনডেক্স এটিই - আর এটি মেমরি সাইজিংকে আবার ডিজাইন সিদ্ধান্ত বানিয়ে দেয় (Oracle এটি একটি ডেডিকেটেড vector মেমরি পুল থেকে কেটে নেয়)।
• IVF (Inverted File) vector-গুলোকে পার্টিশনে ক্লাস্টার করে এবং শুধু সবচেয়ে সম্ভাবনাময় ক্লাস্টারগুলো খোঁজে। মেমরির চাহিদা কম, খুব বড় ও ঘন ঘন বদলানো টেবিলের সঙ্গে বন্ধুত্বপূর্ণ, সমান গতিতে কিছুটা কম recall।

-- An HNSW vector index with a recall target
CREATE VECTOR INDEX tickets_hnsw_idx
ON support_tickets (ticket_vec)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;

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

৫. নতুন অপারেশনাল দায়িত্বগুলো

Vector এলে আমাদের দিকের ঘরে আসলে যা যা বদলায়:

• সামঞ্জস্যের নিশ্চয়তা। একটি কলামের প্রতিটি vector আসতে হবে একই embedding মডেল থেকে, একই dimension সংখ্যা, একই distance রীতি। মিশ্র কলাম নীরবে ব্যর্থ হয় - কোয়েরি চলে, ফলাফল আবর্জনা। এটিকে constraint-এর মতো প্রয়োগ করুন: প্রতি কলামে মডেল ডকুমেন্ট করুন, ভার্সন দিন, আর 'এই vector কোন মডেলের তৈরি' - তা schema মেটাডেটা হিসেবে দেখুন।
• Re-embedding জীবনচক্র। Embedding মডেল উন্নত হয়, আর বদলানো মানে প্রতিটি vector নতুন করে তৈরি - লাখ লাখ সারিতে ইনডেক্স রিবিল্ডসহ একটি বাল্ক অপারেশন, যেকোনো মাইগ্রেশনের মতো পরিকল্পনা করে (ব্যাচিং, ডাউনটাইম উইন্ডো, রোলব্যাক)। এটি সত্যিকারের নতুন এক পুনরাবৃত্ত রক্ষণাবেক্ষণ কাজ; বাজেটে রাখুন।
• ক্যাপাসিটি। Vector চওড়া - ৭৬৮টি float মানে ইনডেক্সের আগেই প্রতি সারিতে ~৩ KB - আর HNSW মেমরি চায়। স্টোরেজ পূর্বাভাস, SGA/vector-pool সাইজিং, আর পারফরম্যান্স বিশ্লেষণ - সবগুলোতে নতুন একটি লাইন আইটেম যোগ হয়।
• Hybrid কোয়েরি টিউনিং। Optimiser এখন relational ফিল্টারের সঙ্গে ANN সার্চ মেলায় (pre-filter বা post-filter, খুবই ভিন্ন খরচে)। সেই প্ল্যানগুলো পড়তে পারাই নতুন দক্ষতা - একই শৃঙ্খলা, নতুন অপারেটর।
• সিকিউরিটি ও অডিট। Vector ডকুমেন্টের অর্থ এনকোড করে; vector কলামকে তার উৎস টেক্সটের সমান শ্রেণিবিন্যাসে দেখুন। Privilege, মাল্টি-টেন্যান্ট retrieval-এর জন্য VPD/row-level ফিল্টার, আর অডিট ট্রেইল - ঠিক ডেটাবেজ সিকিউরিটি হার্ডেনিং-এর মতোই প্রযোজ্য।

৬. আমি আপনার জায়গায় থাকলে এই কোয়ার্টারে যা করতাম

এর আগে থাকতে আপনার কোনো AI প্রোগ্রাম লাগবে না। আপনার হাতে থাকা একটি বাস্তব করপাস নিন - টিকিটের টেক্সট, প্রোডাক্টের বর্ণনা, ডকুমেন্ট মেটাডেটা - আর একটি টেস্ট ডেটাবেজে তার ওপর একটি similarity সার্চ বানান। একটি embedding মডেল লোড করুন, vector তৈরি করুন, একটি exact আর একটি ANN-ইনডেক্সড কোয়েরি বানান, তারপর প্ল্যান, latency আর ফলাফলের মান নিজে তুলনা করুন।

এমন দুটি বিকেল এক মাসের পড়াশোনার চেয়ে বেশি শেখায়, আর আপনার প্রতিষ্ঠান যখন তার প্রথম RAG প্রকল্প শুরু করবে, তখন আপনাকে সেই ঘরে বসিয়ে দেয় - সেই মানুষ হিসেবে যিনি স্টোরেজ স্তরটি আগে থেকেই বোঝেন, যেখানে বাকিরা অনুমান করছে। এই পদক্ষেপের পেছনের ক্যারিয়ার-যুক্তি DBA-দের জন্য AI দক্ষতা লেখার বিষয়, তবে সংক্ষিপ্ত সংস্করণটি সহজ: প্রতিটি AI সিস্টেম ভেতরে ভেতরে একটি ডেটা সিস্টেম - আর আমরাই ডেটার মানুষ।

৭. একটি বাস্তব কেস: অর্থ দিয়ে খুঁজে পাওয়া ডুপ্লিকেট টিকিট

আমি যে সাপোর্ট প্রতিষ্ঠানকে পরামর্শ দিয়েছিলাম তাদের ছিল ক্লাসিক এক সমস্যা: একই ইস্যু পঞ্চাশ রকমভাবে রিপোর্ট হয়, আর keyword সার্চ প্রায় কিছুই ধরে না - "invoice PDF corrupt" আর "download gives broken file"-এ কাজের কোনো keyword মেলে না। আমরা বিদ্যমান টিকিট টেবিলে একটি embedding কলাম যোগ করলাম, ডেটাবেজের ভেতরেই vector তৈরি করলাম, আর ইনটেক ফ্লোতে একটি similarity লুকআপ বসালাম: প্রতিটি নতুন টিকিট সঙ্গে সঙ্গে তার পাঁচটি নিকটতম প্রতিবেশী আর তাদের সমাধান দেখায়।

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

সাধারণ জিজ্ঞাসা (FAQ)

ডেটাবেজে vector search কী?

Vector search প্রতিটি সারির পাশে একটি embedding - অর্থের সংখ্যাগত উপস্থাপনা - সংরক্ষণ করে এবং কোয়েরির vector-এর সবচেয়ে কাছের vector-ওয়ালা সারিগুলো খুঁজে উত্তর দেয়। WHERE-ক্লজের নির্ভুল মিলের বদলে এটি semantic similarity অনুযায়ী র‌্যাংক করা কনটেন্ট ফেরত দেয় - এভাবেই AI সিস্টেম প্রাসঙ্গিক ডকুমেন্ট, টিকিট বা প্রোডাক্ট খুঁজে পায়।

আলাদা vector ডেটাবেজ কি দরকার?

ক্রমশ কম। Oracle (নেটিভ VECTOR datatype-সহ AI Vector Search), PostgreSQL ও অন্যরা মূল ডেটাবেজেই vector সাপোর্ট করে, যেখানে সেগুলো ট্রানজ্যাকশন, সিকিউরিটি, ব্যাকআপ পায় এবং এক SQL স্টেটমেন্টে ব্যবসার ডেটার সঙ্গে join করা যায়। আলাদা vector store মানে একটি sync পাইপলাইন আর দ্বিতীয় একটি সিকিউরিটি মডেল - যা মূলত চরম বিশেষায়িত স্কেলে যুক্তিযুক্ত।

HNSW আর IVF vector ইনডেক্সের পার্থক্য কী?

দুটোই approximate nearest-neighbour ইনডেক্স। HNSW মেমরিতে একটি গ্রাফ বানায় - দ্রুততম কোয়েরি আর উঁচু recall, উল্লেখযোগ্য মেমরি খরচের বিনিময়ে। IVF vector-গুলোকে ক্লাস্টার করে শুধু সম্ভাবনাময় ক্লাস্টারগুলো খোঁজে - মেমরিতে হালকা, খুব বড় বা ঘন ঘন বদলানো টেবিলের জন্য ভালো, কিছুটা কম recall-এ। পছন্দটি ক্লাসিক ইনডেক্স trade-off-এরই প্রতিফলন, নতুন টিউনিং ডায়াল হিসেবে যোগ হয়েছে 'accuracy target'।

Vector search-এ আনুমানিক ফলাফল কেন গ্রহণযোগ্য?

কারণ প্রশ্নটাই 'সবচেয়ে কাছাকাছি কী', 'ঠিক কী মেলে' নয়। মাঝে মাঝে ১০তম-নিকটতম প্রতিবেশী বাদ পড়লে ব্যবহারকারীর কাছে ফলাফল কার্যত অপরিবর্তিত থাকে, অথচ approximate ইনডেক্স প্রতিটি vector স্ক্যান করার চেয়ে বহু মাত্রায় দ্রুত। আপনি স্পষ্টভাবে একটি recall লক্ষ্য (ধরুন ৯৫%) ঠিক করেন এবং শেষ কয়েক শতাংশ গতির বিনিময়ে ছেড়ে দেন।

Vector search DBA-দের জন্য কী নতুন দায়িত্ব তৈরি করে?

প্রতি কলামে embedding-মডেলের সামঞ্জস্য নিশ্চিত করা (একই মডেল, dimension, distance metric), মডেল বদলালে re-embedding মাইগ্রেশন পরিকল্পনা, স্টোরেজ ও ইনডেক্স মেমরি সাইজিং, hybrid relational-plus-similarity কোয়েরি প্ল্যান টিউনিং, আর vector-এ তার উৎস টেক্সটের সমান সিকিউরিটি শ্রেণিবিন্যাস প্রয়োগ।