You Asked in English; Your Note Was in Another Language; the AI Never Found It

Ask a question in English, and an assistant searching notes you wrote in Vietnamese, Spanish, or Arabic can miss them entirely — not because the notes are gone, but because keyword search shares no tokens across languages and default embeddings lean English. The fix is three habits you control: tag each note's language, verify your model, or store a translated key.

Researchers have now measured the gap. In The Cross-Lingual Cost, a 2025 study of Arabic-English retrieval, "performance degrades most in cross-lingual settings where the user and document languages differ, with drops that can exceed 40% compared to same-language configurations" ¹. A 2026 preprint, All Languages Matter, found the bias baked into the ranking step: with a widely used reranker, "more than 70% of the top-5 retrieved documents, averaged across 13 languages, originate from English and the query language alone" ². This is a how-to, not a lament. The mechanism is knowable, and so is the fix. The rest of this guide diagnoses why your note is invisible, then gives you a five-minute and a thirty-minute version of the same habit — plus a canary test, so you never have to assume your assistant crosses languages. You test it instead.

Why your assistant swears the note isn't there

Two failures stack. Keyword search matches surface strings, so a query in English and a note in Arabic share nothing to match. Semantic search maps meaning into vectors, but default embedding models cluster English text and push a translation's neighbors apart. The note exists in your vault; the retriever never surfaces it.

The measurements are blunt. In the Arabic-English study, "retrieval Hit@20 decreases by 42% on the Legal benchmark and by 33% on Travel, compared to their same-language counterparts" ¹ — and those retrieval declines carry through: "drops of 40% for Legal and 37% for Travel" in end-to-end accuracy ¹. The reranking preprint is blunter still: "Current [multilingual] RAG systems exhibit a pronounced language preference bias during the reranking stage, systematically favoring English and the original query language" ². A separate 2024 study puts it plainly — "English benefits from RALMs' selection bias and speaks louder in multilingual knowledge selection" ³.

Arabic-English is one language pair, but the mechanism is general. The wider a script and grammar sit from English — a different alphabet, a different word order, fewer training examples — the harder the model works to place a translation near its English counterpart, and the more the ranker falls back on the language it knows best. The English-anchoring result above was averaged across thirteen languages, not cherry-picked. If your notes mix a high-resource language with a lower-resource or non-Latin one, assume the gap is at least this wide until a canary test proves otherwise.

A hybrid of keyword and semantic search rescues a same-language vocabulary gap — "PTO" versus "annual leave" — which is why grep still beats a small vector index inside one language. That fix does not survive a language boundary, because keyword scoring has no tokens to match across scripts, and the semantic half inherits the English bias. The cost of writing notes in a non-English language is one problem; being unable to get them back is the other.

The one habit: make both languages reachable

The single discipline: never let a note live in a language your retriever cannot reach. Three interchangeable moves close the gap — a language tag in the note, a verified multilingual embedding model, or a one-line translated key beside the original. Any one works; together they are belt and suspenders.

The reason dedicated multilingual models exist is that the defaults align poorly. One open model, M3-Embedding, was built to "support more than 100 world languages" across dense, sparse, and multi-vector retrieval ⁴ — a direct response to what a Turing Institute study named as the root cause: "weak cross-lingual semantic alignment in embedding models" ⁵. You do not have to fix the model. You only have to give it a token it can match, in a language it was trained to place near your query.

Which of the three you reach for depends on what you control. If you own the notes, the translated key is the most reliable move: it survives model swaps, works for keyword and semantic search alike, and needs no infrastructure. If you own the pipeline, swapping in a verified multilingual model fixes every note at once. The language tag is the smallest move of the three — one field that makes the other two easier to automate later. Start with whichever you can do today, then add the others as insurance.

The five-minute version

In five minutes you can make one note bilingually findable. Tag its language, add a single translated line that carries the title and a few keywords, then run a canary test: ask in your query language and confirm the note comes back. If it does, repeat the pattern across the vault.

1. Tag the language. Add a lang: field to the note's frontmatter (lang: vi). This alone lets any tool filter or route by language later.
2. Add a translated key. One line that restates the title plus three or four keywords in the language you actually search in. Not a full translation — a retrieval handle.
3. Check the model's language list. Open your embedding model's published documentation and confirm your language is named. If it is not listed, no tag will save you.
4. Run a canary test. Ask in English (or whatever your query language is) for the note you just tagged. Confirm it returns in the top few results.
5. Re-index. If your assistant caches an index, rebuild it so the new key is embedded.

A tagged, keyed note looks like this — plain Markdown, no tool-specific syntax:

---
title: "Cách sao lưu ghi chú của tôi"
lang: vi
key_en: "How to back up my notes — backup, export, sync, restore"
tags: [backup, ghi-chu]
---

# Cách sao lưu ghi chú của tôi

...nội dung ghi chú bằng tiếng Việt...

The key_en line is doing the work. When you later ask "how do I back up my notes," the English keywords give both keyword search and the embedding model something to match — even though the body is Vietnamese.

One caution on step three: "supported" and "well-supported" are not the same claim. A model can name a hundred languages and still rank a low-resource one poorly, because coverage in the training data is uneven. Treat the published list as necessary, not sufficient — the canary test is what tells you whether your language actually retrieves, not the marketing page.

The thirty-minute version

The thirty-minute version hardens the habit across the whole vault. Standardize one multilingual model for both queries and documents, embed everything into a single index, add a translated key to every note that matters, and keep a standing canary set — one note per language — that you re-run whenever the model changes.

Three details make the difference between a tidy vault and a searchable one:

