方寸 Portal

AI Engineer Portal

Your personal operating system for career transition.

Private mode

Exercise

Build a production RAG pipeline with caching and fallbacks

Build a Production RAG Pipeline with Caching and Fallbacks

A RAG pipeline that works in a demo rarely survives its first month in production. The embedding API goes down. The vector database returns stale results. The LLM provider has a service disruption. Users send the same question 50 times in an hour. Without caching and fallback strategies, every one of these situations becomes a user-facing failure.

What you are building

Create a ProductionRAGPipeline class that adds operational resilience to a basic RAG pipeline:

  1. Query result caching — cache query -> (chunks, answer) with configurable TTL using a dict with timestamps. Cache miss triggers full retrieval + generation.
  2. Retrieval fallback — if the primary retriever raises an exception, fall back to a secondary retriever (injectable). Track which path was used.
  3. Generation fallback — if the primary LLM fails, fall back to a secondary LLM. If both fail, return a graceful degraded message.
  4. Per-step timing — track latency for retrieval, generation, and total in milliseconds.
  5. Circuit breaker for the primary retriever — after 3 consecutive failures, skip the primary and use the fallback directly until a success resets the count.
  6. Returns a PipelineResponse with: answer, chunks, from_cache bool, fallback_used string, latency breakdown, and error context.

Why this matters

Caching eliminates redundant work for repeated queries (common in help-center bots where 20–40% of queries repeat within an hour). The fallback chain ensures a degraded-but-working answer instead of an error page. The circuit breaker prevents timeout latency from cascading across all requests when a service is degraded.

Constraints

  • Standard library only (use time.monotonic). Injectable callables for testability.
  • Retrieve function: Callable[[str], list[dict]]. LLM function: Callable[[str, list[dict]], str].

Retrieval / hard / Step 13 of 15

Practice stage

Retrieval quality and ranking

Hint

Do not trust a single score blindly. Combine ranking logic with metadata and think about why a candidate deserves to rise.

Success criteria
  • - Ranking rule is explainable
  • - Supports future iteration without rewriting everything
  • - Feels tied to product trust rather than pure math trivia
Review checklist
  • - Did I account for both relevance and metadata?
  • - Would I be able to explain the ranking rule in an interview?
  • - Does the code make future tuning easy?

Practice

Generate a variation

Generate a new exercise variation to deepen understanding or practice a related concept.

Attempt history

Recent submissions

Before you submit, decide what a strong answer should make obvious to the reviewer.

No attempts yet.