How to Measure RAG Accuracy Before You Launch
RAG accuracy is two scores, not one. See how to build a gold question set, measure both halves, and set release gates that hold.
A multilingual AI chatbot answers a Hindi question from English documents. Here is the architecture, the testing method and a safe rollout plan.
A multilingual AI chatbot answers a question in the language the person used, even when your documents sit in English. That single idea changes who can use your knowledge base.
Most Indian companies write policies, SOPs and product notes in English. Yet the shop floor, the branch counter and the field team think in Hindi, Marathi, Tamil or a mix of two. So the gap is not knowledge. The gap is language.
Four problems sit under the surface. Each one breaks a different part of a normal search stack.
A keyword index fails on all four. Therefore the answer has to come from meaning, not from matching letters.
Picture a field engineer who types “warranty claim ka process kya hai”. Your warranty SOP says nothing in Hindi. It says “raise a claim within 30 days of the fault”.
No word overlaps between the two lines. Still, they mean the same thing. So the system must place both sentences close together in meaning, and then read the English page to write a Hindi reply.
That is the whole job. Everything else is engineering detail around it.

The trick is a multilingual embedding model. It maps text from many languages into one shared space, where meaning decides the position rather than spelling.
So “chutti ki policy” lands next to “leave policy”, even though the two share no letters. Your documents go in once, in whatever language they were written. Questions then arrive in any language and still land nearby.
We use Cohere Embed Multilingual on AWS Bedrock with pgvector for this, running in the Mumbai region. If the idea of vectors is new, start with our primer on vector search.
First stage search is fast but rough. It usually returns ten to fifty candidate passages, and the best one is rarely on top. A reranker then reads the question with each passage and scores the pair properly.
This step matters twice as much across languages. Without it, English questions get sharp results while Hindi questions get vague ones, because the first stage drifts more on translated meaning.
Pair the reranker with keyword search for names, codes and part numbers. Our note on hybrid search explains why both halves are needed.
Clean Hindi is easy. Hinglish is where most demos fall apart, because people type Hindi words in English letters and switch mid sentence.
Real examples from support logs look like this: “salary slip download karna hai”, “kal ka shipment cancel kar do”, “PF withdrawal ke liye kya documents chahiye”. Notice how each line mixes both languages and skips grammar.
Three habits help here. Keep a transliteration step so common Hindi words in Latin letters map to their Devanagari form. Also collect 200 real Hinglish lines from your own tickets. Then test against those lines every week, since this is the traffic you will actually get.
Retrieval solves half the problem. Generation solves the other half, and the rule is simple: reply in the language the person used.
If they asked in Hinglish, reply in plain Hindi written in Latin letters, because that is what they read comfortably. If they asked in Tamil, reply in Tamil. Never answer a Hindi question in English just because the source page was English.
Keep the terms of art untouched though. Words like PF, CTC, GST and SKU should stay as they are, since translating them only confuses people.
Translation is not dead. It is simply the wrong default.
Translating every document into eight languages is expensive, and it goes stale the moment a policy changes. Instead, translate at three points only: the answer, the short snippet you show as proof, and any content your legal team must publish in a local language.
That keeps one source of truth in English, while people still read in their own language.
| Question type | How many | Why it is there |
|---|---|---|
| Common questions in the local script | 60 | Covers the daily traffic |
| Hinglish and mixed sentences | 20 | Catches transliteration gaps |
| Short forms and local slang | 10 | Real people type this way |
| Questions with no answer in your docs | 10 | Checks that the bot refuses politely |
Write the ideal answer beside each question. Then run the set before every release, so a fix for Tamil never quietly breaks Hindi.
| Metric | Target | Read it as |
|---|---|---|
| Recall at 10, per language | Above 90 percent | Search finds the right page at all |
| Gap between best and worst language | Under 8 points | Language fairness |
| Grounded answers | Above 95 percent | Every line traces to a source |
| Language match | Above 98 percent | Reply uses the language of the question |
| Polite refusals | Under 8 percent | Coverage of your content |
The blended average is the trap. A strong English score hides a weak Marathi one, and the people you built this for are the ones getting poor answers.
A web widget suits office staff. Field teams and factory floors live somewhere else, so meet them there.
WhatsApp usually wins in India, since everyone already has it and voice notes work well for people who type slowly. Our guide to a WhatsApp AI chatbot for Indian business covers the setup side.
Voice comes next, especially for drivers and technicians. Same index, same permissions, different surface.
| Stage | Typical time | Cost driver |
|---|---|---|
| Embedding the question | 40 to 80 ms | Per query, very cheap |
| Vector search | 30 to 90 ms | Index size and machine class |
| Reranking 25 passages | 120 to 250 ms | Number of candidates |
| Writing the answer | 500 to 900 ms | Model size and answer length |
Indexing costs sit mostly in the first load. After that, only new and changed documents cost anything, so monthly spend stays flat and predictable.

