Data Preparation: Databricks Generative AI Engineer Associate Practice Questions

Correct answer: B

WHY B is correct: When source documents have a natural semantic unit — in this case, the Q+A pair — the chunking strategy should preserve that unit. A document with explicit Q/A structure provides a strong signal: each QA pair is a self-contained knowledge nugget. When a user asks a question similar to a FAQ question, embedding-based retrieval will score the chunk highest when the chunk contains the FAQ question + answer as a complete unit, because the FAQ question and the user query will be semantically close, and the complete answer is co-located. Splitting per-QA-pair is sometimes called 'structure-aware' or 'document-aware' chunking. WHY NOT A: Recursive character splitting ignores the QA structure and may split a QA pair mid-answer or merge partial answers from two adjacent QA pairs into one chunk. A generic strategy that ignores document structure always underperforms a structure-aware strategy when clear semantic units exist. WHY NOT C: Separating the question from its answer into different chunks breaks the retrieval-answer co-location property. If a user query retrieves the FAQ question chunk (high similarity, since both are questions), the retrieved chunk contains no answer text — the LLM must then try to answer without any retrieved context. If the answer chunk is retrieved (lower similarity, since answer text is often declarative while queries are interrogative), it lacks the question's framing. WHY NOT D: Fixed 128-token chunks cut some QA pairs mid-answer (an 8-sentence answer may exceed 128 tokens), again breaking the semantic unit. Small chunks also create more noise in the index by splitting structural units that should stay together. WHY NOT E: Sentence-level chunking across the entire document obliterates the QA structure. A retrieved single sentence like 'The return window is 30 days' has almost no context about what product, what conditions, or what exceptions apply. The user would receive ambiguous, context-free fragments instead of complete answers.

Correct answer: C

WHY C is correct: This is the fundamental, well-documented limitation of cross-encoders. A cross-encoder scores a (query, document) pair by running a full transformer forward pass on both texts simultaneously. This requires one separate forward pass per candidate document. For a corpus of 1 million chunks: - **ANN (Approximate Nearest Neighbor) bi-encoder search**: ~5–50 milliseconds (pre-computed embeddings + vector index) - **Cross-encoder scoring 1M chunks**: 1M × ~5ms per pair = ~1,400 hours per query This makes cross-encoders completely impractical as a first-stage retriever over large indices. They are practical ONLY as second-stage re-rankers applied to a small set of candidates (20–100) pre-selected by the bi-encoder. This two-stage architecture is the canonical 'retrieve-then-rerank' pipeline, and the sentence_transformers documentation explicitly frames CrossEncoder usage this way. WHY NOT A: Cross-encoder context window limits depend on the underlying model, typically 512 tokens for BERT-based models or 4,096+ tokens for modern transformer architectures. The limit is not universally 128 tokens, and truncation behavior is configurable. The 128-token claim is false. WHY NOT B: Multilingual cross-encoder models exist (e.g., cross-encoder/mmarco-mMiniLMv2-L12-H384-v1 from the sentence_transformers library). The claim that cross-encoders require same-language query and document is false — it depends on the model trained. WHY NOT D: Cross-encoder re-ranking can only re-rank candidates within the set retrieved by the first-stage bi-encoder. If the relevant chunk was not in the top-K bi-encoder results (recall failure), the cross-encoder cannot elevate it because it never sees it. The cross-encoder is bounded by the recall ceiling of the first stage. Additionally, if the cross-encoder model is poorly calibrated or mismatched to the domain, re-ranking can decrease precision. WHY NOT E: Multiple open-source cross-encoder models are available from Hugging Face Model Hub via the sentence_transformers library (e.g., cross-encoder/ms-marco-MiniLM-L-6-v2, cross-encoder/ms-marco-TinyBERT-L-2-v2). These can run entirely on-premises without any cloud API call. The claim that only proprietary cloud APIs exist is false.

Correct answer: E

WHY E is correct: The unstructured library (by Unstructured.io) is specifically designed for this multi-format document extraction use case. Its partition() function automatically detects the file type (PDF, DOCX, HTML, image) and routes to the appropriate internal parser. Critically for scanned PDFs with no text layer, unstructured integrates with Tesseract OCR via the unstructured[local-inference] install and applies OCR automatically when it detects a PDF with no extractable text layer. This means a single consistent API call handles all four source types without branching logic per format — which is the minimal-engineering approach favored in production RAG pipelines on Databricks. WHY NOT A: PyPDF2 (now pypdf) works ONLY for digital PDFs with embedded text layers. It has no HTML parser, no DOCX parser, and no OCR capability. Attempting to extract text from a scanned image PDF with PyPDF2 returns empty strings because there is no text layer — it extracts nothing. The claim of a 'universal document reader interface' is false. WHY NOT B and C: These combinations are technically correct and would work, but they require separate library calls per document type. Options B and C both correctly identify pytesseract + image rendering for scanned PDFs, BeautifulSoup for HTML, and python-docx for DOCX. However, answer E (unstructured) provides a single unified API that handles all four types with type auto-detection, making it the more practical and maintainable choice in production. Both B and C are not wrong per se, but E is more correct as the optimal answer for a production system. WHY NOT D: scrapy is a web crawling framework for extracting content from websites via HTTP requests — it does not parse local PDF or DOCX binary files. textract is a wrapper library that calls external system utilities (pdftotext, antiword, etc.), which must be separately installed at the system level and are not always available in cloud notebook environments. textract also does not support OCR for image-based PDFs without additional configuration.

Correct answer: B

WHY B is correct: Metadata-enriched chunking with semantic boundaries combines two powerful techniques for academic paper retrieval: 1. **Section-aware metadata**: Tagging each chunk with section: 'abstract', paper_id, year, authors enables metadata filtering at retrieval time. For the query 'What does the abstract of the Smith 2023 paper say?', the retriever can filter WHERE section = 'abstract' AND authors CONTAINS 'Smith' AND year = 2023 before performing similarity search — dramatically reducing search space and improving precision. 2. **Semantic boundaries**: Splitting body sections at paragraph boundaries (semantic chunking) rather than arbitrary token positions preserves the coherent argument structure of academic paragraphs, improving embedding quality. 3. **Dual query support**: For broad conceptual queries ('debate between solar forcing and greenhouse gas causation'), full index search (no metadata filter) retrieves the most semantically relevant paragraphs from across all papers. WHY NOT A: Uniform 512-token fixed-size chunks ignore the structural signal that 'abstract' sections provide. A query specifically asking about an abstract will retrieve any chunk, not necessarily the abstract section. Structured documents with distinct section types always benefit from structure-aware chunking. WHY NOT C: Proposition-based chunking decomposes content into atomic factual claims and is an advanced strategy that works well for dense factual retrieval. However, it requires running an LLM over every sentence of every paper (computationally expensive for a large academic corpus), and propositions lose the relational context between claims within a paragraph — relevant for synthesis queries about debates and frameworks. WHY NOT D: Indexing only abstracts discards 90%+ of each paper's informational content. The body sections contain methodology, experimental results, and discussion of debates that are essential for synthesis questions. An abstract-only index cannot answer 'How do recent papers frame the debate between X and Y?' because the framing of the debate is in the discussion sections, not the abstract summaries. WHY NOT E: Random subsampling introduces arbitrary coverage gaps. Some critical sections may be underrepresented or absent from the sample. There is no principled way to ensure that specific sections (abstracts, conclusions) or specific arguments are consistently represented. This is an anti-pattern that trades a solvable structural chunking problem for non-deterministic coverage quality.

Correct answer: B

WHY B is correct: The question specifically asks to evaluate *retrieval* performance using a dataset that includes ground-truth chunk IDs. Recall@K, Precision@K, and Mean Reciprocal Rank (MRR) are purpose-built information retrieval metrics that measure whether the retriever returns the correct chunks: - **Recall@K**: what fraction of the relevant chunks appear in the top K retrieved? (Catches whether the retriever finds all needed information) - **Precision@K**: what fraction of the K retrieved chunks are actually relevant? (Measures retrieval noise) - **MRR**: where does the first relevant chunk appear in the ranked list? (Measures ranking quality) With ground-truth chunk IDs available, these metrics can be computed directly and faithfully. WHY NOT A: BLEU and ROUGE-L measure lexical overlap between output text strings — they are generation quality metrics used to evaluate summarization and translation outputs. They cannot be directly applied to compare chunk IDs or rank positions, and they measure surface text similarity rather than retrieval recall/precision. WHY NOT C: Perplexity measures a language model's uncertainty in predicting a text sequence — it is a training metric for language models, not a retrieval quality metric. Low perplexity means text is predictable/fluent, not that the chunk is relevant to the user's question. A fluent but irrelevant chunk would have low perplexity and incorrectly score as a high-quality retrieval. WHY NOT D: Latency and storage are operational/infrastructure metrics, not retrieval quality metrics. A fast retriever that returns wrong chunks scores perfectly on latency but fails completely on the task. These metrics are important in production profiling but do not measure retrieval effectiveness. WHY NOT E: Answer correctness and faithfulness (LLM-as-judge end-to-end metrics) evaluate the full RAG pipeline including the generation step. While ultimately important, they conflate retrieval quality with generation quality — a poor-quality retriever can sometimes be masked by a powerful enough LLM. To specifically diagnose retrieval problems, isolated retrieval metrics (Recall@K, Precision@K) are needed.

Correct answer: BC

