Embeddings and vector search quiz

19 questions across 2 lessons. Choose an answer, check it, and read why each option is right or wrong.

Back to the module Flashcards

Checking answers needs JavaScript. You can still read every question and option below.

0 of 19 answered

Keyboard: arrow keys move between options. Space or Enter selects the focused option.

Embeddings and similarity search8 questions

ObjectiveExplain how a dedicated embedding model turns a chunk or a query into one vector, and why nearby vectors mean similar meaning.

Question 1 of 19A search box gets the query "how do I cancel my subscription". The right page is titled "Ending your plan". Why can embedding search find it when keyword search does not?
Choose one answer.
- The model rewrites the query with synonyms such as "end" and "plan" and then runs a keyword match.
- The two phrases are encoded as nearby vectors, since people use them in the same situations.
- The search measures how many characters the query and the title share, after lower-casing both.
Question 2 of 19You index 1,000 chunks with a dedicated embedding model for search. What does the index store for each chunk?
Choose one answer.
- One fixed-length vector for the whole chunk, produced by the model reading all of it.
- One vector per token, kept in order so a query can be aligned with the chunk word by word.
- A short list of keyword vectors, one for each distinct noun in the chunk.

ObjectiveCompare cosine similarity, dot product and Euclidean distance, and show why cosine equals the dot product on unit-length vectors.

Question 3 of 19You normalize all embeddings to length 1 and switch your index from cosine to plain dot product. What happens to the ranking of results?
Choose one answer.
- It changes a lot, because dot product rewards long vectors while cosine ignores length.
- It becomes random, since a raw dot product is just a number and not a real similarity measure.
- It stays the same, because cosine's denominator is 1, so the score reduces to the plain a·b.
Question 4 of 19Your embeddings are not normalized and their lengths vary a lot. You rank by raw dot product. What is the likely side effect?
Choose one answer.
- Vectors with larger magnitude can outrank vectors that point in a closer direction to the query.
- Nothing changes, since dot product and cosine give the same ranking for any set of vectors.
- Euclidean distance becomes the only valid metric, because dot product needs unit vectors to run at all.

ObjectiveDiagnose why embedding search misses exact identifiers, rare terms or domain-specific text, or returns related but unhelpful results, and name the fix.

Question 5 of 19Users search "ERR-40412" in your docs. Vector search returns general pages about errors, and the page for that exact code is missing. What is the best first fix?
Choose one answer.
- Lower the similarity cutoff so more pages pass, because the right page must be sitting just below it.
- Use an embedding model with more dimensions, because a bigger vector can memorize the code.
- Run keyword (BM25) search alongside vector search and merge both result lists, so exact strings can win.
Question 6 of 19After a model upgrade, you embed new documents with the new model but keep the old document vectors. Search quality collapses, and no error is raised. Why?
Choose one answer.
- Scores now compare vectors from two different spaces, so they carry no consistent meaning.
- The index silently deletes vectors whose values fall outside the range of the new model.
- Newer models always produce shorter vectors, which can then never be compared with the older ones.
Question 7 of 19Your semantic search returns pages on exactly the right topic, but users say none of them answers the question. Which change targets that problem most directly?
Choose one answer.
- Switch the metric from cosine to Euclidean distance, since Euclidean separates near topics much better.
- Fetch a wider candidate set, then reorder it with a model that scores each passage against the query.
- Re-embed the corpus with a shorter dimension setting, so that only the strongest meaning remains.
Question 8 of 19A support search built on embeddings finds the right help page for "how do I end my plan" but returns nothing useful for the order number "TK-48213". What best explains the difference?
Choose one answer.
- Order numbers are too short for an embedding model to accept, so the query is dropped before any vector is made.
- The vector index only stores words from a dictionary, and an order number is missing from the dictionary the index was built with.
- Cosine similarity cannot compare queries of different lengths, and an order number is shorter than the phrases it searches against.
- Embeddings capture meaning, not exact strings, so an identifier lands near many similar codes and needs an exact-match step too.

Vector databases11 questions

ObjectiveExplain why exact nearest-neighbor search does not scale and what an approximate (ANN) index gives up in return.

