Bury It at the Bottom of a Long Note and the AI Won't Find It

Front-load the one line that matters, and split a note before it grows long. A text-embedding model reads the top of a document far better than its tail, so a fact buried at the bottom of a long note may never be retrieved — no matter how clearly you wrote it.

This is not a prompt problem or a model-quality problem. It happens one stage earlier, when the retriever turns your note into a vector and decides whether the note is even worth showing the model.

João Coelho and colleagues measured the effect at ACL 2024 and gave it a name: dwell in the beginning. After training, they found, the model "already generates embeddings that better capture the beginning of the input content, with fine-tuning further aggravating this effect."¹² The step that makes a retriever good at everything else makes it worse at reading the bottom of a long document.

The bias is baked into how retrieval embeddings are built, so you cannot prompt your way out of it. The fix is a plain-text discipline you fully control: keep one idea per note, put the load-bearing line up top, and break a long note apart before you ever index it.

Why a buried fact never gets retrieved

A dense retriever compresses your whole note into a single vector, then compares it to your question. Because that vector over-weights the note's opening, a fact near the bottom is faintly represented — it barely moves the vector, so the note ranks below others and never reaches the model. Coelho et al. call this the dwell in the beginning effect.¹

The symptom is disorienting the first time you hit it. You ask, "what's the deadline for the Atlas migration?" The date is right there — you typed it into the project note last week — but the assistant says it cannot find it. You open the note, scroll to the bottom, and there the deadline sits, in a line you added after three hundred lines of standup logs. The text never left. Its weight in the note's vector did.

They did not infer the effect from one benchmark score. They physically moved the relevant passage to different positions inside a document and re-measured. "When the relevant passage is moved to the beginning of the document, the performance increases when compared to the default setting," they report, and "if the passage is moved anywhere else, the performance drops."¹ Same words, same document, same question — only the position changed.

The bias is visible at the embedding level too, below any end-task score. Looking directly at cosine similarity, the authors find "the similarity values tend to decrease when the position of the sub-string moves from the beginning."¹ The further down the page a sentence sits, the less the note's vector reflects it. Their conclusion is blunt: the embeddings "favor information located at the beginning of the input, leading to decreased performance when relevant information is elsewhere in the document."¹

How long is "long"? The retriever they studied was trained "with a context length of 2048 tokens" — a few thousand words.¹ Past that, a note's far end competes for a shrinking share of a single vector, and the tail thins out. This is why a running daily log is the worst possible shape: the newest, most-queried lines are always the ones sitting at the very bottom.

Chunking does not save you either. Many personal-RAG setups split a note into pieces before embedding, but the same positional bias repeats inside each chunk — the top of every chunk is favored over its end — and a split made mid-thought can orphan a heading from the lines it labels. Where the chunk boundaries fall is its own lever, covered in how you structure a note is its AI retrieval.

This is not "lost in the middle"

"Lost in the middle" is a different, later stage. That effect — from Nelson Liu and colleagues at TACL — is about text you have already pasted into the model's context window, not about whether a note gets pulled in. It governs how the model reads what it was handed, not which notes reach it in the first place.

In their words, "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."³ That is a symptom of the reading window. Dwell-in-the-beginning happens one step earlier, at retrieval: whether a note gets selected at all.

We covered the generation-stage effect — where a note sits among many in the prompt — in where you put a note in the context changes the answer. This post is about position inside one single note when it is embedded. Two stages, two failure modes, two fixes.

flowchart TD
  A[Your long note] --> B[Embedding step<br/>indexes the text]
  B --> C{Where does the<br/>key fact sit?}
  C -->|Near the top| D[Well represented<br/>likely retrieved]
  C -->|At the bottom| E[Under-represented<br/>may be skipped]
  D --> F[Retrieved notes go<br/>to the model]
  E --> F
  F --> G[Model reads the context<br/>and writes the answer]

Figure: The two positional-bias stages of note retrieval. "Dwell in the beginning" happens at the embedding step (B–E): a fact near the top is well represented and likely retrieved, a fact at the bottom is under-represented and may be skipped. Only notes that survive that step reach the model (F–G), where the separate "lost in the middle" effect governs how the model reads them.

