Скан приходить як PDF, перекладачеві потрібен редагований Word, а клієнт уже чекає кошторис і дедлайн. Якщо кожен файл треба відкривати вручну, копіювати текст і відновлювати таблиці, гальмує не переклад - гальмує підготовка документа.
REST API може автоматизувати розпізнавання, але не обов’язково видасть готовий DOCX. Щоб налаштувати процес для агенції, з’єднайте перевірку файлу, OCR, обробку асинхронного завдання, відновлення структури Word і контроль якості.
Що має робити scan-to-Word процес¶
OCR API для агенції перекладів - це програмний інтерфейс, який приймає документ або посилання на нього, розпізнає текст і повертає результат у визначеному форматі. Розпізнавання саме собою не створює готовий Word: API може повернути текст, координати блоків, структуровані дані чи JSON, а DOCX доведеться зібрати окремо.
Ось як може виглядати процес від завантаження до перекладу:
- Файл надходить від клієнта або з внутрішньої системи замовлень.
- Сервіс перевіряє формат, доступність, пароль і кількість сторінок.
- Документ потрапляє до сховища, доступ до якого має лише потрібний компонент.
- Оркестратор надсилає завдання до OCR API.
- Система зберігає ідентифікатор операції та відстежує її стан.
- Після завершення система нормалізує результат у внутрішній формат агенції.
- Генератор створює DOCX, а перевірка звіряє його з оригінальними сторінками.
- Сторінки з невпевненим розпізнаванням або складним макетом передаються на ручну перевірку.
- Перекладач отримує документ із текстом і структурою, придатними для роботи.
Такий поділ допомагає швидко знайти, де сталася помилка. Якщо OCR правильно прочитав текст, але таблиця в Word розвалилася, збій стався під час відновлення макета. Якщо завдання зависло й результат не з’явився, перевіряйте обробку операцій і сховище, а не генератор DOCX.
Google Cloud Vision обробляє PDF і TIFF асинхронним методом files:asyncBatchAnnotate: запит повертає ресурс Operation, а результат сервіс записує у JSON-файл у вказаний Cloud Storage bucket. Документація Cloud Vision для PDF і TIFF чітко показує: розпізнавання й отримання готового Word - окремі речі.
У документації Google сказано: “Output from a PDF/TIFF request is written to a JSON file created in the specified Cloud Storage bucket.”
Отже, результат OCR - це не готовий перекладений DOCX. Інтеграції потрібні місце для JSON, перетворення відповіді у внутрішню модель і окремий етап створення Word-файлу.
Не змішуйте OCR, переклад і верстку. OCR читає сторінку, переклад змінює мову тексту, а генератор DOCX вирішує, де розмістити текст - в абзацах, таблицях і полях. Коли всі три операції злиті в один незрозумілий крок, команді важче визначити причину помилки.
Які можливості перевірити під час вибору API¶
Не вибирайте API лише за точністю розпізнавання. Для процесу агенції важливі формати документів, спосіб передавання файлів, асинхронна обробка, тип відповіді, обмеження за розміром і спосіб перевірити статус.
| Критерій | Google Cloud Vision для PDF/TIFF | Azure Document Intelligence Read |
|---|---|---|
| Як передати документ | PDF або TIFF має бути в Cloud Storage | Вміст документа в base64 або джерело за URL |
| Як отримати результат | JSON у Cloud Storage | Результат аналізу через адресу операції |
| Тип результату | OCR-дані, не готовий DOCX | Текст або Markdown, не готовий DOCX |
| Асинхронний процес | Ресурс Operation і подальше опитування Operations API | HTTP-відповідь 202 Accepted і URL у заголовку Operation-Location |
| Обмеження для багатосторінкового PDF/TIFF | До 2 000 сторінок | До 2 000 сторінок у документації Read версії 4.0 |
| Додаткові вимоги | Обліковий запис сервісу з доступом до вхідного й вихідного bucket | Версія API, модель, джерело документа та параметри запиту |
Формат запиту Google описаний у REST-довіднику методу asyncBatchAnnotate, а обмеження за сторінками й доступ до сховищ - у документації Google Cloud Vision. Azure Read версії 4.0 приймає PDF, JPEG/JPG, PNG, BMP, TIFF, HEIF та офісні формати, зокрема DOCX, XLSX, PPTX і HTML. Список форматів є в документації Read.
Відрізняється не лише формат відповіді. Google вимагає, щоб PDF або TIFF лежав у Cloud Storage, а результат потрапляв у bucket. Отже, інтеграції треба контролювати обидва сховища й права доступу. Azure REST API приймає документ у запиті як base64 або посилання на джерело, а параметр сторінок дає змогу вибрати, яку частину документа аналізувати. Для Azure також можна передати підказку щодо мови, наприклад en або en-US; подробиці є в описі Analyze Document REST API.
Azure повертає текст або Markdown. Документація описує Markdown як формат із такими елементами, як заголовки розділів і таблиці. Але ні текст, ні Markdown не є DOCX. Тож запитайте не лише «який OCR прочитає сторінку?», а й «які дані потрібні генератору Word?».
Якщо агенція вже має сховище й інфраструктуру Google Cloud, Cloud Vision може вписатися в наявну систему. Якщо ваша інтеграція працює з Azure і вам потрібно вибирати сторінки, Analyze Document має відповідний параметр. В обох випадках доведеться окремо подбати про статуси завдань і створення DOCX.
У таблиці немає універсального переможця. Якщо команді бракує інженерного ресурсу на асинхронні завдання, зберігання результатів і генерацію Word, нижча ціна OCR-запиту не обов’язково здешевить увесь процес.
Як DOCX формується з результату OCR¶
DOCX - це пакет OOXML, у якому зберігаються структура документа й властивості форматування. Просто записати plain text із розширенням .docx не вийде: генератор має розмістити розпізнаний текст у структурі абзаців, фрагментів і таблиць.
Опис формату DOCX від Бібліотеки Конгресу США пояснює, що DOCX - це ZIP-пакет із частинами Office Open XML. Абзаци й фрагменти тексту мають власні властивості, тому для відновлення документа треба зіставити текст зі структурою, а не просто зберегти послідовність символів.
На практиці почніть із проміжного представлення. Не будуйте Word безпосередньо з відповіді провайдера: спершу зведіть різні відповіді до власної моделі - сторінка, блок, рядок, текст, координати, тип елемента, мова й оцінка впевненості, якщо API її надає. Тоді заміна провайдера або генератора не змусить переписувати весь процес.
Розміщення тексту залежить від типу сторінки. Звичайний лист можна перетворити на кілька абзаців. Формі треба зберегти зв’язок між міткою й полем. Таблиця має залишитися таблицею, а не перетворитися на рядки, розділені пробілами. Печатку чи підпис можна залишити як зображення в контексті сторінки, навіть якщо OCR не прочитав їхній текст.
Координати особливо важливі для документів із кількома колонками або текстом біля печаток. OCR може повернути слова, але генератор має визначити порядок читання. Якщо він помилиться, перекладач побачить фрагменти з різних колонок як один суцільний абзац.
Визначте, що означає «готовий до перекладу» для кожного типу документа. Для простого листа перевірте, що всі абзаци на місці й ідуть у правильному порядку. Для анкети збережіть поля й підписи. Для договору перевірте нумерацію, таблиці та посилання на додатки.
Наприклад, OCR повернув усі слова зі сторінки, але зчитав рядок ліворуч, а потім рядок праворуч у двоколонковому макеті. Кількість розпізнаних символів може виглядати переконливо, хоча зміст уже переплутаний. Тож перевіряйте не лише наявність тексту, а й порядок блоків і відповідність Word оригінальній сторінці.
Як побудувати асинхронний процес і не загубити завдання¶
Асинхронний API не повертає весь результат у першій відповіді. Система надсилає завдання, отримує його ідентифікатор або адресу операції, а потім перевіряє, чи завершилося розпізнавання. Збережіть стан операції окремо від з’єднання з клієнтом - тоді процес не залежатиме від того, чи залишається це з’єднання відкритим.
Google Cloud Vision повертає довготривалий ресурс Operation. Клієнт перевіряє його через Operations API, а після завершення забирає JSON із налаштованого bucket. Цей процес описаний у документації Google щодо PDF і TIFF.
Azure Analyze Document повертає HTTP 202 Accepted, а в заголовку Operation-Location передає адресу для перевірки результату. Асинхронний цикл описаний у розділі Analyze Document REST API.
Оркестратору потрібні щонайменше внутрішній ідентифікатор замовлення, провайдер, ідентифікатор зовнішньої операції, час подання, поточний стан і місце збереження результату. Внутрішній ідентифікатор прив’язує OCR-відповідь до замовлення навіть після перезапуску сервісу. Ідентифікатор провайдера дає змогу знову звернутися до операції, а не навмання створювати нове завдання.
Опишіть стани завдання окремо: файл перевірено, документ завантажено, OCR подано, OCR виконується, результат отримано, DOCX формується, потрібна перевірка, готово або помилка. Так підтримка бачитиме, де зупинився процес. Статусу «обробляється» замало, якщо він може означати і очікування OCR, і невдале читання вихідного JSON.
Для тимчасових збоїв передбачте повторні спроби, але не запускайте нове завдання після кожного тайм-ауту, не перевіривши стан попереднього. Інакше система може обробити один документ двічі й створити два DOCX. Зробіть повторне подання ідемпотентним: запит із тим самим внутрішнім ключем не має непомітно створювати копію завдання.
Google Cloud Vision має окремі вимоги до доступу: PDF і TIFF не можна обробляти через API-ключ, потрібен обліковий запис сервісу з доступом до вхідного й вихідного bucket, зокрема з правом запису у вихідний. Це описано в офіційній документації Cloud Vision. Перевірте права до того, як подасте великий пакет документів, а не після помилки під час запису результату.
Azure endpoint приймає посилання на джерело або документ у форматі base64, а параметр pages дає змогу опрацьовувати вибрані сторінки. Наприклад, команда може використати його, коли перевіряє якість лише частини документа. Але вибір сторінок не замінює перевірки цілісності: зафіксуйте пропущені сторінки, щоб вони не зникли з перекладу непомітно.
Скільки коштує OCR API і що рахувати в бюджеті¶
Рахунок за API - лише частина вартості scan-to-Word. Додайте до бюджету зберігання вхідних і проміжних файлів, розробку оркестратора, генерацію DOCX, контроль якості й ручну роботу зі складними сторінками.
У тарифній таблиці Google Cloud Vision, перевіреній під час дослідження, розпізнавання тексту в багатосторінкових PDF коштувало $1.50 за 1 000 одиниць у діапазоні від 1 000 до 5 000 000 одиниць; перші 1 000 одиниць кожного місяця були безплатними. Перед складанням бюджету звірте чинний тариф Cloud Vision: ціна може змінитися, а зберігання може оплачуватися окремо.
| Стаття витрат | Що рахувати | Чому її легко пропустити |
|---|---|---|
| OCR-запити | Сторінки або інші тарифні одиниці, які тарифікує провайдер | Обсяг файлу й кількість сторінок не завжди означають однакову кількість оплачуваних одиниць |
| Зберігання | Вхідні файли, проміжні дані та результати | Google Cloud Vision використовує bucket для джерела й JSON-відповіді |
| Інтеграція | Валідація, черги, обробка статусів і помилок | REST-запит не створює повний процес замовлення |
| DOCX-реконструкція | Формування абзаців, таблиць, полів і зображень | Текстовий результат API не є готовим Word |
| Перевірка | Звіряння тексту, порядку читання та макета | Поганий результат може бути формально заповненим, але непридатним до перекладу |
| Ручне виправлення | Час редактора або оператора для складних сторінок | Рукопис, низька якість і складна верстка потребують окремої уваги |
Не діліть рахунок провайдера на кількість документів і не вважайте результат повною собівартістю. Розбийте документи на групи: звичайний друкований текст, таблиці, форми, багатоколонкові сторінки й документи з рукописом. Потім перевірте, скільки сторінок у кожній групі проходять без ручного втручання.
Для агенції корисніший показник, ніж «ціна одного OCR-запиту», - вартість підготовленої до перекладу сторінки. Він охоплює і розпізнавання, і виправлення помилок, і відновлення Word. Дешевший API може не зменшити загальні витрати, якщо редактор витрачає більше часу на виправлення результату.
Порахуйте й повторні запуски. Інтеграція може повторно подати документ після зміни параметра запиту або виявлення проблеми з файлом. Фіксуйте причину кожного повтору й відокремлюйте тимчасовий збій від повторної обробки після зміни налаштувань.
Окремо рахуйте час на ручну перевірку. Зіставте, скільки часу займає перегляд сторінки з друкованим текстом і сторінки з формою, печаткою чи поганим сканом. Не встановлюйте одне правило для всіх документів: для простого листа може вистачити автоматичної звірки, а таблицю з ідентифікаційними даними потрібно уважно перевірити - помилка в одному символі може змінити зміст.
Контроль якості: від скану до перекладу¶
Не оцінюйте OCR лише за тим, чи API відповів без помилки. Перевірте кількість сторінок, порядок блоків, важливі числа, імена, дати, таблиці й поля. Текст може виглядати повним, але в ньому може бракувати рядка або бути неправильно прочитаний символ.
Azure радить подавати одне чітке зображення або якісний скан. Для моделі Read версії 4.0 документація встановлює межі зображення від 50 × 50 до 10 000 × 10 000 пікселів; захищений паролем PDF треба розблокувати до подання. Ці вимоги описані в документації Azure Read версії 4.0.
Перед цитатою Microsoft Learn ось саме її практична порада:
Microsoft Learn радить: “For best results, provide one clear photo or high-quality scan per document.”
Зрозуміти її просто: API не зробить поганий оригінал якісним. Перед завантаженням перевірте, чи читається документ, чи немає перекосу, чи відкриті важливі поля та чи можна відкрити PDF без пароля.
Розділіть автоматичні правила й людську перевірку. Автоматично позначайте документи з розбіжністю в кількості сторінок, порожнім результатом або пропущеними важливими полями. Людині передавайте сторінки, де система не може впевнено визначити структуру таблиці, порядок колонок або зв’язок між полем і підписом.
Не плутайте якість розпізнавання зі статусом перекладу. Сторінка може бути добре розпізнана, але мати зіпсований макет. Акуратний DOCX, своєю чергою, може містити неправильно прочитану дату. Перевіряйте текст і верстку окремо, щоб не оголосити готовим документ, у якому готова лише одна частина.
Уявімо скан із датою, номером документа й прізвищем. OCR може правильно передати більшість тексту, але помилитися в одному символі. Складіть список полів, які треба звіряти з оригіналом у кожному документі, і не покладайтеся лише на загальну оцінку якості сторінки.
Azure Read може повернути searchable PDF - PDF із вбудованим розпізнаним текстом. Такий файл зручний для пошуку, але це не експорт у DOCX. Якщо перекладачеві потрібен редагований Word, пошуковий шар не замінить відновлення структури документа.
Три способи організувати процес у агенції¶
Можна розпізнавати скани вручну, під’єднати REST API або взяти документний сервіс, який сам виконує частину перетворення. Вибір залежить від обсягу й складності файлів, наявної інфраструктури та того, чи потрібен агенції власний інтегрований процес.
| Підхід | Що відбувається | Коли підходить | Основне обмеження |
|---|---|---|---|
| Ручна підготовка | Оператор відкриває скан, розпізнає або передруковує текст і створює Word | Нерегулярні замовлення або сторінки, які потребують уважної роботи | Час оператора й повторення однакових дій |
| Власна REST-інтеграція | Система подає файл в OCR API, стежить за завданням, будує DOCX і перевіряє результат | Коли потрібен контроль над потоком, сховищами та внутрішніми статусами | Агенція сама підтримує код, обробку помилок і реконструкцію |
| Документний інструмент | Користувач передає скан у сервіс, який розпізнає текст і формує документ для перекладу | Коли потрібна готова робота з документом без побудови власного API-процесу | Менше контролю над внутрішньою логікою, а складні скани все одно потребують перегляду |
Власна інтеграція стане в пригоді, коли агенція має вимоги до внутрішніх систем, хоче сама обирати провайдера або повинна керувати передаванням файлів і статусами. Але вона не обмежується REST-запитом: доведеться налаштувати сховище, автентифікацію, обробку операцій, внутрішню модель результату, генерацію DOCX і контроль якості.
Якщо вам передусім потрібен редагований файл для перекладу, а не власний OCR-конвеєр, порівняйте API зі спеціалізованим документним інструментом. У ChatsControl можна завантажити сканований PDF або зображення: система розпізнає сторінки, а потім формує Word-файл зі структурою, наближеною до макета оригіналу. Такий варіант підходить для завдань із перекладу документів і збереження верстки, але не замінює повноцінну TMS чи CAT-систему з пам’яттю перекладів і командним керуванням проєктами.
Для чистих друкованих сканів інструмент може заощадити на розробці власного конвертера. Рукописний або дуже зіпсований документ однаково треба перевірити вручну: обмеження щодо рукопису й поганих сканів наведені в описі продукту. Порівнюйте не просто «скан на вході, Word на виході», а й те, чи можна перевірити результат і знайти сумнівні рядки.
У сервісі також можна переглядати джерело й переклад поруч. Це допомагає перекладачеві звіряти результат під час редагування, але не звільняє від перевірки якості скану й відновленого макета.
Покроковий план запуску та типові помилки¶
Спершу визначте, який результат вважатимете успіхом: розпізнаний текст, редагований DOCX чи документ, який уже можна передавати перекладачеві. Потім побудуйте невеликий наскрізний процес і перевірте його на різних типах сторінок, перш ніж під’єднувати всі замовлення.
- Опишіть вхідні файли. Зафіксуйте, які типи файлів надходять, звідки вони беруться та як агенція визначає кількість сторінок. Перевірте, чи відкривається документ, чи він не захищений паролем і чи відповідає вимогам провайдера.
- Оберіть сховище та модель доступу. Визначте, де зберігатимуться оригінал, результат OCR і сформований DOCX. Для Google Cloud Vision перевірте доступ облікового запису сервісу до джерела й право запису в сховище результату за документацією API.
- Подайте асинхронне завдання. Збережіть ідентифікатор операції або адресу для перевірки її стану. Google повертає ресурс Operation, а Azure передає адресу операції в заголовку Operation-Location; подробиці є в REST-довіднику Google та REST-довіднику Azure.
- Нормалізуйте результат. Перетворіть відповідь провайдера на внутрішню структуру сторінок, блоків, координат і тексту. Збережіть дані, потрібні генератору DOCX, а не лише суцільний текст.
- Створіть Word-документ. Відновіть абзаци, таблиці, поля й порядок читання. Не змінюйте розширення текстового файлу на
.docx: скористайтеся генератором, який створює пакет OOXML, як описано в довідці Бібліотеки Конгресу США. - Перевірте текст і макет. Зіставте кількість сторінок, критичні числа, імена, дати й таблиці. Позначте сторінки для ручного перегляду, перш ніж віддавати документ перекладачеві.
- Зафіксуйте результат і помилки. Збережіть зв’язок між замовленням, операцією провайдера та фінальним DOCX. Окремо показуйте невдале завантаження, недоступний результат, помилку генерації та рішення передати документ на перевірку.
Одна з типових архітектурних помилок - чекати, що REST-виклик спрацює синхронно й одразу поверне результат. Google Cloud Vision повертає операцію, а Azure Analyze Document - відповідь 202 Accepted з адресою для подальшої перевірки. Якщо система не зберігає стан, повторний запит може створити дублікат або залишити файл без зрозумілого статусу.
Інша помилка - продумувати DOCX уже після вибору формату виходу OCR. Генератору можуть бути потрібні координати, межі блоків і тип елемента, тоді як plain text не зберігає достатньо інформації для відновлення таблиць. Узгодьте внутрішню модель із відповіддю API до того, як вирішите, як формуватиметься Word.
Не відправляйте кожну сторінку на ручну перевірку без пріоритетів. Інакше команда витрачатиме час на однакові перевірки навіть для простих сторінок. Визначте ризикові поля й структури - дати, номери, таблиці та підписи - і використовуйте автоматичні сигнали, щоб вибирати сторінки для перегляду.
Перед запуском перевірте, що відбувається в разі часткового успіху. Якщо OCR обробив лише частину документа, агенція має бачити, які сторінки отримали результат, а які треба повторити. Не формуйте фінальний Word так, ніби пропущених сторінок не було: неповний документ може пройти швидку перевірку й потрапити в переклад.
Ще одна помилка - надсилати клієнтський скан у хмару, не звіривши це з внутрішньою політикою агенції. Перегляньте договори й правила обробки документів, визначте, які файли можна передавати зовнішньому провайдеру, і налаштуйте потрібний рівень доступу до сховища. Документація API пояснює технічний доступ, але не визначає, чи має агенція дозвіл на обробку конкретних матеріалів.
FAQ¶
Як агенції перекладів автоматизувати перетворення сканованого PDF у Word через REST API?¶
Перевірте файл, передайте його в асинхронний OCR-сервіс і збережіть ідентифікатор операції. Після завершення заберіть результат, нормалізуйте текст і структуру, сформуйте DOCX та передайте сумнівні сторінки на перевірку.
Чи повертає OCR API редагований DOCX?¶
Не обов’язково. Google Cloud Vision для PDF і TIFF записує результат у JSON, а Azure Document Intelligence повертає текст або Markdown; для обох варіантів DOCX треба створювати окремо.
Як обробляти асинхронні OCR-завдання для багатосторінкових PDF?¶
Збережіть ідентифікатор операції, перевіряйте її стан і заберіть результат після завершення. Передбачте повторні спроби й тайм-аути, щоб тимчасовий збій не створив дубль, а незавершене завдання не загубилося.
Скільки коштує OCR API за сторінку?¶
Ціна залежить від тарифу провайдера, кількості сторінок і додаткових витрат. У тарифі Google Cloud Vision, перевіреному під час дослідження, розпізнавання багатосторінкових PDF коштувало $1.50 за 1 000 одиниць у діапазоні від 1 000 до 5 000 000 одиниць, а перші 1 000 одиниць на місяць були безплатними; перед бюджетуванням звірте чинний прайс.
Чи безпечно надсилати клієнтські скани в хмарний OCR API?¶
Безпека залежить від правил агенції, договору з клієнтом і вимог до обробки документа. Перевірте умови зберігання та доступу у провайдера, обмежте доступ до файлів і не передавайте матеріали, для яких хмарна обробка заборонена.
Хто відповідає за помилки розпізнавання перед перекладом?¶
Агенція визначає, коли результат OCR готовий до перекладу, і встановлює правила перевірки критичних даних. Відповідь API не гарантує, що кожне ім’я, число чи фрагмент таблиці прочитаний правильно.
Чи можна подати лише окремі сторінки документа на OCR?¶
Azure Analyze Document підтримує параметр pages для вибіркового опрацювання сторінок; можливість описана в REST-довіднику Azure. Збережіть перелік пропущених сторінок у замовленні, щоб вони не зникли з фінального процесу непомітно.
Чим OCR для PDF відрізняється від перетворення PDF у Word?¶
OCR читає текст зі сторінки, а перетворення у Word додатково відновлює структуру й розміщення вмісту. Без відновлення таблиць, абзаців і полів перекладач може отримати текст, який правильно розпізнано, але незручно редагувати.