Recipes: a traced request, cache keys with invalidation, a budget table
Production-shaped but small: the tracer uses simulated time, the cache is in memory. Swap in your tracing library and shared cache; the shapes stay.
Four recipes to copy into any RAG project: a traced request, cache keys with invalidation, a latency budget table, and a migration runbook for changing the model. Plus a launch checklist for the production side.
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 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write cut_over_allowed(old_hits, new_hits, regressions) returning True only when new_hits is at least old_hits and the list of regressions is empty. Print yes or no for the cases (3, 5, []), (3, 5, ["Q1"]) and (5, 4, []).
Write batches(ids, size) that splits a list into consecutive lists of at most size ids, and print the lengths of the batches for 8 ids and size 3.
Explain it without notes
What goes into a RAG cache key, and what must happen to entries when a document changes?
How would you use a latency budget table in operations?
Walk through the migration runbook for changing the embedding model.
What would you check before launching a RAG service, on the operations side?
Expected output
req=r1 embed=30 search=120 rerank=120 generate=310 total=580
budget: search over by 40
key: toy-v1|index8|p3|what does the monthly pass cost
get before edit: hit
invalidate D8 removed 1 entries
get after edit: miss