Привет, Хабр! Меня зовут Всеволод Зайковский, я заместитель руководителя проекта в «Газпром ЦПС».

Есть рутинные задачи, которые отнимают много времени и трудовых ресурсов. В проектах, с которыми работала компания, такой задачей была каталогизация исполнительной документации. Кто не знает, что это такое, тому очень в жизни повезло исполнительная документация – это документы, которые подтверждают фактическое выполнение работ на стройке. Выкопали траншею? Составили акт. Закопали траншею? Составили акт. И так далее. В конце среднего размера стройки мы получаем десятки тысяч актов, протоколов и схем, которые нужно вручную разобрать, хорошо отсканировать и вручную разнести по нужным папка. А затем поиск нужного документа все равно превращается в монотонный квест на несколько часов.

Мне и моей команде поставили задачу: найти способ автоматизировать этот процесс с помощью ИИ и сократить трудозатраты на ручной разбор документов. Так началась работа над «АФИДОЙ» — системой, которая использует ИИ, чтобы читать и каталогизировать документы.

Эта статья - наша история о том, как построить такое ML-решение в реалиях энтерпрайза. Расскажу про то, как мы реализовывали проект по «разгребанию» архивов строительной документации, создавали синтетические документы для обучения, и, конечно, про результаты, которые мы получили на выходе. А также о том, как мы увидели потенциал для развития и пошли дальше. Если вам это знакомо или у вас в работе есть похожие задачи — добро пожаловать.

Почему мы просто не купили готовое?

Само собой, первым делом мы пошли на рынок. Есть много продуктов для распознавания стандартных документов вроде счетов-фактур или паспортов. Но строительная документация — это настоящий зоопарк форматов. Акты, протоколы, схемы, журналы — у каждого свой шаблон, который к тому же может меняться от объекта к объекту. Многие из них — это сканы с низким разрешением, с печатями, подписями и рукописными пометками.

Готовых инструментов, способных разобраться в этом хаосе и автоматически каталогизировать такие документы, на рынке мы не нашли. И пришли к выводу, что адаптировать универсальные OCR-системы было бы дольше и дороже, чем написать свою. Так что путь был один — делать всё самим с нуля.

Знакомьтесь, «АФИДА»!

Итак, мы начали делать «АФИДУ». В ее основе конвейер, который обрабатывает каждый документ. В целом, всю работу можно разделить на четыре этапа:

• Вход. Специалист загружает в систему пачку сканов.

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

• Распознавание и извлечение. Как только тип понятен, система сначала перегоняет весь документ в текст с помощью библиотеки Tesseract и уже потом работает с ним, вытаскивая ключевую информацию: номер объекта, даты, фамилии, технические параметры.

• Архив. На выходе вся эта информация вместе с оригиналом документа попадает в структурированный архив, где найти что-либо — это дело пары кликов.

Бэкенд написан на Python, для управления очередью документов используем Celery. Это позволяет нам гибко управлять нагрузкой. Если в систему одновременно загрузят тысячу документов, она не упадет, а спокойно поставит их в очередь и разберет один за другим.

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

Самое сложное — не код, а данные и «железо»

На словах все выглядит просто. Но на деле мы столкнулись с двумя сложностями — с данными и «железом».

Начнем с «железа». Все тесты, работа моделей и эксплуатация системы происходили на обычных серверах с CPU, без единой видеокарты (GPU). В корпоративной среде часто приходится работать с тем, что есть, а с отечественными GPU, как вы знаете, есть определенные сложности.

В связи с этим у нас не было возможности распараллеливать вычисления на тысячи ядер, как это делают те, у кого есть видеокарты. По этой же причине мы не могли использовать современный подход парсинга страниц через visual LLM. Из-за этого каждая операция должна быть максимально эффективной, а модели — легкими.

Отсюда вытекала вторая, главная проблема — данные. Чтобы научить модель понимать документы, ей нужно «скормить» тысячи примеров.

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

Разметка превратилась в трудоемкий этап проекта. Представьте: несколько наших специалистов на несколько месяцев плотно работали с архивными PDF-ками. В тысячах сканов они вручную искали и размечали, где находится номер объекта, где фамилия, где дата и номер документа и т.д.

В цифрах это выглядело так:

●       Самый первый, простой датасет для проверки гипотезы мы собрали за неделю.

