Week 9 · Phase 2 Engineering & Tools
The Vector Search Playground
Yesterday's RAG pipeline asked “which chunks are closest?” — this is the machinery that answers it. Embeddings become points; search becomes geometry.
Click a document, find its neighbours
24 support tickets, embedded and projected to 2D. Click any point — the index returns its top-5 nearest neighbours, exactly like your Week 9 semantic-search build over 100+ documents.
Cosine cares about direction (topic), Euclidean about absolute position — with normalised embeddings they mostly agree, but watch the borderline results reshuffle when you switch.
Choosing your vector database
Same maths, very different operational trade-offs.
ChromaDB
- Runs in-process with your Python — zero infra
- Perfect for prototypes & the sandbox
- Persist to disk with one line
Pinecone
- Fully managed, scales past billions of vectors
- Metadata filtering + hybrid search built in
- Pay-per-use; no servers to run
pgvector
- Vectors inside PostgreSQL you already run
- Join embeddings with business data in SQL
- One database to secure, back up, govern
What “tuning retrieval” actually means
How many chunks you fetch. More = better recall, noisier prompts. Start at 3–5.
Drop results below a floor (e.g. 0.7) so irrelevant chunks never reach the model.
Matters as much as the LLM. Benchmark two on your own corpus, not on leaderboards.
Combine keyword (BM25) + semantic scores — rescues exact terms like error codes. Week 14 territory.
Week 9 outcome: a semantic search demo with precision metrics — which is precisely where Week 10 picks up.