Универсальные факты: конструктор извлечения для аналитика

37e94e5b56e51c5b69a7a0ace47a2bd4.jpg

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

Если бы эту экспертизу проводил человек, то на его стол (физический или виртуальный) должен попасть большой пакет документов: устав организации, протокол о создании общества, протокол о нотариальные доверенности и многое другое. И чтобы искусственный интеллект (система автоматического принятия правового решения, или, как мы её называем, «робот-юрист», эта технология даже запатентована) мог принять решение, нужно сначала из каждого документа извлечь определённую информацию (значимые факты), структурировать её и отправить на проверку. Только после этого робот-юрист решит, есть ли правовые риски в этой кредитной сделке.

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

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

Подвох первый: множество разных типов документов

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

Список

  • Протокол высшего органа управления о создании общества.

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

  • Протокол высшего органа управления общества об одобрении сделок.

  • Протокол об итогах голосования на общем собрании акционеров.

  • Нотариальное свидетельство об удостоверении факта принятия решения органом управления юридического лица и о составе участников (членов) этого органа, присутствовавших при принятии данного решения.

  • Нотариальную доверенность.

  • Устав юридического лица.

  • Внутренние нормативные акты юридического лица.

  • Договор передачи полномочий единоличного исполнительного органа управляющей организации.

  • Договор передачи полномочий единоличного исполнительного органа управляющему индивидуальному предпринимателю.

  • Договор купли продажи недвижимого имущества.

  • Акт приёма‑передачи к договору купли продажи недвижимого имущества.

  • Договор аренды земельного участка.

  • Акт приёма‑передачи к договору аренды земельного участка.

  • Договор купли‑продажи долей в уставном капитале юридического лица.

  • Дополнительное соглашение к договору купли‑продажи долей в уставном капитале юридического лица.

  • Договор купли‑продажи движимого имущества.

  • Акт приёма‑передачи к договору купли‑продажи движимого имущества.

  • Договор услуг подряда.

  • Договор услуг генерального подряда (в том числе на проектные работы).

  • Дополнительное соглашение к договору услуг подряда.

  • Дополнительное соглашение к договору услуг генерального подряда (в том числе на проектные работы).

  • Договор купли‑продажи ценных бумаг.

  • Дополнительное соглашение к договору купли‑продажи ценных бумаг.

  • Опционный договор.

  • Дополнительное соглашение к опционному договору.

  • Корпоративный договор.

  • Дополнительное соглашение к Корпоративному договору.

  • Договор об осуществлении прав участников общества.

  • Договор цессии.

  • Дополнительное соглашение к договору цессии.

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

Подвох второй: сложность юридического языка

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

Архитектура применяемой нами нейронной сети с LSTM- и CRF-слоями на выходе.

Архитектура применяемой нами нейронной сети с LSTM- и CRF-слоями на выходе.

Чтобы решить эту задачу, нам пришлось дообучать нейронную сеть на основе архитектуры RuBERTBase. На вход нейронной сети поступает токенизированный текст с координатами каждого токена, чтобы можно было потом восстановить сложные конструкции, как в примере выше про «юрлицо, в лице физлица, в лице физлица». Токенизатор разбивает исходную фразу, например, «Цель, предмет и виды деятельности общества», на последовательность токенов [цель, ,, предмет, и, виды, деятельности, общества] с индексами в словаре [3382, 16, 3055, 141, 4151, 1027, 818]. Если последовательность оказывается длиннее 511 токенов (максимальный размер окна контекста для архитектуры BERTBase минус один), то она делится на подпоследовательности, длина каждой из которых не превышает 511 токенов. В начало каждой такой подпоследовательности мы добавляем специальный токен [CLS] — это необходимо для предсказания (классификации) типа исходного документа. Каждому токену взаимно однозначно соответствует числовой вектор длиной 768, который принято называть эмбеддингом. Далее к эмбеддингу токена прибавляется эмбеддинг позиции токена в предложении (чтобы мы могли восстанавливать взаимосвязанные сущности). Таким образом модель получает информацию о порядке слов в предложении, учась решать две задачи: восстанавливать зашумлённые токены (MLM, Masked Language Modelling) и предсказывать класс документа.

Архитектура нейронной сети и данных, поступающих на вход при обучении решению MLM-задачи. В этом режиме модель должна научиться предсказывать вероятность токена, скрытого маской (MASK).

Архитектура нейронной сети и данных, поступающих на вход при обучении решению MLM-задачи. В этом режиме модель должна научиться предсказывать вероятность токена, скрытого маской (MASK).

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

Универсальные факты

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

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

Мы собрали подборку разных типов документов и на её основе сформулировали набор из 12 универсальных составных частей (блоков):

Есть и более специфичные блоки, но эти встречаются чаще всего.

Документы часто довольно велики, некоторые на 50–70 страниц, поэтому их обрабатывает не одна большая модель, а каскад из не менее 5–6 маленьких специализированных моделей. И когда нам нужно сделать конвейер обработки для нового типа документа, он на 70–90% собирается из готовых универсальных моделей, отвечающих за выделение конкретных блоков. На это уходит всего неделя. Остаётся лишь дополнить обучающую выборку и схему данных новыми примерами и универсальными фактами. Либо сделать ещё одну-две маленькие модели, которые будут извлекать специфические для этого типа документов данные. Причём делать это тоже стало проще, потому что мы уже покрыли универсальными блоками большую часть документа и в нём осталось гораздо меньше мест для извлечения недостающей информации. Вместе с разметкой на эти доработки уходит ещё недели три-четыре. И теперь на подготовку нового конвейера мы тратим минимум вдвое меньше времени, чем раньше.

Схема каскада моделей извлечения.

Схема каскада моделей извлечения.

Внедрив универсальные факты, мы решили переосмыслить те документы, извлечение из которых было разработано ранее. И оказалось, что новый подход повысил качество извлечения, измеряемое F-мерой (F1-Score). Это можно интерпретировать так: модели начали лучше находить разные формулировки, которые могли различаться буквально считанными символами. Человек такую разницу даже не замечает, а для алгоритмов с низкой обобщающей способностью это бывает критично.

Что нам это даёт?

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

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

Ознакомиться подробнее с сервисом извлечения, использующем универсальные факты, и запросить демо можно на странице DeepDocs.

© Habrahabr.ru