Lost in the Middle

Lost in the middle is the empirically observed tendency of large language models to use information positioned at the beginning and end of a long input context more reliably than information in the middle, documented by Liu et al. "Lost in the Middle" (2023)¹. Plotted against the position of the relevant information, accuracy forms a U-shape: strong at the two edges, sagging in the middle. The paper's verbatim summary is that "performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts."

The effect was measured on multi-document question answering and key-value retrieval: when the document (or key) containing the answer was placed in the middle of a long context, models retrieved it less reliably than when the same content sat at the start or end. The phenomenon is about where information sits inside the model's assembled context window at generation time, not about where it sits on a source web page.

Status in 2026

Lost in the middle is a widely-cited and still-relevant finding, but its magnitude is model-dependent and partially mitigated since 2023. The 2024-2026 generation of long-context models (much larger context windows, improved long-range attention) reduced the U-shape's depth but did not flatten it; several post-2023 evaluations and practitioner tests have reported middle-context degradation to varying degrees across models. Treat it as a live tendency to design around, not a solved problem and not a fixed constant.

Its main importance for AI-search work is corrective: it is one evidence-backed mechanism that "front-load your key content" advice gestures at (chunk-boundary survival, snippet readability, and human scanning are others), and naming it cleanly prevents two common errors. First, it is not a retrieval-ranking effect: BM25 itself and the dense-similarity scoring used in hybrid retrieval do not reward a term simply for appearing earlier in the body text, so "front-loading helps you rank" claims that invoke within-body position weighting are wrong (production systems may add field/heading boosts, but that is structure weighting, not body-position weighting). Second, it is a context-position effect at generation time, which a publisher does not directly control: you do not decide where a retrieval pipeline places your passage in the model's context window.

How to apply

The publisher-controllable response to lost in the middle is not "move content to the top of the page" (that conflates page position with context position). It is to make each unit of content survive extraction and stay usable wherever it lands:

• Write self-contained passages. A paragraph that states its own subject, makes one clear claim, and does not depend on the sentence before or after it remains usable whether a retrieval system places it at the edge or the middle of a context window. This is the same discipline behind passage-level optimization and sub-passage extraction; lost in the middle is the mechanism that makes it pay off.
• Put the load-bearing answer early in its own section, not buried mid-document. Within a single long page, the answer to a likely query should open its section rather than appear in the eleventh paragraph. This helps chunk-boundary survival (the answer is less likely to be split across chunks) and concept density, which is what definition-lead style and answer blocks operationalize.
• Do not over-trust position as a lever you control. Because context position is assigned by the retrieval pipeline, not by you, the durable investment is passage self-containment and clear structure, not chasing a "top of context" slot you cannot occupy on demand.

What to skip:

• "Put your most important content at the top of the page and the LLM will prioritize it." Page position is not context position; the model sees retrieved chunks in an order the pipeline chooses.
• Citing lost in the middle as evidence that retrieval ranks front-loaded content higher. It is a generation-side effect; the retriever does not weight within-document position.
• Treating the 2023 U-shape as a fixed constant. It is model-dependent and has been partially mitigated; verify against current model behavior rather than assuming the 2023 magnitude.

How it relates to other concepts

• Underlying mechanism for passage-level optimization and sub-passage extraction: both disciplines assume the unit that matters is the passage, not the page. Lost in the middle is the generation-side evidence for why self-contained passages survive better than answers buried in long context.
• Helps explain why definition-lead style, answer blocks, and quotation addition may be useful disciplines: leading with a clear, self-contained statement keeps the load-bearing content out of the fragile middle and in an extractable form. Whether any of these earns measurable citation lift still has to be tested; lost in the middle only explains one mechanism by which they could.
• Distinct from retrieval-side ranking in BM25 and hybrid retrieval: those rank documents/passages by relevance, not by within-document position. Lost in the middle operates one stage later, when the LLM reads its assembled context. Conflating the two is the position-weighting myth this entry exists to correct.
• Adjacent to citation precision in the ai-behavior cluster: both describe measured LLM behaviors (citation faithfulness; context-position usage) rather than content tactics, and both set realistic ceilings on what content optimization can achieve. (Note: this entry's source is a different Liu et al. 2023 paper from the one cited in citation precision. This is "Lost in the Middle" (Nelson F. Liu, Lin, Hewitt, et al., Liang, arXiv:2307.03172). Citation precision cites "Evaluating Verifiability in Generative Search Engines" (Nelson F. Liu, Zhang, Liang, arXiv:2304.09848). Same first author and senior author, different work; cite by short title, not bare "Liu et al. 2023.")
• A constraint on Generative Engine Optimization generally: it marks the boundary between what a publisher controls (passage self-containment, clarity) and what the retrieval-plus-generation pipeline controls (context assembly and position).