Как стать автором
Обновить

Комментарии 22

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

Если у вас есть обоснованные соображения, что длина итерации в две недели коротковата для этого проекта, или что подготовка публичного релиза займет более двух итераций, это вполне справедливые опасения. Но в конечном итоге, как длина итерации, так и объем первого релиза определяются эмпирически.

Спасибо за комментарий.


Наш многолетний опыт в области high-end юриспруденции (M&A, банкротство, защита активов и др.) позволяет с уверенностью говорить о том, как должна быть построена логика работы системы Legal AI, чтобы соответствовать самым высоким требованиям и стандартам. Для примера: мы хорошо знаем, как на самом деле устроен документооборот в судебной системе: по сравнению и с тем, как есть "на бумаге", и с тем, как должно быть в идеале. Именно поэтому в статье приведен пример в виде фрагмента судебной онтологии. Для тех, кто не столько глубоко погружен в тему — разработчик, data scientist (то есть по пирамиде Акоффа находится на уровнях data и information), действительно увидеть всю картину невозможно. Подчеркну, что наш подход не отменяет необходимости тесного общения с заказчиком и проработки всех деталей на этапах согласованиях ТЗ, написания проектного решения, выпуска релизов и т. п.


В плане нашей критики agile: мы не говорим о том, что Agile — это плохой подход. Наша критика сфокусирована на том, что применение Agile именно создании продуктов — крайне рискованная затея. Стремление создать для клиента "quick win" вполне разумно и обоснованно, однако на практике существенно ограничивает перспективы проектов: LegalTech все никак не может перерасти в настоящий Legal AI.

Наша критика сфокусирована на том, что применение Agile именно создании продуктов — крайне рискованная затея. Стремление создать для клиента «quick win» вполне разумно и обоснованно

Это ложное представление. Аджайл не для быстрых побед, а для митигации рисков.

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

Наш многолетний опыт в области high-end юриспруденции (M&A, банкротство, защита активов и др.) позволяет с уверенностью говорить о том, как должна быть построена логика работы системы Legal AI, чтобы соответствовать самым высоким требованиям и стандартам.

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

Есть сложные вопросы, связанные с деконструкцией субъектности. Я сам еще не вполне разбираюсь в этой теме, но какие должны быть законы в свете новых открытий о человеке? Как применять те законы, что уже есть в свете тех же открытий?
Ну вот, например, акцепт. Акцепта же не существует в реальности, это просто такая игра словесная.
Это элементарно проверить: EULA каждого первого сервиса включает в себя отказ от ответственности. Но при этом в межличностных отношениях отказ от ответственности — красный флаг и с человеком, который свою ответственность отрицает просто не будут говорить. А под EULA подписываются и бровью не ведут.
Хотя, разумеется, если у личности могут быть разумные основания отказаться от ответственности (психически здоровых людей не бывает), то компания, в которой работают люди с самыми разными особенностями принципиально имеет более широкие возможности, чем отдельный человек. Даже два человека, с несовпадающими отклонениями друг-друга корректируют, а у компании в 300 человек вообще 0 оснований для такого отказа. Получается, что обычный механизм регуляции отношений, который мы используем для людей просто не работает с компаниями.
Это ложное представление. Аджайл не для быстрых побед, а для митигации рисков.

Мы, юристы, — довольно упрямые создания и любим вдумчиво читать первоисточник:


"Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения."


"Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев."


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


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

Большое спасибо за комментарий! Именно такую позицию мы сотни и, наверное, уже тысячи раз встречали в общении с разработчиками / представителями IT. Более того, именно такая позиция отчасти и сподвигла нас к тому, чтобы написать этот цикл статей. Мы максимально подробно, на простом русском языке стремимся объяснить тем, кто имеет очень поверхностное представление о юриспруденции, что даже такая "очень простая операция", как проверка полномочий директора, никак не является таковой. Поэтому, чтобы не повторяться, рекомендую еще раз проанализировать наши примеры и графы из статьи.


Есть сложные вопросы, связанные с деконструкцией субъектности. Я сам еще не вполне разбираюсь в этой теме, но какие должны быть законы в свете новых открытий о человеке? Как применять те законы, что уже есть в свете тех же открытий?

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

