Recipe: do I even need an index?
The speed (1 billion multiply-adds per second per core), the 4 cores and the 50 percent rules are assumptions to reason with. Replace them with numbers measured on your hardware.
Recipes to copy into any vector search project: test whether you need an index at all, start from documented parameters, benchmark against exact search, shrink and re-score, choose a filter strategy, and keep recall from silently dropping.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write check_recall_floor(recall, floor) that returns "ok: recall 0.970 meets the floor 0.950" when recall is at least the floor and "FAIL: recall 0.930 is below the floor 0.950" otherwise (3 decimals). Print the result for 0.93 and 0.97 with a floor of 0.95.
Write needs_index(n, dim, budget_ms) that estimates the exact query time as n * dim // 1000000 milliseconds and returns "yes" when twice that is above the budget, otherwise "no". Print the answer for 50,000, 200,000 and 1,000,000 vectors of 384 numbers with a 200 ms budget.
Explain it without notes
Walk through the test for whether a project needs a vector index.
Where would you start with IVF and HNSW parameters, and what do you do next?
What does the benchmark harness need, and why must it work with any search function?
What belongs in CI to protect recall, and what does it not protect against?
Expected output
handbook: 12 chunks: 0 ms per query, 0% of 4 cores at 1/s, 0 MB -> exact search is enough
help centre: 50,000 chunks: 19 ms per query, 2% of 4 cores at 5/s, 76 MB -> exact search is enough
busy help centre: 200,000: 76 ms per query, 190% of 4 cores at 100/s, 307 MB -> use an index: too many queries for the cores
big archive: 1,000,000: 384 ms per query, 192% of 4 cores at 20/s, 1536 MB -> use an index: too slow for one query and too many queries for the cores
huge: 10,000,000 x 1024: 10240 ms per query, 12800% of 4 cores at 50/s, 40960 MB -> use an index: too slow for one query and too many queries for the cores