Применение инструментов интеллектуального анализа текстов в юриспруденции
© Д.С. Зуев ©А.А. Марченко ©А.Ф. Хасьянов Казанский (Приволжский) федеральный университет,
Казань, Россия
dzuev11@gmail.com anton.marchenko@kpfu.ru ak@it.kfu.ru
Аннотация.Описана архитектура системы интеллектуального анализа текстов в юриспруден- ции, способной на имеющейся базе данных судебных документов выявлять общие зависимости, предоставлять для ознакомления юридические дела, близкие по тематике, рекомендовать наиболее вероятные исходы судебного рассмотрения или помечать важные места, на которые следует обра- щать внимание при процессуальных действиях с использованием инструментов текстовой аналити- ки. Ключевые слова: аналитика и управление данными, интенсивное использование данных, электронные библиотеки, кластеризация, рекомендательная система, микросервисная архитектура.
Text Mining Tools in Legal Documents
© D.S. Zuev ©A.A. Marchenko ©A.F. Khasiannov Volga Region Federal University,
Kazan, Russia
dzuev11@gmail.com anton.marchenko@kpfu.ru ak@it.kfu.ru
Abstract. We present the architecture of the system for the intellectual textual analysis in jurispru- dence based on microservices. The system can identify common dependencies on an existing database of legal documents, provide legal cases close to each other, familiarize them with the most probable outcomes of judicial review or mark out important places during procedural actions.
Keywords: analytics and data management, data intensive domains, digital libraries, clustering, rec- ommender system, microservices.
1 Введение
Как известно, информационное общество харак- теризуется высоким уровнем развития информаци- онно-коммуникационных технологий (ИКТ) и их интенсивным использованием всеми и всюду. В основе ИКТ лежит информация, а сами они во мно- гом определяют содержание, масштабы и темпы развития других технологий.
Интересным направлением разработки специа- лизированных автоматизированных информацион- ных систем является создание интеллектуальных систем, способных на имеющейся базе данных су- дебных документов выявлять общие зависимости, предоставлять судьям для ознакомления близкие по тематике дела, рекомендовать наиболее вероятные исходы или помечать важные места, на которые судебным работникам следует обращать внимание при процессуальных действиях. Подобная система, на наш взгляд, поможет участникам судебного про- цесса точнее оценивать свои позиции или выбирать лучшую стратегию поведения, а судьям – в сжатые
сроки формировать подборку связанных докумен- тов, не тратя для вынесения вердикта лишнего вре- мени на поиск во всем архиве документов.
Проведенные исследования по семантическому структурированию информации в других предмет- ных областях (см., например, [1, 2]), анализ инстру- ментов текстовой аналитики (см, например, [3]) и наработки по применению семантических техноло- гий при работе с юридическими документами [4]
говорят о реализуемости поставленной задачи.
2 Интеллектуальная система «Робот- юрист»
2.1 Цели и задачи
«Робот-юрист» – это информационная система, которая должна позволять участникам юридическо- го процесса правильно проводить подготовку дела, а также осуществлять планирование судебной дея- тельности. Эта система ориентирована на арбит- ражные суды, занимающиеся рассмотрением споров в сфере предпринимательства. В целом наш проект направлен на развитие российского правового госу- дарства, обеспечение доступности, открытости и прозрачности правосудия, формирование у граждан Труды XIX Международной конференции «Ана-
литика и управление данными в областях с ин- тенсивным использованием данных» (DAMDID/
, Москва, Россия, 10–13 октября 2017
правосознания, основанного на верховенстве Права.
Задача системы – помочь определить характер спора, осуществить поиск и проверку действия пра- вовых норм, регулирующих спорные правоотноше- ния, оказывать содействие в установлении компе- тентного суда (подсудность, подведомственность), статуса участников спора (действующее, ликвиди- рованное, банкрот), определении круга обстоятель- ств, имеющих значение для рассмотрения спора, характера спорного правоотношения, нормы права, подлежащей применению (действует ли данная норма), а также проверять достаточность и ком- плектность представляемых документов. Отдель- ными функциями планируются обеспечение воз- можности оформления искового заявления, а также вычисление (по предоставленным исходным дан- ным на основе архива судебных дел) вероятности принятия того либо иного решения.
Для достижения поставленных целей были по- ставлены следующие задачи: создание портала для формирования шаблонов исковых заявлений с от- слеживанием их жизненного цикла; разметка и ана- лиз существующей базы судебных решений, иско- вых заявлений (классификация заявлений и реше- ний, извлечение сущностей и фактов); подбор ана- логичных дел и решений, рекомендательный сервис;
сопоставление исковых заявлений и судебных ре- шений; распределение судебных дел между судьями с учетом их специализации и текущей загрузки и прогнозирование вероятного решения по предостав- ленным исходным данным.
Каждая из выделенных задач является автоном- ным модулем разрабатываемой информационной системы, а сама система – практическая демонстра- ция совместного использования ряда семантических технологий и инструментов текстовой аналитики.
2.2 Архитектура системы
Текущие парадигмы разработки предусматрива-
ют два концептуально различных подхода к дизайну приложений. Первый вариант – «монолитные при- ложения», когда вся логика по обработке запросов выполняется в рамках единственного процесса, при этом используются возможности конкретного языка программирования для разделения приложения на классы и функции. Однако любые изменения, даже самые небольшие, требуют перекомпиляции всего дистрибутива информационной системы и после- дующего обновления всех ее модулей. С течением времени изменения в логике работы одного модуля начинают влиять на функции других модулей.
Другой подход – это построение среды, в кото- рой отдается предпочтение слабым связям, абстра- гированию низкоуровневой логики, гибкости, а также возможности многократного использования и обнаружения компонентов [5, 6], сервис- ориентированная архитектура (Service-Oriented Ar- chitecture, SOA). Такая архитектура строится на сер- висах, а не на приложениях. Сервисы – это дискрет- ные программные компоненты, предоставляющие четко определенную функциональность и использу- емые в составе многих приложений. Каждый сервис представляет собой изолированную сущность с ми- нимумом зависимостей от других совместно ис- пользуемых ресурсов. Таким образом, возникает возможность изменять отдельные сервисы, не затра- гивая при этом всю систему. Дальнейшим развити- ем парадигмы сервис-ориентированной архитекту- ры можно считать появление архитектуры микро- сервисов [7]. Термин «Microservice Architecture»
получил распространение в последние несколько лет для описания способа проектирования приложе- ний в виде набора независимо развертываемых сер- висов.
Архитектурный стиль микросервисов – это под- ход, при котором единое приложение строится как набор небольших сервисов, каждый из которых ра- ботает в рамках собственного процесса и взаимо- Рисунок 1Архитектура системы
действует с остальными. Сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Централизованное управление минимизиро- вано, а сами сервисы могут быть написаны на раз- ных языках программирования и использовать раз- ные технологии хранения данных. Более того, внут- ри каждого микросервиса вполне может быть задей- ствована собственная база данных (см. [7]).
С учетом достаточно большого количества мо- дулей системы наиболее логичным путем для со- здания «Робота-юриста» стало применение архитек- туры микросервисов.
Архитектура системы приведена на Рис. 1. Нами выделено несколько групп сервисов, взаимодей- ствующих между собой с помощью программного интерфейса (API). Каждый из них реализует одну из соответствующих функциональных задач. На схеме выделены серверная и клиентская часть веб-портала системы, а также слой доступа к данным – база дан- ных судебных дел и решений, нормативно- справочная информация. В виде отдельного модуля разрабатывается экспертная система, в автоматиче- ском режиме оказывающая консультации по юри- дическим вопросам в формате взаимодействия с виртуальным собеседником – Telegram-Ботом.
2.3 Разметка массива документов
Разметка существующего массива документов необходима для дальнейшего обучения сервисов системы. Для реализации этой задачи использовался инструмент для быстрого структурированного ан- нотирования текстов BRAT [8]. BRAT – это веб- система с открытым исходным кодом, разработан- ная группой разработчиков в университетах Токио и Манчестера. Результаты разметки получаются в виде, удобном для дальнейшей машинной про- граммной обработки.
Судебные решения и дела открыты и доступны для просмотра в интернете и представляют собой массив неразмеченных документов, в котором ори- ентироваться непросто. Важна собственно разметка текстов судебных дел для выделения классов и под- классов сущностей, их зависимостей с целью даль- нейшего построения модели машинного обучения.
На текущий момент времени, в рамках создания прототипа системы, принято решение о первона- чальной разметке сравнительно небольшого количе- ства документов (около 3000). Важно отметить, что самих типов споров, значит, и классов связанных документов может быть достаточно много. С целью упрощения работы на начальном этапе мы обраба- тывали судебные дела, относящиеся только к не- скольким категориям судебных споров.
Размеченный текст будет использоваться для обучения подсистемы поиска аналогов и прогнози- рования вердикта по делу. В качестве результата работы получаем размеченный текст, который запи- сывается в БД судебных дел для дальнейшей обра- ботки.
Для первоначальной разметки были выделены основные сущности, такие, как «Истец», «Ответ- чик», «Предмет спора», «Действующие нормы». На текущий момент времени определено 56 сущностей, которые необходимо выделять внутри судебных решений для дальнейшей обработки. Множество выделенных сущностей будет уточняться по мере увеличения объема размеченного текста. На сего- дняшний день проведена всего лишь первая итера- ция данного процесса.
2.4 Рекомендательный сервис
Одной из важнейших задач формируемой ин- формационной системы являются поиск и предо- ставление аналогичных решений по схожим судеб- ным искам. Таким образом, необходим сервис поис- ка аналогичных документов, или рекомендательный сервис.
Существуют два основных типа рекомендатель- ных систем: контент-ориентированные и социаль- ные (коллаборативной фильтрации) (см., например, [9]). Первые основаны на представлении предпочте- ний пользователей путем анализа содержимого ре- комендательных элементов. Системы второго типа моделируют предпочтения, оценивая близость про- филей пользователей. Ниже под рекомендательным сервисом будем понимать информационную систе- му, которая: 1) формирует модель предметной обла- сти на основе массива документов (включая подго- товительные операции – приведение к векторному виду, кластеризацию и т. п.); 2) получает на вход документ и выдает список документов, близких к входному.
По сравнению с поисковыми системами реко- мендательные системы наиболее полезны, когда у пользователя возникают трудности с формулиров- кой эффективного поискового запроса.
Подходы к организации рекомендательных сер- висов могут быть разными, в [1] описан подход с использованием онтологий и предпочтений пользо- вателей. Учитывая специфику предметной области и разрабатываемой системы, использовать предпо- чтения пользователей не корректно.
Алгоритм работы сервиса можно разделить на два этапа. На подготовительном этапе обрабатыва- ются все имеющиеся документы: вырезаются знаки пунктуации, термы приводятся к единому виду (для слов с разными окончаниями и суффиксами). Далее документ приводится к векторному виду. Для пред- ставления массива документов в виде числовых век- торов, отражающих важность использования каждо- го слова из некоторого набора слов (количество слов набора определяет размерность вектора), в каждом документе используется мера TF-IDF [3, 10]. На основе массива векторов происходит класте- ризация.
На первом шаге необходимо определить количе- ство K кластеров, мы использовали для этого фор- мулу 𝐾𝐾=𝑁𝑁𝑆𝑆𝑡𝑡𝐷𝐷/10, где Ndoc – общее количество об-
рабатываемых документов. Далее производится собственно кластерный анализ по методу K-means (метод К-средних, [3, 11]). Полученные результаты сохраняются для дальнейшего использования.
На основном этапе работы на вход сервису пода- ется идентификатор документа. Производится при- ведение его к векторной форме, которая обрабаты- вается моделью, причисляется к определенному кластеру. На выходе алгоритм выдает первые n до- кументов из того же кластера, что и входной доку- мент, количество выдаваемых документов настраи- вается, на данном этапе реализации системы n опре- делено равным 10.
Процесс переобучения модели следует прово- дить периодически, например, раз в сутки, либо по- сле существенного изменения всего корпуса доку- ментов.
Обработка массива из 3250 документов занимает 5 мин (Intel® Core™ i7-3632QM CPU @ 2.20GHz × 8), что на текущем этапе развития системы «Робот- юрист» является приемлемым показателем быстро- действия. Сервис реализован на языке Python, взаи- модействие с другими модулями системы происхо- дит по внутреннему согласованному протоколу вза- имодействия.
2.5 Классификация судебных дел
Одной из проблем судебного делопроизводства является процедура определения категории и харак- тера спора. Правильное определение категории су- дебного спора важно, поскольку влияет на назначе- ние судьи на соответствующий процесс, а назначае- мый судья должен иметь максимальный опыт рас- смотрения подобных споров. На текущий момент выявлено около 60 различных категорий судебных споров, которые встречаются с разной частотой. За определение категории судебного дела отвечает модуль классификации судебных дел. Процесс классификации с ростом количества обрабатывае- мых документов может быть очень затратным по времени, поэтому с архитектурной точки зрения было решено вынести данную функциональность как отдельный микросервис с реализацией обмена с другими модулями системы в асинхронном режиме.
К тому же определение категории спора (судебного дела) не является задачей, требующей мгновенного ответа.
На уровне межсервисного взаимодействия об- щий алгоритм обработки документа выглядит сле- дующим образом: на вход подается идентификатор документа; из документа выделяются ключевые слова и их количество; проводятся анализ и подбор класса дела; алгоритм возвращает идентификатор класса судебного дела, который становится допол- нительным свойством документа. При добавлении нового класса проводятся анализ допустимых клю- чевых слов и повторное обучение нейронной сети.
К сожалению, на текущий момент нами оконча- тельно не выбран оптимальный способ реализации данной задачи – рассматривается реализация алго- ритма с использованием глубинного обучения и
сверточных нейронных сетей или с использованием латентно-семантического анализа.
2.6 Создание шаблонов исковых заявлений Отдельной задачей является сопоставление су- дебных актов и заявлений по рассмотренным делам, поскольку сами исковые заявления, в отличие от базы знаний принятых решений, являются закры- тыми и не публикуются в сети интернет. В рамках разработки системы «Робот-юрист» актуальной яв- ляется задача связывания вновь поданного искового заявления и близких результатов судебных процес- сов для дальнейшей обработки. В этом случае необ- ходимо иметь заявление в размеченном виде, удоб- ном для машинной обработки. Для этого необходи- мо либо отдельно предусматривать процесс размет- ки массива электронных копий бумажных исковых заявлений, либо формировать заявления изначально в электронном виде и далее распечатывать готовое заявление с помощью системы. Второй вариант яв- ляется предпочтительным, и его было предложено реализовать в рамках создания прототипа системы.
Для получения экземпляров исковых заявлений сразу в электронном виде был предложен механизм веб-портала – шаблонизатора заявлений. При пода- че пользователем системы искового заявления си- стема формирует печатную версию заявления в со- ответствии с регламентирующими нормативными документами РФ, а электронная копия документа автоматически размечается и сохраняется в базе данных системы с определенным статусом.
Процесс организован следующим образом: поль- зователь авторизуется на портале системы; ему предоставляется ряд экранных форм с полями ввода для заполнения данных. После окончания ввода данных пользователь сохраняет заявление в систе- ме; в базе данных системы появляется размеченный вариант документа для дальнейшего анализа, а пользователю предоставляется печатная форма за- полненного искового заявления.
Веб-портал предусматривает несколько ролей пользователей с различной функциональностью, также предложена и реализована статусная модель судебного дела для удобства отслеживания жизнен- ного цикла документа в системе.
2.7 Экспертная система
В рамках проекта также разрабатывается реше- ние по автоматизации предоставления экспертных консультаций по вопросам юридического характера.
Решение представляет собой экспертную систему (ЭС) (см., например, [12]) – компьютерную систему, способную частично заменить эксперта-специалиста в разрешении какой-либо проблемы юридического характера.
В рамках проекта реализована экспертная систе- ма в области защиты интеллектуальной собственно- сти. Важными вопросами в автоматизации предо- ставления экспертных консультаций являются надежность решений и удобство использования,
поэтому решения ЭС подкрепляются ссылками на соответствующие нормативные документы, указан- ные юристами при формировании базы знаний.
Были определены наиболее часто встречающие- ся сценарии и вопросы в данной области права. На текущий момент реализованы 13 типовых сценариев поведения ЭС, которые практически полностью по- крывают всевозможные случаи в данной области права.
В качестве пользовательского интерфейса к экс- пертной системе был выбран интерфейс чат-бота или, другими словами, виртуального собеседника, реализованного в виде Telegram-Бота (далее – бота).
Совпадение логики процессов взаимодействия с ботом и ЭС позволяет предоставить удобный доступ к инструментам юридического консультирования со всех платформ, для которых доступен сам мессен- джер (Telegram). Логика работы модуля представля- ет собой конечный автомат, а использование бота в качестве интерфейса к ЭС позволяет снизить трудо- затраты на разработку пользовательского интерфей- са и сконцентрироваться на функционале ЭС вслед- ствие простоты разработки.
3 Заключение
Теоретические исследования в рамках текстовой аналитики показывают наличие готовых или прак- тически готовых инструментов для реализации функций отдельных модулей системы. Необходимы лишь их грамотное объединение и применение в отдельно взятых предметных областях. «Робот- юрист» должен стать именно такой демонстрацией применения известных подходов и алгоритмов в юриспруденции.
На данный момент завершен первый этап созда- ния системы – закончено проектирование системы и реализован прототип системы «Робот-юрист», про- изводится разметка документов. Для успешного завершения работ и перевода в опытную эксплуата- цию требуется дальнейшая оптимизация как раз- личных алгоритмов текстовой аналитики, так и пользовательского интерфейса. Выбранная архитек- тура построения приложения позволяет произво- дить модификацию отдельных модулей системы, не затрагивая общего механизма взаимодействия. Так- же необходимы апробация инструментов системы на большем массиве документов и рефакторинг программного кода.
Поддержка
Работа выполнена за счет средств субсидии, вы- деленной Казанскому федеральному университету для выполнения государственного задания в сфере научной деятельности, проект 2.8712.2017/БЧ.
Литература
[1] Елизаров, А. М., Жижченко, А. Б. Жиль- цов, Н. Г., Кириллович А. В., Липачёв, Е. К.:
Онтологии математического знания и рекомен- дательная система для коллекций физико-
математических документов. Докл. Академии наук, 467 (4), с. 392-395 (2016). doi:
10.1134/S1064562416020174
[2] Елизаров, А. М., Липачёв, Е. К., Невзоро- ва О. А., Соловьев, В. Д.: Методы и средства семантического структурирования электрон- ных математических документов. Докл. Ака- демии наук, 457 (6), с. 642-645 (2014). doi 10.7868/S0869565214240049
[3] Ингерсолл, Грант С., Мортон, Томас С., Фэр- рис, Эндрю Л.: Обработка неструктурирован- ных текстов. Поиск, организация и манипули- рование / Пер. с англ. Слинкин А. А. М.: ДМК Пресс, 414 с.: ил. (2015)
[4] Peroni, S.: SemanticWeb Technologies and Legal Scholarly Publishing Law, Springer, Governance and Technology Series, 15 (2014). doi 10.1007/978-3-319-04777-5
[5] Gold, N. et al.: Understanding Service Oriented Software. IEEE Software, 21 (2), pp. 71-77 (2004) [6] Jones, S.: Toward an Acceptable Definition of
Service. IEEE Software, 22 (3), pp. 87-93 (2005) [7] Fowler, М.: Microservices a definition of this new
architectural term. https://martinfowler.com/ arti- cles/microservices.html
[8] Stenetorp, P., Pyysalo, S., Topić, G., Ohta, T., An- aniadou, S., Tsujii, J.: Brat: a Web-based Tool for NLP-Assisted Text Annotation. Proc. of the Demonstrations Session at EACL (2012)
[9] Ricci, F., Rokach, L., Shapira, B., Kantor, P. B.:
Recommender Systems Handbook. N.Y.: Springer (2011)
[10] https://ru.wikipedia.org/wiki/TF-IDF [11] https://ru.wikipedia.org/wiki/K-means
[12] Джарратано, Дж., Райли, Г.: Экспертные си- стемы. Принципы разработки и программиро- вание. 4-е издание. Вильямс, 1152 c. (2007)
