Как из факапа родился продукт: история 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, без необходимости доработки программного кода.

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

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%), документ отправляется человеку-верификатору.

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

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

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

7. Экспорт

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

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

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