The distinction matters because the two problems have opposite fixes. If your note was never retrieved, reordering your prompt cannot help — the fact was never in the room. You fix retrieval by changing the shape of the note before it is indexed, which is exactly the part you own.

The five-minute fix

The fastest version is a habit, not a project — front-load the answer and cap the length. You can apply every step below while you write, with no tooling, no plugins, and no re-indexing pipeline to run afterward. It changes what you type, not what you install.

1. Write the load-bearing line first. The one fact you will later ask about goes in the first sentence or the first bullet — not the meeting's third tangent, not a footnote at the bottom.
2. State the conclusion, then the discussion. Decisions, owners, dates, and definitions belong at the top. The narrative that led there can follow.
3. Cap a note at one idea. If you can title it with two nouns joined by "and," it is probably two notes.
4. Split a daily log by entry, not by day. A month-long running note is one giant document with thirty tails. Thirty dated notes each have their own well-represented top.
5. Repeat the key term near the top. If the answer is a project code or a person's name, make sure it appears early, not only in a closing line.
6. Move the appendix out. Long reference dumps at the bottom of a working note push the working content downward. Link to them instead.

None of this asks you to write worse notes. It asks you to lead with the point — which is good writing anyway.

The thirty-minute version

Set aside half an hour and pass over the notes you actually query. You are converting long, accreting documents — daily logs, meeting dumps, project files — into focused notes whose openings carry their weight. This is where the compounding payoff lives, because these are the exact shapes a personal RAG handles worst.

Start by finding your longest notes and reading only their bottom third. Anything load-bearing down there is a candidate to promote or to split off. To decide what counts as load-bearing, ask what you would later type into a search box: a decision, a definition, a name, a date, a number. That is the line to lift to the top. The surrounding narrative can stay below it — it is context, not the answer. Then apply a before-and-after you can copy:

# BEFORE — one long note, key fact buried at the bottom
# Project Atlas — running log
- 2026-03-02 kickoff call, intros, scheduling
- 2026-03-09 scoping, open questions about the API
- ... (weeks of entries) ...
- 2026-05-18 DECISION: we ship read-only in v1; write access is deferred

# AFTER — split, with the load-bearing line on top
# Project Atlas — decisions
DECISION (2026-05-18): v1 ships read-only. Write access deferred to v2.
Reason: auth scope not finalized. Owner: platform team.

# Project Atlas — log 2026-05
- 2026-05-18 decision recorded (see: Project Atlas — decisions)

The "after" note leads with the answer, names the terms you would search for, and stays short enough that its vector reflects the whole thing. When you later ask "what did we decide about write access?", the decisions note is well represented at exactly the words you used.

Meeting notes reward the same flip. Most people type them chronologically — attendees, agenda, discussion, and finally the decision — which buries the one line anyone ever searches for at the very bottom. Invert it. Put the outcome, the owner, and the date in the first two lines, then let the discussion follow underneath:

# Standup — 2026-05-18
OUTCOME: Ship read-only in v1. Owner: platform team. Next review: 2026-06-01.
- discussion: auth scope still open, deferred write access
- attendees, agenda, side threads ...

Then verify it. Do not trust that the split worked — test it the way you would test any change. Drop a distinctive marker line near the bottom of a note and ask your assistant to find it; if it cannot, the tail is under-represented. That canary technique has its own walkthrough in bury a canary in your notes to test your RAG.

One caution while you reshape: retrievers narrow this gap over time, so do not overcorrect into a vault of one-line fragments. A note still needs enough context to mean something on its own. The target is focused, not tiny — one idea, its key terms up top, and only the supporting detail that idea actually needs.

Common mistakes

