Распознавание рукописного текста — задача, которая остаётся болезненной даже в 2025 году. Именно это не позволяет оцифровать многие архивы и документы, а также является камнем преткновения в разной бизнес деятельности.

 OCR-движки вроде Azure Document Intelligence, Google Vision или ABBYY уже давно научились безошибочно читать печатные формы, но всё рушится, когда на сцену выходит человек с ручкой.

Почерк — это хаос, в котором буквы скачут, строки уползают, а “5M” внезапно превращается в “5 PM”, если повезёт. И если обычный OCR видит только буквы и пиксели, LLM видит смысл.

Производители заявляют, что модели вроде GPT-5, Gemini 2.5 Pro и Claude Sonnet 4.5 способны не просто распознать текст, а догадаться, что автор имел в виду: исправить пунктуацию, восстановить сокращения, даже понять, что стоит за пометками на полях.

Звучит красиво. Но работает ли это на реальных документах, а не в демо-видео с идеально отсканированными формами?  Чтобы ответить, мы провели исследование и сравнили, как три топ-LLM обрабатывают рукописные и смешанные документы — с точки зрения точности, структурной консистентности и понимания контекста.

Содержание

  1. Методология

    1. Что мы тестировали

    2. Как мы тестировали

    3. Почему три модели?

  2. Как справились модели

    1. Формуляр в Музей трамваев (Streetcar Museum Event Form)

    2. Анкета для фотооархива (“Johnny – King of Sausages” Photo Form)

    3. Форма для смены в больнице (Change of Shift Huddle)

  3. Кто победил?

    1. Себестоимость и скорость

    2. А можно ли лучше?

    3. Пример на практике: Azure Document Intelligence + Gemini 2.5 Pro

    4. Что делать, когда облако – не вариант?

  4. Заключение и выводы

Методология

Что мы тестировали

Документы, которые мы отдавали в LLM
Документы, которые мы отдавали в LLM

Чтобы не скатиться в синтетические бенчмарки, мы взяли три реальных документа, типичных для корпоративных сценариев, где OCR-ошибки могут стоить времени и денег:

  1. Формуляр мероприятия в Музей трамваев (Event Form to Streetcar Museum)

  2. Анкета для фотооархива (Photo Submission Form “Johnny – King of Sausages”)

  3. Форма для смены в медицинском учреждении (Medical Change of Shift Huddle Form)

Каждый документ имеет свои особенности и сложности для OCR и LLM:

  1. Формуляр в Музей трамваев – смешанные шрифты, наложения текста, пересекающиеся строки и неоднозначные цифры

  2. Анкета для фотооархива – курcив, капс, подписи, апострофы и артефакты от скана старой бумаги

  3. Форма для смены в больнице – несколько почерков, медицинские сокращения, пересекающиеся сетки таблиц

Как мы тестировали

Для чистоты эксперимента:

  • Все три документа поданы в неизменном виде, без предварительной очистки изображений.

  • Каждая модель получала один и тот же ввод (скан) и задачу: извлечь данные в структурированном JSON.

  • Оценка велась вручную и по метрикам:

    • CA (Character Accuracy) – сколько символов распознано корректно

    • FA (Field Accuracy) – сколько полей правильно извлечено

    • SA (Semantic Accuracy) – насколько правильно понят смысл и контекст

    • C (Completeness) – доля извлечённых полей от ожидаемого

    • S (Schema Consistency) – единообразие JSON-структуры между документами

Почему три модели?

Особенности каждой LLM
Особенности каждой LLM

Для эксперимента были выбраны три модели разных архитектурных подходов:

  1. Claude Sonnet 4.5 — фокус на интерпретации и языковом рассуждении;

  2. Gemini 2.5 Pro — структурная точность и стабильность вывода;

  3. GPT-5 — сильная контекстная и семантическая обработка.

Это позволило оценить не только базовую точность OCR, но и то, как модели восстанавливают смысл, формат и структуру данных после распознавания.

Как справились модели

1. Формуляр в Музей трамваев (Streetcar Museum Event Form)

Эта форма — старомодный бланк с полями вроде Sponsor, Date of Event, Category, Mailing Address. Часть напечатана, часть вписана вручную — и именно это делает задачу интересной.

Основные сложности:

  • строки налезают на границы таблиц;

  • одни слова написаны капсом, другие — курсивом;

  • рукописные цифры 2 и 5 путаются с буквами S и Z;

  • некоторые поля («Tour» с обведённым кружком) требуют не просто OCR, а понимания логики формы.

Как LLM справились с музейным формуляром
Как LLM справились с музейным формуляром

Claude 4.5 справился посредственно: понял суть, но несколько полей спутал, а слова вроде “Cultural” превратил в мифических существ (“Scolyunile”). Он явно склонен к «творческой интерпретации».

Gemini 2.5 Pro показал почти безупречный результат. Он не только правильно распознал все поля, но и нормализовал их формат: аккуратные даты, выровненные адреса, единый стиль JSON. Даже догадался, что “5M” — это “5 PM”, и восстановил недостающие запятые.

