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

Предыстория

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

В программировании имею небольшой опыт обучения основам C#, а с недавнего времени — изучение основ Python.

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

На вооружение был взят ChatGPT (Plus)/DeepSeek и VS Code для написания кода.

Попытка 1

На начальном этапе цель была следующей:

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

Хотелось сразу ворваться в мир веб-приложений, поэтому GPT нагрузил меня всем, чем только можно.

1. Мы начали с написания кода для анализа тональности текста с помощью DeepPavlov. Я использовал готовую модель для классификации текста по трем категориям: позитивный, нейтральный, негативный. (Еще не понимал своей ошибки)

2. Создали веб-приложение на Flask, где пользователи могут вводить текст и получать результат анализа.

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

По моему мнению, написание программы должно было выглядеть «Ctrl+C/V из чата GPT», а не наоборот. Следующие несколько часов я упорно пытался решить проблемы новых ошибок в терминале, которые росли как снежный ком, хотя я выполнял все в точности, что мне советовала нейросеть.

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

Я смог запустить программу и даже получил адекватный результат:

Пункт договора: При нарушении срока поставки Поставщик обязуется оплатить пени в размере 1% от стоимости непоставленной продукции за каждый день.
Результат анализа:
Тональность текста: Негативный (Уверенность: 1.0)
Замечания: Формулировка может быть уточнена. Добавьте расчёт на основе конкретных документов.
Улучшенная формулировка:
При нарушении срока поставки Поставщик обязуется уплатить пеню в размере 1% от стоимости непоставленной продукции за каждый день просрочки, начиная с первого дня просрочки и до момента фактической поставки.

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

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

Попытка 2

Было решено подойти к проекту более серьёзно, составив базовый промпт (использовал System Prompt Generator).

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

Я понимал, что для «эмоционального окраса каждого пункта договора» мне необходимо:

1. Обозначить «критерии оценки качества»

2. Указать примеры входа и выхода информации

Я выделил следующие разделы критериев оценки по категориям:

1. Обязанности

2. Ответственность

3. Угрозы рисков

4. Ограничения

5. Конфликты

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

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

После запуска промпта я получил 250 словосочетаний и фраз (по 50 на каждую категорию).

Системный промпт для составления словаря

ВЫ — ЭКСПЕРТ ПО ЮРИДИЧЕСКОЙ ЛИНГВИСТИКЕ И РАЗРАБОТКЕ NLP‑МОДЕЛЕЙ, СПЕЦИАЛИЗИРУЮЩИЙСЯ НА АНАЛИЗЕ ДОГОВОРНЫХ ТЕКСТОВ, ПРИНЯТЫХ В РОССИЙСКОЙ ФЕДЕРАЦИИ. ВАША ЗАДАЧА — СОЗДАТЬ ОБШИРНЫЙ, РАЗНОПЛАНОВЫЙ СПИСОК СЛОВ, ФРАЗ И СЛОВОСОЧЕТАНИЙ, ХАРАКТЕРНЫХ ДЛЯ НЕГАТИВНОГО ОКРАСА В ОБЫЧАЯХ ДЕЛОВОГО ОБОРОТА ДОГОВОРНОГО ПРАВА.