●       На последующие, большие выборки, ушло несколько месяцев работы двух-трех человек.

И еще два месяца — на генерацию синтетики. Именно здесь мы и столкнулись с настоящим вызовом. Одно дело, когда у тебя сотни примеров одного типа документа. Но что делать, если на какой-то редкий вид акта есть всего 3 реальных примера, а для обучения модели нужно 200? Ответ: остальные 197 нужно сделать самим.

Мы не просто генерировали листы текста, а создавали полноценные, «живые» документы. Добавляли разные варианты подписей, сделанных под разным наклоном. Накладывали артефакты: кофейные пятна, следы от деформаций (от простых сгибов до строительных ботинок), лёгкое «замыливание» текста, как от плохого принтера. На каком-то этапе мы даже автоматизировали этот процесс через текстовый редактор: делали подложку из картинки мятой бумаги, чтобы документ выглядел максимально реалистично. Каждый такой сгенерированный PDF-файл был маленьким произведением искусства, которое помогало модели учиться на данных, максимально приближенных к реальным.

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

Первые результаты

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

●       Время на оцифровку комплекта приемо-сдаточной документации по сравнению с инструментами без ИИ снизилось на 70%.

●       Скорость обработки исполнительной документации выросла вдвое, что подтвердила и наша внутренняя оценка.

●       Время на поиск нужного акта или шифра сократилось с часов до 2–5 минут за счет распознавания, нормализации атрибутов и полнотекстового индекса. Экономия времени на практике составляет до 80%.

●       Доля корректно описанных документов в «АФИДЕ» стабильно выше 95%, доля дублей менее 1%. При этом обеспечивается доступ к актуальной версии с прозрачной историей изменений.

●       Верификация документов со стороны всех участников процесса ускорилась на 50%.

На практике это означает, что специалисты смогли переключиться на более сложные задачи, где действительно нужен человек.

Кстати, о специалистах. Обычно внедрение нового инструмента вызывает сопротивление, но у нас его почти не было. Информационную систему мы внедряли на новом проекте, так что у команды просто не было старых привычек и слома «привычного» процесса.

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

Не только каталогизация: мы пошли дальше

Изначально проект был сфокусирован на том, чтобы закрыть главную боль — каталогизацию документов. Но когда мы увидели, как система работает и какую приносит пользу, мы решили не останавливаться.

Следующим шагом стало расширение функционала. Мы научили систему работать с LLM, чтобы с ней можно было общаться на естественном языке: задал вопрос по тематике загруженных документов — получил понятный ответ со ссылкой на страницу документа. А затем подружили её с BIM-моделями в формате IFC, чтобы каждый документ был связан с конкретной деталью на цифровом двойнике объекта, в том числе с отслеживанием статуса детали по QR-коду. Это позволяло использовать «АФИДУ» уже в других, более сложных сценариях, а также предложить её внешним заказчикам. Но про этот опыт мы, возможно, расскажем в одном из следующих материалов.

 Что дальше?

 «АФИДА» уже прошла экспертизу и внесена в реестр отечественного ПО Минцифры с пометкой «Применение искусственного интеллекта». Мы смогли создать отличный инструмент на базе ИИ и упразднить самую неприятную часть ежедневной рутины.

Как говорит наш заместитель руководителя программы проектов Валентин Решетник: «В основе философии ИС “АФИДА" лежит задача закрыть инструментами ИИ большинство текущих бизнес-процессов строительства и эксплуатации опасных производственных объектов»

Наша система — не просто «очередной» ИТ-продукт, а часть большого отраслевого тренда. Минстрой РФ уже несколько лет говорит о необходимости перехода на работу со структурированными данными. Ключевую роль в этом играют XML-схемы — по сути, это единые цифровые шаблоны для документов, которые позволяют машинам однозначно понимать их содержание. Мы глубоко погрузились в эту тему, вошли в рабочую группу Минстроя по работе с данными схемами и сейчас встраиваем в «АФИДУ»  поддержку XML-формата.

Еще одна большая задача на будущее — выйти за рамки простого распознавания. Мы хотим, чтобы система не только читала документы, но и помогала в их создании — например, в автоматическом формировании актов (АОСР, АОРПИ).

Так что работа продолжается. Интересно, а как вы встраиваете ИИ в свои ИТ-решения? Делитесь в комментариях.