Сто страниц сканов и один оператор: когда распознавание текста дешевле, чем перепечатать

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

Восемь месяцев назад в накладной вместо ИНН 7707083893 в базу уехало 7707083839. Две последние цифры поменялись местами — обычная опечатка усталого человека на семидесятом документе за день. Платёж ушёл не туда, вернулся через одиннадцать дней, контрагент успел выставить неустойку. Разбирались две недели.

После этого в компании ввели двойной ввод: реквизиты набивают два человека независимо, система сравнивает. Опечатки почти исчезли. Стоимость приёмки документов выросла ровно вдвое.

Это и есть та развилка, на которой обычно вспоминают про распознавание текста. Дальше — как оно устроено сейчас, во что обходится ручная приёмка в часах и где у машины заканчиваются полномочия.

Где именно течёт

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

Сколько это стоит в часах и когда окупается

Считать «экономию от OCR» в процентах бессмысленно — цифра получится любой. Считать надо в секундах на поле, и допущения я назову вслух, чтобы вы подставили свои.

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

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

Стоимость запросов при этом остаётся далеко позади стоимости часов. Одна страница — один запрос, сто двадцать документов по одной-две страницы — меньше трёхсот запросов в день. Цена одного запроса — десятки копеек, актуальная цифра на странице тарифов: она меняется, а статья остаётся. Триста запросов в день — это порядка полутора сотен рублей, то есть примерно стоимость получаса работы человека против пяти сэкономленных часов. Разрыв не астрономический, но десятикратный, и он устойчив к тому, что цена подрастёт.

Как это встроить, чтобы работало

Порядок такой, и последний шаг важнее первых.

Шаг первый: приведите страницу в разумный вид. На вход метода уходит картинка в Base64, и после декодирования она должна укладываться в десять мегабайт. Скан А4 в 300 dpi весит 2–5 МБ и проходит спокойно, так что бороться за килобайты не нужно. Полезно другое: не гнаться за разрешением вверх. 600 dpi в цвете там, где хватает 200–300 в сером, не добавляет точности — этот запас нужен мелкому шрифту в сносках, а не основному тексту, — зато удлиняет обработку каждой страницы, и на пакете из тысячи листов разница уже измеряется часами. Заодно выпрямите перекос: кривой скан с тенью от сгиба портит результат сильнее, чем что-либо ещё.

Шаг второй: отправьте страницу в сервис «Распознавание текста». Целиком, одним запросом. Карта зон с координатами прямоугольников под каждый тип документа не нужна: разметку макета сервис строит сам. Резать страницу на куски имеет смысл в одном случае — когда конкретное поле на плохом скане читается неуверенно и вы хотите переспросить по нему отдельно, указав mode: "digits" там, где ожидаются только цифры. Тогда цифра «0» перестаёт превращаться в букву «O».

Шаг третий: вытащите поля из Markdown, а не из пикселей. В ответе приходит текст с сохранённой структурой, и зацепки в нём смысловые: подпись «ИНН» и число за ней, шапка столбца «Сумма» и колонка под ней. Такой разбор переживает смену вёрстки бланка, чего нельзя сказать про координаты прямоугольника, которые ломались от каждого нового шаблона накладной.

Шаг четвёртый — и он обязательный: проверьте результат тем, что вы про поле знаете. Сервис отдаёт текст и не отдаёт оценку уверенности, поэтому доверие к ней вы строите сами. ИНН юрлица — ровно 10 цифр со сходящейся контрольной суммой. Расчётный счёт — 20 цифр и своя контрольная сумма с БИК. Дата — разбирается в календарную. Сумма — сходится с суммой строк. Каждая такая проверка стоит вам нисколько и ловит именно те ошибки, которые делает OCR: перепутанный символ, лишний или потерянный.

Всё, что не прошло проверку, уходит человеку. Всё, что прошло, — тоже уходит человеку, но уже в режиме «посмотри и нажми Enter».

Код: страница и один запрос

