Пакетная верификация AI-агентов: как снизить затраты в 10 раз

Андрей Отинов -

Команда, разрабатывающая юридического AI-агента, сталкивается с неожиданной проблемой: проверка качества работы агента обходится дороже, чем сам агент. Каждое задание в бенчмарке LAB, выпущенном компанией Harvey в мае 2026 года, содержит до 50 и более отдельных критериев, которые необходимо оценить. Если каждый критерий проверять отдельным запросом к сильной модели, стоимость верификации взлетает до сумм, делающих масштабное тестирование или обучение с подкреплением (RL) экономически неоправданным.

Источник: langchain.com

Исследователи из LangChain Labs совместно с Harvey поставили практический вопрос: можно ли снизить стоимость верификации на порядок, не потеряв качество проверки? В статье, опубликованной 2 июня 2026 года, они представили результаты экспериментов, которые показывают — да, можно. Ключевые методы: пакетная проверка критериев (батчинг) и использование открытых моделей вместо дорогих frontier-решений.

Что изменилось: от проверки каждого критерия по отдельности к пакетной оценке

Бенчмарк LAB (Legal Agent Benchmark) устроен так, как работает реальный юридический ревьюер: каждое задание имеет набор критериев, которые должны быть выполнены. Например, для задачи по корпоративным слияниям и поглощениям может быть 50–70 отдельных требований: «документ содержит правильную ссылку на статью 57 ГК РФ», «оговорка о конфиденциальности включена», «сроки указаны верно».

Традиционный подход — запустить LLM-верификатор для каждого критерия отдельно. Это означает 50–70 API-вызовов на одно задание. При масштабировании на сотни или тысячи заданий затраты становятся критическими.

Исследователи предложили альтернативу: вместо отдельных вызовов отправлять весь рубрикатор одним запросом и просить модель оценить все критерии сразу. Это называется пакетной оценкой (batch scoring). Вместо 50 вызовов — один. Экономия токенов достигается за счёт того, что контекст (описание задания и ответ агента) передаётся один раз, а не повторяется для каждого критерия.

Второй метод — использование более дешёвых моделей. Вместо Opus 4.7 (взятого за эталон) исследователи протестировали GPT-5.5, Sonnet 4.6, DeepSeek v4 Flash и Claude Haiku 4.5 как в режиме покритериальной, так и в пакетной оценке.

Почему это меняет экономику разработки юридических AI-агентов

Эксперимент проводился на 40 публичных задачах из LAB в четырёх практических областях: корпоративные слияния и поглощения, налоги, стартапы/венчурный капитал, трасты и наследство. Агент на базе Kimi K2.6 сгенерировал ответы, которые затем проверялись по 2 348 отдельным критериям рубрикатора.

Для каждого прогона верификатора измерялись четыре показателя:

  • Согласие — насколько часто верификатор совпадает с эталоном (Opus 4.7 покритериально).
  • Ложное принятие (false pass) — верификатор засчитал критерий как пройденный, хотя эталон считает его проваленным.
  • Ложное отклонение (false fail) — обратная ситуация.
  • Стоимость — фактические затраты на токены для прогона 40 задач.

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

Результаты показали, что комбинация пакетной оценки и дешёвых моделей позволяет снизить стоимость на порядок (примерно в 10 раз) при минимальной потере согласия с эталоном. Точные цифры по каждой модели и режиму авторы приводят в полной версии статьи, но ключевой вывод: пакетная оценка не приводит к катастрофическому падению качества, а использование открытых моделей (DeepSeek v4 Flash, Claude Haiku 4.5) даёт приемлемый уровень ложных принятий.

Что проверить до внедрения: практический чек-лист для команды

Прежде чем менять процесс верификации, необходимо провести собственные замеры. Эксперимент LangChain Labs и Harvey — это ориентир, а не готовое решение для любой юридической задачи.

Что меняется Почему важно бизнесу Что проверить
Переход от покритериальной к пакетной оценке Снижение затрат на API в 5–10 раз Не увеличивается ли доля ложных принятий на ваших задачах
Использование открытых моделей вместо frontier Снижение стоимости токенов, меньшая зависимость от одного вендора Достаточно ли качества для ваших критериев (особенно по ложным принятиям)
Промпт-тюнинг верификатора Возможность настроить строгость проверки под конкретную задачу Требуется ли разный уровень строгости для разных типов документов
Масштабирование на RL post-training Становится экономически feasible обучать агента с подкреплением Хватает ли вычислительных ресурсов и бюджета на несколько итераций

Чек-лист для первой проверки (можно выполнить за неделю):

  1. Выберите 10–20 типовых задач из вашей практики, для которых у вас есть эталонные ответы или экспертные оценки.
  2. Составьте рубрикатор критериев для каждой задачи (не менее 20 критериев на задачу).
  3. Запустите пакетную оценку с использованием DeepSeek v4 Flash или Claude Haiku 4.5.
  4. Сравните результаты с покритериальной оценкой через Opus 4.7 или GPT-5.5.
  5. Посчитайте долю ложных принятий — если она превышает 5–7%, метод может быть неприемлем для вашего домена.
  6. Оцените фактическую экономию в рублях или долларах с учётом ваших тарифов на API.
  7. Примите решение: использовать пакетную оценку для всех задач, только для предварительного скрининга или не использовать вовсе.

Какие риски и ограничения нужно учитывать

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

Использованные в статье названия моделей (Opus 4.7, GPT-5.5, DeepSeek v4 Flash, Claude Haiku 4.5) могут быть гипотетическими или относиться к будущим версиям. На момент публикации статьи (июнь 2026 года) эти модели могут быть недоступны или иметь другие характеристики. Перед принятием решения проверьте актуальные версии и цены.

Методология сравнивает все модели с Opus 4.7 как с эталоном. Однако сам Opus имеет расхождения с другими frontier-моделями на уровне 4–5%. Это означает, что «ложные принятия» могут быть не ошибкой дешёвой модели, а расхождением между двумя сильными моделями. Для критически важных юридических задач может потребоваться человеческая верификация хотя бы выборочно.

Статья написана вендорами — LangChain (платформа для разработки AI-агентов) и Harvey (юридический AI-стартап). Это создаёт потенциальный конфликт интересов: результаты могут быть смещены в пользу инструментов и подходов, которые продвигают эти компании. Рекомендуется воспроизвести эксперимент на собственных данных, прежде чем принимать стратегические решения.

Что делать на этой неделе

Не пытайтесь внедрить пакетную верификацию сразу на все задачи. Начните с малого: выберите один тип юридических документов, с которым ваша команда работает регулярно. Составьте рубрикатор из 20–30 критериев. Запустите пробный прогон с использованием DeepSeek v4 Flash или Claude Haiku 4.5 в пакетном режиме. Сравните результаты с текущим процессом проверки.

Если доля ложных принятий окажется приемлемой (менее 5%), можно расширять эксперимент на другие типы задач. Если нет — возможно, для вашего домена потребуется более строгий верификатор или гибридный подход: пакетная оценка для предварительного скрининга и покритериальная проверка для критических критериев.

Главный практический вывод из исследования LangChain Labs и Harvey: стоимость верификации не должна быть барьером для разработки юридических AI-агентов. Пакетная оценка и открытые модели делают масштабное тестирование и RL-обучение экономически доступными. Но решение о внедрении должно опираться на ваши собственные данные, а не на чужие бенчмарки.

Источники

Темы журнала

Что почитать дальше