# Term-based and embedding retrieval interview questions > 6 term-based and embedding retrieval interview questions for AI and ML engineer roles, each with a model answer. Canonical: https://llmdojo.dev/interview/topic/retrieval-algorithms Last updated: 2026-10-23 6 questions: 1 junior, 3 mid-level and 2 senior. Taught in [Term-Based and Embedding Retrieval](https://llmdojo.dev/learn/retrieval-knowledge-systems/term-and-embedding-retrieval). ## [What do TF and IDF measure?](https://llmdojo.dev/interview/q/what-do-tf-and-idf-measure) Level: Junior **Term frequency**: how often a term appears in a document. **Inverse document frequency**: how rare it is across the collection, the total count divided by the documents containing it, usually logged. TF-IDF sums IDF × TF over the query's terms, so **rare** query words count most. ## [What does BM25 add to TF-IDF?](https://llmdojo.dev/interview/q/what-does-bm25-add-to-tf-idf) Level: Mid-level Two corrections to term frequency: - **Saturation**: the tenth mention adds less than the first (parameter k1). - **Length normalisation**: long documents contain terms by chance, so their counts are discounted (parameter b; 0 turns it off). It's still a strong baseline. On the course's help-centre data, length alone decides which of two equally matching toy articles wins. ## [Why is term-based search fast, and what does it never return?](https://llmdojo.dev/interview/q/why-is-term-based-search-fast-and-what-does-it-never-return) Level: Mid-level An **inverted index** maps each term to the documents containing it, with counts, so only documents on the query terms' lists are scored. **Diagram: An inverted index** 1. The query, after lowercasing and dropping stop words, is three terms that appear in the collection. 2. An inverted index maps each term to the documents that contain it, with how often: like the index at the back of a book. 3. Look up each query term. The number of documents in each list is the term's document frequency, which IDF needs. 4. Only documents on some list are scored. That's why term-based search is fast, and why a document sharing no term is never returned. Terms and articles from the search-lab help centre (lib/labs/data/search-lab.json). The flip side: a document sharing **no term** with the query is never a candidate, however well it answers. Paraphrase is term search's blind spot. ## [How does embedding retrieval work, and what's its catch?](https://llmdojo.dev/interview/q/how-does-embedding-retrieval-work-and-what-s-its-catch) Level: Mid-level Embed every chunk once; at query time embed the query **with the same model** and return the k nearest vectors. The catch: there's **always** a nearest neighbour, so it returns k results even when nothing is relevant. A similarity threshold helps, but it's model-specific. It can also struggle outside the domain its model was trained on. ## [Exact k-NN is too slow at your scale. What do you give up with an ANN index, and how do you choose one?](https://llmdojo.dev/interview/q/exact-k-nn-is-too-slow-at-your-scale-what-do-you) Level: Senior **Recall**: approximate search looks at only some vectors, so a true neighbour can be missed. **Diagram: Approximate search with clusters (IVF)** 1. Approximate nearest-neighbour (ANN) indexes organise vectors so a query only looks at some of them. IVF uses clusters. 2. Each vector is filed under its nearest cluster centre. AI Engineering notes clusters are typically sized to hold 100 to 10,000 vectors on average. 3. A query compares itself with the centroids, then only with the vectors in the closest clusters. 4. That's the trade every ANN index makes, whether clusters (IVF), graphs (HNSW), hashing (LSH), trees (Annoy) or compressed vectors (product quantization): speed for some recall. Indexes differ in how they trade: IVF searches the nearest clusters; HNSW walks a graph, accurate and fast to query but slow and memory-hungry to build; LSH hashes, cheap to build but less accurate. Compare on **recall, queries per second, build time and index size**, and weigh build time heavily if the data changes often. ## [Term-based or embedding retrieval for a support search full of error codes and paraphrased questions?](https://llmdojo.dev/interview/q/term-based-or-embedding-retrieval-for-a-support-search-full-of-error) Level: Senior Both. Term search is faster, cheaper and strong out of the box, and exact codes like EADDRNOTAVAIL are where it's most reliable; embeddings can blur them. Embeddings handle paraphrase and can be improved by fine-tuning, but cost more to compute, store and search. Also check term tokenization: splitting can create false matches (“two-year-old” matching “two-factor”) or destroy identifiers. Then measure both on real queries. ## Related - [All interview questions](https://llmdojo.dev/interview)