Transcription
[музыка] >> Да, всем привет. Меня зовут Филип. Я из Германии. Я работаю в команде Google DeepMind, в основном над Gemini API и агентами. И сегодня мы поговорим о том, почему не стоит выпускать навыки без оценки. И, возможно, прежде чем мы начнем, мне понадобится ваша небольшая помощь. Поднимите, пожалуйста, руки, кто использует кодирующих агентов для написания кода. Ну да, надеюсь, все руки поднимутся, верно? А вы используете с ними навыки? Хорошо. Есть ли у вас оценки для этих навыков? Хорошо, да, это... не так много рук. Все используют навыки, ни у кого нет оценок. Надеюсь, мы сможем это исправить сегодня. И очень важно понять, почему проверки терпят неудачу в продакшене. И Skill Bench — это очень популярная и хорошая оценка или бенчмарк, который индексирует более 50 000 навыков из разных источников и пытается их изучить, и почти ни у одного из этих навыков не было оценок. Большинство из них были написаны ИИ, не были должным образом протестированы, и очень трудно понять, хорош ли ваш навык или плох, потому что агенты действительно недетерминированы. Так что вы можете не знать, терпит ли ваша задача неудачу из-за плохого навыка или потому, что она слишком сложна для модели. Поэтому очень важно, прежде чем мы углубимся, я хочу убедиться, что мы знаем разницу между агентами, которые мы используем, и агентами, которые мы создаем. Большинство из нас используют агентов для написания кода, для продуктивной работы. Это те агенты, которые мы используем. Это вроде Anti-gravity, Cursor, Claude code. И там вы — инженер, и у вас есть контекст о навыках, верно? Если вы напишете какой-нибудь запрос, чтобы, я не знаю, помочь мне создать новую функцию Gemini API. И если ваш агент не вызовет навык с первого раза, вы очень быстро это заметите. Вы остановите свою задачу и повторно отправите запрос или используете команды слэш для вызова этих навыков. Когда вы создаете агента внутри своего приложения для потребителей или клиентов, они понятия не имеют, что такое навык. Они не начинают свой запрос с "используй навык поддержки клиентов, чтобы помочь мне вернуть деньги" или "используй навык возврата денег, чтобы помочь мне решить мою проблему". Так что есть большая разница между агентами, которые мы используем, и тем, как мы используем навыки, и агентами, которые мы создаем, и тем, как наши клиенты могут захотеть использовать навыки в этом контексте. И что такое навык? Я имею в виду, каждый из нас надеется, что к настоящему времени знает, что такое навык. Это, по сути, папка с файлом skills.md внутри, а затем некоторые дополнительные ресурсы, чтобы этот навык действительно работал. И большая разница с навыками в том, что они работают по принципу постепенного раскрытия информации. Так что большинство навыков начинаются очень просто. У вас есть название и описание. Описание обычно является частью контекста модели. Так что модель знает, когда использовать навык. Второй уровень — у нас есть тело навыка с дополнительными инструкциями, более подробной информацией и, надеюсь, ссылками на внешние файлы. А затем вы можете действительно углубиться в эти справочные файлы, где находится весь контекст, который модели нужен для обнаружения и решения задачи. И я хотел бы различать два типа навыков. Это навыки возможностей и навыки предпочтений. Навыки возможностей учат модели тому, чего она пока не может делать последовательно. Возможно, это, я не знаю, отслеживание каких-то логов, создание нового React-приложения. И эти навыки возможностей временны. Так что чем лучше становится наша модель, тем вероятнее, что мы сможем удалить эти навыки. И оценки скажут нам, когда мы можем отказаться от навыка, а когда нет. А затем у нас есть навыки предпочтений. Они более долговечны, в основном содержат некоторые ссылки. Так что, если у вас есть определенный рабочий процесс в вашей команде или определенный стиль языка или другие предпочтения, которые очень специфичны для вашей компании, у вас будут или будут созданы навыки предпочтений, и эти навыки предпочтений затем защищены оценками, потому что большинство базовых моделей могут не интегрировать знания, которые очень специфичны для вашего варианта использования или вашей области. И навыки предпочтений очень ценны, поэтому мы действительно хотим убедиться, что они работают, и мы не обновляем наших агентов, чтобы ухудшить производительность. Так работают ли навыки? Да, они работают, и я возвращаюсь к Skills Bench, который имеет обновление 1.1, которое оценило все виды открытых и закрытых моделей в различных средах, показывая, что навыки в среднем улучшают производительность примерно на 15%. Skills Bench охватывает около 100 различных задач, основанных на кодировании, а также продуктивности на разных языках. Он открыто доступен, и у них очень хороший веб-сайт, очень хороший рейтинг, а также они очень открыты для вклада сообщества. А затем они провели второй анализ самогенерируемых или ИИ-генерируемых навыков, верно? Очень легко, если вы находитесь в кодирующем агенте и работаете над чем-то, скажите модели: "Создай навык", и тогда она напишет файл skills.md. Мы, возможно, внимательно посмотрим на него. Он примерно охватывает то, что мы хотим сделать, а затем мы просто принимаем его и начинаем использовать. И то, что я обнаружил, это то, что навыки, написанные человеком, — это лучшее, что мы можем предоставить. ИИ-генерируемые навыки могут негативно повлиять на производительность. И что навыки или файлы skills.md должны быть менее 500 строк слов. Так что, если у вас открыт ноутбук и есть доступный навык, откройте его, и если он превышает 500 строк, вам определенно стоит посмотреть на навык после нашей сессии. И последняя тема о том, что такое навык и как он работает, у нас есть разные способы вызова наших навыков, верно? У нас может быть навык, вызываемый моделью, что означает, что на основе контекста и описания модель решает использовать или прочитать навык, чтобы получить больше контекста для решения задачи. А затем есть навыки, вызываемые пользователем. И я думаю, люди недооценивают, насколько мощны навыки, вызываемые пользователем. И они чаще всего просто принимают накладные расходы, добавляя их в контекст. У меня есть много навыков, вызываемых пользователем, для задач типа рабочего процесса, таких как создание pull request, подготовка документации и вся обычная разработка, которая может быть выполнена в скрипте, скорее всего, должна быть навыком, вызываемым пользователем. И когда вы создаете агентов для клиентов, у вас нет этих навыков, вызываемых пользователем. Мы работаем только с навыками, вызываемыми моделью, и именно на этом мы сосредоточимся для небольшой секции оценки, которую мы рассмотрим чуть позже. Так что написание навыков — это важная тема. Мы рассмотрим восемь примеров того, как или советов о том, как писать хорошие навыки. И самое главное, если вы работаете с навыками, вызываемыми моделью, это описание, потому что описание — это чаще всего два предложения, которые мы предоставляем системной инструкции, чтобы помочь модели понять, когда использовать навык, а когда нет. И плохо, если ваше описание слишком слабое, потому что тогда оно может срабатывать слишком часто или не срабатывать, когда оно вам нужно. Так что очень важно — это "почему" и "как" для модели. Почему она должна использовать этот навык, а затем как она должна его использовать. Очень распространенный пример: "используйте этот навык, если вы работаете над React-приложением". А затем, конечно, "когда". И мы должны писать директивы, а не эссе. Так что мы не должны говорить что-то вроде: "Эй, API взаимодействий рекомендуется для многочатового чата, потому что он обрабатывает состояние сеанса, и именно там вы должны быть гораздо более директивными, как: используйте API взаимодействий, если вы работаете над чат-приложением". Так что вам нужно дать модели четкие инструкции и директивы о том, когда и как она должна использовать навык. И аналогично тому, что мы видели в результатах Skills Bench, мы должны держать навык легким и слоистым по информации. Так что описание — это стоимость, которую мы всегда платим при каждом вызове модели. Так что при каждом вызове модели описание является частью контекста модели. Так что вы всегда платите эту стоимость в 100-200 токенов, и вы не хотите иметь супер длинное описание, потому что тогда вам всегда придется за это платить. Когда у вас очень длинный файл skills.md, он всегда будет читаться в контекст, когда модель решит прочитать навык или использовать его, что может быть дорого. Поэтому мы хотим сделать его максимально кратким, но при этом включить все ссылки и детали, необходимые модели для решения задачи. И затем, конечно, третий уровень — это то, что у нас могут быть эти справочные файлы, куда модели нужно действительно глубоко погрузиться в очень специфическую задачу. И хороший пример этого — если вы работаете, возможно, в мультиоблачной среде, и у вас есть навык для развертывания вашего приложения, вам могут понадобиться инструкции для развертывания в AWS и для развертывания в Google Cloud. Это не должно быть частью вашего файла skills.md. Это должны быть ссылки. У вас есть ссылка на AWS, ссылка на Google Cloud, возможно, ссылка на Azure, чтобы модель могла, по сути, исследовать на основе контекста, куда ей следует обратиться, чтобы получить всю эту информацию. Затем мы должны установить правильный уровень свободы. Я вижу, как многие люди очень четко описывают точный рабочий процесс в навыке. Шаг первый, иди туда. Шаг второй, сделай это. Шаг третий, сделай это. Если у вас есть такие типы вариантов использования, вы не должны использовать навыки. Возможно, вам следует написать скрипт, потому что если процесс или рабочий процесс всегда одинаковы, вам не нужно тратить модели и токены на это упражнение. Вы можете создать скрипт. Вы можете сказать модели: "Используй этот скрипт для выполнения определенного рабочего процесса". Так что лучше определять цели и ограничения. Так что, если вам нужно, например, развернуть или подготовить вашу документацию, опишите, как модель может это сделать. Или, например, для обновления конфигурации вашей базы данных, вы не должны говорить: "Прочитай конфигурацию, обнови порт, а затем снова разверни". Модель знает, что делать. Просто скажите: "Эй, если нам нужно изменить конфигурацию, вот файл, внеси изменения". Затем не пропускайте негативные случаи. Так что мы всегда смотрим на то, когда мы хотим использовать этот навык, но чаще всего мы не смотрим на то, когда мы не хотим его использовать. Так что, если у нас есть описание для нашего навыка, которое гласит: "используйте его для задач веб-разработки", он может срабатывать слишком часто. Возможно, вы работаете с React, возможно, вы также работаете с Angular, и модель всегда загружает навык, если вы работаете в среде веб-разработки, но если вы очень специфичны, например: "используйте этот навык только для React-компонентов или для Tailwind CSS", тогда модель знает: "Эй, это очень специфично для использования". И с помощью оценок мы также можем это выявить. И затем тестируйте рано. Так что это то, на что мы посмотрим. Мы действительно должны попытаться протестировать, когда вы создаете новый навык. Всегда старайтесь создать 10-20 запросов. Мне нравится создавать пять для "счастливого пути". То есть, когда я хочу использовать этот навык? Пять, когда я не хочу его использовать, просто чтобы убедиться, что модель не срабатывает слишком часто и не запутывает себя. И затем, если у вас уже есть какие-то следы клиентов или продакшена, попробуйте включить и их, потому что нет ничего лучше, чем реальные данные. И затем совет семь, который довольно новый, и я должен отдать должное Мэтту. Так что, если вы не знаете Мэтта, он отличный ИИ-педагог, и вам определенно стоит на него подписаться. Он опубликовал твит, а также навык по "убийству" всех "no-ops". И что он обнаружил, так это то, что ИИ-генерируемые навыки, как правило, включают много "no-ops". А "no-ops" — это, по сути, инструкция, которая никак не меняет поведение агента. Это вроде как перед тем, как сделать реализацию легкой для чтения. Модель знает, когда ей нужно сделать что-то легким для чтения или написать чистый высококачественный код. Я имею в виду, это то, что мы ожидаем от модели, без того, чтобы ей об этом говорить. Так что определенно обратите внимание на эти "no-ops". У него есть очень хороший навык в его репозитории навыков. И затем, последнее, но не менее важное: знайте, когда следует отказаться от навыка. Навыки не предназначены для вечной жизни. Модели становятся лучше, поведение меняется, ожидания меняются, среда меняется. Так что всегда старайтесь запускать оценки с включенным и выключенным навыком. И если модель достигает производительности без даже вызова навыка, вы знаете, что можете отказаться от этого навыка, сэкономить затраты на токены, а также не держать его избыточным. Так что в итоге сэкономьте затраты и техническое обслуживание. И чтобы посмотреть на практический пример, а также на то, как вы можете создать свою собственную небольшую оценку или среду оценки для навыков. Ранее в этом году мы хотели создать новый навык для Gemini Interactions API. Так что Gemini Interactions API — это наш новый интерфейс для работы с моделями Gemini и агентами. И Interactions API был выпущен после последней тренировки Gemini. Так что модель или Gemini 3 и даже 3.1 или даже 3.5 не имеют контекста о том, что такое Gemini Interactions API. Поэтому мы решили: "Хорошо, давайте посмотрим на создание навыка, который поможет модели создавать хороший код для Interactions API, чтобы использовать последние модели". И для этого мы создали 117 тестовых случаев. Они основаны на данных, которые мы видим от реальных пользователей, пытающихся сгенерировать код Gemini из синтетически сгенерированных тестовых случаев, а также из отзывов, которые мы видим от людей, например: "Эй, модель использует Gemini 2.0, хотя мы уже на 3.0". И конечным результатом было то, что мы улучшили производительность до почти 90% для генерации допустимого кода Interactions API с последними моделями Gemini. И для этого нам понадобились всего два очень простых ресурса. Один из них — это JSON-файл со всеми нашими тестовыми случаями. И у него нет четкой структуры. Это вроде: "Эй, у нас есть запрос". Это, по сути, то, что мы ожидаем, что пользователь предоставит. У нас есть язык, потому что мы хотели протестировать навык на TypeScript и Python. У нас есть "должен срабатывать". Это, по сути, для того, чтобы сказать нам, должен ли агент читать навык или нет. А затем у нас есть разные ожидаемые проверки. Мы посмотрим на них немного позже. Это, по сути, очень простые утверждения для этого запроса, должен ли он срабатывать или нет. А затем у нас есть очень простой Python-скрипт, который запускает кодирующего агента. В данном случае это был Gemini CLI, который передает вывод и возвращает результат, чтобы мы могли посмотреть на исход, есть ли у нас допустимый код для Interactions API или нет. И большинство тестов или оценок для навыков могут быть основаны на регулярных выражениях. Это удивительно, насколько хорошо регулярные выражения можно писать с помощью кодирующих агентов. И для нас все сводилось к: "Хорошо, используем ли мы правильный SDK? Используем ли мы правильную модель? Используем ли мы правильные методы? Используем ли мы какие-либо устаревшие шаблоны?" И мы создали очень простые утверждения для всех этих случаев, которые очень дешевы в исполнении. Так что мы можем многократно запускать наш навык против оценок. Так что, если выходит новая модель, у нас есть простой способ обновить эти утверждения до последних идентификаторов моделей. И это очень дешево для оценки, потому что нам не нужно использовать LLM в качестве судьи. Но, конечно, вы можете использовать LLM в качестве судьи, если у вас есть более сложные навыки, которые требуют анализа всего трафика или всех предпринятых шагов. И очень простой случай — это когда вы просто создаете LLM в качестве судьи с рубрикой о том, на что вы хотите обратить внимание, а затем берете вывод, пропускаете его через LLM в качестве судьи, пытаетесь получить проход или провал, а затем, если он проваливается, смотрите на данные, а затем пытаетесь улучшить свой навык на основе этого. И именно так мы теперь оцениваем навыки в Google DeepMind. Мы не используем YAML, но это просто как пример. У нас есть тесты или оценки наряду с каждым навыком, который у нас есть внутри Google DeepMind. Каждый тест имеет несколько случаев с запросом. Мы все запускаем их в чистых рабочих пространствах, так что вы можете определить свое рабочее пространство или среду, если она должна включать дополнительные файлы, такие как среды вашего приложения. У вас есть команды запуска, которые, по сути, предварительно загружают или устанавливают библиотеки в среду. А затем у нас есть скриптовые оценки или данные. Это те регулярные выражения, где мы смотрим на весь трафик, чтобы увидеть, что сработало, была ли запущена определенная команда, был ли запущен определенный CLI. А затем у нас также есть LLM в качестве судьи, где у нас есть некоторые ожидания, которые, по сути, сравниваются с: "Сработало ли это навык, была ли запущена определенная команда bash, чтобы также оценить это". И мы запускаем их при каждом изменении навыка. Так что, если происходит изменение или дифференциал в файле навыка, оценка будет запущена, и будет результат, и изменение не будет объединено, если оно не улучшает тестовые случаи. Так что у нас всегда есть эти регрессионные тесты для каждого изменения навыка, и вы можете изменить навык только в том случае, если он улучшает оценку или добавляет новые оценки. И да, вот так мы управляем этим. И затем, последнее, но не менее важное: 10 примеров лучших практик для навыков. Вам не нужно делать фотографии, они есть в посте в блоге, который я могу поделиться позже. Так что, я имею в виду, мы проходили это много-много раз. Описание навыка очень важно. Мы видели 50% сбоев, потому что навык не был вызван должным образом, потому что запрос пользователя был недостаточно детализирован, чтобы модель поняла: "Эй, мне нужно использовать этот навык, чтобы решить эту задачу". И особенно если вы создаете агентов для других, они не знают об описаниях навыков, которые у вас есть для вашей модели и вашего навыка. Так что они могут написать что-то очень поверхностное, а затем модель должна знать: "Хорошо, мне нужно вызвать этот навык". Мы должны писать директивы вместо пассивной информации. Так что мы всегда должны думать об этом. Вы должны говорить агенту, что делать, а не что не делать, а не просто: "Эй, если ты сегодня в хорошем настроении, пожалуйста, используй навык". Включайте негативные тесты. Мы всегда забываем негативные тесты. Начинайте с малого. Даже 10-20 примеров оценки навыков лучше, чем ничего. Вы будете удивлены, сколько вы найдете даже из 5-10 примеров. И затем определенно создавайте результаты, а не пути. Мы не хотим тестировать, загружает ли модель навык на первом ходу. Мы действительно хотим протестировать, может ли она достичь задачи на основе запроса. И если она загружает навык, она загружает навык. Если нет, то нет. Если она загружает навык после пяти ходов, это тоже нормально. Затем мы хотим иметь изолированные запуски, потому что кодирующие агенты очень хороши в поиске или обмане. Так что, если вы запускаете внутри вашей существующей среды, он может искать предыдущие чаты или другие выполнения и затем пытаться обмануть и получить контекст из навыка, даже не используя его. Затем обязательно запускайте более одного испытания при проведении оценок. Как и агенты, наши модели недетерминированы. Возможно, первый работает, второй — нет. Так что всегда запускайте от двух до шести испытаний на случай и измеряйте надежность. Тестируйте на разных средах, если вы работаете с сотрудниками или людьми, работающими с разными средами, не только оценивайте против Claude или Anti-gravity. Если у вас есть люди, работающие с Cursor, попробуйте включить и их, потому что среды агентов ведут себя по-разному, и, конечно, модели ведут себя по-разному. Так что, возможно, ваш навык очень хорош с Gemini, но очень плох с Codex, а затем у вас есть клиенты, потребители, использующие вашу среду с Codex, и тогда он терпит неудачу. И затем создавайте свои оценки. Так что, если ваша модель достаточно хороша, что ей больше не нужен навык, сохраните эту оценку. Вам не нужно выбрасывать эту оценку, потому что вы выбрасываете навык. Вы можете сохранить эту оценку, чтобы убедиться, что модель или агент сохраняют производительность, и как только вы начнете видеть некоторое снижение, вы можете повторно ввести навык. Вы можете, возможно, настроить некоторые другие инструменты или части, чтобы поддерживать производительность, и затем действительно определить, когда вы можете отказаться от навыка, и вы будете очень удивлены всеми обновлениями моделей, как быстро вы можете отказаться от навыка, который вам мог понадобиться шесть месяцев назад, но не сегодня. И у меня есть домашнее задание для вас. Так что, если вы вернетесь из отпуска в понедельник, выберите самый используемый навык и напишите пять тестовых запросов. Вы также можете использовать своего кодирующего агента и попросить его посмотреть на ваши траектории, которые являются моими самыми используемыми навыками, а затем попытаться создать некоторые навыки. Вы видели, что очень легко написать свою среду оценки. Это вроде JSON или YAML файла, а затем какой-то Python-скрипт, который запускает вашего кодирующего агента или вашу среду агента, а затем смотрит на результат. Определенно попробуйте посмотреть на удаление "no-ops". Возможно, это не изменит производительность оценки, но это поможет вам сэкономить затраты, потому что все токены, которые не являются полезными или не меняют поведение агента, — это деньги, которые вы потратите. Так что посмотрите на "написание отличных навыков" от Мэтта. Вы можете найти это на GitHub, а также провести абляционные тесты. Так что всегда запускайте оценки с загруженным навыком и без загруженного навыка. Только так вы узнаете, когда вы можете отказаться от навыка или если навык действительно полезен для вашей производительности. Так что не выпускайте навыки без оценок. Спасибо. >> [аплодисменты]