Как проверять юридический ИИ: тесты, источники и ошибки
Юридический ИИ нельзя оценивать как обычный чатбот. Красивый ответ не означает, что система правильно нашла источник, учла редакцию документа, не смешала похожие нормы и не придумала уверенную формулировку. В правовой задаче качество ответа начинается не со стиля, а с проверяемости.
Поэтому тестирование юридического ИИ должно быть ближе к приемке продукта, чем к разговору с моделью. Нужно заранее подготовить набор вопросов, ожидаемые источники, допустимые границы ответа, случаи, где система должна отказаться, и журнал типовых ошибок. Тогда проверка показывает не настроение модели, а рабочую надежность контура.
LegalBench полезен как публичный сигнал: юридическое рассуждение можно раскладывать на разные типы задач, а не мерить одной общей оценкой. Но для прикладной системы одного бенчмарка мало. Нужна локальная тестовая подборка, похожая на реальные вопросы пользователей и реальные документы.
Что именно проверять
Первый слой проверки: источник. Система должна показать, откуда взят ответ. Если ответ нельзя связать с документом, пунктом или цитатой, это не юридический ответ, а предположение. Второй слой: применимость. Даже правильный источник может быть не тем, если документ устарел, относится к другой ситуации или не имеет нужной силы.
Третий слой: поведение на границе. Хорошая система не обязана отвечать на все. Иногда правильный ответ: не хватает данных, нужен первичный документ, требуется юрист, источник не найден. Для юридического ИИ отказ от ответа является не слабостью, а частью качества.
Главное:Проверка юридического ИИ должна отвечать не на вопрос "умно ли звучит модель", а на вопрос "можно ли принять ее ответ в рабочем процессе". Для этого нужны источники, цитаты, тестовые случаи, ошибки, отказы и журнал изменений.
Минимальная матрица тестов
| Тип теста | Что показывает | Пример риска |
|---|---|---|
| Прямой вопрос по норме | умеет ли система найти первичный источник | модель пересказывает обзор вместо нормы |
| Вопрос с устаревшей редакцией | различает ли версии документов | ответ строится на старом тексте |
| Похожий, но другой случай | не смешивает ли правовые режимы | находится похожая, но неприменимая норма |
| Недостаточно данных | умеет ли система отказаться | модель додумывает факты |
| Контроль цитаты | можно ли проверить ответ руками | цитата не подтверждает вывод |
Метрики retrieval-качества помогают сделать эту проверку менее субъективной. Context precision показывает, попали ли в контекст релевантные фрагменты. Faithfulness помогает смотреть, можно ли вывести утверждения ответа из найденного контекста. Но даже хорошие метрики не отменяют ручной приемки: юридический риск часто живет в деталях формулировки.
Как встроить это в агентный контур
Если юридический ИИ работает как агент, проверка должна смотреть не только на финальный текст. Важно видеть путь: какой запрос он сделал, какие документы получил, какие фильтры применил, где остановился, почему выбрал этот источник. Иначе ошибка будет выглядеть как один красивый абзац, а не как цепочка решений, которую можно исправить.
Для Codex-подхода это можно оформить как отдельный навык приемки. Агент сначала собирает ответ, потом сам прикладывает источники, затем прогоняет чеклист: есть ли цитата, совпадает ли редакция, не было ли отказа, не нарушены ли границы. После этого человек смотрит не пустой ответ, а пакет проверки.
Где граница
Такая проверка не делает модель юристом и не заменяет профессиональную ответственность. Она помогает понять, где система может быть полезным помощником: найти документы, собрать цитаты, показать противоречия, подготовить черновик анализа. Но финальное решение, особенно в спорной ситуации, остается за человеком.
Главное преимущество тестового подхода в том, что он делает качество обучаемым. Ошибка перестает быть случайным неприятным эпизодом. Она превращается в новый тест, новую проверку, новую границу для агента.