- PVSM.RU - https://www.pvsm.ru -
У меня, как у практикующего юриста в консалтинге и человека, горящего желанием научиться новым навыкам, появилась идея (которая в ходе реализации изменила свой вид) создать программу для анализа эмоций и тональности документов.
В программировании имею небольшой опыт обучения основам C#, а с недавнего времени — изучение основ Python.
Я начну с самого начала, чтобы те, кто еще не пробовал кодить, могли понять, с чем придется столкнуться и чего бояться не стоит.
На вооружение был взят ChatGPT (Plus)/DeepSeek и VS Code для написания кода.
Пользователь загружает договор в формате текстового документа, а программа отображает пункты в договоре, которые соответствуют определенному тону (позитивный, негативный, нейтральный), дополнительно предлагая альтернативу.
Хотелось сразу ворваться в мир веб-приложений, поэтому GPT нагрузил меня всем, чем только можно.
Мы начали с написания кода для анализа тональности текста с помощью DeepPavlov. Я использовал готовую модель для классификации текста по трем категориям: позитивный, нейтральный, негативный. (Еще не понимал своей ошибки)
Создали веб-приложение на Flask, где пользователи могут вводить текст и получать результат анализа.
После первых нескольких часов, пока я разбирался в работе с терминалом, установкой множества библиотек и т.д., я столкнулся с проблемой, с которой даже не предполагал встретиться, так как был наивно уверен в точности и достоверности ответов GPT, а именно: написание кода с устаревшими или уже не существующими библиотеками.
По моему мнению, написание программы должно было выглядеть «Ctrl+C/V из чата GPT», а не наоборот. Следующие несколько часов я упорно пытался решить проблемы новых ошибок в терминале, которые росли как снежный ком, хотя я выполнял все в точности, что мне советовала нейросеть.
После регистрации на OpenAI и внедрения API-ключа в код начались безуспешные попытки запустить программу. GPT каждый раз предлагал новые решения, однако ошибки повторялись по кругу. На этот момент я понял, что все же придется самостоятельно искать проблему и скармливать ему различную информацию из документации и других открытых источников.
Я смог запустить программу и даже получил адекватный результат:
Пункт договора: При нарушении срока поставки Поставщик обязуется оплатить пени в размере 1% от стоимости непоставленной продукции за каждый день.
Результат анализа:
Тональность текста: Негативный (Уверенность: 1.0)
Замечания: Формулировка может быть уточнена. Добавьте расчёт на основе конкретных документов.
Улучшенная формулировка:
При нарушении срока поставки Поставщик обязуется уплатить пеню в размере 1% от стоимости непоставленной продукции за каждый день просрочки, начиная с первого дня просрочки и до момента фактической поставки.
После нескольких попыток тестирования программа начала виснуть и выдавать ошибку с информацией о превышении лимитов токенов в API.
По итогу я понял, что необходимо искать более локальные решения для возможности использования, менее зависимо от лимитов.
Было решено подойти к проекту более серьёзно, составив базовый промпт (использовал System Prompt Generator).
Но для того чтобы составить базовый промпт, необходимо было сформировать детали, которые я хотел бы в нём увидеть. Поэтому сначала надо было создать промпт для промпта.
Я понимал, что для «эмоционального окраса каждого пункта договора» мне необходимо:
Обозначить «критерии оценки качества»
Указать примеры входа и выхода информации
Я выделил следующие разделы критериев оценки по категориям:
Обязанности
Ответственность
Угрозы рисков
Ограничения
Конфликты
Указал, что каждая категория содержит множество примеров. Все приведённые варианты — это возможные формулировки, которые в юридической практике могут указывать на негативную окраску, обременения или потенциальные риски для сторон.
По результату был создан промпт для составления списка фраз и словосочетаний, часто встречающихся в юридических документах с негативным окрасом.
После запуска промпта я получил 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 для улучшения результатов.
Natasha и razdel: Для лингвистического анализа, лемматизации и разбиения текста на предложения.
ruT5 (версии base и large): Для генерации текстовых рекомендаций.
ruGPT-3 (версии small, medium, large): Для экспериментов с генерацией рекомендаций.
Torch: Для обработки моделей на локальном устройстве (с поддержкой MPS на MacBook Air).
docx: Для работы с юридическими текстами и добавления комментариев.
datasets: Для подготовки данных к обучению.
Fine-tune данных: JSON-файл fine_tune_data.json с размеченными примерами рисков и рекомендаций.
Python с использованием популярных библиотек (transformers, torch, docx).
MacBook M1 для локального выполнения кода и тестирования.
Hugging Face Models, включая их загрузку и интеграцию.
Интеграция Natasha и razdel:
Успешно использовались для обработки текста договоров, лемматизации и разбиения на предложения.
Позволило выделить ключевые слова и фразы для анализа.
Базовый анализ рисков:
Предопределённый список ключевых слов (negative_keywords.json) позволил выявлять категории рисков в тексте договоров.
Генерация рекомендаций с ruT5:
Модель ruT5 успешно применялась для генерации рекомендаций, хотя на первых этапах возникали проблемы с зависаниями при сложных текстах.
Fine-tuning модели:
Успешно разработан скрипт для дообучения моделей, включая оптимизацию под ресурсы MacBook M1 (MPS).
Fine-tuning был выполнен на ограниченном наборе данных из fine_tune_data.json.
Оптимизация генерации рекомендаций:
Добавлен таймер для предотвращения зависаний модели.
Настроены параметры генерации, такие как repetition_penalty и temperature, для улучшения качества ответов.
Генерация рекомендаций:
Ответы моделей часто были слишком общими или некорректными. Например:
"Риск отсутствует" или "Напиши договор правильно."
Fine-tuning дал лишь частичное улучшение из-за небольшого объёма данных.
Использование мощных моделей (YaLM, ruGPT-3.5):
Эти модели не могли быть использованы на локальной машине из-за ограничений памяти и требований к GPU.
Работа с длинными текстами:
Модели не могли корректно обрабатывать длинные договорные секции из-за ограничения длины токенов (max_length).
Повторяющиеся рекомендации:
Модель генерировала однотипные ответы для разных секций, что не соответствовало задаче.
Ошибки токенизации:
Некорректная работа некоторых моделей с токенизаторами привела к необходимости их замены.
Модели с большими требованиями к ресурсам:
YaLM 100B, ruGPT-3.5 large и их аналоги были исключены из-за невозможности их запуска на локальной машине.
Использование таких моделей возможно только в облачных средах.
Низкоуровневые модели:
sBERT и другие классификаторы были исключены, так как они не предназначены для генерации текста.
Неэффективные инструменты для обработки текстов:
Некоторые решения для обработки .docx были исключены из-за ограниченной гибкости при работе с комментариями.
Нехватка ресурсов для запуска моделей:
Ограниченные ресурсы MacBook M1 не позволяли запускать крупные модели и проводить их дообучение на больших данных.
Зависания при генерации рекомендаций:
Проблемы с производительностью моделей при обработке сложных текстов. Решено введением таймера и уменьшением параметров модели.
Малый объём данных для обучения:
Для качественного fine-tuning требуются тысячи размеченных примеров, что недоступно в текущем проекте.
Проблемы с интерпретацией результатов моделей:
Даже после обучения, модели часто давали слишком общие или неконкретные рекомендации.
Интеграция ruT5 и ruGPT-3 для анализа договоров.
Успешное дообучение модели на малом объёме данных.
Оптимизация работы моделей на MacBook M1.
Достичь высокой точности в генерации рекомендаций из-за малого объёма данных.
Обеспечить полноценную работу с длинными текстами.
Увеличить объём данных для обучения.
Использовать облачные сервисы для запуска и fine-tuning более мощных моделей.
Рассмотреть альтернативные модели (например, LLaMA или Falcon) для локальной работы.
Изначально необходимо было учитывать не «эмоциональную тональность», а «юридическую негативность», что реализовалось значительно позднее.
Для определения "юридической негативности" была внедрена система «индекса негативности». Для каждого предложения вычислялось, в скольких категориях оно участвовало и с какими словами произошло совпадение. При обнаружении в тексте категории «Ответственность» можно условно добавлять +0.3, «Угрозы рисков» – +0.4 и т.д. В результате по каждой фразе (предложению) получается числовое значение, например:
«Обязанности» = +0.2
«Ответственность» = +0.4
«Угрозы рисков» = +0.3
«Ограничения» = +0.3
«Конфликты» = +0.2
Сложив баллы, при превышении порога (например, 0.5) считаем, что формулировка «юридически негативна». (Баллы выставлены условно, и необходимо тестирование для более четкой настройки.)
После возврата информации в программу, если формулировка «юридически негативна», программа должна была указать риски к пункту. На данный момент мне не удалось достичь необходимого результата в связи с тем, что я не смог настроить языковые модели работать «из коробки» с юридическими документами. Языковые модели требуется обучать на большом объёме данных, которые должны быть проанализированы самостоятельно.
Обучение языковой модели, которое я запускал, не дало должного результата в тестовом режиме. Также после обучения необходимо много тестировать модель с изменением данных кода: настраивать температуру, токены, штрафы за повторы и т.д.
Для юридических примеров GPT предлагает много воды с галлюцинациями, даже с качественным промптом. Каждый вариант требует оценки с юридической точки зрения для последующего запуска в обучение языковой модели.
Одна из главных проблем для меня, как для человека, который пишет код только через чат, — это произвольное переписывание GPT рабочих элементов кода и, как следствие, появление новых ошибок. Пока решаешь эти ошибки, чат опять переписывает код и так по кругу.
За всё время работы над новыми вариантами запуска программы код менялся множество раз. Из-за ограниченного доступа GPT к актуальным данным, не всегда представлялось возможным запросить актуальные языковые модели, которые подходили бы под конкретную ситуацию. Необходимо было разбираться в документации на Hugging Face самостоятельно, скармливать эту информацию в чат для дальнейших рекомендаций.
В любом случае ChatGPT пишет детальный код с комментариями и пояснениями, разобраться в котором не составит большого труда, если вы собрались заняться написанием кода.
Выбор моделей:
Использовать более современные модели, такие как Nemo, Deepseek 14b и ниже, Mistral, Qwen, так как они лучше подходят для задач и железа.
Старые версии библиотек, используемые GPT, могут вызывать проблемы, и нужно вручную проверять документацию.
Постановка задачи:
Задача выявления рисков в договорах слишком широкая и сложная для одного человека или небольшой команды.
Сузить задачу до конкретной области (например, только аренда) и постепенно расширять функционал.
Важность четкого определения, что такое "риски" и как их анализировать.
Структура кода и подход к разработке:
Разделять код на модули и функции, чтобы упростить понимание и отладку.
Сначала выстроить логику работы программы, а затем уже писать код.
Понимать, как работает программа на каждом этапе, чтобы избежать "круговых ошибок".
Начать с малого, собрать базу данных рисков и лучших практик, а затем постепенно добавлять функционал.
Описанное выше - это лишь часть проделанной работы юристом, который пытается разобраться в программировании с помощью нейросетей. Если будут более детальные вопросы, готов ответить.
Канал автора: @AI_Skrepka [1]
Автор: Mersh
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/avtomatizatsiya/413603
Ссылки в тексте:
[1] @AI_Skrepka: https://t.me/+3J8494TbnUExYzgy
[2] Источник: https://habr.com/ru/articles/890886/?utm_source=habrahabr&utm_medium=rss&utm_campaign=890886
Нажмите здесь для печати.