Как автоматизировать работу с юридическими документами с помощью open-source LLM: кейс Рег.облака и Raft

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

В конце 2025 года Рег.облако совместно с командой Raft провели прикладной эксперимент: решили проверить, можно ли построить автономный контур извлечения данных из юридических документов на базе open-source LLM — без внешних API, с управляемым качеством и предсказуемой инфраструктурной экономикой.

Всё актуальное — в наших соцсетях. Подписывайтесь!

Телеграм ВКонтакте

Эксперимент стал частью discovery-фазы продуктового направления Raft и одновременно способом протестировать GPU-инфраструктуру Рег.облака на реальных бизнес-сценариях.

О клиенте

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

До эксперимента юридическая функция опиралась на классические инструменты рынка — прежде всего API крупных правовых систем. Такой подход имел несколько ограничений:

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

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

Вызовы и задачи

Перед командами стояли несколько ключевых задач:

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

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

Решение

Эксперимент запускался в публичном облаке на инфраструктуре Рег.облака — Cloud GPU A100 (80 ГБ). При этом архитектура изначально проектировалась так, чтобы при необходимости ее можно было развернуть в закрытом корпоративном контуре заказчика.

Подход к архитектуре

Команда Raft рассматривала решение не как выбор «лучшей модели», а как построение управляемого пайплайна:

1. загрузка и извлечение текста из документа;
2. классификация типа документа;
3. выбор стратегии обработки;
4. LLM-экстракция;
5. постобработка, дедупликация и валидация данных.

Такой подход позволял контролировать качество на каждом этапе и снижать риск ложных данных.

Почему выбор модели оказался не главным

В ходе эксперимента тестировались разные классы open-source LLM.

Легковесные модели с квантизацией показали низкие требования к ресурсам, но при работе с юридическими документами регулярно пропускали критичные поля или возвращали некорректные значения — например, ИНН или суммы, которых не было в договоре. 

Полноразмерные модели обеспечивали более высокое качество, но требовали нескольких GPU с большим объемом памяти, что делало их инфраструктурно и экономически нецелесообразными.

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

Оптимальным компромиссом стали instruct-модели класса Mixture of Experts (MoE). В эксперименте использовалась модель, которая:

• полностью помещалась на одну GPU A100;
• оставляла 30–40% вычислительного буфера для масштабирования;
• обеспечивала высокую точность извлечения;
• укладывалась в требования по пользовательской задержке.

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

Инженерные решения, которые дали рост качества

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

• Разделение обработки по типам документов
  Решение: для договоров, актов, счетов-фактур и допсоглашений использовались разные наборы полей и сценарии извлечения.
  Пример: при общей логике модель пыталась искать условия оплаты в актах или приложения в счетах-фактурах. После разделения пайплайна такие ошибки перестали возникать.
  
• Строгий формат ответа вместо свободной генерации
  Решение: модель должна была возвращать данные строго в заданной структуре без комментариев и пояснений.
  Пример: если в ответе появлялся текст вроде «Скорее всего, сумма договора составляет…», такой результат автоматически отклонялся и не попадал в бизнес-системы.
  
• Контроль длины контекста для каждого поля
  Решение: в модель передавались только те фрагменты документа, которые потенциально содержат нужные реквизиты.
  Пример: при обработке длинных договоров это снизило случаи, когда сумма из приложения подменяла основную сумму договора или реквизиты брались из нерелевантного раздела.
  
• Адаптивный чанкинг длинных документов
  Решение: документы разбивались не на равные части, а на смысловые блоки разного размера.
  Пример: в дополнительных соглашениях ключевые изменения часто находятся в одном абзаце — адаптивное разбиение позволяло корректно извлекать данные именно из этого блока, не «размывая» контекст.
  
• Постобработка и дедупликация данных
  Решение: результаты извлечения проходили дополнительную проверку и очистку.
  Пример: если модель возвращала два разных значения одного и того же реквизита (например, счета или даты), система выявляла дубликаты и исключала конфликтующие данные до загрузки в ERP и DWH.

В результате LLM стала частью управляемой системы.

Контроль ошибок и снижение рисков

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

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

• проверку типов;
• валидацию форматов;
• бизнес-проверки на дубли и логические противоречия.

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

Результаты

После нескольких итераций настройки пайплайна удалось получить следующие показатели:

• Precision — 99,7% в тестовом сете из документов заказчика;
• Recall — 93,1%;
• F1-score — 95,9%;
• Overall Score — 0,96.

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

Почему выбрали Рег.облако

Рег.облако предоставило инфраструктуру, которая позволила провести эксперимент в условиях, близких к реальному внедрению:

• GPU A100 с достаточным запасом по мощности;
• возможность тестировать автономный контур без внешних API;
• высокую пропускную способность сети, критичную для стабильной работы моделей;
• предсказуемую экономику масштабирования.
  

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

Выводы

Эксперимент показал, что open-source LLM уже можно использовать для промышленной работы с юридическими документами — при условии, что модель встроена в управляемый инженерный контур.

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

Комментарий эксперта