A charter-desk question about a long escalation clause causes the assembled prompt to exceed the serving model's context limit, and the request fails. The team must keep the model and the chunking scheme unchanged. Which approach best resolves the failure while preserving answer quality?
Select an answer to reveal the explanation.
Short Explanation
Over-long context is a retrieval budget problem. Do not chop the prompt blindly and do not touch max_tokens — that governs the answer, not the question. Rank hard, keep the few passages that matter, and squeeze them if you must.
Full Explanation
When the assembled prompt exceeds the context window, the principled fix is to reduce what you put in it in a quality-preserving order: rerank the candidates, keep only the top passages, and if that is still too much, compress each passage to the spans relevant to the query before assembly. That keeps the strongest evidence and discards the weakest. Blind truncation is the closest-looking distractor and is the wrong answer for a specific reason — it cuts by position, not by value, so it will happily discard the highest-ranked passage or slice a clause in half mid-sentence, and it can silently remove the system instructions if they sit at the wrong end. Reordering the prompt changes which content the model attends to most, which is a real quality lever, but it does not change the total token count and so does not clear the limit. The max_tokens parameter caps the tokens the model may generate and is subtracted from the available window rather than added to it, so raising it makes the failure more likely, not less — that inversion is the single most common misconception here. Exam framing: over-long context is fixed upstream in retrieval, never by loosening a generation parameter.