Chapter 2 — Embeddings, Vector Database & RAG: AI-কে নিজের Knowledge শেখানো

Chapter 1-এ আমরা দেখেছি কীভাবে একটি LLM API ব্যবহার করে Application-এ AI যুক্ত করা যায়। কিন্তু একটি গুরুত্বপূর্ণ সমস্যা তখন থেকেই রয়ে যায়। ধরুন তুমি একটি Company-এর জন্য AI Assistant বানালে। সেই Assistant-কে Company Policy, Product Documentation, Internal Guide বা হাজার হাজার PDF থেকে উত্তর দিতে হবে। কিন্তু LLM Provider-এর Model তো তোমার Company-এর Private Document সম্পর্কে জানে না। তাহলে কীভাবে AI সেই তথ্য ব্যবহার করে সঠিক উত্তর দেবে?

এখানেই আসে Embeddings, Vector Database এবং RAG। এই তিনটি Technology একসাথে ব্যবহার করে আমরা এমন একটি System তৈরি করতে পারি যেখানে LLM নিজের Training Data-এর বাইরে থাকা তথ্যও ব্যবহার করে User-এর প্রশ্নের উত্তর দিতে পারে।

---

Problem Statement — LLM-কে নিজের Data কীভাবে দেওয়া যাবে?

ধরো একটি E-commerce Company-এর কাছে ৫০,০০০টি Product আছে। প্রতিটি Product-এর Name, Description, Specification এবং Manual Database-এ রয়েছে।

User জিজ্ঞেস করল:

"Gaming-এর জন্য ৮০ হাজার টাকার মধ্যে কোন Laptop-এ সবচেয়ে ভালো GPU আছে?"

একটি সাধারণ LLM এই প্রশ্নের উত্তর দিতে চেষ্টা করবে তার Training Data থেকে। কিন্তু তোমার Website-এর বর্তমান Product, Price এবং Stock সম্পর্কে তার কোনো ধারণা নেই।

আর যদি পুরো Database-এর সব Product Information প্রতিটি Request-এর সাথে Prompt-এর মধ্যে পাঠাও, তাহলে Prompt অনেক বড় হয়ে যাবে এবং Cost ও Latency দুটোই বেড়ে যাবে।

আমাদের দরকার এমন একটি System যেখানে User-এর প্রশ্ন অনুযায়ী শুধু Relevant Information খুঁজে বের করে LLM-কে দেওয়া হবে।

এই সমস্যার সমাধান হলো RAG।

---

Embedding কী?

Embedding হলো Text বা অন্য কোনো Data-কে একটি সংখ্যার Vector-এ রূপান্তর করার পদ্ধতি।

সহজভাবে চিন্তা করলে, একটি Sentence-কে Computer-এর জন্য এমন একটি Mathematical Representation-এ পরিণত করা হয় যেখানে তার Meaning বা Semantic Relationship ধরা থাকে।

ধরো আমাদের কাছে দুটি Sentence আছে:

"I want to buy a cheap laptop."

এবং

"I am looking for an affordable notebook."

শব্দগুলো আলাদা হলেও Meaning প্রায় একই। একটি ভালো Embedding Model এই দুই Text-এর Vector-কে কাছাকাছি অবস্থানে রাখবে।

অন্যদিকে—

"The weather is very hot today."

এর Meaning সম্পূর্ণ আলাদা হওয়ায় এর Vector অনেক দূরে থাকবে।

অর্থাৎ Embedding-এর মাধ্যমে আমরা Text-এর Semantic Similarity মাপতে পারি।

---

Vector কী?

একটি Text Embedding দেখতে এমন হতে পারে:

"Gaming laptop"

        ↓

[0.021, -0.342, 0.812, 0.119, ...]

বাস্তবে একটি Embedding-এ শত শত বা হাজার হাজার সংখ্যা থাকতে পারে।

এই সংখ্যাগুলো মানুষের পড়ার জন্য নয়। এগুলো Model-এর তৈরি Mathematical Representation।

তারপর এই Vector ব্যবহার করে আমরা Similar Information খুঁজে বের করতে পারি।

---

Embedding কীভাবে তৈরি হয়?

সাধারণ Flow:

Text
 │
 ▼
Embedding Model
 │
 ▼
Vector
 │
 ▼
Vector Database

ধরো একটি Product Description:

"ASUS gaming laptop with RTX 4060 GPU,
16GB RAM and 1TB SSD."

Embedding Model এটিকে একটি Vector-এ Convert করবে।

