OCR для перекладу документів: як обрати рушій

Порівняйте Google Document AI, Amazon Textract, Azure Read і Tesseract для сканів, таблиць та багатомовних PDF. Отримайте план тестування на власних документах.

Також: UK RU EN
OCR для перекладу документів: як обрати рушій

OCR для перекладу документів: як обрати рушій

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

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

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

Що потрібно зробити перед перекладом сканованого документа

Спершу з’ясуй, чи потрібен OCR. У PDF може бути справжній текст, який ти виділиш мишкою, а може бути тільки зображення сторінки, де кожна літера - це пікселі. У першому випадку витягни вбудований текст; у другому запускай розпізнавання.

PDF буває і змішаним: на одних сторінках є цифровий текст, на інших - скани. Тут легко втратити текст, який уже був у файлі. Наприклад, sidecar-файл OCRmyPDF може містити текст, розпізнаний OCR, але не текст, що вже був у сторінках. Отже, такий файл не обов’язково містить увесь текст змішаного PDF (документація OCRmyPDF).

Google Document AI має окрему можливість витягувати вбудований текст із цифрових PDF, зокрема текст із незвичним оформленням або повернутими фрагментами. Google також розділяє Enterprise Document OCR, призначений для роботи з документами, і Cloud Vision, який описаний як засіб загального витягу тексту з вимогами до малої затримки та високої пропускної здатності (документація Enterprise Document OCR).

У документації Google Enterprise Document OCR рекомендований, коли потрібно «Recommended when extracting text from documents» - тобто для витягу тексту з документів.

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

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

  1. З’ясуй, де текст уже доступний, а де є тільки зображення.
  2. Витягни вбудований текст із цифрових сторінок і запусти OCR для сканів.
  3. Перевір розпізнаний текст, структуру й порядок читання.
  4. Передай текст або підготовлений документ у переклад.
  5. Звір переклад з оригіналом, особливо числа, імена й таблиці.

На кожному кроці може працювати окремий інструмент. Деякі OCR-сервіси повертають структуровані блоки й координати. Інші створюють пошуковий PDF або текст, який треба додатково обробити. Обирай рушій з огляду на те, що має отримати наступний етап.

Якщо команда перекладає договори, сертифікати, форми чи інструкції, одразу визнач, який результат потрібен перекладачеві: текст для CAT-системи, файл із координатами, таблиці як окремі структури, PDF із текстовим шаром чи редагований документ Word. Інакше навіть правильно розпізнані слова можуть виявитися незручними для роботи.

PDF із виділюваним текстом не треба пропускати через OCR лише про всяк випадок. Якщо файл змішаний, перевір, чи потрапили до витягу і цифровий текст, і розпізнані скани. А коли в документі є і цифрові, і скановані сторінки, тестуй їх окремо.

Як обрати OCR для мов, сканів і структури документа

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

Google Enterprise Document OCR повертає ієрархію документа: блоки, абзаци, рядки, слова й символи. Документація також описує вирівнювання PDF та зображень перед витягом, визначення мови й мовні підказки, роботу з рукописним текстом, корекцію повороту та вибір діапазону сторінок. Серед проблем якості зображення згадані розмиття, дуже малий шрифт і відблиски. Функції можуть залежати від версії процесора та регіону, тому перед запуском звірся з актуальною документацією (Enterprise Document OCR).

У переліку процесорів Google Enterprise Document OCR зазначений як такий, що підтримує текст, зокрема рукописний, більш ніж двома сотнями мов. Це не означає однакової якості для кожної мови й писемності. Перевір потрібні мову та писемність у чинному переліку підтримки (перелік процесорів Google).

Amazon Textract повертає текст із координатами та показником упевненості для слів і рядків. Функція Layout визначає заголовки, абзаци, списки, зображення, номери сторінок і нижні колонтитули та віддає їх у природному порядку читання. Витяг таблиць охоплює рядки, стовпці й об’єднані клітинки (FAQ Amazon Textract).

За актуальним описом AWS, Textract розпізнає друкований текст більш ніж сорока мовами, а рукописний - англійською. Витяг форм і пар ключ-значення задокументований для англійської, німецької, французької, іспанської, італійської та португальської. Можливості залежать від API та мови, тож перевір саме той режим, який хочеш використовувати (FAQ Amazon Textract).

Amazon Textract описує результат так: «Every word and line comes with a bounding box and a confidence score» - кожне слово й рядок мають рамку на сторінці та оцінку впевненості.

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

Azure Document Intelligence Read може обробляти рядки зі змішаними мовами без зазначення коду мови. Microsoft застерігає: якщо ти не впевнений, яка саме мова в документі, не нав’язуй моделі конкретну. Результат може бути неповним або неправильним. У документації сказано: «Don’t provide the language code as the parameter unless you are sure of the language and want to force the service to apply only the relevant model» (підтримка мов Azure OCR).

