Армянский, русский и английский в одной AI-системе

Многоязычная AI-система для армянского, русского и английского — это не переводчик, добавленный к чат-боту. Это production-архитектура, в которой язык становится явным состоянием: система определяет его, сохраняет во всех интеграциях, отдельно оценивает качество для каждого языка и выбирает безопасный fallback при недостаточной уверенности.

Для компании в Армении это практическая задача. Клиент может написать на армянском, оператор — искать внутренний документ на русском, а продуктовый каталог или API — использовать английские идентификаторы. Если архитектура молча считает английский языком по умолчанию, demo может выглядеть убедительно, хотя в production искажаются имена, даты, отрицания, product codes или права доступа.

Ниже — переиспользуемая архитектура, контракты компонентов, failure modes и production-check. Материал раскрывает технический long-tail и поддерживает broad commercial intent страницы AI-специалиста в Армении, но не заменяет эту landing page.

1. Начните с workflow, а не со списка языков

Формулировка «поддерживать армянский, русский и английский» слишком расплывчата для реализации. Production-требование должно определять, кто отправляет вход, какое решение последует, где находятся source data и как оператор исправляет результат.

Рассмотрим маршрутизацию обращений в поддержку:

• клиенты пишут в свободной форме на армянском, русском или английском;
• система извлекает account, продукт, intent и urgency;
• retrieval ищет утверждённые политики и продуктовые документы;
• модель готовит draft ответа или recommendation по маршруту;
• человек подтверждает чувствительные ответы и каждый consequential CRM write;
• audit record сохраняет исходный текст, определённый язык, источники, output и действие reviewer.

Требование здесь — не «перевести всё на английский», а «сохранить смысл и traceability при прохождении многоязычного запроса через контролируемый бизнес-процесс». Это различие определяет data model и тесты.

До выбора модели соберите representative examples для каждого языка, сообщения со смешанными письменностями, армянский в латинской транслитерации, названия продуктов, даты, числа и распространённые исключения. Этот же inventory помогает AI-воркшопу в Ереване завершиться evidence-based pilot, а не общей дискуссией.

2. Production-требования нужно превратить в контракты

Полезный language contract отвечает на пять вопросов.

1. Input: Какие encoding, scripts, channels и attachment types принимаются?
2. State: Какие языковые атрибуты обязаны пережить каждую queue, API и database write?
3. Output: Ответ должен совпадать с языком пользователя, настройкой account или выбором оператора?
4. Evidence: Какие источники, transformations и версия модели должны быть прослеживаемыми?
5. Fallback: Что происходит, если язык или смысл неоднозначны?

Минимальный message envelope может выглядеть так:

type LanguageCode = "hy" | "ru" | "en" | "mixed" | "unknown";

type MultilingualEnvelope = {
  messageId: string;
  originalText: string;
  detectedLanguage: LanguageCode;
  detectionConfidence: number;
  normalizedText?: string;
  outputLanguage: "hy" | "ru" | "en";
  glossaryVersion: string;
  sourceIds: string[];
  requiresHumanReview: boolean;
};

Исходный текст должен быть immutable. Normalization и translation — производные artifacts, а не замена оригинала. Без этого правила оператор не сможет восстановить, почему позднее ошиблись classifier, retrieval query или ответ.

3. Архитектура LANE

Авторская схема в этом материале называется LANE: Language-Aware Normalization and Execution. Она разделяет workflow на gates вместо попытки одним prompt определить язык, перевести, найти документы, принять решение и выполнить действие.

Такое разделение важнее выбора конкретной модели. Компоненты можно заменять независимо, сохраняя envelope и acceptance gates стабильными.

Capture и Unicode normalization

Unicode normalization должна быть осознанной. Выберите документированную форму, сохраняйте original bytes или text и тестируйте армянские кавычки, combining characters, emoji, punctuation и текст из офисных документов. Нельзя бездумно приводить всё к lowercase: регистр несёт продуктовый или юридический смысл в русском и английском, а mixed identifiers могут быть case-sensitive.

Language detection — только routing hint

Короткие inputs — имена, «OK», product codes или адреса — могут не содержать достаточно языковых признаков. Detector обязан уметь возвращать mixed или unknown. Confidence не является универсальной вероятностью: thresholds нужно калибровать на реальном channel и длине сообщения.