এই Vector আমরা Database-এ Store করব।

---

Vector Database কেন দরকার?

এখন আমাদের কাছে হাজার হাজার Document আছে।

প্রতিটি Document-এর Embedding তৈরি করে Store করা হলো।

Document 1 → Vector 1
Document 2 → Vector 2
Document 3 → Vector 3
...
Document 100000 → Vector 100000

এখন User একটি Question করল।

প্রথমে Question-এরও Embedding তৈরি করা হবে।

User Question
      ↓
Embedding Model
      ↓
Query Vector

তারপর Query Vector-এর সাথে Database-এর Vector-গুলোর Similarity Compare করা হবে।

সবচেয়ে কাছের Vector-গুলোই হবে সবচেয়ে Relevant Document।

এটাই Vector Search-এর মূল ধারণা।

---

Vector Database কীভাবে কাজ করে?

ধরো Database-এ তিনটি Document আছে।

Document A
"MacBook Pro with M3 chip..."

Document B
"Gaming laptop with RTX 4060..."

Document C
"How to configure a PostgreSQL database..."

User জিজ্ঞেস করল:

"Which laptop has an RTX 4060?"

Query-এর Embedding তৈরি হওয়ার পর Vector Database বুঝবে যে Document B-এর Vector Query-এর সাথে সবচেয়ে বেশি Similar।

তাই Document B Retrieve করা হবে।

---

Popular Vector Databases

বর্তমানে বিভিন্ন ধরনের Vector Database ব্যবহার করা হয়।

Pinecone

Pinecone একটি Managed Vector Database। Infrastructure নিজে Manage না করেও দ্রুত Production-এ Vector Search তৈরি করা যায়।

Qdrant

Qdrant একটি জনপ্রিয় Vector Search Engine, যা Self-hosting এবং Production Application—দুই ক্ষেত্রেই ব্যবহার করা যায়।

Weaviate

Weaviate একটি Vector Database এবং Search Platform, যেখানে Semantic Search-এর পাশাপাশি বিভিন্ন Advanced Retrieval Feature পাওয়া যায়।

Chroma

Chroma তুলনামূলকভাবে সহজ এবং Developer-friendly। Prototype, Learning এবং ছোট AI Application-এর জন্য এটি বেশ জনপ্রিয়।

কোনটি ব্যবহার করবে তা নির্ভর করবে Project-এর Scale, Infrastructure, Budget এবং Feature Requirement-এর উপর।

---

RAG কী?

RAG-এর পূর্ণরূপ হলো Retrieval-Augmented Generation।

নাম থেকেই বোঝা যায়, এখানে দুইটি গুরুত্বপূর্ণ কাজ হচ্ছে:

Retrieval → Relevant Information খুঁজে বের করা।

Generation → সেই Information ব্যবহার করে LLM-এর মাধ্যমে Answer তৈরি করা।

অর্থাৎ LLM-কে সরাসরি প্রশ্ন না করে আগে Knowledge Base থেকে Relevant Information বের করে তারপর সেই Context সহ LLM-কে প্রশ্ন করা হয়।

---

RAG-এর সম্পূর্ণ Architecture

একটি সাধারণ RAG System এমনভাবে কাজ করে:

                Documents
                    │
                    ▼
              Chunking
                    │
                    ▼
             Embedding Model
                    │
                    ▼
             Vector Database
                    │
                    │
              User Question
                    │
                    ▼
             Query Embedding
                    │
                    ▼
             Similarity Search
                    │
                    ▼
          Relevant Documents
                    │
                    ▼
                 LLM
                    │
                    ▼
              Final Answer

এখানে Document আগে থেকেই Index করা থাকে। User Question আসার পরে শুধু Relevant Information Retrieve করা হয়।

---

Document Chunking কেন দরকার?

ধরো তোমার কাছে ২০০ পৃষ্ঠার একটি PDF আছে।

পুরো PDF-কে একটি Vector বানালে Search খুব Precise নাও হতে পারে।

তাই Document-কে ছোট ছোট অংশে ভাগ করা হয়। এই Process-কে Chunking বলা হয়।

উদাহরণ:

Large PDF

      ↓

Chunk 1
Chunk 2
Chunk 3
Chunk 4
...
Chunk 500

প্রতিটি Chunk-এর আলাদা Embedding তৈরি করা হয়।

তখন User কোনো নির্দিষ্ট বিষয় সম্পর্কে প্রশ্ন করলে System সেই বিষয়ের সাথে সবচেয়ে Relevant Chunk খুঁজে বের করতে পারে।

