Task 2.1: Apply a chunking strategy for a given document structure and model constraints; Design retrieval systems using advanced chunking strategies

• AKeep 1,200-token chunks and pass only the top 3

  Incorrect

  Three results fit the budget, but each chunk is still cut at 512 tokens when embedded, so most of its text never shapes retrieval.

• BRe-chunk to 900 tokens with 20 percent overlap

  Incorrect

  Chunks above 512 tokens are still truncated at embedding time, and eight of them exceed the context budget.

• CKeep the chunks and switch the queries to hybrid search

  Incorrect

  Keyword matching does not stop embedding truncation, and eight 1,200-token chunks still overflow the prompt budget.

• DRe-chunk to about 450 tokens with a small overlap

  Correct

  Chunks of about 450 tokens embed without truncation, and eight of them fit in roughly 3,600 tokens of the 4,000-token budget.

Passing a chunk longer than the embedding model's maximum tokens truncates it, losing information. Chunk size must also respect the LLM context when several chunks are retrieved. Both limits together set the upper bound.

• ABuild a second index over whole procedures and query both indexes for every question

  Incorrect

  Two indexes double the cost, and nothing links a matched step in one index to its procedure in the other.

• BPass parent_text in columns_to_rerank so that the reranker returns the procedures

  Incorrect

  columns_to_rerank gives the reranker extra context for scoring; it does not decide which columns come back.

• CEmbed each step, keep its procedure in a parent_text column, request parent_text

  Correct

  Recording child and parent text in the same source row lets the index match on the child embedding and return the parent column with each result.

• DEmbed the procedure column and return the step column for each match

  Incorrect

  That is the reverse: matching on 2,000-token procedures is what loses precision for single-step questions.

Small chunks localize specific information while larger parents keep context. In AI Search, put child and parent text in the same source table, embed the child text, and list the parent column among the returned columns.

• ASplit every file into fixed 100-character chunks

  Incorrect

  Fixed 100-character splits ignore the Markdown headings that should set the chunk boundaries here, so chunks keep starting mid-section.

• BKeep each whole file as a single chunk

  Incorrect

  Whole files make chunks hard to pinpoint and can exceed embedding and context limits.

• CSplit on Markdown headers with a header-based text splitter

  Correct

  Format-specific chunking uses the document's own structure, such as Markdown headers, to set chunk boundaries.

• DStrip all headings before chunking

  Incorrect

  Headings are the structure that should drive boundaries and context; removing them makes chunks lose their topic.

• EPrepend the document title and section heading to each chunk

  Correct

  Semantic metadata such as section headers gives the embedding model and the reranker the topic of each chunk.

Markdown and HTML have structure that can define chunk boundaries. Adding document and section context to each chunk improves retrieval of chunks that would otherwise be ambiguous.

• A8,192 tokens per chunk, the embedding window

  Incorrect

  The documented limit for the embedding source column is set in bytes, not in tokens.

• B1,024 words per chunk of indexed text

  Incorrect

  1,024 words is the token limit for a hybrid search query, not for indexed text.

• C10 MB per chunk in the source table

  Incorrect

  10 MB is the bulk upsert and response size limit, not a column limit.

• D32,764 bytes per embedding source value

  Correct

  The embedding source column for a Delta Sync index is limited to 32,764 bytes.

AI Search limits index creation and updates as well as queries; for Delta Sync indexes they include a 100 KB row size and a 32,764-byte embedding source column.

• A1,024 tokens, for more context in each chunk

  Incorrect

  The guide lists 1,024 tokens for more context per chunk, which makes a single fact harder to pinpoint.

• B8,192 tokens, to fill the embedding window

  Incorrect

  An embedding window is a ceiling, not a target, and such large chunks bury the fact a question asks for.

• C256 tokens, for precise fact retrieval

  Correct

  The guide's starting configurations list 256-token chunks as better for precise fact retrieval, 512 as balanced and 1,024 for more context.

• D4,096 tokens, so that each FAQ page stays whole

  Incorrect

  Whole pages carry many unrelated facts, so retrieval cannot localize the one the user asked for.

Chunk size is a trade-off: smaller chunks localize specific information but can lose context, larger ones keep context but are harder to pinpoint. The guide suggests testing 256, 512 and 1,024 tokens and measuring the effect.

• Adatabricks-gte-large-en

  Correct

  GTE Large (En) has an 8,192-token embedding window, enough for 1,500-token chunks.

• Bdatabricks-bge-large-en

  Incorrect

  BGE Large (En) has a 512-token embedding window, so most of each chunk would be cut off.

• CEither, as both return 1,024 dimensions

  Incorrect

  The output dimension is the same, but the windows differ: 8,192 tokens against 512.

• DNeither, as both stop at 256 tokens

  Incorrect

  Both accept more than 256 tokens; their windows are 8,192 and 512 tokens.

Match chunk length to the embedding model's window. Both hosted English models return 1,024-dimension vectors, but GTE Large accepts 8,192 tokens and BGE Large 512.

• ASemantic chunking, which detects topic shifts

  Incorrect

  Semantic chunking uses techniques such as topic modeling to find topic shifts; it does not rely on paragraph breaks.

• BParagraph-based chunking of the prose

  Correct

  Paragraph-based chunking uses the natural paragraph boundaries of the text, because paragraphs often hold related information.

• CFormat-specific chunking on the markup

  Incorrect

  Format-specific chunking follows Markdown or HTML structure, which these memos do not have.

• DFixed-size chunking by token count

  Incorrect

  Fixed-size chunking cuts at a set number of characters or tokens, whatever the paragraph boundaries are.

Databricks groups chunking strategies into fixed-size, paragraph-based, format-specific and semantic chunking. For prose without markup, paragraph boundaries are the natural structure to chunk on.