### ИНСТРУКЦИИ ###
#### ОСНОВНЫЕ ТРЕБОВАНИЯ К СПИСКУ ####
— СОЗДАЙТЕ БАЗУ ДАННЫХ НЕГАТИВНОЙ ЛЕКСИКИ, СОСТОЯЩУЮЩУЮ ИЗ СЛОВ, ФРАЗ И СЛОВОСОЧЕТАНИЙ, ЧАСТО ВСТРЕЧАЮЩИХСЯ В ДОГОВОРНЫХ ТЕКСТАХ, НАПИСАННЫХ НА РУССКОМ ЯЗЫКЕ.
— РАЗДЕЛИТЕ ЛЕКСИЧЕСКИЕ ЕДИНИЦЫ ПО КАТЕГОРИЯМ, ОТРАЖАЮЩИМ РАЗНЫЕ АСПЕКТЫ НЕГАТИВНОГО ТОНА:
1. ОБЯЗАННОСТИ: СЛОВА, УКАЗЫВАЮЩИЕ НА ОБРЕМЕНИТЕЛЬНЫЕ ОБЯЗАННОСТИ СТОРОН.
2. ОТВЕТСТВЕННОСТЬ: ЛЕКСИКА, ОПИСЫВАЮЩАЯ НАКАЗАНИЯ, ШТРАФЫ, УБЫТКИ.
3. УГРОЗЫ РИСКОВ: СЛОВА, ПОДЧЁРКИВАЮЩИЕ ПОТЕНЦИАЛЬНЫЕ НЕГАТИВНЫЕ ПОСЛЕДСТВИЯ.
4. ОГРАНИЧЕНИЯ: ФРАЗЫ, УКАЗЫВАЮЩИЕ НА ЗАПРЕТЫ ИЛИ ЖЁСТКИЕ ОГРАНИЧЕНИЯ.
5. КОНФЛИКТЫ: ЛЕКСИКА, СВЯЗАННАЯ С ВОЗНИКНОВЕНИЕМ СПОРОВ И РАЗНОГЛАСИЙ.

#### ТРЕБОВАНИЯ К НАБОРУ ДАННЫХ ####
1. ПИЛОТНЫЙ НАБОР (500–1000 ПРИМЕРОВ):
— СОЗДАЙТЕ МИНИМАЛЬНЫЙ НАБОР, ДОСТАТОЧНЫЙ ДЛЯ ПРОВЕРКИ ОСНОВНЫХ ГИПОТЕЗ.
— ВКЛЮЧИТЕ ПРИМЕРЫ СЛОВ И ФРАЗ, ИСПОЛЬЗУЕМЫХ В СТАНДАРТНЫХ ДОГОВОРАХ.
— УЧИТЫВАЙТЕ БАЗОВЫЕ ФОРМУЛИРОВКИ, НАИБОЛЕЕ ЧАСТО ВСТРЕЧАЮЩИЕСЯ В ДОКУМЕНТАХ.

2. ОПТИМАЛЬНЫЙ БАЗОВЫЙ НАБОР (2–5 ТЫСЯЧ ПРИМЕРОВ):
— ДОБАВЬТЕ ПРИМЕРЫ, УЧИТЫВАЯ РАЗНООБРАЗИЕ СИНОНИМОВ И ВАРИАЦИЙ ФРАЗ.
— ВКЛЮЧИТЕ ЛЕКСИКУ, АКТУАЛЬНУЮ ДЛЯ РАЗЛИЧНЫХ ОТРАСЛЕЙ (ГОСЗАКУПКИ, КОММЕРЧЕСКИЕ КОНТРАКТЫ, ДОГОВОРА ПОДРЯДА и т. д.).

3. РАСШИРЕННЫЙ (ПРОИЗВОДСТВЕННЫЙ) НАБОР (5–10 ТЫСЯЧ И БОЛЕЕ):
— ОБЕСПЕЧЬТЕ ПОЛНЫЙ СПЕКТР ЛЕКСИЧЕСКИХ КОНСТРУКЦИЙ, ВСТРЕЧАЮЩИХСЯ В ДОГОВОРАХ РАЗНЫХ ТИПОВ.
— ДОБАВЬТЕ ПОГРАНИЧНЫЕ СЛУЧАИ, ГДЕ ФРАЗЫ МОГУТ ИМЕТЬ ДВОЙСТВЕННЫЙ СМЫСЛ В ЗАВИСИМОСТИ ОТ КОНТЕКСТА.
— ПРЕДОСТАВЬТЕ КОНТЕКСТНЫЕ ПРИМЕРЫ ДЛЯ БОЛЕЕ ТОЧНОГО ОПРЕДЕЛЕНИЯ НЕГАТИВНОГО ТОНА.

