Pull to refresh

Comments 17

Статья больше про лингвистический анализ, чем про ии в юриспруденции. Но в целом очень интересно и хочется выразить автору большую благодарность за проделанную работу. Среди выводов, на мой взгляд, стоит добавить то, что идея отказа от «живого» юриста обречена из-за проблемы ввода-вывода. Даже если научить ии правильно анализировать текст, и на основе этого анализа делать какие-либо выводы, ссылаться на нормы права и прочее, в идее «робота юриста» остаётся слабое звено — оператор. Без понимания «юридической картины мира» нельзя дать программе правильный ввод, описать полную картину происходящего. Попытка предусмотреть все возможные варианты привет к тому, что любой запрос к ии будет выливаться в полуторачасовой опросник.
Благодарю за комментарий!
Как юрист я хорошо понимаю проблему «ввода» и интерпретации смыслов. Однако есть понимание, что данная проблема имеет рациональное решение; именно на эту тему сейчас готовится материал для следующей статьи.
ИМХО:
В большинстве естественных языков в тексте можно отыскать более одного смысла. Хорошая система должна извлекать все возможные, и давать пользователю возможность оперировать с удобным ему. Я так понял ни одна из обозреваемых систем этим не занимается.

Спасибо за комментарий!
С пониманием текста ситуация выглядит примерно так:


image


В одном и том же тексте бухгалтер, юрист, разработчик, инженер и каждый другой видит свои смыслы. Поэтому универсальных (any domain) решений пока нет и, скорее всего, для их создания не обойтись без сильного ИИ (AGI).

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

Недостатки в выделении смыслов, которые описываете Вы, чаще вообще — просто ошибки «недоученного» автомата. Да, бывают проблемы неизвестности контекста предметной области, но не стоит ждать «сильного ИИ», чтоб дообучить автомат этому контексту.

Бывают и просто проблемы многозначности слов, (например, «замок на замке» — что здесь на чём? и висит, стоит или нарисовано?) тогда система должна выдать все смыслы в распоряжение более сильному интеллекту, а главное потребителю её работы — человеку. Почему это «нечеткое» распознавание не принято делать, почему ИНС должна разглядеть в картинке или лягушку, или фонарь, а не выдаст, что это «фонарь + лягушка = фонарь в виде лягушки» — для меня загадка.

Извлечение всех разумных смыслов из текста — достаточно сложная задача, насколько мне известно, пока нет практических методик по ее решению.


Мой любимый пример в подтверждение тезиса — Winograd Schema Challenge:


  • на ввод подается предложение: "Приз не влезал в чемодан, потому что он был слишком __ " и задается вопрос "Он — это что?";
  • вместо пропуска может быть либо "большой", либо "маленький";
  • в зависимости от пропущенного слова ответ меняется на противоположный: если "слишком маленький", то правильный ответ "чемодан", если "слишком большой", то — "приз".

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


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


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

Благодарю, ознакомился. Тема объемная, универсального действенного решения нет. Работаем по привычным методикам.

Спасибо за обзор, вижу что "мы" в начале трудного пути.


По моему опыту проблема понимания текстов начинается с того, что большая часть информации попадает в обработку в виде сканов документов. Причем не качественных, т.к. зачастую это бывают сканы не качественных прошитых копий с печатями. OCR от лидеров рынка, к сожалению, плохо справляются с некачественными сканами, плюс лингвистические модели зашитые в них слабо подходят для нашей предметной области. Повсеместного внедрения ЭЦП я, увы, пока не наблюдаю. И если можно приставить человека вычитывать входящие документы после OCR, то вычитывать корпуса необходимые для обучения моделей — уже сложнее. Т.е. текст для понимания нужно еще заслужить. Стоит отметить, что модели основанные на правилах, как правило, гораздо менее толерантны к опечаткам в тексте, чем модели основанные на DL.


Что касается открытых корпусов для обучения эмбеддингов и лингвистических моделей, то с моей точки зрения это не является проблемой. В открытом доступе есть 40 млн документов арбитражных судов, есть федеральное, региональное и муниципальное законодательство, есть документы публичных компаний. Можно обучить ELMo с нуля, можно дообучить BERT. Вот еще полезная инициатива: https://github.com/irlcode/RusLawOD


Если говорить о проблеме ИИ в данной области в целом, то возможно не стоит пытаться создать AGI раньше Google. Завышенные ожидания у бизнеса, которые зачастую подпитываются обещаниями "магов", скорее вредят отрасли. Мне понравилась модель юридического бизнеса в виде треугольника, где в основании находятся паралигалы, в центре консультанты, а на вершине партнеры. И на выступлении, где эта модель упоминалась, предлагалось путем внедрения основанных на ИИ технологий превратить треугольник в ромб. Т.е. для начала можно решить массовые задачи, для которых существуют большие объемы документов и экспертиза, научиться в условных 90% случаев принимать правильные решения, и с хорошей точностью отличать эти 90% от 10%, когда нужно позвать человека. Я допускаю, что на каком-то этапе при решении такого класса задач, можно будет превзойти результаты человека.


