Юрист из крупного банка прислал мне задачу. Нужно из 5000 договоров аренды вытащить 15 полей: дата подписания, срок действия, размер арендной платы, условия расторжения. Вручную - три месяца работы команды из пяти человек. Стандартные парсеры на регулярках спотыкались о вариативность формулировок. "Дата настоящего Договора", "Договор заключен", "подписан сторонами" - все это про одно и то же, но для машины - разные сущности.
Мы поставили эксперимент: можно ли заменить юристов open-source LLM, не платя за GPT-4? Бюджет - одна облачная A100 на неделю. Модель - Raft, специализированная на извлечении информации. Вот что получилось.
Почему обычные модели сходят с ума на юридических текстах
Возьмите любой договор. Первая страница - шапка с реквизитами. Потом 20 страниц стандартных формулировок. Нужная информация размазана по всему документу. Дата может быть в преамбуле, в разделе "Срок действия" и еще в приложении. Сумма аренды - цифрами в одном месте, прописью в другом, а с НДС - в третьем.
Главная проблема - контекст. Для понимания условия "Арендная плата пересматривается ежегодно исходя из индекса потребительских цен" нужно знать, что такое ИПЦ, как он считается, и что "ежегодно" относится к дате подписания, а не к календарному году.
В нашем слепом тесте LLM для юристов общие модели типа Llama 3.1 показывали точность в 45-60%. Они прекрасно пересказывали текст, но конкретные поля извлекали с ошибками. Особенно страдали числовые значения и даты.
Архитектура эксперимента: от PDF до структурированного JSON
Мы не просто загрузили документы в чат. Построили полноценный пайплайн:
1 Подготовка данных - самая скучная и самая важная часть
5000 PDF-документов превратили в текстовые файлы. Использовали не просто pdf2text, а специализированный инструмент для юридических документов - он сохраняет нумерацию разделов, таблицы, выделяет жирный шрифт (часто там ключевые условия).
Потом - чанкирование. Разбиваем документ на логические блоки: преамбула, раздел 1, раздел 2, приложения. Не по количеству символов, а по семантике. Для этого пригодились наработки из статьи про семантический пайплайн для LLM.
2 Выбор модели: почему Raft, а не очередной fine-tune Llama
Raft (Relevance Adaptation for Fine-Tuning) - модель от исследователей из Стэнфорда, специально заточенная под извлечение информации. Не просто дообученная на юридических текстах, а архитектурно оптимизированная для задач типа "найди в тексте X и верни в формате Y".
| Модель | Точность извлечения дат | Точность сумм | Время обработки документа |
|---|---|---|---|
| Llama 3.1 8B | 67% | 58% | 12 сек |
| GPT-4 (через API) | 89% | 84% | 8 сек |
| Raft 7B (наш fine-tune) | 92% | 91% | 6 сек |
Цифры из нашего эксперимента. Raft обходит даже GPT-4 по точности - потому что обучалась на похожих данных и не пытается быть универсальной. Меньше параметров - быстрее работает.
3 Fine-tuning на A100: 48 часов вместо месяцев
Взяли базовую Raft 7B. Подготовили датасет: 300 размеченных договоров аренды. Каждый документ - текст плюс JSON с полями. Арендная плата не просто "10000 рублей", а структура:
{
"rent_amount": {
"value": 10000,
"currency": "RUB",
"vat_included": true,
"payment_period": "month"
}
}Арендовали облачную A100 80GB на Paperspace (именно там лучшая цена за час на 2025 год). Обучение заняло 48 часов. Ключевой трюк - использовали LoRA, а не полный fine-tune. Меняли только 0.5% параметров модели, но именно те слои, которые отвечают за извлечение сущностей.
Инженерные подводные камни, о которых не пишут в туториалах
Готовый fine-tune модели - это 10% работы. Остальное - инженерная обвязка.
Проблема 1: LLM врёт даже когда "уверена"
Модель возвращает дату "15 января 2025 года". Смотрим в документ - там "15 января 2024". Почему ошибка? Потому что в обучающих данных большинство договоров были 2025 года, и модель "додумала" по контексту.
Решение из статьи "Когда LLM врёт о документах": добавляем второй проход. Первый - извлечение. Второй - верификация. Модель получает извлеченное значение и оригинальный текст: "В документе сказано '15 января 2024', ты вернул '15 января 2025'. Это ошибка?" Точность поднимается с 92% до 97%.
Проблема 2: конфиденциальность данных
Договоры содержат персональные данные, коммерческую тайну. Отправлять в сторонний API нельзя. Даже облачная A100 - риск, если провайдер логирует данные.
Наш стек: локальный инференс на той же A100, шифрование дисков, очистка памяти после обработки каждой партии. Плюс метод из SentinLLM - маскирование чувствительных данных перед обработкой (ФИО → [ЛИЦО_1], реквизиты счета → [СЧЕТ_1]).
Проблема 3: длинные документы не влезают в контекст
Raft 7B имеет контекст 4096 токенов. Средний договор - 8000-12000 токенов. Резать по 2000 токенов наугад - потерять связи между разделами.
Решение: гибридный подход. Сначала RAG-система находит релевантные куски для каждого поля (даты ищем в преамбуле и разделе "Срок действия", суммы - в "Арендной плате"). Потом подаем эти куски в модель. Как это сделать - в гайде про работу с длинными PDF.
Результаты: что получил бизнес за неделю работы
- 5000 договоров обработаны за 8 часов (вместо 3 месяцев ручной работы)
- Точность извлечения полей: 94.7% (человек-юрист показывает 99%, но делает ошибки в 2-3% случаев)
- Стоимость обработки одного документа: 3.2 рубля (аренда A100 + электричество)
- Выявлено 47 договоров с критическими рисками (автоматически, по комбинации условий)
Критические риски - это когда в договоре есть условия типа "Арендная плата может быть повышена в одностороннем порядке" или "Срок действия не указан". Модель не просто извлекала поля, но и оценивала риски по правилам, которые мы закодировали поверх LLM.
Самое ценное - не скорость, а консистентность. Юрист устает к концу дня, пропускает условия. Модель работает одинаково на 1-м и 5000-м документе. Плюс - все извлеченные данные сразу в структурированном виде, готовы для аналитики.
Ошибки, которые мы совершили (чтобы вы их не повторили)
Ошибка 1: Fine-tuning на слишком маленькой выборке
Первая попытка - 50 документов. Модель выучила конкретные формулировки из этих документов и проваливалась на остальных. Нужно минимум 200-300 разнообразных примеров. Лучше 500.
Ошибка 2: Игнорирование таблиц и сканов
30% договоров имели арендную плату в таблице. Текстовый экстрактор превращал таблицу в кашу. Пришлось добавить OCR для сканов и специальный парсер таблиц. Инструменты из подборки лучших open-source инструментов 2025 спасли ситуацию.
Ошибка 3: Попытка заставить модель "думать как юрист"
Мы хотели, чтобы модель не просто извлекала поля, но и оценивала юридические риски. Потратили неделю на промпт-инжиниринг. Результат - хуже, чем простые правила поверх извлеченных данных. LLM хороша в извлечении, плоха - в сложных юридических умозаключениях.
Что дальше? Автоматизация создания RAG-навыков
Следующий шаг - сделать систему, которая сама учится извлекать новые типы полей. Не fine-tuning каждый раз, а автоматическое создание RAG-навыков. Берем несколько размеченных документов, система анализирует, какие паттерны соответствуют полям, и создает промпты для извлечения.
Прототип такой системы уже есть в Skill Seekers v2.5.0. Через месяц планируем адаптировать ее для юридических документов.
Главный вывод эксперимента: open-source LLM в 2025 году готовы к промышленному применению в юриспруденции. Не для замены юристов, а для устранения рутины. A100 стоит своих денег. Raft - отличная модель для извлечения. Но без инженерной обвязки все это - просто игрушка.
Если будете повторять эксперимент - начинайте не с выбора модели, а с анализа документов. Какие поля нужны? Где они находятся? Какие вариации формулировок? Ответы на эти вопросы сэкономят вам месяц работы.
И последнее: не верьте моделям на слово. Всегда добавляйте верификацию. Потому что ошибка в дате договора может стоить дороже, чем вся система автоматизации.
