Embedding ও vector search ডেভেলপারের জন্য সহজ ব্যাখ্যা

Keyword search হুবহু শব্দ খোঁজে। ব্যবহারকারী "how to fix a slow site" খুঁজলে আর আপনার নিবন্ধে "improve page speed" থাকলে keyword search তা মিস করতে পারে। Embedding আপনাকে অর্থ দিয়ে খুঁজতে দেয়।

Embedding কী?

Embedding হলো সংখ্যার একটি তালিকা (vector) যা embedding model-এর বানানো একটি লেখার প্রতিনিধিত্ব করে। সাধারণ আকার কয়েকশো থেকে কয়েক হাজার সংখ্যা।

মূল ধর্ম: সমান অর্থের লেখার vector কাছাকাছি হয়। "Car" ও "automobile" কাছাকাছি, "car" ও "banana" দূরে। প্রতিটি বাক্যকে বিশাল মানচিত্রের একটি বিন্দু ভাবুন যেখানে প্রতিবেশী মানে সমান অর্থ।

ছবি, অডিও ও কোডের জন্যও embedding আছে, আর কিছু model লেখা ও ছবি একই স্থানে রাখে।

সাদৃশ্য মাপা

দুটি vector তুলনায় আমরা দূরত্ব বা কোণ মাপি:

• Cosine similarity: vector-দের মধ্যের কোণ। 1 মানে একই দিক (খুব সদৃশ), 0 সম্পর্কহীন। লেখার জন্য সবচেয়ে প্রচলিত।
• Dot product: vector normalised হলে cosine-এর মতো।
• Euclidean distance: সরলরেখার দূরত্ব।

আপনার embedding model যে metric সুপারিশ করে তা এবং index ও query-তে একই metric ব্যবহার করুন।

খোঁজার ধারা

১. Index সময়: নথি টুকরো করুন, প্রতিটি টুকরো embed করুন এবং লেখা ও metadata-সহ vector সংরক্ষণ করুন। ২. Query সময়: ব্যবহারকারীর প্রশ্ন একই model দিয়ে embed করুন, সবচেয়ে কাছের সংরক্ষিত vector খুঁজুন, মেলানো টুকরো ফেরত দিন।

-- pgvector extension সহ PostgreSQL
CREATE EXTENSION vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  doc_id int,
  content text,
  embedding vector(768)
);

SELECT id, content
FROM chunks
ORDER BY embedding <=> '[0.12, -0.03, ...]'   -- cosine distance
LIMIT 5;

(Vector-এর আকার আপনার embedding model-এর ওপর নির্ভর করে।)

Chunking

নথি সাধারণত পুরোটা embed করার পক্ষে বেশি লম্বা, আর লম্বা লেখার একটি vector তার অর্থ ঝাপসা করে। Chunk-এ ভাগ করুন:

• প্রতিটি মোটামুটি কয়েকশো token, প্রায়ই অনুচ্ছেদ বা অংশ অনুযায়ী যাতে ধারণা একসাথে থাকে।
• Chunk-এর মধ্যে সামান্য overlap একটি ধারণা আধা কেটে ফেলা এড়ায়।
• প্রতিটি chunk-এর সাথে শিরোনাম ও উৎস রাখুন, যাতে ফল ব্যাখ্যা ও লিংক করা যায়।

Chunk-এর আকার লাভ-ক্ষতির ব্যাপার: খুব ছোট হলে context হারায়, খুব বড় হলে অর্থ পাতলা হয়। নিজের data-য় পরীক্ষা করুন।

Approximate nearest neighbour index

একটি query-কে লক্ষ লক্ষ vector-এর সাথে একটি একটি করে তুলনা ধীর। HNSW ও IVF-এর মতো vector index সামান্য নির্ভুলতার বিনিময়ে বড় গতিতে প্রায় কাছের vector দ্রুত খোঁজে। এগুলো টিউন করুন এবং recall মাপুন।

Vector কোথায় রাখবেন

• PostgreSQL-এ pgvector: Postgres আগে থেকে ব্যবহার করলে সবচেয়ে সহজ, আর সাধারণ SQL দিয়ে filter করা যায়।
• নিবেদিত vector database: Pinecone, Qdrant, Weaviate, Milvus, Chroma ও অন্যান্য, বড় পরিসরে বা বিশেষ সুবিধার জন্য কাজের।
• কিছু search engine (Elasticsearch, OpenSearch)-ও vector সমর্থন করে।

ছোট বা মাঝারি প্রকল্পে যা আগে থেকে চালান তা দিয়ে শুরু করুন।

Hybrid search

অর্থভিত্তিক খোঁজ product code, নাম বা error নম্বরের মতো হুবহু শব্দ মিস করতে পারে। Hybrid search keyword search (যেমন BM25) ও vector search মিলিয়ে র‍্যাঙ্কিং একত্র করে। এটি প্রায়ই একটির চেয়ে ভালো। এরপর একটি re-ranker model সেরা ফল পুনর্বিন্যাস করে ভালো নির্ভুলতা দিতে পারে।

Metadata filter

Vector search-এর সাথে filter মেলান: ভাষা, তারিখ, বিভাগ, বা কোন ব্যবহারকারী নথিটি দেখার অনুমতি পায়। অ্যাক্সেস filter query-র ভেতরেই প্রয়োগ করুন, যাতে মানুষ দেখার অধিকার নেই এমন কনটেন্ট পেতে না পারে।

সাধারণ ভুল

• এক index-এ ভিন্ন model-এর embedding মেশানো।
• সব আবার embed না করে embedding model বদলানো।
• খুব বড় chunk, বা বাক্যের মাঝখানে কাটা chunk।
• মূল্যায়ন না করা: জানা সঠিক উত্তরসহ ছোট প্রশ্নের সেট বানিয়ে দেখুন সেগুলো ফেরত আসে কি না।
• উদ্ধার করা কনটেন্টের অনুমতি উপেক্ষা।
• ডেটা নীতি না দেখে ব্যক্তিগত লেখা embedding সেবায় পাঠানো।

কোথায় ব্যবহার

Semantic site search, সুপারিশ ("সদৃশ নিবন্ধ"), ডুপ্লিকেট শনাক্তকরণ, clustering এবং retrieval-augmented generation (RAG), যা পরের লেখায় আছে।

মূল কথা: Embedding অর্থকে vector-এ ম্যাপ করে, nearest-neighbour search সম্পর্কিত লেখা খোঁজে, ভালো chunking ও metadata একে কাজের করে, আর hybrid search ও মূল্যায়ন একে নির্ভরযোগ্য করে।

---

AI ও LLM সিরিজ, পর্ব ১ (language model দিয়ে বানানো): 3 নম্বর (মোট 5)। আগের লেখা: Prompt engineering: LLM থেকে ভালো ফলের ব্যবহারিক নির্দেশিকা.