A legal department deploys a Copilot Studio agent backed by Azure AI Search over a corpus of 500-page legal contracts. Users report that when they ask about specific clause obligations (e.g., 'What are the termination notice requirements in the Master Services Agreement?'), the agent returns partial clause text that cuts off mid-sentence and lacks the preceding context that defines key terms. The knowledge source uses the default fixed-size chunking with 512-token chunks and no overlap. Which chunking strategy change would most directly resolve the incomplete context problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Fixed-size chunking with no overlap is like tearing a book into pages and throwing away the words that straddle the tear — you lose the connective tissue right where it matters most. Adding overlap is duct tape across those seams: it copies the end of one chunk to the beginning of the next, so clauses that span chunk boundaries arrive at the retriever intact.
Full explanation below image
Full Explanation
The symptom — mid-sentence truncation and missing definitional context — is a textbook consequence of fixed-size chunking with zero overlap applied to long-form legal documents. Legal contracts have clauses that routinely span many hundreds of tokens, with defined terms introduced early in a section and referenced throughout. When a 512-token chunk boundary falls in the middle of a clause, the retrieved chunk begins in media res, lacking the preceding context that defines the terms being used.
The two-part fix in Option B addresses both dimensions of the problem: (1) increasing chunk size to 1024 tokens reduces the frequency of mid-clause cuts by capturing more complete sections per chunk; and (2) adding a 128-token overlap ensures that content near each boundary is duplicated into adjacent chunks. This means that even if a clause straddles a boundary, both the opening context and the continuing obligation text appear in at least one retrievable chunk.
Option A (sentence-window chunking with semantic ranker) is a reasonable approach for some document types, but sentence-window chunking with 3 sentences is actually smaller than the 512-token default — it would worsen the truncation problem for long legal clauses. While the semantic ranker improves relevance ranking, it cannot reconstruct content that was never included in any chunk.
Option C (section-level splitting via custom skill) is architecturally sound and could be highly effective for well-structured contracts with consistent heading patterns. However, it requires building and maintaining a custom enrichment skill pipeline, which is significantly more complex than adjusting chunk parameters. It is the right long-term solution for structured legal documents but is not the most direct answer to the immediate problem described.
Option D is counterproductive. Reducing chunk size to 256 tokens with no overlap would dramatically increase truncation frequency. Integrated vectorization with ada-002 is about embedding quality for semantic search, not about preserving clause context — and smaller chunks with better embeddings still cannot contain text that was cut out of them.
Exam tip: Chunking strategy questions in RAG scenarios have three levers: chunk size (how much content per chunk), overlap (duplication at boundaries), and chunking method (fixed-size vs. semantic/structural). Match the lever to the symptom: truncated context → increase size and overlap; irrelevant retrieval → improve embedding or use semantic chunking; section mismatch → structural chunking by document element.