Анализ договорных рисков при помощи искусственного интеллекта

[staffel]

Скажите пожалуйста: какова цель данной статьи?

Отчет о работе? Инструкция? Что-то другое?

[favioes]

Это практический инженерный кейс про внедрение LLM в юрпроцесс: архитектура, парсинг docx, нормализация нумерации, промпт и SGR, протокол экспериментов и измеримые эффекты.

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

[johnnyBoy1984]

спасибо за интересную статью! работаю в страховой компании, очень интересный опыт использования ии агентов

[aborouhin]

Плюсик за технические подробности. Сам когда первый раз полез в эту тему, удивился, что ни одна библиотека для парсинга docx режим рецензирования не поддерживает нормально. Ладно читать, а вот когда хочется в этом режиме выдавать результат... По нумерации Вам в копилку ещё кейс - нумерация полями AUTONUMLGL или LISTNUM, лично я у себя её использую, т.к. автонумерация на сложной структуре имеет обыкновение непредсказуемым образом слетать.

Не вполне понял, в каком формате Вы получаете результат. Просто замечания (а там пусть менеджер правит как хочет), протокол разногласий, исправленный текст? Если первое - это проще, но часто от юристов ожидают второе или третье.

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

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

[favioes]

1. По Track Changes и нумерации: да, многие библиотеки это ломают. У нас поэтому сначала предобработка docx (убираем <w:del> , разворачиваем <w:ins> ), потом восстанавливаем номера пунктов через numbering.xml. Про AUTONUMLGL/LISTNUM — спасибо, хороший кейс

2. Формат результата сейчас простой: это не “исправленный договор”, а замечания/подсветка риск-пунктов в отчёте — номер пункта, к какому риску относится, confidence и короткое объяснение

3. Про “минуты”: я имел в виду ускорение первичного прохода по типовым рискам (мы видим 5×–10×), но это не тезис “договор можно не читать вообще”

[Yaro]

Спасибо, очень интересно разобран кейс.

[Intelllectual]

В целом ОК за исключением пресловутого JSON... В школе не учили о деградации на JSON разметках из за размытого Attention и кашеобразных векторов {}?

[favioes]

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