Session-based Vector Stores
- Why
- Each user gets an isolated FAISS index
- Trade-off
- Uses more memory but prevents data leakage between users
- Alternative
- Shared store with tenant filtering (more complex)
Guide 04 — Case study
About the build.
The design decisions, technical choices and lessons behind this RAG implementation, plus an honest list of what production would still need.
01 — Overview
Beyond the tutorial.
RagXGen is a portfolio project built to demonstrate a working understanding of Retrieval-Augmented Generation: a complete implementation with clear architecture and an honest discussion of trade-offs.
The goal is to show employers, collaborators and AI leads the ability to build, evaluate and improve real systems, not just follow a guide.
- Full-stack implementation (Next.js + FastAPI)
- Real RAG pipeline with FAISS + LangChain
- Interactive demo with live document processing
- Production-style code patterns
02 — Tech stack
What it runs on.
Frontend
- Next.js 14App Router for modern React patterns
- TypeScriptType safety and better DX
- Tailwind CSSReset and utility layer
- GSAP + LenisScroll choreography and smooth scrolling
Backend
- FastAPIHigh-performance async Python API
- PydanticData validation and settings
- LangChainRAG pipeline orchestration
- FAISSVector similarity search
AI / ML
- GPT-4o-miniResponse generation (any OpenAI-compatible API)
- text-embedding-3-smallDocument embeddings
- RecursiveCharacterTextSplitterSmart chunking
03 — Design decisions
Each choice, and its cost.
In-memory Storage
- Why
- Simplicity for demo purposes
- Trade-off
- Data lost on server restart
- Alternative
- Persist FAISS indices to disk or use managed vector DB
RecursiveCharacterTextSplitter
- Why
- Handles various content types well
- Trade-off
- May not be optimal for highly structured documents
- Alternative
- Semantic chunking or document-specific splitters
Low Temperature (0.1)
- Why
- Prioritizes factual, consistent responses
- Trade-off
- Less creative, may be repetitive
- Alternative
- Higher temperature for creative tasks
04 — Lessons learned
What building it taught.
Lesson 01
Start Simple
Basic RAG works surprisingly well. Add complexity only when needed.
Lesson 02
Chunk Size Matters
Too small = no context. Too large = noise. 1000 chars is a good starting point.
Lesson 03
Prompt Engineering is Key
The system prompt significantly affects response quality and grounding.
Lesson 04
Observability is Essential
Log retrieved chunks and scores to debug and improve the pipeline.
05 — Production
What production would add.
If this were deployed for real users, these come next.
Retrieval Quality
- Add reranking with a cross-encoder model
- Implement hybrid search (semantic + keyword)
- Use HyDE (Hypothetical Document Embeddings)
- Add query expansion/reformulation
Scalability
- Use managed vector DB (Pinecone, Weaviate, Qdrant)
- Add Redis caching for frequent queries
- Implement connection pooling
- Deploy with auto-scaling
Reliability
- Add comprehensive error handling
- Implement retry logic with exponential backoff
- Add health checks and monitoring
- Set up structured logging
User Experience
- Streaming responses for faster perceived latency
- Add conversation history and memory
- Implement feedback collection
- Support more file formats (DOCX, HTML, etc.)
Let's connect
Talk RAG, or try it.
Interested in RAG, AI engineering, or working together? The source is on GitHub, and the demo is one click away.