Structural Extractability for RAG: Inverted Pyramid & Positional Retrieval Bias

Most pages that lose AI citations do not lose them on quality. They lose them on geometry. The decisive fact sits in paragraph fourteen, wrapped in a narrative build-up that a human might enjoy — and a retrieval pipeline never reaches.

Retrieval-augmented generation (RAG) systems do not read your page the way a person does. They shred it into chunks, embed each chunk separately, and pull back a handful of passages to synthesize an answer. Where a fact sits inside your document now matters almost as much as whether the fact exists at all.

This guide explains the chunking mechanics behind that behavior, the reasons position skews retrieval, and a concrete inverted-pyramid rewrite process you can apply to any existing article this week.

Why RAG Systems Never Read Your Whole Page

Every major answer engine — Google AI Overviews, Perplexity, ChatGPT Search — runs a variant of the same pipeline. Your page is fetched and stripped to text. That text is segmented into chunks, typically 200-500 tokens each, often with a 10-15% overlap window. Each chunk becomes an independent vector in an index. When a user asks a question, the engine retrieves the top-k chunks by similarity — usually somewhere between 5 and 20 passages drawn from multiple domains — and the LLM writes its answer from those passages alone.

Two consequences follow directly from this architecture:

1. Your page competes at the chunk level, not the page level. A 2,000-word article is not one candidate; it is roughly 8-12 candidates of uneven quality. One self-contained, fact-dense chunk beats eleven diffuse ones.
2. Context does not travel between chunks. If chunk 3 says “the study” and only chunk 1 names which study, chunk 3 is nearly useless to the synthesizer. Every chunk must survive being read in isolation — the core idea behind what we call structural extractability, and a natural companion to the metrics used to score fact density and citation frequency.

Positional Retrieval Bias: Why the Opening Wins

Position inside the document skews retrieval. Passages near the top of a page are selected more often than passages of equivalent quality near the bottom, and the effect is a property of the pipeline rather than of your writing.

The bias has three compounding causes:

• Truncation. Many crawlers and context assemblers cap how much of a page they ingest. Long pages get their tails cut off before embedding even happens.
• Introduction-query similarity. Openings tend to restate the topic in the same vocabulary users search with, so opening chunks naturally score higher on cosine similarity.
• Lost-in-the-middle effects. Even after retrieval, LLMs weight the beginning and end of their context window more heavily than the middle — the behaviour documented in Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” — further discounting mid-document passages.

The practical takeaway is blunt. A fact placed in your final third needs to be dramatically better than a competitor’s fact placed in their first third to be cited at the same rate.

Rewriting for the Inverted Pyramid, Step by Step

The inverted pyramid — conclusion first, evidence second, background last — was engineered for newspaper editors who cut stories from the bottom. RAG systems are that editor, automated and merciless. Here is the rewrite sequence we apply during audits:

Step 1: State the complete answer in the first 100 words

The opening block after your H1 should contain, in order: the direct answer to the title’s implied question, the single strongest number supporting it, and the named entity or source behind that number. Forty to eighty words is the sweet spot — short enough to sit inside one chunk, long enough to be quotable without trimming.

Step 2: Make every H2 section self-sufficient

Chunk boundaries frequently fall at headings, because parsers treat headings as natural split points. Treat each H2 section as a mini-article: restate the subject noun (not “it” or “this approach”), include at least one concrete figure, and avoid references that point outside the section. Question-phrased headings help twice over — they match conversational queries and they announce the chunk’s content to the similarity function.

Step 3: Repeat critical facts at controlled intervals

In narrative writing, repetition is a flaw. In chunked retrieval, a key statistic that appears once at word 1,800 exists in exactly one low-probability chunk. Restating your core claim — with varied phrasing — in the introduction, once mid-document, and once in the conclusion places it in three separately retrievable passages. Two to three placements is the ceiling; beyond that you drift into keyword-stuffing territory that both Google’s spam systems and LLM quality filters penalize.

Step 4: Convert buried prose facts into structure

Lists and tables survive extraction better than dense paragraphs because their boundaries are explicit. If a paragraph contains three comparable data points, it usually performs better as a table row set. This dovetails with the empirically tested content tactics collected in our reference directory of GEO research, where adding concrete statistics is consistently among the highest-yield edits.

Narrative Structure vs. Inverted Pyramid: What the Machine Sees

The honest caveat: narrative structure is not wrong everywhere. Opinion pieces, founder stories, and long-form essays earn links and loyalty precisely because they withhold. Reserve the inverted pyramid for the content you want retrieved — guides, comparisons, definitions, and data pages.

How to Audit Extractability on Your Own Pages

You do not need a vector database to approximate what retrieval sees. A ~40-line script gets you a usable diagnostic:

import re, textwrap
import trafilatura  # pip install trafilatura

CHUNK_TOKENS = 300          # typical retrieval chunk size
KEY_FACTS = [
    r"\d+(\.\d+)?%",        # your primary statistic
    r"inverted pyramid",    # your primary entity/concept
]

html = trafilatura.fetch_url("https://example.com/your-article/")
text = trafilatura.extract(html)
words = text.split()
# ~0.75 words per token -> 300 tokens ~ 225 words
chunk_size = int(CHUNK_TOKENS * 0.75)
chunks = [" ".join(words[i:i+chunk_size])
          for i in range(0, len(words), chunk_size)]

for pattern in KEY_FACTS:
    hits = [i for i, c in enumerate(chunks)
            if re.search(pattern, c, re.I)]
    first = hits[0] if hits else None
    depth = round(100 * first / len(chunks)) if hits else None
    print(f"{pattern}: chunks {hits} (first at {depth}% depth)")

Read the output against two thresholds. If your primary claim first appears after chunk 2, your opening is scene-setting rather than answering. If any load-bearing statistic lives only past the 60% depth mark, it is effectively invisible to retrieval and needs a second placement higher up.

Where to Start This Week

Do not rewrite your whole archive. Pull your ten highest-impression pages — the same Search Console shortlist you would use when working striking-distance keywords — run the chunk audit above, and fix only the openings: a 100-word answer-first block and one early restatement of the key statistic typically takes 20 minutes per page and captures most of the available gain. Measure AI referral traffic and citation appearances over the following 4-6 weeks before touching page bodies.

If you want the audit done for you — chunk mapping, positional scoring, and rewritten openings for every indexed page — that is exactly what the MarketLens Standard Audit delivers in Markdown you can hand straight to your writing tools.