Меня зовут Вадим Петросян, я директор по развитию бизнеса в ITFB Group. Почти десять лет я занимаюсь тем, что сегодня называют Intelligent Document Processing (IDP). Всё началось с досадной ситуации в договоре, которая грозила крупными расходами, но вместо этого породила одного из лидеров российского рынка OCR/IDP. Сегодня EasyDoc — платформа №1 по версии CNews, которую используют крупнейшие банки, пенсионные фонды и госорганы. А в 2016 году мы просто отказались платить 50% прибыли вендору за его движок — и решили создать свой.

Точка отсчёта: как мы ввязались в драку

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

Мы попросили исправить. В ответ получили ультиматум: либо принимаем их условия и поставляем заказчику безлимитную лицензию, либо отчисляем 50% прибыли от проекта. Такое положение было неприемлемо. Я всегда выступаю за win-win, но здесь его не было и в помине.

Мы отказались. И приняли решение: делаем свой продукт. Так появилась нулевая версия EasyDoc. Мы погрузились в новую для себя тему, изучали литературу и исследования по распознаванию. Первый стек собрали на open-source компонентах: Tesseract для OCR, OpenCV и Leptonica для предобработки, прикладную часть — на Java. Проект сдали в срок. Но главное открытие было впереди: на чистом open-source промышленный продукт не построить. У нас был большой прикладной опыт, но собственный продукт команда создавала впервые. И столкнулись с трудностями.

Сложность №1: кривые сканы и компьютерное зрение

Первые промышленные запуски показали: основной поток — не сканы, а фотографии. Люди делают их в условиях плохого освещения, с руки, что вносит искажения и резко снижает качество распознавания. Tesseract справлялся слабо — точность была всего 30–40%.

Пришлось писать собственный слой предобработки. Мы внедрили автоматическое выравнивание, подавление шума, бинаризацию, обрезку полей. Использовали OpenCV, Leptonica и свои алгоритмы. Точность выросла до 85–90%. В этот момент мы поняли: качественное распознавание начинается с подготовки изображения.

Первая версия технологии включала:

• Предобработку
• Снятие текстового слоя
• Извлечение данных через регулярные выражения и нечёткий поиск

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

От счётов ко всему подряд

Первый EasyDoc распознавал счёта на оплату: ЖКХ, штрафы, налоги. Тогда ещё не было универсальных QR-кодов — всё приходилось извлекать из текста и макета. Потом добавили паспорта, СНИЛС, ИНН, 2-НДФЛ.

Мы реализовали несколько прикладных решений для разных направлений. Это можно считать второй версией продукта — проект для крупного банка в 2019–2020 годах, где обрабатывали разные типы документов на реальных объёмах.

Вскоре стало ясно: рынку нужна универсальная платформа, которую можно настроить под любой процесс и любой документ. В 2018–2019 годах родилась концепция EasyDoc как энтерпрайз-платформы для потоковой обработки любых документов. Мы переписали архитектуру, внедрили микросервисы, добавили поддержку российских ОС и СУБД — импортозамещение тогда только набирало обороты, но мы смотрели вперёд.

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

К третьей версии мы добавили не только обработку и извлечение данных, но и собственную студию разработки — Capture Studio. Она позволяет создавать модели распознавания и классификации, управлять сценариями обработки, пользователями и доступом.

В 2021 году EasyDoc внесли в реестр отечественного ПО.

Как это устроено сегодня: архитектура и pipeline

Сейчас EasyDoc 4.0 — это набор микросервисов, оркестрируемых в Kubernetes. Основная бизнес-логика на Java (Spring Boot), ML-сервисы — на Python, лёгкие API — на Node.js. Базы данных — любые, по умолчанию используются российские (PostgreSQL-like), объектное хранилище — S3-совместимое (MinIO). Платформа работает on-premise: клиенты устанавливают её в своём контуре из соображений безопасности.

Весь процесс обработки настраивается в low-code конструкторе (Workflow Designer): пользователь перетаскивает блоки и соединяет их:

[Импорт] → [Предобработка] → [Классификация] → [Извлечение] → [Постобработка] → [Верификация] → [Экспорт]

Гибкие проверки без кода

В системе реализованы механизмы no-code проверок, которые можно настраивать без изменений в коде.

Проверка комплектации пакетов документов
Например, клиент банка подаёт документы на кредит: обязательные (паспорт, СНИЛС) и дополнительные (справка 2-НДФЛ, водительское удостоверение).

Если отсутствуют обязательные документы — процесс приостанавливается. При отсутствии дополнительных — система лишь уведомляет, но не блокирует.

