Retrieval-Augmented Generation (RAG) Pipeline

This project implements a complete Retrieval-Augmented Generation (RAG) system for structured business data.

The system is designed with a clear separation between offline ingestion and online retrieval & generation, following production best practices.

---

Chunking Strategy

Each row of the dataset is first concatenated into a single textual representation using relevant columns (e.g. date, product ID, category, promotion flag, competitor pricing).

Chunking strategy:

• One combined row → one chunk
• No cross-row concatenation
• Ensures semantic consistency and traceability of retrieved results

This approach is well-suited for structured or semi-structured tabular data, where each row represents an independent fact.

---

Embedding Model

A free, open-source embedding model is used to generate vector representations of the chunks.

Key characteristics:

• Runs fully offline
• No API keys required
• Suitable for local development and production environments
• Embeddings are computed during the offline ingestion phase

This design allows embeddings to be generated once and reused efficiently during retrieval.

---

Offline vs Online Phases

Offline (Ingestion)

• Chunk creation
• Embedding generation
• FAISS index construction
• Files saved locally

This step is executed once unless the dataset changes.

Online (Retrieval & Generation)

• User query is embedded
• Query vector is compared against stored document vectors
• Top-k relevant chunks are retrieved
• Retrieved context can optionally be passed to a language model for answer generation

---

Retrieval Method

The retrieval layer uses a FAISS index for efficient similarity search.

How retrieval works:

1. The user query is converted into an embedding vector
2. FAISS compares this query vector against all stored document vectors
3. Similarity is computed using vector distance
4. The top-k most relevant chunks are returned

FAISS provides fast, scalable vector search and is commonly used in production RAG systems.

---

Why FAISS Instead of a Vector Database

This project uses FAISS as the vector retrieval engine instead of a full vector database (e.g. Chroma, Pinecone, Weaviate).

Key Reasons

1. Lightweight and Offline-First

FAISS is a pure library-based solution:

• No server to deploy
• No background services
• No network overhead

This makes it ideal for local development, research, and reproducible pipelines.

---

2. Full Control Over the Retrieval Pipeline

Using FAISS allows direct control over:

• Index type selection (We can tune it and compare different results of different type)
• Distance metrics
• Index persistence
• Memory usage

This transparency is valuable for understanding and debugging similarity search behavior.

---

3. Production-Relevant Core Technology

Many vector databases internally rely on FAISS or FAISS-inspired algorithms.
By using FAISS directly, this project demonstrates understanding of the core retrieval mechanics behind modern vector search systems.

---

4. Cost and Vendor Independence

• No managed service costs
• No API usage limits
• No vendor lock-in

This enables free experimentation and easy migration to other systems if needed.

---

5. Clear Separation of Concerns

FAISS handles only what it is best at:

• Efficient nearest-neighbor search

Other responsibilities such as:

• Metadata handling
• Orchestration
• LLM inference

are intentionally kept outside the retrieval layer, resulting in a clean and modular design.

---

Design Philosophy

• Modular and reproducible pipeline
• No vendor lock-in
• Offline-first embedding computation
• Pluggable LLM backend (local or API-based)
• Suitable for both experimentation and production deployment