Об эксперте: Евгений Мартынов, директор по информационным технологиям «Рег.облака».
LLM входит в практику
Несколько лет подряд вокруг больших языковых моделей (LLM) сохранялось общее мнение: такие системы нельзя использовать в задачах, где цена ошибки высока. Регуляторы и профессиональные сообщества указывали на риски для конфиденциальности данных, сложности с проверкой результатов и потенциальные проблемы с соблюдением законодательства.
Эти опасения подкреплялись практикой. В разных странах юристов уже привлекали к ответственности за документы с вымышленными ссылками на судебную практику и другими ошибками, появившимися из-за некритичного применения генеративных ИИ-инструментов. Например, в октябре 2025 года в штате Калифорния суд оштрафовал адвоката Амира Мостафави на $10 тыс. за подачу апелляции, в которой 21 из 23 цитат оказалась сгенерированной ChatGPT.
При этом в конце 2025 года в журнале Humanities and Social Sciences Communications (Nature) вышел обзор, в котором отмечалось: использование LLM в правовых сценариях перестало быть единичным экспериментом. Модели применяют для анализа документов, подготовки материалов, комплаенса и извлечения данных. При этом ключевым фактором становится не сама модель, а то, как она встроена в систему обработки.
Речь не о том, что LLM стали безошибочными. Скорее, меняется подход. Вместо универсального чат-ассистента компании все чаще строят управляемые контуры, где модель работает внутри пайплайна с ограничением контекста, заданным форматом ответа и обязательными проверками.
Этот вывод подтверждают и исследования качества. Например, Stanford AI в 2024 году показал, что даже специализированные юридические модели могут допускать ошибки примерно в каждой шестой проверочной задаче. Это делает контроль и валидацию не дополнительной опцией, а обязательным условием применения.
Почему юридические документы снова стали кандидатом на автоматизацию
Юридические документы остаются одной из самых сложных областей для цифровизации. В них редко встречается строгая структура: формулировки отличаются от документа к документу, данные распределены по тексту, а ошибка в одном поле может привести к финансовым или комплаенс-рискам.
При этом бизнес-задача обычно не сводится к поиску текста или подсветке фрагментов. В реальных сценариях требуется извлекать конкретные бизнес-сущности — реквизиты, суммы, сроки, ссылки на приложения — и загружать их в ERP-системы (корпоративные системы управления ресурсами компании) и юридические платформы в структурированном виде.
Классические подходы автоматизации проходили несколько этапов: от шаблонов и регулярных выражений к NLP-алгоритмам и ранним нейросетевым решениям. Многие проекты упирались либо в качество, недостаточное для эксплуатации, либо в стоимость поддержки — любая вариативность формулировок требовала ручных доработок.
Сегодняшний сдвиг связан не только с развитием языковых моделей. Существеннее то, что меняется сама логика применения: LLM используют не как самостоятельный источник ответа, а как часть управляемой системы с проверками и ограничениями.
Рост бизнеса как точка давления на юридические процессы
На практике интерес к автоматизации юридических документов часто возникает на этапе роста компании. По мере расширения бизнеса увеличивается объем договоров, запросов и пользователей, а юридическая функция начинает масштабироваться хуже, чем остальные процессы.
В таких условиях даже привычные инструменты — например, справочно-правовые системы с ограничениями по API-запросам — перестают справляться с нагрузкой. Юридическая экспертиза становится узким местом, а затраты на ручную обработку документов растут быстрее, чем компания в целом.
Кроме того, меняется характер запросов. Юристы все чаще участвуют не только в проверке документов, но и в оценке рисков, сценариев и последствий управленческих решений. Это требует и доступа к текстам, и устойчивого анализа и интерпретации данных.
Как тестируют LLM для работы с чувствительными данными
В декабре 2025 года команда компании Raft — разработчика решений в области прикладного машинного обучения и анализа данных для бизнеса — получила грант «Рег.облака» на использование облачных серверов с GPU A100 (80 ГБ). Целью эксперимента было проверить, как open-source LLM работают с длинными юридическими документами и возможно ли построить автономный контур извлечения данных без обращения к внешним API.
Эксперимент запускался в публичном облаке, но архитектура изначально проектировалась так, чтобы ее можно было развернуть и в закрытом корпоративном контуре. Это означало изолированное размещение у заказчика, при котором документы не передаются сторонним сервисам, а весь пайплайн обработки находится внутри доверенной инфраструктуры.
Почему архитектура важнее выбора модели
В корпоративных сценариях выбор конкретной модели редко оказывается решающим. На первом этапе важнее зафиксировать ограничения:
- данные не должны покидать доверенную среду;
- результат должен быть воспроизводимым;
- требования к инфраструктуре должны оставаться разумными.
В рамках эксперимента тестировали разные классы open-source LLM с точки зрения качества извлечения, стабильности и времени обработки. Легковесные модели с квантизацией не обеспечивали стабильного качества и допускали ошибки в критичных полях. Полноразмерные модели давали высокую точность, но требовали нескольких GPU и плохо вписывались в экономику типовых развертываний. Reasoning-модели — LLM, ориентированные на пошаговое рассуждение и объяснение логики ответа, показывали хорошие результаты, но обрабатывали один документ до нескольких минут, что затрудняло прогнозирование нагрузки.
Наиболее сбалансированным вариантом оказались instruct-модели класса Mixture of Experts — модели, обученные строго следовать заданным инструкциям и динамически распределять вычисления между специализированными подсетями. Они позволяли удерживать качество и при этом обходиться одной GPU с запасом по мощности, что снижало совокупную стоимость владения.
Контроль ошибок как основа доверия
Даже корректный выбор архитектуры не решает проблему автоматически. Базовый уровень без оптимизации показывал около 63% по точности и полноте извлечения. Существенный рост качества обеспечили инженерные решения вокруг модели.
- Разделение обработки по типам документов. Юридические документы сильно отличаются по структуре и логике. Договор, акт или судебное решение нельзя обрабатывать одинаково. Поэтому для разных типов документов использовались разные сценарии обработки. Это позволяло задавать модели более точный контекст и снижало количество ошибок при интерпретации текста.
- Строгий формат ответа. LLM может вернуть почти правильный результат, но сломать структуру: перепутать поля, типы данных или вложенность. Чтобы этого избежать, вывод ограничили строгим форматом. Если ответ ему не соответствовал, он не принимался, и запускалась повторная генерация. Так некорректные данные отсеивались до попадания в бизнес-системы.
- Контроль длины контекста. Хотя модели заявляют поддержку длинного контекста, на практике при его переполнении они начинают терять часть информации и «додумывать» недостающее. Поэтому длину контекста сознательно ограничивали. Если документ становился слишком длинным, предыдущие части сжимались без потери ключевого смысла и только после этого передавались дальше.
- Адаптивный чанкинг длинных договоров. Текст делили не на одинаковые куски, а на смысловые фрагменты разного размера. В одних случаях достаточно строки, в других — абзаца или нескольких связанных предложений. Такой подход позволял точнее извлекать данные и лучше сохранять смысл, чем механическое деление текста.
- Постобработка и дедупликация данных. Даже корректные ответы модели могут содержать повторы или избыточные формулировки. На этапе постобработки данные очищались: убирались дубли, значения приводились к единому формату, формулировки упрощались.
Ключевым стал подход к контролю ошибок. В юридических сценариях безопаснее не извлечь поле вовсе, чем вернуть неверное значение. Поэтому каждому результату присваивалась оценка уверенности, а значения ниже заданного порога автоматически отбрасывались. Далее данные проходили типизацию, проверку форматов и бизнес-валидацию.
Что показывают измеримые результаты
После нескольких итераций настройки пайплайна качество извлечения стало стабильным:
- precision — 99,7% в тестовом сете из документов заказчика;
- recall — 93,1%;
- F1-score — 95,9%;
- overall score — 0,96.
На практике это означает, что система почти не возвращает ошибочные данные, большинство критичных реквизитов извлекается автоматически, а ручная проверка остается только там, где уровень риска действительно высок.
Что меняется в подходе к юридическим документам
Этот эксперимент не отменяет ограничений LLM и не снимает требований по безопасности и комплаенсу. Он показывает, что у бизнеса появляется более управляемый способ работать с юридическими документами — без передачи данных во внешние сервисы и без ожиданий, что модель сама по себе даст надежный результат.
Фокус смещается с вопроса «можно ли использовать LLM» на вопрос «при каких условиях это допустимо». Архитектура, контроль ошибок и воспроизводимость становятся важнее размера модели и ее формальных возможностей.
Что стоит учитывать компаниям
Совмещение практики и исследований позволяет выделить несколько устойчивых выводов:
- даже сильные модели могут ошибаться, поэтому контроль ложных данных остается критичным;
- требования к конфиденциальности и правовым основаниям обработки данных ограничивают выбор архитектуры;
- производственное качество достигается там, где LLM встроена в управляемый пайплайн, а не используется как автономный источник ответа.
Юридические документы долго считались слишком рискованной зоной для автоматизации. Эти риски никуда не исчезли, но подход к работе с ними стал более зрелым. LLM постепенно перестают быть экспериментальным инструментом и становятся частью инфраструктуры при условии, что бизнес готов управлять ограничениями, а не игнорировать их.
➤ Подписывайтесь на телеграм-канал «РБК Трендов» — будьте в курсе последних тенденций в науке, бизнесе, обществе и технологиях.