Practice: Retrieval-augmented generation with vector databases

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Main tool: Retrieval-augmented generation (RAG) · The lesson's verified documentation covers the whole RAG pipeline on one managed vector database, from chunking and sparse or dense indexing through reranking to grounded generation and evaluation, so each stage can be practised without running your own search infrastructure. · Alternatives: pgvector keeps vectors inside an existing Postgres database, Qdrant and Weaviate are open-source vector databases you host yourself with built-in hybrid search, Elasticsearch and OpenSearch add vector search to a mature BM25 keyword engine, and LlamaIndex or LangChain are orchestration libraries that sit on top of any of these stores rather than replacing them.

Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1

Setup (one time)

1. Read the four-stage description of a RAG system and sketch the offline ingestion half and the online retrieval half for a corpus you know.
Every later step fills in one box of this diagram, so you need the ingestion, retrieval, augmentation and generation split in your head first.
Explained in: Retrieval-Augmented Generation (RAG) | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You have a one-page diagram naming the four stages and what data moves between them.
2. Install the Pinecone Python SDK in a fresh virtual environment and pick your target: the free starter tier with an API key, or the Pinecone Local emulator in a container if you want no cloud account at all.
All steps talk to the index through the SDK, and the local emulator is the closest laptop substitute when a cloud account is not available.
Explained in: What is a Vector Database & How Does it Work? Use Cases + Examples | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: A short script imports the SDK, connects and lists indexes without an error.
3. Initialise the client and create one empty index for the practice project, keeping the API key in an environment variable.
Getting the client and index creation working once removes connection problems from every later step.
Explained in: Building a reliable, curated, and accurate RAG system with Cleanlab and Pinecone | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: The new index appears in the index list and reports a ready status.
4. Assemble a small practice corpus of 30 to 50 documents you know well and write 20 questions whose answers are in it.
A corpus you can judge by eye plus a fixed question set is what makes later comparisons of chunking, search and reranking meaningful.
Explained in: RAG makes LLMs better and equal | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You have a folder of documents and a file of 20 questions with the expected source document for each.

Steps

1. Create a sparse index, upsert a handful of records from your corpus and run your first keyword-style query against it.
This is the shortest route to a working retrieval round trip, and it shows the lexical side of search before embeddings are involved.
Explained in: Don’t be dense: Launching sparse indexes in Pinecone | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: A query returns ranked record ids with scores, and the top hit is the document you expected.
2. Run the same five questions against the sparse index and against a dense index built with a free local embedding model, then combine the two result lists into one hybrid ranking.
Hybrid search exists because exact terms such as product codes and names are found by sparse vectors while paraphrases are found by dense ones. Seeing each miss what the other finds makes the case concrete.
Explained in: Don’t be dense: Launching sparse indexes in Pinecone | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You have a table per question showing sparse, dense and hybrid top five, with at least one question where the hybrid list beats both.
3. Run your 20 questions twice through a small model, once closed-book using only what the model knows and once with retrieved passages added, and record both sets of answers.
This separates parametric memory in the model weights from non-parametric memory in the index, which is the core architectural idea of RAG.
Explained in: RAG makes LLMs better and equal | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You can point at questions the closed-book run got wrong or refused and the retrieval run answered correctly.
4. Create two versions of the index content in separate namespaces, one with fixed-size chunks and one with structure-aware or recursive chunks, and compare retrieval hits on the question set.
Chunking decides what a single retrievable unit is, and persisting both variants side by side lets you compare them on the same questions instead of guessing.
Explained in: Chunking Strategies for LLM Applications | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You have a hit-rate number for each chunking strategy and a written choice of which one to keep.
5. Write a contextual chunking pass that asks a model for a short situating sentence per chunk, prepends it before embedding, and load the result into a third namespace.
Chunks cut out of a long document lose the context that says what they are about. Contextual retrieval restores it and usually rescues questions that plain chunks miss.
Explained in: Chunking Strategies for LLM Applications | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: At least one question that failed with plain chunks now retrieves the right chunk from the contextual namespace.
6. Configure the dense index deliberately: choose the similarity metric that matches your embedding model, attach metadata such as source and date to every record, and query with a metadata filter.
The metric and the filtering behaviour are properties of the vector index itself, and a wrong metric or missing metadata silently degrades every query built on it.
Explained in: What is a Vector Database & How Does it Work? Use Cases + Examples | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: A filtered query returns only records from the chosen source and the scores are consistent with the metric you set.
7. Create a backup or collection of the winning index and restore it under a versioned name as your promoted index. If your tier or the local emulator does not offer backups, re-ingest into a new versioned index as the substitute.
Treating an index as a versioned artifact lets you promote a known-good build and roll back when a new chunking or embedding change makes retrieval worse.
Explained in: What is a Vector Database & How Does it Work? Use Cases + Examples | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: Two indexes exist with version names and the promoted one returns the same top results as the original.
8. Run a reranker over the top 25 hybrid results for each question and keep only the best few passages for the context window. Use the hosted rerank endpoint on the free tier or a small open reranker model on CPU.
First-stage search is tuned for recall and a reranker restores precision, which lets you pass fewer and better passages to the model and keep the context window small.
Explained in: Refine Retrieval Quality with Pinecone Rerank | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: For several questions the relevant passage moves into the top three after reranking, and your context holds fewer passages than before.
9. Write the generation prompt so the model answers only from the supplied passages, cites the passage id for each claim and says it does not know when the passages are insufficient.
Grounded generation is what makes an answer checkable, and the refusal instruction is what stops the model from falling back to unsupported parametric knowledge.
Explained in: RAG makes LLMs better and equal | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: Answers carry passage ids you can trace to stored chunks, and an out-of-corpus question gets an explicit do-not-know reply.
10. Create an evaluation run that scores your 20 questions on retrieval hit rate and on answer faithfulness and relevancy, and store the scores next to the index version.
Most RAG quality problems are retrieval problems, so you need separate numbers for retrieval and for generation to know which half to fix.
Explained in: RAG makes LLMs better and equal | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: You have a results file with a retrieval score and an answer score per question for the promoted index.
11. Write one script with pinned dependency versions that rebuilds the index from the raw documents, covering parse, chunk, embed and upsert, and then reruns the evaluation. Run it from a clean environment.
An ingestion pipeline that only works from your notebook history cannot be rerun in CI or handed to a customer team. Rebuilding from scratch proves the result is reproducible.
Explained in: Retrieval-Augmented Generation (RAG) | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: A clean checkout plus one command produces a fresh index and evaluation scores within a small margin of your earlier run.
12. Configure a production-like layout: one namespace per tenant, a much larger corpus loaded through the pipeline, and latency measured for filtered queries under concurrent requests. Real scale needs a paid cloud plan, so use the free tier or local emulator with as many records as it allows.
Customer deployments are multi-tenant and latency-sensitive, and isolation and scale behaviour are the things that break first when a demo becomes a service.
Explained in: Domain-specific AI Agents at Scale: CustomGPT.ai Serves 10,000+ Customers with Pinecone | Pinecone (www.pinecone.io), checked 2026-10-11
Done when: Queries for one tenant never return another tenant's records, and you have recorded median and tail latency at your largest corpus size.

Back to Retrieval-augmented generation with vector databases