Представьте, что на стол одновременно падают 500 кредитных заявок. В каждой - сканы паспорта, выписка из банка, справка о доходах, налоговая форма. Всё упаковано в PDF с безликими именами вроде upload1.pdf, upload2.pdf и так далее.
Если разбирать это вручную, потребуется неделя работы нескольких сотрудников: открыть каждый файл, понять, что за документ перед нами, вытащить из него нужные поля, перепроверить. Старый "автоматический" путь тоже не радовал: приходилось писать отдельный парсер под каждый формат, жёстко привязываясь к шаблонам и расположению полей, а потом молиться, чтобы банк не поменял макет, шрифт или порядок строк.
Эта эволюция - от распознавания букв до реального понимания документа - и есть главная линия развития технологий работы с документами. От чистого OCR к ADE: от Optical Character Recognition к системам Automated / Advanced Document Extraction, которые не просто "читают", а разбираются, что именно написано и как это устроено на странице.
---
Документ - это больше, чем текст
Главная ошибка старых подходов в том, что документ рассматривался как длинная строка символов. На самом деле это почти никогда не так.
Документы - это:
- таблицы, где смысл зашит в структуру строк и столбцов;
- графики, в которых важна форма линии, масштаб осей, подписи;
- блок‑схемы, где логика процесса выражена в стрелках и фигурах;
- печати и штампы с изогнутым текстом по окружности;
- рукописные пометки на полях;
- чекбоксы и радиокнопки, где важен не текст, а факт отметки.
Все эти элементы несут информацию, но каждый - в своей форме. На них нельзя смотреть, как на обычный линейный текст.
---
Часть 1. OCR: машина, которая видит буквы, но не понимает страницу
Долгие годы единственным массовым инструментом для оцифровки документов был OCR - технологии оптического распознавания символов. Их задача предельно узка: превратить картинку в последовательность букв и цифр.
Как работал классический OCR
Один из самых известных движков - Tesseract, созданный в лабораториях HP ещё в 1985 году. Логика была простой:
1. Разбить изображение на строки.
2. В каждой строке выделить слова.
3. Слова порезать на отдельные символы.
4. Каждый символ сравнить с эталонами и выбрать наиболее похожий.
Основа - жёстко заданные признаки:
- наличие замкнутых контуров (у "О" есть замкнутый контур, у "F" - нет);
- соотношение ширины и высоты символа;
- количество пересечений с горизонтальными линиями;
- характерные "крючки", уголки, диагонали.
Классификатор решал: "Эта фигура больше похожа на B, чем на 8" - и выдавал букву. На идеально отсканированных однотипных документах это работало приемлемо. Но стоило смениться шрифту, появиться шуму, перекосу или неаккуратной печати - качество резко падало.
---
Часть 2. Современный OCR: нейросети вместо ручных правил
Новые движки, вроде тех же PaddleOCR, почти полностью отказались от ручной инженерии признаков. Главную работу делают нейросети.
Типичный стек:
- CNN (свёрточная сеть) сама "выучивает", что важно:
- первые слои фиксируют простые элементы - края, линии, углы;
- промежуточные - сложные сочетания, части букв;
- финальные - целостные символы и даже целые фрагменты текста.
- Трансформер (например, SVTR) добавляет контекст:
- символ рассматривается не поодиночке, а в окружении соседей;
- размытую букву в слове "привет" легче распознать, когда видно "_ривет".
Ключевой плюс современных OCR - они возвращают не просто текст, а ещё и bounding box'ы: координаты прямоугольников вокруг каждого текстового блока. То есть машина знает и "что написано", и "где это написано" на странице.
Но даже этого оказывается мало.
---
Фундаментальная проблема: OCR не понимает структуру
Посмотрим, что происходит с двухколоночной научной статьёй. Классический пайплайн OCR идёт по строкам слева направо, сверху вниз.
Результат:
- текст из левой и правой колонок перемешивается в кашу;
- в таблицах числа отрываются от заголовков столбцов;
- подписи к осям графиков оказываются посреди основного текста;
- сноски, колонтитулы и вставки "врезаются" в основной поток.
Причина проста: OCR решает задачу распознавания символов, а не задачу понимания документа. Архитектурно он смотрит на страницу "через трубочку": видит один символ, затем следующий и так далее.
Никакого глобального представления о макете страницы у него нет и быть не может - этим он просто не занимается.
Это не "баг, который можно допилить", а принципиальное ограничение: OCR не знает, где таблица, где заголовок, где подпись к рисунку, где боковая колонка с комментариями.
---
Часть 3. Layout Detection: взгляд на страницу целиком
Следующий шаг в эволюции - Layout Detection: модель, которая смотрит на документ как на цельное изображение и отвечает на вопрос: какие типы регионов здесь есть и где они расположены.
Такая модель:
- находит отдельные блоки - параграфы, колонки, таблицы, графики, заголовки, подписи, колонтитулы;
- рисует вокруг них ограничивающие прямоугольники;
- для каждого прямоугольника даёт метку типа: "table", "title", "paragraph", "figure", "footer" и т.п.
Ключевое отличие в пайплайне:
- если модель понимает, что перед ней таблица, она не разворачивает её в линейный текст, а сохраняет структуру строк и ячеек;
- если это колонка, она читает её сверху вниз, целиком, прежде чем переходить к следующей;
- если это подпись к рисунку, она связывает её именно с этим изображением, а не с абзацем ниже.
Layout Detection даёт ответ на два вопроса:
1. Где находятся смысловые блоки?
2. Что они собой представляют?
Но остаётся ещё одна больная тема.
---
Порядок чтения: отдельная и нетривиальная задача
После OCR у нас есть "облако слов с координатами". После Layout Detection у нас есть ещё и типы блоков. Однако порядок чтения всё ещё не задан.
В простом одноколоночном документе достаточно отсортировать блоки сверху вниз и слева направо - и этого будет достаточно. Но в реальных сценариях:
- журнальная статья с боковой врезкой;
- презентационный слайд с несколькими независимыми блоками;
- газетная полоса с колонками разных высот и вставками;
- сложные формы с подписями к полям, сгруппированными по разделам -
простая сортировка ломает смысл: подписи отрываются от полей, комментарии вклиниваются в основной текст, части предложения разрываются.
Для этого поверх Layout Detection строят модели, которые:
- анализируют взаимное расположение блоков;
- учитывают типы регионов (заголовок → текст → подписи → сноски);
- выстраивают логический маршрут чтения по странице.
Так рождаются так называемые layout‑aware‑ридеры - системы, способные пройти по документу примерно так, как это сделал бы человек.
---
Часть 4. Почему текста всё равно недостаточно: визуальное понимание
Даже при правильном порядке чтения и разметке макета один только текст не покрывает всех сценариев.
Примеры:
- В таблице процентов по кредиту важен выделенный жирным столбец или строка "итого".
- На графике нужно понять, какая из линий соответствует какому показателю - это уже связка подписи, цвета и формы.
- В форме заявки значение поля может быть перед полем, внутри него как placeholder, над ним или справа - и всё это один и тот же смысл.
Здесь на сцену выходят Vision-Language модели - архитектуры, которые одновременно:
- "смотрят" на картинку (страницу документа) как компьютерное зрение;
- "читают" текст, распознанный OCR;
- объединяют оба потока в общее представление.
В типичной гибридной архитектуре:
1. Визуальный энкодер (обычно CNN или Vision Transformer) обрабатывает изображение страницы, получая пространственные признаки.
2. Текстовый энкодер (трансформер) работает с распознанным текстом, учитывая контекст.
3. Модуль слияния соединяет визуальные и текстовые представления, позволяя модели "понимать", что надпись относится к конкретному блоку, строке таблицы или чекбоксу.
Так система начинает опираться не только на слова, но и на их оформление, взаимное расположение и визуальные связи.
---
Часть 5. Агентный подход: система, которая принимает решения
Когда у нас есть:
- текст с координатами,
- карта макета,
- визуально‑языковая модель,
становится возможным следующий уровень - агентный подход.
Идея такая: вместо того чтобы один раз "прочитать" документ и выдать плоский JSON, система действует по шагам, как человек‑оператор:
1. Сформулировать цель: "Вытащи все поля из кредитной заявки".
2. Посмотреть на документ и решить: "Сначала определю тип документа (паспорт, справка, выписка...)".
3. В зависимости от типа выбрать стратегию:
- для паспорта искать блок с личными данными;
- для выписки - распознать таблицу транзакций;
- для налоговой формы - разобрать структурированные секции.
4. По каждому шагу явно рассуждать: что уже найдено, чего не хватает, куда смотреть дальше.
Подход ReAct, применяемый в таких системах, расшифровывается как Reason + Act - "сначала рассуди, потом действуй".
Вместо чёрного ящика, который "как‑то" выдаёт ответ, мы видим последовательность логических шагов:
- модель формулирует гипотезу;
- выбирает действие (распознать таблицу, перейти к следующей странице, уточнить контекст);
- оценивает результат и корректирует стратегию.
Так появляется не просто "читалка PDF", а зачатки цифрового клерка, который разбирает документы, принимает промежуточные решения и может объяснить ход работы.
---
Часть 6. От пайплайна к единой модели: DPT‑подход
Классический инженерный путь - собирать систему из множества компонентов:
- отдельный OCR;
- отдельный детектор макета;
- отдельный модуль для таблиц;
- отдельные правила для разных типов документов.
Такой самодельный пайплайн:
- сложен в поддержке;
- хрупок при малейших изменениях форм;
- плохо масштабируется на новые типы документов.
Современный подход, который всё активнее используется в индустрии, - Document Processing Transformer (DPT): когда почти весь этот пайплайн схлопывается в одну большую модель, обученную "от конца к концу".
Условно три принципа такого подхода:
1. Единое представление документа.
Модель сразу получает:
- картинку страницы;
- распознанный текст;
- координаты блоков.
И учится воспринимать это как целостный объект.
2. Совместное обучение множества задач.
В рамках одной модели отрабатываются:
- распознавание макета;
- извлечение полей;
- определение типа документа;
- нахождение чекбоксов, обведённых слов, подчёркиваний;
- визуальное привязки ответа к исходному фрагменту.
3. Фокус на реальных сценариях.
Модель тренируют не на "абстрактных картинках с текстом", а на наборах реальных документов: форм, договоров, счетов, заявок.
Отдельный интересный пример - обучение на чекбоксах и обведённых словах. Модель учится:
- отличать отмеченные и неотмеченные чекбоксы при любом дизайне;
- понимать, что обведённое или подчёркнутое слово - это акцент, несущий смысл;
- привязывать эти выделения к конкретным полям ответа.
Производительность таких моделей позволяет обрабатывать сотни и тысячи страниц за минуты через удобный API, без написания сотен кастомных парсеров.
---
Часть 7. Извлечение структурированных данных: как это выглядит на кредитных заявках
Вернёмся к нашим 500 кредитным заявкам.
Современная система не просто превращает PDF в текст, а проходит примерно такой сценарий:
1. Классификация страниц и документов.
Модель определяет: это паспорт, это банковская выписка, это справка 2‑НДФЛ, это налоговая декларация.
2. Извлечение полей по типу документа.
Для паспорта - фамилия, имя, дата рождения, номер, кем и когда выдан.
Для выписки - список транзакций, средний остаток, зарплатные поступления.
Для налоговых форм - год, источник дохода, суммы и вычеты.
3. Сохранение структуры.
Таблицы остаются таблицами, а не превращаются в простую "простыню" текста.
Это позволяет потом агрегировать данные, строить отчёты, контролировать лимиты.
4. Проверка связей между документами.
Система может сопоставить:
- ФИО в паспорте и в справке о доходах;
- номер счета в выписке и реквизиты в заявлении;
- указанную зарплату и фактические поступления.
5. Формирование единой карточки заявки.
На выходе - готовый структурированный набор данных по каждому заёмщику, пригодный для скоринговой модели, аналитики или ручной проверки.
В итоге то, на что раньше уходила неделя ручной работы, сводится к нескольким минутам обработки и проценту выборочной проверки.
---
Часть 8. RAG: когда нужно не просто вытащить данные, а "спросить документ"
Даже идеально извлечённые поля не покрывают всех задач. Иногда важно не "спарсить" форму, а задать вопрос документу:
- "Какой максимальный лимит по кредиту в этом договоре и на каких условиях он меняется?"
- "Какие штрафы предусмотрены за просрочку платежа?"
- "Какие документы необходимо предоставить заёмщику по этому продукту?"
Обычный подход через keyword‑поиск работает плохо:
- одно и то же можно сформулировать десятком разных фраз;
- важная информация может быть "спрятана" в сноске или примечании;
- контекст ("к чему относится это условие") критичен.
Здесь используются RAG‑системы (Retrieval-Augmented Generation), которые:
1. Разбивают документ на небольшие смысловые фрагменты.
2. Строят для каждого фрагмента векторное представление (embedding).
3. По запросу пользователя находят релевантные куски текста.
4. Передают их языковой модели, которая формулирует осмысленный ответ.
В документной среде к этому добавляется Visual Grounding:
- ответ не просто генерируется текстом;
- система показывает, на какой именно фрагмент документа она опиралась - с указанием страницы, координат или выделением нужного блока.
Так пользователь видит не только "что" ответила модель, но и "откуда это взято" в исходном документе.
---
Часть 9. Зачем всё это бизнесу
Переход от простого OCR к комплексному ADE‑подходу меняет не только технологический стек, но и экономику процессов:
- Снижается стоимость обработки документов.
Там, где раньше требовались отдельные парсеры и ручное сопровождение, достаточно одной хорошо обученной модели.
- Растёт устойчивость к изменениям форм.
Если банк перерисовал шаблон справки о доходах или добавил новую строчку, модель, опираясь на структуру и визуальные признаки, часто продолжает работать без доработок.
- Повышается качество данных.
Структура таблиц, связи между документами, визуальные акценты - всё это учитывается и сохраняется.
- Появляется возможность сложной аналитики.
Когда данные из разных видов документов оказываются в едином структурированном виде, становится проще строить скоринговые модели, мониторить риски и оптимизировать продукты.
---
Итоговая картина
За несколько десятилетий индустрия прошла путь:
- от систем, которые видели только отдельные символы;
- к моделям, понимающим макет страницы;
- к гибридным визуально‑языковым архитектурам, воспринимающим документ как цельный объект;
- к агентным системам, способным рассуждать и принимать решения по шагам;
- к интегрированным DPT‑моделям, которые охватывают весь пайплайн "от PDF до структурированных данных";
- к RAG‑подходу, позволяющему общаться с документами в форме вопросов и ответов.
В результате машины научились не просто "читать" документы, а по‑настоящему понимать, что в них написано, как это организовано и как эти данные использовать в реальных бизнес‑процессах - от обработки кредитных заявок до аналитики сложных отчётов.
Комментарии