Всем привет! На связи команда ML инженеров подразделения «Искусственный интеллект». Мы занимаемся внедрением технологий машинного обучения в производственные процессы нашей компании. Сегодня мы расскажем, как нам удалось автоматизировать извлечение параметров из договоров о долевом участии. Далее подробности того, как мы решали эту задачу, с какими трудностями столкнулись и почему не стали отдавать всё на откуп LLM.

Описание проблемы, потребности бизнеса

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

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

В идеальном мире, где все застройщики используют единый формат ДДУ, задача автоматизации извлечения информации об объекте из договора решалась бы относительно легко, даже без применения машинного обучения. Однако в реальности у каждого застройщика свой шаблон договора: в одном шаблоне информация о квартире сведена в таблице на последней странице, в другом шаблоне - разбросана по всему тексту документа. В связи с подобной вариативностью документов мы создали свое решение – сервис для распознавания параметров в ДДУ с использованием модели машинного обучения.

Общая архитектура сервиса

Архитектурно система распознавания параметров ДДУ состоит из нескольких микросервисов: 

• Сервис парсинга документов
• Сервис извлечения параметров с помощью NER-модели
• Сервис извлечения параметров с помощью регулярных выражений
• Сервис постобработки результатов

Общение между сервисам происходит через брокер сообщений Kafka. Использование подобной архитектуры в противовес монолитному приложению позволяет распараллелить работу с данными. Каждому поступившему на обработку документу присваивается некий task_id, информацию о котором получает каждый сервис. Благодаря этому, например, сервису парсинга нет необходимости ждать, когда отработают последующие воркеры, чтобы перейти к чтению нового документа.

Ответ каждого сервиса складывается в базу данных Postgres. Таким образом гарантируется сохранение результата работы каждого компонента: даже если следующий в пайплайне воркер сломается, прогонять предыдущие не будет необходимости, так как обработанные данные уже сохранены в БД. Для хранения файлов самих договоров мы используем MinIO в качестве объектного хранилища S3.

От бизнес-кейса к ML-задаче

Итак, чтобы извлечь значения параметров из документа, его для начала необходимо прочесть. Для обработки файлов типа doc/docx мы используем библиотеку python-docx. Машиночитаемые файлы формата pdf обрабатываются с помощью PyMuPDF. Сканы проходят обработку с помощью Tesseract.

После того как мы достали текст из документа и хотим начать автоматически извлекать значения таких параметров, как стоимость объекта, общая площадь, этажность дома и подобные, мы сталкиваемся с классической задачей извлечения именованных сущностей (NER, Named Entity Recognition). Под наш конкретный случай мы решили обучить на своих данных модель для классификации токенов. Для этого нам предварительно понадобилось сделать разметку договоров в Label Studio.

Протестировав дообученные на кастомных данных модели, лучший результат в плане качества и скорости мы получили с моделью bert-base-multilingual-uncased. Для обучения модели использовали порядка 1300 размеченных предложений. Обучение проводили на одной A100 40GB на протяжении двух эпох, с максимальной длинной текста - 256 и количеством батчей 8.

В качестве поддерживающего решения для основной NER модели мы также внедрили модуль, извлекающий атрибуты с помощью регулярных выражений. В нашем пайплайне результаты модуля RegExp используются в случаях, когда ML модель не смогла извлечь данные. Для каждого извлекаемого нами атрибута мы написали отдельную функцию, внутри которой рассматривается 3-4 варианта контекста на основе ключевых и стоп-слов. Исходя из контекста мы выбираем одно из regexp-правил, написанных для данного атрибута, и применяем его для извлечения значения из текста договора.

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

Может ли LLM заменить кастомизированный BERT

Конечно, нельзя было обойти вниманием использование LLM для решения подобной задачи. В частности, наилучшим образом для извлечения сущностей из текстов подходит система на основе технологии RAG – Retrieval-Augmented Generation. Суть подхода заключается в том, что языковая модель генерирует ответ на вопрос типа «На каком этаже расположен объект ДДУ?», на основе информации из документа, который пользователь подает на вход системы. Плюсом такого решения однозначно является отсутствие необходимости (до)обучения модели: достаточно взять готовую LLM, развернуть векторную базу данных для поиска релевантных контекстов в документе и базовая Question-Answering система готова.

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

Если оценивать работу такого подхода на наших тестовых документах количественно, то по метрикам RAG сильно уступает решению с NER моделью.

Проведя подобное упражнение и сравнив классическое решение задачи NER через дообучение BERT с использованием LLM 
на реальной практической задаче, мы пришли к выводу, что первый вариант для нас более предпочтителен по следующему ряду причин:

Качество работы. Дообученный BERT справляется с задачей значительно лучше LLM «из коробки»; 

Цена внедрения. Можно возразить, что дообучив LLM можно получить сопоставимое или даже лучшее качество извлечения сущностей. Однако вариант дообучения большой языковой модели представляется нецелесообразным в плане требуемых ресурсов и времени. Кроме того, для инференса LLM модели необходимо использование мощной видеокарты, в то время как наша BERT модель быстро отрабатывает и на CPU;

Лёгкость. Здесь мы подразумеваем, как лёгкость самих файлов модели типа BERT в сравнении даже с самыми легкими LLM-like моделями, так и лёгкость адаптации модели под нужную задачу и лёгкость поддержки решения при необходимости дальнейшего расширения списка параметров, извлекаемых из ДДУ.

Итак, завершив нашу небольшую исследовательскую «разведку» и выбрав наиболее подходящий метод извлечения сущностей из договоров долевого участия, мы приступили к внедрению нашего ML сервиса в нашу платформу по интеллектуальной обработке документов DOM.IDP (Intelligent Document Processing).