Все примеры работают с публичным демо-ключом ak_sandbox_demo_mockdata_v1 — копируйте и запускайте, регистрация не нужна. На демо-ключе API отдаёт моки: содержимое выдумано, но форма ответа настоящая — заголовок, абзацы и Markdown-таблица с сошедшимся итогом, ровно как отдаёт боевой движок. Это сделано намеренно: разбор ответа, написанный на песочнице, должен работать и с личным ключом, а не разваливаться при первом реальном запросе. Ответы детерминированы — одна и та же картинка всегда даёт один и тот же результат, поэтому на песочнице удобно писать тесты конвейера. Настоящее распознавание работает только с личным ключом.

Метод один: POST /api/ocr/image-to-text. В теле — JSON с картинкой в Base64.

# Картинка кодируется в Base64 и уходит в теле запроса.
# -w0 нужен, чтобы base64 не разбил строку переносами.
IMG=$(base64 -w0 page_01.jpg)

curl -X POST "https://atlorium.com/api/ocr/image-to-text" \
     -H "Authorization: Bearer ak_sandbox_demo_mockdata_v1" \
     -H "Content-Type: application/json" \
     -d "{\"image\":\"$IMG\"}"
        

import base64
import requests

BASE = "https://atlorium.com"
HEADERS = {"Authorization": "Bearer ak_sandbox_demo_mockdata_v1"}


def recognize(img_bytes: bytes, digits_only: bool = False) -> str | None:
    """Возвращает распознанный текст либо None, если распознать не удалось."""
    resp = requests.post(
        f"{BASE}/api/ocr/image-to-text",
        json={
            "image": base64.b64encode(img_bytes).decode(),
            "mode": "digits" if digits_only else "auto",
        },
        headers=HEADERS,
        timeout=30,
    )

    # 503 — источник недоступен. Кредиты при этом не списываются,
    # так что повторить запрос позже ничего не стоит.
    if resp.status_code == 503:
        return None
    resp.raise_for_status()

    data = resp.json()
    # recognized=false означает «читаемого текста не нашли». Это не ошибка
    # запроса и не повод для retry: тот же файл даст тот же результат.
    if not data["recognized"]:
        return None

    # truncated=true — страница длиннее предела одного ответа, текст обрезан.
    # Внешне такой ответ неотличим от полного, поэтому проверять поле обязательно:
    # молча принять обрезанный документ хуже, чем не принять никакой.
    if data.get("truncated"):
        send_to_operator("Страница распознана не полностью")
        return None

    return data["text"]


with open("page_01.jpg", "rb") as f:
    page = recognize(f.read())

if page is None:
    send_to_operator("Страница не распознана")
else:
    # Ищем реквизит по подписи в тексте, а не по координатам на картинке.
    inn = find_after_label(page, "ИНН")

    if inn is None or not valid_inn_checksum(inn):
        send_to_operator(f"ИНН не подтверждён: {inn}")
    else:
        save(inn)
        

using System.Net.Http.Json;
using System.Text.Json;

var http = new HttpClient { BaseAddress = new Uri("https://atlorium.com") };
http.DefaultRequestHeaders.Add("Authorization", "Bearer ak_sandbox_demo_mockdata_v1");

var bytes = await File.ReadAllBytesAsync("page_01.jpg");

var payload = new
{
    image = Convert.ToBase64String(bytes),
    mode = "document",   // страница целиком: и цифры, и текст
};

var resp = await http.PostAsJsonAsync("/api/ocr/image-to-text", payload);

// 503 — сервис недоступен или перегружен, списания не было: можно повторить позже.
if (resp.StatusCode == System.Net.HttpStatusCode.ServiceUnavailable)
    return null;

resp.EnsureSuccessStatusCode();
var card = await resp.Content.ReadFromJsonAsync<JsonElement>();

var recognized = card.GetProperty("recognized").GetBoolean();
// text приходит null, когда recognized=false, — читать его без проверки нельзя.
var text = recognized ? card.GetProperty("text").GetString() : null;

// format сообщает, ЧТО лежит в text: "markdown" (страница с разметкой),
// "plain" (короткая строка) или "latex" (формула). Выбирать разбор по этому
// полю надёжнее, чем угадывать по содержимому.
var format = card.GetProperty("format").GetString();

// units — во сколько единиц работы обошёлся запрос: по ним он и тарифицирован.
// Короткая строка это всегда 1, страница — столько, сколько на ней областей.
var units = card.GetProperty("units").GetInt32();

