Промышленные записки
Как настроить модель машинного обучения для проверки юридических контрактов
Глубокое погружение в недавно выпущенный набор данных обработки естественного языка для понимания контрактов
Обзор контракта - это процесс тщательного прочтения контракта, чтобы понять права и обязанности человека или компании, подписавшего его, и оценить связанные с этим последствия. Это широко считается одной из самых повторяющихся и утомительных работ, которые должны выполнять младшие сотрудники юридической фирмы. Кроме того, использование профессиональных навыков юриста является дорогостоящим и неэффективным. В этом сообщении блога я покажу, как настроить недавно выпущенный набор данных и связанные модели машинного обучения для автоматизации проверки контрактов.
Что влечет за собой обзор контракта?
Когда дело доходит до проверки контракта, работа юриста состоит в том, чтобы вручную просмотреть сотни страниц контрактов, чтобы найти соответствующие положения или обязательства, предусмотренные в контракте. Он повторяется, потому что им всегда нужно идентифицировать одни и те же точки данных в любом конкретном контракте: какова дата вступления контракта в силу? Какие условия продления? Кто стороны вовлечены в этот контракт?
Юридические фирмы испытывают огромное давление с целью сократить свои расходы, особенно во время и после коронавируса. Благодаря последним достижениям в области обработки естественного языка (NLP) модели машинного обучения могут научиться автоматически извлекать и определять ключевые положения из контрактов, что позволяет сэкономить сотни часов ручного труда.
Что такое набор данных CUAD?
В марте 2021 года Atticus Project выпустил Contract Understanding Atticus Dataset (CUAD), который состоит из более 500 контрактов, каждый из которых тщательно промаркирован юристами для определения 41 различных типов важных положений, в общей сложности более 13 000 аннотаций. . Наряду с набором данных они также опубликовали несколько современных моделей Transformer, которые были обучены на этом наборе данных. Вы можете найти набор данных и обучающий код в их репозитории GitHub, а отлаженные модели можно скачать с Zenodo.
В этом посте я расскажу вам, как настроить и запустить точные модели, чтобы вы могли использовать их для своих собственных прогнозов.
Подготовка данных
Вы должны иметь возможность запустить этот пример на своем собственном компьютере, так как он не очень ресурсоемкий, и мы не ищем миллисекундных откликов от модели. Весь код и записные книжки, которые я использую, можно найти в моем репозитории GitHub.
В первой записной книжке 1_preparation.ipynb я запускаю набор команд оболочки для загрузки данных, кода, модели и библиотек. Вместо этого вы можете легко запустить эти команды в терминале.
В этом блоге я использую модель roberta-base, которая является самой маленькой, но также третьей по эффективности моделью. Вы, конечно, можете выбрать использование модели roberta-large или модели deberta-v2-xlarge, которые имеют лучшую производительность (см. Здесь). Какую бы модель вы ни выбрали, инструкции по загрузке модели и составлению прогнозов будут одинаковыми. Все модели доступны для скачивания здесь.
После выполнения этих команд у вас должны быть следующие три папки в основной папке проекта: cuad-data /, который содержит фактический набор данных CUAD, , cuad-models /, который содержит модель (s), и cuad-training /, который содержит сценарии Python и сценарии оболочки для обучения модели.
Загрузка модели
Глядя на обучающий код в cuad-training / train.py, мы видим, что модель CUAD основана на классе AutoModelForQuestionAnswering, который специально обучен для задач с ответами на вопросы. Это имеет смысл, потому что мы хотим, чтобы модель определяла определенные части контракта, задавая ей вопрос (например, «Какая дата контракта?»).
Обладая этими знаниями, мы можем загрузить модель и ее токенизатор (который подготавливает входные данные для модели) следующим образом:
Обратите внимание, что мы установили для параметра use_fast значение False. Причина в том, что модель QuestionAnswering (Q&A) (пока) не совместима с быстрыми токенизаторами, которые имеют более разумную обработку переполнения. Это совершенно нормально для наших целей, мы просто должны не забыть установить соответствующий параметр.
Теперь, когда мы загрузили модель, мы можем быстро протестировать ее на образце. Команда CUAD предоставляет данные контрактов и связанных запросов в файлах JSON. Полный список из 41 запроса можно посмотреть здесь. Теперь мы можем протестировать модель, которую мы только что загрузили, используя один из контрактов и запросов в наборе данных:
Этот код загружает третий запрос из файла JSON с вопросом: «Какова дата контракта?» первого контракта и отображает первые 100 слов этого контракта:
Делаем первый тестовый прогноз
Принцип работы моделей вопросов и ответов состоит в том, что вопрос и контракт объединяются (разделяются специальным токеном), токенизируются (т. Е. Подготавливаются входные данные, чтобы модель могла их понять), а затем вводятся в модель. Затем модель предоставит два выхода: начальные логиты и конечные логиты.
Начальные логиты описывают вероятность того, что каждое слово в строке будет началом ответа на вопрос. Точно так же конечные логиты описывают вероятность того, что каждое слово будет концом ответа.
Чтобы получить наилучший прогноз от модели, все, что нам теперь нужно сделать, это выбрать начальный и конечный токены с наивысшими вероятностями.
Все это звучит немного абстрактно, поэтому для пояснения я включил следующие две диаграммы. Первая диаграмма отображает вероятности того, что каждый токен в контракте будет начальным токеном ответа, второй делает то же самое, но для конечных токенов:
Выбирая два токена с наибольшей вероятностью соответственно, мы получаем прогноз модели с наибольшей общей вероятностью:
Весь код можно найти в записной книжке 2_loading_model.ipynb.
Резюме
В этом сообщении блога мы представили задачу автоматизации проверки контрактов и набор данных CUAD, который помогает решить эту проблему. Мы загрузили набор данных и загрузили соответствующую точно настроенную модель. Затем мы создали первый пример запроса, чтобы убедиться, что модель работает правильно. Мы рассмотрели выходные данные модели и определили простой подход к извлечению прогноза модели.
Следующие шаги
На этом мы еще не закончили: теперь у нас есть готовая и работающая модель, но наш подход слишком упрощен, чтобы его можно было использовать в производственной среде. Прежде всего, вы, возможно, уже спрашивали себя: «Что, если модель предсказывает конечный токен, который находится перед стартовым токеном в контракте?» Это законный вопрос, поскольку начальный и конечный токены предсказываются моделью независимо, поэтому нам придется реализовать некоторую логику, чтобы учесть это.
Другое ограничение нашего текущего подхода не так очевидно, но связано с базовой архитектурой модели вопросов и ответов. Большинство этих моделей, включая эту, могут принимать только 512 токенов (что примерно соответствует 512 словам), включая вопрос и договор вместе. Но это не работает для нашего варианта использования: большинство контрактов намного длиннее 512 слов, и ответ на конкретный запрос проверки контракта может, например, быть на странице 27 контракта.
В следующем сообщении блога мы рассмотрим, как преодолеть эти ограничения и как настроить удобный пользовательский интерфейс для этой демонстрации.
[ИЗМЕНИТЬ 13 апреля 2021 года: Вторая часть опубликована!]