Междокументарные проверки
Клиент предоставляет паспорт, 2-НДФЛ и анкету — все содержат пересекающиеся данные: ФИО, дата рождения, доход, место работы.

Система сопоставляет данные между документами. При критичных расхождениях (разные ФИО) — процесс останавливается. При некритичных (небольшие различия в написании) — уведомляет и фиксирует замечания.

Правила, уровни критичности и логика обработки настраиваются через low-code / no-code интерфейсы.

Этапы обработки: инженерные детали

1. Импорт
Документы поступают из сканеров, папок, e-mail, CRM, ERP, ECM. Есть готовые коннекторы и OpenAPI. Пакетные файлы (PDF, TIFF) автоматически разделяются на отдельные документы — с помощью детектора концов страниц по визуальным признакам.

2. Предобработка
Самый недооценённый этап. В реальности сканы часто бывают низкого качества. Наши алгоритмы (OpenCV + свёрточные сети) выполняют:

• Поворот и выравнивание (по текстовым блокам)
• Удаление шума (медианная фильтрация, морфологические операции)
• Бинаризацию (адаптивный порог)
• Обрезку полей (детекция границ документа)
• Улучшение контраста на плохо читаемых участках

Этот этап повышает точность OCR на 10–20 процентных пунктов. Без него любые нейросети работают плохо.

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

• Свёрточная сеть (CNN) — для визуальных признаков (макет, расположение полей)
• Random Forest — для принятия решений на основе объединённых признаков
• LLM или нечёткий поиск — в сложных случаях (например, отличить старый паспорт от нового)

Пользователь может дообучить классификатор в интерфейсе Capture Studio: загружает 10–20 образцов каждого типа, нажимает «Обучить» — и через пару минут модель готова.

4. Извлечение данных
Мы применяем три подхода, иногда комбинируя их:

• Шаблонный (OCR + регулярки) — для жёстко структурированных документов. Находим «якоря» (например, слово «ИНН») и извлекаем значение по координатам или контексту.
• NLP-извлечение (NER) — для слабоструктурированных. Используем модель LayoutLMv3 — мультимодальный трансформер, который видит и разметку страницы, и текст. Находит сущности даже при плавающих полях или опечатках.
• LLM — для свободной формы. Например, в письме: «прошу перечислять пенсию на карту Сбера». LLM извлекает ФИО, номер карты, сумму. Мы используем компактные модели (до 13B), чтобы обработка занимала 1–2 секунды на страницу на GPU среднего класса.

5. Постобработка и валидация
Сырые данные могут содержать ошибки. Применяем:

• Кросс-проверки: ФИО в паспорте должно совпадать с ФИО в заявлении.
• Вычислительные проверки: сумма в таблице должна равняться итогу.
• Форматные проверки: ИНН — по контрольной сумме, дата — по валидности.
• Сверка с внешними источниками: вызовы 1С, CRM и других систем.
• Верификация человеком: если уверенность модели ниже 95%, документ отправляется оператору.

Кросс-проверки и проверки комплектности — наша сильная сторона. Всё делается через интерфейс, без кода. Даже неподготовленный пользователь может создавать такие правила самостоятельно.

6. Верификация
У нас удобный интерфейс для операторов. На скане подсвечиваются все извлечённые поля. Если поле не найдено — можно выделить область мышкой, и система дораспознает. Можно перетаскивать страницы, менять состав документа. Это снимает нагрузку с операторов и ускоряет проверку в разы.

7. Экспорт
Результаты уходят в целевую систему в формате JSON или XML. Вместе с данными можно передать координаты полей, изображения, метаданные. Интеграция — через API, коннекторы или прямую запись в БД.

Кейс, которым мы гордимся: НПФ «Будущее»

Это был один из самых сложных проектов. Фонд получает поток обращений от граждан и госорганов — заявления, письма, запросы. Документы часто рукописные, полностью неструктурированные. Раньше операторы вручную вводили данные, тратя 10–15 минут на каждый документ.

Для обработки мы создали модели на основе LLM, обученные на 140 тысячах исторических документов. Модель классифицировала тип обращения (смена реквизитов, жалоба, запрос выписки), а другие модели извлекали ключевые сущности: ФИО, СНИЛС, номер счёта, сумму.

Результаты:

• 62% операций регистрации автоматизировано полностью
• Скорость обработки выросла на 20%
• Операционные затраты снизились на 30%
• Ошибки сократились на 80%

Мы не использовали шаблонное решение — пришлось экспериментировать с размером модели, балансом скорости и качества. Но результат того стоил.

