41. Stuffing 100 chunks into the prompt
To "improve recall", a team puts 100 retrieved chunks into a long-context prompt. Answer quality drops compared to using the top 8. What is the most likely reason?
- A.Relevant facts get buried among many distractors; models often use information in the middle of long contexts less reliably
- B.Long context models cannot read more than 8 chunks
- C.The vector database returns random results after 8
- D.Temperature automatically increases with prompt length
Show answer
Answer: A. Relevant facts get buried among many distractors; models often use information in the middle of long contexts less reliably
More context is not always better. Irrelevant chunks add noise, raise cost and latency, and models can pay less attention to information buried in the middle of a long prompt. Better retrieval, reranking and putting the most relevant content in prominent positions usually work better.
42. Budgeting the context window
Your model has a 128,000-token context window. The system prompt uses 2,000 tokens, tool definitions 6,000, chat history 30,000, and you reserve 4,000 for the answer. How many 800-token retrieved chunks fit at most?
- A.107
- B.112
- C.160
- D.102
Show answer
Answer: A. 107
Free space = 128,000 − 2,000 − 6,000 − 30,000 − 4,000 = 86,000 tokens. 86,000 / 800 = 107.5, so 107 whole chunks fit. Forgetting the output reserve gives 112, which would leave too little room for the answer. In practice you would use far fewer chunks for quality reasons.
43. IVF index after a new language
An IVF index was trained on English documents. You then add 3 lakh Arabic documents. Latency spikes for Arabic queries and recall drops. What is likely happening?
- A.IVF indexes can only store one language at a time
- B.Arabic vectors are larger, so the index runs out of disk
- C.The new vectors crowd into a few old clusters; retrain the centroids
- D.The Arabic documents are being ignored by the index
Show answer
Answer: C. The new vectors crowd into a few old clusters; retrain the centroids
IVF centroids come from k-means on the data present at training time. If new data lies in a different region, it piles into a few lists, making them huge and slow, while the clustering no longer separates it well. Re-train the IVF on a representative sample and rebuild.
44. Inner product with unnormalised vectors
Your index uses inner product (dot product), and the embeddings are not normalised. A few long chunks show up for almost every query. Why?
- A.Long chunks are always more relevant than short ones
- B.Vectors with large norms get high dot products with many queries
- C.Inner product ignores vector length completely
- D.The index sorts results by chunk length
Show answer
Answer: B. Vectors with large norms get high dot products with many queries
Dot product = ‖a‖ × ‖b‖ × cos. If some vectors have larger norms, they score high regardless of direction. Normalise vectors to unit length (making dot product equal cosine) unless the model's docs say the norm carries useful meaning.
45. One vector for a 40-page PDF
To save cost, a team embeds each 40-page PDF as a single vector (using a long-context embedding model). Specific questions now retrieve poorly. Why?
- A.Long-context embedding models always return random vectors
- B.The vector database cannot store vectors for long files
- C.One vector blends many topics, so no single detail stands out
- D.Specific questions need keyword search and never work with vectors
Show answer
Answer: C. One vector blends many topics, so no single detail stands out
An embedding is a summary; for a long document it reflects the overall theme and dilutes any one clause. A question about a single penalty rule then matches poorly. Chunk the document, or keep a document-level vector for routing plus chunk vectors for detail.
46. Answer split across two chunks
A rule reads "Claims must be filed within 30 days" at the end of chunk 41, and "unless the employee was abroad, in which case 60 days" starts chunk 42. Only chunk 41 is retrieved, so the answer is incomplete. What helps without re-chunking?
- A.Raise the LLM temperature so it guesses the exceptions
- B.Lower top_k so that only the strongest chunk is used
- C.Also fetch the neighbouring chunks (n − 1 and n + 1) of each hit
- D.Delete chunk 42 because it starts mid-sentence
Show answer
Answer: C. Also fetch the neighbouring chunks (n − 1 and n + 1) of each hit
Storing each chunk's position lets you expand a hit with the chunks next to it, a pattern also called sentence-window or context expansion. Exceptions and conditions often sit just past a boundary. Watch the extra tokens, and prefer structure-aware boundaries in future ingestion.
47. Questions about the whole corpus
Leadership asks the RAG bot, "What are the main complaint themes across all 40,000 support tickets this year?" Answers are shallow and miss big themes. Why, and what fits better?
- A.Top-k sees few tickets; use map-reduce or GraphRAG summaries
- B.The embedding model is too small; switch to a larger dimension
- C.The bot needs a higher temperature to think more broadly
- D.Tickets must be retrieved in date order to see themes
Show answer
Answer: A. Top-k sees few tickets; use map-reduce or GraphRAG summaries
Standard RAG retrieves a handful of chunks similar to the question, but a "global" question needs evidence from the whole corpus. Approaches like map-reduce summarisation, clustering, or GraphRAG (entity graphs with pre-computed community summaries) aggregate across everything. For counts, structured analytics may be better still.
48. Garbled chunks from two-column PDFs
Chunks from research reports read like "The tariff on imports rose 4% Section 3 covers the Dubai free-zone rules sharply in Q2". What is the cause and fix?
- A.The embedding model mixes sentences; switch embedding models
- B.The extractor reads across both columns; use a layout-aware parser
- C.Overlap is too large; set chunk overlap to zero
- D.The reports are in two languages; translate them first
Show answer
Answer: B. The extractor reads across both columns; use a layout-aware parser
Basic PDF extraction can read lines left to right across the page, merging two columns into nonsense. Layout-aware tools detect columns, headers and footers and read in the correct order. Spot-check parsed text from each document type; bad parsing silently ruins retrieval.
49. Re-runs create duplicate chunks
Each time the ingestion job is re-run after a failure, the index gains another copy of many chunks. Chunk IDs are random UUIDs. What is the fix?
- A.Run the ingestion job only once a year to avoid duplicates
- B.Use deterministic IDs (document ID plus index) and upsert
- C.Delete the entire index and rebuild it before every run
- D.Ask the LLM to ignore repeated chunks in the context
Show answer
Answer: B. Use deterministic IDs (document ID plus index) and upsert
With random IDs, the store cannot tell that a chunk already exists, so every retry inserts it again. A deterministic ID derived from the source and position (or content hash) turns inserts into idempotent upserts. Re-runs then overwrite instead of duplicating.
50. RAG gets totals wrong
Finance users ask, "What was total GST paid across all branches in Q3?" The RAG bot retrieves 5 invoice chunks and gives a wrong total. What is the right design?
- A.Route them to a SQL tool over the structured data
- B.Retrieve 500 invoice chunks so the model can add them up
- C.Ask the model to estimate based on the 5 invoices it sees
- D.Embed the invoices with a larger model so totals are captured
Show answer
Answer: A. Route them to a SQL tool over the structured data
Aggregations need every relevant record and exact arithmetic, but top-k retrieval returns a small sample and LLMs add numbers unreliably. Detect analytic questions and send them to a text-to-SQL or analytics tool over the source tables. Use RAG for policy and explanation questions.
51. Generating questions for each chunk
Instead of rewriting queries at search time, a team uses an LLM at ingestion to write 3 likely questions per chunk and indexes them with the chunk. What is the main trade-off?
- A.No ingestion cost, but every query now needs three LLM calls
- B.Higher ingestion cost and index size, but no extra latency at query time
- C.It lowers recall, since questions never match user questions
- D.It removes the need to store the original chunk text
Show answer
Answer: B. Higher ingestion cost and index size, but no extra latency at query time
This index-time expansion (like doc2query) makes chunks easier to match with question-style queries. The LLM work happens once per chunk, so search stays fast. You pay for generation over the whole corpus and store more vectors or text, and bad generated questions can add noise.
52. Suspiciously high eval scores
After adding few-shot examples to the RAG prompt, your eval score jumped from 71% to 93%. Later you find the examples were copied from the eval set. What is the problem?
- A.Test leakage: the eval now measures memorised examples, not real ability
- B.Few-shot examples always lower accuracy, so the score must be wrong
- C.The eval set is too small to contain any examples
- D.The judge model was updated at the same time
Show answer
Answer: A. Test leakage: the eval now measures memorised examples, not real ability
If test questions or their answers appear in the prompt, the model can copy them, inflating scores without improving real performance. Keep prompt examples, tuning data and eval sets separate, and hold out a set that nobody tunes against.
53. False facts planted in a wiki
Your RAG indexes an internal wiki that any employee can edit. Someone adds a page with a wrong refund rule, and the bot starts quoting it to customers. What reduces this risk?
- A.Index more wiki pages so the wrong one is outnumbered
- B.Rank sources by trust and review edits to open sources
- C.Raise the temperature so the bot varies its answers
- D.Remove citations so customers cannot see the source
Show answer
Answer: B. Rank sources by trust and review edits to open sources
Open-edit sources let anyone insert content the bot will treat as truth. Tag sources by authority, filter or rank approved policy documents above wiki pages for customer answers, and route changes to sensitive topics through review. Monitoring which sources answers cite also catches surprises.
54. Better offline, flat online
A new reranker raised offline nDCG@5 from 0.71 to 0.80, but after an A/B test the online resolution rate did not change. What is the most useful next step?
- A.Conclude that rerankers never help and remove it
- B.Ship it anyway and stop measuring online metrics
- C.Check the eval set matches live traffic and find real failures
- D.Lower the nDCG cut-off from 5 to 1 so the gain looks bigger
Show answer
Answer: C. Check the eval set matches live traffic and find real failures
Offline gains only help if the eval reflects real queries and retrieval was the bottleneck. Compare the eval set with live query types, and sample failed online chats to see whether failures come from missing content, generation or UX. Then target the real bottleneck.
55. Data that must stay in the country
A UAE government client requires that its documents never leave in-country infrastructure. Your pipeline calls a foreign-hosted embedding API at ingestion and at query time. What must change?
- A.Nothing, because embeddings are just numbers
- B.Every model that sees the text must run in-country
- C.Only the vector database needs to be moved into the country
- D.Encrypt the vectors after they come back from the API
Show answer
Answer: B. Every model that sees the text must run in-country
Calling an embedding or LLM API sends the raw document and query text to that provider's servers. For residency requirements, every step that sees the text, including ingestion, query embedding, reranking and generation, must run in approved locations. Check the provider's regions or self-host models.
56. Retrieval got worse as the index grew
An HNSW vector index grew from 1 million to 50 million chunks with the same settings. Answer quality dropped, and recall@10 against exact search fell from 0.97 to 0.85. What should you tune first?
- A.Lower the embedding dimension to 2
- B.Raise the search-time candidate list (ef_search), and if needed rebuild with a higher M, measuring recall and latency
- C.Switch from cosine to random ranking
- D.Shrink the number of chunks returned to 1
Show answer
Answer: B. Raise the search-time candidate list (ef_search), and if needed rebuild with a higher M, measuring recall and latency
Approximate search trades recall for speed, and settings tuned for a small index may miss neighbours in a larger graph. ef_search controls how many candidates are explored per query, so raising it improves recall at some latency cost. Measuring recall against exact search on a sample keeps this tuning honest.
57. New embedding model, old index
You upgrade the query embedding model in a RAG system but keep the existing vector index. Retrieval quality collapses. Why?
- A.Vector indexes expire after an upgrade
- B.Old and new embeddings live in different vector spaces
- C.The new model has too many dimensions to search
- D.Query caching returns the old results
Show answer
Answer: B. Old and new embeddings live in different vector spaces
Vectors from two different embedding models are not comparable even with the same dimension. Documents must be re-embedded with the new model, ideally into a new index, with retrieval evals before switching traffic.
58. Real sources, wrong claims
Your RAG answers always cite real chunk IDs, but reviewers find some cited chunks do not actually support the claim. How should you catch this at scale?
- A.Run an automated check, such as a judge or entailment model, that tests whether each cited chunk supports its claim, and track that rate as a metric
- B.Trust the citations, since the IDs are real
- C.Remove citations from the UI
- D.Ask the model to cite more chunks per claim
Show answer
Answer: A. Run an automated check, such as a judge or entailment model, that tests whether each cited chunk supports its claim, and track that rate as a metric
A valid ID only proves the chunk exists, not that it says what the answer claims. Checking claim and source pairs measures faithfulness, often called groundedness. Flag or block unsupported claims and review samples by hand to calibrate the checker.
59. An expert persona that still errs
Adding "You are a world-class UAE tax lawyer" made answers sound more authoritative, but factual errors about VAT rules stayed the same. What is the best explanation and fix?
- A.The persona needs more adjectives, such as "senior" and "award-winning"
- B.Roles only work for programming tasks
- C.The model must be told it is in Abu Dhabi
- D.A role shapes tone, not facts; supply the current VAT rules as context
Show answer
Answer: D. A role shapes tone, not facts; supply the current VAT rules as context
A role prompt can change vocabulary, depth and style, but it cannot add knowledge the model lacks or update rules that changed after training. Grounding the answer in up-to-date regulation text (retrieval) is what fixes factual errors.
60. Six levels of categories on mobile
An industrial parts app has six category levels. On mobile, users get lost tapping through. Which approach helps most?
- A.Show all six levels together on one screen
- B.Remove four of the six levels at random
- C.Use a swipeable carousel at each level
- D.Strong search and filters, plus clear path and back
Show answer
Answer: D. Strong search and filters, plus clear path and back
Deep trees are hard on small screens. Search with filters lets experts jump straight to parts, while drill-down with a visible path and easy back supports browsing. Flattening the tree where possible also helps.