Where we left off

Lesson 6 showed sparse retrieval winning on bare IDs and losing on pure paraphrase. This lesson turns that observation into something usable before a query is even run: a rule of thumb for predicting, in advance, which retriever a given question is likely to need.

The code, piece by piece

ID_SHAPED = re.compile(r"[0-9]|-|^[A-Z]{2,}$")


def has_id_shaped_token(query: str) -> bool:
    return any(ID_SHAPED.search(token) for token in query.split())

A crude signal: does any word in the query contain a digit, a hyphen, or look like an all-caps acronym? None of those carry much "meaning" for an embedding model to place precisely (Lesson 1's whole premise), so a query built around one is a query where sparse retrieval's literal matching has the advantage.

Checkpoint

  • The heuristic: a query token with a digit, hyphen, or all-caps acronym shape is a signal sparse retrieval likely has the advantage.
  • Its blind spot: rare proper nouns with no digits or punctuation (a product name, a person's name) trip up dense retrieval the same way, without matching this particular rule.
  • Heuristics like this are useful for deciding which retriever's result to trust more, not a replacement for running both and fusing, which is why this course fuses by default rather than routing.

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