Что дальше?

Сейчас мы активно экспериментируем с мультимодальными моделями, которые видят текст и изображения одновременно. Пока OCR остаётся лучшим решением для распознавания, но оптимальна комбинация: OCR снимает текстовый слой, а LLM анализирует его. В такой синергии качество растёт на 20–30%.

Мы считаем, что через 5 лет визуально-языковые модели (VLM) станут основой распознавания — особенно для документов с подписями, печатями, рукописными пометками.

Также прорабатываем идею программно-аппаратного комплекса EasyDoc — сервера в стойке с предустановленным ПО и оптимизацией под конкретное железо. Для тех, кому важны производительность и простота развёртывания.

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

Привет, Хабр! Меня зовутВадим Петросян, я директор по развитию бизнеса вITFB Group. Почти десять лет я занимаюсь тем, что мы теперь называем Intelligent Document Processing (IDP). А началось всё с досадной подставы в договоре, которая влекла за собой большие расходы, но вместо этого подарила рынку одного из игроков в сфере OCR/IDP. СегодняEasyDoc— это платформа №1 по версии CNews, работающая в крупнейших банках, пенсионных фондах и госорганах. А тогда, в 2016 году, мы просто не захотели платить 50% прибыли вендору за его движок. И решили сделать свой.

Точка отсчёта: как мы ввязались в драку

В 2018 году мы делали проект для крупного федерального банка — систему распознавания счетов на оплату. Планировали использовать движок одного из лидеров рынка. Договор с заказчиком был подписан, но в последний момент, перед подписанием договора с ведором, на движке которого мы и собирались реализовывать проект, наши юристы заметили отклонение от договоренностей: вместо лимитированной лицензии оказалась прописана  безлимитная лицензия. Мы обратились к вендору, надеясь на цивилизованное решение. Ответ был жёстким: либо мы принимаем их условия (т.е. поставляем заказчику литимированную лицензию), либо отчисляем 50% прибыли от проекта. Такое ультимативное предложение было для нас неприемлемо. Я всегда придерживаюсь позиции, что в таких сложных переговорах нужно стремиться к ситуации win-win.

Конечно, мы отказались. И решили создать свой продукт. Так родилась нулевая версия EasyDoc. Мы погрузились в новую для нас тему, досконально изучали литературу и исследования по распознаванию. Мы собрали первую версию технологического стека продукта на open-source компонентах: Tesseract для OCR, OpenCV, Leptonica для предобработки, прикладная часть на Java. Мы успешно сдали проект в срок. Но главное открытие случилось позже: мы поняли, что на чистом open-source промышленный продукт не сделать. У нас был огромный прикладной опыт, но собственный продукт наша команда еще никогда не делала. И, конечно же, мы столкнулись со сложностями.

Сложность №1: кривые сканы и компьютерное зрение

Первая же промышленная эксплуатация показала: мы столкнулись не только со сканами документов, но в основном — с фотографиями, их было больше! А фотографируют люди часто в условиях малого света, с руки, что вносит значительные искажения в изображение и, соответственно, влияет на качество распознавания. Tesseract в таких условиях не мог качественно распознать документ, точность составляла всего 30–40%. Пришлось писать свой слой предобработки. Мы добавили автоматическое выравнивание, подавление шума, бинаризацию, обрезку полей. Использовали OpenCV, Leptonica и собственные наработки. Точность подскочила до 85–90%. Это был момент, когда мы поняли: качественное распознавание начинается с того, как подготовлено изображение.

Первая наша технология включала в себя:

1. Предпроцессинг
2. Снятие текстового слоя
3. Извлечение данных из текстового слоя при помощи регулярных выражений, нечёткого поиска.

Результаты были хорошими, всё благодаря этапу предобработки документов.

От счётов ко всему подряд

ПервыйEasyDocбыл предназначен для распознавания счетов на оплату — оплата ЖКУ, штрафов, оплата налогов. Тогда ещё не было в помине универсальных QR-кодов, которые сейчас спасают жизнь при оплате квитанций, — всё приходилось вытаскивать из текста и макета. Потом появились паспорта, потом СНИЛС, ИНН, 2-НДФЛ.

Мы сделали несколько прикладных решений для определенных бизнес направлений. Фактически, это была вторая версия продукта — проект для другого крупного банка в 2019–2020 годах, где мы уже отрабатывали промышленную обработку разных типов документов на реальных объёмах. Но быстро осознали, что рынку нужна универсальная платформа, которую можно настроить под любой процесс и любой тип документа. Так в 2018–2019 годах родилась концепция EasyDoc как энтерпрайз-платформы для потоковой обработки любых документов. Мы переписали архитектуру, сделали микросервисы, добавили поддержку российских ОС и СУБД (импортозамещение тогда только набирало обороты, но мы смотрели вперёд).