Для решения не массовых задач юристам нужны справочно-правовые системы, хотя мне больше нравится английский термин CALR — computer assisted legal research, в этой области есть много не решенных задач, для которых не требуется AGI, но обработка больших объемов информации, например, судебной практики.


Спасибо, буду следить за вашими успехами.

Спасибо за развернутый и вдумчивый комментарий!
Проблема с OCR действительно есть, но очень хочется верить, что в скором времени мы увидим прорывы в работе с русским языком от разработчиков в этой области.
А пока, очевидно, лучше работать в тех областях, где наличие электронной копии документа — де-факто стандарт.

Как я вижу, качественные модели для syntax analysis вы так и не взяли… Ну, может, взяли одну или две, но deeppavlov и stanford parser бывают разных версий… А сравнивать модели, выученные на GST/Taiga, которые в 10 раз меньше корпуса syntagrus — это вообще наивно.
C ЭТАП тоже штука сложная: для более распространённых слов и фраз точность его очень неплохая, у него были проблемы с полнотой: чтобы на всех документах и незнакомых словах показывать более хорошие результаты, потому что это система на правилах.
И ещё, как вы думаете, сколько нужно проанализировать примеров парсинга, чтобы уверенно выдавать заключения наподобие «нарушение последовательности связей в сложных предложениях и числовых значениях» или «эта библиотека работает лучше вот этой»?
Я вообще не понимаю, как вы смогли получить какие-то разумные обоснования в вашей оценке качества. Правда, наверное, это я, зная, какая библиотека с каким качеством работает, могу их разумно проинтерпретировать…
Посмотрите на более хороший анализ: github.com/natasha/naeval
А вот здесь ещё датасетов для тестирования моделей подвезли: habr.com/ru/company/sberbank/blog/506058

С точки зрения канонического data science, Ваша позиция вполне понятна и разумна: надо всегда использовать самую SOTA-версию библиотеки, тестировать на общепринятых датасетах, приводить выверенные метрики accuracy, f1/f2… Таких инициатив достаточно много, и поэтому мы не ставили задачу сделать еще leaderboard.


Наша ценность и вклад принципиально в другом — мы можем оценить практическую применимость существующих решений для автоматизации юридической функции. В частности, надо четко понимать, что юридические тексты имеют существенную специфику и очень не похожи на тексты научных статей, новостей, литературных произведений (как мы описали на примерах). Соответственно, представляется маловероятным, что появление какой-то новой модели с приростом качества в несколько процентных пунктов вдруг "заработает" на юридических текстах.

>тестировать на общепринятых датасетах
Нет, моя позиция другая: вам нужно сделать юридический датасет, пусть даже на 500 предложений, и протестировать имеющиеся решения на нём автоматически. Вот можете прямо взять скрипты из naeval.
Потому что как раз ценность тестирования на 5 предложениях под предлогом «мы можем оценить практическую применимость существующих решений» мне непонятна. Нет, не можете, вы даже не знаете, получили ли вы хорошую оценку применимости этих библиотек, если вы на 5 примерах прогоняли и делали выводы. Вы легко можете заблуждаться на небольшом числе примеров. Понимаете?
вам нужно сделать юридический датасет

Именно так мы и поступили, в статье для наглядности представлены наиболее характерные примеры по итогам тестирования и анализа результатов.

Спасибо, это многое объясняет. Опубликовать не хотите?

Интересная статья, спасибо.


Жаль, что вы не добавили в проверку проект spacy-ru (его автор, buriy, тоже здесь). По моему опыту, неплохой результат.

Я чуть выше уже в этой статье комментировал: habr.com/ru/post/506086/#comment_21727492

Относительно наилучшего качества для русского языка:
Пожалуй, мы ждём spacy 3.0, в котором будут и классические модели, оптимизированные для CPU, и русские модели на основе RoBERTa, оптимальные для GPU (и запуска батчами).
Собственно, классические модели из 2.3 для 3.0 я уже натренировал:
github.com/buriy/spacy-ru/releases/tag/v2.3_beta, а, как время будет, натренирую и более качественные, но более медленные.
И я обязательно напишу об этом статью на Хабре, только это будет наверное уже в декабре.

А именно для Legal была ещё идея сделать отдельный LegalBERT.
Вот ребята рассказывают про их подход к этой задаче и их NER: www.youtube.com/watch?v=lTM1tgYW72o
Sign up to leave a comment.

Articles