Legora подняла точность юридических ссылок с 70% до 99% без доступа к данным

У команды Legora неудобная, но всё более знакомая проблема: её юридический агент работает с конфиденциальными документами, а разработчики не могут просто открыть трассу и посмотреть, где модель свернула не туда. Данные принадлежат клиентам юридических фирм. Значит, привычный цикл «нашли плохой ответ — прочитали запрос — поправили промпт» здесь не работает.

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

Как проверить то, чего нельзя увидеть

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

Затем команда заранее задаёт правильные ответы и измеряет отдельные этапы: найден ли нужный документ, извлечено ли условие, соответствует ли вывод источнику, ведёт ли цитата в правильное место. В интервью CTO Legora Джейкоб Лауритцен описывает отдельную команду из инженеров и юристов, которая строит такие среды. Это напоминает игровые «миры» для обучения агентов: система получает реалистичную задачу, но не соприкасается с закрытым делом клиента.

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

Метрики важнее красивой демонстрации

Особенно показателен пример с цитатами. По словам Лауритцена, в одном из тестов модель правильно указывала источники примерно в 70% случаев. После очередного обновления базовой модели показатель вырос до 99%, хотя Legora не меняла собственную систему. Для продукта это хорошая новость, но одновременно предупреждение: качество агента зависит не только от вашего кода. Поставщик модели может внезапно исправить слабое место — или сломать то, что вчера работало.

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

Что можно перенести в обычный продукт

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

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

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