// truncated=true — текст обрезан по пределу длины, страница неполная.
var truncated = card.GetProperty("truncated").GetBoolean();

var elapsedMs = card.GetProperty("elapsedMs").GetInt64();
        

{
  "recognized": true,
  "format": "markdown",
  "truncated": false,
  "text": "## Товарная накладная № 4417 от 12.03.2026\n\nПоставщик: ООО «Ромашка», ИНН 7707083893\n\n| № | Наименование | Кол-во | Сумма |\n|---|---|---|---|\n| 1 | Короб 600x400 | 120 | 43 200,00 |\n| 2 | Стретч-плёнка | 15 | 8 250,00 |\n\nИтого: 51 450,00",
  "elapsedMs": 1180
}

# Читаемого текста не нашлось — плата за такой запрос не берётся:
{
  "recognized": false,
  "text": null,
  "format": "plain",
  "truncated": false,
  "elapsedMs": 940
}
        

Полей в ответе пять, и одну вещь стоит принять как данность при проектировании: вся структура страницы приезжает разметкой внутри text, отдельных полей под координаты слов или список вариантов в ответе нет. Что делать с каждым:

Из кодов ошибок в конвейере важны три. 400 — картинка не передана, битый Base64 или файл больше десяти мегабайт: чинится на вашей стороне, кредит не тратится. 429 — упёрлись в лимит запросов, конвейер надо притормозить. 503 — движок временно недоступен или перегружен, и вот здесь важная деталь: деньги за такой запрос не списываются. Пакет можно спокойно поставить в очередь и прогнать через полчаса.

Отдельно про темп. На клиента отведено 60 запросов в минуту — ровно страница в секунду, и это осознанно много: сервис задуман под пакетную оцифровку, где меньший темп просто бессмысленен. Но параллелить сверх этого не нужно даже не из-за 429: страницы считает одна видеокарта, и запросы сверх её пропускной способности встают в очередь. Практический вывод для конвейера — увеличивать параллелизм, пока растёт скорость пакета, и останавливаться, когда начинает расти elapsedMs. Момент, когда время ответа поползло вверх при тех же картинках, и есть точка насыщения; дальше вы добавляете не производительность, а длину очереди.

И одна честная оговорка про песочницу. Структуру ответа мок повторяет точно, но вашу картинку он не читает — использует её лишь как зерно генератора, поэтому текст в ответе никак не связан с тем, что на изображении. И мок всегда отвечает recognized: true с truncated: false: ветки recognized: false и обрыва по длине на демо-ключе воспроизвести нельзя, тестировать их придётся подстановкой ответа в своём коде.

Чего распознавание не умеет

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

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

Оценки уверенности нет. Есть только recognized: да или нет. Промежуточного «распознал, но не уверен» не существует, и порог «отправить оператору при уверенности ниже 0,8» построить не на чем. Роль этого порога у вас играют проверки формата и контрольные суммы реквизитов — их придётся написать. Это не отговорка: для ИНН, счёта и суммы контрольная сумма надёжнее любого внутреннего скора модели, потому что проверяет само значение, а не то, насколько уверенно оно прочиталось.

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

Тяжёлые PDF — отдельная история. Сама модель PDF на вход принимает, но метод image-to-text работает с растровой картинкой, поэтому многостраничный файл вы рендерите в страницы у себя и отправляете постранично. Это не временная недоделка, а осознанная граница: постраничный рендер на своей стороне даёт вам контроль над dpi и цветом — то есть над скоростью и ценой пакета. Для случаев, где важны электронные подписи, слои и сложная вёрстка, планируется отдельный сервис — обещать его как готовый я не буду, потому что его пока нет.

Сервис не подскажет, что это за документ. Классификация типа, сопоставление контрагента с базой, решение «проводить или отклонить» — всё это остаётся вашему коду. Модель отвечает на один вопрос: «какой текст на этой странице и как он там расположен». Что этот текст значит для вашего бизнес-процесса, она не знает.

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

Частые вопросы

curl -H "Authorization: Bearer ak_sandbox_demo_mockdata_v1" \
     https://atlorium.com/openapi/ocr_ru.json