Мы, юристы, — довольно упрямые создания и любим вдумчиво читать первоисточник

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

Большое спасибо за комментарий! Именно такую позицию мы сотни и, наверное, уже тысячи раз встречали в общении с разработчиками / представителями IT.

И на то есть основания. Если мне нужно сделать сайт, то каким бы сложным сайт ни был, это все равно простая работа, потому что задача разбивается на простые операции, с которыми любой человек может справиться.

С точки зрения юриспруденции, есть веками зарекомендовавшаяся себя практика изменения правовых норм

А кем и к кому применяются правовые нормы? И что вообще означает «применить норму»?
вы оба правы — хотя и пишете о разном.
(этот тред — прямо как КПДВ, только в тексте)

PS: небольшое примечание:
Если мне нужно сделать сайт, то каким бы сложным сайт ни был, это все равно простая работа, потому что задача разбивается на простые операции, с которыми любой человек может справиться.
вот сразу видно математическое мышление :D: «какой бы ни был сложный юридический документ — это все равно простая работа, потому что задача разбивается на простые операции».
В реальной жизни, увы, присутствует амортизация на разбиения: чем меньше кусочки и чем больше их количество — тем больше усилий нужно приложить чтобы продолжать…
И это еще без учета того, что без знания о _целом_ — его трудно построить из кусочков «снизу-вверх» и не обнаруживать каждый раз, что «какого-то еще кусочка не хватает… хммм… но какого?»
Это совсем не верно. Вы и так делаете лишь маленькие кусочки, только вы в уме объединяете их в виртуальные большие кусочки. Простая работа — это линейная работа, которая реализуема за конечное время. Любой проект — простая работа, особенно если он типовой.

Сложная работа — разрешать нерешенные противоречия.

Профессионалы стремятся избегать такой работы (и я не исключение), но все главные профиты (и риски) лежат именно в сфере противоречий.

Забавно, что как разработка, так и юриспруденция, хотя и (по большей части) простые «внутри», сами по себе в «зазеркалье»: по ту сторону неразрешенного противоречия.
(этот тред — прямо как КПДВ, только в тексте)

Спасибо, очень верно подмечено! =)

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

Мнение основано в том числе на опыте управления командой разработчиков и применении agile в разработке IT-проектов.


И на то есть основания. Если мне нужно сделать сайт, то каким бы сложным сайт ни был, это все равно простая работа, потому что задача разбивается на простые операции, с которыми любой человек может справиться.

Как верно подметил vassabi, действительно речь идет о классическом мышлении разработчика. Позиция хорошо понятна и часто оправдывает себя, но прежде чем сравнивать разработку сайта с юриспруденцией / Legal AI, я бы рекомендовал чуть больше узнать о предметной области.


А кем и к кому применяются правовые нормы? И что вообще означает «применить норму»?

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

Мнение основано в том числе на опыте управления командой разработчиков и применении agile в разработке IT-проектов.

Вот это уже интересно. Расскажите, как ваш опыт ведет к такому выводу?

Как верно подметил vassabi, действительно речь идет о классическом мышлении разработчика. Позиция хорошо понятна и часто оправдывает себя, но прежде чем сравнивать разработку сайта с юриспруденцией / Legal AI, я бы рекомендовал чуть больше узнать о предметной области.

Я чуть ниже в ответе написал, что это не «мышление разработчика», а просто мышление.

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

Мне интересно, как именно вы на этот вопрос отвечаете. Потому как те имеющиеся источники, которые я пока что находил не учитывают последние научные открытия в области изучения человека.
Как именно вы интегрируете для себя научные данные о человеке и юриспруденцию?
Вот это уже интересно. Расскажите, как ваш опыт ведет к такому выводу?

В качестве иллюстрации можно привести проект pullenti. Эта система показывает достаточно неплохие результаты при работе с некоторыми задачами NER. При этом сам проект развивался итеративно, под каждого нового заказчика. Такой подход в итоге привел к тому, что сейчас систему очень сложно использовать для решения новых задач (по сути нужен рефакторинг с нуля). Отдельно отмечу, что это не критика самого продукта (в основе системы лежит фундаментальная и детально проработанная лингвистика), а именно итеративного подхода к разработке IT-продуктов в области LegalTech.


