DEV Community: Anushka Gupta

RAG from Scratch: Building a Document Q&A System with LangChain, ChromaDB & Free AI Models

Anushka Gupta — Sat, 22 Aug 2026 19:20:20 +0000

In this blog, we'll build a RAG pipeline from scratch using LangChain, and understand what happens at every step: from loading a document to generating the final answer.

I want you to keep this diagram in mind.

📄 DOCUMENT
     ↓
1️⃣ Document Loader
     ↓
📃 Documents
     ↓
2️⃣ Text Splitter ✂️
     ↓
🧩 Chunks
     ↓
🧠 Embedding Model
     ↓
🔢 Vectors
     ↓
3️⃣ ChromaDB 🗄️
     ↓
4️⃣ Retriever 🔎
     ↓
Relevant Chunks
     ↓
🤖 LLM
     ↓
💬 Final Answer

Now, we'll go through each component one by one and understand both the theory behind it and how it works practically.

1. Component 1 — Document Loader

Reads your files (PDF, DOCX, TXT, etc.) and extracts their content.

Imagine you have:

employee_handbook.pdf
Your Python application can't simply reason over the PDF itself.

The Document Loader reads the file and converts it into a format that LangChain can work with.

employee_handbook.pdf
        ↓
   PDF Loader
        ↓
LangChain Document objects

A LangChain Document generally contains:

Document(
    page_content="Employees are entitled to 20 days...",
    metadata={
        "source": "employee_handbook.pdf",
        "page": 10
    }
)

So you get two important things:

page_content - The actual text.
metadata - Information about the text.

For RAG, metadata is incredibly useful because later you can tell the user:

"This answer came from Employee Handbook, page 10."

Practical example:

For a PDF, you can use a PDF loader such as PyPDFLoader or PyMuPDF.

For this blog, I'll use PyMuPDFLoader because it generally offers better performance and text extraction for real-world RAG applications. If you're just getting started or working with simple PDFs, PyPDFLoader is also an excellent choice.

from langchain_community.document_loaders import PyMuPDFLoader

loader = PyMuPDFLoader("employee_handbook.pdf")

documents = loader.load()

Now:

PDF
 ↓
PyMuPDFLoader
 ↓
documents

You can inspect:

print(documents[0].page_content)
print(documents[0].metadata)

There are many others document loaders in the LangChain ecosystem. Some of them are:

PDF → PyMuPDFLoader
TXT → TextLoader
DOCX → Docx2txtLoader
CSV → CSVLoader
Web page → WebBaseLoader

2. Component 2 — Text Splitter ✂️

Breaks large documents into smaller, meaningful chunks that are easier for the AI to process.

Now suppose your PDF has 100 pages.

You don't want to treat it as one giant block.

Instead:

100-page PDF
     ↓
     ✂️
     ↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...
Chunk 500

This process is called chunking.

A chunk is simply a smaller piece of the original document.

Why do we need chunks?

You don't necessarily want to embed the entire 100-page document.

We split large documents into smaller chunks so the AI can process and understand information more effectively.

It also helps the retriever find only the most relevant pieces instead of searching through the entire document.

Which splitter should we use?

RecursiveCharacterTextSplitter is a great starting point.

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)

chunks = text_splitter.split_documents(documents)

Conceptually:

Document
↓
Try paragraphs
↓
Too large?
↓
Try smaller boundaries
↓
Eventually split further

It tries to keep related text together rather than blindly chopping at arbitrary positions.

What is chunk overlap?

Imagine:

Chunk 1:
A B C D E F
Chunk 2:
E F G H I J
E F is the overlap.

Why? Because important information might sit around a boundary.

Without overlap, you could separate related information. A small overlap helps preserve continuity.

Few other text splitters :

CharacterTextSplitter- Simple splitting based on a character separator.
TokenTextSplitter- Splits based on tokens, useful when working with token limits.
MarkdownHeaderTextSplitter- Useful for Markdown documents while preserving headings/structure.
SemanticChunker- Splits text based on semantic meaning rather than just character count.

3. Component 3 — Embedding Model

Stores the chunks as numerical embeddings so they can be searched by meaning.

"Employees receive 20 days of annual leave."
                  ↓
          Embedding Model
                  ↓
[0.023, -0.421, 0.812, ...]

That list of numbers is an embedding vector.

What Embedding model should we use?

