RAG & search
Chat with your PDF
Upload documents, ask questions in plain English, and get answers that cite the exact source page.
Copy or download the full plan and paste it into your AI coding agent to build it.
Why build it
Large language models don't know your private documents, and when they don't know something they tend to make it up confidently. RAG (retrieval-augmented generation) fixes this: instead of trusting the model's memory, you fetch the most relevant passages from your own documents at query time and force the model to answer only from them, with citations. This is the single most in-demand AI skill in 2026, because almost every company wants an assistant grounded in its own content. Master this one project and you understand the core pattern behind most production AI features.
Who it's for: Your first real AI project. If you can call an API and render a page, you can build this.
What you'll build
Core (MVP)
- Upload one or more PDFs
- Extract and chunk the text into overlapping passages
- Embed each chunk into a vector and store it
- Embed the user's question and retrieve the closest chunks
- Answer only from the retrieved context, with a strict grounding prompt
- Show the answer with clickable citations (filename + page)
Stretch
- Chat history and follow-up questions
- Highlight the exact cited passage on the page
- An 'I don't know' fallback when retrieval is weak
- Multi-document collections and filters
- Streaming responses
Step-by-step build
- 1
Set up the project
Scaffold a Next.js app, get a free Groq API key, and create a free MongoDB Atlas cluster. Add a vector search index on your chunks collection with the same number of dimensions as your embedding model (384 for all-MiniLM-L6-v2).
- 2
Ingest and chunk the PDF
On upload, extract the text, then split it into roughly 500-token chunks that overlap by about 50 tokens so no sentence is cut off. Keep each chunk's page number and source filename as metadata; you'll need them for citations.
- 3
Embed and store
Run every chunk through the embedding model and store { text, embedding, page, source } in your vector collection. Do this once per document, not per question. This is your searchable knowledge base.
- 4
Retrieve on a question
When a question comes in, embed it with the SAME model, then run a vector search for the top 4 to 6 nearest chunks. These, not the model's memory, are the only facts the answer is allowed to use.
- 5
Ground the answer
Build the prompt in three parts: a system message that says 'answer only from the context, cite sources as [page], and say you don't know if it isn't there', then the retrieved chunks, then the question. Send it to Groq.
- 6
Return answer + citations
Send back the model's answer along with the source chunks (filename + page) so the UI can render citation chips that link to where each claim came from. Verifiable answers are the whole point.
- 7
Build the UI
An upload area, a chat box, a streaming answer, and citation chips under each response. Keep it simple; the intelligence is in the retrieval, not the interface.
- 8
Handle the edges
Deal with empty or huge files, a retrieval that finds nothing (return 'I couldn't find that in your documents' instead of guessing), and API rate limits (back off or rotate keys).
- 9
Deploy and document
Ship it live, then write a README with the live link, a 20-second demo GIF, and one paragraph on how it works. That README is what recruiters actually read.
Done when
- ✓You ask 10 questions you know the answers to and every answer is correct and cites the right page.
- ✓You ask something that isn't in the documents and it says it doesn't know instead of inventing an answer.
- ✓A brand-new PDF works end to end with no code changes.
- ✓The live URL loads and works for someone who isn't you.
Ship it
Wrap the logic in a Next.js API route or a small FastAPI service, Dockerize it, and deploy the frontend on Vercel with data on Atlas and any heavy service on the AWS free tier. Put the live URL, a short demo GIF, and a plain-English 'how it works' at the top of the README.
What it proves: You can ground an LLM in real data with citations, the number-one skill on 2026 AI job descriptions, and you understand embeddings, vector search, and prompt grounding end to end.
Hand it to your AI agent
Paste this into Cursor, Claude, or ChatGPT and build it step by step.
You are my senior AI engineer pair. Help me build "Chat with your PDF", a RAG app, step by step. Stack: Next.js (UI + API routes), Groq API for the LLM, all-MiniLM-L6-v2 for embeddings, MongoDB Atlas Vector Search (free M0) for storage, pdf-parse for text extraction.
Requirements:
1. Upload PDFs; extract and chunk the text into ~500-token overlapping chunks, keeping page number and filename.
2. Embed each chunk and store { text, embedding, page, source }.
3. On a question, embed it and vector-search the top 5 chunks.
4. Answer ONLY from those chunks, with a system prompt that forbids outside knowledge, requires [page] citations, and returns "I don't know" when retrieval is weak.
5. A chat UI that streams the answer and shows clickable citations.
Work in this order: scaffold the app and the Atlas vector index, then ingestion, then retrieval, then the chat UI. Give me the commands and code for each step and STOP after each so I can test. Do not write the whole app at once.More in RAG & search
Semantic search over your notes
Search your own notes and markdown by meaning instead of exact keywords, and get back the passages that actually answer you.
Hybrid-search RAG + reranking
Combine keyword search and vector search, then rerank the merged hits with a cross-encoder so the passage the model reads is actually the best one.
Multimodal document RAG
Answer questions over documents whose real content lives in images, tables, and charts by having a vision model describe every visual and indexing those descriptions alongside the text.
Building this? I post a new AI project plan on LinkedIn most weeks. Follow along and share what you ship.