Azure Read також створює пошуковий PDF: розпізнаний текст накладається на зображення сканованих сторінок. Такий файл зручно шукати й копіювати, водночас він візуально лишається схожим на оригінал. Опис функції належить до документації Azure Document Intelligence v4.0, тому перед упровадженням перевір поточну підтримку й умови (модель Read Azure).

Tesseract - відкритий OCR-рушій, який можна запускати локально. Його командний рядок працює з кількома мовними моделями одночасно, наприклад eng+deu. Для нейронного механізму LSTM документація наводить параметр --oem 1. Якщо мову не вказати, рушій за замовчуванням використає англійську. Параметри залежать від версії та встановлених мовних моделей (командний рядок Tesseract).

Рушій Що може бути корисним для перекладу Що перевірити перед запуском
Google Document AI Ієрархія блоків, абзаців, рядків і слів; корекція повороту; оцінка якості сторінки Потрібну мову, версію процесора, формат документа й фактичну якість на своїх сканах
Amazon Textract Координати й оцінки для слів та рядків; порядок читання; окремий витяг таблиць Потрібний API, мови для форм, якість зображень і обмеження обробки
Azure Document Intelligence Read Розпізнавання змішаних мовних рядків і створення пошукового PDF Актуальну матрицю мов, формат, рівень обслуговування та обсяг файлу
Tesseract Відкритий рушій, кілька мовних моделей, виходи hOCR і TSV Наявність мовних моделей, правильний порядок мов і потребу в попередній обробці

Ця таблиця не визначає переможця за точністю. Вона допоможе скласти короткий список для тесту. Якщо тобі потрібні координати слів і показники впевненості, перевір формат результату Textract або TSV Tesseract. Якщо важливі блоки документа й порядок читання, порівняй структурований вихід Google і Textract на тому самому багатоколонковому скані.

Перевір і формат результату. Tesseract може створювати пошуковий PDF, hOCR і TSV. hOCR містить рамки слів, а TSV може містити оцінки впевненості на рівні слова. Такі формати дають змогу побудувати власну перевірку, але команді потрібен процес, який прочитає ці дані й передасть їх далі (документація Tesseract).

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

Де кожен варіант підходить і де може підвести

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

Google Document AI варто перевірити, якщо тобі важливі структура документа, оцінка якості зображення та обробка різних форматів. Документація перелічує PDF, GIF, TIFF, JPEG, PNG, BMP і WebP. Для синхронних запитів наведено межу в п’ятнадцять сторінок, для асинхронних - у п’ятсот, а для синхронного режиму без зображень - у тридцять сторінок. Обмеження залежать від конфігурації процесора, тому перед запуском звір їх з актуальними умовами (Enterprise Document OCR).

Google також описує додаткові можливості: розпізнавання математичних формул із перетворенням у LaTeX, прапорців і властивостей стилю шрифту на рівні слова. Ці доповнення стосуються конкретних версій процесорів v2.0 та v2.1. Якщо в документі є формули або анкети з прапорцями, перевір сумісність потрібного процесора, а не покладайся лише на сам факт згадки функції в документації (Enterprise Document OCR).

Amazon Textract перевір, якщо процесу потрібні координати тексту, порядок читання або структурований витяг таблиць. Сервіс приймає JPEG, PNG, PDF і TIFF, але не підтримує PDF на основі XFA. Документація AWS наводить для асинхронної обробки PDF і TIFF межі 500 МБ і 3 000 сторінок, а для синхронної обробки таких файлів - одну сторінку й 10 МБ. Це задокументовані квоти на час перевірки. Перед упровадженням підтвердь актуальні ліміти (квоти Textract).

Якість зображення важлива й для Textract. AWS зазначає мінімальну висоту тексту в 15 пікселів, що приблизно відповідає шрифту 8 пунктів за роздільності 150 DPI, і радить надсилати зображення якнайкращої якості, бажано щонайменше 150 DPI. Ці параметри не гарантують правильного розпізнавання, але допоможуть знайти технічну причину пропусків, якщо дрібний текст зникає (квоти Textract).

Azure Document Intelligence Read перевір, якщо команда працює не тільки зі сканованими PDF, а й з іншими форматами. Документація v4.0 перелічує PDF, JPEG/JPG, PNG, BMP, TIFF і HEIF, а також DOCX, XLSX, PPTX та HTML. Для PDF і TIFF зазначено максимум у 2 000 сторінок. У платному рівні S0 вказаний ліміт розміру 500 МБ, у безплатному F0 - 4 МБ; у F0 аналізуються лише перші дві сторінки PDF або TIFF. Це значення з документації v4.0 GA, тож перевір чинні обмеження свого рівня (модель Read Azure).

