EmbeddingGemma 2 驅動瀏覽器應用，讓用戶以 Telugu 搜尋英文保險文件

EmbeddingGemma 2 puts 100+ languages into one vector space, and the text-only weights are 165 MB in Google's LiteRT packaging. That combination has an obvious product hiding in it, and nobody is selling it: search your own English documents in the language you actually think in.

This is that product, running entirely in a browser tab.

The gap

Every offline-language app translates. None of them retrieve. So if the insurance policy, the discharge
summary and the tenancy agreement are all in English, and the person who needs an answer reads Telugu,
the options are: translate the whole document (lossy, and you still have to find the paragraph), or ask
someone else to read it for you.

Retrieval across languages is a different job from translation, and it is the one that actually answers
the question. "గది అద్దె రోజుకి ఎంత" does not need the policy translated. It needs page 7.

What it does

1. Download the model once, 300 MB, cached by the browser.
2. Prove the model loaded correctly before it is trusted with anything.
3. Index your PDFs locally, keeping page numbers.
4. Ask in Telugu, Hindi, English or romanised Tenglish. Get ranked pages with the surrounding text.

Two real documents ship with it so the demo works on first visit: a 29-page Arogya Sanjeevani policy
wording from HDFC ERGO, and a public 3-page discharge summary sample from University Health Network.

The mechanics that mattered

Task prefixes. Queries get task: search result | query:, documents get title: none | text:.
Measured on twelve clean passages: 12/14 with the prefix, 12/14 without, 11/14 with the question-answering
prefix. On this data the prefix made no reliable difference, so it stays because it is documented and
costs nothing, not because it was proven here.

Quantization is not free. Same twelve passages, same queries:

• q8: 8/10 correct at rank 1
• fp16: 8/10
• q4f16: 6/10

The browser build started on q4f16 because it is 150 MB instead of 300 MB. That cost two correct
answers out of ten, on Hindi and romanised queries specifically. The shipped build is q8.

Chunk boundaries ate the answers. At 1200 characters, the sentence "subject to maximum of Rs.5000
per day" sat at the tail of one chunk and the consequence at the head of the next, so the top hit was
the paragraph after the answer. Cutting to 800 characters with 250 overlap, and stitching a hit with
its neighbours before showing it, moved rank-1 accuracy from 6/18 to 8/18 on the same corpus.

The model finds the right page more often than the right paragraph. Chunk-level rank 1 is 8/18.
Page-level rank 1 is 12/18 on the 18-query set, and 4/6 in the browser. So the interface shows pages,
not snippets pretending to be answers.

English was worse than Telugu. On the full corpus, English questions retrieved the definition
page rather than the benefit page: ask about AYUSH cover, get the page that defines an AYUSH hospital.
That is a sensible semantic match and a useless answer. It is the clearest argument for a reranking
step, and it is not in this build.

What it costs

On an M2 mini with Chrome and WebGPU, a 29-page policy:

• model download plus init: 201s
• indexing 153 chunks: 26s, about 5 chunks/s
• the index itself: 459 KB, 3 KB per chunk at 768 dimensions
• a query: 118 to 967 ms to embed, 32 to 270 ms to rank

And the number that decides whether this is useful: across six queries in Telugu script, Hindi,
romanised Tenglish and English, the answer was on one of the five pages shown 6 out of 6 times. It was
on the first page 4 out of 6 times.

That gap is the honest shape of the thing. It is a page finder, not an answer machine.

A detail that makes the 6/6 less magical and more useful: page 21 kept winning, and page 21 is the
policy schedule, the one page that lists every benefit next to its limit. The model was doing what a
person does with a policy, which is to find the summary table first.

Limits

• Telugu script is weaker than romanised Telugu and Hindi. On clean passages: Hindi 3/3, Telugu 1/3.
• No OCR. A scanned PDF gets told it has no text layer instead of being silently ignored.
• Text only. The vision and audio encoders exist in the 440M and 740M variants, and are not wired in here.
• 300 MB before first use, and a 26 MB WASM runtime if the browser has no WebGPU.
• This is a browser app on a phone, not an APK. An APK means MediaPipe Tasks or LiteRT plus an Android toolchain, which is the next build.

The privacy claim, and how to check it

No server. The model comes from Hugging Face once, then every embed, every vector and every answer is
computed in the tab. Playwright listening to every network request confirms it: during a query, zero
requests.

One thing that did not survive that check: the first build pulled the ONNX Runtime WebAssembly loader
from jsDelivr. Two requests at load time to a CDN nobody consented to, in a product whose whole argument
is that nothing leaves the device. The runtime is now bundled and served from the app's own origin.

Try it

Code & more: https://www.dailybuild.xyz/project/289-cross-lingual-brain