yoklainterview sim
ProgressHistory

AI Engineer Rag Retrieval Search Interview Questions

75 verified AI Engineer Rag Retrieval Search interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Rag Retrieval SearchDifficulty 1
In retrieval for RAG, what is the core difference between dense (embedding-based) retrieval and sparse (keyword/BM25) retrieval?
  • aDense only works on short docs; sparse only works on long docs.
  • bDense matches by meaning; sparse matches by exact term overlap.✓
  • cDense needs no index; sparse always needs a graph index.
  • dDense sorts results alphabetically; sparse sorts by file size.
Explanation:Dense retrieval compares query and document embeddings in a semantic vector space, so paraphrases and synonyms can match even without shared words. Sparse retrieval (e.g. BM25) scores documents by exact token overlap, weighted by term rarity and frequency, so it needs the literal term to appear. (a), (c), and (d) describe distinctions that have nothing to do with how these two methods actually compute relevance.
Rag Retrieval SearchDifficulty 1
At a high level, what does the BM25 scoring function weigh when ranking a document for a query?
  • aTerm frequency, term rarity (IDF), and document length.✓
  • bHow recently the document was indexed and its inbound link count.
  • cThe cosine angle between two learned dense vectors.
  • dTotal unique word count in the document, ignoring the query.
Explanation:BM25 combines term frequency (how often a query term appears in a document), inverse document frequency (rarer terms across the corpus get more weight), and document length normalization (so long documents don't win purely by repeating terms more). (b) describes recency/link-based ranking signals, unrelated to BM25. (c) describes dense vector similarity, not sparse scoring. (d) ignores the query entirely, which BM25 does not do.
Rag Retrieval SearchDifficulty 2
A 4-document corpus (tokenized by whitespace) is indexed with BM25Okapi, and the query "what does error x401 mean" is scored against each:
doc0: "restart the service after updating the configuration file"
doc1: "error code x401 means the authentication token has expired"
doc2: "authentication tokens can expire and usually require a refresh"
doc3: "server logs show timeout errors during periods of high load"

Running bm25.get_scores(query) gives real scores of [0.0, 1.6946, 0.0, 0.0]. Why does doc1 score so much higher than the rest?
  • aBM25 always favors whichever document was indexed first.
  • bdoc1 is the shortest document, and BM25 favors short documents.
  • cdoc1 uniquely contains the rare query token "x401".✓
  • dThe other documents were rejected by the tokenizer for stopwords.
Explanation:"x401" appears in the query and is unique to doc1 in this corpus, giving it a high inverse-document-frequency weight; doc2 is semantically about the same topic (authentication token expiry) but shares no exact query tokens with high IDF, so it scores 0. (a) is false — BM25 has no notion of insertion order. (b) is a real but secondary factor (BM25 does have length normalization), but here the deciding factor is the exact rare-term match, not length alone. (d) misdescribes tokenization — stopwords lower scores, they don't zero out documents entirely.
Rag Retrieval SearchDifficulty 2
Two candidate documents are represented as 4-dim toy embeddings along semantic axes [auth, error, server, refresh]:
query = [0.90, 0.10, 0.00, 0.60]
doc1  = [0.85, 0.90, 0.00, 0.10]   # mentions the exact error code, weak refresh signal
doc2  = [0.95, 0.05, 0.00, 0.90]   # paraphrase, no code, strong auth+refresh signal

Computing real cosine similarity gives cos(query, doc1) ≈ 0.6782 and cos(query, doc2) ≈ 0.9841. What does this tell you about dense retrieval here?
  • aCosine similarity cannot exceed 0.9 for normalized vectors.
  • bdoc1 must contain a typo, since it scores lower here.
  • cNeither document is relevant, since neither score is near 1.
  • ddoc2's semantic profile aligns more closely with the query.✓
Explanation:Cosine similarity measures the angle between vectors regardless of exact tokens present; here doc2's profile (strong auth + refresh, matching the query's dominant signals) aligns more closely with the query than doc1's profile, even though doc1 is the one containing the literal error code. This illustrates that dense retrieval ranks by overall semantic alignment, not by presence of a specific rare term. (a) is a false constraint — cosine similarity naturally ranges up to 1.0. (b) and (c) misread what the numbers indicate.
Rag Retrieval SearchDifficulty 3
For the same query, BM25 (question 3) ranks doc1 (contains "x401") first with score 1.6946 while doc2 scores 0.0. Running dense cosine similarity (question 4) on a semantically comparable pair ranks the paraphrase document (0.9841) above the exact-code document (0.6782). What does this divergence demonstrate about combining the two methods?
  • aOne of the two scoring implementations must contain a bug.
  • bDifferent signals cause disagreement; that's why hybrid combines both.✓
  • cBM25 should be dropped entirely in favor of dense retrieval.
  • dBM25 scores and cosine similarities are directly comparable.
Explanation:Both scoring runs are correct on their own terms — they simply measure different kinds of relevance. BM25 rewards exact rare-term overlap, dense embeddings reward overall semantic closeness. Neither is "wrong"; this exact kind of disagreement is the motivation for hybrid retrieval, which merges both rankings so that a document strong in either signal can surface. (a) wrongly assumes disagreement implies a bug. (c) draws an unsupported conclusion from a single example. (d) is a critical error — BM25 and cosine similarity live on different, non-comparable scales, which is precisely why fusion methods use rank position rather than raw scores.
Rag Retrieval SearchDifficulty 2
A retrieval run returns this ranked list of document IDs: ["d7", "d3", "d1", "d9", "d2"]. The only relevant document for the query is "d1", sitting at rank 3. Computing recall@k for real gives recall@1 = 0.0, recall@2 = 0.0, recall@3 = 1.0. What does this concretely show about the effect of top-k on recall?
  • arecall@k is undefined whenever the relevant doc isn't ranked first.
  • bRecall dropped as k increased, meaning more results made it worse.
  • cRecall stays 0 until k reaches the relevant doc's rank, then jumps to 1.✓
  • dThis recall@k is actually measuring precision, not recall.
Explanation:recall@k asks whether the relevant document(s) are contained anywhere within the top-k results; since d1 is at rank 3, top-1 and top-2 both miss it (recall 0), and top-3 (and beyond) include it (recall 1). Because raising k only adds more candidates without removing any, recall@k is monotonically non-decreasing in k. (a) is false — recall@k is well-defined even at 0. (b) misreads the numbers, which increase, not decrease. (d) confuses recall with precision; precision would also account for how many irrelevant documents are mixed in, which this example does not test.

By specialization

LLM/RAG 450MLOps 450Python 450

By seniority

AI Engineer JuniorAI Engineer MidAI Engineer Senior

Other fields

BackendFrontendFullstackDevOps / CloudDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2025-question AI Engineer bank.

Start interview