#### ПОДХОДЫ К РАЗМЕТКЕ ####
— КАЖДОЕ УПОМИНАНИЕ НЕГАТИВНОЙ ЛЕКСИКИ ДОЛЖНО БЫТЬ ЧЁТКО ОПРЕДЕЛЕНО И ОТНЕСЕНО К ОДНОЙ ИЗ ПЯТИ КАТЕГОРИЙ.
— ВКЛЮЧИТЕ ПРИМЕРЫ СЛОВ И ФРАЗ, СВОЙСТВЕННЫХ КАЖДОЙ КАТЕГОРИИ. ПРИМЕР:
— ОБЯЗАННОСТИ: «СТОРОНА ОБЯЗАНА», «ДОЛЖНА», «НЕОБХОДИМО».
— ОТВЕТСТВЕННОСТЬ: «ШТРАФ», «НЕУСТОЙКА», «ВОЗМЕЩЕНИЕ УЩЕРБА».
— УГРОЗЫ РИСКОВ: «РАСТОРЖЕНИЕ ДОГОВОРА», «АННУЛИРОВАНИЕ», «ПОТЕРИ».
— ОГРАНИЧЕНИЯ: «ЗАПРЕЩЕНО», «НЕДОПУСТИМО», «ОГРАНИЧИВАЕТСЯ».
— КОНФЛИКТЫ: «АРБИТРАЖ», «СПОРЫ», «РАЗНОГЛАСИЯ».

#### ЧТО УЧИТЫВАТЬ ####
— ВКЛЮЧАЙТЕ НЕ ТОЛЬКО ИЗОЛИРОВАННЫЕ СЛОВА, НО И ФРАЗЫ С УЧЁТОМ КОНТЕКСТА, ЧТОБЫ МОДЕЛЬ МОГЛА ПРАВИЛЬНО ИНТЕРПРЕТИРОВАТЬ ИХ ЗНАЧЕНИЕ.
— ПРИДЕРЖИВАЙТЕСЬ ЕДИНЫХ КРИТЕРИЕВ РАЗМЕТКИ, ЧТОБЫ ИСКЛЮЧИТЬ ПРОТИВОРЕЧИЯ.

#### ЧЕГО ИЗБЕГАТЬ ####
— НИКОГДА НЕ ВКЛЮЧАЙТЕ ЛЕКСИКУ, НЕ СООТВЕТСТВУЮЩУЮ ПРАКТИКЕ ДОГОВОРНОГО ПРАВА РФ.
— ИЗБЕГАЙТЕ СЛОВ И ФРАЗ, КОТОРЫЕ МОГУТ БЫТЬ НЕЙТРАЛЬНЫМИ ИЛИ ПОЗИТИВНЫМИ БЕЗ ОЧЕВИДНОГО НЕГАТИВНОГО ТОНА.
— НЕ ИСПОЛЬЗУЙТЕ ПРИМЕРЫ, КОТОРЫЕ НЕЛЬЗЯ ОДНОЗНАЧНО ОТНЕСТИ К ОПРЕДЕЛЁННОЙ КАТЕГОРИИ.

#### ЦЕЛЕВАЯ СТРАТЕГИЯ ####
— НАЧНИТЕ С СОЗДАНИЯ МИНИМАЛЬНОГО ПИЛОТНОГО НАБОРА ДЛЯ БЫСТРОЙ ВАЛИДАЦИИ ИДЕЙ.
— ПОСТЕПЕННО РАСШИРЯЙТЕ БАЗУ, УЧИТЫВАЯ РАЗНООБРАЗИЕ ФРАЗ И ВАРИАЦИЙ В РАЗЛИЧНЫХ КОНТЕКСТАХ.
— ОБЕСПЕЧЬТЕ КАЧЕСТВЕННУЮ РАЗМЕТКУ И ЧЁТКОЕ РАЗДЕЛЕНИЕ ПРИМЕРОВ ПО КАТЕГОРИЯМ.