Мне интересно, как именно вы на этот вопрос отвечаете. Потому как те имеющиеся источники, которые я пока что находил не учитывают последние научные открытия в области изучения человека.
Как именно вы интегрируете для себя научные данные о человеке и юриспруденцию?

Боюсь, что из комментариев по-прежнему не понятна суть Вашего вопроса, а читать мысли наш продукт пока не научился:


  • В чем конкретно заключается вопрос? О какой из трактовок термина "применение правовых норм" мы говорим?
  • О каких конкретно "последних научных открытиях в области изучения человека" идет речь? Где, кем и когда они опубликованы?
  • В чем конкретно недостатки классического подхода к применению правовых норм?..

Согласитесь, что достаточно трудно отвечать на вопросы формата:


Я прочитал некоторые материалы про последние открытия, которые меняют общепринятое представление об X. Что Вы можете ответить на этот вопрос?


Если Вам действительно интересна эта тема и в ней видится некая интересная тема для дискуссии, предлагаю Вам написать более подробную развернутую отдельную статью, например на Хабре.

по сути нужен рефакторинг с нуля

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

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

При этом сам проект развивался итеративно, под каждого нового заказчика

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

Боюсь, что из комментариев по-прежнему не понятна суть Вашего вопроса, а читать мысли наш продукт пока не научился:

Нет какого-то одного открытия, это фронт работ и дискуссий.

Согласитесь, что достаточно трудно отвечать на вопросы формата:

Я прочитал некоторые материалы про последние открытия, которые меняют общепринятое представление об X. Что Вы можете ответить на этот вопрос?

Ну, как последние. Лет 10 примерно. Сейчас это доминирующая концепция, но я не знаю как ее описать, потому что ситуация в настоящем всегда видится сложнее и объемнее, чем в исторической перспективе.

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

Боюсь, что Вы снова меня не поняли… Решение pullenti — достаточно известный в сфере русского NLP продукт, разработчиками которого мы, очевидно, не являемся (информация об этом есть по ссылке в предыдущем комментарии). Тем не менее мы плотно общались с его создателями и хорошо понимаем, как этот продукт создавался. Пример приведен специально с открытым исходным кодом и достаточно популярный, чтобы Вы смогли самостоятельно посмотреть "в глубину" и понять, к чему приводит отсутствие четкого видения продукта на старте в сфере LegalTech.


Как вам удается выживать в эпоху метамодерна?, если хотите.

Хорошо, спасибо.


Если Вас интересует более развернутая дискуссия, то полагаю, что Вам (как эксперту по данному вопросу) не составит большого труда описать актуальную проблематику и поделиться своими умозаключениями.

Простите, что отнял ваше время. Я неверно интерпретировал ваши мотивы и ситуацию. Всего хорошего.
Немного не понял следующее:
1. Почему стоит цель закрывать все кейсы, а не N самых популярных?
2. Почему нет у юристов общей дескрипторной и терминологической базы? Для автопилота, который ездит чётко по правилам, надо сильно модернизировать дорожную сеть, а вот юристам надо всего лишь (хе-хе) договориться о терминологии.
3. Это рекомендательная система с decision trees или нейросеть? Как оно лицензируется?

Спасибо за интерес, по вопросам:


  1. Наш опыт разработки говорит о том, что для закрытия даже нескольких самых популярных кейсов нужно проделать значительный объем подготовительной работы, построить своего рода фундамент: трансформировать имеющиеся регламенты в формализованные алгоритмы, в тесном сотрудничестве с заказчиком и непосредственными исполнителями проработать все проблемные и спорные вопросы. Если такой фундамент не создавать, то при переходе к новым кейсам велики шансы, что все придется переделывать "с нуля". По временным затратам наш подход является достаточно дорогим, особенно на самых первых этапах, но в конечном итоге оправдывает себя.


  2. Сразу вспоминается мем из сферы юриспруденции: "2 юриста — 3 мнения"…
    Для иллюстрации можно привести такой пример: как классифицировать отношения компании с ее генеральным директором — это трудовые или корпоративные отношения? С одной стороны, генеральный директор — это сотрудник организации, который работает по трудовому договору, поэтому отношения с ним — трудовая сфера. С другой стороны, генеральный директор — это единоличный исполнительный орган, который назначается решением общего собрания акционеров или советом директоров — а это уже сфера корпоративных отношений.
    Но сам вопрос действительно хороший, в следующей статье мы постараемся раскрыть его более глубоко, когда будем говорить о сравнении доступных онтологий в сфере legal.


  3. По классу решений — это интеллектуальная система поддержки принятия решений, где присутствуют как и классические алгоритмы, так и машинное обучение. Хотя, честно говорят, сегодня это уже интеллектуальная система принятия решений. Лейбл "поддержка" мы прогнозируем в скором будет не актуален, однако это требует серьезных изменений: как на законодательном, так и на психологическом уровне. Лицензирование зависит от формата сотрудничества с заказчиком, по умолчанию — это интегрируемое решение, но можно говорить также о SaaS и других форматах.