Tesseract протестуй, якщо важливі відкритий інструмент, локальний запуск або контроль над форматом результату. Тут основна робота - налаштування: встановити мовні моделі, задати мову й вирішити, як обробляти поворот, перекіс і шум. OCRmyPDF використовує мовні пакети Tesseract, за замовчуванням припускає англійську й дозволяє вказати кілька мов. Документація прямо попереджає: «Unfortunately, the Tesseract OCR engine has no ability to detect the language when it is unknown» - рушій не визначає невідому мову самостійно (мови OCRmyPDF).

OCRmyPDF попереджає, що Tesseract не вміє самостійно визначити невідому мову.

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

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

Якщо команді потрібен не лише витягнутий текст, а й перекладений файл зі збереженим макетом, можна перевірити ChatsControl. Завантажуєш сканований PDF або зображення, система читає сторінку, відтворює її структуру в документі Word, а потім перекладає документ зі збереженням оформлення. Результат можна перевірити у двомовному режимі; рукописні й дуже зіпсовані скани для цього процесу підходять погано, а позначка якості показує слабкі місця розпізнавання. Такий інструмент не замінить окремий OCR-тест, якщо команда обирає рушій для власної інфраструктури.

Як провести тест OCR перед выбором

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

Почни з вибірки, схожої на реальні документи команди. Додай чисті сторінки, складні скани, таблиці, форми, багатоколонковий текст, кілька мов і ділянки з іменами, датами та числами. Якщо у потоці є і цифрові PDF, і сторінки-зображення, включи обидва типи. Окремо познач сторінки, де OCR не потрібен, бо текст уже вбудований у PDF.

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

Заздалегідь зафіксуй критерії:

  1. Слова й символи. Чи правильно розпізнані заголовки, прізвища, адреси, реквізити й спеціальні символи?
  2. Числа та дати. Чи збереглися десяткові роздільники, знаки, нулі на початку й порядок частин дати?
  3. Мови. Чи правильно рушій обробив змішані мовні рядки й назви, що не відповідають основній мові сторінки?
  4. Структура. Чи лишилися таблиці, поля форм, підписи, заголовки й колонки пов’язаними?
  5. Порядок читання. Чи може перекладач читати результат послідовно, не переставляючи рядки вручну?
  6. Перевірка. Чи є координати, оцінки впевненості або інша інформація, яка допомагає знайти сумнівні фрагменти?
  7. Передавання далі. Чи можна без зайвих перетворень передати результат у переклад, CAT-систему або на перевірку?

Не зводь оцінку до одного середнього числа. Для договору одна помилка в сумі може бути важливішою за кілька неправильно прочитаних слів у декоративному колонтитулі. Для інструкції з таблицями критично зберегти зв’язок між значенням і назвою рядка. Для архіву пошуковий PDF може бути кориснішим за структурований JSON.

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

Для кожного рушія запиши всі налаштування, що впливають на результат: мови, параметри обробки зображень, тип запиту й формат відповіді. Не порівнюй Tesseract з англійською моделлю та хмарний рушій, налаштований на потрібну мову, ніби тест був однаковим. Якщо змінюєш параметри посеред перевірки, познач новий запуск окремо.

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

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

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

Підводні камені: що перевірити у файлі й налаштуваннях

Розмиття, перекіс і неправильний поворот - різні проблеми. Вирівнювання сторінки не зробить чітким зображення, де літери злилися. Підвищення контрасту не виправить колонку, яку OCR прочитав не в тому порядку. Спершу оглянь сторінку, а вже потім вмикай обробку зображень.

OCRmyPDF розділяє поворот сторінки на прямий кут і виправлення невеликого перекосу: для першого є параметр --rotate-pages, для другого - --deskew. Документація також радить переглядати сторінки після обробки, адже очищення може пошкодити потрібний вміст (рецепти OCRmyPDF).

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

Неправильно задана мовна модель створює системну помилку. Tesseract за замовчуванням використовує англійську, якщо мову не зазначено, а OCRmyPDF не може самостійно визначити невідому мову. Azure Read працює інакше: модель може обробляти змішані мовні рядки без коду мови, а примусова мова за невпевненого вибору може дати неповний чи неправильний текст. Дотримуйся документації конкретного рушія, а не перенось налаштування з одного продукту на інший (Tesseract, OCRmyPDF, Azure).

Таблиці перевіряй окремо. Звір заголовки стовпців, об’єднані клітинки, порожні клітинки й відповідність кожного значення своєму рядку. OCR може зберегти всі слова, але втратити сенс, якщо число опиниться не в тій колонці. Textract документує витяг рядків, стовпців і об’єднаних клітинок, однак результат усе одно треба перевіряти на твоїх таблицях (FAQ Textract).

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

