Multilingual RAG for Armenian, Russian and English Content

Multilingual RAG is not one English retrieval system with a translation step at the end. The language in which a user asks, the language of the governing source, the way documents are analysed and the language used in the answer all affect whether retrieved evidence is appropriate. A plausible answer can still be wrong if it silently crosses a language or version boundary.

This guide addresses the technical question of multilingual RAG for Armenian, Russian and English content. The broader decision to build and operate a RAG product belongs to the RAG systems service. Teams that need an architecture review can frame the work through an AI engineering brief, rather than using this article as a substitute for a commercial service page.

Start with a language contract, not a language switch

Record language as structured state at the request boundary. A useful request record contains the authenticated scope, a declared locale when the UI has one, detected language with confidence, requested output language, and the policy for mixed-language text. Detection is a signal, not authorization to rewrite the request.

The same discipline applies to sources. Each document or passage needs a source language, a canonical source ID, version, lifecycle, access attributes and a human-openable locator. If a document is a translation, retain the relation to the governing original rather than presenting both versions as interchangeable. In some workflows an Armenian translation is the approved source; in others the Russian or English original governs. That is a content-policy decision which retrieval should preserve.

{
  "requestLanguage": "hy",
  "outputLanguage": "hy",
  "languageConfidence": 0.93,
  "allowedSourceLanguages": ["hy", "ru", "en"],
  "translationPolicy": "show-governing-source",
  "scope": { "tenant": "example", "role": "support" }
}

Do not use a confidence value as a claim of quality. It is a routing input: a low-confidence or mixed-language request can ask for clarification, run a bounded fallback, or go to review.

ML-RAG-9 architecture: one evidence contract, explicit language lanes

The ML-RAG-9 workflow separates language handling from permissions and evidence. It can use shared infrastructure, but it does not erase language-specific behaviour.

REQUEST + authenticated scope + declared locale
  -> classify language and preserve confidence
  -> apply trusted scope, lifecycle and language policy
  -> retrieve eligible Armenian / Russian / English evidence
  -> normalize candidates without losing source language or locator
  -> select evidence for each material claim
  -> compose in requested language with visible source context
  -> evaluate route: answer | clarify | review | no-answer

At ingestion, preserve original Unicode text and structural boundaries. Normalisation may improve matching, but it must not replace the original passage that a reviewer needs to inspect. Store analysis configuration with the indexed version: tokenizer or analyser, embedding model, chunking policy, language fields and source version. Without that receipt, an operator cannot tell whether a retrieval regression came from a source update, an analyser change or a model change.

At retrieval, calculate eligibility before ranking. Tenant, role, document lifecycle and product scope remain deterministic filters. Language policy then decides whether the first search lane should be exact-language only, whether a permitted parallel lane is allowed, and how translated or bilingual sources are labelled. A vector similarity score must not grant access, override a superseded version or hide a language mismatch.

Component contracts that prevent silent drift

Request router. Keep raw input, declared locale, detected language, confidence and fallback decision separate. A user may write an Armenian sentence containing Russian product terms and English identifiers. That is not an error; it is a case the acceptance set must cover.

Document pipeline. Keep source language and writing system with each chunk. Do not assume all Cyrillic text is Russian, or that all Latin-script content is English. Preserve the canonical source and any approved translation relationship. Re-indexing a changed document should make the prior version ineligible according to the lifecycle policy.

Retriever and reranker. Pass language, source ID, version, locator and access attributes to every candidate. The hybrid search guide is relevant when exact identifiers and paraphrases require separate lexical and semantic signals; the language contract must survive both lanes and rank fusion.

Answer composer and UI. Draft only from selected evidence. If a statement is translated for the response, keep the original source title and a clear locator. Do not make a translated paraphrase look like a verbatim source quote. The citation workflow in RAG citations and traceability shows why source, version and locator should remain structured objects through the final UI.

Failure modes to test before production

The important test is not whether the system can produce three fluent answers. It is whether it can preserve evidence and choose a safe route when language, source and product policy disagree.

Build a per-language acceptance set

Create cases from the real corpus and review them with the owners of the governing documents. Include equivalent questions in Armenian, Russian and English only when they are genuinely equivalent; keep language-specific terminology, document titles and workflows where they differ.

For every language lane, test normal retrieval, exact identifiers, paraphrases, recently changed sources, denied access, missing evidence and citation links. Add mixed-language queries, ambiguous transliteration and a request whose answer must be qualified because the authoritative source exists only in another language. Track the route and evidence receipt, not only a single answer-quality score.

A bounded production check

Start with one workflow and a small, permission-safe source set. Pin the ingestion, embedding, retrieval and language-policy configurations for the test. Release with a rollback path, then inspect real traces for language route, source versions, citation-link health, no-answer reasons and changed-source reconciliation. Avoid collecting unnecessary user or document text in telemetry.

const route = decideLanguageRoute(request, localePolicy);
const candidates = retrieve({
  scope: request.scope,
  languages: route.allowedSourceLanguages,
  lifecycle: "current",
});

const evidence = selectCitableEvidence(candidates, route);
if (!evidence.coversMaterialClaims) return { route: "review-or-no-answer" };
return composeAnswer({ outputLanguage: route.outputLanguage, evidence });

This is a control sketch, not a universal implementation. The decisive acceptance criteria are that scope is trusted, language policy is explicit, evidence is inspectable and the system can decline an answer when it cannot support one. Those are practical criteria for an architecture review or technical audit before scaling a multilingual RAG system.