---

একটি Real-Life Project Example

ধরো তুমি একটি University-এর জন্য AI Assistant তৈরি করছ।

University-এর কাছে রয়েছে:

• Admission Policy
• Course Catalog
• Tuition Fees
• Exam Rules
• Scholarship Policy
• Student Handbook

এগুলো Vector Database-এ Index করা হলো।

এখন Student জিজ্ঞেস করল:

"Computer Science Master's Program-এর জন্য Scholarship-এর Minimum GPA কত?"

System প্রথমে Question-এর Embedding তৈরি করবে।

তারপর Vector Database-এ Search করবে।

ধরো Scholarship Policy-এর একটি Chunk সবচেয়ে Relevant পাওয়া গেল।

সেই Information LLM-এর Context-এ দেওয়া হবে।

তারপর LLM উত্তর তৈরি করবে।

Student Question
       ↓
Embedding
       ↓
Vector Search
       ↓
Scholarship Policy Chunk
       ↓
LLM
       ↓
Answer

এখানে LLM নিজে Scholarship Policy জানে না। RAG তাকে Relevant Document এনে দিয়েছে।

---

RAG কেন এত গুরুত্বপূর্ণ?

RAG-এর সবচেয়ে বড় সুবিধা হলো তোমাকে প্রতিবার Model Retrain করতে হয় না।

ধরো Company-এর Policy পরিবর্তন হলো।

পুরো AI Model আবার Train করার দরকার নেই।

শুধু নতুন Document Index করলেই হলো।

Old Policy
    ↓
Replace

New Policy
    ↓
Embedding
    ↓
Vector Database

এরপর User নতুন Policy সম্পর্কে প্রশ্ন করলে RAG নতুন Information Retrieve করবে।

---

RAG বনাম Fine-Tuning

এখানে একটি গুরুত্বপূর্ণ পার্থক্য বোঝা দরকার।

RAG মূলত Model-কে External Knowledge দেয়।

Fine-Tuning Model-এর Behavior বা নির্দিষ্ট Task-এর উপর Model-কে অতিরিক্ত Train করার পদ্ধতি।

ধরো তোমার লক্ষ্য:

"Company-এর ১০,০০০টি Document থেকে Answer দিতে হবে।"

এখানে RAG সাধারণত বেশি উপযোগী।

অন্যদিকে যদি লক্ষ্য হয়:

"একটি নির্দিষ্ট Style-এ Response তৈরি করতে Model-কে Adapt করতে হবে।"

তাহলে Fine-Tuning বিবেচনা করা যেতে পারে।

অনেক Production System-এ দুটো একসাথেও ব্যবহার করা হয়।

---

RAG-এর একটি গুরুত্বপূর্ণ Challenge

RAG মানেই শুধু Vector Search নয়।

বাস্তব Production System-এ Retrieval Quality অত্যন্ত গুরুত্বপূর্ণ।

যদি ভুল Document Retrieve হয়, তাহলে LLM-ও ভুল Answer দিতে পারে।

এটিকে অনেক সময় বলা হয়:

Garbage In, Garbage Out

অর্থাৎ Retrieval ভুল হলে Generation যত ভালো Model দিয়েই করো, Final Answer ভুল হওয়ার সম্ভাবনা থাকবে।

তাই ভালো RAG System-এ Chunking, Metadata Filtering, Retrieval Strategy, Reranking এবং Context Management গুরুত্বপূর্ণ।

---

Semantic Search বনাম Keyword Search

Traditional Search সাধারণত Keyword Match করে।

User লিখল:

"cheap gaming laptop"

তখন Database-এ একই Keyword খুঁজতে পারে।

কিন্তু Semantic Search Meaning বুঝতে চেষ্টা করে।

যেমন:

"budget-friendly notebook for gaming"

এখানে "cheap gaming laptop" কথাটি সরাসরি নেই, কিন্তু Meaning কাছাকাছি।

Embedding-based Search এই Semantic Relationship ধরতে পারে।

এটাই Vector Search-এর বড় শক্তি।

---

Production RAG-এর Basic Architecture

একটি Production Application-এ Architecture সাধারণত এমন হতে পারে:

                User
                 │
                 ▼
            Backend API
                 │
                 ▼
          Query Processing
                 │
                 ▼
          Embedding Model
                 │
                 ▼
          Vector Database
                 │
                 ▼
        Relevant Context
                 │
                 ▼
              LLM
                 │
                 ▼
             Response

আর Document Upload-এর সময়:

