Проект связан с автоматизацией проверки исполнительной документации на строительных объектах. Это всегда большой комплект документов: общие журналы работ, акты освидетельствования скрытых работ, исполнительные схемы, реестры, документы качества и многое другое. Их проверка требует много времени и внимания (особенно в периоды, когда от подрядчиков одновременно поступает большой объем документации, например, во время ввода объекта).

Мы разработали сервис, в который загружается комплект исполнительной документации, далее происходит распознавание документов и множество автоматических перекрёстных проверок. Например, сведения из акта сверяются с общим журналом работ, исполнительной схемой и другими документами. Сейчас система успешно распознает и анализирует более 90% поступающих документов.

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

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

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

Так появился «Чек-лист финмодели» – внутреннее приложение для проверки комплекта документов и данных финансовой модели. Сотрудник планово-аналитического отдела загружает файлы по проекту, после чего система проверяет их комплектность и структуру, контролирует основные параметры, внутреннюю логику финансовой модели, следит за тем, чтобы данные по себестоимости и сроки были корректны, проверяет соответствие значений в разных файлах. Одна проверка может включать сразу десятки или сотни отдельных показателей. Пользователь видит в первую очередь ошибки и предупреждения – то, что требует дополнительного внимания человека.

Для меня было принципиально, чтобы сама финансовая проверка не зависела от свободной интерпретации, которая характерна для нейросети. Одинаковый запрос должен давать всегда одинаковый ответ, экономические расчёты требуют воспроизводимого результата. Поэтому приложение проверяет данные по заранее заданным жёстким правилам. А искусственный интеллект мы использовали прежде всего при создании и развитии самого инструмента: я описывал необходимую логику и правила, а ИИ помогал превращать их в программный код.

Если коллега обнаруживает ошибку в работе приложения или предлагает дополнить его ещё одним видом проверки, такое обращение к разработчику (то есть мне) можно создать прямо внутри приложения. Мы разбираем его, при необходимости корректируем правила и обновляем систему. Так инструмент постепенно развивается вместе с практикой работы подразделения. Сервис уже используется внутри нашей команды и размещён в корпоративном контуре.

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

Пилотный проект запустили на объекте «Визионер». Система анализирует изображение с камер в режиме реального времени. Один из рабочих сценариев – контроль средств индивидуальной защиты: если человек находится на площадке без каски или сигнального жилета, система распознаёт нарушение и направляет уведомление ответственным.

Ещё один сценарий – контроль опасных зон. В интерфейсе можно задать виртуальный периметр, например, вокруг котлована или зоны работы крана. Если человек или транспорт пересекает границу, система фиксирует это и отправляет оповещение. При этом удобно, что такие зоны в системе можно быстро менять по мере того, как меняется сама стройплощадка.

В дальнейшем мы хотим научить систему распознавать госномера автомобилей, фиксировать большое скопление людей, задымление, а также ситуации, когда человек упал или долго не двигается. Проект пока находится в стадии пилотирования и обучения моделей. Одними из главных «подводных камней» на старте оказались ограниченные вычислительные мощности и качество интернет-соединения, но эта проблема была решена.

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

Мы сознательно не заводили ни жюри, ни баллов. Причина простая: как только появляется судейство, команда начинает собирать не продукт, а защиту. За 90 минут это гарантированно даёт красивый слайд вместо чего-то работающего. Задача первого хакатона была другая: чтобы коллеги своими руками прошли путь от задачи до прототипа и увидели, что этот путь им доступен. Поэтому вместо «защит перед жюри» был показ.

Какой результат показали команды? Обе успели собрать бэкенд – работающую логику. Продукт принимает запрос, обрабатывает его и выдаёт результат. Одна команда успела ещё и начать фронт, то есть интерфейс, через который с этой логикой «разговаривает» человек. Бэкенд и фронтенд – это как двигатель и кузов автомобиля. «Двигатель» как раз более сложная часть, интерфейс делается быстрее и понятнее. Обе команды, можно сказать, собрали двигатель, но не успели поставить на него кузов. За отведённое время дошли не до презентации идеи, а до работающего механизма. Это ровно та граница, которую я считал реалистичной в рамках 90 минут.

Что показал хакатон? Что «барьер входа» ниже, чем кажется. Самая ценная строчка в опросе после демо-дня от одного из участников: «Теперь есть понимание, что такие продукты можно делать без углублённых знаний кода». Это ровно тот сдвиг, за которым мы шли – чтобы коллеги перешли от «интересно» к «сделал своими руками». По итогам первого демо-дня в апреле у нас был разрыв между интересом и действием: оценка демо-дня была 9,1 из 10, но до применения ИИ в работе тогда дошли единицы. Хакатон и затевался как «лечение» этого разрыва, чтобы у людей исчезло ощущение «это не для меня». И он сработал: появилась группа коллег, которые прошли путь не глазами, а руками. Именно такой опыт потом превращается в реальные внутренние продукты, мы знаем это по кейсам предыдущего демо-дня.