Перекладач з машини, або як навчити МФУ перекладати документи

Привіт, %username%!

Нещодавно ми,ABBYY LS, спільно з Xerox запустили Xerox Easy Translator Service — сервіс, який дозволяє отримати машинний переклад документа – для цього його потрібно відсканувати за допомогою БФП на базі технології Xerox ConnectKey або ж сфотографувати камерою телефону. Через цю ж платформу можна замовити і професійний переклад.



Як це працює? Давай розбиратися!

Машинний переклад



Користувач сканує, фотографує або завантажує готовий файл через Web. Файл зберігається в базі, після чого починається його розбір на сегменти — об'єкти, що зберігають фрагменти тексту (як правило, це пропозиції), та інформацію про верстки цих фрагментів. Файли в графічних форматах попередньо розпізнаються за допомогою ABBYY Recognition Server. Перед відправкою документа на розпізнавання ми запитуємо користувача, на якій мові написаний документ. Зображення може бути розпізнано і без цього, однак вказівка мови вихідного документа дозволить розпізнати його швидше і якісніше.

В процесі інтеграції з Recognition Server нам потрібно було вибрати параметри обробки для нашого потоку документів: формат експорту результатів, відповідне для нас співвідношення швидкість\якість розпізнавання, тип складання документа.

В якості формату експорту зараз ми використовуємо «дідка» .doc, так як на даний момент він найбільш повно описує Rich-текст і при цьому вирішує ряд проблем, пов'язаних з компонуванням елементів на сторінці при сегментації (привіт, .docx!). Тим не менш, перехід на .docx в планах є. Співвідношення між швидкістю і якістю викликало найбільше суперечок. З одного боку, якість розпізнавання – найвищий пріоритет для машинного перекладу документа, так як весь процес автоматизований, і немає можливості залучати фахівців з верстки. З іншого боку, основна перевага MT (machine translation) — швидкість (особливо в сценарії, коли користувач чекає роздрукований переклад біля МФУ), а за швидкість доводиться платити якістю. Тим не менше, вибір був зроблений на користь якості.

Тип складання документа визначає, які елементи вихідного документа потраплять у файл з результатом. Можна обмежити результат розпізнавання plain-текстом (цей варіант нам не підходить, так як важлива для розуміння контексту нетекстовая інформація буде втрачена), можна зберегти форматування тексту (вже краще, але як бути з важливою не текстовою інформацією?). Тип Editable Copy зберігає текст з форматуванням і нетекстовий контент, але без прив'язки до сторінок. Здавалося б, порушується компонування сторінок — і це мінус. Але так як при перекладі довжина слів може значно змінюватися (наприклад, німецький переклад слова «дружба» – «Freundschaftsbezeigungen»), відсутність прив'язки до сторінок вихідного файлу дозволяє уникати ситуацій, коли блоки з текстом «наїжджають» на інші елементи сторінки, а також коли текст перекладу не можна вписати в розміри блоку вихідного тексту. Останній варіант Exact Copy зберігає і форматований текст, і нетекстовий контент. На виході ми маємо документ, максимально наближений до оригіналу з точки зору посторінкового перегляду. Такий варіант виглядає більш цілісним з точки зору форматів, що підтримують посторінковий висновок (pdf, djvu), але переклад може опинитися «за бортом». У результаті ми зробили вибір на користь Editable Copy.

Вихідний текст



Приклад Exact Copy



Приклад EditableCopy



Далі розпізнаний файл проходить вже згадану сегментацію, а для сегментів, що складають першу 1000 символів документа, виконується автоматичне визначення мови тексту. Незважаючи на те, що ми вже попросили користувача вказати мову документа при завантаженні файлу, ми все одно проводимо авто-визначення, так як при роботі через API завдання мови необов'язкове для графічних форматів, і зовсім необов'язково при завантаженні документів текстових форматів. Знаючи мову, ми можемо підрахувати статистику по документу: кількість сторінок, слів, символів. Після цього сервіс направляє блоки сегментів документа через API машинного перекладу (MT-API) в один з кількох движків МТ. По завершенню перекладу документ збирається, а користувачеві надсилається повідомлення.

