Привет! Меня зовут Глеб Смольяков, я инженер-программист в DevRel-отделе Битрикс24. 

DevRel-команда работает с разными задачами, которые помогают разработчикам и пользователям быстрее разобраться в возможностях продукта. Одна из таких задач — улучшение документации и её перевод на другие языки.

В статье я остановлюсь на 2 проблемах, которые мы решаем во время локализации.

Скриншоты в документации могут показать, где искать настройку или как выглядит нужный экран. Но скриншот — это картинка, и его нельзя просто прогнать через перевод. Поэтому для локализации скриншотов нужен отдельный процесс: распознать текст на изображении, перевести его и проверить, что термины совпадают с терминологией продукта.

Количество смыслов одного и того же слова на другом языке — другая проблема. Например, слово issue можно перевести 5-7 разными способами: это и проблема, и ошибка, и задача. Без единого источника правды система будет переводить такие слова по-разному, и читаемость и понятность документации снижается.

В этой статье покажу, как мы автоматизировали перевод скриншотов и какие результаты получили в цифрах.

Содержание:

• Перед началом: какие термины используем

• Зачем переводить скриншоты

• Как выглядит процесс автоматического перевода

• Как мы проверяли гипотезу с глоссарием

• Как классифицировали проблемы: Q2, Q3 и QA

• Основная проблема: иногда модель плохо распознаёт текст

• Что изменилось после подключения глоссария

• Наши выводы из тестирования гипотезы

Перед началом: какие термины используем

Вот несколько вещей, чтобы можно было разобраться в теме статьи. Это значение терминов конкретно для нашей задачи — в другом контексте они могут иметь другое значение, например слово Строка.

Строка подразумевает в основном целые интерфейсные фразы, а не отдельные слова. Например, файлы из письма, подробнее, количество неиспользуемых версий.

OCR — распознавание текста на картинке. Эта ИИ-модель просто читает текст на изображении без перевода.

Глоссарий включает список уже утверждённых переводов, например: Подробнее → Learn more. 

Глоссарий нужен до перевода: его дают модели как подсказку. Теперь, если OCR-модель прочтёт где-то текст как Подробнее, модель для перевода сразу будет знать, как перевести этот текст.

Темины — то, что содержится в глоссарии. Это важные для понимания смысла определения, которые часто повторяются на экранах.

В переводе содержатся и другие строки: данные пользователя, переменные, кастомные фразы. Они не повторяются и могут служить примерами или простым наполнением.

Канон — эталонный вариант перевода, с которым сравнивают результат. 

Это текст с уже существующего экрана, с которым можно сравнивать новый автоматический перевод.

Gen — новый перевод, который сгенерировала модель автоматически в текущем запуске. Потом gen сравнивают с глоссарием и каноном.

Fuzzy matching — поиск похожих строк. Он помогает сопоставить текст со скриншота с глоссарием, даже если OCR распознал строку не полностью или с небольшой ошибкой. Например, в глоссарии есть строка Применить для всех пользователей, а OCR распознал текст немного криво: Примнить для вех польз ватй. Система сравнивает эти строки и понимает, что скорее всего, это одна и та же фраза.

Покрытие глоссарием означает, сколько строк со скриншотов уже есть в глоссарии.

Доля извлечения показывает, сколько строк удалось распознать и сопоставить с глоссарием.

Зачем переводить скриншоты

Скриншот в документации помогает понять, где находится нужная настройка, какую кнопку нажать и как должен выглядеть результат. Текст внутри скриншота влияет на качество инструкции.

Пример того, как может выглядеть скриншот интерфейса:

В статье может быть написано Click Apply for all users, а на скриншоте будет кнопка «Применить для всех пользователей». Скорее всего пользователь поймёт, что надо сделать, но потратит внимание на сопоставление. Для одной инструкции это мелочь, но в больших масштабах становится заметной проблемой.

Как выглядит процесс автоматического перевода

Схема примерно такая:

1. Сначала система берёт скриншот.

2. OCR распознаёт текст на изображении.

3. Найденные строки сопоставляются с глоссарием.

4. Модель получает задачу перевести текст с учётом утверждённых терминов.

5. Перевод проходит проверку. Для этого новый перевод сравнивается с каноном и глоссарием: так видно, совпали ли формулировки с эталоном и утверждёнными терминами.

Глоссарий в этой цепочке нужен как источник правильных формулировок: если в продукте уже принято переводить Подробнее как Learn more, модель должна использовать именно этот вариант, а не использовать синонимы вроде More details или Read more. Это важно, потому что если одна и та же кнопка в разных местах называется по-разному, пользователю сложнее ориентироваться.

Примеры оригинального текста, утверждённого перевода из глоссария и перевода, который может предложить модель без глоссария.

Как мы проверяли гипотезу с глоссарием

Мы проверяли, станет ли автоматический перевод скриншотов станет ближе к принятой терминологии продукта, если передавать модели глоссарий с утверждёнными переводами.