Спасибо. Про лицензирование я имел в виду несколько другое: допустим, покупатель опирается на советы вашей ИС в суде. Может ли ИС пояснить, почему надо вот так, а не иначе? Сможет ли пользователь обвинить ИС в проигрыше, если он исполнял все рекомендации?

Да, все рекомендации системы являются детализированными и могут быть интерпретированы человеком, это стандарт по умолчанию.


Тема ответственности за принимаемые решения, в том числе распределения убытков — очень непростая. Сразу возникает ряд вопросов: насколько точно были выполнены рекомендации системы? Является ли проигрыш в суде следствием ошибки работы/логики системы? Или судебное дело было проиграно по причине того, что судья по своему усмотрению принял некое аномальное решение?..


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

Спасибо за статью. Хотелось высказать несколько общих соображений.

  1. На мой взгляд, существует проблема в самой постановке задачи: заменить человека в некоторой деятельности, которая исходно формировалась именно как сугубо человеческая. Эту проблему наглядно можно пояснить на примере создания беспилотных автомобилей: есть дорожная инфраструктура, ориентированная на восприятие ее человеком (разметка, знаки, правила и пр.), есть автомобили, приспособленные для вождения их человеком, и ставится задача заменить в этой деятельности человека на IT устройство. То есть сама постановка проблемы выглядит абсурдной. Ведь, по сути, нам надо решить задачу доставки грузов или пассажиров из точки А в точку Б, а не сохранить систему созданную человеком для человека и заменить в ней человека на робота. Речь о том, что должна решаться задача автоматизации перевозок, а не автоматизация управления автомобилем. Фактически: надо не учить робота распознавать разметку, знаки и жесты водителей, а сделать электронную разметку, поставить электронные маркеры вместо знаков на столбах и объединить транспортные средства (а еще и пешеходов) в единую сеть, для согласования их действий. Аналогичная ситуация и на юридическом фронте: вся деятельность в области юриспруденции основана на взаимодействии людей посредством составления бумажных документов и трактовки их семантики людьми же. И вы осознанно ставите задачу заменить человека на робота в деятельности, которая исходно ориентирована исключительно на человека. Ведь возможен и другой подход: попытаться изменить деятельность с целью максимально исключить из нее человека (см. например "Деятельность, документы и семантика"). Понятно, что задача изменения системы не решается и даже не может быть поставлена на уровне локального предприятия, но проблема в любом случае должны быть осмыслена: какова конечная цель — заменить человека машиной в существующей юридической системе или изменить систему, чтобы минимизировать участие человека в ней.
  2. Второе соображение касается семантики и онтологии. Я понимаю, что сложно даже помыслить, что семантика может быть не объектной, а логика не субстанциональной, что нам никуда не деться от построения иерархии тысяч классов и следует смирится со статичностью онтологии. И это при полном понимании, что предметная область юриспруденции не статична, не объектна, а исключительно процессуальна, событийна, темпоральна. Да, конечно, на данный момент еще нет в достаточной степени разработанной процессуальной логики и темпоральной онтологии. Но есть наработки, в частности академика А.В. Смирнова и первые прототипы темпоральных семантических графов. Тут вопрос только в правильной постановке задачи (хотя бы на будущее, см. Семантика и деятельность).
  3. Третий момент касается автоматизации построения онтологий. Очевидно, что делать это путем анализа текстовых документов затея практически провальная. Документы — это результат деятельности, статичный результат или можно сказать плоская проекция деятельности. И тут должно само напрашиваться решение проблемы: для создания онтологии предметной области некоторой деятельности, надо парсить не документы, а саму деятельность, в результате которой появляются эти самые документы. По сути, речь идет о создании рабочего пространства/инструмента для актора/юриста, в котором он выполняет/фиксирует все события, операции, процессы по созданию документов. В итоге по анализу потока событий деятельности множество акторов можно создать онтологию. Правда для этого у нас должны быть событийная (а не объектная) онтология.