Приклад машинного перекладу:

Початкове зображення



Результат



Хочу відзначити, що, незважаючи на те, що технологія машинного перекладу ще сильно поступається по якості професійною, вона відмінно справляється із завданням швидкого перекладу великих обсягів інформації, коли потрібне розуміння загальних положень документа. Інший частотний сценарій — розуміння релевантних шматків вихідного тексту, які потім можна перевести більш ретельно. Тим не менш, ми робимо кроки для поліпшення якості машинного перекладу за рахунок використання баз пам'яті перекладу, про які ми поговоримо трохи нижче.

Професійний переклад

Якщо користувачеві необхідний більш якісний переклад, він може зробити замовлення професійним перекладачам. В цьому випадку шлях до файлу буде трохи інший:



Текст, який вийшов в результаті розпізнавання на Recognition Server, разом з вихідним документом надсилається SmartCAT — платформу для автоматизації процесу перекладу. Вихідний файл потрібен для того, щоб при перекладі був доступний нетекстовий контент, який може містити інформацію, важливу для збереження контексту перекладу. Але перш ніж документ потрапляє до самому перекладачеві, менеджер перевіряє, чи потрібна йому попередня верстка, і в разі необхідності залучає фахівців з верстки. Тільки потім призначаються виконавці. Безпосередньо в редакторі перекладач має доступ як до движка машинного перекладу, так і до баз Translation Memory (пам'яті перекладу), що дозволяє скорочувати час роботи над документом. Коли переклад завершено, він редагував, вичитується і ще раз перевіряється менеджером. І ось переклад завершено, а користувач отримує повідомлення по пошті і файл з висококласним результатом.

Приклад перекладу:

Початкове зображення



Результат



Як все це влаштовано всередині? Хороше питання!

Cake is not a lie!



Ви любите листкові тістечка? Ми любимо, і інфраструктуру нашої програми можна представити у вигляді такого тортика:



Кожен шматок складають dll-збірки, що реалізують конкретну фічу (feature), наприклад, FileManagement — управління файлами. Також бібліотеки поділяються по шарах: Контракти, Web API, Data Storage, Task Processing. При поділі був реалізований принцип CQRS — command-query responsibility segregation, згідно з яким метод повинен бути командою, що виконує якусь дію, або запитом, повертають дані, але не одночасно. Іншими словами, задавання питання не повинно змінювати відповідь (wiki).

Контракти
У контрактне складання зберігаються інтерфейси, за яким взаємодіють модулі програми, а також команди і запити, якими оперує ця фіча. Ці збірки використовуються іншими шарами того ж набору функціональності (на прикладі управління файлами це FileManagement.Api і FileManagement.Processing) та іншими фічами (управління замовленнями використовує керування файлами).

Web API
Тут все просто — метод API, що викликається споживачем, ініціює виконання команд, запитів, або їх комбінацій, і віддає результат виконання користувачеві.

Data Storage
Зберігання даних. Збірка підписується на виконання команд і запитів певних типів і здійснює зміну або читання даних. Ми використовуємо для цих цілей MongoDB, але так як робота з даними здійснюється через команди і запити, інші (не Data Storage) складання можуть лише здогадуватися про документальної сутності бази.

Task Processing
Виконання тривалих операцій. Як і збірка зберігання даних, ця збірка підписується на виклик певних команд, проте реальний час початку обробки такої команди регулюється планувальником. Такі команди називаються завданнями. Розбір файлу на сегменти — одна з таких задач.

Дерево всього проекту при цьому виглядає так:



Подібний поділ на верстви і фічі дозволяє досить гнучко нарощувати функціональність нашого тортика програми, додаючи все нові і нові смачні корисні можливості.

А на сьогодні все, до нових зустрічей.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.