WHY B and C are correct: These two filters directly address the two identified quality degradation sources. (B) Code-only chunk filtering: Dense vector search uses cosine similarity on semantic embeddings. Code blocks produce embeddings heavily influenced by programming language tokens, identifiers, and syntax — not semantic meaning in the domain question space. When users ask 'How do I authenticate to the API?', a code-only chunk embedding for import requests; response = requests.get(url, headers=auth_header) will score lower than a prose explanation chunk but still occupies a top-k slot, displacing better context. Setting a minimum prose token threshold (e.g., >30 words of natural language required per chunk) filters these low-utility code-only chunks. Code can still appear in chunks alongside explanatory text. (C) Link section removal: 'See also' sections with only Markdown hyperlinks have zero retrievable text content — the URL paths and display text ('See UserAuthentication docs') are semantically noisy and not answerable knowledge. They function as navigation aids, not informational content, and should be stripped before chunking. WHY NOT A: Removing all code blocks is an over-aggressive filter. Documentation quality for technical questions often relies on seeing code examples alongside explanations. The problem is code-only chunks with no prose context — not code appearing within chunks that also contain explanation text. WHY NOT D: Stripping Markdown formatting symbols is a common pre-processing step (recommended for cleaner tokenization), but it does not address the two specific problems: code-only chunks still exist as code-only chunks after stripping # symbols, and link sections still exist as a list of URL paths. WHY NOT E: Increasing top-k from 3 to 10 is a mitigation, not a fix. It increases context window usage (potentially hitting the LLM's context limit), adds latency, and introduces more potentially irrelevant content — all making the generation step harder, not easier. The root cause (low-quality index entries) must be addressed at the data preparation stage.

Correct answer: B

WHY B is correct: Parent-child (also called 'small-to-big' or 'hierarchical') chunking is the advanced strategy specifically designed to serve dual granularity requirements. The architecture is: 1. **Indexing**: Chunk the document into small child chunks (128 tokens) AND large parent chunks (full sections, ~1,024 tokens). Index ONLY the small child chunk embeddings in the vector store. 2. **Retrieval**: Execute embedding similarity search on small child chunk embeddings — this gives high retrieval precision because small chunks have tightly-scoped embedding vectors. 3. **Context expansion**: Once the relevant child chunk is identified, retrieve its mapped parent chunk and pass the parent (large) chunk to the LLM. For detail queries: the small child chunk for Section 3.4.2 is retrieved precisely, and the parent section provides the full specification context. For synthesis queries: retrieving child chunks from multiple sections causes each query to return multiple parents, effectively loading multiple full sections into the LLM's context for cross-section synthesis. WHY NOT A: Uniform 4,096-token chunks improve synthesis queries but hurt detail queries. The large chunk's embedding vector averages signals from thousands of tokens, making it less precise for specific detail retrieval. A chunk covering 4,096 tokens of a complex spec will score lower similarity to a specific technical detail query than a 128-token chunk containing that exact detail. WHY NOT C: Sentence Window Retrieval expands context within a local N-sentence neighborhood. This works well for questions requiring a few surrounding sentences. However, for synthesis questions requiring content from two different sections (network layer + application layer), the N-sentence window around a network layer sentence would not capture the application layer section — the sections may be hundreds of tokens apart. WHY NOT D: Embedding the entire 500-page document as one chunk makes retrieval meaningless — all queries return the same single chunk, regardless of relevance. LLM long context windows (128K tokens) typically represent ~100 pages, not 500 pages, and processing a full spec on every query is extremely costly in latency and API tokens. This eliminates the purpose of chunking entirely. WHY NOT E: BM25 keyword retrieval is a complement to dense retrieval (useful in hybrid search), not a universal solution to dual granularity. For synthesis queries about cross-section relationships, keyword retrieval may return sections with overlapping technical terms but miss semantically related sections that use different vocabulary. Dense retrieval's semantic understanding is superior for synthesis-type questions.

Correct answer: B

WHY B is correct: The canonical PySpark pattern for writing Python-generated data to a Unity Catalog Delta table is: Python list → spark.createDataFrame() → Delta write via saveAsTable(). spark.createDataFrame(chunk_list) directly accepts a list of Python dicts (or list of Row objects) and can infer or be given an explicit schema. saveAsTable('catalog.schema.chunks_bronze') registers the table in Unity Catalog under the three-level namespace (catalog.schema.table), making it a managed Delta table with full governance. Providing an explicit StructType schema is best practice to avoid type inference errors — especially for the chunk_index and page_number integer fields that could otherwise be inferred as long or nullable. WHY NOT A: pandas_df.to_csv() writes a CSV _file_ to a filesystem path, not to a Unity Catalog table. You would be writing the path string 'catalog.schema.chunks_bronze' as a local filename, not as a Unity Catalog table reference. CSV files are not Delta tables and are not registered in Unity Catalog's metastore. This approach fails both the Delta format requirement and the Unity Catalog registration requirement. WHY NOT C: spark.createDataFrame() absolutely CAN accept Python lists directly — this is a fundamental PySpark API capability. The DBFS intermediate step is unnecessary and adds I/O overhead. The claim that spark.createDataFrame() requires a serialized file is false. WHY NOT D: Building an INSERT VALUES SQL statement via Python string interpolation is dangerous (SQL injection risk, escaping issues with quotes in text), not scalable (SQL string length limits), and not idiomatic Databricks. The correct way to load a Python list is via spark.createDataFrame(), not string-constructed DML. For 5,000 multi-sentence chunks, the SQL string would be enormous and likely exceed Spark SQL statement size limits. WHY NOT E: Pandas UDFs are transformation functions applied to existing DataFrame columns — they are not a data loading mechanism. There is no standard pattern of 'apply a UDF to an empty DataFrame to generate data.' This answer describes a convoluted workaround that is not a documented pattern and would not work as described.