Why Regional Acronyms Break Multilingual RAG, and a Dictionary Fixes It

A user types “BTO 组屋可以申请吗?” into a RAG system. The Chinese half is the easy part for a multilingual embedding model. The Latin half is the risk. “BTO” is three capital letters, and unless the model saw dense Singapore property text in training, it has little to anchor on. The English page explaining Build-To-Order public housing eligibility is sitting in the same index, yet the query vector can land far from it. Retrieval hands back plausible, wrong chunks, and the answer is confidently off.

The Cross-Lingual Vector Miss

Multilingual embedding models align languages through shared semantic structure. That works for “apartment” and “公寓”. It works poorly for a localized acronym, because there is little structure in it to align. “BTO”, “EC” and “ABSD” are compressed local knowledge. Unless the training corpus covered Singapore property text well, the model tends to treat them as opaque strings.

So the acronym ends up isolated. Its vector sits near other short capitalized tokens, not near the concept it names. Drop it into a Chinese sentence and the clustering you rely on for retrieval weakens. A Chinese query containing “ABSD” can pull back chunks that only look similar on the surface.

The usual response is to hope a stronger component will compensate: a bigger model, a higher top-k, a reranker. These help at the margins. But they treat a lookup problem as a probabilistic one, and a reranker cannot promote a chunk that never made it into the candidate set.

Lessons from Legacy Data Taxonomies

None of this is a new AI mystery. It is data normalization.

Integrations over regional property data face the same problem, with or without vector databases. Terms like EC, BTO and TOP need a strict taxonomy. If “TOP” means Temporary Occupation Permit in one system and something else in another team’s usage, search, reporting and CRM exports all break, because one token means different things. Someone has to own the dictionary.

RAG developers often skip that step because embeddings feel like they absorb mess. They do absorb some of it. But shorthand that a human in the region resolves instantly can be noise to a model trained mostly elsewhere. Normalize deterministically at ingestion, and the model gets input it can actually place.

The String Matching Trap

The naive fix is a key-value dictionary and str.replace. It will corrupt your data.

Replace “EC” with “Executive Condominium” and “DIRECT” becomes “DIRExecutive CondominiumT”. “ECHO” becomes “Executive CondominiumHO”. In a corpus full of English prose, substring collisions are everywhere.

The obvious repair is a regex with \b word boundaries, and in a bilingual corpus that fails more quietly. Python’s re module treats CJK characters as word characters for str patterns. In “BTO组屋” there is no boundary between “O” and “组”, so \bBTO\b never matches. The Chinese-context queries you set out to fix are exactly the ones that slip through.

Two options hold up:

• An Aho-Corasick automaton for fast multi-pattern matching, with a boundary check on each hit.
• A regex with explicit lookarounds, such as (?<![A-Za-z0-9])EC(?![A-Za-z0-9]), which asserts “not adjacent to another Latin letter or digit” and ignores CJK neighbours.

Either way the rule is the same. Expand a local acronym only when it appears as a discrete token in its own script.

Implementing the Dictionary Override

Intercept in two places, the query and the chunk text, before either reaches the embedding endpoint. Normalize only one side and you create an asymmetry that is painful to debug.

A bilingual English and Chinese agent system, for deal qualification say, can pass regional terms through a custom dictionary override before vectorization. “BTO” becomes “Build-To-Order public housing flat”. “EC” becomes “Executive Condominium”. “ABSD” becomes “Additional Buyer’s Stamp Duty”. Every expansion is standard English, the form multilingual models are most likely to have seen often. That gives the model a better chance of placing the vector correctly, so the Chinese query meets the English chunk where it should.

The dictionary has limits. Ambiguous terms like “TOP” can’t be expanded blindly. Give them context rules, or leave them unmapped and log them. Expansion also lengthens chunks slightly, which matters if you are close to your token limits.

Compare this with an LLM translation pass and the cost is lopsided. A local Aho-Corasick lookup is in-process string work. An LLM pass adds a network round trip and inference time to every call, and it can hallucinate. It may expand an acronym confidently and wrongly, which is worse than leaving it alone. A dictionary entry gets reviewed once, when someone adds it. An LLM’s output rarely gets reviewed at all.

The Token Tax and Dual Vector Spaces

The latency gap is structural. An LLM pass is network-bound inference, while a dictionary lookup is in-process matching. No benchmark is cited here, so measure both in your own deployment, with your provider region and payload sizes, before you assign latency budgets.

There are two brute-force alternatives. Both cost more.

Dual vector spaces, one English and one Chinese, roughly double your storage and re-embedding work. Every content update has to be synchronized across both, and every ranking decision has to reconcile two scoring distributions. The bill grows with the corpus.

On-the-fly LLM translation charges tokens on every query, adds the latency described above, and opens a new failure surface. You pay continuously, on traffic you can’t predict.

Normalizing before vectorization avoids both. You keep one index, one embedding model and one set of distances. What it costs you is a dictionary that someone maintains: a text file under version control, with a review process.

What to Build

If you ship a RAG app for a region with its own shorthand, put a deterministic preprocessing stage in front of the embedder and treat the dictionary as a first-class artifact. Test it against the collision cases (“DIRECT”, “ECHO”) and the CJK-adjacent cases (“BTO组屋”). Log every term that reaches the embedder unmapped, because that log is your backlog.

Embedding models will probably get better at regional text. The dictionary should stay useful anyway, because it encodes decisions about your domain that a general model can’t make for you.