Data preparation Study Guide — Generative AI Engineer Associate

Data Preparation for Retrieval-Augmented Generation

This domain tests your ability to design, implement, and evaluate the full data pipeline that feeds a RAG system — from raw document ingestion through chunking, embedding, indexing, and retrieval quality assessment. It accounts for 14% of the exam, making it the third-largest domain. Questions are scenario-based: you will be given a data format, a retrieval requirement, or a quality symptom, and you must choose the correct pipeline design decision or Databricks-specific configuration.

Chunking Strategies

Chunking is the process of splitting source documents into smaller text units that fit within an embedding model's context window and return focused, relevant passages at retrieval time. Choosing the wrong strategy is the most common design error in RAG pipelines.

Fixed-Size Chunking

Fixed-size chunking splits text into chunks of a predetermined character or token count, with an optional overlap between consecutive chunks.

• Chunk size is typically measured in tokens (not characters), because embedding models have token limits.
• Overlap (e.g., 10–20% of chunk size) prevents relevant context from being split across chunk boundaries.
• Simple, fast, and predictable — but ignores document structure and can split sentences mid-thought.

Typical defaults to memorize:

• Common chunk sizes: 256, 512, 1024 tokens
• Common overlap: 10–20% of chunk size (e.g., 50–100 tokens for a 512-token chunk)

Semantic Chunking

Semantic chunking uses embedding similarity between consecutive sentences to detect topic shifts and create chunk boundaries. Chunks have variable length but high internal coherence.

• Requires an embedding model to be called during the chunking phase itself.
• Higher quality retrieval but more expensive and slower to produce than fixed-size.
• Best when documents mix unrelated topics in a single file.

Document-Aware Chunking

Document-aware chunking (also called structure-based or recursive character text splitting) respects the document's own delimiters — headings, paragraphs, sections, HTML tags, Markdown headers — and splits only when a structural boundary is crossed.

• Keeps semantically related content together without needing to run an embedding model during chunking.
• The LangChain RecursiveCharacterTextSplitter is the canonical example; it tries \n\n, then \n, then spaces before character-level splitting.
• Ideal for structured documents (HTML, Markdown, legal contracts with numbered sections).

Comparison Table

Bold concept: Overlap is only relevant in fixed-size chunking. Semantic and document-aware strategies create natural boundaries and do not need explicit overlap.

Common Traps

• The exam may describe a PDF with clearly defined chapters and ask which strategy is "most appropriate" — the answer is document-aware, not semantic (semantic is expensive and adds no value when structure already exists).
• Overlap is presented as a solution for "context loss" — it is only valid for fixed-size, not for structure-based chunking.
• A question may say "the embedding model has a 512-token context window" — this means chunk size must be ≤ 512 tokens, not ≤ 512 characters.

Worked scenario: A legal team has contracts in Markdown format with numbered sections (e.g., ## Section 3: Indemnification). Retrieval must return complete sections, not fragments. Fixed-size chunking at 512 tokens occasionally splits a section across two chunks. Semantic chunking is proposed. Correct choice: Document-aware chunking — split on ## headers. This respects document structure, keeps sections intact, and costs less than semantic chunking.

Document Extraction from PDFs and Unstructured Sources

RAG pipelines must convert raw files (PDFs, HTML, Word, images) into plain text before chunking. The extraction step determines the ceiling on retrieval quality — garbage in, garbage out.

PDF extraction libraries recognized on the exam:

unstructured is the library most frequently referenced in Databricks RAG documentation and exam scenarios. It auto-detects file type, extracts text, and can partition documents into typed elements (Title, NarrativeText, Table, ListItem).

Key extraction considerations:

• Tables in PDFs are notoriously hard to extract as structured data — pdfplumber or unstructured with strategy="hi_res" are preferred.
• Scanned PDFs contain no embedded text — OCR is mandatory; pure-Python PDF libraries return empty strings.
• HTML documents should be parsed with BeautifulSoup or unstructured's HTML partitioner to strip navigation, footers, and boilerplate.

Common Traps

• A question describes a scanned (image-based) PDF — using PyPDF2 will return empty text, not an error. The correct tool is an OCR-capable library.
• The exam distinguishes between "extracting text" (getting raw characters) and "extracting structure" (getting headings, tables as structured objects). These require different tools.
• unstructured elements have a .category attribute (e.g., "Table", "Title") that can be used to filter or route content during ingestion.