Многоязычный RAG для армянского, русского и английского контента

Многоязычный RAG — это не англоязычная система retrieval с переводом в самом конце. Язык вопроса, язык управляющего источника, способ анализа документов и язык ответа влияют на то, уместны ли найденные evidence. Правдоподобный текст может быть неверным, если система незаметно пересекла языковую или версионную границу.

Этот материал отвечает на технический запрос «многоязычный RAG армянский русский английский». Более широкое решение о запуске и эксплуатации продукта относится к RAG-системам. Команда, которой нужен архитектурный разбор, может оформить задачу через AI engineering brief, а не подменять этой статьёй коммерческую страницу.

Начните с language contract, а не с переключателя языка

Фиксируйте язык как structured state на входе запроса. Полезный request record включает authenticated scope, declared locale из UI, detected language с confidence, требуемый язык ответа и policy для mixed-language текста. Detection — это сигнал, а не разрешение переписать вопрос пользователя.

Та же дисциплина нужна источникам. Для документа или passage сохраняются source language, canonical source ID, version, lifecycle, access attributes и human-openable locator. Если документ является переводом, держите связь с governing original, а не выдавайте обе версии за взаимозаменяемые. В одном процессе одобренный армянский перевод может быть источником истины, в другом — исходный русский или английский текст. Это решение content policy, которое retrieval обязан сохранить.

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

Confidence не является заявлением о качестве. Это вход в routing: low-confidence или mixed-language запрос может запросить уточнение, пройти ограниченный fallback либо уйти на review.

ML-RAG-9: единый evidence contract и явные language lanes

Workflow ML-RAG-9 отделяет работу с языком от permissions и evidence. Инфраструктура может быть общей, но она не должна стирать language-specific поведение.

REQUEST + authenticated scope + declared locale
  -> classify language и сохранить confidence
  -> применить trusted scope, lifecycle и language policy
  -> retrieve допустимые Armenian / Russian / English evidence
  -> нормализовать candidates, не теряя source language и locator
  -> выбрать evidence для каждого material claim
  -> собрать ответ на нужном языке с видимым source context
  -> route: answer | clarify | review | no-answer

При ingestion сохраняйте original Unicode text и структурные границы. Normalisation может улучшить matching, но не должна заменять оригинальный passage, который проверяет reviewer. Храните рядом с indexed version receipt: tokenizer или analyser, embedding model, chunking policy, language fields и source version. Без этого нельзя понять, вызван regression обновлением источника, analyser или модели.

При retrieval сначала вычисляйте eligibility. Tenant, role, lifecycle документа и product scope остаются deterministic filters. Затем language policy определяет, нужен ли strict exact-language lane, разрешён ли параллельный lane и как помечать translated или bilingual sources. Similarity score не даёт доступ, не отменяет superseded version и не должен скрывать language mismatch.

Контракты компонентов, которые не дают языку «потеряться»

Request router. Сохраняйте raw input, declared locale, detected language, confidence и fallback decision раздельно. Армянская фраза с русскими продуктовыми терминами и английскими identifier — нормальный production case, а не ошибка.

Document pipeline. Держите source language и writing system у каждого chunk. Не предполагайте, что любой Cyrillic — русский, а Latin script — английский. Сохраняйте canonical source и approved translation relation. Re-index changed document должен сделать старую версию ineligible по lifecycle policy.

Retriever и reranker. Передавайте в каждый candidate language, source ID, version, locator и access attributes. Материал о hybrid search полезен, когда exact identifiers и paraphrases требуют отдельных lexical и semantic signals; language contract должен пережить обе ветви и rank fusion.

Answer composer и UI. Пишите ответ только по selected evidence. Если утверждение переведено для ответа, сохраняйте original source title и понятный locator. Не представляйте translated paraphrase как дословную цитату. Почему source, version и locator должны остаться structured objects до финального UI, разбирает материал о цитатах и traceability.

Failure modes, которые надо проверить до production

Главная проверка — не три беглых ответа. Нужна способность сохранить evidence и выбрать безопасный route, когда язык, источник и product policy расходятся.

Соберите per-language acceptance set

Создайте cases из реального corpus и проверьте их с owners управляющих документов. Делайте эквивалентные вопросы на Armenian, Russian и English только когда они действительно эквивалентны; сохраняйте language-specific терминологию, названия документов и workflow там, где они различаются.

Для каждого language lane тестируйте normal retrieval, exact identifiers, paraphrases, недавно изменённые sources, denied access, отсутствие evidence и citation links. Добавьте mixed-language queries, ambiguous transliteration и запрос, который нужно ограничить, потому что authoritative source есть только на другом языке. Фиксируйте route и evidence receipt, а не только один aggregate score качества.

Bounded production check

Начните с одного workflow и небольшого permission-safe source set. Зафиксируйте ingestion, embedding, retrieval и language-policy configurations для теста. Выпустите с rollback path, затем изучите реальные traces: language route, source versions, citation-link health, причины no-answer и reconciliation changed sources. Не собирайте в 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 });

Это control sketch, а не универсальная реализация. Решающие acceptance criteria: trusted scope, явная language policy, inspectable evidence и способность отказаться от ответа без опоры. Это практические критерии архитектурного ревью или технического аудита перед масштабированием многоязычной RAG-системы.