Something moved below the page. Every GEO article gets that much right. Then it sells you control over the cut. You cannot see the cut.
What actually moved
Google announced passage ranking in October 2020 and shipped it for US English in February 2021. It is still listed as a current system in the December 2025 documentation.
Five years live. Most of the field has never heard of it. Has anyone quoted it to you?
Google's definition: passage ranking "is an AI system we use to identify individual sections or 'passages' of a web page to better understand how relevant a page is to a search."
Read the end of that sentence twice. Passages are evidence about the page's relevance. Google is not saying passages rank on their own.
Which is a problem for the title of this chapter, so take the correction now. The page did not stop being the unit of indexing. Google indexes pages, ranks pages, and reads passages as evidence about them.
What moved is the unit of extraction. The thing lifted out of your page and shown to somebody.
"The unit of ranking is no longer the page" is the field's shorthand, and it is loose. The precise version is duller and truer. The page is still what gets ranked. A span is what gets used.
Hold that split. Half the bad advice you have been sold comes from losing it.
The 2026 optimization guide goes further:
"There's no requirement to break your content into tiny pieces for AI to better understand it. Google systems are able to understand the nuance of multiple topics on a page and show the relevant piece to users."
Two claims in one paragraph, pointing opposite ways.
Google is denying an author obligation. Google is also confirming a system behavior: it shows the relevant piece.
So which is it? Both: sub-page selection is real, and pre-chunking your content is not something Google is asking you for.
Two more sentences sit in the same entry, and nobody quotes those either. Google says shorter pages, and sometimes longer ones, "can work well depending on your audience and subject matter." Then: "There's no ideal page length."
That sentence caps what this chapter can claim about page length. Hold onto it.
Perplexity says it from the other side. Chapter 2 quoted the sentence: spans "individually retrieved and ranked at query time." A company describing its own machine.
Individually retrieved. Individually ranked.
The unit moved. Nobody disputes that.
The cut is one problem. Which cut counts is another.
Chapter 2 left you a question: what decides where a passage begins and ends. Here is the answer, and you will not like it.
Most of what is sold as chunking optimization dies on one detail. Perplexity published it in March 2026.
Perplexity described the layer above their parser: a span-labeling pipeline that "identifies which segments of a source document are responsive to a given query."
Read what they built it for before you read what it does. Their words: "we engineered a new evaluation system." A rubric for grading their own snippets. Not a serving component they have described. Different thing entirely.
Read the rubric anyway. A company grades what it is trying to produce.
For a given query and document, it labels spans "by their relation to the query." Four classes follow. Vital spans "that must be included in the snippet." Irrelevant spans "that should be excluded." Duplicates. Other.
For a given query and document.
A span is not vital in the abstract. It is vital relative to a question somebody asked.
Which separates two things the field runs together. Segmentation: a parser cuts a document into spans. Selection: a question decides which spans matter.
In Perplexity's design the first happens at parse time, before any query exists, and the second happens per query. One fixed, one not.
That is one company's architecture, not a law. The 1994 section below shows you a system that did the opposite. Very little here is settled.
Now hold this book to its own standard.
A section below prosecutes people for exactly this move. That Perplexity page documents their Search API. A developer product. Same category as the OpenAI file search document this chapter takes apart.
Why does theirs count?
One difference runs in their favor.
The Perplexity Search API serves the open web, indexed by Perplexity. The OpenAI and Google Cloud parameters govern a corpus you upload yourself. Different input, different problem.
Two differences run the other way.
Perplexity's four classes come from an evaluation system. OpenAI's 800 tokens is at least a documented runtime default.
And the same Perplexity API exposes a developer-set extraction limit. Exactly the knob at issue.
Both directions, printed.
None of it is proof about the consumer product. Perplexity has never said the two share a pipeline.
Label it for what it is. The best-scoped thing anybody has published, and one company describing one product.
Worth reading closely. Not worth building a service line on.
Perplexity said the serving half of that split out loud in September 2025. The sentence Chapter 2 quoted describes retrieval and ranking. Not cutting.
Your structure nudges where the parser cuts. Nothing tells you where it landed. Nothing tells you which cut a query promoted. You are editing blind.
What can you do? Make every plausible cut survive. That is a different discipline.
One lever is genuinely yours, and it sits upstream of all of this.
Segmenters read the document tree. Not your CSS. Not your visual layout.
Whatever your markup declares is what they cut against. It is the only place your intent reaches them.
Four things carry, and not one of them is a content decision:
- Wrap the article in
<main>and<article>. Everything outside them is boilerplate a parser is entitled to drop. Body copy in a stack of unnamed divs tells it nothing. - Never skip a heading level. An H4 sitting under an H2 makes the tree ambiguous. Nobody has published what a parser does with an ambiguous tree. Which is the reason not to hand it one.
- Use a real
<table>, with<th>and a<caption>. A table built out of divs is a pile of unrelated strings the moment it is linearized. A table rendered as an image is not there at all. - Make source order match reading order. CSS can move a block anywhere. The parser still reads the source. Sidebars, pull quotes and sticky panels are the usual offenders.
None of that is a chunking strategy. It is the difference between a parser reading your structure and one guessing at it.
Half a day of front-end work, once, for your whole template. Whether a crawler can read any of it is Chapter 10's problem. Different ticket.
Do not make the parser guess.
Everything sold as chunking optimization is somebody else's problem
Five names you have read in GEO articles: fixed-size windows with overlap, recursive character splitting, semantic boundary detection, late chunking, contextual retrieval.
Here is what they actually are:
Techniques for building your own retrieval system. You do not run one. All five, same problem.
OpenAI documents 800-token chunks with 400-token overlap. That is the file search API (for documents you upload). It is not how ChatGPT reads the open web, and OpenAI has never said it is.
Google Cloud Document AI does heading-aware chunking with ancestral context. Azure AI Search has a Document Layout skill that chunks on markdownHeaderDepth. Both are enterprise RAG products, for your own documents.
Neither is Google Search. Neither is Copilot. Which one did your agency quote?
This is the most abused conflation in the field. A vendor documents a chunking parameter in a developer product. An article quotes it as though it describes web retrieval. A hundred agencies build a service line on it.
Is one of them on your invoice?
Exactly one company has documented anything about how it segments the open web, and it documented it for a developer API: Perplexity. Google confirms selection happens and documents no method at all.
The other two have said nothing.
So when someone shows you the optimal chunk size for AI search, ask one question. Which engine published it?
None of them did.
The experiments nobody in GEO has read
Passage retrieval is not new. O'Connor was publishing answer-passage retrieval in 1980, and the field ran the experiment your vendors are guessing about while they were still in school. They have not read it either.
Salton, Allan and Buckley put it on the modern map at SIGIR 1993. James Callan followed at SIGIR 1994, testing two definitions against each other: passages bounded by paragraphs, and passages bounded by overlapping text windows. Structure against arithmetic.
His result, verbatim: "Passages based upon paragraph boundaries were less effective than passages based upon overlapping text windows of varying sizes."
Structure lost. Yours included.
Price the finding honestly. 1994, pre-neural, one retrieval system. And it was not his only result. He also found, "perhaps the clearest result" in his own words, that document and passage evidence together beat either alone.
Two findings, not one. Both matter here.
It does not settle anything for 2026 dense retrieval.
But notice what it does to the burden of proof. The comparison has been run more than once. It keeps landing the same way.
Callan in 1994. Then Kaszkiel and Zobel at SIGIR 1997. They found fixed-length arbitrary passages "robust and effective" against the alternatives they tested. Those passages beat whole-document ranking by 8% on TREC disks 2 and 4, and by 18 to 37% on the Federal Register. Their reading: it confirms Callan.
And note when Callan cut. His windows began at the first query term matched in the document, so the passages did not exist until the query arrived. The opposite order to Perplexity's.
Say it precisely, because the precise version is the one you can use in a meeting. Structural passages do beat whole-document ranking. Salton showed that in 1993. So did Zobel's earlier work, whose passages were built so every boundary fell on a paragraph break. Wilkinson's results on that question came back mixed.
Both head-to-heads between arbitrary windows and structure-derived passages went to the windows. Structure loses to arithmetic.
And the GEO field has never mentioned any of it to you.
Which looks like it contradicts the markup ticket two sections ago. It does not, and the difference is worth ten seconds.
Those experiments say do not expect your structure to define the boundary. They say nothing against making it legible to a parser that linearizes you either way. Different claim.
Structure as a spec, no. Structure as an input, still the only one you have.
Callan's headline answers the question we get asked most. Do you split a long page into several short ones, or consolidate several into one?
Carefully, because he never varied document length. Both get counted. Neither substitutes for the other.
Read straight, that argues against publishing pages that are only passages. A page with no subject of its own is missing an axis.
Callan declines to say how the two get weighted. He does say you want both.
It argues harder against the everything page, at any length. Here Callan at least says why he cared.
His framing: long documents, structurally complex documents, and "even short documents summarizing many subjects" are all a challenge for systems that cannot tell where in a document the match happened.
Note which one is doing the work. Not length. Subject count.
So: one subject per URL, covered completely. A 900-word page on one thing beats a 6,000-word page on six. A 300-word page on nothing loses to both.
Google says in the same breath that shorter or longer can sometimes work, and that there is no ideal page length. Our inference, not his finding.
But the 1994 paper points at it from both ends. Which beats the vendor blog post on your desk.
The numbers behind the pitch
The techniques being sold to you do have measured results. The numbers are smaller than the pitch. Considerably.
| Method | Measured result | Source | Used by any answer engine? |
|---|---|---|---|
| Late chunking | +1.5 to +1.9 absolute points nDCG@10 over naive chunking | Jina AI, Sept 2024, BEIR subsets | Not documented |
| Semantic chunking | Costs "not justified by consistent performance gains" | NAACL 2025 Findings, peer reviewed | Not documented |
| Contextual retrieval | Retrieval failure 5.7% → 1.9%. The headline 67% requires contextual BM25 plus a reranker | Anthropic, Sept 2024, vendor benchmark | Not documented |
| Recursive splitting | No controlled evaluation published by its author | LangChain documentation | Not documented |
| Fixed-size windows | Repeatedly hard to beat in pre-neural IR | Callan 1994, Kaszkiel and Zobel 1997 | Not documented |
Take contextual retrieval, the most quoted of them. Anthropic published a 67% reduction in retrieval failures, and the number is real.
The 67% is a relative reduction, from a 5.7% failure rate to a 1.9% one. And the ladder matters. Contextual embeddings alone gave 35%. Adding contextual BM25 gave 49%. The headline 67% needs a reranker on top of both.
So the technique on its own moved 5.7% → 3.7%.
Useful if you are building a RAG pipeline. Irrelevant to whether Google cites your pricing page.
Lost in the middle is not about your page
One more correction, and this one is a category error rather than an exaggeration.
You have seen the finding. Liu and colleagues published it in TACL, in 2024.
Model performance "is often highest when relevant information occurs at the beginning or end of the input context." It "significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models."
Two independent groups have since proposed incompatible mechanisms for it. A 2026 analysis finds the U-shape in untrained models at step zero, with or without positional encoding. A 2025 account derives it from pretraining retrieval demands instead.
Two explanations, one effect. Neither disputes the effect.
So it is real. It is architectural. And it is not advice about your page.
The position that matters is position in the model's assembled context window. An ordering of retrieved passages, decided by a ranking system at request time.
Not position in your HTML.
You do not control where your passage lands in somebody else's context. Nobody does.
Position on your page still matters, by a different route. Your structure is what a parser cuts against. Just not this one.
So every article that turns this into "put your key points above the fold" has confused two different sequences. How many have you read?
The finding explains the engines' behavior, not yours. Perplexity names the family it belongs to: performance degrades with "increases in context size" and with "pollution of context with irrelevant information." Position bias is one member of that family, and they do not name it.
Context degradation is why the unit moved. It is not an instruction about your layout.
What actually survives the cut
Three things hold up. Narrower than the advice you have been sold, and better evidenced.
One: keep coupled elements physically together
This is the most actionable structural finding anybody has measured. Which says more about the evidence base than about the finding. And it is not about headings.
A 2026 paper on evidence units (preprint) named the failure mode plainly. Structured documents "are routinely fragmented when indexed for retrieval": tables split from their captions, figures from their explanations, equations from the paragraphs that interpret them.
Element-level indexing treats every parsed element as its own chunk. Your table goes one way. The paragraph explaining it goes another. Neither survives alone.
Keeping them together moved Recall@1 0.15 → 0.51 on ground-truth layouts. More than triple. On two real parsers it survived, measured a different way.
One caveat, and it is a real one. That experiment reorganized documents inside a retrieval index. It did not test writing pages with the elements already adjacent.
Index-side result, authoring-side rule. Ours, not the paper's.
Which gives you a rule for tomorrow morning. A table, its caption and the sentence that interprets it belong in one uninterrupted block. So do a code sample and what it does. So do a chart and its finding.
Not "add more H2s." Stop separating things that only mean something together. How many of yours are split right now?
Two: make every plausible cut self-sufficient
Chapter 1 gave you the cut test. Chapter 2 gave it a number. So why is it the right instrument when nobody can tell you where the cuts fall?
Because the test does not need the boundary. It needs every candidate boundary to be survivable. That is stricter than either chapter stated.
Chapter 1 asked whether a section survives having the page deleted around it. That assumes the section is the unit.
It is not. A span is cut wherever a parser decides, which may be mid-section, mid-list, or across the join between your table and the sentence explaining it.
So a passage has to survive a boundary you did not author.
Which changes the test. Do not ask whether your H2 sections stand alone. Ask where a machine would plausibly cut, and check those.
Three joins are worth auditing, and all three are cheap. A heading to its first sentence. A list stem to its first item. A figure to the sentence that reads it.
Why those three? A section above just spent a page saying nobody publishes a boundary rule.
Because one of the three has a published rule behind it. The other two are in the audit on the argument alone. No pretending otherwise.
Azure's Document Layout skill segments on heading depth, in markdown output mode. Google Cloud's layout parser is vaguer. Semantically coherent chunks, with the ancestral headings stapled back on.
Google's own words: standard parsers create chunks "removed from their original context, separating a paragraph from its heading." Theirs does not.
Which tells you two things at once. Headings are where at least one vendor draws its lines. And the engineers who built the other one thought a chunk without its heading was broken. Broken enough to engineer around. They were right.
Nobody has built you that repair on the open web. Nobody has said they will not, either.
You read that already. Still enterprise RAG, not Google Search.
Neither vendor publishes a rule for the list stem or the table. Google says its chunks carry "table headers." It says nothing about the sentence that reads the table.
So those two joins are in the audit because the argument puts them there. Which is why they are the ones you check yourself.
Best available prior on one. Reasoning on two. A spec on none.
The fix is the same in all three cases. Repeat the subject. Bound the number. Let no pronoun point outside the span.
Which looks like this. Under an H2 reading "Enterprise pricing", the sentence you probably wrote:
"It starts at $40 per seat and includes everything in Growth."
Cut the heading off and it says nothing. "It" is gone, "Growth" is gone, and the span is dead on arrival. Score zero.
The same sentence, written to travel:
"Enterprise pricing starts at $40 per seat per month and includes every Growth feature, plus SSO and audit logs."
Nineteen words instead of eleven. Alive anywhere it lands.
Chapter 2 said near-duplicate spans get suppressed. This says repeat the subject in every one of them. Both hold. The difference is what gets repeated.
Suppression works on claims. Two spans making the same point in different words compete for one slot. One of them loses.
Repeating the subject is not repeating the claim. "Onboarding takes eleven days" and "onboarding covers SSO, data import and two training sessions" name the same subject and say different things.
Name the subject every time. Make the point once.
It reads slightly redundant to a human going top to bottom. That is the cost, and it is the whole price of admission.
Do that and it stops mattering where the knife lands.
- Take your twenty highest-revenue pages. Not your twenty highest-traffic ones. This audit spends editing time. Editing time follows money, not sessions.
- Strip each one to a linear text stream. Reader view, or save as plain text. What you want is the page with its layout gone and its blocks in source order. That is roughly what a parser holds when it cuts.
- Pull three joins per page, mechanically. The first sentence under the first H2 inside the body, not under the H1. Skip the hero, or every commercial page on the site scores zero for a reason that has nothing to do with segmentation. Then the first item of any list. Then the sentence immediately after any table, chart or code block. First instance of each, in document order. Do not go looking for the flattering one.
- Score each join on one question. Read the block on its own, with nothing above it. Does it resolve? One if it does, zero if it needs the block above it to mean anything at all. No half mark, and arguing for one is how this audit gets useless.
Resolves is the test. Not useful, not interesting, not well written. "Enterprise plans include SSO, SCIM and audit logs" scores one: it names its own subject and stands up alone. "It also includes SSO and audit logs" scores zero, because "it" points at a block the reader may never receive. Nothing about how actionable either one is enters the score. - Read the result by column, not by page. Three columns, each scored as a percentage of the joins that actually exist. Most commercial pages carry no table, chart or code block at all. If fewer than half your money pages give you a figure join to score, stop there: that is the finding, and it says you have no evidence-carrying elements on the pages that make money.
A page scoring badly is an editing job. A column scoring badly is a template job. It has been failing on every page since the template shipped. - Under 70 percent on any column, stop editing pages. Seventy is ours. No engine publishes a threshold, and this one is set where a column stops looking like bad pages and starts looking like a bad template. Fix the pattern instead. Headings failing usually means your subheads are labels rather than statements. Lists failing means the stem is carrying the verb. Figures failing means your captions describe the picture instead of stating the finding.
- Re-run it on ten fresh pages after the template change. Same three joins, same scoring, same person. This is the only feedback loop available in this part of the stack, because the engines publish none.
Three: the features that correlate with being used
One 2026 measurement study looked at 21,143 citations across ChatGPT, Google and Perplexity. It scored which content features correlate with influence once a page has been fetched:
- Code present: +76.9%
- Numerical statistics: +61.6%
- Definition markers: +57.3%
- Comparison content: +55.3%
- How-to content: +41.2%
- Q&A format: -5.7%
All six numbers are one measure. Relative change in a mean influence score. Pages carrying the feature against pages without it.
Look at the last row twice. Q&A format is the only one that does not help. And read the size before you read the sign. The top four move that score by more than half. How-to moves it by 41.2 percent. Q&A moves it by 5.7 percent, off a mean influence score near 0.1.
That is not harm. That is nothing. Which is still awkward. "Add an FAQ block" is the single most common GEO prescription in circulation.
And the largest published feature-level study of AI citations cannot find it doing anything. Nothing at all.
The authors are explicit about the fix. If you use Q&A, it has to carry "substantive definitions, quantitative evidence, comparison logic, and clear section structure." The wrapper is not the signal.
The authors put the limit in writing. Nobody quotes it. The influence score is "a constructed observational proxy." The paper "does not claim that observed content features causally force a generative engine to cite or use a page." Correlation, then.
Price it lower still. The draft carries no inferential statistics.
On purpose: it "deliberately avoids fabricated p-values, confidence intervals, or regression coefficients." Read that twice.
So these are uncontrolled means. And word count correlates with influence in the same paper. An obvious confounder for "contains code."
One note on that table. Every feature in it is a page property, measured over whole fetched pages.
Four of them happen to be things you can also put inside a single span. How-to is not. Which is why it does not travel to the takeaway.
These are properties of pages that already got retrieved. Not a route to being retrieved.
The benchmark that should slow you down: C-SEO Bench
There is a peer-reviewed benchmark of conversational SEO methods (NeurIPS 2025). It is not kind.
Its first finding, verbatim: "most current C-SEO methods are not only largely ineffective but also frequently have a negative impact on document ranking."
Its second, and read it as a budget instruction: "traditional SEO strategies, those aiming to improve the ranking of the source in the LLM context, are significantly more effective."
Then the finding nobody wants: "as we increase the number of C-SEO adopters, the overall gains decrease, depicting a congested and zero-sum nature of the problem."
Three of 54 cases came back significantly positive. Three. Ask which three your agency is selling.
Read the setup before you read the numbers. C-SEO Bench hands four models a fixed list of five to ten documents per query. Then measures where each one lands in the citation order. No live engine. White-hat methods only. English only.
Now put it next to the section above, because they disagree.
One of the methods C-SEO Bench tested was adding statistics, "to increase the perceived technical depth."
It reached significance in no domain. None of the six.
The observational study says numbers correlate with being used. The controlled benchmark says adding numbers does not move rank. You have both in front of you.
Here is how we read it. The controlled result is the better evidence about cause. The observational one describes what cited pages look like. Two different questions.
So add the numbers because they make your passage usable once somebody quotes it. Do not add them expecting a rank to move. Different job.
So C-SEO Bench is not evidence about getting retrieved. It is evidence about what happens next. Which is the argument here.
We sell GEO services, and we are printing this anyway. Weigh it accordingly.
So take the finding at its real size. Once your page is retrieved, how it is written measurably changes whether it gets used. Getting retrieved is a different problem. Formatting does not touch it.
Which is why Chapter 3 comes before this one.
The objection this chapter has to answer
"You have spent a chapter telling me nothing works. Then you tell me I cannot see the boundary, cannot measure the selection, and should stop buying the one service anybody sells against it. What am I supposed to do on Monday?"
Two answers. The first is a budget line.
Whatever you were about to spend on chunk optimization, price it. Then read the last column of Table 4.1.
You are buying a parameter from a product you do not run. Tuned on benchmarks its vendor picked. Cancel the line.
We are not going to price someone else's invoice. Pull the line item and read the number yourself. That number is this chapter's first deliverable.
The second answer is harder to hear. You were always editing blind.
Twelve years of featured snippets. Nobody could ever see which paragraph of theirs won one.
What changed is the size of the blind spot. It used to be one box. Now it is the whole surface.
So do what you have always done without feedback. Make the thing hard to break instead of tuned.
Artifact 4.3 is the audit. The four markup fixes are the template. Neither one needs a boundary spec.
Which is why those two are the deliverables.
The instructions that survived
Strip out everything that failed to survive. A markup ticket, an audit and two editing habits. That is the whole list. Unglamorous. That is the point.
Every method that promised you the boundary was selling you somebody else's product. The boundary is not on sale.
Which leaves the sentences, and this chapter has said almost nothing about those.
Structure decides where a span breaks. Wording decides whether the piece inside it is worth anything.
That is Chapter 5, and it is the half of this you can actually control.
The knife is not yours. The text is.
- Stop buying chunk-size advice. No consumer answer engine has published a chunk size, boundary rule or segmentation spec. Anyone quoting one is quoting a developer API.
- Fix your coupled elements first. Table with caption with interpretation, chart with finding, code with explanation. One uninterrupted block each. Measured index-side, so the authoring rule is ours.
- Run the cut-point audit. Artifact 4.3: twenty of your pages, three joins each, one point per join that resolves alone. Read it by column. Under 70 percent is a template problem.
- Fix the markup before the copy. A real
<main>and<article>, no skipped heading levels, real tables, source order matching reading order. Half a day, once. - Add code, numbers, definitions and comparisons, not FAQ wrappers. Those four correlate with being used, by 55 to 77 percent each. Q&A format measures nothing. Uncontrolled means, all of it.
- Do not confuse being used with being retrieved. Everything above is conditional on already being in the pool. Chapter 3 owns the pool.
- Google Search Central, "A guide to Google Search ranking systems," updated 10 December 2025. Passage ranking definition, listed as a current system.
- Google Search Central, "Optimizing your website for generative AI features on Google Search," published May 2026, updated 10 July 2026. The chunking myth entry, quoted in part.
- Prabhakar Raghavan, "How AI is powering a more helpful Google," 15 October 2020. Passage ranking announced. Live for US English 10 February 2021.
- Martin Splitt, quoted in Search Engine Journal, 11 February 2021. "There is nothing that you need to do." Note his own hedge on passage length: "I would guess."
- Perplexity, "Architecting and Evaluating an AI-First Search API," 25 September 2025. Self-contained spans, and the content-understanding module. Corporate engineering publication, no named authors.
- Perplexity, "Search API: better extraction, dynamic benchmarks," 11 March 2026. Query-conditional span labeling, vital and irrelevant classes. Described as an evaluation system for the Search API. Not stated as a serving component, and not stated for the consumer product.
- OpenAI retrieval guide, developers.openai.com. 800-token chunks with 400-token overlap, in the file search API.
- Google Cloud Document AI Layout Parser, and Microsoft Azure AI Search Document Layout skill. Heading-aware chunking with ancestral context, in enterprise RAG products, not web search. Azure chunks on heading depth only in markdown output mode. Text mode is fixed character length.
- J. O'Connor, "Answer-passage retrieval by text searching," JASIS 31(4), 1980, cited in Callan 1994. Salton, Allan and Buckley, "Approaches to Passage Retrieval in Full Text Information Systems," SIGIR 1993. James P. Callan, "Passage-Level Evidence in Document Retrieval," SIGIR 1994, University of Massachusetts Amherst. Marcin Kaszkiel and Justin Zobel, "Passage Retrieval Revisited," SIGIR 1997, pages 178 to 185. They found fixed-length arbitrary passages "robust and effective" against the alternatives they tested, beating whole-document ranking by 8% on TREC disks 2 and 4 and 18 to 37% on the Federal Register, and reported that their results confirm Callan's. Callan's windows were cut at query evaluation time rather than in a preprocessing pass, beginning at the first query term matched in each document. Kaszkiel and Zobel's arbitrary passages start at fixed word offsets instead, independent of the query. Their survey also records Salton and Zobel finding structure-derived passages more effective than whole-document ranking, and Wilkinson's results on that question mixed. Callan found paragraph boundaries less effective than overlapping windows, and that combining document-level and passage-level evidence beat either alone. He did not vary document length, so the page-length reading in this chapter is ours.
- Günther, Mohr, Williams, Wang and Xiao, "Late Chunking," arXiv:2409.04701, September 2024. 1.5 to 1.9 absolute points nDCG@10 across three models and four BEIR subsets.
- Qu, Tu and Bao, "Is Semantic Chunking Worth the Computational Cost?", Findings of ACL: NAACL 2025.
- Anthropic, "Introducing Contextual Retrieval," 19 September 2024. Failure rate 5.7% to 3.7% with contextual embeddings (35%), to 2.9% with contextual BM25 added (49%), to 1.9% with a reranker on top (67%). Vendor-selected corpora, not a public benchmark, no third-party replication.
- Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni and Liang, "Lost in the Middle," TACL volume 12, 2024. Two later papers propose incompatible mechanisms for it, neither disputing the effect: arXiv:2510.10276 (October 2025) derives it from pretraining retrieval demands, while arXiv:2603.10123 (March 2026) finds the U-shape present at initialization.
- Han, "Evidence Units: Ontology-Grounded Document Organization for Parser-Independent Retrieval," arXiv:2604.00500, April 2026. Recall@1 0.15 to 0.51 from keeping coupled elements together, on the ground-truth layout track. Single-author preprint, auto-generated QA pairs, index-side rather than authoring-side.
- Zhang, He and Yao, "From Citation Selection to Citation Absorption," arXiv:2604.25707, April 2026. 602 prompts, 21,143 citations, 72 features. Pre-submission draft that deliberately reports no p-values, confidence intervals or regression coefficients, so every figure quoted here is an uncontrolled descriptive mean. The authors explicitly disclaim causal interpretation, and advise that Q&A format is not a universal intervention.
- Puerto, Gubri, Green, Oh and Yun, "C-SEO Bench: Does Conversational SEO Work?", NeurIPS 2025 Datasets and Benchmarks Track. A controlled setup over a fixed document list of five to ten per query, four models, not a live answer engine. Its "statistics" method reached significance in no domain.