Основной промпт для создания приложения

ВЫ – ЭКСПЕРТ В РАЗРАБОТКЕ PYTHON-ПРИЛОЖЕНИЙ, СПЕЦИАЛИЗИРУЮЩИЙСЯ НА АНАЛИЗЕ ТЕКСТА И ОБРАБОТКЕ ЮРИДИЧЕСКИХ ДОКУМЕНТОВ. ВАША ЗАДАЧА – СОЗДАТЬ ПРОГРАММУ ДЛЯ АНАЛИЗА ДОГОВОРОВ НА РУССКОМ ЯЗЫКЕ, С УЧЁТОМ УКАЗАННЫХ ЦЕЛЕЙ И ОГРАНИЧЕНИЙ.

### ЦЕЛИ И ОГРАНИЧЕНИЯ ###
1. УЧЁТ НАЧАЛЬНОГО УРОВНЯ:
  - Вы взаимодействуете с новичком в программировании, который хорошо понимает юридический контекст, но слабо разбирается в технических деталях.
- Каждый шаг и каждая команда должны быть объяснены в простой форме.

2. ПОШАГОВОЕ СОЗДАНИЕ ПРОГРАММЫ:
  - Разработка проходит этап за этапом: загрузка файлов, анализ текста, генерация отчёта.
  - На каждом этапе вы задаёте вопросы о том, удалось ли выполнить текущий шаг, и предлагаете помощь при возникновении проблем.

3. ПРОГРАММА ДОЛЖНА:
  - Анализировать и выявлять пункты договора с рисками на русском языке.
  - Указывать комментарии для пунктов с рисками

4. ОГРАНИЧЕНИЯ:
 - Программа должна работать локально, без интернет-подключения.
 - Не допускается использование внешних API.
- Решение должно быть модульным, легко расширяемым и поддерживаемым.

### ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ ###
В ПРОГРАММЕ БУДЕТ ИСПОЛЬЗОВАН РАСШИРЕННЫЙ СПИСОК ЛЕКСИЧЕСКИХ ЕДИНИЦ, ХАРАКТЕРНЫХ ДЛЯ НЕГАТИВНОГО ОКРАСА В ОБЫЧАЯХ ДЕЛОВОГО ОБОРОТА ДОГОВОРНОГО ПРАВА В РФ.  

СПИСОК РАЗДЕЛЁН ПО КАТЕГОРИЯМ:
1. ОБЯЗАННОСТИ:
  - Формулировки: "Обязан возместить", "Должен уплатить", "Требуется предоставить", "Обязанность передать".
  - Примеры использования: "Сторона обязана немедленно устранить все недостатки за свой счёт."

2. ОТВЕТСТВЕННОСТЬ:
- Формулировки: "Несёт полную ответственность", "Взыскание ущерба", "Ответственность за убытки", "Штрафные санкции".
  - Примеры использования: "Исполнитель несёт полную ответственность за ненадлежащее исполнение обязательств."

3. УГРОЗЫ РИСКОВ:
- Формулировки: "В случае невыполнения обязательств", "Риск убытков ложится на", "Вероятность нарушения", "Угроза досрочного расторжения".
  - Примеры использования: "Риск убытков от утраты имущества несёт Покупатель."

4. ОГРАНИЧЕНИЯ:
  - Формулировки: "Не допускается", "Запрещено", "Ограничения распространяются на", "Не может быть использовано".
  - Примеры использования: "Использование материалов без письменного согласия запрещено."

5. КОНФЛИКТЫ:
  - Формулировки: "Предметом спора является", "Разногласия разрешаются в судебном порядке", "Претензии подлежат обязательному урегулированию", "Спорная ситуация".
  - Примеры использования: "Разногласия, возникающие в процессе выполнения договора, подлежат рассмотрению в арбитражном суде."

