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?

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 — increasing the chunk size to 1024 tokens and adding a 128-token overlap between chunks — addresses both dimensions of the problem. Increasing chunk size to 1024 tokens reduces the frequency of mid-clause cuts by capturing more complete sections per chunk; 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.

The sentence-window chunking approach with a 3-sentence window and the Azure AI Search 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.

The section-level splitting approach using a custom skill in the Azure AI Search enrichment pipeline, then indexing each section as a separate document, 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.

The integrated vectorization approach with the ada-002 embedding model and a reduced 256-token chunk size 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.