Transcription
Выходные у меня такой агент поработал и, ну, ни фига себе, рост в 11 раз. Называется man on the middle. Теперь не контролирует его, а присматривает за его работой. Пруф того, что харнесы хорошо работают. А из забавного ни одну задачу хакатона я глазами не читал. Собака была вылечена. Ну, удивительная история.
Новая память агентов, то, к чему все агенты в итоге придут. Спасибо большое за внимание всем. Привет. Спасибо, что пришли. Сегодня расскажу про скилы. Я работаю в Сбере над созданием гигачата, нашей большой языковой модели. И план доклада у меня будет такой. Немножко сделаю небольшой рекап про то, как развивались агенты и как пришли к Харнесу, потому что слово Харнес я сегодня слышал, наверное, очень много-много раз. В самое ближайшее время, наверное, оно будет употребляться так часто, что скоро станет запретным. Но пока ещё нет. Я вам расскажу, потому что как будто бы не все до конца понимают, что это такое. Потом я расскажу про инструменты агентов, как они эволюционировали, как мы прошли от функций к MCP и куда идём дальше, и поделюсь своим личным опытом, а какие скилы я каждый день использую, а и что мне это даёт вместе с многими агентами. И на четвёртом этапе немножко поговорим про агентные циклы. Это следующая Захарна самитема большая, кажется, будет в двадцать седьмом году максимально популярным. И главная мысль моего сегодняшнего доклада, который я хочу донести - это то, что скилы - это не просто навыки агента. На самом деле скилы, объединённые с данными пользователя и объединённые с алгоритмами автоулучшения скилов - это новая память агентов. А то, к чему все агенты В итог в итоге придут. Ну, это то, что на самом деле я осознал, подготавливая этот доклад.
Итак, начнём с того, как же появились у нас харнесы. А, маленький рекап, как вообще развивались агенты. А, двадцать второй год, начало двадцать третьего, появляется LLM, появляется чат GPT - это просто чатовая модели. У неё можно спросить что-нибудь текстом, она текстом ответит. Исключительно чат. А это GPT3, ещё даже не чатовая модель. Чат GPT. Задаём один промпт. Нет памяти, нет никаких инструментов. А где-то в двадцать третьем году, по-моему, летом или раньше появляется концепция реакттов. Реактагенты - это чат, у которого есть возможность ответить текстом или вызвать какую-нибудь функцию. Поэтому, когда он получает задачу, он сначала вызывает одну функцию или несколько функций подряд. Это называется агентный цикл. После этого, когда он считает, что он всё сделал, то он возвращает ответ текстам. Иде очень простая. Её даже с помощью чата можно было реализовать. Вот. Но на самом деле, так я вот сюда перейду. А на самом деле очень глубоко, потому что с помощью вызова функций агент рефлексирует, он получает обратную связь от мира, вызывая функции и может поменять своё поведение. Поэтому эта тема очень вся и на самом деле она сохранилась до сих пор. Всё построено вокруг агентных циклов.
Но мир на месте не стоял. Вызовы стали объединяться в цепочки, разные роли агентов объединятся в цепочки. В этот момент появляются крупные первые агентные СДК, самые известные Lнchain, Lлаam, IndКС. Люди начинают строить что-то такое уже на агентах корпоративное. Тогда же появляются векторные базы данных, появляется такой подход, как, который позволяет агенту использовать внешние знания. Появляется в моделях JSON Structured Output, который заставляет модель отвечать уже не текстом, а какой-то структурированной информацией, которую можно с помощью компьютера, дальше с помощью алгоритмов дискретных обрабатывать. А всё это быстро разрастается, а цепочки начинают ветвельвиться и превращаются в графы. Самый известный на этот момент фреймворк - это уже Нграф, а где поведение агента может частично меняться с помощью, частично с помощью алгоритмов. А популярные мультиагентные становятся подходы. Ты агент-критик, ты агент-планировщик. Вот ты спланируй, я покритикую, а третий агент нам что-нибудь ответит. А популярные фреймворки Autто и всё это называется сфолдинг. СФoldдинг переводится как строительные леса. Мы берём LLM и обстраиваем её вокруг огромной конструкции. Зачем? Затем, чтобы повысить её возможности. то, что она может делать, наверное, это период вот двадцать четвёртый-двать пятый год, начало самых технически сложных агентов. Но потом неожиданно всё пошло по пути упрощения. Оказалось, что нам не нужен очень сложный агент для решения задачи, а можно сделать простого агента с небольшим набором функций, дать ему правильную многоступенчатую задачу, дать ему все необходимые файлы. А функции, которые мы ему даём - это просто средство для работы с этими файлами. И довольно часто он сам эту задачу решит нам. Не надо строить сложный граф, он сам к нему придёт, потому что это логично. А начинается эпоха универсальных агентов. Где-то в конце двадцать пятого года она пошла и сейчас вовсю происходит. И в общем-то Харнес - это универсальный агент. О нём чуть подробнее расскажу.
Но что же дальше? Что нас ждёт в конце двадцать шестого, двадцать седьмого? универсальных агентов, если мы хотим, чтобы они работали днями, часами, днями и неделями, их начали запихивать в ещё один уровень циклов. Внутри агента находится всё тот же Реакт цик цикл, но можно его засунуть в ещё один цикл, в котором написано: "Делай задачу". Агент делает задачу, а потом мы его перезапускаем и говорим: "Продожай делать задачу". "Продолжай делать задачу". Этот подход называется Ref loop. Также появились ещё более сложные циклы, когда мы заставляем агента действовать по шагам, но при этом периодически перезапускаться. Зачем это нужно? Затем, что это скидывает его контекст, но при этом он смотрит на наработанные результаты, и это позволяет двигаться на задачах, которые в один контекст модели не помещаются, значительно увеличить контекст. И появилось такое понятие, как Dark Factory, когда мы можем дать задачу вообще без участия человека, а система будет работать дни и недели и вернётся к нам с итоговым, а, качественным результатом. Как вот сегодня коллеги уже рассказывали, термин японский завод, который работает вообще без людей, и на нём можно даже свет не включать. В данном случае светом у нас является Human in the Loop, который смотрит за работой агента. Ну вот мы находимся в той точке, где иногда уже можно вообще не смотреть.
А также точно меняются и профессии. Думаю, все помнят, как совсем недавно все были мт- инженерами вокруг. Всё, приомт инженеринг, новая профессия, все начали это изучать, огромное количество курсов, а подбирали промты, учились правильно ставить задачу модели, но промт инженеры быстро переросли в контекст инженеров. Чем они отличаются? Если прям - это просто текстовое описание, что надо сделать, то контекст инженер уже управляет сложным промтом. Промпты разрослись, в них появились разные разделы, блоки памяти, блоки рага, описание сложных структур, которые агент должен понять и должен вернуть. Все стали контекстнженерами тоже, по-моему, году так в конце двадцать четвёртого. А сегодня все строители харнесов. Контекст уже не так важен. важен, какой у вас харнес, что вы используете, как он работает с файлами, как вы для него прописали политики и что вокруг его окружает. И самое важное, в какой песочнице он у вас крутится. А, и активно начинается разгоняться тема с лупнженерами. То есть не просто какой у тебя харнес, а как ты построил цикл своей разработки вокруг него. То есть всё меняется.
Давайте теперь чуть подробнее. Что же такое харнес? Вот, ээ, я придумал. Ну, наверное, не я, но я картинку нарисовал. А в целом Харнес переводится как упряжка или вот меня за слово упряжка критикуют, да? Упряжка. Ладно, пусть будет упряжка. Вот. Ам - это источник силы. А источник силы мы запрягаем набором инструментов. Набор инструментов - это упряжка, а поле - это наше пространство данных. И что получается? Источник силы, запряжённый в набор инструментов и этим его ограничивающий, тянет эти инструменты по пространству данных, превращая его в выполненные задачи. То есть результатом является обработанное поле ваших задач. На самом деле очень важная э картинка, потому что задачи разные, а способ их обработки одинаковый. Одна и та же упряжка, одна и та же LM теперь может решать большое количество задач. Всё просто зависит от того, что вокруг него лежит. А, то есть харнес - это определённый тип агента. Вообще изначально просто считается, ну, как бы если идти по определению, то Харнес - это агент плюс инструменты. Вот термин не суперрустоявшийся, но так сложилось, что Харнес - это агент вот с набором инструментов. Мы десятки их разобрали, а, которые сводятся вот к такому списку. Он умеет работать с файлами, он умеет читать файлы, редактировать файлы, записывать файлы и умеет выполнять башкоманды. В целом этого достаточно. Это по сути вот системный администратор, который может сделать всё, что угодно с компьютером, с виртуальной машиной. Он работает. Вот этих инструментов ему хватит, чтобы сделать всё. Дальше, конечно же, для более эффективной работы с файлами Харнес должен уметь использовать поиск по файлам, потому что файлы бывают большие, целиком их читать нельзя, поэтому он использует ГРП, часто использует webч, часто умеет ставить себе задачи и двигаться по своему туду-листу и запускать субагентов. Мы разобрали очень много openсорсных харнесов. Вот это вот среднее ядро и дальше уже, ну, кто во что горазд, добавляют в них дополнительные функции. Ну что интересно, я ещё не встречал ни одного Харнеса, у которого было бы больше 30трицати, ну, наверное, со0ка встроенных тулов, потому что на самом деле это предел современных LLM. Если мы добавим в LM 100 тулов, она хоть Fable 5, хоть кто угодно начинает в них путаться. Плюс это съедает очень много контекста, потому что каждый тул подкладывается в вызов. Мы контекст теряем с огромной скоростью. Классический примеры харинесов, это клодкод, это кодекс силай, это курсор в каком-то смысле. А на харнесах построены такие популярные решения, как Open Claw, Гермес, ну и, наверное, все агенты последнего поколения, они сейчас строятся вокруг Харнеса.
А из чего хороший Харнес состоит? Прежде всего, это некий системный промпт, систем полиси, который определяет, как он должен работать. Чем короче, тем лучше. Базовое - это используй инструменты, чтобы решить задачу пользователя. Вот это делай, вот это не делай. А второе - это набор стандартных тулов, которые я только что показывал. Это runй loop. Ц цикл, в котором работает этот харис. По сути, это эволюция того же Реактагента. У тебя есть задача, вызывай свои инструменты до тех пор, пока ты её не решишь. После этого вернись к текстовым ответом. Это управление контекстом, потому что инструменты он может вызывать много и часто. Ну, представим себе, сколько системному администратору придётся сделать чтение изменений записей файлов, чтобы решить какую-то сложную задачу. Например, там обновить операционную систему и софт на ней. Десятки, сотни, контекст у модели в какой-то момент закончится. Поэтому модель должна уметь правильно управлять своим контекстом, вовремя его суммаризировать, запускать субагентов, не вкладывая в них весь предыдущий контекст и не получая от них весь контекст на выполнения. Управление контекстом в Харнесе. Чем он лучше, тем лучше. Это очень важно. А есть некий набор джентльменских договорённостей. Какие файлы считать для Харнеса ключевые. Тоже сложилось, э, силами, наверное, антропика, силами сообщества. Ну, некий набор стандартов, что в Agence MD или в ClМ MD мы кладём основную информацию о проекте, о том, как надо с ним взаимодействовать. Скилы - это отдельные директории, внутри которых лежит скилл МДС, информацией о том, как ими пользоваться, что к Харнесу можно подключить MCP. Никто этот стандарт не стандартизировал, но по сути он просто устоялся. Ещё для Харнеса очень важно, насколько он хорошо умеет работать с различными нештатными ситуациями, с обрывами соединения, потому что он может работать часами, с какими-то ретраями, с ошибками операционной системы, с тем, что вы отключили VPN, а, и тому подобное. А, ну и какой-то у Харнеса должен быть интерфейс. Это может быть пользовательский интерфейс, в котором человек взаимодействует чате. Очень часто это консольный интерфейс, через который мы можем его запустить и просто попросить его сделать что-то или текстовый интерфейс, или, может быть, это месengджер, как у OpenCL, через который мы с ним общаемся и просто получаем готовые ответы. Ну, собственно, вот это у нас харness и получается.
Очень важно, что у большинства хороших харнесов есть два режима работы. Это интерактивный режим, в котором он постоянно общается с пользователем. Может быть, не постоянно называется Human in the middle, когда какие-то вещи он у нас всё время уточняет. Можно ли ему прочитать файл, можно ли ему сходить в в интернет. Но из того, что я вижу, все их запускают в режиме можно всё, что ты захочешь. Только задавай мне уточняющие вопросы. Называется man on the middle, то есть человек теперь не контролирует его, а присматривает за его работой. И второй режим работы, который тоже очень часто есть, по сути, в стандарт де-факто стал, это возможность запустить его с какой-нито задачи из консоли, указать её в качестве аргумента командной строки или файликом положить, и этот агент задачу будет решать до тех пор, пока не решит. Fire and forget просто вернётся к нам с решённой задачей. А такой интерфейс консольный позволяет харс встраивать в качестве бэкэнда, в качестве элемента какого-то пайплайна CCD или строить из них цепочку тоже последовательных вызовов харнесов. В общем, автоматизировать технический режим.
А почему я думаю, что все агенты сейчас будут делаться на Харнесе? Ну вот поделюсь своим опытом. За последние полгода в трёх акатонах поучаствовал популярных в России. Первый был Enterprise RX Challenge. Enterprise R Challenge. Аа я там седьмое место занял. Агент у меня ещё был без харнесов на ленграфе, но я полностью делал на харнесах уже реализацию. Сначала я сделал базовую реализацию агента с помощью clid кода, ну, условно говоря, навайп-кодил. И затем я с помощью того, что харнас можно запускать э в headдess режиме, то есть давая ему задачу, я ему поставил задачу: "А улучши моё решение, улучши мою метрику". И запустил в бесконечном цикле. Оставил на пару дней, на выходные. Ну вот в результате седьмое место и пруф того, что харнесы хорошо работают. А из забавного ни одну задачу хакатона я глазами не читал. Второй хакатон на Snowbase Camp был несколько месяцев назад. Это был первый опыт, когда я попробовал использовать Харнес в качестве бэкэнда. Агент был полностью построен на, по-моему, утечке на тот момент клодкода. То есть на Харнесе клоне Клодкода. Вокруг него был красивый фронт. Заняли с командой третье место в общем зачёте и первое место по техническим метрикам. Тогда я понял, да, что агенты, которые используют Харнес в качестве бэкэнда, в ситуации, когда задача плохо, понятно заранее, потому что мы толком не знали, на чём на будут тестировать. Отличный вариант. Ну и третий пример, э, недавний hкаaton bitn. Там не так удачно я выступил, вошёл, по-моему, в двадцатку решений, но обнаружил там крайне интересный инсайт. Я посмотрел всех топ-20 людей, и 19, по-моему, команд из них делали своё решение, свой бэкэнд уже на харнесах. Из чего стало понятно, ну, что все разработчики, которые как минимум участвуют в интересных хакатонах, уже в курсе и смотрят в эту сторону. А вывод, да, агенты на харнесах - это мах.
Рекап про карнесы закончился. Поговорим об инструментах агентов. Тоже немножко истории. Сначала у агентов были тулы, были библиотеки этих тулов. Это началось, наверное, с Лангчейна тоже и лама индекса двадцать второй тире двадцать четвёртый год. М, что такое Тул? Это инструмент, который доступен модели, чтобы она его вызвала, и он каждый раз попадает в контекст. А были библиотеки тулов для подключения гита, для подключения, ну, для подключения каких угодно внешних сервисов. Проблема была в том, что их надо было каждый раз адаптировать или вообще писать самому, как это иногда выглядело. Писали какую-то функцию, к примеру, на Питоне, помечали её специальным тегом, она превращалась в функцию, которая подкладывалась вызов модели. Модель могла её вызвать. А че конец двадцать четвёртого года, начало двадцать пятого, компания Anтропик представляет концепцию MCP. MCP Tool, MCP сервер. Это вещь, которая может быть загружена по интернету или из там какого-то стандартного файлика в виде MCP-сервера локально развёрнутого и подключена напрямую к агенту. При подключении к агенту к нему добавляется несколько готовых тулов. Очень популярны стали маркетплейсы MCP серверов. Все вокруг начали их делать. Многие MCP сервера содержали десятки тулов. Можно несколько MCP серверов было подключить к одному агенту. В итоге у нас получался агент, у которого м больше 100 функций. Со страшной скоростью отъедался контекст. Вот. Плюс, ну, есть некие проблемы с безопасностью, особенно если я MCP-сервер получаю по сети из какого-то внешнего источника. Источник может поменяться. Поведение моего агента также может поменяться. А не буду хейтить MCP, потому что сегодня все эти проблемы уже решены. И на самом деле MCP имеет право на жизнь, но популярность в этот момент с двадцать пятого года и по сейчас начали обретать скилы. А скилы - это тоже способ дать агенту инструменты, но они очень легковестные. То есть скилл - это директория и джентльменское соглашение. Что информацию о том, как работает этот скилл, я храню в skillлм. Эн инструменты, которые нужны для работы моего скила, хранятся в виде баш, скриптов, Python кода в той же директории. Я просто эту директорию копирую к своему агенту. Он сам в неё заходит, смотрит, что там есть, и пользуется. Сейчас чуть подробнее расскажу, как это работает. Для нас самое главное, что это супердёшево создавать, да, для того, чтобы создать свой MCP-сервер. Ну, в общем, надо быть разработчиком. Для того, чтобы создать свой скилл, надо просто уметь писать тексты, можно даже не на английском языке. И их очень легко распространять. Там хоть через мессенengжер кидай, хоть на GitHub выкладывай, куда угодно. Ну, тоже времени не стоит на месте. И, а-э, сегодня хочу как бы немножко поправитствовать и сказать, куда всё это дальше пойдёт. Вот, мне кажется, следующий подход будет, который очень популярный, я им поделюсь, надеюсь, станет популярным, это скилы внутри гит репозиториев, объединённых с данными, потому что скилл сегодня хранит в себе информацию о том, как работать, как вызывать инструменты. Если его ещё снабдить, а с данными, над которыми он это будет вызывать, это несёт в себе, на мой взгляд, очень большие профиты. А покажу на своих примерах.
Итак, из чего состоит классический скилл? Одна из самых главных идей, которая была в скиле, у него двухэтапное описание. В чём была проблемалов и MCP серверов? Что описание функции, которую мы подключаем к агенту, оно может быть очень большим. Вот я работаю в Сбере, и как-то я посмотрел, как выглядит функция для блокировки карты. Вот не учебная, где мы пишем: "Вызвиту этот тул для блокировки карты", а настоящее. В ней приходится описывать бизнес-логику, которую пишет человек, который, ну, реально погружен в эту тему. Вот в каком случае надо блокировать карту, в каком нет. А, четыре страницы мелкого текста А4 она занимает. А теперь представим, что таких тулов у там банковского агента десятки. Один-два запроса, и мы полностью забиваем этот этим контекст. Для того, чтобы с этим побороться, у скила двухэтапная загрузка. У него есть короткое описание, и только оно попадает в систмпромт агента. Ну или подгружается в процессе, только его он видит. И есть длинное описание подробное о том, как пользоваться этим скилом, но оно не попадает у нас в запрос, в контекст модели ровно до того момента, как агент не решит, что ему нужно этим скилом воспользоваться. Тогда он зайдёт в директорию со скилом, прочтёт этот файлик, может быть, даже не целиком. Это будет зависеть от Харнеса, это решение уже самого агента и начнёт двигаться по этому скилу. Таким образом, у агента инструментов может быть намного больше. Вот я недавно устанавливал Хермес, и у текущей его версии было 56 скилов из коробки. Ну, после того, как я с ним пару недель поработал, их стало 100. При этом он прекрасно работает, контекста ему хватает. Если бы это были не скилы, а тулы, то, ну да, два запроса и контекст бы у него закончился. Ну и третье, то, о чём я говорил, внутри скила находятся инструменты. То есть, если это блокировка карты, то там находится описание, как нужно карту блокировать. Плюс может режать скриптик для того, чтобы конкретную карту заблокировать. Скриптик для того, чтобы узнать статус конкретной карты, если это нужно для самого скила. А если сравнивать на сегодняшний день скилы и MCP, и тут я говорю про классический MCP, то, ну, я бы такую рекомендацию дал. Если в вашем агенте вы не знаете, какую задачу он будет решать каждый следующий раз, или если он решает разные задачи, и для решения разных задач нужны абсолютно разные инструменты, то есть часто инструментов при части сценариев не используется. Или если у вас количество тулов больше птися, то лучше использовать скилы. Если агент решает однотипную задачу, в него идёт поток этих задач, и для почти каждой задачи нужно вызывать один и тот же набор инструментов. Инструментов немного, агент узкоспециализированный, меньше пдесяти, тогда стоит использовать MCP. И маленькая оговорка, грань начала стираться. Некоторые харнесы, например, а клод используют MCP не напрямую, а они как бы превращают их в скилы. Они вокруг MCP создают тоже файлик, подкладывают его сразу функции в контекст не попадают. И тогда он фактически MCP работает в режиме скила, его минусы во многом исчезают. Поэтому я говорю к хейтерам MCP себя причислять не хочу. Да.
И вот ещё раз, из чего состоит скил? Короткое описание, а, большое описание, инструменты, которыми он пользуется, и как будто здесь чего-то не хватает, да, как будто у нас архитектура фонеймана, а, код есть, а данных нету. Моё предложение также добавлять данную, история развития скила и все его артефакты прямо в сам скилл. И тогда он раскрывается, да? Вот короткое описание, длинное описание, инструменты и ещё у нас добавляются данные. А всё это удобно в виде гит репозитория хранить. Почему? Сейчас расскажу. Потому что когда мы храним его в виде гит репозитория, мы можем подключить к одному скилу, то есть у нас получается такая skillф архитектура несколько разных агентов. М это оказалось очень удобно. Например, когда мне нужно сделать какую-то большую работу, я беру клод-код или курсор, открываю там этот скилл с его данными и могу поработать. А могу сделать над данными какую-то операцию, которая требует правок в большом количестве файлов. Затем я, например, закончил работу, поехал домой, у меня к тому же скилу может быть подключён Гермес, Open Claw. Я в Телеграме ему пишу: "А ещё сделай вот это". Или там о чём мы сегодня говорили, какие там были данные? Он в тот же в тот же самый репозитарий сходит, данные вытащит и мне прямо в Telegram, в мессенджер ответит. Также такой подход, такие скилы очень удобно встраивать в ICD и пайплайны. Они точно также в гитрепозитарии сделают то, что нужно. А, и самое главное, можно поделиться таким скилом с коллегами, можно организовать совместную работу. А тут, кстати, даже очень интересное отступление у меня появилось. Войти всю дорогу борться с коллизиями. Аэ, вот там базы данных, вторая, третья нормальная форма, а транзакционные модели данных. Мы всю дорогу боролись с коллизиями, чтобы не случилось такой ситуации, при которой, а, несколько разных акторов поменяли одни и те же данные, и мы не знаем, что с ними делать. А проблему коллизия отлично решает гит. Но раньше для того, чтобы в гите решить конфликт, обычно нужен был человек. Некоторые конфликты вручную неруша не решаются, и всё. Стоп, у нас смерч конфликт, мы зовём человека. Современной модели на харинесах конфликты научились решать, и из-за этого мы во многом тушим проблему коллизий. И теперь можно системы, где много параллельно людей работают над одним и тем же, строить просто на гите. Конечно, не везде, да, транзакционную там систему платежей на этом не построить, но вот подумайте об этом. Многие вещи можно пересмотреть в сторону более простых решений. А главное при создании такого скила в MD приписать жёсткое правило, что всегда, когда ты начинаешь работать, ты делаешь getpol вытаскиваешь последние данные, как ты их меняешь и сразу после работы делаешь push и комит. И ещё очень хороший совет - это использовать в таких системах C, а ещё его называют бэкпреш, обратное давление, то, что будет запихивать в правила скила то, что он генерил агент. Потому что когда агенты бесконтрольно работают, м они всегда стремятся расползтись, придумать себе какую-нибудь новую задачу, сделать то, чего не было описано в MD. Если это долго происходит, такие изменения накапливаются и да, агент расползается. Наличие C, которые обязательно в Egen о ага, в MD прописан. А, но оно помогает этого избежать частично.
А вот хочу поделиться теми скилами, которые я пользуюсь каждый день. Некоторые из них поподробнее раскрыть. Самый прикольный, наверное, это скилл по работе с ДНК и медициной. Вот сейчас про него будет поподробнее. Ещё у меня есть скилл для рекомендаций фильмов, музыки, игр, которые я собрал на основе того, а какие оценки я в своё время ставил на кинонавигаторе бывший МХАТ. Они, спасибо ребятам, э дали это выгрузить. У меня там, наверное, около тысячи фильмов было размечено. И вот объём данных с из которого можно извлечь.
информацию о моём увлечении. Что с ними делать? Я их завернул в скилл. Теперь у агента всегда могу спросить: "А вот этот фильм мне понравится? А что из новенького посоветуешь?"
Очень удачный скилл получился — планирование поездок и командировок. А есть скилл для работы по линии HR. Мне довольно часто в личку присылают резюме, спрашивают: "А вы нанимаете?" А мы нанимаем. В какой-то момент оценивал их сам, потом их стало слишком много. Сделал скилл для оценки резюме, расскажу о нём.
Скилл для управления финансами, мониторинга всяких платежей. Сдал ли я показания на воду, а кто кому что сколько должен. И есть рабочие скилы у нас в команде тоже используем для ведения R&D активности по исследованию агентов.
Скилл, с которым работает много людей. Одновременно можно ему кидать задачи, и он будет накапливать историю, что нужно оценить, что уже оценили и как.
А давайте про ДНК стел немножко расскажу. Он мне прямо очень нравится. История такая. Когда-то давно я сдал генетический тест, не помню, Атлас илик. Они присылают такой отчётик, в котором написано: "Какая у тебя национальность, какие у тебя основные признаки". Ну, один раз прикольно. Потом я туда ещё раз зашёл, ещё раз зашёл и увидел, что этот отчётик ещё и всё время меняется. Думаю, ну, ерунда какая-то. Вот.
Э попробовал сам поанализировать те данные, которые они отдают. Прикольно. Поразбирался немножко в генетике, поставил себе какой-то генетический софт. Ну, в общем, забросил. Сложно. Я как бы не генетик. Но сейчас, когда во вкус на всё равно тогда вошёл, я сдал, супруга сдала этот тест, э, дети сдали. Почему мне это было интересно? Потому что я разработчик, а разработчику всегда интересно покопаться в исходниках, а тут фига себе можно покопаться в своих собственных исходниках. Ну, прямо жалко, дебагр не приложили. А, поэтому сдали не только ДНК тесты, но и ДНК секвенирование. Огромный объём информации на выходе, около 100 Гб прочитанного ДНК. Причём там рандомные кусочки. Какая-то часть прочтена восемь раз, какая-то часть причтена один раз. Не очень понятно, как их совместить. Всё это я засунул в директорию, вокруг которой создал скилл. Вот это тот момент как раз, когда инструменты и данные объединяются.
Также по каждому человеку сделал, ну, сделал шаблон типа "исследуемый человек". Там обязательные параметры: пол, возраст, вес, какие-то информация про него, какие-то особенности, может быть, какие лекарства он принимает. Всё вот это сложено в набор людей. А какие вопросы можно задать? Ну, да, я скормил это, естественно, самой мощной модели OPС 4.8. И оказалось, что она выдаёт очень классные инсайды, и можно задавать вопросы про себя. Например, какие лекарства на меня лучше действуют, какие хуже. Оказалось, что там довольно интересно. У разных людей разное количество рецепторов к разным, а, к разным лекарствам, поэтому на кого-то что-то не действует, на кого-то что-то действует очень эффективно. Можно спрашивать, какие, к примеру, виды спорта мне больше подходят, какие меньше, какой стиль обучения мне подходит.
Когда я это показал друзьям и коллегам, некоторые из них взяли и поделились со мной тоже своими ДНКанализами. Мы придумали такое классное развлечение. Берёшь два ДНК, просишь э клод их сравнить, и он может сказать, кто из людей, например, более общительный, кто более усидчивый. Ну, как бы всё совпадает. Звучит немножко как слоб, но на самом деле всё довольно глубоко. Вот что меня больше всего впечатлило. Стогигабайтные исходники ДНК. Я отдал их к лоду. И что с этими нужно делать? Там отдельные кусочки ДНК разбросанные случайным образом. Нужно свести их в единую цепочку. То есть получить тот исходник, собственно, в который уже можно смотреть единую цепь плюс уровень качества её оценить. Работа, ну, для меня, когда я первый раз с этим разбирался, была на неделю. Плюс надо скачать референсный геном человека и совместить, насколько ты в каких местах отличаешься от дефолтового человека, собранного в проекте Human Gно. А система вот за сутки это сделала.
Тут, э, сейчас маленькую историю расскажу, а пока покажу. Вот я у кода Клода попросил на образе, на основе моей ДНК составить дашборд, как будто я герой компьютерной игры, как бы у меня выглядело распределение моих, э, характеристик, какие у меня есть перки, какие есть дебафы. А, а история такая. Я с чего понимаю, что оно мелкое, не предлагаю к этому серьёзно относиться, но всё это я писал подробно у себя в Telegram-канале. Если кому интересно, можно про это и почитать, и открыть эту страничку. А история следующая. У каждого из нас есть около вообще, ну, почему я вот погрузился, около 100 уникальных мутаций, которые происходят при копировании ДНК. А эти мутации, они прямо новые. Вообще они не описаны в науке обычно, да. Ну, некоторые самые такие типовые описаны, а большинство нет. Мы ничего про них не знаем. Из них считается, что 10 полезные, 10 вредные, остальные 80 в среднем ничего не значащие. А что можно с этим делать? Ну вот я свой ДНК сравниваю с референсным геномом человека. Вот есть мутация, про которую ничего неизвестно. Я попросил у Клода проанализировать, а вот что мы про неё можем сказать. Очень легко про такую мутацию найти, например, к какому гену она относится или, может быть, к ни какому, тогда она, скорее всего, неважная. Но дальше вопрос тяжёлый: на что она, собственно, влияет, как она, она вредная или полезная? И тут меня поразило. Он обратился, он посмотрел, нашёл, что эта мутация нигде не описана, обратился к гугловской системе Alльpha Fold. Это и, который умеет рендерить, э, как сворачиваются белки. Он сказал: "Да, это я вижу, что это относится к такому-то белку, но сломанный он в результате этой мутации или нет, я не знаю". Пошёл в Альфафолт, отрендерил, по сути, мой белок, посмотрел, как он сворачивается, и на выходе мне сказал: "Да, этот белок сворачивается корректно, можешь не волноваться, это твоя мутация, ничего не значит. Ты молодец". Круто.
Почему я вообще считаю, что это не какой-то нейрослоп? Потому что, ну, казалось бы, да, звучит ужасно, но оно работает. Во-первых, довольно много сейчас появляется всяких громких историй о том, как люди использовали и для личной медицины. Одна из историй была опубликована в блогей. Один из пользователей Редита всю жизнь страдал болми в спине, не мог никак разобраться, что же у него происходит. И тогда тоже он загрузил все свои данные в чат GPT, загрузил свою картину MRI МРТ, попросил найти, а, неочевидные взаимосвязи, и чат GPT ему нашёл сложную взаимосвязь с каким-то недостатком витамина B12. Человек, который всю жизнь искал проблему со своей спиной, пошёл ко врачу, и эта проблема подтвердилась. Ну, поскольку это в блогей запостили, ну, некое доверие к этой истории есть.
Вторая, более известная история. Пол Конингем. У него пёс заболел раком. От рака собак никто не лечит, потому что и людей не успеваю. Тем не менее, он взял чат GPT, взял тот самый Альфафолт и целиком полностью сам с нуля разработал МРНК в акции. Ну, то есть это индивидуальная вакцина против конкретного рака. Заказал печать этой вакцины у какой-то лаборатории, вколол её собаки, собака была вылечена. Ну, удивительная история с помощью Ии.
А заодно я для того, чтобы проверить, что всё это работает и что лаборатории генетические нас не дурят, э, у меня по некоторым людям были несколько разных ДНК, например, из атласа и генотека и секвенированные. Теперь я могу взять их и свести. Я могу сравнить, вот этот анализ и с этим — это вообще один и тот же человек или нет. Ну, вот я проверил, у меня получилось 99-95% точности. Очень хороший показатель. А лаборатория меня не надурила.
Ну и так, чтобы осознать масштаб изменений. Э геном человека 3 млрд долларов, 13 лет заняло для того, чтобы собрать референсный. Сегодня свой полный геном можно, ну, за какие-то небольшие деньги, скажу, 1.000 долларов и один вечер работы ноутбука и клода точно также получить и покопаться в своих исходниках, если вы биохакер.
Второй кейс по проще, не такой хардкод — это планирование поездок. У меня много командировок, я создал скилл, в нём есть шаблон командировки, есть описание людей, которые теоретически могут со мной поехать. Есть их все документы, поэтому я могу агента, которому подключён этот скилл, например, попросить зайти на сайт и заполнить. Вот недавно он мне заявление на визу заполнил практически без ошибок. А и как это выглядит? Я, если знаю, что мне предстоит какая-то большая поездка. Я открываю курсор, прошу его, а, а, прошу его создать мне поездку, с ней работаю. О'кей, поездка создана, но, например, не куплены ещё билеты, не куплена гостиница. А потом беру клод-код, который под клодкод как это называется? Гермес, да, который подключен к тому же скилу. Пишу ему в Telegram: "О, я купил билет". И кидаю прямо в него. Он заходит в этот скил, обновляет его из гита, вписывает туда билеты, добавляет пдфку в эту же директорию, в папочку, которая ассоциирована с этой поездкой. И так у меня расширяется набор знаний об этой поездке. В любой момент я его могу спросить: "А вот там у меня планируется поездка, не знаю, в Китай, мне по ней что осталось?" Он говорит: "У тебя ещё гостиница не забронирована". Или я ему могу спросить: "А вот это я успею посмотреть?" Он говорит: "Нет, у тебя там разница между самолётами 2 часа, даже не пытайся".
Ещё один кейс, о котором я чуть-чуть уже начал говорить, HR pйплай. Он вообще возник стихийно. Я кинул Гермесу резюме, которое мне скинули в телегу, и говорю: "Оцени". Он как-то оценил. Естественно, вообще нерелевантно, но при этом ему ещё пришлось попариться с тем, чтобы оно было без текстового слоя. Чисто картинка. Он подтянул Оси. Да, сразу оговорюсь, Сбере этим мы не пользуемся. Закон о защите персональных данных всё соблюдаем. Ну, когда мне в Telegram присылает человек сам резюме, ну, тут как бы имею моральное право его обработать. Вот. А закинул, э, он его обработал, дал фидбэк и создал скилл. Дальше этот скилл скорректировал. Говорю: "Когда я тебе кидаю резюме, обязательно через этот скилл его пригоняй". И так было 10 или 20 итераций. Я ему кидал людей, он их как-то обрабатывал, и я ему давал фидбэк. Например, он мне говорит: "Тебе стоит позвать этого человека на собеседование". А я читаю резюме. Человек готов только к полной удалёнке, а у нас гибрид. Говорю: "Нет, таких людей не рассматриваем. У нас только гибрид". Или, к примеру, вижу, что у человека есть GitHub указан. Я говорю: "Обязательно, когда у человека есть GitHub, а то в него заходи и анализируй, какой у него там выложен код, какой он делает, например, импакт в Open source. Если делает там, ну, мне это нравится. Если не делает, ничего не могу сказать". Итак, 10-20 итераций. На каждый из них этот скилл сам улучшался. Это механизм Гермеса. О нём тоже сейчас расскажу. Мне он кажется максимально полезным. На выходе я получил идеальный HR skill. Кидаешь резюме, получаешь ответ и соглашаешься. Если потом смотришь его глазами, ну, до ошибок там 10%.
А что вообще происходит с агентами, скилами? Вот, на мой взгляд, революция харнесов началась с появлением клодкода. Потом завершился Open Claw, сейчас завершился Гермес. И почему нам Гермес здесь очень интересен? Потому что он фактически построен полностью вокруг скилов. Он не только их использует, но он их активно создаёт. И у него есть цикл самоулучшение этих скилов. Вообще у него много всего есть для скилов. Он их правильно умеет форматировать по классике. Он их умеет автоматически создавать. Критериям создания скила у него, кстати, является, если на какую-то задачу он потратил больше пяти тулколов, он сразу рассматривает, не стоит ли мне это запомнить как скилл. Ими, понятно, можно управлять, создавать, удалять через текст, через консольку. Есть хаб со скилами, куда сообщество накидывает их огромное количество. Кстати, не так, чтобы, я вижу, чтобы им пользовались, все сами создают. И у него, самое главное, есть механизм куратора. А это очень важно. Это механизм, который эти скилы постоянно улучшает. В нём есть два слоя важных. Один слой — это прунинг. То есть он отрезает те скилы, которые не используются. Если какой-то скилл не использовался 30 дней, он его, ну, по сути, он его делает как бы неактивным, что система, он всё ещё в системе, но он не подкладывается каждый раз в запрос или подкладывается какая-то уменьшенная версия его дескрипшена. Если скилл не используется 90 дней, он его архивирует, скилл вообще исчезает. И второй слой работы куратора — это консолидация. Она запускается раз в 7 дней. А если у нас много мелких скилов, он подробно анализирует, можно ли какие-то мелкие скилы попарно объединить в более крупный скилл. Это не раздувает систему, не делает так, чтобы этих скилов стало тысяча и даже их короткие описания, а в итоге отъедали весь контекст. И за счёт этого получается, что скины скилы постоянно эволюционируют, а если они у нас ещё и с данными, то как бы становится основой этой системы.
И вот, собственно, главная самая мысль, которую мне бы хотелось рассказать э в своём докладе и вот который я подвожу, что если у нас есть скилл, он насыщен данными. Если мы периодически эти скилы улучшаем, обслуживаем, удаляем лишнее и развиваем, то это превращается в новую память агента. Раньше мы делали память на поиски в переписках, на рагах, на извлечении какой-то информации о человеке. Ну, по сути, вот она, вся информация о нас, у нас лежит в скиле, и она подтягивается ровно в тот момент, когда скилл активируется. А у самого агента, у Харнеса есть возможность с этой информацией работать, загружать то, что ему нужно, не загружать то, что ему не нужно. То есть он сам решает, что попадёт в контекст, а не какой-то рак до того, как модель начала работать и решает за него. Вот это, мне кажется, главная мысль по тому, куда идут скилы.
А, в общем-то, хотел на этом закончить, но не могу затрёнуть ещё одну очень маленькую тему, потому что я занимаюсь много агентами, мы их исследуем. И агентные циклы — это то, что прямо сейчас стреляет. Буквально вот три слайдика, куда всё идёт. Аа первое поколение циклов, я о нём говорил — это Реактагенты, которые превратились в харнесы. Это цикл выполнения задач, которые работает до тех пор, пока задача агент не решит вашу задачу. И это называется innerloop, вложный цикл. Вокруг них такой человек, как Джеффри Хантли, придумал строить внешний цикл, просто засунуть Харнес в бесконечный цикл while отрышай мою задачу. Этот подход называется. Он очень интересный. Он позволяет агенту работать днями и неделями. А он придумал несколько хитростей для того, чтобы это не превращалось в слоп. А, например, то, о чём я сегодня уже говорил, бэкпреше — это обратное давление, это CICD вокруг агента, чтобы он его возвращал, если агент начинает слетать с катушек. Ну и ещё валидация качества кода. А почему эта штука работает? Почему она важна? Потому что она позволяет действовать с без ориентации на рост контекста. Чем дольше работает агент, тем больше он съедает контекстов. В какой-то момент контекст заканчивается, его надо суммаризировать. На сумморизирование мы теряем данные. А это проблема. Агент тупеет. Кто вот пользуется, например, OpenClow видели? Сегодня он мои задачи решает, а завтра я ту же самую задачу ему даю, а он как будто поглупел, забыл, о чём мы вчера говорили. Вот это произошла суммаризация контекста. Ещё у модели есть смартзона. Это где-то, наверное, первая треть контекста, когда она проявляет свои самые, ну, максимальную свою умность. Даже если мы за неё выходим, казалось бы, у нас модель с миллионным контекстом, но она уже начинает глупеть. Вот такой подход без раздувания контекста позволяет постоянно при решении задачи удерживаться в этой смарт-зоне.
И третий уровень, честно говоря, его сам придумал, но я думаю, что он тоже, а, наберёт популярность, даже если мы бесконечно гоняем агента в бесконечном цикле. Вот Анджей Карпатый подсветил такую вещь: схлапывание. А если мы даём модели одну и ту же задачу постоянно, она может её, а, как будто бы решать разными способами, но на самом деле это всё один и тот же способ, сказанный разными словами. Он это приводил на примере анекдота. Попросите модель рассказать анекдот, потом ещё один, потом ещё один, и на пятый раз вы увидите, что это тот же самый анекдот, просто в нём померено место действия и действующие лица. А идея то же самое. Как бороться с этим схлапыванием? Идея такая, что мы в какой-то момент останавливаем полностью выполнение цикла и запускаем его с полного нуля, вообще зачистив все данные, которые он создал. Данные можно взять и положить в архив. Он их изначально не видит и начинает идти каким-то другим путём. Через какое-то время он находит этот архив, распаковывает его и обнаруживает в нём все свои данные, но он уже пошёл в другую сторону. Это позволяет исследовать задачу в разных направлениях. Этот подход очень хорош, когда вам нужно что-то исследовать, когда вы сами до конца не понимаете, какую задачу вы решаете, когда нужно прокопать со всех возможных сторон. И таким образом получаются три уровня циклов у меня. Вот здесь пример того, как устроен. Ну, это самый простой пример, но он объединяет в себе всё. А вот здесь мы запускаем клод с пара с командой реши задачу. Он, кстати, забыл здесь, по-моему, N надо ему ещё задать. Это тот самый inner loop. Clетчу в цикле, пока её не решит. И сам этот вызов находится внутри бесконечного цикла. Это loop. Вот. А металуOP он в коде уже не получится. Тут могу просто порекламировать свой доклад, где я эту тему более подробно разбираю на Ютюбе. Если интересно, посмотрите, вот так они вложены. То есть есть Harness innerloop, Realf Loop вокруг него и MetalOP — это ещё один, э, цикл вокруг Ральфлупа.
На этом, наверное, всё. А, спасибо большое за внимание. Не удержусь, порекламирую свой Telegram-канал и поотвечаю на вопросы. Да, спасибо большое, Константин, за такой интересный и подробный доклад многосоставной. Да, сейчас у нас вопросы. А, пожалуйста.
>> Да, Константин, спасибо большое за доклад. Невероятно интересно. Вопрос двухсоставной. Первый. Можешь ли ты уже сказать, что система скилов и вообще работа агентов со скилами — это некий фундаментальный принцип или есть вероятность, что что-то снова поменяется революционно? И второй, вторая часть вопроса, на какие вообще фундаментальные знания разработчиков, которых вы нанимаете, вы сейчас смотрите, есть ли у нас всё агенты, циклы и тому подобное.
>> Спасибо за вопрос. А про фундаментальность я бы точно не стал говорить. Я вот с самого начала этой л движухи ничего фундаментального нету. Раз полгода всё меняется стабильно. А корпорации от этого сильно страдают. Только вроде бы утвердили MCP на архитектурном комитете, а уже никто не хочет на MCP. Все хотят AA. Утвердили ATA, опять всё поменялось. Поэтому, ну, вот я лично смотрю, у нас такая команда больше RНD. Я смотрю на широкий технический кругозор и автономность. То есть, если человек фстек, если он может сам найти задачу, сам прокопать, сам её решить, он нам подходит. А какие-то знания, ну, доберёт в процессе, да, фундаментальных знаний. Ну, круто, если есть фундаментальные знания в математике, в устройстве, э, обучения. Всегда круто, но это не прямо не стоп-фактор.
>> Следующий вопрос. Да. А кто по каким принципам? Да, спасибо за доклад. По каким принципам и кто решает, какие данные а достойны того, чтобы их увековечить в одной репе со скилом?
>> А я думаю, что никаких каких-то стандартных правил, как это, пока нет. Рынок покажет. Сейчас только интуиция и вристика использования. Строить, строить, строить скилы, видеть то, что заработало, то, что нет. Ну, сложный вопрос. Я пока по интуити.
>> применить к геному, например, всё складывать, вообще все геномы всех людей класть в репу со скилом.
>> А я бы так сказал, харинесы довольно умные, в этом их большой плюс, что насыщая данными скил, мы его не убиваем, в отличие от рагов, в отличие от классических промтов. То есть, да, мы можем позволить себе положить довольно много данных. Ну, конкретно у меня в геномном скиле там 200 ГБ данных лежит, а в скиле по моим поездкам 100 Кб данных. Вот. И как бы и тот, и тот работает хорошо.
>> Спасибо.
>> То есть потолок сверху ещё не нащупал.
>> Ещё вопросы?
>> Константин, спасибо за доклад. Один вопрос, может быть, продолжение, которого уже задали. Ну, концептуально получается, что у нас же все нейронная сеть состоит из нескольких частей. Ну, первая была статистическая. Все поняли, что она работает не очень хорошо. К ней нужно было добавить тулзы. Добавили тулзы, скилы. Появилась вторая часть, которая больше уже такая классический алгоритм. Добавили данные третьей части и четвёртая получается то, что вот вы сейчас презентовали в самом конце. Само улучшение. Ну и получается, что концептуально-то больше ничего к нейронке не добавишь. Или на на мой взгляд есть что-то ещё, что можно добавить?
>> Мне бы очень хотелось, чтобы у неё расширялось а восприятие мира. А, очень много шуток есть про эти про нейронки, когда, например, я говорю м какая там была последняя шутка, что мне до автомойки 5 минут ехать или 10 минут идти пешком. Как ты советуешь мне туда добираться, чтобы помыть машину? Она говорит: "Ну, пешочком сходи, что, всего 5 минут". Как бы, ну, глупость, да. Что мне там без машины делать? Вот когда много общаешься с нейками, чувствуется, что у неё нету кваля. Вот мне бы хотелось, чтобы это появилось, но как это сделать? Вопрос сложный. Возможно, модели мира нам здесь помогут. Следующий вопрос.
>> Да, >> раз-раз. Да, спасибо большое за доклад. Козрыв Илия, компания Рафт. Слушай, а приведи примеры, где вот скилы с данными в цикле разработки именно тебе буст дают. То есть либо тебе, либо твоей команде, где их можно в разработке использовать. А у меня есть очень один хороший скилл, где это хорошо сработало по улучшению агентов. Вот. А данные — это бенчмарк, который я хочу улучшить, и, собственно, код агента. И я говорю системе, вот у меня есть агент, и он проходит этот бенчмарк на, ну, в моём случае он там решал одну из 89 задач Таунча, по-моему, было обидно. Тестировали гигачат какой-то ранней модели слабенький. Я ему говорил: "Улучшим". И он начал в цикле бесконечно сам этот скилл вызывать, обнаруживать ошибки, их исправлять. Эту идею тоже у Карпатова я подсмотрел. У него автоент назывался, а, репозитарий. Он выдвигает гипотезу. Если гипотеза хорошая, перемеряет с ней бенчмарк. Она хорошая, он улучшает. Она плохая, он откатывает. И в итоге так идёт итеративно. Выходные у меня такой агент поработал и выбил уже 11 задач из 89. Ну, ни фига себе, рост в 11 раз. Я посмотрел, что он сделал. сделал всё адекватно, нигде не зауверфитился. Ну, отличный пример. Тоже об этом в одном из докладов недавно рассказывал. Прямо зашло.
>> Спасибо большое. К сожалению, на этом у нас время подходит к концу. Ah.