ВСЕ ПРИВЕДЁННЫЕ ФОРМУЛИРОВКИ МОГУТ УКАЗЫВАТЬ НА НЕГАТИВНУЮ ОКРАСКУ, ОБРЕМЕНЕНИЯ ИЛИ ПОТЕНЦИАЛЬНЫЕ РИСКИ ДЛЯ СТОРОН.

### РАЗДЕЛЕНИЕ ЗАДАЧ НА ПОДЭТАПЫ ###
1. Обработка входных данных:
  - Реализовать функции для чтения и парсинга текстовых файлов .txt и документов .docx.
  - Разделить текст на секции или пункты с использованием регулярных выражений и шаблонов (Раздел X, Пункт X.X).

4. Форматирование и сохранение результатов:
  - Представить анализ в структурированном формате (.json, .txt, .docx).
  - Включить в итоговый файл: исходный текст, обоснование анализа, предложенную альтернативу.

5. Интерактивные возможности:
  - Добавить возможность редактирования анализа и альтернативных формулировок вручную.
  - Реализовать повторный анализ после изменений.

### ПРИМЕР ВВОДА И ВЫВОДА ###
Выходной текст:
6.1. В случае нарушения сроков поставки товара, Поставщик уплачивает Покупателю пеню в размере 0,1 % от стоимости недопоставленного товара, за каждый день просрочки.

КОММЕНТАРИЙ:
Найден риск. Категории: Ответственность, Угрозы рисков.
Рекомендации: Определите верхний предел пени, чтобы избежать чрезмерных штрафов. Укажите исключения для форс-мажорных обстоятельств.

6.3. О готовности товара Покупателю сообщается соответствующим письмом по электронной почте.

КОММЕНТАРИЙ:
Найден риск. Категории: Ответственность.
Рекомендации: Добавьте пункт о разумном сроке для отгрузки после получения уведомления. Рассмотрите возможность корректировки платы за хранение.

КРИТЕРИИ ОЦЕНКИ КАЧЕСТВА
1. Точность:
• Классификация тональности должна учитывать расширенный список лексических единиц.
2. Читаемость:
• Итоговый отчёт должен быть структурированным и легко читаемым.
3. Юридическая консистентность:
• Переписанные формулировки не должны изменять смысл оригинального текста.
4. Производительность:
• Обработка больших документов (50+ пунктов) должна занимать не более 1 минуты на стандартном ноутбуке.

ИСПОЛЬЗОВАНИЕ БИБЛИОТЕК
• transformers: Переписывание текста и сложный анализ тональности.
• python-docx: Чтение и запись файлов Word.
• pandas, json: Форматирование и сохранение результатов.

ВОЗМОЖНЫЕ ПРОБЛЕМЫ И РЕШЕНИЯ
1. Обработка больших файлов:
• Использовать пошаговую обработку секций для минимизации использования памяти.
2. Неоднозначная классификация:
• Использовать расширенный словарь лексических единиц для повышения точности.
3. Ограничения языковых моделей:
• Использовать предварительно настроенные модели или адаптировать их вывод вручную.

Промпт для обучения модели

ТЫ — ВЫСОКОКЛАССНЫЙ ЭКСПЕРТ В ОБЛАСТИ ДОГОВОРНОГО ПРАВА, СПЕЦИАЛИЗИРУЮЩИЙСЯ НА АНАЛИЗЕ ДОГОВОРОВ ПОСТАВКИ И СУДЕБНОЙ ПРАКТИКЕ В РОССИИ. ТВОЯ ЗАДАЧА — СОСТАВИТЬ МАКСИМАЛЬНО ВОЗМОЖНОЕ КОЛИЧЕСТВО ПРИМЕРОВ ПУНКТОВ ДОГОВОРОВ ПОСТАВКИ, СОДЕРЖАЩИХ РИСКИ ДЛЯ СТОРОН, ПО КОТОРЫМ ЧАЩЕ ВСЕГО ВОЗНИКАЮТ СПОРЫ В РОССИЙСКОМ ЗАКОНОДАТЕЛЬСТВЕ И СУДЕБНОЙ ПРАКТИКЕ.

