Don’t ship skills without evals
Скиллы едут и бибикают, но остаётся, как мне кажется, слабо освещённым вопрос: как проверить, что скилл работает качественно? И вообще, что считать качеством?
В исследовании SkillsBench ребята собрали 47 тысяч уникальных скиллов – почти все без evals. В целом я этих людей понимаю: забахали скилл, вроде работает – бежим дальше. А проверка качества – это уже скучные детали. В результатах SkillsBench заранее подготовленные и отобранные скиллы дали в среднем +16,2 процентного пункта, а скиллы, которые агенты генерировали сами перед выполнением задачи, – −1,3.
Посмотрел доклад ребят из DeepMind – про evals для скиллов.
Сначала докладчик даёт общие рекомендации по скиллам:
– описание должно точно объяснять, когда, зачем и как использовать скилл – и когда не использовать
– инструкции стоит формулировать директивно, а не расплывчато, вычищать no-ops, держать SKILL.md компактным, а детали выносить в референсы. Думаю, в целом это уже всем известные приёмы
– мне понравилось замечание, что не всё стоит пытаться натянуть на скилл. Если процесс всегда состоит из одних и тех же чётких шагов, вероятно, скилл вообще не нужен – проще написать скрипт
– не все скиллы нужно вызывать автоматически. Например, скилл для ревью имеет смысл вызывать вручную
Дальше – собственно про evals.
– начать стоит 10–20 кейсов: кейсы, где скилл должен сработать, где не должен срабатывать. Если есть подтвержденные сценарии с прода, их тоже стоит включить в проверки. От себя хочу уточнить, что важно не полагаться на автогенерацию evals. Агент может помочь собрать первую версию, но в основе должны быть реальные сценарии использования, с реальными формулировками
– проверять стоит не то, вызвал ли агент скилл на первом шаге, а решил ли он задачу. В примере с Gemini API итогом был валидный код с актуальными SDK, моделью и методами. Такие условия можно проверять регулярками или скриптами, а более сложные результаты – через LLM as a judge
– каждый кейс стоит запускать в чистом окружении и повторять 3–6 раз, потому что ответы агента недетерминированы. Если в работе используются разные модели или харнессы, evals нужно прогонять на каждом из них
– одни и те же сценарии нужно прогонять со скиллом и без него. Только так можно понять, улучшает ли он результат. А заодно увидеть момент, когда модель уже справляется сама и скилл уже не нужен
#ai
Скиллы едут и бибикают, но остаётся, как мне кажется, слабо освещённым вопрос: как проверить, что скилл работает качественно? И вообще, что считать качеством?
В исследовании SkillsBench ребята собрали 47 тысяч уникальных скиллов – почти все без evals. В целом я этих людей понимаю: забахали скилл, вроде работает – бежим дальше. А проверка качества – это уже скучные детали. В результатах SkillsBench заранее подготовленные и отобранные скиллы дали в среднем +16,2 процентного пункта, а скиллы, которые агенты генерировали сами перед выполнением задачи, – −1,3.
Посмотрел доклад ребят из DeepMind – про evals для скиллов.
Сначала докладчик даёт общие рекомендации по скиллам:
– описание должно точно объяснять, когда, зачем и как использовать скилл – и когда не использовать
– инструкции стоит формулировать директивно, а не расплывчато, вычищать no-ops, держать SKILL.md компактным, а детали выносить в референсы. Думаю, в целом это уже всем известные приёмы
– мне понравилось замечание, что не всё стоит пытаться натянуть на скилл. Если процесс всегда состоит из одних и тех же чётких шагов, вероятно, скилл вообще не нужен – проще написать скрипт
– не все скиллы нужно вызывать автоматически. Например, скилл для ревью имеет смысл вызывать вручную
Дальше – собственно про evals.
– начать стоит 10–20 кейсов: кейсы, где скилл должен сработать, где не должен срабатывать. Если есть подтвержденные сценарии с прода, их тоже стоит включить в проверки. От себя хочу уточнить, что важно не полагаться на автогенерацию evals. Агент может помочь собрать первую версию, но в основе должны быть реальные сценарии использования, с реальными формулировками
– проверять стоит не то, вызвал ли агент скилл на первом шаге, а решил ли он задачу. В примере с Gemini API итогом был валидный код с актуальными SDK, моделью и методами. Такие условия можно проверять регулярками или скриптами, а более сложные результаты – через LLM as a judge
– каждый кейс стоит запускать в чистом окружении и повторять 3–6 раз, потому что ответы агента недетерминированы. Если в работе используются разные модели или харнессы, evals нужно прогонять на каждом из них
– одни и те же сценарии нужно прогонять со скиллом и без него. Только так можно понять, улучшает ли он результат. А заодно увидеть момент, когда модель уже справляется сама и скилл уже не нужен
#ai