• Trusting that "it's in there" is enough. The AI is not lying when it misses a fact you can see. The text exists; its representation in the note's vector is faint. Presence is not retrievability.
• Fixing the prompt instead of the note. Reordering or re-wording your question cannot surface a note that was never retrieved. The lever is the note's shape at index time, not the query.
• Treating "lost in the middle" as the whole story. That is the generation stage. If retrieval already dropped the note, the model never sees the middle to lose.
• Letting one note grow forever. A never-split daily log is the single worst shape for this effect — a long document whose newest, most relevant lines sit at the very bottom.
• Re-indexing without re-shaping. Rebuilding your vector index over the same long notes changes nothing about their shape. The embedding still favors each note's opening — you have only re-encoded the same bias more efficiently.
• Assuming a bigger context window fixed it. Longer contexts and better retrievers narrow the gap, but the direction still holds as of 2026: long-note tails are fragile at retrieval time. Do not bet a critical lookup on it.

How this works when you own your notes

The fix depends on one thing: the notes have to be yours to reshape. When your notes are plain-text Markdown files stored locally on your own device, splitting a long note, promoting a buried line, or re-titling a file is a direct two-second edit — no export, no lock-in, no vendor indexer to wait on.

That is the discipline this whole post asks for, and open Markdown is what makes it cheap. A closed app can bury your text inside a format you cannot open; a Markdown file is the same on disk as it is on screen, so the shape you give a note is the shape the retriever sees.

Plain text also keeps the check honest. You can open any note and read its actual first line — the line the retriever weights most — instead of guessing what a closed app decided to store. When the file on disk is exactly what gets indexed, front-loading is something you can see and verify, not a setting buried three menus deep.

MNMNOTE keeps notes as plain Markdown on your device, works offline, and needs no account — so the structure of your notes is always something you can inspect and change. One honest caveat: this discipline improves retrieval, the step where a note is found. If you run AI over your notes, your notes stay on your device, but the text you choose to send goes to whatever model provider you point it at with your own key. Shape the note well, and the fact is at least there to be found.

Frequently asked questions

Why does my AI miss information that's clearly written in my note? Because the retriever embeds the top of a long note far better than the bottom. A fact near the end barely registers in the note's vector, so the note ranks low and never reaches the model. The words are present; their representation is faint. Coelho et al. name this the "dwell in the beginning" effect.¹

Why isn't my RAG retrieving the right chunk? Often it is not which chunk but where inside it the answer sits. Coelho and colleagues moved the same passage around a document and found performance rose only when it was at the beginning and "drops" everywhere else.¹ Position within the note, not just note selection, decides retrieval.

Does the length of a document affect embedding quality? Yes. Long inputs dilute the tail. The authors stress "the importance of considering the quality of embeddings for long inputs, particularly in contexts where effectively capturing the entire sequence is essential."¹ A shorter, focused note lets its vector reflect the whole thing.

Is "lost in the middle" the same as retrieval failing? No. "Lost in the middle" is the generation stage — how a model reads text already in its context window, where accuracy "significantly degrades" for information in the middle.³ Dwell-in-the-beginning is earlier: whether the note is retrieved at all.

How should I split my notes for better retrieval? One idea per note. Split before a note gets long, front-load the load-bearing line, and break daily logs into dated entries rather than one running document. Each short note then has a well-represented top instead of a buried tail.

Isn't this just one small model on a web benchmark? It was measured on a dense retriever trained "with a context length of 2048 tokens" over the MS-MARCO web-document collection¹ — so treat the note-vault mapping as an analogy, not a proof about your setup. But the direction is corroborated: a 2026 preprint reports that "dense retrieval models exhibit positional bias: retrieval effectiveness degrades when relevant information appears later in a passage."⁴

Doesn't the benchmark already put answers early? It does, and the authors say so — in MS-MARCO the relevant passage tends to appear early, "with the median starting position at 746 characters."¹ That is why they ran the controlled experiments that physically move the passage: those isolate the positional bias from the corpus's own head-start rather than relying on it.

The words in your note are not the same as the note's representation. Lead with what matters, keep each note short enough to hold its own shape, and the AI will find the fact you already wrote down.

This method builds directly on the dwell in the beginning finding of Coelho et al.¹² — to keep it practical, write notes you can reshape in one edit.

The plainest way to own the shape of your notes is to keep them as plain-text Markdown on your own device, and mnmnote.com does exactly that.