###ИНСТРУКЦИИ###
1. СОСТАВЬ ПРИМЕРЫ ПУНКТОВ ДОГОВОРА ПОСТАВКИ, КОТОРЫЕ СОДЕРЖАТ РИСКИ ДЛЯ СТОРОН (ПОСТАВЩИКА ИЛИ ПОКУПАТЕЛЯ).  
2. ОПИШИ КАЖДЫЙ ПУНКТ И ПОЯСНИ, ПОЧЕМУ ОН МОЖЕТ ПРИВЕСТИ К СПОРАМ, ОСНОВЫВАЯСЬ НА РОССИЙСКОМ ЗАКОНОДАТЕЛЬСТВЕ И СУДЕБНОЙ ПРАКТИКЕ.
3. ВКЛЮЧАЙ ТОЛЬКО ТЕ ПРИМЕРЫ, КОТОРЫЕ НАИБОЛЕЕ ЧАСТО СТАНОВЯТСЯ ПРЕДМЕТОМ ЮРИДИЧЕСКИХ РАЗНОГЛАСИЙ.
4. ПОКРЫВАЙ ОСНОВНЫЕ ОБЛАСТИ СПОРОВ:  
  - НАРУШЕНИЕ СРОКОВ ПОСТАВКИ.  
  - НЕСООТВЕТСТВИЕ КАЧЕСТВА ТОВАРА.  
  - НЕУТОЧНЁННЫЕ УСЛОВИЯ ОПЛАТЫ.  
  - ОТВЕТСТВЕННОСТЬ ЗА УЩЕРБ, ПРИЧИНЁННЫЙ ТОВАРУ.  
  - ПРОЦЕДУРА ВОЗВРАТА ИЛИ ЗАМЕНЫ ТОВАРА.  
  - ПЕРЕХОД РИСКОВ С ПОСТАВЩИКА НА ПОКУПАТЕЛЯ.  
5. СОХРАНИ СТРУКТУРУ:  
  - "Пункт: ..."
  - "Риск: ...".

###ШАБЛОН ПРИМЕРА###
Пример 1:  
Пункт: "Поставщик обязуется доставить товар в течение 30 дней с момента подписания договора."  
Риск: Отсутствие чётких санкций за нарушение срока поставки создаёт риски для покупателя, особенно при наступлении убытков, связанных с задержкой.

Пример 2:  
Пункт: "Покупатель обязан уведомить поставщика о ненадлежащем качестве товара в течение 2 дней после получения."  
Риск: Слишком короткий срок уведомления может привести к невозможности доказать наличие дефектов, что создаёт риск для покупателя в спорах о качестве товара.

Пример 3:  
Пункт: "Оплата производится в течение 90 дней после получения товара."  
Риск: Продолжительный срок оплаты создаёт финансовые риски для поставщика, увеличивая вероятность просрочек и возникновения споров о задолженности.

Пример 4:  
Пункт: "Ответственность за повреждение товара во время транспортировки несёт покупатель."  
Риск: Не уточнён момент перехода рисков с поставщика на покупателя, что может привести к разногласиям в случае утраты или повреждения товара.

Пример 5:  
Пункт: "В случае форс-мажорных обстоятельств стороны освобождаются от ответственности."  
Риск: Отсутствие чёткого перечня обстоятельств форс-мажора позволяет сторонам злоупотреблять этим пунктом, что приводит к затяжным судебным разбирательствам.

Пример 6:  
Пункт: "Гарантийный срок на товар составляет 12 месяцев."  
Риск: Отсутствие условий, описывающих процедуру возврата или ремонта товара в случае обнаружения дефектов, создаёт неопределённость для покупателя и может стать причиной споров.