Одним из факторов повлиявшем на наше решение создание собственного продукта – выход на рынок инвестиций и получение гранта на развитие. Для этого нам пришлось систематизировать бэглог, определить направление развития, подробно изучить наших конкурентов и, даже, пересмотреть архитектуру нашего решения.

К третьей версии мы добавили не только обработку и извлечение данных, но и, что самое главное, создали собственную студию разработки (Capture Studio), которая включает создание моделей распознавания, моделей классификации, управление сценариями обработки, а также управление пользователями, доступом и т.д.

В 2021 году EasyDoc внесли в реестр отечественного ПО.

Как это устроено сегодня: архитектура и pipeline

СейчасEasyDoc 4.0— это набор микросервисов, оркестрируемых в Kubernetes. Мы используем Java (Spring Boot) для тяжёлой бизнес-логики, Python для ML-сервисов, Node.js для лёгких API. Базы данных — любые, по умолчанию российские (PostgreSQL-like), объектное хранилище — S3-совместимое (Minio). Клиенты ставят платформу у себя в контуре (on-premise), потому что для многих важна безопасность.

Весь путь обработки настраивается в low-code конструкторе (Workflow Designer). Пользователь перетаскивает блоки, конфигурирует под свою задачу и соединяет их:

[Импорт] → [Предобработка] → [Классификация] → [Извлечение] → [Постобработка] → [Верификация] → [Экспорт]

Кроме того, в системе реализованы возможности быстрой настройки дополнительных вспомогательные процессов, позволяющих осуществлять следующие операции:

Проверка комплектации пакетов документов.Представим, что клиент банка для получения кредита должен предоставить набор документов, включающий обязательные (например, паспорт и СНИЛС) и дополнительные, желательные, но не обязательные (например, справку 2-НДФЛ и водительское удостоверение).

Механизм проверки комплектации работает следующим образом: если в пакете отсутствуют обязательные документы, процесс обслуживания клиента приостанавливается до их предоставления. В случае отсутствия дополнительных документов система не блокирует процесс, а лишь уведомляет пользователя об их отсутствии.

Все правила и логика проверки гибко настраиваются с помощью механизмов low-code / no-code, без необходимости доработки программного кода.

Междокументарные проверки.Представим, что клиент предоставляет несколько документов в рамках одного процесса (например, паспорт, справку 2-НДФЛ и анкету заемщика), содержащих пересекающиеся данные: ФИО, дату рождения, номер документа, доход и место работы.

Механизм междокументарных проверок позволяет сопоставлять данные между различными документами и выявлять расхождения. Если обнаруживаются критичные несоответствия (например, различие в ФИО или дате рождения), процесс обслуживания может быть приостановлен до уточнения или корректировки данных. В случае некритичных расхождений (например, незначительные отличия в написании или округлении сумм) система не блокирует процесс, а уведомляет пользователя и фиксирует замечания.

Все правила сопоставления, уровни критичности и логика обработки расхождений гибко настраиваются с помощью механизмов low-code / no-code, без необходимости доработки программного кода.

Теперь по каждому этапу с инженерными деталями

Система умеет забирать документы откуда угодно: сканер, сетевая папка, e-mail, корпоративные системы (CRM, ERP, ECM). Есть готовые коннекторы и OpenAPI для вызова из внешних систем. Пакетные файлы (PDF, TIFF) автоматически разделяются на отдельные документы — мы используем детектор концов страниц по визуальным признакам.

2. Предобработка

Самый недооценённый этап. В реальной жизни сканы бывают очень некачественными. Наши алгоритмы (OpenCV + свёрточные сети) делают:

• Поворот и выравнивание (определяем угол по текстовым блокам).
• Удаление шума (медианная фильтрация, морфологические операции).
• Бинаризацию (адаптивный порог).
• Обрезку полей (детектируем границы документа).
• Улучшение контраста для плохо читаемых участков.

Это повышает точность последующего OCR на 10–20 процентных пунктов. Без этого этапа любые нейросети будут страдать.

3. Классификация

Прежде чем извлекать данные, надо понять, что за документ: счёт-фактура, паспорт, договор или письмо. Мы используем гибрид: свёрточная сеть (CNN) для визуальных признаков (макет, расположение полей) и Random Forest для принятия решения на основе объединённых признаков. В особо сложных задачах к этому гибриду добавляется классификация на основе нечёткого поиска или с помощью LLM. Это позволяет, например, отличить старый паспорт от нового или понять, что в пачке лежит не тот документ.