Используйте deterministic rules для очевидных условий, протестированный detector для обычных сообщений и human clarification для неоднозначности. Low-confidence label не должен молча выбирать high-impact action.

Translation опционален

Некоторые компоненты могут лучше работать через English pivot, но перевод всего потока способен стереть различия и добавить второй error surface. Предпочитайте native processing, если evaluation подтверждает надёжность. Если pivot необходим, храните original и translation, версию перевода и проверяйте critical entities по оригиналу.

Имена, адреса, суммы, даты, contract terms и отрицания требуют явных assertions. Свободный и красивый перевод не доказывает сохранение бизнес-смысла.

4. Retrieval и устройство знаний

У multilingual retrieval есть три распространённых паттерна:

• отдельные indexes по языкам — больше контроля и ясное ownership;
• единый multilingual embedding index — cross-language discovery;
• hybrid routing — сначала primary language, затем контролируемое расширение.

Выбор зависит от документов. Если армянская policy является authoritative, а русская копия устарела, cross-language search не должен поднимать перевод выше source of truth. Поэтому каждому chunk нужны language, document status, owner, version, effective date и access-control metadata.

Retrieval должен возвращать source IDs и релевантные passages, а не непрослеживаемый blob. Generation step обязан abstain, когда approved source не подтверждает ответ. Access control применяется до или во время retrieval, но не после того, как текст уже попал в модель.

Для mixed-language queries создавайте language-specific variants только при необходимости и логируйте их. Retrieval quality измеряйте отдельно от answer quality: модель не процитирует правильную policy, если retriever её не вернул.

5. Model routing и structured output

Одна модель может обслуживать все три языка, если проходит evaluation set. Но capability — лишь один фактор routing. Учитываются также task type, sensitivity, latency budget и то, является ли результат draft или action.

Компоненты должны обмениваться typed objects. Например, intent classifier возвращает schema с intent, entities, language, confidence, evidence и review_required. Объект валидируется до передачи в CRM, n8n или другую систему.

Prompt задаёт язык output, допустимость transliteration, правила сохранения identifiers и условия abstention. Но system prompt не является security boundary: permissions и validation реализуются в application code.

6. Интеграции обязаны сохранять language state

Многоязычные ошибки часто возникают вне модели:

• webhook предполагает ASCII или некорректно обрезает Unicode;
• CRM field имеет неправильную длину или encoding;
• queue теряет detectedLanguage при serialization;
• search endpoint плохо tokenizes Armenian;
• notification template по умолчанию переключается на русский;
• correction оператора хранится без связи с исходным output.

Определите один canonical envelope и версионируйте его. Каждая integration либо сохраняет обязательные поля, либо явно маппит их. Idempotency keys не должны зависеть от translated text: иначе один message после разных переводов создаст duplicate actions.

Consequential writes требуют least privilege, schema validation и human approval там, где цена ошибки существенна. Это engineering boundary, а не настройка prompt.

7. Failure modes, которые проектируются до запуска

Самые опасные failures часто молчат. Crash заметен, а правдоподобный ответ с неверной суммой или устаревшим source может пройти незамеченным. Поэтому acceptance criteria должны измерять severe semantic errors, а не только grammatical quality.

8. Evaluation set строится по риску

Создайте versioned evaluation set из реальных, разрешённых и anonymized cases. Балансируйте его по language, channel, message length, task type и risk. Включите:

• native Armenian в формальной и разговорной форме;
• русский деловой язык и распространённые сокращения;
• английские product и technical terms;
• армянский, записанный латиницей;
• mixed Armenian/Russian/English messages;
• опечатки, voice-transcription artifacts и неполные requests;
• имена, адреса, даты, currencies, units и product codes;
• неоднозначные cases, где правильный ответ — clarification или abstention;
• adversarial instructions внутри документов или user text.

Оценивайте component stages отдельно: language routing, entity preservation, retrieval recall, citation correctness, schema validity, output-language consistency и action safety. Затем запускайте end-to-end workflow evaluation.

Launch threshold может требовать ноль severe permission или amount errors, полную schema validity, протестированный abstention и отдельный минимум для каждого языка. Среднее по трём языкам недостаточно: сильный English не должен скрывать слабый Armenian.

9. Testing pyramid для multilingual AI