Перевір і тип PDF. Textract не підтримує PDF на основі XFA, а синхронна й асинхронна обробка PDF та TIFF мають різні задокументовані квоти. Перед запуском з’ясуй тип файлу, спосіб виклику сервісу й актуальні ліміти. Так технічну відмову не сплутаєш із помилкою розпізнавання (квоти Textract).

Не вважай пошуковий PDF повним текстовим архівом без перевірки. Якщо файл містить тільки текст, знайдений OCR, у змішаному PDF може зникнути текст, уже вбудований у цифрові сторінки. Перевір такі сторінки окремо або налаштуй процес, який обробляє вбудований текст і зображення (рецепти OCRmyPDF).

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

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

Що порівняти перед вибором рушія

Розділи перевірку на два запитання: чи підходить система технічно і чи зручний її результат для перекладу. Перше - про вхідний файл і формат виходу. Друге - про те, чи можна використати текст без небезпечного відновлення змісту вручну.

Критерій Запитання для тесту Що зафіксувати
Вхідний файл Чи підтримує рушій ваш PDF, скан або зображення? Формат, тип PDF і випадки відмови
Мова Чи є потрібні мови й змішані рядки? Параметри мов, пропуски, помилки в назвах
Якість сторінки Що стається з розмиттям, перекосом, поворотом і дрібним текстом? Помилки до та після попередньої обробки
Порядок читання Чи зберігаються колонки, блоки й послідовність рядків? Ручні перестановки та втрачені фрагменти
Таблиці й форми Чи пов’язані значення з потрібними заголовками та полями? Помилки в рядках, стовпцях і об’єднаних клітинках
Дані для перевірки Чи є координати або оцінки впевненості? Чи допомагають вони швидше знаходити проблемні ділянки
Передавання в переклад Яке перетворення потрібне після OCR? Кроки, формати та ручна робота

Окремо встанови, коли автоматичну обробку треба зупинити. Якщо важлива таблиця втрачає стовпці, направ сторінку на перевірку. Якщо мова невідома, не запускай Tesseract із типовими параметрами в надії, що він визначить її сам. Якщо в документі є критичні реквізити, звір їх незалежно від загальної оцінки OCR.

Результат тесту - не просто назва рушія. Запиши, для яких документів він підходить, які налаштування потрібні, коли потрібна ручна перевірка і який формат передавати в переклад. Один рушій може добре працювати з чистими друкованими формами, але підвести на рукописних позначках чи складних таблицях.

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

FAQ

Який OCR-рушій обрати для перекладу сканованих PDF?

Порівняй Google Document AI, Amazon Textract, Azure Document Intelligence Read і Tesseract на однакових сторінках, схожих на твої документи. Оцінюй не лише текст, а й мови, порядок читання, таблиці, координати та формат, потрібний наступному етапу.

Чи підходить Tesseract для багатомовного перекладу документів?

Tesseract працює з кількома мовними моделями одночасно, наприклад eng+deu, але потрібні моделі мають бути встановлені й правильно задані. Документація OCRmyPDF зазначає, що Tesseract не визначає невідому мову автоматично (мови OCRmyPDF).

Який OCR зберігає таблиці та порядок читання?

Textract документує витяг таблиць і повернення елементів сторінки в природному порядку читання, а Google Document AI - ієрархію блоків, абзаців, рядків і слів. Перевір обидва результати на власних документах: формат і поведінка залежать від API та версії.

Як перевірити точність OCR перед перекладом?

Підготуй однаковий набір цифрових PDF, сканів і складних сторінок та звір результат із ручним еталоном. Окремо перевір імена, дати, числа, мови, таблиці й порядок читання: документація не дає універсального порівняльного показника для твоїх файлів.

Чи потрібен OCR для кожного PDF?

Ні. PDF із виділюваним текстом може вже мати текстовий шар, який можна витягнути без OCR. Для сторінок-зображень потрібне розпізнавання; у змішаному файлі перевір, чи обробка охоплює обидва типи сторінок.

Чи можна перекладати документ одразу після OCR без перевірки?

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

Чи допомагає оцінка впевненості знайти помилки OCR?

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

Що робити, якщо документ має змішані мови?

Перевір рекомендації конкретного рушія. Azure Read описує роботу зі змішаними мовними рядками без коду мови й застерігає від примусового вибору невідомої мови, тоді як для Tesseract треба налаштувати відповідні мовні моделі.

Джерела

Спробуйте ChatsControl

AI-платформа для професійних перекладачів

Спробувати безкоштовно →