How the Pipeline Works

The problem it solves

BM25 treats "cozy ramen locals love not too loud" as eight separate keywords. It has no concept that "not too loud" is a negative constraint, or that "locals love" is a sentiment signal.

Why this approach

The space of food queries is infinite. "Something warm for a rainy night", "anniversary dinner under $80" — all require genuine language understanding. Rule-based parsing can't handle this diversity.

How it works

1. Raw query is wrapped in a structured prompt with output schema definition
2. Claude Haiku generates JSON with rewritten_query (expanded keywords for BM25), hyde_document (ideal answer for dense retrieval), intent, search target, filters, and negatives
3. The HyDE document is a hypothetical perfect restaurant description — when embedded, it lands near real relevant restaurants in vector space
4. If the API call fails, a fallback passes the raw query through (BM25 still works)

Example input / output

The problem it solves

BM25 only matches exact keywords ("ramen" but not "noodle soup"). Dense-only retrieval catches semantics but can miss specific terms. Neither alone is sufficient.

Why this approach

Each method has different blind spots. BM25 misses "cozy" → "intimate". Dense misses exact dish names. RRF combines them without weight tuning — documents that rank well in multiple methods are almost certainly relevant.

How it works

1. BM25 path: rewritten_query → Elastic multi_match on name, categories, embedding_text, reviews (top 100)
2. Dense path: HyDE document → BGE-M3 embedding → Elastic kNN cosine search on dense_vector field (top 100)
3. Sparse path: rewritten_query → BGE-M3 sparse encoding → Elastic rank_features on sparse_vector (top 100)
4. All three run in parallel (~200ms total)
5. RRF fusion: score = Σ 1/(k + rank_i) — documents appearing in multiple lists get higher scores
6. Output: top-50 candidates ordered by fused score

Example input / output

The problem it solves

Bi-encoder retrieval encodes query and documents separately — they can't attend to word-level interactions. "Spicy Thai" might match a Thai restaurant that reviews describe as "not spicy at all."

Why this approach

Cross-encoders are more accurate than bi-encoders because they see both texts simultaneously. Too slow for initial retrieval (O(n) for all docs) but perfect for reranking a small candidate set.

How it works

1. For each candidate, build a text pair: [query, "Restaurant Name. Categories. Embedding text. Stars: 4.5. Price: $$"]
2. Pass all 50 pairs through bge-reranker-v2-m3 (568M params)
3. The model uses cross-attention: every query word attends to every document word (and vice versa)
4. Output: one float score per pair — higher means more relevant
5. Sort by score, take top 20
6. This is the compute bottleneck: 50 transformer forward passes on CPU (~10-20s cold, ~300ms warm)

Example input / output

The problem it solves

Cross-encoders score each pair independently. They cannot compare candidates against each other or reason about constraints like "not too loud" across the full set.

Why this approach

Only an LLM can reason: "this restaurant's reviews mention quiet atmosphere — better match for the not-loud constraint than that one, which reviews describe as lively." Pairwise models cannot do comparative reasoning.

How it works

1. Format top-20 candidates into a numbered list with name, categories, price, stars, and review excerpt
2. Send to Claude Haiku with a system prompt defining ranking criteria (relevance > atmosphere > dietary > price > sentiment)
3. The LLM returns a JSON with reordered ranking and natural-language reasoning for top 3
4. Attach match_reason to each result — this becomes the "why this result" text shown to users
5. If the LLM returns invalid JSON, fall back to the cross-encoder ordering

Example input / output