GPT-5 занял второе место. Он хорошо понял смысл, корректно обработал сложные фразы вроде “Share the fun of a streetcar ride…”, но слегка потерял структурность — часть данных «сплющил» в одну строку.

Итог: Gemini — образцовый инженер, GPT-5 — умный редактор, Claude — вдохновлённый поэт.

2. Анкета для фотооархива (“Johnny – King of Sausages” Photo Form)

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

Как LLM справились с анкетой
Как LLM справились с анкетой

Claude 4.5 всё понял правильно, но внёс хаос в ключи — где-то snake_case, где-то CAPS, а где-то просто пропустил пустые поля.

Gemini 2.5 Pro снова показал себя с лучшей стороны: идеально воспроизвёл текст, сохранил пунктуацию (даже кавычки в “King of Sausages”), выстроил вложенные секции “WHEN / WHERE / WHO” и сдал JSON, который можно прямо загружать в базу.

GPT-5 чуть проиграл по структурной чистоте, но оказался лучшим по естественности текста. Он сгладил орфографические неровности и исправил регистр, делая результат ближе к «читаемому человеку описанию».

Итог: Gemini — идеален для продакшена, GPT-5 — ближе к “human-readable”, Claude — опять решил, что JSON — это рекомендация, а не стандарт.

 3. Форма для смены в больнице (Change of Shift Huddle)

Форма с дежурства — таблица, где вписаны имена, числа, состояния пациентов и короткие заметки вроде “MRSA developing in a patient” или “Wiping down the surfaces”.

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

Как LLM справились с медицинской формой
Как LLM справились с медицинской формой

Claude 4.5 сработал лучше, чем ожидалось: правильно распознал числовые поля и основные секции (Team, Advocate, Motivate), но перепутал имена и местами дублировал значения.

Gemini 2.5 Pro снова лидер: он сохранил структуру таблицы, корректно распределил имена по колонкам, а странное «Einnish» (OCR-ошибка) — единственный заметный промах. При этом общая точность полей — 99 %.

GPT-5 показал сильное понимание контекста: фраза “Extremely busy but managed well” была не просто прочитана, а осмыслена как unit status. Но часть имён он перепутал (“Mac” вместо “Max”) — классическая жертва OCR.

Итог: Gemini вновь впереди, GPT-5 почти догнал, Claude — стабильный, но не продакшен-уровень.

Кто победил?

После десятков прогонов трёх LLM по реальным рукописным формам результат оказался довольно однозначным — Gemini 2.5 Pro уверенно вырвался вперёд по всем формальным метрикам.

Метрика

Claude Sonnet 4.5

Gemini 2.5 Pro

GPT-5

Комментарий

Character Accuracy

(сколько символов распознано корректно)

93–97 %

98–99 %

97–98 %

Gemini чище по символам, Claude чаще теряет пробелы и пунктуацию

Field Accuracy (сколько полей правильно извлечено)

90–96 %

99–100 %

96–98 %

Gemini безошибочно выстраивает ключи и значения

Semantic Accuracy (насколько правильно понят смысл и контекст)

95–98 %

99–100 %

98–99 %

GPT-5 чуть сильнее в логике, но слабее в форме

Completeness (доля извлечённых полей от ожидаемого)

96–100 %

100 %

96–100 %

Все трое неплохо, но Gemini стабильно полон

Schema Consistency (единообразие JSON-структуры между документами)

Средняя

Очень высокая

Высокая

JSON у Gemini можно подавать в прод без пост-обработки

Если коротко:

  • Gemini 2.5 Pro показал лучшую комбинацию точности (до 99 %) и структурной стабильности.

  • GPT-5 чуть уступает в формализме, но сильнее в семантическом «понимании» текста.

  • Claude 4.5 часто ошибается в полях, но умеет красиво пересказывать — что полезно для описательных задач.

Себестоимость и скорость

Мы замеряли не только качество, но и цену и время обработки, потому что в продакшене важно не просто «чтобы красиво», а чтобы дёшево и предсказуемо.

Модель

Стоимость на документ (USD)

Среднее время обработки

Примечание

Claude Sonnet 4.5

0.0165

~ 75 с

Быстрее, но дороже и менее точен

Gemini 2.5 Pro

0.0080

~ 90 с

Оптимальное соотношение цена / качество

GPT-5

0.0094

~ 120 с

Медленнее, но стабильно выдаёт контекстно-богатый результат

Что это значит:

  • Обработка одного рукописного документа в Gemini стоит достаточно дёшево.

  • Claude — самое «дорогое вдохновение», но не лучший вариант, если счёт идёт на тысячи страниц.

  • GPT-5 — универсал: если нужно чуть больше глубины в понимании текста, разница в 30 секунд может быть оправдана.

А можно ли лучше? 

Когда речь идёт о распознавании реальных документов, ни один инструмент в одиночку не идеален. OCR прекрасно видит буквы, но не понимает смысла. LLM — наоборот: понимает смысл, но не знает, где на картинке что написано.

Поэтому оптимальная архитектура гибридная:
OCR → LLM → Валидация.