• One model, both sides. Embed your query and your documents with the same multilingual model, into one shared index. Two models means two coordinate systems, and a cross-language match becomes an accident rather than a design.
• Keys where it counts. You do not need a translated key on every grocery list. Add one to the notes you would be angry to lose — the references, the decisions, the how-tos. Ten minutes of keying buys years of recall.
• A canary set you keep. Write one deliberately bilingual note per language you use, each with a known answer. After any model swap or app change, ask the same questions. If a canary stops returning, your retriever quietly stopped crossing that language — and you know before a real note goes missing.

Re-test on a schedule, not only after a change you noticed. Hosted models get updated underneath you without a version bump, so a canary set you run monthly catches a silent regression before it swallows a note you needed.

If a canary fails, resist the urge to translate the whole note. Add the translated key first and re-test — most misses close with that one line. If the key does not help either, the problem is upstream: your model likely does not cover that language well, and no amount of tagging rescues a language the embeddings never learned. That is your signal to switch models, not to rewrite notes.

Strong multilingual models genuinely narrow the gap; some may close it for your languages entirely. The discipline is not to distrust them — it is to verify rather than assume, because the failure is silent and the note you lose is your own.

Common mistakes

Most cross-language retrieval failures trace to four assumptions. That modern models are multilingual enough to skip testing. That keyword search reaches across languages. That any embedding model will do for both query and documents. And that a hosted assistant keeps your text on your device. Each one quietly hides a note.

• Assuming multilingual, never testing. Even strong rerankers leave room on the table: on one benchmark, "standard rerankers underperform the oracle by nearly 20%" ². The models "heavily prioritize documents based on surface-level language matching or dominant language priors (predominantly English), rather than assessing semantic relevance equitably" ². Run the canary.
• Trusting keyword search across scripts. BM25-style search has no shared vocabulary between English and Arabic or Vietnamese. It is not weak across languages — it is blind.
• Mismatched embedding models. Documents embedded by one model and queries by another rarely land in the same semantic space. Use one model for both.
• Translating the whole note. A full machine translation is lossy and doubles your maintenance. A one-line key is lighter and more precise.
• Forgetting where the text goes. If your assistant uses a hosted model, the note text you ask about leaves your device and travels to that provider. That is a privacy fact, not a retrieval bug — but it belongs in the same decision.

How this works over notes you own

These fixes are disciplines you own, not features you rent. A language tag and a translated key are plain text; they live inside the Markdown file and travel with it to any tool. When your notes are local-first and stored as open Markdown on your own device, the habit is portable — it outlives whichever assistant reads it.

Because the key is just text, you can add it in bulk. A short script can walk your vault, read each note's language, and stub a key_en: line for you to fill in or machine-translate — turning a per-note chore into a one-time pass. A note format you can read with grep is a note format you can repair with a loop.

That portability is the point. The lang: field and the key_en: line are not a proprietary schema; they are two lines any editor, script, or search index can read. Keep your notes as files you control, and the work you do to make them findable is never trapped inside one app's search box. The honest caveat still holds: any assistant that reaches your notes through a hosted model — bring-your-own-key or otherwise — sends the text you ask about off your device to that model. That is true even when your notes themselves stay on your device: the moment you ask a question, the passage the assistant reads travels with it. Decide what you send with that in mind.

Frequently Asked Questions

A few questions come up whenever notes span more than one language and an assistant has to find them. The short version: retrieval, not storage, is where bilingual notes disappear, and every fix below makes the note reachable from the language you actually search in.

Why can't my AI find my notes in another language? Because retrieval, not storage, fails at the language boundary. Keyword search shares no tokens between, say, English and Vietnamese, and default embedding models cluster English, so a translated note's meaning lands far from your English query. The note is there; the retriever never ranks it. Cross-lingual drops can exceed 40% versus same-language search ¹.

Does keyword search work across languages? No. Keyword and BM25-style search match surface strings, and two languages share almost no surface tokens — different words, often different scripts. Within one language a keyword-plus-semantic hybrid rescues vocabulary gaps, but across a language boundary the keyword half has nothing to match, so it contributes no cross-language recall at all.

Do I need to embed documents and queries with the same model? Yes. Embed both your notes and your questions with the same multilingual model, into one shared index. Different models produce different vector spaces, so a query vector and a document vector that should be neighbors end up in incompatible coordinate systems, and a correct cross-language match becomes luck rather than design.

How do I find the best multilingual embedding model for RAG? Read the model's published language list first and confirm your languages are named — coverage is not universal. Open models built for breadth exist: M3-Embedding was designed to "support more than 100 world languages" across dense, sparse, and multi-vector retrieval ⁴. Then verify empirically with a canary note per language rather than trusting the marketing.

Why does my vector search only return English results? Because rerankers carry an English bias. A 2026 preprint found "more than 70% of the top-5 retrieved documents, averaged across 13 languages, originate from English and the query language alone," with roughly 60% concentrated in English and the query language ². Tag each note's language and add a translated key so non-English notes carry a token the ranker will surface.

How do I build cross-lingual search over my own notes? Standardize one multilingual embedding model for queries and documents, embed everything into a single index, add a one-line translated key to every note worth finding, and keep a canary note per language you re-test after any model change. Tag, key, verify — in that order. The habit is plain text and moves with your files.

Test your retriever the way you test a backup — with a note you deliberately hid in another language, and a query in the language you think in. A note you cannot retrieve was never really filed; it was only stored. The language you wrote it in should not decide whether you ever see it again.

When your notes live as plain Markdown on your own device, the language tag and the translated key travel with the file — mnmnote.com.