Open-source LLM против юридических документов: эксперимент Рег.облака и Raft

Рег.облако выделил грант команде Raft на использование облачных серверов с GPU A100 80 ГБ. Задача была практической: понять, как современные open-source модели работают с длинными контекстами и объемными юридическими текстами, и можно ли использовать их для извлечения бизнес-критичных данных.

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

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

С какой задачей мы работали

Юридические документы — одна из наиболее сложных зон цифровизации. Данные в них не всегда систематизированы, структура у каждого документа разная, а цена ошибки высока: неверный ИНН, счет или сумма — это вполне реальный финансовый и комплаенс-риск.

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

Здесь важно уточнить, что нас не интересовал поиск текста или подсветка фрагментов. Целью было извлечение бизнес-сущностей, которые можно сразу загружать в ERP, DWH и юридические системы без ручной доработки.

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

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

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

Поэтому мы сознательно подошли к задаче как к R&D-исследованию и протестировали несколько классов open-source моделей, чтобы понять границы применимости каждой из них.

Что показало тестирование моделей

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

Вместо того чтобы сразу фиксироваться на одной модели, мы сознательно протестировали несколько классов open-source LLM. Задача была не найти максимальное качество в вакууме, а понять границы применимости моделей в реальных инфраструктурных условиях и при работе с длинными юридическими текстами.

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

В итоге наилучший баланс показали Instruct-модели класса Qwen3-30B-A3B. Они стабильно следовали инструкциям, корректно извлекали сущности и укладывались в инфраструктурные ограничения. Именно на них мы остановились в финальной версии системы.

Почему качество определяется не только моделью

Начальный baseline был предсказуемым. Простые промпты без структурирования давали около 63 процентов Precision и Recall. Было очевидно, что одной только заменой модели эту планку не поднять.

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

Подход к контролю ошибок

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

Мы заложили принцип: лучше не извлечь поле, чем извлечь его неправильно. Для этого каждое значение, возвращаемое моделью, получало confidence-оценку. Поля с уровнем уверенности ниже 70 процентов автоматически отбрасывались.

После этого данные проходили типизацию, проверку форматов и бизнес-валидацию: поиск дублей и несовместимых реквизитов. Такой подход резко снизил количество галлюцинаций и ложных данных.

• Precision: 63,2% → 99,7% (в тестовом сете из документов заказчика)
• Recall: 62,8% → 93,1%
• F1-score: 62,7% → 95,9%
• Overall Score: 0,595 → 0,96

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

Как устроена система

Финальная система реализована как асинхронный пайплайн. Сначала происходит загрузка документа и извлечение текста, затем классификация типа документа. После этого выбирается стратегия обработки, выполняется LLM-экстракция, агрегация и дедупликация данных, а на финальном этапе — строгая валидация.

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

Вместо заключения

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