Оптимальная гибридная архитектура
Оптимальная гибридная архитектура

Пример на практике: Azure Document Intelligence + Gemini 2.5 Pro

  1. Azure DI делает то, что умеет лучше всего — распознаёт текст, возвращает bounding-box координаты и confidence-оценку для каждого слова.

  2. Gemini 2.5 Pro принимает этот результат и:

    • исправляет очевидные OCR-ошибки («5M» → «5 PM», «SBO» → «SBO Card»);

    • нормализует формат (даты, капитализацию, пунктуацию);

    • собирает данные в чистый JSON;

    • при необходимости восстанавливает контекст («Tour» отмечено кружком — значит, выбрано).

  3. Система валидации проверяет поля с низкой уверенностью Azure и подставляет исправления Gemini.

После того как мы применили этот подход, мы получили лучшие результаты. Вместе эти инструменты формируют систему, где человек нужен только в спорных случаях, а всё остальное идёт автоматически. Вот результаты:

  • точность полей выросла с ~84 % (Azure DI в одиночку) до ~99 %;

  • ручная проверка сократилась на 90–95 %;

  • JSON стал полностью пригоден для загрузки в базу без ручного редактирования.

Что делать, когда облако – не вариант? 

Облачные OCR и LLM-платформы вроде Gemini, GPT-5 или Azure Document Intelligence уже обеспечивают почти идеальную точность и масштабируемость.
 

Но не все компании могут позволить себе отправить документ в облако и дождаться JSON.  Иногда это просто запрещено политиками безопасности. 

Если данные нельзя выносить в облако, ту же логику можно воспроизвести локально:
Внутренний OCR → приватная LLM.

Локальная реализация гибрида
Локальная реализация гибрида

Локальный гибрид может быть идеален для некоторых компаний компаний, поскольку:

  1. Никакие данные не покидают инфраструктуру организации.

  2. Модели можно обучать и настраивать на образцах почерка, характерных для конкретной бизнес-темы.

  3. Работает в отключенных сетях или в средах с высоким уровнем безопасности.

  4. Единовременная стоимость установки и неограниченное использование.

  5. Возможность прямой подачи данных во внутренние озера данных или ERP-системы без внешних зависимостей.

Заключение и выводы

LLM действительно умеют читать почерк — не идеально, но с пониманием.
И если раньше «распознать рукописную форму» означало час ручной чистки Excel, то теперь это вопрос одной модели и пары API-вызовов.

После трёх десятков тестов, сотен строк JSON и пары нервных шуток про курсив можно сделать несколько уверенных выводов.

  1. LLM-OCR перестал быть экспериментом.
    Гибриды вроде Azure DI + Gemini 2.5 Pro уже сегодня обеспечивают до 99 % точности и сокращают ручную проверку на 90–95 %.

  2. Gemini 2.5 Pro — оптимальный выбор для продакшена.
    Высокая структурная точность, стабильный JSON и лучшая цена за страницу делают его рабочей лошадкой enterprise-уровня.

  3. GPT-5 — лидер в понимании контекста.
    Он «думает» о смысле текста, но требует строгих схем и валидации, если данные идут в базу.

  4. Claude 4.5 Sonnet — отличный интерпретатор и storyteller, но не всегда детерминирован.
    Хорош для описательных задач, не для бухгалтерии.

  5. On-prem OCR — не про экономию, а про суверенность данных.
    Его выбирают не те, кто хочет сэкономить, а те, кто не может позволить себе облако.

Комментарии (2)


  1. remzalp
    13.11.2025 10:18

    1. Qwen-VL почему не поучаствовал в тесте? - как пример вполне себе открытой модели?

    2. Почему только английский язык?

    3. Была бы полезной ссылка на исходники в оригинальном качестве - для оценки и независимых тестов.


  1. SurMaster
    13.11.2025 10:18

    Злободневная для меня тема. Как раз бьюсь над решением проблемы с распознаванием кропов определенных полей в ЖД накладных с рукописным текстом, причем не всегда он русский, а может быть английским, китайским, вьетнамским.
    Добился распознавания почти всех 6 необходимых для извлечения полей до 95-99% точности, кроме одного (где не могу перейти планку в 85%), где могут присутствовать: печати и штампы разных цветов, зачеркнутый разными ручками текст (который нужно извлечь и не весь, а частично по определенным паттернам), артефакты сканирования, необычные способы написания чисел и букв. Из этого поля надо извлечь только одно число. Испробованы: DeepSeek-OCR, GPT-5, Gemini, PaddleOCR, Tesseract и еще куча менее известных. Построен довольно хитрый конвейер из обученной YOLO - специализированной OCR - LLM - постпроцессинг (эвристика+regex).
    Если добьюсь 95% точности на оставшемся поле, это можно будет считать победой. Пожелайте удачи ))
    Есть мысль обучить отдельный доп классификатор на рукописных цифрах, но мне кажется что эта овчинка не стоит выделки по затратам время/качество.
    Что ж так в ЖД все сложно-то и не структурировано!