Since I want free local open models, I can use a Hugging Face/Sentence Transformers embedding model locally. Hugging Face models

Good candidates:

BAAI/bge-small-en-v1.5
intfloat/e5-base-v2
all-MiniLM-L6-v2

To start with, I'd recommend: BAAI/bge-small-en-v1.5

Why?

Open model
Can run locally
No per-request API fee
Good for semantic retrieval
Lightweight enough for experimentation
Well suited to RAG/semantic search

You can use it through LangChain's Hugging Face integration.

What about Gemini?

Here's an important distinction.

Gemini is an LLM/model family from Google, but your RAG pipeline needs two different model capabilities:

Embedding model
        +
Generation model

You need an embedding model to turn chunks/questions into vectors.
You need a generative LLM to produce the final answer.

So your architecture could be:

PDF
 ↓
LangChain (RecursiveCharacterTextSplitter)
 ↓
Chunks
 ↓
Embedding Model (BGE ← embedding model)
 ↓
Vector DB (ChromaDB)
 ↓
Retriever
 ↓
LLM (Gemini ← generation model)
 ↓
Answer

4. Component 4 — Vector Database 🗄️

Stores the chunks as numerical embeddings so they can be searched by meaning.

Now we have:

Chunk
 ↓
Embedding model
 ↓
Vector

We need somewhere to store those vectors. That's where Vector Database comes in.

I'll go with ChromaDB because it's simple, local, free to experiment with, and integrates nicely with LangChain.

Think of ChromaDB as a specialized database for your AI application's semantic search.

Chunk 1 → Vector 1
Chunk 2 → Vector 2
Chunk 3 → Vector 3
Chunk 4 → Vector 4

Chroma stores the vectors along with associated information such as document content and metadata.

Why not just use a normal database?

Traditional databases are great for exact keyword or structured searches, but RAG needs to find information based on meaning.

Vector search helps find that semantic relationship.

For example:

Question: “How many vacation days do employees get?” Document: “Employees receive 20 days of annual leave.”

A vector database can recognize that “vacation days” and “annual leave” have similar meanings by comparing their embeddings, even though the exact words are different.

Practical ChromaDB implementation

LangChain provides a Chroma integration.

Conceptually:

from langchain_chroma import Chroma

vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embedding_model,
    persist_directory="./chroma_db"
)

Some other Vector database examples:

FAISS — Free, open-source, excellent for local projects and learning.
Qdrant — Open-source vector database with strong filtering and search capabilities.
Weaviate — Open-source vector database with a free self-hosted option.
Milvus— Open-source and designed for large-scale vector search.

5. Component 5 — Retriever 🔎

Finds and returns the most relevant chunks from the vector database based on the user's question.

The retriever is the component that says:

"Given this question, which chunks should I bring back?"

Suppose the user asks:

How many annual leaves do employees get?
The process becomes:

Question
   ↓
Embedding Model
   ↓
Question Vector
   ↓
ChromaDB
   ↓
Similarity Search
   ↓
Top relevant chunks

For example:

retriever = vectorstore.as_retriever(
    search_kwargs={"k": 3}
)

Here, k = 3. Means return the 3 most relevant chunks.

Therefore,
🥇 Chunk 32 → 0.92 similarity
🥈 Chunk 31 → 0.84 similarity
🥉 Chunk 89 → 0.71 similarity

The top results are sent to the LLM.

These retrieved chunks become the context provided to the LLM to generate the answer.

But how is this "similarity" actually calculated?

One of the most common methods is cosine similarity.

Look at the direction of two vectors and see how similar they are.

If two vectors point in similar directions: Similarity → HIGH

If they point in very different directions: Similarity → LOW

Formula for cosine sinilarity is:

              A · B
cosine = ─────────────
         ||A|| × ||B||

A = question vector
B = chunk vector
A · B = dot product
||A|| = magnitude of vector A
||B|| = magnitude of vector B

