Where we left off

Every earlier lesson's failures had a fix: dense missed an ID, sparse caught it; sparse missed a paraphrase, dense caught it; fusion combined both and recovered. This lesson shows the case fusion can't fix: a question where neither retriever ranks the right document highly to begin with.

The code, piece by piece

QUESTION = "What change finally made things work reliably again?"
EXPECTED = "old_travel_router.md"

This question presupposes its own answer shape: "a change fixed something." old_travel_router.md's actual resolution is the opposite, it was deliberately kept on an older firmware build, specifically because updating had introduced a bug. Nothing "changed" in the sense the question assumes, the fix was refusing to change.

Why this matters more than it looks like

This isn't a corpus-size problem, more documents wouldn't fix a question built on a wrong assumption about its own answer. It's a genuine ceiling on what retrieval, dense, sparse, or fused, can do: retrieval finds documents that match a query's words or meaning, it has no way to notice when a query's premise is simply false for the document that actually answers it. Fixing this needs something retrieval alone can't provide, which is exactly the opening corrective_rag (course 4 in this series) is built around: grading retrieved results and rewriting the query when they don't hold up.

Checkpoint

  • Fusion recombines existing rankings, it can't invent a good rank for a document that both retrievers already ranked poorly.
  • A query built on a wrong assumption about its own answer's shape can defeat both dense and sparse simultaneously, for different reasons, with no floor to catch it.
  • This failure mode isn't fixed by anything in this course. It's a preview of why the series continues past Hybrid RAG at all.

If anything here still feels unclear, ask before moving to Lesson 17.