Question 9 of 19A prototype does exact search over 20,000 vectors and answers in a few milliseconds. The corpus will grow to 200 million. What is the main reason to plan an ANN index?
Choose one answer.
- Exact search becomes less accurate as the corpus grows, because distances get noisier, so a newer index is needed.
- Each query is compared with every stored vector, so latency climbs with corpus size until it breaks the budget.
- Databases cannot hold more than a few million vectors unless an ANN index is there to store them.
Question 10 of 19An ANN index returns 9 of the 10 true nearest neighbors for a query. What is the recall@10, and what does it tell you?
Choose one answer.
- 0.9. One true neighbor was missed, which is what the index gave up in exchange for speed.
- 0.1. Only one result differs from the exact answer, so the index is wrong for most neighbors.
- 0.9. It tells you how useful those nine results are to the person who typed the query.
Question 19 of 19A team's brute-force vector search is too slow at 10 million vectors, so they move to an approximate nearest-neighbour index and queries get much faster. What have they most likely given up?
Choose one answer.
- Ranking quality across the board, because the index scores every result with a rougher formula than cosine or dot product.
- Some recall, since the index may skip a true nearest neighbour by examining only a small part of the stored vectors.
- Freshness, because any ANN index must be rebuilt from scratch after each new vector is added or an old one removed.
- Extra memory for the index structure, with the top results staying identical to the exact answer from brute-force search.

ObjectiveCompare HNSW and IVF on how they search, their memory cost, and whether they need training.

Question 11 of 19Memory is tight and the corpus is mostly static, so you pick IVF over HNSW. When should you create the index?
Choose one answer.
- At deploy time on an empty table, because the clusters adapt as rows arrive over the next weeks.
- After the table holds data that looks like production, so training can place the cluster centers well.
- Either way, because IVF needs no training and only HNSW depends on the data already present.
Question 12 of 19Two engineers describe how an HNSW query avoids visiting every vector. Which description is accurate?
Choose one answer.
- It sorts all the vectors along a single axis and then runs a binary search for the value of the query.
- It compares the query with the cluster centers and scans only the few closest clusters it finds.
- Long hops across a thin top layer reach the query's area fast, then finer hops below finish the job.

ObjectiveName the main recall-versus-latency knobs for HNSW and IVF, and say how to measure recall against brute-force search on a sample.

Question 13 of 19Latency is fine but recall@10 is 0.82 against brute force on your sample queries. Which change is the most direct way to raise recall on an IVF index?
Choose one answer.
- Raise nprobe so each query scans more clusters, then re-measure recall and latency.
- Raise nlist and rebuild, because smaller clusters make each query more precise.
- Switch the distance metric to Euclidean, because it fixes ranking errors in clustered data.
Question 14 of 19How should you measure the recall of your ANN index before launch?
Choose one answer.
- Run production queries and check that the top result looks right to a reviewer.
- Use the vendor's published recall number, since index settings do not depend on your own data.
- Compare ANN top-k with brute-force top-k on real sample queries, changing one knob at a time.

ObjectiveChoose between a Postgres extension, a vector library and a dedicated vector database for a given scale and team.

Question 15 of 19A team with 80,000 documents already runs Postgres for its product. A colleague wants to add a dedicated vector database "to be safe". What is the best advice?
Choose one answer.
- Add it now, because Postgres cannot index vectors and would have to be replaced for this feature.
- Embed FAISS in the web server, since a library also takes care of persistence and updates.
- Try pgvector first and add another system only once measured latency or memory forces the move.
Question 16 of 19Your security team asks whether you must use a managed cloud service to run Qdrant or Weaviate inside your own network. What is the accurate answer?
Choose one answer.
- No. Both are open source and can be self-hosted, and each also offers a managed cloud.
- Yes. Both are sold only as managed services, so your data has to leave your own network.
- Only Weaviate can be self-hosted, while Qdrant is available as a cloud service alone.

ObjectiveExplain why metadata filters and document updates need explicit design in a vector store.

Question 17 of 19You ask for the 10 nearest chunks where department = legal. The corpus holds thousands of legal chunks, but only 3 come back. What is the most likely cause?
Choose one answer.
- The department field has too many distinct values for the index to handle at this corpus size.
- The filter was applied to a short candidate list from the approximate search and dropped most of it.
- Only 3 chunks are close enough to the query, so the index has returned everything it could possibly find.
Question 18 of 19A policy page was edited yesterday. Search still returns the old wording next to the new one. Which design most likely prevents this?
Choose one answer.
- Index each edited version under a fresh random ID, and let the latest timestamp win at query time.
- Derive each chunk ID from the document and position, so re-ingesting overwrites it, and delete leftovers.
- Increase the candidate list size, so that the newest vector gets a much better chance of ranking first.