Data preparation: free practice questions

Delta Sync indexes rely on the Delta table's Change Data Feed (CDF) to identify which rows have been inserted, updated, or deleted since the last sync. If CDF was not enabled before the updates were written, those change records are not logged in the Delta log, and the Vector Search sync process has no way to detect which rows changed. As a result, the index is not updated. Option A is incorrect—partitioning has no effect on CDF or Vector Search sync behavior. Option C is incorrect—Delta Sync is the correct index type for incremental updates; snapshot indexes are less efficient for update-heavy workloads, not more. Option D is incorrect—while Unity Catalog is recommended, it is not a hard requirement for CDF to function; CDF is a Delta table feature that works in both Unity Catalog and hive_metastore contexts.

A Delta Sync index with triggered sync scheduled nightly aligns precisely with the nightly batch update pattern—it will automatically re-sync after each nightly Delta table load without requiring manual intervention, while also being efficient for a batch workload that doesn't need real-time streaming updates. A snapshot index that is manually triggered (option A) requires human intervention and doesn't satisfy the 'no manual intervention' requirement. A snapshot index on a fixed 24-hour schedule (option B) may miss the timing of the nightly load and is less flexible. A Delta Sync index with continuous sync (option C) would also work but is unnecessary and more expensive for a nightly batch pattern—triggered sync is the better fit.

High recall@10 means the relevant document is present somewhere in the top 10 results. Low precision@3 means the top 3 results contain a high proportion of irrelevant chunks—the relevant content is not bubbling up to the very top. A re-ranker (cross-encoder) model takes the initial retrieval candidates and re-scores them for relevance to the query, improving precision at small k values. Option A is incorrect because recall is already high—more chunks in the index would likely worsen precision further. Option B misdiagnoses the problem and proposes an inappropriate fix; generative models are not retrieval mechanisms. Option D is false—precision and recall are standard, compatible retrieval metrics routinely measured together.

Semantic chunking detects topic shifts by embedding sentences or short passages and measuring cosine distance between adjacent embedding windows. This means the embedding model must be called at chunking time—before the final index is built—adding significant computational overhead and latency to the data preparation pipeline. Option A is incorrect—semantic chunking generally produces more coherent chunks and can improve retrieval recall; fixed-size chunking does not universally outperform it on recall. Option C is incorrect—semantic chunking works on any extracted text string regardless of its origin (PDF, HTML, plain text, etc.). Option D is incorrect—semantic chunking is specifically designed to preserve topical coherence by grouping semantically related content together; fixed-size chunking ignores semantic boundaries.

Removing boilerplate (navigation, footers, cookie banners, repeated headers) is the most critical cleaning step because these non-content elements add noise to embeddings, causing the vector index to return irrelevant results when similar boilerplate matches a query rather than actual article content. Lowercasing (option A) is a minor normalization that has little effect on modern transformer-based embedding models and does not address the core noise problem. Tokenizing with the embedding model's tokenizer (option C) is a technical step done internally by the embedding model, not a content-cleaning step. Immediately chunking after tag removal (option D) skips the necessary content filtering and perpetuates the boilerplate problem.