(This is just for knowledge purposes, you don't have to worry about the formula as Retriever is taking care of all the calculations bts.)

So conceptually:

Similar meaning
      ↓
Similar vector direction
      ↓
High similarity score

Look at these two sentences:

"How many vacation days do employees get?""Employees receive 20 days of annual leave."
They don't share many exact words. But their meaning is related.

The embedding model has learned semantic relationships, so their vectors can end up relatively close in the embedding space.

That's why vector search can find:

annual leave
when the user asks about:

vacation days

ChromaDB doesn't generate the answer.
ChromaDB doesn't understand the question like an LLM.
It performs vector similarity search.

Question Vector
       ↓
[0.11, -0.43, 0.76, 0.24...]

       ↕
       ↕ similarity
       ↕

Chunk 1 Vector
[0.12, -0.45, 0.78, 0.21...]

Chunk 2 Vector
[0.15, -0.40, 0.72, 0.18...]

Chunk 3 Vector
[-0.72, 0.31, -0.15, 0.84...]

The system calculates how similar the vectors are.

6. Prompt — Giving the LLM the Right Context 📝

Combines the user's question with the retrieved context and tells the LLM how to answer.

For example, the user asks:

"How many annual leave days do employees get?"

The retriever might find:

Context:

Employees are entitled to 20 days of annual leave per calendar year. Employees must submit their leave requests through the HR portal.

Instead of simply sending the question How many annual leave days do employees get? to the LLM, we provide the LLM with both:

📚 Context
+
❓ User Question
+
📝 Instructions

And now the LLM has the information it needs.

The LLM combines the retrieved context with its own language understanding to generate a relevant, natural-language answer to the user's question.

For example:

User Question
"How many vacation days do employees get?"
          ↓

📚 Retrieved Context
"Employees receive 20 days of annual leave....."
          +
🧠 LLM's language understanding
          ↓

💬 Answer
"Employees receive 20 days of annual leave per year."

Prompt Template in LangChain

Instead of manually creating strings every time, LangChain lets us create a reusable Prompt Template.

For example:

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template("""
You are a helpful assistant.

Answer the question using only the provided context.
If the answer is not present in the context,
say that you don't have enough information.

Context:
{context}

Question:
{question}

Answer:
""")

Now every time a user asks a question, we can insert:

context
+
question

into the template.

Which LLM to use?

Gemini Flash

For this project, we'll use Gemini through its free API tier. If you specifically need an open-weight model that can run locally, Gemma is a suitable alternative.

Why Gemini?
✅ Free tier available
✅ Very capable for RAG question answering
✅ Easy to integrate with LangChain
✅ Works nicely in Google Colab
✅ No need to run a large LLM locally

(FYI: Gemini is not an open-source model. It is Google's proprietary model family that currently offers a free API tier for certain models/usage.)

Your code sends the request to Google's API:

Your Python code
      ↓
Gemini API
      ↓
Google's servers run Gemini
      ↓
Answer returned

Few other LLMs:

Llama— Meta's open-weight models, widely used for local AI and RAG applications.
Mistral— Efficient open-weight models that work well for RAG and text-generation tasks.
Qwen— Alibaba's open-weight models, offering strong performance across many AI tasks.
GPT-OSS — OpenAI's open-weight models designed to run on your own infrastructure.

Grounding

The prompt can also instruct the LLM to ground its answer in the retrieved context.

For example:

❌ Don't make up information.

✅ Answer using the provided context.

❓ If the context doesn't contain the answer,
   say that you don't know.

This is important because LLMs can sometimes generate plausible-sounding information that isn't actually present in your documents.

RAG helps reduce this problem by providing relevant external context.

RAG doesn't magically eliminate hallucinations, but good retrieval + good prompting can significantly improve grounded responses.

6. Generation — The LLM Generates the Answer 🤖

Generation is the final step where the LLM uses the retrieved context along with its language understanding to generate a relevant, natural-language answer.

Example:

Context: "Employees receive 20 days of annual leave."
Question: "How many vacation days do employees get?"
                    ↓
                  🤖 LLM
                    ↓
Answer: "Employees receive 20 days of annual leave per year."

In simple words: Retrieve the information → Give it to the LLM → LLM generates the answer.

Conclusion 🚀

And that's RAG from scratch! We've walked through the complete journey of a document, from loading and chunking the content to creating embeddings, storing them in ChromaDB, retrieving relevant context, and finally using an LLM to generate an answer.

The key takeaway is that RAG isn't just about using an LLM, it's about giving the LLM the right information at the right time. By combining retrieval with generation, we can build AI applications that can work with our own documents and knowledge sources.

I hope this breakdown made the RAG pipeline a little less intimidating and a lot more understandable. 😊
Now it's your turn, try it with your own documents and see what you can build!

💻 Try It Yourself

Want to experiment with the complete pipeline? I've put together a practical notebook that walks through the implementation step by step. You can run it, experiment with different documents, models, chunk sizes, and retrieval settings, and see how each component affects the final answer.

🔗 Open the Google Colab Notebook

AI Tokens Explained: The Tiny Building Blocks Behind ChatGPT and Generative AI🧩🧩

Anushka Gupta — Wed, 22 Jul 2026 21:00:37 +0000

Let's start with the simplest definition:

A token is a small piece of text that an AI model processes as input or generates as output.

An AI model doesn't read text exactly the way humans do.

You see:

"I love learning AI."
The AI might break this into tokens somewhat like:

"I" " love" " learning" " AI" "."

The exact tokenization depends on the model and tokenizer.

So, a token can be:

A complete word
Part of a word
A punctuation mark
A space combined with a word
Sometimes special symbols

Tokens Are Not the Same Across Models
Different AI models may tokenize text differently.

For example:

"GenerativeAI"
might be:

Model A:
["Generative", "AI"]
Model B:
["Gener", "ative", "AI"]
The exact number of tokens depends on:

Model
Tokenizer
Language
Text

Therefore, you should not assume: 1 word = 1 token

Why Does AI Use Tokens?

Computers work with numbers.

An LLM cannot directly process "I love learning AI".

Instead, the text goes through a process:

Human Text
     ↓
Tokenizer
     ↓
Tokens
     ↓
Token IDs (Numbers)
     ↓
Neural Network
     ↓
Predicted Token IDs
     ↓
Text

This whole process of breaking text into tokens is called Tokenization.

For example:

Input:

"I love Pizza!"
Tokenizer:

I love Pizza !

Then each token is mapped to a number called a token ID.

I → 12345 love → 4567 Pizza → 234 ! → 45

Is Token ID the same as Vectors?

Now, here comes an important question: if token IDs represent words as numbers, then what are vectors?

(I have already discussed about Vectors and Embeddings in my previous blog. I would recommend you to check that out to fully understand the context here.)

Coming to the point. The answer of the above question is No. Token IDs and vectors are not the same thing, although both are represented using numbers. This is a very common confusion when learning how LLMs work.

The process is:

Text → Token IDs → Vectors → LLM processing

                 HUMAN TEXT
                     │
                     ▼
               ┌───────────┐
               │ Tokenizer │
               └───────────┘
                     │
                     ▼
                 TOKEN IDs
               [40, 1832, 2456]
                     │
                     ▼
            ┌─────────────────┐
            │ Embedding Layer │
            └─────────────────┘
                     │
                     ▼
            VECTOR REPRESENTATION
           [0.12, -0.45, 0.87, ...]
                     │
                     ▼
                    LLM
                     │
                     ▼
             NEXT TOKEN PREDICTION

Token IDs are identifiers. Vectors are numerical representations.

Let's take an example to clearly understand the concept of Token IDs, Vectors and Embeddings:

 "I love pizza"
      ↓
   TOKENIZER
      ↓
  Token IDs (Identifies a token)
[45, 782, 1234]
      ↓
EMBEDDING MODEL
      ↓
  Embedding 
[0.21, -0.45, 0.87, ...]
(This list of nos. is a vector created to represent meaning)

Explaination:

🏷️ Token ID

"Which token is this?"
pizza → 1234

It's just an identifier. 1234 does not mean "pizza" mathematically.

🔢 Vector

"What is the numerical format?"
[0.21, -0.45, 0.87, 0.12]

Just a list of numbers.

🧠 Embedding

"What does this data mean?"

An AI model converts:

"I love pizza"

into an embedding, which is represented as a vector:

[0.21, -0.45, 0.87, 0.12]

The numbers collectively capture semantic information about the text.

Remember this:

Token ID = Identifier 🏷️ (tells the AI what token it is)
Vector = List of numbers 🔢 () (numerical form used to represent data.)
Embedding = Meaning represented as a vector 🧠 (represent what the data means)

Tokens and LLMs

Now let's understand how tokens actually work when you talk to ChatGPT or another LLM.

Suppose you type:

"What is RAG?"

The process looks like:

Your Question
      ↓
Tokenization
      ↓
Token IDs
      ↓
LLM processes tokens
      ↓
Model predicts next token
      ↓
Another token
      ↓
Another token
      ↓
Final Response

The model generates the answer one token at a time.

For example, it might generate:

RAG → stands → for → Retrieval → Augmented → Generation → ...

Each generated token is selected based on probabilities learned by the model.

Does the AI Generate the Whole Answer at Once?
No.
You must have noticed when ChatGPT generates a response. Word by word, right?! It keeps predicting the next token until it decides the response is complete.

This is why LLMs are sometimes called autoregressive models in the context of next-token prediction.

Tokens and AI Pricing 💰

Before I tell you about the token cost, I'll first explain to you what we mean by token usage.

Tokens are generally divided into two categories:

1. Input Tokens: The tokens you send to the model.

For example:

User:
Explain RAG in simple terms.

Your input might include:
System instructions + Your question + Conversation history + RAG context/documents + Tool results

All of these consume input tokens.

2. Output Tokens: The tokens the model generates.

RAG stands for Retrieval-Augmented Generation...
So, for a basic request:

Input Tokens
     +
Output Tokens
     =
Total Token Usage

For example:

Your request
      ↓
Input: 5,000 tokens
      +
Output: 2,000 tokens
      ↓
Total: 7,000 tokens

If the model's available context window is 128K, you're well within the limit.

Wait, What Is a Context Window?

This is another extremely important concept.

An LLM has a maximum amount of text it can process at one time. This is called its context window.

┌───────────────────────────────┐
│       Context Window          │
│                               │
│ System Instructions           │
│ +                             │
│ Previous Conversation         │
│ +                             │
│ User Prompt                   │
│ +                             │
│ Retrieved Documents (RAG)     │
│ +                             │
│ Generated Response            │
│                               │
└───────────────────────────────┘

Everything needs to fit within the model's context limits.

What Happens When You Exceed the Context Window?

Suppose:

Context Window = 100,000 tokens
But you try to send:

120,000 tokens
The model cannot process all of them within that request.

Depending on the application, you may see:

An API error
Input truncation
Older conversation content removed
Context being summarized

The exact behavior depends on the model and platform.

Coming to Token pricing. It is one of the most important topics to understand if you're building GenAI applications using APIs.

The basic idea is:

You are generally charged based on how many tokens your application sends to the model and how many tokens the model generates.

The cost may depend on:

Input token price
Output token price
Model being used

This means developers need to manage tokens carefully.

Simple Example:

Let's imagine a fictional model with pricing:

Input:
$1 per 1 million tokens
Output:
$5 per 1 million tokens
Suppose your application uses:

Input = 100,000 tokens
Output = 20,000 tokens

Input cost
100,000 / 1,000,000 × $1 = $0.10

Output cost
20,000 / 1,000,000 × $5 = $0.10

Total
$0.10 + $0.10 = $0.20

So the request costs $0.20.

This is just a hypothetical example to explain the calculation. Real model prices vary significantly.

Token Cost vs Context Window

Don't confuse these two.

Imagine:

Model Context Window = 128K tokens
This means the model can process a certain amount of context within its supported limits.

It doesn't mean: "You have to use 128K tokens."
You could send:

2,000 tokens and still use the same model.

You pay based on your actual usage according to the provider's pricing, not simply because the model supports a 128K context window.

Think of it like a backpack:

🎒 Backpack capacity = Context window

📦 What you actually put inside = Token usage

💰 What you pay for = The actual usage according to the pricing model

One simple formula to remember:

Total LLM Cost ≈ (Input Tokens × Input Rate) + (Output Tokens × Output Rate)

Where Are Tokens Used?

Tokens are used across almost every part of modern Generative AI.

1. Chatbots
User Question → Tokens → LLM → Output Tokens

2. RAG
Question → Tokens → Retrieve Context → LLM → Answer

3. AI Agents
Goal → Tokens → Reason → Tool Call → Tool Result → Tokens → Final Answer

4. Summarization
Long Document → Tokens → LLM → Summary Tokens

The Simplest Way to Remember:

Think of an LLM like a chef.

Tokens are the ingredients 🧱- The model processes language as small pieces.
The context window is the kitchen counter 🏠- You can only have a limited amount of ingredients on the counter at once.
The LLM is the chef 👨‍🍳- It uses the available ingredients to prepare the answer.
Token limits are the counter size 📏- If you bring too many ingredients, everything won't fit.
Token costs are the grocery bill 💰- The more ingredients you use, the more you may pay.

Vectors and Embeddings in Generative AI🤖(How AI Understands Meaning Instead of Just Words)

Anushka Gupta — Wed, 15 Jul 2026 18:39:11 +0000

One of the most confusing concepts in Generative AI is the difference between embeddings and vectors.

Many people use these terms interchangeably, but are they actually the same?

Not exactly.

Understanding this difference is essential if you're working with RAG (Retrieval-Augmented Generation), semantic search, recommendation systems, or AI chatbots.

Let's start with a simple example :

Imagine You're Organizing a Library 📚

Suppose your library contains these books:

Book 1
"Introduction to Machine Learning"

Book 2
"How to Bake a Chocolate Cake"

Book 3
"Deep Learning with Python"

Book 4
"Indian Desert Recipes"

Now someone asks:

"I want books about Artificial Intelligence."

Would you search for the exact keyword Artificial Intelligence?

No.

Book 3 doesn't even contain those exact words. Yet you know it's related.

Humans understand meaning. Computers don't...unless we convert meaning into numbers.

That's where embeddings come in.

Why Can't AI Understand Words Directly?

Computers only understand numbers.

They don't know what

Dog Cat Car Love Pizza

mean.

To a computer they're simply characters.

D o g

Nothing more.

So before AI can compare meanings, it converts words into numbers.

What is an Embedding?

An embedding is a numerical representation of data that captures its meaning and context.

Think of it as translating human language into a mathematical language that AI can understand.

Instead of storing

Machine Learning

AI stores something like

[0.42, -0.18, 0.91, 0.13, ...]

This list of numbers represents the meaning of the text.

Notice something...That list itself is actually a vector.

Wait... Then What's a Vector?

This is where most people get confused.

A vector is simply an ordered list of numbers.

Example:

[1, 5, 9]
or
[0.27, -0.83, 0.15, 0.92]

A vector has no inherent meaning. It's just numbers.

An embedding is a special type of vector whose numbers have been learned by an AI model to represent semantic meaning.

In other words:

Every embedding is a vector, but not every vector is an embedding.

Think of it like this:

Every mango is a fruit.
But not every fruit is a mango.

A Real-Life Analogy :

Imagine Google Maps.

Every city has coordinates.

Mumbai (19.0760, 72.8777)

Delhi (28.6139, 77.2090)

Coordinates don't describe the city. They simply tell you where it is.

Embeddings work similarly.

Instead of physical location, they represent semantic location.

Words with similar meanings end up close together.

Example : Suppose we have four words.

King Queen Apple Banana

Their embeddings might conceptually look like this:

King → [0.91, 0.77] Queen → [0.90, 0.79] Apple → [-0.83, 0.21] Banana → [-0.79, 0.25]

Notice:

King and Queen are close.
Apple and Banana are close.

The AI has learned relationships without anyone explicitly programming them.

How Are Embeddings Created?

This is where the embedding model comes in.

Popular embedding models include:

OpenAI text-embedding models
BAAI BGE
E5
Sentence Transformers
Cohere Embed

Suppose your document says:

Employees receive 20 annual leaves.

The embedding model reads the sentence and produces something like:

[0.22, -0.63, 0.89, 0.11, ...1536 numbers...]

Those numbers encode meaning.

Where Are Embeddings Stored?

Embeddings are stored inside a Vector Database.

Popular vector databases include:

Pinecone
Chroma
FAISS
Milvus
Weaviate

How Does the Vector Database Know Which Documents Are Similar?

Imagine this 2D space.

                 AI

                  ● Machine Learning

             ● Deep Learning

--------------------------------------------

      ● Pizza

             ● Burger

When someone asks:

"Tell me about AI."

The query embedding lands near:

Machine Learning
Deep Learning

Not near

Pizza

The vector database doesn't search words. It searches distances between vectors.

Measuring Similarity?

The database compares vectors using mathematical distance metrics.

Common ones include:

Cosine Similarity (most common for text)
Euclidean Distance
Dot Product

Imagine throwing a dart onto a map, the database returns the nearest neighbors to where your query landed.

The closer two vectors are, the more similar their meanings are.

Why Are Embeddings So Powerful?

They enable:

Semantic search instead of keyword search.
Better document retrieval for RAG.
Product recommendations.
Similarity search.
Duplicate detection.
Personalized content.
Question answering.
Document clustering.

Keyword Search vs Semantic Search

Suppose your document says:

"Employees are entitled to 20 days of annual leave."

You ask:

"How many vacation days do I get?"

A keyword search might fail because the document says annual leave, not vacation days.

A vector search succeeds because the embeddings for "vacation days" and "annual leave" are close in semantic space.

This is one of the biggest advantages of embeddings.

Final Takeaway

Vectors are simply numerical arrays. Embeddings are vectors that have been learned by AI models to capture semantic meaning. In a Generative AI application, documents and user queries are converted into embeddings and stored in a vector database. When a user asks a question, the query embedding is compared with stored embeddings to find the most semantically relevant information, which is then passed to the LLM to generate an accurate response.

In short:

Vectors are the language of mathematics. Embeddings are the language of meaning.

That's what makes modern AI systems capable of understanding concepts rather than just matching keywords.

RAG vs Agentic RAG : Explained with Real-World Examples

Anushka Gupta — Mon, 13 Jul 2026 16:27:59 +0000

Imagine you ask an AI:

"What is my company's leave policy?"

There are two ways the AI can answer:

It guesses based on what it learned during training.
It opens your company's HR documents, finds the correct policy, and then answers.

The second approach is Retrieval-Augmented Generation (RAG).

Now imagine instead of just looking up one document, the AI:

Decides which documents to search.
Realizes it needs more information.
Searches multiple sources.
Compares conflicting information.
Uses a calculator if needed.
Asks you a follow-up question if your request is ambiguous.
Verifies its answer before responding.

That's Agentic RAG.

Why Was RAG Needed?

Large Language Models (LLMs) like ChatGPT are trained on enormous datasets.

But they have limitations:

They don't know your private documents.
They don't know today's latest information unless connected to external sources.
They sometimes hallucinate (confidently generate incorrect information).

Imagine asking:

"What's the refund policy in my company's employee handbook?"

The LLM has never seen your handbook.

Without RAG it might answer:

"Most companies allow refunds within 30 days..."

That sounds reasonable...but could be completely wrong.

What is RAG?

Retrieval-Augmented Generation (RAG) is a technique that allows an AI model to retrieve relevant information from external knowledge sources before generating an answer.

Instead of relying only on its training, the AI first looks up the information, then writes a response using what it found.

Think of it like an open-book exam instead of a memory test.

Everyday Analogy :

Imagine you're a chef.

Someone asks:

"How many grams of salt does Grandma's lasagna recipe use?"

Option 1:

You guess.

Option 2:

You open Grandma's recipe book,
read the recipe,
then answer.

RAG is Option 2.

How RAG Works

Suppose your company has thousands of PDF files.

HR Policy.pdf
Employee Handbook.pdf
Travel Policy.pdf
Insurance Guide.pdf
IT Security.pdf

Now someone asks:

"How many casual leaves do employees get?"

The workflow looks like this:

User Question (Query)
      │
      ▼
Convert question into embeddings
      │
      ▼
Search Vector Database
      │
      ▼
Retrieve most relevant documents (Context)
      │
      ▼
Send retrieved content + question
to the LLM (Query + Context)
      │
      ▼
Generate final answer

The AI doesn't search every document. Instead, it retrieves only the most relevant ones.

Advantages of RAG

Up-to-date Information
No retraining needed. Just update documents.
Private Knowledge
Works with company documents.
Reduced Hallucination
Answers come from retrieved evidence.
Easy Maintenance
Updating a PDF updates the AI's knowledge.
Lower Cost
No need to retrain expensive models.

Limitations of RAG

RAG is powerful but still limited.

Suppose you ask:

"Compare all cloud providers, recommend one, calculate the yearly cost, and prepare a migration strategy."

Simple RAG retrieves documents.
It doesn't think step by step.
It retrieves once.
Answers once.

That's where Agentic RAG comes in.

You ask:

"I'm taking my parents out for dinner. Recommend a restaurant within ₹1500, serving vegetarian food, within 5 km, and book a table for 7 PM."

Traditional RAG :

RAG searches restaurant documents or reviews and replies:

Restaurant A
Restaurant B
Restaurant C

Maybe it summarizes reviews.

Done.

It doesn't:

Check your budget
Filter by distance
Check table availability
Make a booking

It simply retrieved information.

Agentic RAG :

The AI thinks like this:

Step 1: Find vegetarian restaurants
↓
Step 2: Filter within 5 km
↓
Step 3: Check average pricing
↓
Step 4: Check table availability
↓
Step 5: Book a table
↓
Step 6: Send confirmation

Here the AI is planning and taking actions, not just retrieving information.

What is Agentic RAG?

Agentic RAG extends traditional RAG by giving the AI decision-making capabilities.

Instead of following a fixed retrieve-then-answer pipeline, the AI acts like an intelligent agent that can plan, reason, choose tools, retrieve information multiple times, and validate its own results before responding.

Agentic RAG Workflow :

User Question
      │
      ▼
Understand Goal
      │
      ▼
Plan Steps
      │
      ▼
Retrieve Information
      │
      ▼
Need More?
     Yes
      │
Retrieve Again
      │
Use Tools
      │
Reason
      │
Validate
      │
Generate Final Answer

Notice retrieval can happen multiple times.

Final Takeaway

Retrieval-Augmented Generation (RAG) make LLMs far more useful by allowing them to access external knowledge instead of relying solely on what they memorized during training. It reduces hallucinations, keeps responses current, and enables AI to answer questions using private or domain-specific data.

Agentic RAG takes this a step further. Rather than following a single retrieve-and-answer pipeline, it behaves like an intelligent agent: it plans, retrieves information iteratively, uses tools, reasons through complex tasks, and validates its work before producing an answer.

A simple way to remember the difference is:

RAG helps an AI know more.
Agentic RAG helps an AI think and do more

npm vs pnpm: The Package Manager Battle Every React Developer Should Know

Anushka Gupta — Sun, 05 Jul 2026 20:41:50 +0000

If you've started learning React or Node.js, you've probably come across commands like npm install or pnpm install. Both npm and pnpm are package managers, they help you install and manage the libraries your project depends on.

Think of them as delivery services for your code. Need React? Axios? Tailwind CSS? Your package manager fetches and installs them for you.

What is npm?

npm (Node Package Manager) is the default package manager that comes with Node.js. It's widely used and works great for most projects.

npm install

What is pnpm?

Interestingly, pnpm doesn't officially stand for a fixed expansion. The name is commonly interpreted as: Performant Node Package Manager.
pnpm is a faster and more disk-efficient alternative to npm. Instead of downloading the same package multiple times for different projects, pnpm stores it once and reuses it wherever needed.

pnpm install

The Key Difference :

The main difference between npm and pnpm is how they install and manage dependencies. Both can be used to create and manage React projects, but pnpm is generally faster and more space-efficient.

Imagine you have two projects:

Project A uses React and Axios
Project B uses React only

With npm, each project keeps its own copy of the dependencies.

Project A
node_modules/
    react
    axios

Project B
node_modules/
    react

This duplicates packages across projects.

With pnpm, packages are stored once in a global store and linked to projects when needed. This saves both installation time and disk space.

Global Store
react
axios
lodash

Each project's node_modules contains links to these packages instead of full copies.

Project A
node_modules -> links

Project B
node_modules -> links

**
Why Developers Love pnpm
**
✅ Faster installs

✅ Less disk usage

✅ Better dependency management

✅ Excellent support for monorepos

A Real-World Example

Suppose Project B doesn't have Axios listed in its package.json, but your code tries to use it:

import axios from "axios";

With pnpm, you'll immediately get an error because Axios wasn't declared as a dependency.

Error: Cannot find module 'axios'

Here, your project can only access packages that are explicitly listed in its own package.json

While this may seem strict, it actually prevents the classic "works on my machine" problem and makes projects more reliable for teams.

The key thing to understand is that pnpm's global store is not the same as your project's dependencies.

With npm, the behavior is different because dependencies can sometimes be accidentally accessible.

Suppose Project B doesn't have Axios in its package.json:

{
  "dependencies": {
    "react": "^19.0.0"
  }
}

Now, when you do :
import axios from "axios";
What can happen?
If another package in node_modules already installed Axios as its own dependency, your code might still work with npm.

Project B
│
├── package.json
│   └── react
│
└── node_modules
    ├── react
    ├── some-library
    │   └── axios
    └── ...

Your application may successfully import axios even though you never declared it.

The problem: Another developer or your CI/CD pipeline may install a slightly different dependency tree where Axios isn't present at that location. Suddenly, the same code fails.

This leads to the classic:

✅ Works on my machine
❌ Fails on yours

Final Thoughts

npm is reliable, popular, and perfectly fine for many projects. But if you're starting a new React application, pnpm offers faster installs, better dependency isolation, and significant disk space savings.

That's why many modern development teams are making the switch to pnpm.