Document Upload
      ↓
Text Extraction
      ↓
Chunking
      ↓
Embedding
      ↓
Vector Database

এভাবে দুইটি আলাদা Pipeline কাজ করে—একটি Indexing Pipeline, আরেকটি Query Pipeline।

---

RAG System তৈরি করতে কী কী দরকার?

একটি Basic RAG Application-এর জন্য সাধারণত দরকার:

1. LLM

Final Answer Generate করার জন্য।

2. Embedding Model

Text-কে Vector-এ Convert করার জন্য।

3. Vector Database

Embedding Store এবং Search করার জন্য।

4. Document Processing

PDF, Website, Markdown, Word বা অন্যান্য Source থেকে Text বের করার জন্য।

5. Chunking Strategy

বড় Document-কে ছোট Context-এ ভাগ করার জন্য।

6. Retrieval Logic

User Query অনুযায়ী Relevant Information খুঁজে বের করার জন্য।

---

একজন Developer হিসেবে কী বুঝতে হবে?

RAG শেখার সময় শুধু Pinecone বা Qdrant-এর API শেখা যথেষ্ট নয়।

তোমাকে বুঝতে হবে—

• Embedding কীভাবে Semantic Meaning Represent করে।
• Similarity Search কীভাবে কাজ করে।
• Chunk Size কেন গুরুত্বপূর্ণ।
• Metadata কীভাবে Retrieval Improve করে।
• Top-K Retrieval কী।
• Reranking কেন দরকার।
• Context Window কীভাবে Manage করতে হয়।
• Retrieval ভুল হলে কীভাবে Detect করতে হয়।
• RAG-এর Accuracy কীভাবে Evaluate করতে হয়।

এই Concepts বোঝার পর তুমি শুধু একটি RAG Tutorial Follow করবে না; বরং নিজের Project-এর জন্য সঠিক RAG Architecture Design করতে পারবে।

---

Chapter 2 থেকে কী শিখলাম?

এই Chapter-এ আমরা দেখলাম কীভাবে একটি সাধারণ LLM-এর Knowledge সীমাবদ্ধতা কাটিয়ে তাকে External Knowledge-এর সাথে যুক্ত করা যায়।

আমরা শিখলাম:

• Embedding কী
• Text কীভাবে Vector-এ রূপান্তরিত হয়
• Vector Database কী
• Pinecone, Qdrant, Weaviate এবং Chroma কী
• Document Chunking কেন দরকার
• Semantic Search কীভাবে কাজ করে
• RAG কী
• RAG Architecture কীভাবে কাজ করে
• RAG বনাম Fine-Tuning
• Production RAG-এর গুরুত্বপূর্ণ বিষয়গুলো

---

উপসংহার

Chapter 1-এ আমরা LLM-কে আমাদের Application-এর সাথে কথা বলতে শিখিয়েছিলাম। Chapter 2-এ এসে আমরা আরও এক ধাপ এগিয়ে গেলাম—এখন LLM শুধু নিজের Training Knowledge-এর উপর নির্ভর করছে না; এটি আমাদের নিজের Data থেকে Relevant Information Retrieve করে সেই Context ব্যবহার করে Answer দিতে পারছে।

এখান থেকেই AI Application অনেক বেশি বাস্তব এবং Powerful হয়ে ওঠে।

কিন্তু এখানেও একটি নতুন প্রশ্ন তৈরি হয়।

যদি আমরা নিজের LLM Model ব্যবহার করতে চাই?

OpenAI, Claude বা Gemini-এর API ব্যবহার না করে যদি একটি Open Source Model নিজের Computer, Server অথবা GPU Infrastructure-এ চালাতে চাই, তাহলে কী করতে হবে?

সেখান থেকেই শুরু হবে আমাদের পরবর্তী Chapter।

---

পরবর্তী Blog — Part 3

Chapter 3 — Open Source AI Models & Hugging Face

পরবর্তী Blog-এ আমরা দেখব Open Source AI Model কী, Hugging Face কীভাবে কাজ করে, Model Download করে নিজের Environment-এ কীভাবে চালানো যায়, Ollama কী, Model Hosting এবং Self-Hosting-এর মধ্যে পার্থক্য কী এবং নিজের AI Model চালাতে GPU কেন এত গুরুত্বপূর্ণ।

অর্থাৎ পরবর্তী Chapter-এ আমরা API ব্যবহারকারী Developer থেকে Model চালানো Developer-এর দিকে এক ধাপ এগিয়ে যাব।