Where the Task Sits in Your Context: Why an LLM Ignores the Question Unless It Comes Last

PRINCIPLE: The task always goes at the end of the context

✅ CORRECT STRUCTURE:

{document / examples / background context}

────────────────────────────

Task: {question / instruction}

──────────────────────────────────────────────

❌ RISKY STRUCTURES:

Task: {question}       ← question first, context after
{large context}

──────────────

{context 1}
Task: {question}       ← question in the middle
{context 2}

──────────────────────────────────────────────

🔧 DIAGNOSTIC TRICK (if the question has to sit in the middle):

{context 1}
Task: {question}       ← question in the middle
{context 2}

────────────────────────────

Reminder: solve this task: {question}  ← copy at the end

It all works inside a single prompt. No separate requests.

Task: You're reviewing a commercial lease for retail space in Chicago, 15 pages of text. You want to know whether any clauses could hurt your business.

❌ What most people do (risky structure):

Review this lease and flag every clause 
that could be unfavorable to the tenant.

[15 pages of lease...]

The question is buried under a mountain of text. The model reads the context, reaches the end, and finds no task there. So it starts summarizing the text however it sees fit.

✅ The right structure:

[15 pages of the lease...]

────────────────────────────────────────

Your task: flag every clause in the lease above 
that could be unfavorable to the tenant. 
For each clause, explain what the risk is 
and what's worth negotiating with the landlord.

Result: The model gets a clear task after the context, in the position of highest attention. You get a structured list of risks with explanations instead of a generic recap of the lease.

🔧 If the structure forces the question into the middle (say, documents and instructions are interleaved):

[Lease, part 1: pages 1-8...]

Pay special attention to the rent escalation clauses.

[Lease, part 2: pages 9-15...]

────────────────────────────────────────

Task reminder: flag every clause in the lease above 
that could be unfavorable to the tenant, 
especially anything about rent escalation.

The LLM weakness: A model processes tokens sequentially and builds a "working memory" as it reads. By the time it generates an answer, the most recent tokens take priority: they sit closest to where the output begins. This isn't a bug; it's a consequence of the transformer architecture.

What goes wrong with a task in the middle: If the question is surrounded by lots of similar content (solved examples, other questions), the model "grabs" answers from nearby text instead of solving the task. The study found that 76% of errors at the middle position are numbers or answers taken from neighboring examples. At the end position, accidental matches account for only 22%.

Why repeating it at the end works: When a copy of the task comes last, the model "sees" it right before it starts generating. That completely wipes out the positional effect. In the experiment, repetition restored accuracy to within ±4 percentage points of the "ideal" position for all 9 models at 8K tokens of context.

Control levers:

{background_context}

────────────────────────────────────────

{task_or_question}

What to fill in: - {background_context}: the document, article, data, email thread, examples, anything you want the model to take into account - {task_or_question}: the specific instruction or question, always last

If the context comes in parts:

{context_part_1}

{context_part_2}

────────────────────────────────────────

Task: {question_or_instruction}

If the task has to sit in the middle:

{context_part_1}

{intermediate_instruction}

{context_part_2}

────────────────────────────────────────

Reminder, your task is: {question_or_instruction}

⚠️ Model dependence: The effect varies a lot across models. DeepSeek in reasoning mode barely loses accuracy with similar background content, but it does drop with unanswered background questions. Among the new releases, GLM-5.1 and Kimi-K2.6 hold up better than their older versions. Your model may behave differently, so test it.

⚠️ The type of background content is critical: Neutral text (Wikipedia, news) causes almost no interference. Similar examples are the danger, especially if they contain numbers or answers of the same type as your task. Don't use solved examples as "separators" when the task sits in the middle.

⚠️ The effect grows with context length: At 8K tokens the drop is moderate. At 64K it's catastrophic for vulnerable models. If you work with big documents, the "task last" rule goes from nice-to-have to mandatory.

⚠️ The diagnostic trick isn't always 100%: With very long contexts (64K), repeating the task at the end helps, but for some models it doesn't fully restore accuracy. At 8K it works for all 9 models.

Researchers from Beijing Jiaotong University took 9 current LLMs from different providers (DeepSeek, Kimi, GLM, Qwen, MiMo) and tested them on math word problems (GSM8K) and science questions (ARC-Challenge). The idea was simple: take the same task, surround it with background text, and see what happens when the task sits at the end versus in the middle across different context sizes: 8K, 32K and 64K tokens.

