Исследователи из Microsoft и City University of Hong Kong создали Taste-Bench — тест для долгих задач, где агенту нужно выбрать один из двух путей до того, как станет виден результат. Лучший из 14 проверенных моделей набрал 59,7%, а когда ключевая подсказка появлялась только после длительной работы, средняя точность падала до 21%. Для пользователя это простой сигнал: успешный финальный ответ ещё не доказывает, что агент разумно шёл к нему. Для общего контекста о таких системах пригодится обзор фреймворков для AI-агентов.
Суть события
Авторы называют способность выбирать хорошие решения на длинной дистанции «вкусом» агента. Речь не о стиле или предпочтениях. Агент постоянно решает, какую гипотезу проверить, какой код развивать и какой эксперимент запустить следующим. Ошибка может выглядеть безобидной в момент выбора, а её цена проявиться только позже — когда уже потрачена большая часть времени или вычислительного бюджета.
Обычные тесты чаще смотрят на конечный результат: прошли ли тесты или закончилась ли задача. Taste-Bench проверяет промежуточное решение. Исследователи останавливают запись работы в точке расхождения, скрывают продолжение и просят модель выбрать направление, которое позже оказалось более удачным.
Что именно измерил Taste-Bench
В набор вошли 502 вопроса. В каждом есть исходная задача, история действий до точки выбора и два возможных направления. Часть примеров собрана из двух независимых попыток одной задачи, часть — из эпизодов, где агент сам свернул на неудачный путь, а затем исправился. В основу легли тысячи оценённых запусков на задачах программирования и исследования ИИ, включая SWE-bench Pro и открытые расшифровки METR.
В проверке участвовали 14 моделей семейств Claude, GPT, Grok, DeepSeek, GLM, MiniMax и Mistral. Каждый вопрос задавали в двух вариантах с разным порядком ответов; засчитывался только ответ, верный в обоих случаях. При таком правиле случайный выбор даёт 25%. GPT-5.6 Sol достиг 59,7%, GPT-5.5 — 59,5%, а остальные модели заметно отстали. Ни одна не приблизилась к полному решению теста.
Самая неприятная деталь касается времени появления доказательства. Если нужная подсказка уже была в предыдущих шагах, средняя точность моделей составляла 62,3%. Когда она становилась видна лишь после большой части дальнейшей работы, точность опускалась до 21% — почти до уровня случайного выбора. Более долгий режим рассуждений проблему не решил: модели дольше думали именно над самыми трудными вопросами, но чаще всего всё равно ошибались.
Почему результат важен для рабочих задач
Для семьи, небольшой команды или разработчика риск здесь практический: агент может выглядеть убедительно, пока раннее решение незаметно ухудшает следующие шаги. Финальная проверка тогда обнаружит уже дорогую ошибку. Один пройденный тест не показывает, насколько устойчиво система выбирала путь и сколько лишней работы потребовалось.
При этом Taste-Bench не доказывает, что агенты всегда принимают плохие решения. Он измеряет отдельный навык — выбор между направлениями в длинной цепочке — и показывает его слабое место на конкретных примерах. Низкий балл также не означает, что модель бесполезна для каждой задачи: последствия зависят от того, может ли человек проверять промежуточные решения и насколько дорого исправление ошибки.
Авторы отдельно показали, что навык можно улучшать. Они передали оценку правильного пути от модели-учителя модели Qwen3.6-27B. На новых задачах точность ученика выросла с 30% до 47,9%. Когда его советы добавляли в рабочий контекст отдельного агента, результат на 41 отложенной задаче SWE-bench Pro поднялся с 14,6% до 33,7%. Это исследовательский результат, а не обещание одинакового прироста в обычном продукте.
Что дальше
Taste-Bench и код к нему опубликованы, поэтому следующий вопрос для разработчиков — насколько хорошо такой тест переносится на другие типы долгих задач. Пока источник описывает один исследовательский набор и его результаты, а не готовый универсальный стандарт качества.
Пользователю уже сейчас полезно разделять два вопроса: выполнил ли агент задачу и правильно ли он принимал решения по дороге. Для важных поручений стоит сохранять историю шагов, ограничивать последствия автоматических действий и проверять развилки, после которых исправление становится дорогим. Это не заменяет оценку конкретной системы, но не даёт финальному успеху скрыть слабый процесс.
