RAG over a code repo can't find the exact function name a developer searches for: best fix?

MCQ·Medium·4.0 · 0·~1 min·Asked atCopy Ai Midjourney Reliance Jio

Attempt it

The right fix is to add a **lexical/sparse retriever** like BM25 for exact symbols and fuse it with the dense retriever as hybrid search. Here is the core problem. Dense embeddings are built to capture meaning. They take a chunk of text and place it in a space where similar meanings sit close together. That is great for questions like "how do we validate a login token?" But a function name like `parseUserToken` does not have much meaning to capture — it matters as an exact sequence of characters. The embedding smooths it into a fuzzy neighborhood of vaguely similar names, and the exact symbol the developer typed gets buried. A sparse retriever matches literal tokens directly. If the developer searches `parseUserToken`, BM25 finds the chunks that contain that exact string. That is exactly what code symbol search needs. You do not want to drop semantic search, because developers also ask intent-style questions. So you run both retrievers and combine their results — hybrid search. The wrong fixes all try to make dense retrieval do something it cannot: a bigger model still blurs exact tokens, and raising top-k or lowering the threshold just adds noise.

Add a **lexical/sparse retriever** (BM25, or a learned-sparse model like SPLADE) for exact-token matching and fuse it with dense retrieval — hybrid search. The failure is a mismatch between what dense embeddings represent and what the query needs. Dense retrieval ranks chunks by semantic similarity, which is ideal for intent queries but actively wrong for exact identifiers. A symbol like `parseUserToken` or an error code like `ERR_0x80` carries almost no distributional meaning; its value is the literal character sequence. The embedding maps it into a neighborhood of superficially similar names, and the exact match does not reliably rank at the top. A sparse retriever matches the exact token. BM25 scores chunks by term overlap with the query, so the chunk literally containing `parseUserToken` scores highly. This is precisely the behavior code symbol search needs. The reason to fuse rather than replace is that developers issue both query types. They run exact-symbol lookups, and they also ask meaning-based questions such as where a session gets refreshed. Hybrid search runs both retrievers and merges their result lists, commonly with reciprocal rank fusion. That way exact-token hits and semantic hits both surface. The distractors all misdiagnose the problem. A larger or higher-dimension embedding model still smooths exact tokens — capacity is not the issue, representation is. Raising top-k from 5 to 50 or lowering the similarity threshold floods the prompt with near-misses without ever making the exact symbol rank well.

TL;DR

Exact identifiers like parseUserToken carry little semantic signal, so dense embeddings blur them. Add a sparse/BM25 retriever for literal-token matching and fuse it with dense retrieval as hybrid search.

Memory aid

Easy to grasp

Imagine looking someone up in a phone book versus describing them to a friend. If you know the exact spelling of their name, the phone book finds them instantly — letter for letter. But if you only remember "the tall doctor on Oak Street," describing them works better. Searching code is the same. A function name like parseUserToken is an exact spelling: you want the phone-book lookup. A question like "how do we check logins?" is a description: you want the friend who understands meaning. The fix is to keep both helpers and combine what each one finds, instead of forcing one to do the other's job.

Key concepts

RAG Embeddings

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Code search is where pure dense retrieval most visibly breaks, and it is a favorite interview scenario because the wrong fixes are so tempting. A developer types an exact function name, the RAG system returns vaguely related code, and the instinct is to reach for a bigger embedding model or a wider result set. Both instincts are wrong, and understanding why is the difference between a candidate who has tuned a RAG demo and one who understands what embeddings actually represent.

This deep dive unpacks why an exact identifier is hostile to dense retrieval, why a sparse retriever is the natural complement, how fusion combines the two without comparing incomparable scores, and the code-specific details — tokenization, chunking, symbol tables — that separate a working code-search system from a brittle one.

Why an identifier is hostile to dense retrieval

A dense embedding model is trained to map text into a space where semantic similarity equals geometric closeness. Paraphrases land near each other; "validate the login" sits close to "check the credentials." That training objective is the whole value of dense retrieval, and it is precisely what makes it bad at exact identifiers.

Consider parseUserToken. As a piece of meaning, it is thin — it is a name a programmer coined, often rare or unique in the corpus, and possibly never seen during the embedding model's pretraining. The model has little distributional signal to encode, so it falls back on surface cues: it is camel-case, it contains "parse," "user," "token." The resulting vector lands in a fuzzy neighborhood of other camel-case names that share those sub-words. The exact symbol the developer wants is not guaranteed to rank first; a parseUserSession or validateUserToken can easily outrank it.

The key realization is that this is a representation problem, not a capacity problem. A larger embedding model with more dimensions is even better at semantics — which means it is, if anything, even more committed to collapsing surface form into meaning. You cannot scale your way out of a mismatch between what the representation encodes and what the query needs. The query needs the literal string; the representation threw the literal string away.

Why sparse retrieval is the natural complement

Fusing two retrievers without comparing incomparable scores

The code-specific details that make or break it

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

def reciprocal_rank_fusion(dense_hits, sparse_hits, k=60, top_n=5):
    # dense_hits, sparse_hits: ordered lists of chunk ids (best first)
    scores = {}
    for ranked in (dense_hits, sparse_hits):
        for rank, chunk_id in enumerate(ranked, start=1):
            # combine ranks, not raw scores — the two scales are incomparable
            scores[chunk_id] = scores.get(chunk_id, 0.0) + 1.0 / (k + rank)
    fused = sorted(scores, key=scores.get, reverse=True)
    return fused[:top_n]

# dense recovers intent queries; sparse (BM25/SPLADE) recovers exact symbols
results = reciprocal_rank_fusion(dense.search(q), bm25.search(q))

Real products, models, and research that use this idea.

GitHub and Sourcegraph code search lean on exact-symbol and lexical matching, layering semantic search on top rather than relying on embeddings alone.
Qdrant and Weaviate ship native hybrid search that fuses a sparse BM25 vector with the dense vector per query.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you actually fuse the dense and sparse result lists, given their scores are not on the same scale?

Reciprocal rank fusion is the common answer because it combines ranks, not raw scores, sidestepping the incomparable-scale problem. Each retriever contributes 1/(k + rank) per document and you sum. Alternatives are score normalization (min-max or z-score per channel) then weighted sum, but RRF is more robust when score distributions differ a lot.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Reaching for a bigger embedding model to fix exact-symbol search — a larger model still smooths literal tokens into a fuzzy neighborhood, so the exact identifier stays lost.

60 second bullets to scan on the way to the call.

Explain why dense embeddings struggle with exact identifiers
State what a sparse/BM25 retriever matches and why that suits symbol search

Primary sources. Browse if you want the original framing.