Мы проверили, насколько глоссарий покрывает строки на скриншотах и сколько из этих строк реально удаётся извлечь автоматически. В тестовом наборе было 197 переводимых уникальных строк. Мы уже занесли в глоссарий все 197 строк, то есть покрытие глоссарием составило 100%. Тот же уровень покрытия мы планируем стараться поддерживать на всех этапах работы, чтобы перевод всегда был единообразным.

Все 197 строк сняты с 5 экранов.

Не все строки должны быть в глоссарии. Перевод может быть правильным и без этого: в глоссарии содержатся термины, но не каждая строка является термином. Для продуктовой документации можно вывести такие правила:

• Термины, названия кнопок, разделов и настроек лучше держать в глоссарии. 

• Обычные служебные фразы можно разрешить переводить свободнее, если они не влияют на терминологию продукта.

Есть отдельная проблема в том, что строку ещё нужно правильно распознать на изображении. В нашем случае OCR вместе с fuzzy matching смог извлечь 183 строки из 197, то есть мы смогли распознать 92,9%. Оставшиеся 14 строк были и на экране, и в глоссарии, но OCR всё равно прочитал их с ошибками. Часть из них — термины, а часть — просто фразы без определённого перевода, которые не так важны.

Как классифицировали проблемы: Q2, Q3 и QA

Чтобы понять, где система теряет качество, строки разделили на группы. 

Q2 — это случаи, когда строка есть и на экране, и в глоссарии, но OCR прочитал её с ошибкой. В таких случаях глоссарий знает правильный перевод, но система может не передать его модели, потому что не смогла нормально распознать исходный текст.

Q3 — это строки, которых не хватало в глоссарии. После анализа такие строки можно добавить, чтобы в следующем запуске модель уже получала правильные подсказки. 

Правки по QA-анализу — отдельная категория. 

Наша цель — полное покрытие глоссарием терминов. Термины повторяются много раз на разных экранах, и они одинаковы. Потерянные строки чаще всего представляют собой кастомные полян и названия файлов. Для этого не нужен единый перевод, и здесь допустима погрешность. QA нужен, чтобы отделить термины от таких строк с низкой критичностью.

Основная проблема: иногда модель плохо распознаёт текст

Общая таблица получилась такой:

Главное слабое место находится на этапе OCR, когда модель считывает только кусок строки или набор похожих символов. Система не всегда понимает, какую пару из глоссария можно и нужно передать модели для перевода.

Именно для таких случаев используется механизм fuzzy matching — поиск похожих строк. Но он помогает, только если OCR ошибся не сильно. Когда распознавание сильно искажено, глоссарий может не сработать.

В таблице выше есть последняя графа — «Потеряно из-за OCR». Это случаи, когда OCR прочитал строку так плохо, что система не смогла нормально сопоставить её с глоссарием. Например, прочёл Apply for all users как llusers.

Другие примеры того, как могут выглядеть результаты перевода:

Что изменилось после подключения глоссария

Главный результат: новый перевод стал ближе и к канону, и к глоссарию.

Старый перевод совпадал с каноном на 69,4%, новый — на 81,1%. Совпадение с глоссарием выросло с 80,0% до 92,9%. Обратите внимание, что выше есть другая метрика, которая тоже равна 92,9% — доля распознанных строк.

Совпадение с каноном:

Старый перевод — 69,4% ██████████████░░░░░░

Новый перевод — 81,1%  ████████████████░░░░

Совпадение с глоссарием:

Старый перевод — 80,0% ████████████████░░░░

Новый перевод — 92,9%  ███████████████████░

После анализа глоссарий расширили: добавили 14 пар, из которых часть пришла из Q3, часть — из QA-анализа. Эти пары были добавлены уже после генерации, поэтому текущие числа они не меняют. Но при перегенерации часть новых пар должна улучшить метрики: совпадение нового перевода с глоссарием планируется улучшить с 92,9% до 94,6%, а совпадение с каноном — с 81,1% до 82,5%.

На деле это выглядит так, что термины с большим количеством вариантов перевода модель переводит строже. My plan раньше мог переводиться как «Моё предложение», «Мой тариф» или «Мой план», а теперь всегда переводится как «Мой тариф». Похожая ситуация с термином Lead. Без контекста модель могла выбрать «лидер», но в CRM это «лид» — потенциальный клиент. 

Промахи у оптимизации тоже были. Например, Files from email — это имя файла, которое надо было оставить как есть, а система перевела.

Наши выводы из тестирования гипотезы

Глоссарий помогает превратить перевод скриншотов из разовой генерации в управляемый процесс. Он задаёт модели правильные термины, помогает проверять результат и показывает, где система теряет качество.

Наш следующий шаг — улучшать не только промпт и глоссарий, но и этап распознавания текста, который сейчас составляет основную проблему. Расскажем об этом в следующий раз, когда проведём исследование.