Интеллектуальная маршрутизация входящих документов: как мы наняли ИИ в диспетчеры документооборота

Привет! Меня зовут Антон Топчиев, я ведущий аналитик команды продукта «Среда ЭДО» в МТС. Мы автоматизируем электронный документооборот и периодически делаем то, что обычно обещают на презентациях, — действительно снимаем рутину с людей. В том числе и с помощью искусственного интеллекта. 

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

В МТС ежедневно поступает от 6 до 10 тысяч входящих документов от клиентов и контрагентов — разбирать такое количество писем вручную, конечно, просто нереально. Чтобы письма доходили в нужное подразделение, у нас была настроена маршрутизация по некоторым фильтрам и критериям — например, по имени, ИП или ООО контрагентов. Однако в этой схеме не учитывалось то, что сами документы — это файлы разных типов и форматов, и часто с неинформативными именами отправителей или отсутствующими метаданными. Из-за этого время от времени часть писем терялась, так к что схему распределения нужно было оптимизировать.

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

Какую схему маршрутизации придумали

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

1. Перехват. Сервис обработки входящих документов Среды ЭДО постоянно следит за ящиком организации в операторе ЭДО. Как только появляется новый документ, он забирает его файл и метаданные.

2. Анализ. Документ попадает в сервис классификации SmartDocs, где происходит:

1) извлечение текста, в том числе OCR, если нужно;

2) предобработка текста, очистка, нормализация, устранение «шумов»;

3) классификация — определение типа документа и степени уверенности в ответе.

3. Уведомление. Получив ответ от классификатора, сервис Среды ЭДО автоматически информирует через брокер сообщений всех, кто подписан на этот тип документа.

Потребителем может выступать любой продукт — СЭД, CRM, ERP, программный робот, витрина и прочие.

Как выбирали метод классификации

Для классификации документов мы рассматривали два основных варианта:

1. Сделать собственный ML-классификатор. Мы попробовали обучить свою модель: собрали датасет и на его базе команда SmartDocs обучила классификатор. Для этого нам пришлось разработать структуру категорий документов, собрать и разметить тысячи примеров и обучить алгоритм. Подготовка была серьезной и в итоге получился предсказуемый и точный инструмент.

2. Работать с готовыми большими языковыми моделями (LLM). Параллельно мы экспериментировали с внутренними моделями в контуре MWS GPT — они понимают контекст без специального обучения и могут работать с нестандартными документами. Однако на выходе мы часто получали неструктурированные ответы, иногда с ошибками, которые требовали дополнительной проверки.

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

Как готовили данные для обучения модели

Качество модели напрямую зависит от качества данных, на которых она учится. Мы выстроили многоэтапный процесс работы над датасетом:

• Построили дерево классов. Мы не стали брать за основу готовые классификации, все типы входящих документов выделили на основе анализа документооборота компании.

• Собрали исходный материал. Взяли за основу реестры входящих документов за несколько предыдущих месяцев из оператора ЭДО.

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

• Организовали файловый датасет. Получили документы из оператора ЭДО и разместили их в каталогах согласно разработанной нами категоризации классов.

• Проверили документы с помощью LLM. Чтобы найти возможные ошибки в базовой разметке, прогнали тексты документов через большую языковую модель.Так мы быстро обнаружили моменты, которые стоило перепроверить, и избавились от мусора в обучении модели. 

• Завершили работу экспертной проверкой. Чтобы наше видение не расходилось с реальностью, финальную верификацию всего датасета сделал специалист по документообороту, после чего пару моментов мы доработали.

Так мы получили эталонный набор документов для обучения и тестирования классификатора.

Как улучшаем точность классификатора

Мы постоянно дорабатываем классификатор и начали это делать еще до боевой проверки сервиса:

• Экспериментируем с данными. В некоторых документах сигнальная информация есть уже на первых страницах. По такой логике все остальные должны были давать излишний шум. Мы протестировали классификаторы, обученные как на полных текстах, так и на первых страницах, в том числе с дополнительной аргументацией выборки через LLM. В итоге убедились, что при анализе полного текста документа результат получается точнее.

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

• Учим классификатор работать с разными форматами. Один из кейсов — формализованные XML-документы. Их почти не было в изначальной выборке, и модель начинала плавать — теги и служебная структура ломали привычные текстовые паттерны. Решение было максимально приземленным: мы добавили в датасет тексты XML-документов и доработали предобработку. После этого качество выровнялось.

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

Как его уже использует команда документооборота

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

Теперь все работает так:

1. Классификатор как фильтр. Наш сервис, подключенный к оператору ЭДО, передает каждый новый документ в классификатор. Среди счетов, контрактов и прочего классификатор находит нужные письма, обращения и уведомления.

2. Автоматическая маршрутизация и регистрация. Все такие документы автоматически пересылаются в СЭД, где на основе полученных реквизитов создается карточка входящего документа и задача для регистратора.

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

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

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

Чтобы решение могли использовать и другие команды, мы:

1. совместно определяем источник документов, интересующую тематику и бизнес-задачу. То есть понимаем, что ловим, где ловим и куда отправляем; 

2. сверяемся, покрывает ли одна из наших моделей нужные типы документов или ее нужно дообучить;

3. дообучаем классификатор или создаем новую модель, а затем подключаем пользователей к нашему сервису.

Итоги и наши планы

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

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