Привет, Хабр. Мы – Даша (инженер машинного обучения) и Наташа (ведущий аналитик в ЮMoney). В этой статье расскажем о системе машинного перевода, разработанной как end-to-end-решение для многоязычной поддержки в финтех-компании. Рассмотрим архитектуру, технические детали реализации и практические результаты внедрения системы. А ещё покажем, как общались с пользователем из Казахстана.
План статьи:
>> Проанализируем потребность в системе перевода — рассмотрим, почему языковые барьеры критичны для техподдержки и масштабирования бизнеса.
>> Обсудим выбор архитектурного подхода — почему остановились на специализированном агенте вместо универсальных LLM-решений.
>> Детально разберём техническую реализацию — как работают FastText для определения языка и NLLB для перевода и почему потребовалось 12 отдельных LoRA адаптеров.
>> Покажем систему в действии — полный цикл обработки обращения от клиента из Казахстана.
>> Завершим анализом результатов и метрик качества работы системы.
Что это за проект
Система машинного перевода для мультиязычной поддержки представляет собой полнофункциональное решение для автоматического перевода между русским и семью целевыми языками. Архитектура построена по принципу pipeline: определение языка входящего сообщения >> выбор соответствующей модели перевода >> обработка корпоративной терминологии >> формирование результата.
Ключевая особенность системы — специализация под предметную область финансовых технологий с сохранением брендинга и корректной обработкой отраслевых терминов.
Зачем нам понадобился собственный простой AI-агент
Мы проанализировали процесс обработки обращений в техподдержку и отметили критическую роль языкового компонента. Из девяти основных этапов три напрямую связаны с переводом текста:
● определить язык обращения;
● перевести вопрос пользователя на русский;
● разобраться, в чём суть вопроса;
● уточнить детали обращения;
● посмотреть операции пользователя;
● сформулировать решение;
● проверить правильность ответа;
● перевести ответ на язык клиента;
● отправить решение пользователю.
Ручная работа операторов концентрируется на этапах анализа проблемы и верификации решения, в то время как остальные этапы потенциально автоматизируемы при наличии качественного перевода.
Поэтому задачи перевода блокировали автоматизацию остальных процессов: не преодолев языковой барьер, невозможно эффективно масштабировать поддержку и внедрить автоматизированные системы обработки обращений.
Чего хотели стейкхолдеры
Операторы требовали прозрачности процесса — им важно понимать, с какого языка переведён текст, иметь доступ к тексту обращения на языке оригинала и контролировать перевод.
Бизнес хотел снизить языковые барьеры для выхода на новые рынки при контролируемых затратах и масштабируемости решения.
Служба безопасности настаивала на локальной обработке персональных данных без использования внешних API и с возможностью полного аудита переводов.
Требования DevOps-команды — производительность, надёжность fallback-механизмов и масштабируемость системы.
Какие проблемы мы обнаружили
Универсальные опенсорс-модели плохо работают с финтех-терминами — ЮMoney, ЮCard, кэшбэк. Нужно было научить их обрабатывать такую корпоративную терминологию корректно.
Требовалась двунаправленная функциональность, чтобы переводить входящие обращения клиентов и исходящие ответы операторов на определённый язык.
Нельзя было отправлять персональные данные во внешние переводческие API из соображений безопасности. Нужна была собственная инфраструктура обработки.
Готовые решения не учитывали специфику предметной области: нужно было максимально точно переводить финансовые термины, сохраняя при этом брендинг продуктов компании.
Была сильная потребность в экономии ресурсов, поэтому модель NLLB distilled + адаптеры в памяти были бы для нас лучше, чем одна большая LLM c большим контекстным окном.
Свой AI-агент и внешний LLM API в обработке данных: кто кого
Мы сравнили подходы обоих решений и вот что выяснили:
У нашего агента все данные остаются внутри, потому что обрабатываются на собственных серверах. У внешних LLM API данные уходят наружу, а это небезопасно.
Собственный агент обеспечивает полную локальную обработку данных, независимость от интернет-соединения, предсказуемость затрат и полный контроль над процессом и логами.
Внешние LLM API создают зависимости от третьих сторон, требуют передачи конфиденциальных данных, имеют переменную стоимость и ограничения по нагрузке. Например, отсутствие интернета приводит к неполадкам и сбоям.
У собственного агента фиксированная цена, а при работе с внешними LLM API расходы постоянно увеличиваются и есть лимиты.
Таким образом, для финтеха с высокими требованиями к безопасности данных выбор в пользу собственного решения оказался очевиден.
Простой AI-агент и LLM в решении задач перевода
Вот ещё пара аргументов в пользу своего AI-помощника:
Он выполняет узкоспециализированный перевод идеально, без лишних рассуждений и планирования, в отличие от LLM-агента. Также собственный AI обеспечивает предсказуемость результатов, а LLM может, например, перевести одно и то же предложение по-разному.
У своего AI критичные требования к скорости: операторам не подходит длительная обработка запросов. У LLM-агента же задержка непредсказуемая — от 4 секунд на запрос.
Архитектура простого AI-агента реализует последовательную обработку в четыре этапа:
получение входных данных,
определение языка,
машинный перевод,
обработка ошибок.
Система спроектирована как Stateless-сервис с возможностью горизонтального масштабирования и независимой обработки каждого запроса. Время обработки — около 100 миллисекунд на определение языка + 0.5 до 3 секунд на перевод в зависимости от длины запроса, что обеспечивает приемлемый пользовательский опыт в интерактивных сценариях. Для сравнения: на перевод сообщений с помощью Google-переводчика оператор тратит от 30 секунд.
Детали системы
Система поддерживает семь целевых языков для перевода (русский, английский, китайский, казахский, кыргызский, таджикский и узбекский), а также 18 дополнительных (арабский, японский, корейский, европейские языки) для полного покрытия международной аудитории.
Техническая архитектура включает одну модель для определения языка и 12 дообученных специализированных LoRA адаптеров поверх NLLB distilled для машинного перевода.
Главные характеристики системы:
работа без внешних зависимостей,
точное распознавание языка,
специализированная обработка финтех-терминологии,
безопасность данных.
Этап 1: определяем язык
Модель FastText, обученная на 25 языках, делает это с точностью 99% и тратит на обработку около одной миллисекунды.
Логика принятия решений включает пороговые значения уверенности: при confidence выше 0.9 процесс продолжается, при более низких значениях активируется Fallback-режим.
Русский язык обрабатывается как базовый — сообщения на русском не переводятся, а передаются операторам напрямую.
Модель основана на n-граммах из Wikipedia, дообучена на синтетических и реальных диалогах из нашей службы поддержки и работает полностью локально.
Модель распознавания поддерживает 25 языков против 176 в универсальных решениях, что обеспечивает высокую точность за счёт специализации. Покрытие аудитории составляет 95% при существенном повышении качества распознавания по сравнению с универсальными моделями.
Как происходит подготовка данных для FastText
Обучающий датасет подготовлен на основе десятков тысяч реальных сообщений из базы данных чат-бота с последующим переводом на 20+ языков.
Процесс очистки включает нормализацию текста с помощью кастомных CleanText-методов, стандартизацию корпоративных терминов, дедупликацию и фильтрацию некорректных данных.
Использованы предобученные векторные представления Common Crawl размерностью 300D для повышения качества модели.
Подготовка данных для тренировки модели определения языка была направлена на создание многоязычного классификатора для обработки пользовательских обращений в чат-боте. Важным этапом подготовки стала стандартизация корпоративной терминологии — во всех текстах с помощью словарей нашли и исправили названия брендов и сервисов (например, yumoney заменили на yoomoney), что обеспечило единообразие во всех языковых версиях.
В результате обработки сформировали тренировочный датасет объёмом около миллиона примеров, где каждый текст получил соответствующий языковой лейбл в формате FastText (
__label__<код_языка> текст). Данные были сбалансированы по количеству примеров для каждого языка: основные языки получили по ~125 тысяч примеров, японский ~20 тысяч (из-за риска путаницы с китайским), остальные — по ~6 тысяч. Дополнительно подготовили тестовый набор из примерно 500 вручную созданных примеров, переведённых на все языки. Это обеспечило качественную оценку модели на всех поддерживаемых языках.
Обучение модели FastText
Модель обучена с оптимальными параметрами: 25 эпох, learning rate — 0.01, размерность векторов — 300, word n-grams — до 2, character n-grams — от 1 до 3.
Предобученные векторы объединены для всех поддерживаемых языков в единое векторное пространство размером 300 измерений.
Результирующая модель достигает 99% точности на тестовом наборе при размере 2.78 GB и времени определения языка около одной миллисекунды.
Этап 2: машинный перевод
Второй этап использует 12 специализированных LoRA адаптеров к модели NLLB-200, обученных на корпоративных данных с фокусом на финтех-терминологию.
Архитектура обеспечивает двунаправленный перевод между русским и шестью целевыми языками с сохранением брендинга и корректной обработкой отраслевых терминов.
Данные и подход «Текст с ошибками >> Чистый текст»
Обучающий датасет построен так, что модели учатся переводить тексты с возможными ошибками пользователей в корректные формулировки на целевом языке.
Первая группа моделей переводит с целевых языков на русский, вторая — с русского на целевые, что обеспечивает полный цикл коммуникации.
Корпоративная терминология
Словарь системы состоит более чем из 30 корпоративных терминов с правилами их обработки для каждого языка. Принципы обработки такие: брендовые названия остаются неизменными, специальная терминология переводится по корпоративному словарю, обеспечивается консистентность во всех языках.
Параметры обучения и архитектура
Параметры обучения LoRA адаптеров:
Модель NLLB-200-distilled-600M с LoRA адаптерами: 3 эпохи, batch size — 48 (12 per device × 4 gradient accumulation), learning rate — 5e-4.
Warmup steps — 200, weight decay — 0.01, fp16 precision для оптимизации памяти.
Сохранение чекпоинтов после каждой эпохи с ограничением до 5 версий.
Архитектура LoRA (Low-Rank Adaptation):
Параметрическая эффективная адаптация: rank r=32, alpha=64, dropout=0.1
Целевые модули: attention слои (q_proj, v_proj, k_proj, out_proj) и feed-forward слои (fc1, fc2).
Отдельный LoRA адаптер для каждой из 12 языковых пар, заморозка базовых весов NLLB для сохранения предобученных знаний.
Seq2Seq архитектура с автоматическим размещением на GPU, использование специализированного data collator для оптимальной обработки последовательностей.
Система оценки качества
Оценка качества проводится по двум группам метрик:
классические лексические метрики (BLEU, ROUGE-1, ROUGE-2, ROUGE-L, Levenshtein distance);
современная нейронная метрика COMET для семантического анализа.
Классические метрики имеют ограничения: оценивают лексическое совпадение, но не учитывают семантическую близость. ROUGE может показывать низкие значения для синонимичных переводов или переводов с разной структурой предложения, но одинаковым смыслом.
COMET представляет современный подход — это нейронная метрика, обученная на человеческих оценках качества перевода. Она учитывает семантическую близость между исходным текстом, переводом и эталоном, что делает её более репрезентативной для оценки реального качества перевода.
Процесс оценки включает:
генерацию переводов на тестовом наборе;
расчёт всех метрик для каждой языковой пары;
приоритетный анализ COMET-оценок как наиболее надёжного индикатора качества;
агрегацию со сведением результатов по всем моделям.
Результаты и метрики
По классическим метрикам лучшие результаты показали модели:
Русский → Английский: BLEU 66.32 — наивысший показатель качества перевода.
Русский → Таджикский: BLEU 46.51 — лучший результат среди языков СНГ.
Русский → Казахский: BLEU 44.87 — высокое качество для тюркской языковой группы.
Особенности результатов по направлениям:
Переводы с русского языка показали существенно более высокие BLEU-скоры (36-66) по сравнению с переводами на русский язык (22-28).
Китайский язык продемонстрировал специфические особенности: критически низкие BLEU-скоры (~2.8 для рус→кит, ~22.9 для кит→рус) объясняются кардинальными различиями в структуре языка, но COMET-оценки подтвердили адекватность семантической передачи смысла.
Важнее всего оказался анализ COMET-метрик, которые показывают высокое семантическое качество переводов для всех языковых пар. Это особенно важно для языков СНГ, где синтаксические различия могут снижать BLEU при сохранении смысловой точности.
Средняя метрика COMET на все языки > 0.9. Это говорит о том, что смысл полностью передан на каждом языке в обе стороны перевода.
Ключевые технические достижения и результаты проекта
Создали 12 специализированных LoRA адаптеров с параметрической эффективностью (замороженная базовая модель + адаптивные слои).
Достигли высокого качества перевода: BLEU 66.32 для рус→eng, 46.51 для рус→тадж, эффективная обработка морфологически сложных языков СНГ.
Сделали точный перевод корпоративной терминологии.
Сохранили контекст и семантику в переводах.
В качестве практических преимуществ:
реализовали консистентный брендинг во всех языках;
сделали специализацию под финтех-терминологию;
подготовились к продакшену через MLflow.
Пример работы системы: обработка входящего сообщения от зарубежного клиента за восемь секунд
Рассмотрим полный цикл обработки обращения.
Клиент Айнур из Казахстана отправляет сообщение на казахском языке о проблемах с пополнением кошелька.
Система автоматически определяет казахский язык с уверенностью 99.8%, переводит сообщение на русский с сохранением термина ЮMoney и передаёт текст на русском оператору Максиму.
Оператор формулирует ответ на русском языке, используя функцию предпросмотра перевода для контроля качества текста перед отправкой клиенту.
Система автоматически переводит ответ обратно на казахский, и клиент получает помощь на родном языке.
Весь процесс занимает около 1-2секунд с полным сохранением терминологии и без внешних запросов👍
Интерфейсы системы
Интерфейс оператора обеспечивает полную прозрачность процесса — с явными метками переведённого контента, кнопками для просмотра оригинала и управления переводом.
Для исходящих сообщений предусмотрен предпросмотр перевода с возможностью редактирования перед отправкой.
Настройки администратора позволяют конфигурировать систему на уровне очередей для тикетов и каналов для чатов с управлением таймаутами и мониторингом качества.
Детальные сценарии использования
Система реализует два основных алгоритма:
для входящих сообщений — определение языка, условный перевод и передача оператору;
для исходящих — проверка необходимости перевода, выполнение перевода и отправка клиенту.
Ключевые принципы: язык определяется однократно, перевод выполняется только при необходимости, оператор работает исключительно с русским текстом.
Итоги
В заключение сформулируем, какие ключевые принципы построения AI-агентов мы использовали:
Творческий подход к выбору технологий позволяет найти оптимальные решения для конкретных задач.
Чёткие ограничения помогают выбрать специализированное решение вместо универсального.
Комплексный мониторинг должен включать технические метрики, NPS и частоту повторных обращений.
Результат — система машинного перевода с NLLB с адаптерами, 99-процентной точностью определения языка, полностью локальной обработкой и временем отклика около трёх секунд.
Мы создали работающую систему, которая решает задачу языковых барьеров в финтех-поддержке быстро, с высокой точностью и без угрозы для данных.
***
Если остались вопросы, задавайте их в комментариях, с удовольствием ответим.