Deterministic unit tests

Тестируйте Unicode normalization, field mapping, validators, permission checks, idempotency, retry limits и template selection. Эти тесты должны быть быстрыми и стабильными.

Component evaluations

Запускайте labelled cases против detection, retrieval и structured generation. Фиксируйте datasets и записывайте model, prompt, glossary и index versions, чтобы regressions можно было объяснить.

Contract и integration tests

Прогоняйте Armenian, Russian, English и mixed payloads через webhooks, queues, databases, CRM sandboxes и notification services. Проверяйте round-trip text equality и обязательные envelope fields.

End-to-end acceptance

Воспроизводите реальный operator workflow: принять case, найти evidence, создать draft или route, проверить, записать, провести audit и rollback. Включайте timeouts и unavailable dependencies.

Browser и accessibility checks

Интерфейсу нужны fonts с Armenian и Cyrillic glyph coverage, корректные line breaks, поиск по original text и читаемое side-by-side evidence. Проверяйте mobile overflow: длинные identifiers и mixed scripts часто вскрывают layout defects.

10. Production-check

Не запускайте систему, пока нельзя доказать следующие утверждения:

• original text immutable и доступен reviewer;
• каждая normalization или translation имеет версию;
• hy, ru, en, mixed и unknown — валидные states;
• output language выбирается явным правилом;
• critical entities сравниваются с original spans;
• retrieval применяет status, language и access filters;
• каждый ответ цитирует approved sources или abstains;
• structured output валидируется до integration writes;
• retries bounded и idempotent;
• human approval защищает consequential actions;
• evaluation reporting разделён по каждому языку;
• monitoring включает detector drift, no-answer rate, severe errors, latency и cost;
• существуют incident runbook, rollback и named owner.

11. Observability и improvement loop

Логируйте достаточно для диагностики решения, не сохраняя лишние sensitive data. Полезны trace ID, language state, component versions, retrieval source IDs, validation outcome, approval state, latency, token usage и final route. К traces применяются такие же retention и access rules, как к основным business data.

Качество анализируется по языку и workflow stage. Рост Armenian no-answer rate может означать нехватку документов, а не слабую модель. Russian latency spike может идти из translation branch. English entity failures могут возникнуть в CRM mapping. Component-level traces не позволяют называть любую проблему «ошибкой AI-модели».

Operator corrections становятся полезным feedback только при структурированном capture: что было неверно, какой span или source стал причиной, каков правильный outcome и относится ли проблема к data, retrieval, prompt, model или integration.

12. От prototype к production

Prototype может использовать один endpoint, один prompt и spreadsheet с примерами. Production требует разделения ответственности и operational ownership.

1. Зафиксируйте один bounded multilingual workflow и его risk.
2. Соберите representative cases с permission и expected outcomes.
3. Реализуйте canonical envelope и immutable original text.
4. Отдельно оцените detection, normalization, retrieval и generation.
5. Добавьте validation, approval, fallback, idempotency и audit.
6. Проведите controlled pilot с per-language thresholds.
7. Расширяйте систему только после классификации failures и доказанного ownership.

Более широкий local delivery proof находится в кейсах и на странице о студии. Если у команды уже есть prototype, но его multilingual failure modes нельзя объяснить, запросите architecture review или технический аудит до подключения production systems.

Вывод

Одна AI-система может поддерживать армянский, русский и английский, не превращаясь в три несвязанных продукта. Для этого язык должен стать first-class contract, исходное evidence — сохраняться, компоненты — быть изолированными, boundaries — валидироваться, а каждый язык — измеряться отдельно.

LANE намеренно model-agnostic. Модели, detectors и indexes будут меняться; поддерживаемость дают envelope, permissions, evaluation set, failure routes и operational ownership. Начните с одного workflow, докажите контроль severe errors и только после этого расширяйте languages, channels или actions.

Где это применимо

Language-aware architecture, per-language evaluation и production control

Материал полезен командам в Армении, которым нужно провести Armenian, Russian и English через один проверяемый business workflow.

• Сохраняйте original text и language state на каждом integration boundary.
• Оценивайте detection, retrieval, output и severe errors отдельно по каждому языку.
• Блокируйте consequential writes через schema validation, approval, fallback и audit trail.

Обсудить AI-автоматизацию