Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Быстрые модели для мелких решений в ИИ-агентах оказались сложнее в оценке, чем в запуске: ошибки в метриках и учёте затрат меняли вывод о готовности системы к внедрению. Это показал Jiawei Li, заново проверив собственный эксперимент; поскольку препринт не рецензирован, все числа в нём получил сам автор. Для продуктовой команды вывод практический: измерять нужно не отдельный фильтр, а стоимость и ошибки всей цепочки.
Как отделили качество модели от ошибок обвязки
Обвязка ИИ-агента постоянно принимает короткие решения: выбрать модель или инструмент, проверить уместность найденного документа, пропустить запрос либо отправить его на дополнительную проверку. Обычно для этого вызывают LLM, хотя ответ сводится к одному варианту из заданного списка.
Модели System-1 решают такую задачу за один прямой проход и возвращают вероятности вариантов. В работе сравнили открытую Laya и доступную через API Jev на тысячах исходных примеров и изменённых версий. Тест охватывал 11 точек принятия решений — от выбора инструмента до поиска персональных данных.
Обе модели получали побайтово одинаковые входные данные. Сравнение было парным: исследователь смотрел, какая модель верно отвечает на одном и том же примере, а не сопоставлял средние оценки на разных наборах. Отдельные проверки меняли порядок вариантов, формулировки инструкции и канал поступления текста, а повторные запуски проходили на другом оборудовании и в другой день.
Важная часть работы — повторный расчёт результатов из необработанных ответов. Для каждого подозрительного эффекта появился контрольный тест: случайные инструменты заменили похожими, искусственно перенесённые сообщения — естественными документами, а шаблоны персональных данных — обычными фразами. Так удалось разделить ошибки моделей, особенности набора данных и ошибки кода анализа.
Проверяли по одной версии Laya и Jev, без дополнительного обучения, преимущественно на англоязычных публичных наборах. Поэтому работа описывает применение готовых моделей без настройки под конкретный продукт, но не предел их качества после обучения на данных компании.
Jev держит большие наборы вариантов, Laya зависит от их устройства
Jev точнее на 9 из 11 точек принятия решений. Обе модели не справились с выбором между дешёвой и сильной LLM без обучающих примеров, а при проверке уместности документов для генерации с поиском показали сопоставимый результат. Универсального маршрутизатора, который можно поставить перед любым набором моделей, сравнение не выявило.
Разрыв особенно заметен при выборе инструмента. Когда среди 50 похожих вариантов был один однозначно правильный, точность Laya упала до 31%, а Jev сохранила 98%. Код Laya делит ограниченный объём входа между всеми вариантами, поэтому при длинном списке описание каждого инструмента обрезается почти до нескольких слов.
Laya также часто меняла решение после перестановки вариантов. Это означает, что фиксированный тест с одним порядком может переоценить качество. Для такой модели нужно проверять несколько перестановок, ограничивать число похожих инструментов и заново настраивать порог уверенности на данных конкретного процесса.
Jev устойчивее, но тоже не подходит для любой проверки. Выбор модели, отсев документов перед генерацией и поиск персональных данных требуют других сигналов или специализированных компонентов. Высокая средняя точность не компенсирует ошибку именно в том классе, который фильтр обязан не пропускать.
Планы меняет полный расчёт каскада, а не точность фильтра
Главная ошибка первоначального расчёта касалась двухступенчатой проверки безопасности. Быстрая модель должна была пропускать очевидно безопасные запросы, а остальные отправлять в LLM. В первый итог не включили стоимость самой предварительной проверки: заявленная экономия составляла 23,9%, после исправления — 4,3%.
В другом случае точность фильтра приняли за качество всей системы. Для генерации с поиском отчёт показывал около 58%, хотя полный процесс сохранял ответы примерно для 98% запросов, на которые можно было ответить. Документ, ошибочно пропущенный фильтром, всё равно попадал в LLM, поэтому ошибка промежуточного компонента не всегда становилась ошибкой продукта.
Порог уверенности тоже нельзя выбирать и проверять на одних примерах. На исходном наборе он гарантированно попадал в заданную долю пропусков, но на отложенной части результат ухудшался. Для рабочего каскада порог следует настраивать отдельно, а затем измерять долю дорогих вызовов и долю опасных пропусков на новых данных.
Работа не требует отказаться от моделей быстрых решений. Jev подходит как кандидат для выбора инструментов, классификации по большому закрытому списку и предварительного поиска инъекций. Но бизнес-расчёт должен включать цену каждого шага, сетевую задержку, частоту перехода к LLM и стоимость ошибки после прохождения всего процесса.
Пилот такого компонента стоит строить вокруг производственного распределения запросов. Нужны естественные документы для каждого канала, похожие варианты инструментов и отдельный набор для порогов. Иначе команда измерит аккуратность демонстрации, а не экономику будущей системы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