###ЗАДАНИЕ###
1. СОЗДАЙ МАКСИМАЛЬНО ВОЗМОЖНОЕ КОЛИЧЕСТВО ПРИМЕРОВ ПУНКТОВ ДОГОВОРА ПОСТАВКИ, КОТОРЫЕ ЧАСТО СТАНОВЯТСЯ ПРЕДМЕТОМ СПОРОВ В РОССИЙСКОМ ЗАКОНОДАТЕЛЬСТВЕ.  
2. ДЛЯ КАЖДОГО ПРИМЕРА ОПИШИ РИСК, УЧИТЫВАЯ СУДЕБНУЮ ПРАКТИКУ И ОСНОВНЫЕ ЮРИДИЧЕСКИЕ ПРОБЛЕМЫ, СВЯЗАННЫЕ С ЭТИМИ ПУНКТАМИ.  

###ТРЕБОВАНИЯ К ПРИМЕРАМ###
- ПРИМЕРЫ ДОЛЖНЫ ОТРАЖАТЬ РЕАЛЬНЫЕ СИТУАЦИИ И ПРОБЛЕМЫ, ЧАСТО ВСТРЕЧАЮЩИЕСЯ В СУДЕБНОЙ ПРАКТИКЕ РОССИИ.  
- ОПИСАНИЯ РИСКОВ ДОЛЖНЫ БЫТЬ ЧЁТКИМИ И КОНКРЕТНЫМИ.  
- ПОКРЫВАЙТЕ НАИБОЛЕЕ АКТУАЛЬНЫЕ АСПЕКТЫ РОССИЙСКОГО ДОГОВОРНОГО ПРАВА.  

Итоги работы над проектом

Общий процесс работы

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

Что использовалось в проекте

1. Модели и технологии:

• Natasha и razdel: Для лингвистического анализа, лемматизации и разбиения текста на предложения.

• ruT5 (версии base и large): Для генерации текстовых рекомендаций.

• ruGPT-3 (версии small, medium, large): Для экспериментов с генерацией рекомендаций.

• Torch: Для обработки моделей на локальном устройстве (с поддержкой MPS на MacBook Air).

• docx: Для работы с юридическими текстами и добавления комментариев.

• datasets: Для подготовки данных к обучению.

• Fine-tune данных: JSON-файл fine_tune_data.json с размеченными примерами рисков и рекомендаций.

2. Инструменты для разработки:

• Python с использованием популярных библиотек (transformers, torch, docx).

• MacBook M1 для локального выполнения кода и тестирования.

• Hugging Face Models, включая их загрузку и интеграцию.

Успешно использованные элементы

1. Интеграция Natasha и razdel:

   • Успешно использовались для обработки текста договоров, лемматизации и разбиения на предложения.

   • Позволило выделить ключевые слова и фразы для анализа.

2. Базовый анализ рисков:

   • Предопределённый список ключевых слов (negative_keywords.json) позволил выявлять категории рисков в тексте договоров.

3. Генерация рекомендаций с ruT5:

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

4. Fine-tuning модели:

   • Успешно разработан скрипт для дообучения моделей, включая оптимизацию под ресурсы MacBook M1 (MPS).

   • Fine-tuning был выполнен на ограниченном наборе данных из fine_tune_data.json.

5. Оптимизация генерации рекомендаций:

   • Добавлен таймер для предотвращения зависаний модели.

   • Настроены параметры генерации, такие как repetition_penalty и temperature, для улучшения качества ответов.

Что оказалось неуспешным

1. Генерация рекомендаций:

   • Ответы моделей часто были слишком общими или некорректными. Например:

     • "Риск отсутствует" или "Напиши договор правильно."

   • Fine-tuning дал лишь частичное улучшение из-за небольшого объёма данных.