Start with two languages, not eight. English plus the language of your largest team is the right pair. Then translate the test set, score both, and fix the weaker one before you add a third.
Announce each language to a small group first. Collect their complaints for a week, because early users tell you which words your model does not know.
Teams translate the whole document library, then discover the policy changed. Others test only in clean Hindi and get surprised by Hinglish. Some hide the sources, so nobody trusts the answers.
The costliest mistake is quieter. A team ships one language well, calls the project done, and never measures the rest. Six months later the shop floor has gone back to calling the HR desk.
If your content lives in policy documents, our piece on an HR policy chatbot shows what good coverage looks like.
Language models cannot rescue a messy drive. So spend the first week on content, not on code.
Start by finding the live version of each policy. Most teams hold four copies of the leave policy, and only one is current. Then delete or archive the rest, because a multilingual AI chatbot will happily quote a 2019 draft otherwise.
Next, give every document a clear title and an owner. Titles carry a lot of meaning during search, so “Leave policy 2026, India” beats “final_v3_updated”.
Finally, break long PDFs at their headings rather than at fixed lengths. A clean split keeps a rule and its exception in the same passage, which is exactly what the reader needs.
Access rules are easy to forget in a language project, yet they decide whether the tool can touch HR or finance content at all.
The rule is simple. Retrieval filters by the person first, and only then by meaning. A branch employee asking in Marathi should see exactly what the same employee would see in English.
Log every answer with the documents behind it. That log answers the audit question later, and it also shows which teams lack access to content they clearly need. Our guide to an enterprise knowledge chatbot covers this layer in more detail.
Be honest about the limits before you promise anything.
It cannot answer from documents you never wrote. If the process lives only in a senior colleague’s head, the bot will refuse, and it should.
It also cannot settle contradictions. When two policies disagree, the tool can show both, yet a person still has to decide which one wins. Similarly, it will not fix a policy that nobody understands in any language.
Treat those refusals as a gift. Each one names a gap in your documentation, so review the refusal list every month and write what is missing.
Intellowork indexes your existing files once and serves every language from that single index. Multilingual embeddings, reranking for fairness and grounded answers come as standard, not as an add on.
Permissions follow the person, so a branch employee sees branch documents only. Everything runs in your own cloud account in Mumbai, which keeps data in India for DPDP purposes.
Want to see it answer in Hindi from your own English SOPs? Book a walkthrough and bring twenty real questions from your ticket queue.
Modern embedding models cover 90 or more. Quality varies though, so treat each language as a separate rollout with its own test set.
No. Keep one English source of truth and translate the answer instead. That way a policy change reaches every language on the same day.
Yes, with a transliteration step and real Hinglish examples in your test set. Without those, expect weak results on exactly the traffic you get most.
Hindi, Bengali, Tamil, Telugu, Marathi and Gujarati perform well. Smaller languages and dialects still need more testing and a human review loop.
Yes, since language has nothing to do with where data sits. Run the stack inside your own cloud account, keep the region in India, and log every access.
Two to six weeks for two languages, depending on how clean your documents are. Content clean up takes longer than the build in most projects.
The short version: a multilingual AI chatbot works when meaning drives search, reranking keeps languages fair, and the reply comes back in the language the person used. Get those three right and your English knowledge base finally serves everyone.
RAG accuracy is two scores, not one. See how to build a gold question set, measure both halves, and set release gates that hold.
A voice AI agent answers support calls from your own documents. See the stack, the latency budget and a safe rollout plan.
A repeatable way to test an AI chatbot before launch: build a golden question set, score retrieval and grounding separately, and…
Tell us what you are trying to ship. We will tell you what it actually takes — scope, sequence and the risks worth knowing about before you commit budget.