Пользователь может дообучить классификатор под свои типы прямо в интерфейсе Capture Studio: загружает 10–20 образцов каждого типа, нажимает «Обучить», и через пару минут модель готова.

4. Извлечение данных

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

• Шаблонный (OCR + регулярки)— для жёстко структурированных документов. Находим «якоря» (например, слово «ИНН»), по координатам или контексту извлекаем значение.
• NLP-извлечение (NER) —для слабоструктурированных. Используем модель LayoutLMv3 (мультимодальный трансформер, который одновременно видит и разметку страницы, и текст). Она находит сущности, даже если поле «плавает» по странице или написано с ошибками.
• LLM— для полной свободы. Если документ — письмо в свободной форме, где нужная информация может быть сформулирована по-разному, мы пускаем в ход языковые модели. Например, для одного пенсионного фонда мы обрабатывали заявления граждан — там фраза «прошу перечислять пенсию на карту Сбера» может быть написана в любом месте. LLM вытаскивает из текста номер карты, ФИО, сумму.. Важно: мы используем компактные модели (до 13B), чтобы укладываться в 1–2 секунды на страницу на GPU среднего класса.

5. Постобработка и валидация

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

• Кросс-проверки: например, ФИО в паспорте должно совпадать с ФИО в заявлении.
• Вычислительные проверки: например, сумма в таблице должна равняться итогу.
• Проверки по формату: ИНН должен соответствовать контрольной сумме, дата — быть валидной.
• Сверку с внешними источниками  и справочниками (вызовы смежных систем, например 1С, CRM и т.п.).
• Если уверенность модели ниже порога (обычно 95%), документ отправляется человеку-верификатору.

Кросс-проверки и проверки комплектности — наша сильная сторона: всё делается при помощи мышки, это no-code, с этим справится даже неподготовленный пользователь. Такие проверки можно создавать самостоятельно.

6. Верификация

Мы сделали удобный интерфейс для операторов. На скане подсвечивается, откуда извлечено каждое поле. Если поле не найдено, можно мышкой выделить область на скане, и система дораспознает её. Можно перетаскивать страницы, изменять состав документа. Всё это снимает боль с операторов и ускоряет проверку в разы.

7. Экспорт

Результаты уходят в целевую систему в формате JSON/XML. Вместе с данными можно отправить координаты полей, изображения, метаданные. Интеграция через API, коннекторы или прямую запись в БД.

Кейс, которым мы гордимся: НПФ «Будущее»

Это был наш самый сложный и интересный проект. Фонд получает поток входящих обращений от граждан и ФОИВ — заявления, письма, запросы. Полностью неструктурированный поток, достаточно часто рукописный. Раньше операторы вручную вбивали данные в систему, тратя по 10–15 минут на документ.

Для неструктурированных документов, документов в свободной форме мы создали модели с использованием LLM. Обучили модели на исторических данных — более 140 тысяч документов. Модель классифицировала тип обращения (заявление о смене реквизитов, жалоба, запрос выписки), а реализованные нами модели извлекали ключевые именованные сущности: ФИО, СНИЛС, номер счёта, сумму. Результаты:

●      62% операций регистрации автоматизировано полностью.

●      Скорость обработки корреспонденции выросла на 20%.

●      Операционные затраты снижены на 30%.

●      Количество ошибок регистрации сократилось на 80%.

При этом мы не просто скопировали типовое решение — пришлось много экспериментировать с размером модели, балансом скорости и качества, искать компромиссы. Но результат того стоил.

Что дальше?

Сейчас мы активно экспериментируем с мультимодальными моделями, которые могут видеть и текст, и картинки одновременно. Это удобно, но пока OCR остается лучшим решением для распознавания, а оптимальна комбинация: OCR снимает текстовый слой, а LLM анализирует. В такой синергии качество распознавания улучшается на 20–30%. Что касается VLM (визуально-языковых моделей), полагаем, что лет через 5 они станут королем распознавания данных. Это особенно важно для документов с подписями, печатями, рукописными пометками.

Также прорабатываем идею программно-аппаратного комплекса EasyDoc — сервера в стойке с предустановленным ПО и оптимизацией под конкретное железо. Для тех, кому нужна максимальная производительность и простота развёртывания.

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

А теперь вопрос к вам, коллеги: сталкивались ли вы с автоматизацией обработки документов? Какие самые безумные форматы вам попадались? Давайте обсудим в комментариях!

у можно считать как вторую версию