Можно ли доверить важные документы open-source LLM: эксперимент Рег.облака и Raft

Привет, Хабр! На связи команды Рег.облака и Raft.

За последние годы автоматизация работы с юридическими документами прошла несколько этапов: регулярные выражения, классический NLP, первые нейросетевые модели. Почти всегда результат упирался в одно и то же — либо качество оказывалось недостаточным для бизнеса, либо сопровождение и доработки делали решение слишком дорогим.

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

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

Навигация по тексту:

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

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

• Почему для нас так важен выбор инфраструктуры

• Результаты тестирования моделей

• Пара мыслей о связи качества и модели

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

• Результаты, которые мы смогли измерить

• Еще немного об устройстве системы

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

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

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

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

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

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

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

Если упростить, их запросы можно разложить на три уровня:

• первый — базовый: что будет, если выполнить то или иное действие;

• второй — инструментальный: как правильно реализовать конкретную стратегию;

• третий — стратегический: какие последствия это повлечет для компании и контрагентов в перспективе.

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

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

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

Для Raft этот эксперимент стал частью discovery-фазы будущего продуктового решения для работы с юридическими данными. Целью было не показать демо, а проверить, можно ли использовать open-source LLM в реальном промышленном сценарии — с длинными документами, высокой ценой ошибки и понятной экономикой.

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

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

Почему выбор инфраструктуры был критичен

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

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

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

А почему тогда мы начали не с выбора модели?

Логичный вопрос в начале проекта — какую LLM выбрать. В корпоративных сценариях он оказался вторичным. Ключевыми были ограничения реального использования:

• данные не должны покидать доверенный контур;

• результат должен быть воспроизводимым и предсказуемым;

• требования к инфраструктуре — оставаться экономически оправданными.

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

Результаты тестирования моделей

Тестирование быстро показало, что разные классы open-source LLM упираются в разные ограничения — по качеству, ресурсам или времени обработки.

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

Полноразмерные модели демонстрировали эталонное качество, но требовали нескольких GPU и не укладывались в разумную экономику production-развёртываний.

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

Наиболее сбалансированными оказались instruct-модели класса Qwen3-30B-A3B: они стабильно следовали инструкциям, корректно извлекали сущности и укладывались в инфраструктурные ограничения по скорости и ресурсам.

Кратко результаты выглядели так:

• Легковесные модели с сильной квантизацией (Qwen3-30B‑A3B‑GGUF)
  Низкие требования к ресурсам и быстрое развёртывание, но систематические пропуски ИНН, сумм и реквизитов, а также галлюцинации. Для качественного извлечения сущностей непригодны.

• Полноразмерные модели (Qwen3-235B)
  Эталонное качество, но чрезмерные требования к GPU и памяти. Экономически и инфраструктурно неприменимы в production‑сценариях.

• Reasoning‑модели (Qwen3-32B)
  Высокая точность, но избыточное время обработки — до нескольких минут на документ. Для потоковой обработки не подходят.

• Instruct‑модели (Qwen3-30B‑A3B)
  Оптимальный баланс качества и скорости. Стабильно следуют инструкциям, корректно извлекают сущности и укладываются в инфраструктурные ограничения.

Почему выбрали Qwen3-30B-A3B

В финале наилучший баланс показали instruct-модели класса Qwen3-30B-A3B. Модель уверенно работала на одной GPU A100 80 ГБ и при этом оставляла запас по мощности — порядка 30–40%, который можно использовать для роста нагрузки без перестройки архитектуры.

Это оказалось критичным с точки зрения экономики. Большинство моделей с сопоставимым качеством либо не помещаются на одну карту, либо начинают деградировать при росте числа пользователей. Здесь же запас по ресурсам позволяет пройти фазу роста без немедленного масштабирования на несколько GPU и пересборки пайплайна.

По пользовательскому опыту это тоже оказалось важным. Латентность инференса укладывалась в пределы, которые не воспринимаются как «подвисание» интерфейса. Ответы до одной секунды практически не ощущаются, а после нескольких секунд система начинает восприниматься как нестабильная — и это напрямую влияет на доверие пользователей.

В итоге сошлась тройка факторов: качество извлечения на уровне 97–98 % по ключевым полям, инфраструктурная реализуемость на одной GPU и понятная экономика сопровождения без обязательного масштабирования на несколько видеокарт. Дополнительным плюсом стала универсальность модели — ее можно расширять под агентные сценарии, обработку разных форматов и смежные задачи, не меняя базовую архитектуру.

Несколько мыслей о связи качества и модели

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

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

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

Отдельно пришлось контролировать длину контекста. Несмотря на заявленные большие окна, на практике модели начинают терять связность уже при заполнении контекста на 60–70%. Мы использовали адаптивный подход: на длинных договорах контекст сжимался и суммаризировался без потери критичных фрагментов, что снижало вероятность галлюцинаций.

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

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

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

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

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

Результаты, которые получилось измерить

После всех архитектурных и R&D-итераций мы получили систему, качество которой имеет смысл измерять стандартными метриками информационного извлечения.

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

Еще немного об устройстве системы

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

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

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

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

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

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