A legal-tech team is building a Foundry-hosted assistant that must read entire merger agreements, some running past 250 pages, and produce a single risk summary in one pass. Early tests show the assistant silently drops content from the later sections of long documents. Which change addresses the root cause?
Select an answer to reveal the explanation.
Short Explanation
Picture the model as reading through a stack of pages with a fixed-size window it can look through at once. Once the contract runs past that window, everything further back simply falls out of view no matter how carefully the model reads what remains, which is exactly why later sections get dropped. Tweaking how random the wording sounds does not widen that window, and neither does telling the model to write a longer answer since that setting only caps how much it says back, not how much it can take in. Beefing up the deployment for more traffic capacity does not help either, because the limit is baked into the model itself, not the hardware serving it. The real fix is either picking a model built to see more pages at once, or breaking the document into smaller pieces, summarizing each piece, and stitching those summaries together into one overview.
Full Explanation
The correct answer is B. The assistant is dropping content from later sections because the merger agreements exceed the model's context window, the maximum amount of text it can process in a single call. The fix must address input capacity, not output behavior: either choose a catalog model with a larger context window or restructure the workflow to chunk the document into sections, summarize each chunk, and combine the partial summaries into a final risk summary. Option A is incorrect because temperature controls the randomness of word choice, not how much input text the model can read. Option C is incorrect because max_tokens governs the length of the generated response, and raising it does nothing to let the model see text it never received as input. Option D is incorrect because moving from serverless to managed compute changes throughput and cost characteristics for high-volume traffic, but a single request to either deployment type is still bounded by the same underlying model's context window.