2. Использование мощных моделей (YaLM, ruGPT-3.5):

   • Эти модели не могли быть использованы на локальной машине из-за ограничений памяти и требований к GPU.

3. Работа с длинными текстами:

   • Модели не могли корректно обрабатывать длинные договорные секции из-за ограничения длины токенов (max_length).

4. Повторяющиеся рекомендации:

   • Модель генерировала однотипные ответы для разных секций, что не соответствовало задаче.

5. Ошибки токенизации:

   • Некорректная работа некоторых моделей с токенизаторами привела к необходимости их замены.

Исключённые варианты

1. Модели с большими требованиями к ресурсам:

   • YaLM 100B, ruGPT-3.5 large и их аналоги были исключены из-за невозможности их запуска на локальной машине.

   • Использование таких моделей возможно только в облачных средах.

2. Низкоуровневые модели:

   • sBERT и другие классификаторы были исключены, так как они не предназначены для генерации текста.

3. Неэффективные инструменты для обработки текстов:

   • Некоторые решения для обработки .docx были исключены из-за ограниченной гибкости при работе с комментариями.

Основные ошибки и проблемы

1. Нехватка ресурсов для запуска моделей:

   • Ограниченные ресурсы MacBook M1 не позволяли запускать крупные модели и проводить их дообучение на больших данных.

2. Зависания при генерации рекомендаций:

   • Проблемы с производительностью моделей при обработке сложных текстов. Решено введением таймера и уменьшением параметров модели.

3. Малый объём данных для обучения:

   • Для качественного fine-tuning требуются тысячи размеченных примеров, что недоступно в текущем проекте.

4. Проблемы с интерпретацией результатов моделей:

   • Даже после обучения, модели часто давали слишком общие или неконкретные рекомендации.

Заключение

Что было сделано успешно:

1. Интеграция ruT5 и ruGPT-3 для анализа договоров.

2. Успешное дообучение модели на малом объёме данных.

3. Оптимизация работы моделей на MacBook M1.

Что не удалось:

1. Достичь высокой точности в генерации рекомендаций из-за малого объёма данных.

2. Обеспечить полноценную работу с длинными текстами.

Что можно сделать дальше:

1. Увеличить объём данных для обучения.

2. Использовать облачные сервисы для запуска и fine-tuning более мощных моделей.

3. Рассмотреть альтернативные модели (например, LLaMA или Falcon) для локальной работы.

Личный итог

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

Для определения "юридической негативности" была внедрена система «индекса негативности». Для каждого предложения вычислялось, в скольких категориях оно участвовало и с какими словами произошло совпадение. При обнаружении в тексте категории «Ответственность» можно условно добавлять +0.3, «Угрозы рисков» – +0.4 и т.д. В результате по каждой фразе (предложению) получается числовое значение, например:

• «Обязанности» = +0.2

• «Ответственность» = +0.4

• «Угрозы рисков» = +0.3

• «Ограничения» = +0.3

• «Конфликты» = +0.2

Сложив баллы, при превышении порога (например, 0.5) считаем, что формулировка «юридически негативна». (Баллы выставлены условно, и необходимо тестирование для более четкой настройки.)

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

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

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

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

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

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

Планы на дальнейшую работу с учетом опыта

1. Выбор моделей:

   • Использовать более современные модели, такие как Nemo, Deepseek 14b и ниже, Mistral, Qwen, так как они лучше подходят для задач и железа.

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

2. Постановка задачи:

   • Задача выявления рисков в договорах слишком широкая и сложная для одного человека или небольшой команды.

   • Сузить задачу до конкретной области (например, только аренда) и постепенно расширять функционал.

   • Важность четкого определения, что такое "риски" и как их анализировать.

3. Структура кода и подход к разработке:

   • Разделять код на модули и функции, чтобы упростить понимание и отладку.

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

   • Понимать, как работает программа на каждом этапе, чтобы избежать "круговых ошибок".

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

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

Канал автора: @AI_Skrepka ^[1]