The key experiment was a "diagnostic probe": they placed a task in the middle (where it loses accuracy), then added a copy of the same task at the end. Accuracy instantly bounced back to the "task at the end all along" level for all 9 models. That proves the issue isn't task difficulty or context volume as such, but specifically position.

The most surprising result: different kinds of background content have radically different effects. At 64K, MiMo-v2-Flash loses 88 percentage points of accuracy when the background is solved problems, and 0 points when it's neutral Wikipedia text. So it's not "long context kills accuracy": it's topically similar content that creates interference. The model literally pulls answers from the surrounding examples and passes them off as its answer to your task.

A telling detail from the audit: the researchers checked the release reports of four major vendors (DeepSeek, Kimi, GLM, MiMo) and found that none of them included position-controlled tests in their headline tables. The headline tables showcase coding and agent benchmarks. How much a model's accuracy depends on where the task sits is reported nowhere.

Results table: accuracy drop when the task moves from the end to the middle (GSM8K, background = solved problems):

Model               | 8K Drop | 32K Drop | 64K Drop
────────────────────|────────|─────────|─────────
Qwen 2.5-7B         |  −86pp  |  −84pp   |  −94pp ★
MiMo-v2-Flash       |  −12pp  |  −24pp   |  −88pp ★
MiMo-V2.5-Pro       |   −8pp  |  −16pp   |  −32pp ★
GLM-4.7-FlashX      |  −12pp  |  −20pp   |  −34pp ★
GLM-5.1             |   +0pp  |   +2pp   |   +2pp
DeepSeek-R          |   +0pp  |   +0pp   |   +0pp
DeepSeek-V4-Pro     |   −2pp  |   −2pp   |   −4pp
Kimi k2.5           |   +4pp  |   +0pp   |   −6pp
Kimi-K2.6           |   +2pp  |   −2pp   |   +2pp

★ = statistically significant

Diagnostic probe (8K, each model on its worst background type):

Model           |  End  |  Middle  | Middle×2  |  Middle+End
──────────────  |──────|─────────|───────────|────────────────
Qwen 2.5-7B     |  90%  |    4%    |     4%    |      94%
MiMo-v2-Flash   |  98%  |   22%    |    70%    |      98%
MiMo-V2.5-Pro   | 100%  |   44%    |    68%    |     100%
Kimi k2.5       |  94%  |   40%    |    92%    |      96%
DeepSeek-V4-Pro | 100%  |   68%    |    72%    |      96%

Context: The researchers tested 9 LLMs through the providers' official APIs (DashScope, Xiaomi, Zhipu, DeepSeek, Moonshot). N=50 examples per condition, seed=42.

1. Adaptation: working with multiple documents

When you need to compare several documents or feed the model many sources, the structure is the same:

💡 Adaptation for comparing documents:

Copy

=== Document 1 ===
{text 1}

=== Document 2 ===
{text 2}

=== Document 3 ===
{text 3}

────────────────────────────────────────

Compare these three documents on the following criteria: {criteria}

2. Technique: a "closing reminder" for long conversations

🔧 Technique: restate the task at the end of a long conversation

If your chat with the model has stretched across many messages and answer quality is slipping, restate the task explicitly in your next message:

Copy

[Quick reminder of what we're working on: we're {task_summary}]

Next step: {specific_instruction}

Same logic: "task last" works at the level of the whole conversation history too, not just inside a single prompt.

3. Extrapolation: stress-test your own model

Want to see how vulnerable your model is to the positional effect? Run a quick test:

Copy

Take any question with a known answer.
Put the question first, then add 500-1000 words 
of neutral text after it.
Compare the answer with the version where the question comes last.

If the answers differ, your model is vulnerable 
to the positional effect even with short contexts.

Paper title: Positional Failures in Long-Context LLMs: A Blind Spot in Reasoning Benchmarks

Authors: Chuyifei Zhang, Xiaowen Huang, Hongyu Cui, Jitao Sang

Universities: Beijing Jiaotong University, Central South University of Forestry and Technology

Benchmarks mentioned: Needle-in-a-Haystack, RULER, GSM8K, ARC-Challenge, SCROLLS, LongBench, LooGLE, BABILong