От идеи до промышленной эксплуатации: история команды проекта «ProVE»

С чего началась история «ProVE»?

Заказчик – одна из крупнейших в России компаний в сфере ЖКХ. Ежедневно операторы разбирали горы обращений от абонентов на электронной почте: акты, заявления. Всё это нужно было вручную перенести в информационные системы и подготовить официальный ответ. Огромные затраты времени, человеческих ресурсов и денег.

«Зачастую это довольно монотонный и типовой процесс, который и хотели автоматизировать. Всё началось с решения проблемы обработки писем абонентов, которые специалисты разбирали вручную».
– Наталья Семенова, руководитель проекта 

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

Но реализация оказалась сложнее. До нас заказчик обратился с этой задачей к одному из ИТ-гигантов российского рынка, а после анализа ТЗ получил ответ «это невозможно». Мы же прикинули возможные решения и взялись за проект.

Команда

В состав команды проекта вошли 3 человека: Наталья Семенова – руководитель проекта, которая погружалась в бизнес-процессы и требования; Маргарита Сафронова и Рустем Ямалтдинов – разработчики «ProVE».

«Всё, что между сканом и готовым результатом: распознавание, разбор полей, поиск абонента, реестр, письма, статистика – всё это делали мы с Рустемом. Где-то нас поправляла Наташа, которая больше всех разбирается в бизнес-процессах заказчика».
– Маргарита Сафронова, разработчик 

Это был первый проект, который мы реализовали без дизайнера – интерфейс собрали полностью своими силами. И заказчик отметил: получилось удобно. Операторы видят разобранное обращение, могут точечно поправить поле, если нужно, и подтвердить. Всё интуитивно.

Как работает «ProVE»

1.     Письмо попадает в систему через API-интеграцию с электронным документооборотом.

2.     OCR распознает печатный и рукописный текст, переводя сканы и фото в машиночитаемый формат.

3.     Языковая модель Qwen 3 анализирует текст, понимает контекст, выделяет ключевые сущности: даты, номера счетчиков, адреса, типы работ.

4.     Наша разработка «Черника» распознает показания и заводские номера приборов учета по фотографии.

5.     Ещё одна наша разработка «ПроАдрес» ищет адрес по справочным данным, сопоставляет искаженные названия улиц, находит нужные идентификаторы.

6.     Интеграция с информационной системой заказчика обеспечивает проверку, получение и внесение данных по абонентам и приборам учета.

7.     Автоматический ответ абоненту на его обращение направляется так же через API-интеграцию с системой электронного документооборота.

«Оператор у нас видит уже разобранное обращение, может точечно поправить поле, если это необходимо, иногда ему нужно просто провести проверку и нажать «готово». И дальше данные уходят в реестр, в письмо, в укладку. То есть весь процесс покрывается полностью».
– Маргарита Сафронова, разработчик

Сложности, куда же без них

Рукописные документы

Люди пишут по-разному: шестерка может выглядеть как единица, семерка – как четверка. Иногда мы сами не понимали, какое название улицы или дата обращения скрываются в почерке абонента, а наша система предлагала интересные варианты распознавания, которые становились поводом для шуток в рабочем чате.

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

Разные документы в одном письме

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

«Был такой случай: мы хотели подставлять дату роботом, если акта нет, а в итоге дата обращения затирала нормальную дату, хотя этот акт был в пакете обращения. Мы увидели, что ошибок стало больше, разобрали, что смотреть нужно на весь пакет полностью, а не на один файл. Если бумажный акт есть, его дату не трогаем».
– Маргарита Сафронова, разработчик

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

Гонка данных

На проде, в отличие от локального стенда, одновременно работают много операторов. Иногда реестр сохранялся в тот момент, когда оператор проверял поле. Поле показывалось проверенным, но в реестр не попадало.

«Иногда операторы жаловались: все поля проверены и заполнены у конкретного обращения, а в реестре какое-то поле пропало. Локально не получалось воспроизвести проблему, из-за чего мы внесли правки, которые помогли бы нам идентифицировать причину такого неинтуитивного поведения. Оказалось, что происходит так называемая гонка – на проде, в отличие от локального и дев-стендов, происходит много одновременных действий от операторов. Иногда это приводило к тому, что реестр сохранялся в тот же момент, когда происходит проверка поля оператором. Зная причину, мы уже смогли решить проблему».
– Рустем Ямалтдинов, разработчик

Бизнес-процессы

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

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

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

Изменения на ходу

«Основная задача не менялась, но обрастала подробностями, нюансами и пожеланиями на дальнейшие улучшения», – отмечает Наталья.

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

Результаты

Проект стартовал в конце февраля, а в начале мая уже был передан на тестирование. Команда из трёх человек справилась с основным объёмом задач всего за 2 месяца. С мая по сентябрь шли доработки, и вот «ProVE» принята в промышленную эксплуатацию.

Метрики, по которым оценивался продукт:

• Не менее 80% обращений, обработанных полностью автоматически. Сейчас этот показатель около 50% – иногда всё ещё встречаются ошибки в распознавании рукописного текста, а ещё на показатель влияет ручная проверка полей сотрудниками. При исправлении они периодически вносят данные из систем, с которыми не настроена интеграция.

• Не менее 80% точности извлечения ключевых сущностей. Пока колеблется в диапазоне 70–80%, проводим дообучение по рукописным текстам.

• Среднее время обработки одного обращения – не более 5 минут. Фактически до 15–30 минут в зависимости от количества вложений. Ограничение связано с оборудованием: более мощные серверы заняты под голосового робота (тоже наша разработка, о которой мы обязательно расскажем в следующих материалах).

В чем уникальность «ProVE»

Особенность «ProVE» заключается в том, что система не просто распознаёт сущности, а интегрируется в бизнес-процессы заказчика и закрывает весь процесс обработки обращения.

«Продукт стремится к полностью автоматизированной обработке обращений. Его уникальность заключается в том, что система умеет не только извлекать суть и данные обращения, а ещё и правильно взаимодействовать с различными интегрированными сервисами».
– Рустем Ямалтдинов, разработчик

«Мы закрываем разрыв между моделью и реальной работой – вот это круто», – добавляет Маргарита.

Планы по развитию

Мы не останавливаемся. В планах – улучшение текущих сценариев, дообучение модели на рукописных текстах, добавление нового функционала.

Более глобальные задачи на развитие:

• Обработка обращений по другим отделам организации заказчика.

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

• Расширение функционала «ProVE» как виртуального сотрудника на другие спектры задач.