Point at the pipeline and say it plainly: embeddings are numbers sitting in RAM right now with nowhere to live. Today is just "where do they live, and how do we search them fast." Keep it that simple going in.
Let this animation run for a few seconds before saying anything, the dots gently pulsing is meant to feel like "checking, checking, checking." Then say: this is called exact search, and it's exactly this simple, and exactly this slow at scale.
Library analogy works well here. Nobody reads every book to find one topic, they use the index card system. That index is a little imperfect but nobody cares because it's fast and right almost every time. FAISS, HNSW, and IVF are all just different ways of building that index.
Fifty thousand vectors sounds like nothing, and 0.255 milliseconds sounds fast. That's the trap. Ask the class what happens at 500 million vectors instead of 50,000. This is why exact search stops being an option long before you'd expect.
It's not chosen based on the question. One entry point gets fixed the moment the index is built, usually just whichever vector was added first. Every single search, no matter what's being asked, starts at that exact same node and greedily works outward from there.
Read the three numbered steps out loud against the graph before saying anything else. Then ask the room the question they're probably already thinking: why node 1, why not somewhere closer to begin with. The answer is the callout, it's fixed at build time, the algorithm never picks a custom starting point per question.
Run this cell live, don't just show the bars. Ask someone to guess what happens at efSearch=256 before you scroll to the number. Watching it climb toward, but never quite reach, 100 percent is the whole lesson in one table.
Follow the two dashed lines from the question down to the two orange clusters, those are the only neighborhoods that get searched. The three gray circles off to the side are skipped completely, not one vector inside them gets compared. That's nprobe, literally how many of these circles you bother checking.
Compare this to the HNSW numbers a couple of slides back. At a similar rough time budget, HNSW gets noticeably higher recall. Say plainly that this is why most vector databases default to HNSW today, IVF just doesn't win this comparison as often anymore.
Ask the room: would you rather your product be a little wrong sometimes and instant, or occasionally slow and always right. There's no correct answer, that's the point, the answer depends entirely on what you're building.
This is the single most useful slide in the whole notebook for clearing up confusion. FAISS is the bare engine you wire up yourself. Chroma wraps that engine with an actual small database around it, still yours to run. Pinecone wraps it again with someone else running the whole thing on their servers. Same bottom layer, every time.
Query: "How do I get my money back?" Top hit: the refund policy sentence, no shared words needed.
Same idea, but only search where topic is hr and year is 2024. This is how you enforce tenants and access rules in a real product.
The filtering demo is the one to slow down on. This is the feature that turns "cool vector search demo" into "something you could actually ship to a company with different customers and permissions."
Be honest about the trade here. Zero ops sounds free, it isn't, you're paying in dollars and in being locked into their platform instead of paying in engineering time. Frame it as a real decision, not a strictly better option.
| Option | What it is | Reach for it when |
|---|---|---|
| FAISS | In-process library | You want raw control, or you're learning how ANN actually works |
| Chroma | Embedded database | Local dev, small to mid projects, you want filtering without a server |
| Pinecone | Managed serverless | Production scale, zero ops, and the hosted cost is fine |
| pgvector | Postgres extension | You already run Postgres, don't add a new system just for vectors |
| Qdrant / Weaviate | Self-host or managed | Strong filtering or hybrid search, under roughly 50 million vectors |
| Milvus | Distributed database | Billions of vectors, and you have the ops team to run it |
Someone always asks "which one is best." There isn't one. Answer with the question back: how many vectors, who's maintaining it, and what's the budget. That's the actual decision.
| Time | Segment |
|---|---|
| 0 to 5 min | Recap embeddings, land "we need somewhere fast to search these" |
| 5 to 10 min | The brute-force scan diagram, then the exact search baseline number |
| 10 to 25 min | HNSW graph diagram and its knob, then IVF cluster diagram and its knob |
| 25 to 32 min | The layered stack diagram, FAISS versus Chroma versus Pinecone |
| 32 to 40 min | Chroma and Pinecone demos, live if the API keys are set |
| 40 to 45 min | Choosing table, hand off to sparse retrieval |
Notebook 06 shows exactly where dense embeddings fail, on a labeled corpus with known right answers, and why keyword search still earns its place in a real pipeline.