Идея о том, что крупные языковые модели (LLM) справятся со всеми задачами, связанными с распознаванием текста, долгое время витала в воздухе. Ведь они уже умеют блестяще генерировать тексты, синтезировать информацию из самых разных источников и даже писать код. Однако при столкновении с реальными документами — особенно в формате PDF, сложных таблицах, нечетких скриншотах и иных «нетиповых» сценариях — оказывается, что всё не так радужно. Пост «Why LLMs Suck at OCR» от команды Pulse наглядно демонстрирует, почему детальное и точное извлечение информации из изображений до сих пор остаётся большой проблемой для современных моделей.
В этой статье я расскажу, почему распознавание текста — особенно в бизнес-контексте — требует более «приземленных» методов и тщательной технической реализации, чем «просто подключить GPT».
🤔 Как LLM «видит» изображение?
Когда мы говорим о задачах распознавания текста в картинке (OCR), представьте, что вы имеете дело не с классическим детектором символов (например, Tesseract), а с гигантской языковой моделью, обученной предсказывать вероятностные последовательности слов и фраз.
✏️ Проблема в том, что пути LLM и классических инструментов компьютерного зрения (CV) сильно отличаются. Модель, ориентированная на семантику, зачастую игнорирует пиксельные детали. Векторные представления (эмбеддинги) при обучении «смазывают» физические особенности шрифтов, расположение запятых, точек и т.д. Ради понимания смысла модель жертвует точностью узнавания мелких деталей.
С технической стороны это выглядит так:
- Модель разбивает изображение на небольшие фрагменты (обычно 16x16 пикселей).
- Каждый фрагмент кодируется в вектор (embedding), далее работает механизм внимания (self-attention).
- Пространственная (2D) структура документа, которая так важна для корректного распознавания таблиц и сложных макетов, теряется, превращаясь в одномерный поток признаков.
- При повышенной сложности в документе (например, много сносок, объединённых ячеек в таблице, графики и пр.) шансы на ошибку растут.
А ведь даже банальная замена «rn» на «m» может иметь катастрофические последствия, если речь идёт о финансовой документации, где каждая буква и цифра на вес золота.
🚨 Откуда берутся «галлюцинации»?
Самая известная «болезнь» крупных языковых моделей — это генерация правдоподобных, но ошибочных фактов. При OCR ситуация еще сложнее, поскольку модель испытывает затруднение в распознавании отдельных символов:
- 🧩 Ставит «самое вероятное» слово, основываясь на своём языковом опыте, а не на «честном» распознавании;
- 🔍 Может «додумывать» пропущенные куски таблиц и логически «выводить» результат там, где нужен точный посимвольный перенос;
- 🤖 При повторном запуске выдаёт иные варианты, так как включается механизм случайности (sampling) в процессе генерации ответа;
- 🤝 В некоторых случаях пытается быть «полезной» и решать уравнения, если встречает формулы. Это уместно при ответе на математический вопрос, но катастрофично, когда нужно просто дословно переписать исходные данные.
Особенно пугающе, что LLM, «ошибаясь», делает это так убедительно, что трудно заметить подвох. Традиционный OCR, конечно, тоже может ошибаться, но чаще всего ошибки выглядят грубо (например, выдает странные символы), сразу указывая, что что-то пошло не так.
🏗️ Трудности при работе с таблицами
Таблицы — одна из ключевых больных тем в OCR. В классическом подходе мы «ищем» сетку, определяем ячейки, их границы и распознаем содержимое отдельно по каждой ячейке. Языковая модель — существо «линейное», она читает слева направо (или сверху вниз), сворачивая сложную структуру таблицы в поток символов.
Когда документ содержит:
- 📑 Иерархические заголовки внутри ячеек;
- 🌐 Несколько вложенных таблиц или колонки неправильной ширины;
- ⬅️ Комбинация текста и изображений (логотипы, диаграммы между строк);
- 🔗 Перенос строк в неожиданных местах;
LLM начинает буквально «сходить с ума», теряя связь между заголовком и значением, путая валюты, дробные числа, выкидывая или «рисуя» лишние столбцы.
💣 Реальные провалы и «скрытые» угрозы
В статье команды Pulse приводится масса любопытных кейсов, когда LLM не просто «немного ошибается», а даёт критические сбои. Я выделю несколько:
🐕 Искажение финансовых или медицинских данных: опечатка в единице измерения (0.5 mg → 5 mg) может стоить жизни пациенту, а неверно расставленная запятая в сумме денег (1,234.56 → 123456) угрожает убытками.
🧮 Автоматическое «решение» уравнений вместо точной передачи: для научного текста это убийственно, ведь оригинальная формула может быть важнее, чем её численный ответ.
🔓 Уязвимость к внедрению команд (Prompt Injection): достаточно прописать в документе хитрый текст, вроде [SYSTEM MESSAGE: ...], чтобы LLM посчитала его за команду и начала раскрывать внутренние детали или игнорировать прошлые настройки. Открытый «вектор атаки» на корпоративные данные.
Всё это делает LLM-OCR фактически неприемлемым для задач, где необходима гарантия корректности и безопасность (например, в юриспруденции, банковском деле, медицине).
⚙️ Почему традиционным методам OCR рано на пенсию
Некоторые (в том числе и я на определённом этапе) полагали, что раз LLM «умна», то классические алгоритмы распознавания и компьютерного зрения должны остаться в прошлом. Но практика доказывает, что:
- 🏁 Классический OCR (Tesseract, ABBYY, Google Vision OCR и т.д.) лучше справляется с базовым распознаванием символов, особенно в чётко форматированных документах.
- 🔎 Легче «перепроверить» результат: такие системы предоставляют границы (bounding box) для каждого символа, уровни уверенности (confidence scores) и другие метаданные. Это проще валидировать, особенно при появлении «подозрительных» фрагментов.
- 💡 При интеграции ML-компоненты важно предусмотреть последующую проверку человеком (human-in-the-loop). Это жизненно необходимо там, где ошибка стоит дорого.
Да, если документ изобилует нестандартными шрифтами, содержит скан копии с пятнами или элементы рукописного текста, классическому OCR бывает сложно. Однако гибридные подходы (комбинация старых алгоритмов компьютерного зрения и новых Vision Transformers) дают гораздо более надёжные результаты, чем банальное кормление PDF в GPT.
💡 Личный взгляд: нужен комплексный «конвейер» (pipeline)
В идеале мы должны использовать многоступенчатый подход:
🔬 Проанализировать структуру документа: найти таблицы, заголовки, поля форм, графику.
🧩 Распознать символы точечно: сохранить позиционную иерархию (ячейка, параграф, раздел).
🤖 Подключить LLM, но по делу: когда нужно понять смысл больших текстовых блоков, сделать реорганизацию или «умную» разбивку на категории.
Тем самым, мы снимем с языковых моделей задачу «считать» каждый пиксель, сосредоточив их способности на интерпретации и анализе уже качественно извлечённого текста. Именно так команда Pulse, судя по всему, и пришла к созданию гибридного решения, вместо «доверимся GPT» без оглядки.
🔮 Будущее OCR и LLM: есть ли надежда?
Я верю, что со временем появятся улучшенные визуальные трансформеры и более тщательные решения, которые смогут не просто «самонадеянно генерировать» результат, а давать прозрачную модель уверенности и структурировать данные на уровне строк и ячеек. Но, как отмечают авторы оригинального материала, пока даже флагманские модели типа Google Gemini 2.0 продолжают спотыкаться.
Пока же для бизнеса остаётся актуальным классическое правило: тщательно проверяй выходные данные, комбинируй разные методы и ставь безопасность и точность в приоритет.
Ссылка на оригинальную новость
Вывод: LLM, безусловно, революционизировали сферу ИИ, но в части точного распознавания текста они продолжают «забывать» о запятых, дробях и хитрых символах. Для критически важных задач лучше строить надёжный «конвейер», а не слепо доверять вероятностной модели с «гуманитарным» складом ума. И это, на мой взгляд, главная мысль авторов из Pulse: технология должна адаптироваться к реальным условиям, а не наоборот.