Еще раз спасибо за текст.
Большое спасибо за развернутые комментарии и интересные ссылки!
Мы внимательно ознакомились с материалами — всегда полезно посмотреть на проблему под иным углом.

1. Вы безусловно правы в том, что есть альтернативный, более фундаментальный подход трансформации юридической функции. Как Вы верно пишите в своей статье, такой подход требует принципиально нового подхода к работе с документами (по сути речь уже идет о работе не с документами, а об обмене данными).

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

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

Иными словами — участие человека в процессе принятия решений станет статистически и объективно неприемлемым.

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

2. На наш взгляд, перспективным является подход, описанный Judea Pearl в книге The Book of Why: создаваемые системы концептуализации знаний должны уметь отвечать на 3 уровня вопросов:
— связаны ли события X и Y как-либо между собой?
— является ли событие X причиной события Y?
— произошло бы событие X, если бы не произошло событие Y?

3. Подход действительно представляется интересным, однако есть большой вопрос о возможности реализации идеи на практике. Юридическая деятельность — сложная многофакторная сфера, которая лишь частично описана в законах и правилах; многие вопросы решаются при помощи common sense. В частности, нигде формально не описан процесс «вытаскивания» из клиента всей информации, необходимой для написания искового заявления. Иными словами: нет даже событийной/объектной онтологии в юриспруденции, поэтому пока не имеет смысла заниматься построением мета-онтологий по извлечению, нахождению соответствующей информации.

Отдельно хотелось бы прокомментировать Ваш тезис из материалов по ссылке:

Проблема не решается использованием электронных документов, поскольку смысл текста в файле документа недоступен для цифровой модели деятельности. То есть, прежде всего, должна быть решена задача “понимания” цифровой моделью деятельности семантики документа. При этом очевидно, что речь не должна идти о прямом распознании содержания текста, написанного на естественном языке (скажем, с привлечением ML-технологий), поскольку результат такого “понимания” не может быть признан однозначным.


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

1) в контексте Legal AI понимание текста носит не абстрактный, а предельно конкретный характер (например, когда нужно разрешить спор в суде по существу на основании представленным материалов), поэтому количество вариантов интерпретации текста, которые несут практическую ценность, достаточно ограничено;

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

Именно поэтому мы считаем, что, несмотря на существующие многочисленные трудности, ключом к созданию Legal AI является возможность понимания и интерпретации текстов на естественном языке в контексте предметной области.

Еще раз спасибо за развернутые комментарии и полезные материалы!
Спасибо за ответ и интерес к текстам (я дал лишь две ссылки, но, наверное, вы сами нашли здесь же на хабре тексты по парсингу деятельности, событийной онтологии, есть еще тексты по документообороту в других изданиях).

1. Безусловно понятно, что на данном этапе разумно работать в рамках существующего состояния предметной области. Однако я вижу, что и в текущих условиях есть возможность сделать шаг вперед относительно машинного анализа документов на естественном языке. Как минимум можно реализовать семантическую разметку документов (речь в большей степени идет о корпоративных), которая никак не повлияет на человеко-читаемость (только стандартизирует ее), но позволит проводить строгий (а не вероятностный) анализ текста. В идеальном варианте документ должен представлять собой машиночитаемый граф с пояснительными или связующими фрагментами текста, делающими документ полностью человеко-читаемым, причем вся структура графа защищается подписями, и должна иметься возможность внесения изменений в документ с сохранением всей истории. По сути, я описал идею стартапа для системы корпоративного документооборота.

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

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

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

Спасибо, было бы интересно посмотреть! Будем следить за Вашими публикациями.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории