OCR REST API для бюро переводов: скан в Word

Когда скан тормозит работу бюро¶

Пачка сканированных страниц пришла в PDF, а переводчику нужен редактируемый Word-файл, где можно править текст, сверять цифры и сохранять структуру таблиц. Ручное перепечатывание решает задачу, но добавляет отдельную работу до перевода, а обычный OCR часто заканчивается не документом, а текстом, который ещё надо собрать в документ.

Для бюро узкое место не всегда в распознавании букв. Нужно понять, как принять файл, передать его API, дождаться результата, восстановить структуру, создать DOCX и проверить качество до передачи переводчику. Если пропустить хотя бы один этап, автоматизация даст поток текста вместо удобного рабочего файла.

OCR REST API - это интерфейс, через который программа отправляет изображение или документ на оптическое распознавание текста и получает машинный результат. REST описывает способ обмена запросами и ответами, но не обещает готовый Word, перевод или полное восстановление макета.

В документации Google Cloud Vision сказано: “Output from a PDF/TIFF request is written to a JSON file created in the specified Cloud Storage bucket.” Перевод: результат запроса для PDF или TIFF записывается в JSON-файл в указанном хранилище Cloud Storage.

Для интеграции это важное различие: OCR-провайдер распознаёт содержимое, а ваша система ещё должна связать его с заказом, собрать Word и передать файл в рабочий процесс бюро. Разбор того, почему скан сначала надо превратить в структуру, есть в руководстве о переводе сканированных документов с OCR и сохранением макета.

Что нужно построить: не один запрос, а конвейер¶

Автоматизированная конвертация scan-to-Word состоит из последовательных стадий. API распознавания - только одна из них.

1. Принять и проверить файл. Определить формат, размер, наличие пароля, число страниц и пригодность для выбранного API.
2. Сохранить исходник. Связать файл с заказом и ограничить доступ сотрудникам и сервисам, которым он нужен.
3. Запустить распознавание. Передать файл поставщику в допустимом формате и получить идентификатор задачи или адрес её статуса.
4. Дождаться завершения. Сохранить состояние задания и получать результат после окончания обработки.
5. Нормализовать данные. Привести текст, страницы, строки, координаты и сведения об уверенности распознавания к единому внутреннему формату.
6. Собрать DOCX. Создать абзацы, таблицы, заголовки и другие элементы Word из структуры распознавания.
7. Проверить результат. Направить трудные страницы на ручную проверку, а затем передать документ переводчику.

Google Cloud Vision для PDF и TIFF использует асинхронный workflow files:asyncBatchAnnotate: исходный документ размещают в Cloud Storage, а JSON-результат записывают в заданный bucket, согласно документации Cloud Vision. В REST-справочнике описан метод `POST, который возвращает ресурс Operation (справочник метода).

Azure Document Intelligence устроен иначе на уровне запроса: Analyze Document принимает документ как base64 или URL и отвечает 202 Accepted; заголовок Operation-Location содержит адрес для опроса статуса и получения результата (справочник REST API версии 2024-11-30). В обоих случаях клиентское приложение должно помнить, что задание ещё выполняется.

Практический пример: менеджер загружает многостраничный скан к заказу. Веб-приложение не должно ждать, пока OCR закончит работу, удерживая соединение открытым. Оно создаёт задание, записывает идентификатор провайдера, показывает внутренний статус и позднее забирает результат. После этого генератор Word формирует файл, а переводчик получает его как подготовленный материал, а не как набор строк из API.

Подводный камень - считать успешный ответ на отправку признаком готового результата. Ответ может означать только то, что задача принята. Если приложение не сохраняет идентификатор операции и не умеет повторно проверять статус, завершённый OCR может остаться без привязки к заказу.

Варианты API и что они реально возвращают¶

Сравнивайте не только качество распознавания, но и весь контракт: входные типы, режим обработки, формат ответа, ограничения, хранение и трудоёмкость создания DOCX. Названия вроде «PDF OCR API» ничего не говорят о том, можно ли сразу загрузить результат в Word.

Azure Read распознаёт печатный и рукописный текст, а также определяет абзацы, строки, слова, их расположение и языки согласно документации модели Read v4.0. Результат outputContentFormat для REST-вызова может быть текстом или Markdown: текст не содержит форматирования, а Markdown представляет такие элементы, как заголовки секций и таблицы (описание Analyze Document).

Ни текст, ни Markdown не становятся DOCX от смены расширения. Файл Word построен как пакет OOXML, внутри которого есть отдельные части и свойства форматирования абзацев и фрагментов текста; описание формата приводит Библиотека Конгресса США. Генератор должен создать корректную структуру Word и распределить распознанное содержимое по её элементам.

Для Azure Read документация также описывает поисковый PDF с внедрённым распознанным текстом. Поисковый PDF удобен для поиска по содержимому, но не является экспортом в Word, как поясняет описание Read. Если переводчику необходим редактируемый DOCX, этот вариант не отменяет этап сборки.

Бюро может выбрать готовую систему обработки документов, если ей достаточно структурированных данных. В одном из документированных подходов к обработке документов API поддерживает OAuth 2.0, управление файлами, отслеживание состояния и получение JSON или XML; доступный результат описан как извлечённые данные, а не редактируемый Word. Отдельная документация по API указывает на варианты последовательности вызовов и на единый сценарий, но интеграция требует учётной записи арендатора и учётных данных клиента (описание начала работы). Для решения о покупке проверьте доступ к документации и контракт именно в вашей среде, а не предполагайте наличие DOCX-экспорта.

Таблица выбора для руководителя бюро¶

Короткий чек-лист ниже поможет сравнить API до начала разработки. Заполняйте его на реальных типах документов, которые поступают в бюро: договор, справка, форма с полями, многостраничный скан или документ с печатями.

Проверяйте ограничения по версии и тарифу API. Например, документация Azure Document Intelligence Read v4.0, API версии 2024-11-30, описывает обработку PDF и TIFF до 2 000 страниц; бесплатный уровень обрабатывает только первые две страницы. В той же документации указаны максимальные размеры анализируемого файла 500 MB для S0 и 4 MB для F0 (условия Read v4.0). Эти ограничения относятся к указанной версии и тарифным уровням, а не к любому OCR API.

Для Google Cloud Vision документация, доступная на момент исследования, указывает предел до 2 000 страниц для асинхронного распознавания PDF и TIFF; запрос сверх этого предела возвращает ошибку (описание PDF/TIFF). Такое ограничение стоит проверять до постановки задания в очередь: иначе система будет повторять заведомо невыполнимый запрос.

Как устроить асинхронную обработку и сборку Word¶

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

1. Создайте запись задания. Зафиксируйте внутренний идентификатор заказа, исходный файл, поставщика и начальное состояние.
2. Проверьте и сохраните файл. Отклоните неподдерживаемый или заблокированный документ до обращения к OCR.
3. Отправьте запрос. Запишите полученный идентификатор Operation или адрес Operation-Location.
4. Проверяйте состояние. Используйте очередь или планировщик, а не длительный открытый запрос браузера.
5. Заберите результат. Для Google Cloud Vision скачайте JSON из настроенного bucket после завершения операции; для Azure используйте адрес из Operation-Location.
6. Сохраните исходный результат. Храните его отдельно от сформированного DOCX, чтобы повторная сборка не требовала нового OCR-запроса.
7. Сформируйте внутреннюю модель. Сведите поля ответа разных провайдеров к общим объектам: документ, страница, строка, координаты и текст.
8. Создайте Word и проверьте его. Сформируйте элементы DOCX, затем сравните отображение и содержимое с исходником.

Внутренняя модель позволяет не привязывать генератор Word к единственному API. Один поставщик может возвращать структуру в JSON, другой - Markdown или текст. Адаптеры преобразуют разные ответы к общему представлению, а компонент сборки DOCX работает с одним форматом данных. Если менять провайдера, переписывать весь этап создания Word не придётся.

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

Azure описывает ответ Analyze Document как асинхронный: запрос возвращает 202 Accepted, а заголовок Operation-Location указывает адрес для проверки результата (документация REST API версии 2024-11-30).

Для пользователя приложения этот контракт означает понятный рабочий статус: «файл принят», «распознавание выполняется», «нужна проверка» или «Word готов». Не показывайте «готово» после ответа 202; задача принята, но её результат ещё не получен.

В типовом процессе бюро генератор может сначала создать Word для проверки распознавания, а переводчик затем работать с этим DOCX. Если нужен не только OCR, но и перевод документа с сохранением макета, ChatsControl предлагает отдельный путь: загрузить сканированный PDF или фотографию, получить распознанный текст и сформированный Word с расположением элементов страницы. Это вариант обработки документа, а не замена CAT-системе или TMS: в нём нет управления памятью переводов и проектными сегментами. Для рукописных и сильно повреждённых сканов всё равно нужна проверка человеком.

Качество OCR и маршрутизация на проверку¶

OCR нельзя оценивать только по тому, что API вернул ответ. Для бюро важен вопрос, можно ли доверить результат переводчику без дополнительного просмотра каждой строки. Разделите проверку на два уровня: качество исходного изображения и качество сформированного Word.

Плохое качество исходника может дать пропуски, неверные символы и неправильное прочтение печатей или дат. Azure Read рекомендует для лучшего результата предоставлять «one clear photo or high-quality scan per document» - одну чёткую фотографию или качественный скан на документ (документация Read v4.0). Та же документация указывает, что защищённый паролем PDF нужно разблокировать до отправки, а минимальные размеры входного изображения составляют 50 × 50 пикселей, максимальные - 10 000 × 10 000 пикселей.

В качестве правил маршрутизации задайте признаки, которые требуют внимания: сомнительная читаемость, пропущенные участки, таблица с нарушенными колонками, печать поверх текста или рукописная правка. Если API предоставляет confidence scores - оценки уверенности распознавания, сохраните их на уровне фрагментов, а не только всего документа. Низкая оценка отдельного слова полезнее общего предупреждения, потому что проверяющий сразу видит, где смотреть.

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

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

Возможный встроенный подход для команды, которая хочет работать с уже готовым документом, - ChatsControl с двуязычным просмотром: исходник и перевод показаны рядом, а автоматические проверки помогают заметить проблемы с числами, именами, терминами и пропусками. Такой просмотр полезен на этапе постредактирования, но не заменяет проверку исходного скана и не превращает сервис в средство управления проектами бюро.

Подводные камни: безопасность, стоимость и отказоустойчивость¶

Главная ошибка интеграции - отправлять любой клиентский файл в облако, не выяснив, кому доступны входной и выходной объекты. Для Google Cloud Vision PDF и TIFF должны находиться в Cloud Storage, а сервисной учётной записи нужен доступ к исходному bucket и право записи в bucket результата. Документация указывает, что API-ключ для таких асинхронных запросов не поддерживается (условия доступа Google Cloud Vision).

До запуска проверьте, кто может читать исходные файлы, кто получает JSON и сколько хранится копия. Внутренняя политика бюро должна описывать, какие документы допустимо обрабатывать у выбранного облачного поставщика, кто выдает доступ и как удаляются промежуточные данные. Технический ответ API не подтверждает, что обработка разрешена условиями конкретного заказа.

Вторая ошибка - не учитывать разницу между OCR и Word. Распознанный текст может содержать нужные слова, но терять колонки таблицы, подписи полей или порядок блоков. Документ DOCX устроен как набор структурированных частей, а не как текстовый файл с расширением .docx; детали формата описаны Библиотекой Конгресса. Генератор должен создавать структуру, а не просто помещать весь текст в один абзац.

Третья ошибка - оценивать расходы только по ставке за распознавание. Опубликованный тариф Google Cloud Vision, проверенный в ходе исследования, указывает $1.50 за 1 000 единиц в диапазоне от 1 000 до 5 000 000 единиц для распознавания текста в многостраничных PDF; первые 1 000 единиц каждого месяца указаны как бесплатные. Тариф может меняться, поэтому перед расчётом бюджета проверьте актуальную страницу цен и отдельно учтите возможное хранение файлов.

Четвёртая ошибка - повторно запускать OCR при каждом сбое генерации DOCX. Сохранённый результат распознавания позволяет повторить создание Word без повторной обработки исходника. Разделяйте состояния: «OCR завершён», «нормализация завершена», «DOCX собран», «проверка пройдена». Тогда перезапуск одного этапа не приводит к дублированию остальных.

Пятая ошибка - не задавать пределы и проверки для входных файлов. В документации Azure Read v4.0 описаны разные ограничения для тарифных уровней, а для Google Cloud Vision указан предел страниц для PDF и TIFF. Проверка файла до отправки помогает вернуть человеку понятную причину отказа, а не оставить его разбираться с ошибкой провайдера после запуска задачи.

Перед пилотом пройдите чек-лист:

• [ ] Уточнены допустимые форматы, размеры и ограничения по страницам для выбранной версии API.
• [ ] Заблокированные паролем PDF обнаруживаются до отправки.
• [ ] Сервисная учётная запись имеет только необходимые права на входные и выходные файлы.
• [ ] У каждого задания сохраняются заказ, провайдер, идентификатор операции и состояние.
• [ ] Повторная проверка статуса не создаёт новое OCR-задание.
• [ ] JSON или текстовый ответ сохраняется отдельно от DOCX.
• [ ] Генератор создаёт таблицы и абзацы, а не файл с одним сплошным текстом.
• [ ] Сложные страницы можно направить переводчику или оператору на проверку.
• [ ] В бюджете учтены не только API-запросы, но и хранение и обработка промежуточных данных.

FAQ¶

Как бюро переводов автоматизировать конвертацию сканированного PDF в Word через REST API?¶

Проверьте файл и его страницы, сохраните исходник, отправьте асинхронный OCR-запрос и сохраните идентификатор задания. После завершения получите результат, приведите его к внутренней структуре, сформируйте DOCX и направьте сомнительные страницы на проверку.

Возвращает ли OCR API редактируемый DOCX?¶

Не всегда. Google Cloud Vision для PDF и TIFF возвращает JSON в Cloud Storage, а Azure Document Intelligence поддерживает текст и Markdown; оба варианта требуют отдельной логики создания DOCX. Проверьте формат ответа конкретного API до разработки.

Как обрабатывать асинхронные OCR-задания для многостраничных PDF?¶

Сохраните идентификатор операции или адрес Operation-Location и периодически проверяйте статус отдельным процессом. После завершения заберите результат из хранилища или по адресу операции, а затем запустите сборку Word.

Сколько стоит OCR API на страницу?¶

Тариф зависит от поставщика, типа распознавания и объёма. В опубликованном тарифе Google Cloud Vision, проверенном во время исследования, указана цена $1.50 за 1 000 единиц в диапазоне от 1 000 до 5 000 000; первые 1 000 единиц каждого месяца указаны как бесплатные (страница тарифов). Проверьте действующие цены и возможные расходы на хранение перед планированием бюджета.

Безопасно ли отправлять клиентские сканы в облачный OCR API?¶

Одного факта, что API доступен по HTTPS, недостаточно для решения. Бюро должно проверить условия обработки поставщика, разрешения на хранилища, доступ сотрудников, срок хранения файлов и требования клиента к облачной обработке.

Можно ли перевести распознанный текст и сразу получить готовый Word?¶

Да, если связать OCR с переводом и генератором DOCX либо использовать инструмент для обработки документов, который объединяет эти действия. OCR API сам по себе не гарантирует перевод и восстановление макета: текст, перевод и создание Word остаются отдельными стадиями.

Источники¶

• Detect text in files (PDF/TIFF) - Cloud Vision API
• Method: projects.files.asyncBatchAnnotate - Cloud Vision API
• Cloud Vision Pricing
• Read model OCR data extraction - Azure Document Intelligence v4.0
• Document Models - Analyze Document REST API, version 2024-11-30
• DOCX Transitional (Office Open XML), ISO 29500 and ECMA-376