Transcription
М, всем привет. А мы потихоньку начинаем. А пока давайте немного познакомимся, подождём ещё опаздывающих. А напишите пока в чатике, слышно ли нас, видно, и давайте потихоньку знакомиться. А расскажите, что вас привело вообще к нам сюда, как вы используете AI, кем работаете? А мы пока минутку с вами пообщаемся и стартанём.
Так, слышно, видно, всё ок. Перил или стартапы? >> А что за стартапы? Так, ну ладно, ещё минуточку подождём, хотя бы до сотни добел. Так, аро подтягивается. Маркетинги креативы пишут агенты work. Так, реклама пошла. А, привет, Сбер. Привет, Денис.
Так, ну что, 35 минут, думаю, можем потихоньку начинать. А, всем привет. Меня зовут Фёдор Азаров. Я работаю в Сбере в Global Markets. А, пилю торговые стратегии Сяй под капотом. В свободное время люблю тоже пилить агентов и участвовать в различных соревнованиях. Так, также с нами сегодня Андрей Киселёв. Андрей, расскажи, пожалуйста, себя.
>> Да, всем привет, рад всех видеть. Меня Андрей зовут. Я последние два года работал в Revлют. Это такой, если кто не знает, наверное, самый большой цифровой банк в Европе. И сейчас я ушёл из Революта в стартап, где я тоже занимаюсь искусственным интеллектом, в основном компьютерным зрением для ритейла. А давайте я на самом деле начну стримить экран, потому что я буду много чего сегодня показывать. И если кто хочет, в Лингне меня можно найти вот так.
А, ну опыт у меня примерно следующий. Я работал последние 2 года в революте, занимался нашим я ассистентом, про которого я сейчас расскажу. До этого был кофаундером пары компаний, ну и до этого из российских компаний работал в Яндексе, Ламоде и внтесе. Везде занимался датасам или аяем в разных его проявлениях. А вот, а, собственно, последний продукт, который я делал в революте, который в некотором роде будет, скажем так, вдохновение вдохновлением для нашего сегодняшнего разговора, это наш револютовский ассистент, а, который называется Air. Такой вот у него красивый э маркетинг, а, который умеет отвечать на произвольные вопросы пользователей, э, связанные с их финансовыми транзакциями. Давайте я покажу просто пару примеров того, как эта штука работает. Э, зачем я про это рассказываю? Ну, рассказываю и показываю я это для того, чтобы, э, в виде, откуда в целом растут ноги у того опыта, которым я буду делиться, и, э, как на самом деле могут выглядеть какие-то полноценные, сложные яй продукты.
А, ну вот примеры просто каких-то запросов, с которыми, например, вот тот ассистент, которого я строил, умеет работать, они выглядят примерно следующим образом. Это прямо всё скриншоты из моего продакшн приложения. А в Великобритании, например, уже всех у всех пользователей это доступно. Ну вот я как пользователь могу зайти в наш банк, ну и, например, спросить у нашего II ассистента, сколько, ну, насколько дорого для меня будет провести 2 недели в Дубае. Ну и он поймёт, что надо достать мои транзакции, которые я сделал в Дубае, посчитать, сколько в среднем я там трачу за день, сделать для меня какой-то прогноз на основе моих личных там финансовых привычек, например, да. Ну вот даже на уровне такого примера мы уже понимаем, что требует какой-то достаточно высокого уровня интеллектуальности от агента, да, ему надо понять, что у него есть данные, чтобы этот прогноз сделать, собственно, смотри, эти данные достать и посчитать.
>> Какая вот моделька скажи, >> что >> какая моделька там используется?
Ой, ну там целый большой каскад, но в основном в продакшене мы используем использовали, я уже там не работаю всё же. В основном мы использовали Gemite 3 Flash, ээ, потому что, ну, разумный баланс между костами и скоростью. А вот, ну, или вот ещё один пример. Не буду, наверное, идти поверх всех примеров. Ну, вот, например, я, э, спрашивал про трейдинг. Э у меня есть там два типа инвестиционных аккаунтов. аккаунт с акциями и аналог ИИС в России, в Британии. И я хочу узнать, сколько у меня денег лежит в ЕТФах, а сколько в индивидуальных акциях. Ну и вот мы в состоянии там, например, сходить с помощью нашего агента в эту информацию и выдать такого рода расчёт. Вот.
А что мы, собственно, сегодня будем делать? Сегодня будем говорить про вообще структурированную какую-то разработку и я, и агентов, и про Ивала. Это будет довольно простой разговор, поэтому для людей, кто в этой теме уже монстры, кто сам подобные системы в prodдакшн строил, он, возможно, будет супербазовым, но, скорее всего, он точно будет очень полезен тем, кто на это ещё только смотрит и сам руками такие вещи не программировал. Вот. И рассматривать мы это будем, собственно говоря, на примере очень сильно упрощённой версии, а, но агента, который решает ровно такую же проблему. Аэ, я буду показывать и его код, и каким образом мы будем записывать логи с него, и каким образом мы будем эти логи оценивать, чтобы потом получить э метрики, которые мы действительно можем замерить и против которых мы можем оптимизировать наши промпты и наши шаги в агенте. Аэ, вот я думаю, что важно понимать, что наш разговор будет точно довольно неформальным. У нас не будет никаких душных, скучных слайдов. Мы реально будем смотреть в код. ээ, кликать кнопочки во всяких прикольных интерфейсах, читать промпты и так далее. Поэтому, если у вас в любой момент возникают какие-то вопросы или вам хочется на что-то посмотреть подольше, просто пишите в чат. Фёдор будет читать в чат и помогать ээ э нам строить разговор боле лучше и интерактивнее.
>> Да. Андрей, кстати, расскажи вот что же такое вообще валы? Это то же самое, что юниттесты для кода или что-то сложнее? >> Зачем они вообще нужны?
Да, ну давайте про это поговорим. Ну, значит, когда мы строим любого рода AI системы и любого рода системы с любого рода системы с лмками под капотом, обычно в большинстве случаев, в большинстве продуктовых приложений, конечно же, не всегда, но в большинстве случаев, да, э интерфейс, который мы даём пользователю - это произвольный текстовый ввод. Ну, собственно, в том же виде, в котором вы, например, видите, вот в этих примерах из там настоящего продакшн проекта. А, ну, это приводит, на самом деле, к тому, что спектр, э-э, пользовательского ввода, который вы можете получить, как бы ширина его разнообразия, э она безгранична. Пользователь может с простым языком пользователь может написать вам любую ерунду. Ну, и поэтому покрывать такой код вот юнит-тестами, наверное, не очень правильно. Это, на самом деле, очень далёкая, мне кажется, аналогия. Э потому что протестировать весь возможный спектр всех этих инпутов вы не можете. И обычно на практике я бы сказал, что на самом деле вот за этим словом эвалы скрывается просто некоторый способ структурированной оценки качества вашего пайплайна, где обычно словом качество в лмках мы всё же называем в большинстве случаев аэ частоту возникновения каких-то типовых ошибок. То есть за редким исключением, если вы, например, делаете там агентов чисто для кодинга, которые должны решать понятные задачи, у которых есть понятные, простые ответы с которые вы можете легко отвалидировать, например, вы можете написать код и проверить, что все тесты для этого кода красные. Ну или вы можете там решать алгоритмическую задачку, и вы можете просто увидеть там ответ на эту задачку, да. В большинстве случаев и в реальной жизни это на самом деле не так. Пото что, например, даже если мы посмотрим на финансовые юзкейсы, например, на то, что мы видим на экране, да, главные проблемы, с которыми мы будем сталкиваться - это не проблема с вычислением. Там посчитать, сколько процентов лежит э в одном типе финансовых активов, сколько в другом. Это задача не великой сложности. Очень много проблем будет связано с тем, как замерять э частоту ошибок с точки зрения компласа, частоту ошибок с точки зрения Ton of Voice, того, как мы разговариваем с пользователем, или того, как какой какое форматирование, например, даже мы используем, чтобы оно укладывалось в нашу дизайн-систему. Вот. И вот эти вещи обычно обычно, когда мы делаем ивалы на эти вещи, да, мы учимся строить метрики, которые меряют, как часто мы отклоняемся от этих гайдлайнов. То есть я бы сказал, что ивалы от тестов отличаются в первую очередь тем, что, ну, в большинстве случаев на практике валами мы меряем, э, как часто, э, мы фейлимся э в рамках какого-то заданного критерия. Ну, жизненный пример, да, например, в банках, если вы делаете банковского чатбота, вам нельзя давать financial advice. Мы этот пример рассмотрим дальше, но вам нельзя нельзя говорить человеку там, положи всю котлету зарплаты в Nvidю, вот он посадит в тюрьму, короче, если такое сказать, да? Ну, соответственно, Ивал будет мерить частоту, как часто мы случайно срываемся и такие вещи делаем. Вот. И с этой точки зрения довольно далеко от юниттеста. Юниттест проверяет какое-то понятное, детерминированное поведение. О'кей, понятно. А так я правильно понимаю, что ты нам сейчас продемонстрируешь, так сказать, как ты делаешь овал, как ты это делал на работе, да, на таком?
>> Да. Ну давайте посмотрим. Конечно, это будет сильно сильно упрощённый пример, что просто для того, чтобы мы реально на таком звонке могли его разобрать минут за 30. Но он на самом деле будет, на мой взгляд, очень близок к реальной продакшн ситуации. Особенно он будет близок к ситуации, в которой вы только начинаете проект. Мы на самом деле сыграем сейчас в некотором роде в ролевую игру, в которой вот представим себе, что вы ещё ничего с вашим агентом не делали и к вам, не знаю, приходит ваш руководитель и говорит, что завтра нам нужен лучший ай на планете. Ну и вы открываете клоды и идёте, значит, вайп-кодить агента для вашего банка, да? Вот, собственно говоря, мы посмотрим, что в таком сценарии происходит, какие шаги мы буквально руками делаем, чтобы понять его качество, понять, где он ошибается. увидим, как выглядит код какого-то первого самого простого ивала, а потом мы посмотрим на методы автоматической генерации промптов, которые позволяют нам оптимизировать промпты для того, чтобы эти валы, собственно говоря, проходились.
А давайте начнём сначала с самой постановки задач самого агента. Собственно говоря, я пытаюсь в нашем прототипе построить и агента, который решает примерно такие задачи. у него есть доступ к всем данным по транзакциям какого-то конкретного пользователя. На самом деле меня, мы будем смотреть на мои настоящие данные. Э-э, и он будет пытаться отвечать на любые сложные вопросы, связанные с этими транзакционными данными. Значит, что у нас есть на вход? У нас на вход будет такая сейсвишка. А это, на самом деле, просто мой экспорт из моего личного банка. Это просто набор всех моих транзакций. Здесь видно, что вот каждой транзакции есть какой-то тип, например, не знаю, вот транзакция обмен валют, да, есть продукт, с которого она сделала, ну, это там current или savings аккаунт, а дата этой транзакции, э-э, какое-то описание, которое может включать в себя мерчанта или, э-э, текстовое описание этой транзакции, а была ли заплачена за неё комиссия, а-э, валюта.
>> Приятно, что ты нам доверяешь, такие данные нам показываешь.
>> Ну, а что в ней секретного? Не думаю, что с ней можно сделать что-то плохое. А вот состояние этой транзакции, закрылась она или нет. Ну, и там, э-э, собственно говоря, баланс суммы этой транзакции. Вот, э-э, это мои реальные данные живые. То есть вот так вот выглядит буквально там таблица с моими транзакциями, да. Ну, и дальше мы хотим построить агент, который имея доступ к этим данным, может отвечать на какие-то финансовые вопросы для меня. То есть, у которого я смогу там написать, не знаю, сколько я трачу на кофе, и он там каким-то волшебным образом это для меня посчитает, да, как прототип системы, который мы на самом деле, может быть, потом могли бы пользователям давать в продакшене.
А вот как, собственно говоря, выглядит сам агент, э который тако с такими данными будет уметь работать. У нас значит агент у нас очень простой, да, тут, конечно, все скажут, что нельзя показывать вам ключи. Ключи эти, >> да, там были переживания в чате. Я их потом я их я на них во всех стоят снлимиты. Можете поупражняться, но вряд ли вы сможете с них что-то получить. Да. Э, собственно говоря, промпту агента при следующим образом устроен. Значит, наш агент - это э система, у которой есть вот такой очень простой прототипный промпт, очень коротенький, да, понятно, что с таким промтос будет очень много ошибок. Ну, и в этом, собственно говоря, и есть суть демонстрации. Я специально сделал его максимально простым и тривиальным. В промте написано, что ты финансовый ассистент. У тебя как ассистент есть access к одному тулу. Ну, tool -то это функция, которую мка может дёргать, да? Эта функция - это execute sequel. То есть она может написать SQL-код, положить её в этот, и SQL-код закзеeкютится против таблички с транзакциями, да? А, и дальше мы говорим агенту, что он должен пытаться отвечать на вопрос с пользователя, используя этот и таблицу с транзакциями. Ну, и дальше, собственно говоря, запросы к этой лмке. Здесь я взял GMISplay Flash. Они делаются в цикле до тех пор, пока мы не получим этоговый ответ. А, соответственно, модель входит против в базу данных, итерируется против неё, пишет SQL, чтобы потом что-то заэксплорить, как-то ответить на вопрос юзера и выплёвывает ответ.
А вот смотря у меня этот агент даже запущен, можно проверить, работает он или нет. Может быть, конечно, как всегда, случится демо-эффект, но давайте у него что-нибудь спросим. Давайте что-нибуд простое спросим, чтобы ждать недолго. Какой у нас может быть простой вопрос? Ну давайте спросим, а, а, например, а, what is my spend on cl overlast 3 months, например. Сколько я трачу на клода за 3 месяца? Ну, учёт посчитает. Ну вот он пошёл в табличке, там что-то экзек.
>> Я может пропустил. То есть это ты какой-то фреймворк используешь или >> нет? Нет, если честно, я не люблю фреймворки вообще в целом, потому что мне кажется для того, чтобы написать цикл, который на самом деле выглядит вот так, >> это Reactop у тебя или что-то ещё?
>> Да, по сути, да, по сути, да, вот так выглядит React Loop. Мне кажется, что фреймворк для этого не нужен, если честно. Ну, по крайней мере, когда мы говорим про такого рода простые прототипы, большого смысла в этом я не вижу. Вот, собственно говоря, да, вот мы получили какой-то ответ. Ну вот он нам рассказал, что на основе моей истории транзакции мой полный спн наклода за последние 3 месяца 54 фунта. Ну немного. А потому что последние 3 месяца ещё компания за клода платила. Вот поэтому и мало.
А, собственно говоря, теперь у нас возникает вопрос. У нас есть такой прототип. Естественно, весь этот прототип был написан не мной, а очевидно написан клодом, что, наверное, совпадает с вашей ситуацией на работе, на которой вы тоже это навайп-кодите. Но теперь у нас возникает очень понятный и простой вопрос. Хорошо, у нас что-то есть, оно как-то работает. Ну, как нам узнать, оно вообще работает хорошо или плохо? Ну, мы, наверное, подозреваем, что оно работает плохо, конечно же, но плохо как? Да, надо было бы, надо нам это понять. Вот для того, чтобы это делать, нам нужно научиться собирать логи со всей этой системы. Нам нужно где-то сохранить, что нам приходит на вход, что нам, что нам, что у нас вышло на выход. И желательно нам бы ещё знать, что произошло в середине, там какие запросы э наша система сгенерировала, э как долго она работала и так далее, для того, чтобы мы могли их, собственно говоря, проанализировать. Вот. Ну, и здесь мы переходим к инструментам для того, что называется треacing. Ну, вообще тут в этой теме будете слышать слова traйс. Traceйс обычно это просто лог, то есть это там запись каких-то вызовов опишку, которые ваша система делает. Ну, трейсинг - это, соответственно, там запись этой записи в какую-то в какую-то систему. Значит, таких систем осорсных есть очень много, которые предназначены специально для агентов и для лмок. Наверное, три самых популярных - это L Fuse. А она мне лично нравится больше всего. Почему мне нравится больше всего? Потому что она полностью openсоourсная. Раз. Во-вторых, куплена кликхаусом. Я люблю кликхаус 2. В-третьих, у неё очень хорошая опишка. И самое главное, очень хорошие скилы для Клода. То есть, на самом деле, если вы пользуетесь Нгфюзом, самостоятельно ничего программировать вам вообще совершенно точно не придётся, потому что они сами сделали качественные скилы и легко доступную для AI опишку, которая позволяет вам просто зайти в ClС, попросить: "О'кей, сделай мне всю инструментацию с помощьюфьюза, и оно просто заработает, скорее всего". Есть ещё Phenix от компании Aй. Он тоже open sourceный, его можно селфстить. А, в принципе, похож на Leng Fuse, на самом деле. А, и, наверное, из ещё популярный есть Brainust. А вообще Brainust, на мой взгляд, обладает наиболее удобным, комфортным и приятным интерфейсом. Это прямо серьёзный такой американский продукт, идеально вылезанный, где все кнопочки кликаются хорошо и выглядит всё очень красиво. Единственная проблема, он нел вхостится, он за него надо платить. А, и самое главное в любом стартерките, э, нету, не хранятся ваши данные какое-то приличное время, и апишка заблокирована почти. Там очень жёсткий рейдлимит, поэтому вы не сможете с ним программно взаимодействовать. Поэтому, если честно, brainust, на мой взгляд, если вы не платите за протир не работает нормально. Ну, я думаю, тут больше такие любители, да, то есть для нас простых.
>> Ну, вообще для вообще на самом деле, если мне кажется, что LФ Fusз оптимальный вариант почти для всех, потому что если даже там какой-то фичи нет, поверх него очень легко накодить что-то самому, потому что у него открытый код, хорошо отлаженный, хорошие скилы для ия. Соответственно, если там чего-то не хватает, просто напускаешь на это клод и он всё сделает. Вот. Но интерфейс там выглядит, конечно, довольно трагично. Мы на него как раз сейчас посмотрим. Это такой продукт в стиле продуктов от Яндекса, я бы сказал. Именно, наверное, поэтому Кликхаус их и купил. А
>> они из той же из той же серии, что вот нрав Нчейна или это другие ребята?
>> Э, нет, это другие ребята, это не то же самое. И при >> А у тесмит, да? >> Что ещё раз смотри, >> у техмит, да, кажется. Да, да, да, да, по-моему, да, он называется. Но если честно, я вот лангчейновскую тусовку вообще не люблю. Они любят делать свои простые вещи невероятно сложно. Я не очень понимаю, зачем. Я 2 года пытался понять, так и не понял. Но это вопрос вкуса, я думаю. L Smith тоже работает. На самом деле вот этих AI instrumentation систем, их штук 30 есть разных. Все с какими-то разными микропреимуществами. Просто вот эти три, наверное, самые популярные, мне кажется. А, но если честно, они все плюс-минус обладают одним и тем же набором базовых фичей, поэтому выбор системы, на мой взгляд, не важен никаким образом. Вот.
Но на самом деле мы немножко тут запутались. Значит, для чего нам вообще всё это нужно, да? Нам нужно как какой-то софт, куда мы сложим все логи с нашего приложения, где мы сможем их читать, э-э, и как-то на размечать, чтобы делать выводы из ошибок и проблем, которые мы там ловим. Значит, как вообще на практике выглядит, вот буквально на практике, например, если мы возьмём в качестве примера Leng Fuse, как выглядит подключение нашего вот простого новайпкожного агента к ленгфюзу? Он выглядит невероятно просто. Мы возьмём, где у меня там это было? Сейчас, секунду, я прямо покажу прямо живую сессию. Вот у меня была живая сессия из Клода. Я в этой сессии, значит, собрал агента, да, нашего простого. После этого я просто буквально говорю Клоду: "Слушай, всё, заинструментируй это в ЛНФьюзе. Вот тебе IP ключи от лангфюза. Э-э, возьми скилл для работы с ним из официального репозитория. Всё, поехали". э-э, достал скилл, заинстрил его автоматически и написал весь код инструментации. Это что этот код инструментации на самом деле под капотом из себя представляет. Это вот такого рода враперы. Сейчас я достану его. А вот такие. То есть на самом деле ваши LLM вызовы, неважно на какой на какой модели и с каким фрейворком они устроены, то есть и это может быть там Google, Open AI, Antropic, Selfosted, VLM, whatever. Это всё не очень важно. Аа вы можете просто в декоратор от Нгфюзануть э-э свой свою функцию, внутри которой происходит lmвызов, и автоматическим образом э lмm вызов, который внутри этой функции производится, он э будет оттуда вытащен и отправлен в систему для логирования. Вот как это соответственно выглядит на практике. Вот если янсь в свой, >> извини. Може, может быть, если ты в коде чуть можешь покрупнее делать.
>> А, сорри, >> у тебя, я думаю, у тебя очень хороший монитор.
>> Да. Ага, спасибо. >> Ну, это вот примерно примерно вот так это выглядит. А, ну, то есть на самом деле у вас вот любой код, внутри которого происходит lm вызов, он выглядит вот так. То есть вот у неня есть функция run. Она просто по факту на основе чат-контекста прогоняет ээ lm loop, да? Ну, и дальше вы просто заворачиваете её в вызов лангфюза и дальше оно автоматически начинает логироваться. Больше делать по факту ничего не надо. То же самое с остальными фреймворками. Там всё работает точно так же. Может немножко другой синтаксис, но суть такая же. Вот смотря после только после того, как мы вот это сделали, а мы можем попасть в наш observability платформу. Вот в моём случае это fuse, в которой ялогинился. У меня вот тут есть проект специальная демка для вот этого семинара, да. Ну, мы можем посмотреть сессии, которые мы которые мы делали. Я сейчас выберу сессию за последние 30 минут, и мы, собственно говоря, здесь увидим наш последний запрос, который мы делали в агента, когда я показывал демо, да? И что мы здесь увидим? Э, ну, мы можем посмотреть на кост, на когда всё это было создано, на количество входных э выходных токенов э в этой сессии. Самое главное, можем её открыть, а, и увидеть полный лог того, что здесь происходило, да? То есть мы можем увидеть текст пользовательского запроса, полный инпут весь system prompt, э, и можем увидеть полные аутпуты по шагам. То есть, например, вот это там промежуточные запросы, которые моделька делала, да?
>> То есть это по сути есть трейсы, да? То есть, чтобы собекие принты не писать, мы можем сюда зайти >> и всё изучить.
Собственно говоря, если мы откроем полный вид трейса, мы на самом деле увидим вот такое, а как сказать, это не дерево, вот такую последовательность. Это, на самом деле, наши последовательные вызовы лмки. Вот эти generate content, это вызовы самой модельки. Почему так? Ну, потому что у вас любой агент, он на самом деле будет делать какое-то неопределённое количество вызовов, пока он исследует ваши данные. Например, да, в нашем случае он сделал несколько SQL-запросов. А мы можем каждый из них там по отдельности прокликать, но нам пока это не нужно, на самом деле. Нам пока нужен только полный user turn, то есть полная end to end интеракция с пользователем. И мы увидим, что вот у этой сущности usеerna us user дал нам на вход вот такое сообщение. Это был наш финальный ответ, да. Вот. Ну хорошо, у нас появилось, по крайней мере, какое-то место, куда сложатся все ответы юзера. То есть, очевидно, мы сейчас, э, в этом тестовом приложении мы делаем это всё локально, но абсолютно всё то же самое, естественно, применимо в реальном продакшене тоже. То есть, ну, тот же самый код мог бы в теории теории в продакшене крутиться и те же самые ответы могли бы сваливаться сюда. А я заранее ещё, э, позавчера подготовил нам чуть больше сессий, э, чтобы мы сейчас на лету не чатились, э, и залогал их здесь, да. Вот вы можете видеть, что у есть какой-то набор сессий залогированных. Значит, у нас дальше возникает вопрос: "О'кей, у нас есть там, предположим, что у нас есть какой-то набор пользовательских взаимодействий с нашим ботом, да? А что мы с не с этими что мы делаем для того, чтобы понять?
>> Извини, а а тут можно покрупнее тоже сделать?
>> А, да, конечно, можно. А давайте сделаем вот так. Так, >> ещё вот красные чёрточки. Только у меня или да, так получи?
>> У меня тоже, мне кажется, их кто-то мог случайно в анотейте нарисовать. Вот можем как-то почистить экран. Ну ладно. >> Я не знаю, я не эксперт зуми. Вот с ними даже лучше, наверное.
>> А, ну всё, всё, всё, вот я урал. Всё нормально должно быть теперь. А вот, собственно говоря, вот у нас есть вот такой набор наших сессий. Мы можем во всех этих сессиях смотреть на те же самые вещи. То
Есть, например, мы можем посмотреть на пользователя, который спросил: "Во что я хочу должен проинвестировать дальше?" И можно посмотреть, что наш агент из-за того, что он запромчен не очень хорошо, написал ему целое эссессе о том, что и куда надо проинвестировать, да?
А значит, как мы вообще можем структурированно подойти к тому, чтобы такие проблемы, во-первых, сначала собрать их список, э, исходя из пользовательских взаимодействий, а потом к тому, чтобы их исправить. Но на самом деле реально руками мы делаем суперпростую вещь. И мне, и вот это, я бы сказал, самый важный операционный шаг, который вы должны всегда делать, когда вы разрабатываете какой-то яй продукт, которым пользуются живые люди. Он звучит скучно и не очень весело, но на самом деле это самая ценная деятельность, которой вообще можно заниматься. Это просто, ну, как бы как бы тупо это не звучало, это просто читать вопросы и ответы и оставлять комментарии.
Как это сделать реально на практике просто удобно? В любой вот этой системе для трейсинга будет инструмент, который позволяет делать ручные ручную разметку. В лангфюзе, например, это делается руками вот так. Если я выберу вот этот трейс, да, который вот мы оставили недавно, э, несколько минут назад, я могу отправить его на аннотацию. А, и здесь я могу выбрать какой-то тип скора, который вы можете задать. Ну, то есть это по факту поле, которое пользователь может вводить. Как я его назвал freform, что это просто freeform command, да? Я могу его здесь оставить. Ну либо, на самом деле, его можно отправить в очередь, а потом перейти в annotation QS, вот здесь Human annotation, да? И тут у нас будет прямо очередь, в которой можно просто нажать на процес Q, и дальше у вас появляется интерфейс разметки, в котором вы можете стрелочками скролить разные кейсы и что-то аннотировать. Это на самом деле удобно. Вы просто берёте свои логи, там логов штук 50 или 100, отправляете их все в очередь разметки и дальше просто садитесь руками, берёте баночку Red Bull и, значит, день пишете эти аннотации. И после этого вы получаете большое количество какое-то знаний о нашем, о своём продукте.
Как эти аннотации вообще в первой итерации оставлять? На самом деле, значит, в первой итерации реально всё начили делаем, не напрягаемся совершенно. Не надо пытаться придумать какие-то сложные метрики со старта и вообще что-то изобрести. Самый простой подход, который на самом деле всегда на практике работает, особенно у вас продукт ещё не очень матчу, это просто читать вот такого рода логи и оставлять freм комментарии. А вот этот конкретно пример у нас сработал хорошо, поэтому здесь даже оставить особо нечего, но я сейчас покажу несколько примеров, где это было не так. Сейчас я могу сказать, что типа ты здесь молодец или >> нет, это если честно не очень полезно, потому что где где мы молодцы, это в принципе и так будет понятно путём вычитания того, где мы не молодцы, да, поэтому это не супер полезно. Вот. Но мы можем посмотреть на мои старые аннотации, которые я сделал, когда подготовился. Давайте их сейчас прокликаем, посмотрим. Вот. Ну вот у нас, э, да, вот это я просто его ломал, да, вот пользователь написал: "Напиши бабл сорт на Питоне". Да. Ну и поскольку никаких запретов у нас не было, мы ему так ответили. Ну что мы делаем в этой ситуации? Нумы просто пишем текстом вообще без каких-то пока сложных мыслей. Вот оставляем заметку, что это unsafe output. Так не должно быть. Бот должен фокусироваться на financial assistance, а не на том, чтобы давать человеку код, да? Аэ продолжаем двигаться в том же стиле. То есть мы можем сейчас про здесь у нас всё было хорошо, здесь аннотации нет. Давайте уже >> то аннотация комментарий в свободной форме, да? И он их понимает, >> да, абсолютно в свободной форме. Вот тут, например, был предме пример, да, юзер спросил, во что я во что я инвестирую э каждый месяц. Тут у меня, кстати, походу, аннотация поехала. Видимо, я вот я ошибся и допустил человеческую ошибку. Ну такое бывает. Тоже у вас постоянно будет. И это нормально, потому что когда вы будете размечать 100 чатов, вы ошибаться будете регулярно. >> А где она поехала, как ты понял? >> А я оставил комментарий неправильный про пин-код в вопросе про инвестицию. >> Видимо, у меня было два окна, и я скопировал не туда. Ну вот давайте вот этот вот этот посмотрим. А, да, вот здесь пользователь спросил, где он шмотки покупает. Да, а бот выдал. А что бот выдал? Давайте посмотрим. Бот у нас выдал в аутпутерялся в трейсе. Бот нам насчитал, где вотпут. А, демоэффект случился, извиняюсь, потерял куда-то полный трейс. Ну, это довольно такая муторная работа, да, кажется, все, >> да, это работа очень муторная, потому что вот я сейчас пытаюсь её делать онлайн. Её, конечно, делать надо немножко спокойнее, как вы можете заметить, её нужно делать аккуратнее, а не на стриме. Потому что работа действительно медленная и довольно довольно тяжёлая. Давайте, знаете, я просто покажу, потому что я сейчас смотрю это не совсем правильном месте. Давайте я это покажу вот так. И это покажу через сессии. Так просто будет чуть проще, потому что у меня здесь аннотации уже включены. Вот так вот. Мы можем их все здесь прочитать. А-а, вот тут, например, да, давайте выберем какую-нибудь интересную. Вот эту, например, да, сейчас я её открою таким образом. Вот прогрузится. А, да, вот так её посмотреть будет удобнее просто. Вот здесь у нас у пользователя был вопрос, э, где опять же мы пытались что-то сломать, где шмотки покупаю. И мы ответили, что в вашей истории операции нет специализированных магазинов одежда. Единственное место в вашем списке, где продаётся одежда помимо продуктов - это Marкс and Spencer. Но на самом деле это магазин продуктов в Британии, в нём просто иногда продаётся одежда, поэтому, наверное, это не очень правильное какой-то вообще интерпретации. Мы, наверное, не хотели бы, да, чтобы наш робот так отвечал. Он, на самом деле, должен был бы сказать, что я не понимаю, как ответить на этот вопрос. У меня нет данных, вместо того, чтобы делать такой assption. Да. Ну и в такой ситуации, собственно говоря, такой коммент и был оставлен. Вот мы его здесь видим. Это коммент из разметки. If the bot can't make a reasonable assumption based on incomplete data. It should ask a clarifying question. Да, он должен был, на самом деле, мне бы хотелось, да, чтобы он уточнил, что пользователь на самом деле хочет получить. А вот в том же стиле мы можем, мы оставляем оставляем вот такие комменты. Вот тут ещё один пример, да, такого комментария у нас есть вот здесь. А давайте посмотрим, что тут произошло. Тут пользователь спросил, какие послед в какие последние поездки я ездил и сколько я потратил в каждой стране. И мы выкатили ему вот такое эсс, где зачем-то ещё про каждую страну мы ему рассказали почти про каждую транзакцию, которую он там делал, что, если честно, довольно бесполезно, да. Ну, поэтому мы оставили комментарий, что это всё слишком длинно, мы должны пытаться уменьшать размер респонса. >> Вот. То есть, как вы можете понять, это супер неформально, супер в расслабленном режиме. Просто оставляем эти комментарии. Я знаю людей, которые вообще на самом деле одного человека, который это делает вообще войсом, просто кликает стрелочками на свои трейсы и просто бубнит в микрофон. Ну, и дальше сохраняет эти комменты. А на данном этапе наша цель >> Скажи, пожалуйста, что дальше происходит с этими аннотациями на >> Сейчас вот расскажу, да, прямо сейчас мы к этому перейдём. Наша главная цель, да, когда мы это делаем, зачем вообще это делаем? Мы это делаем для того, чтобы понять типы ошибок и типы проблем, с которыми мы сталкиваемся. Но понятно, что из аннотации фриформа типы не следует, да? Нам надо их как-то получить. Ну и вот реально самый простой способ их получить. Опять же, никакой ракетной науки. Э делаю всегда супер тупым образом. Я их выкачиваю и делаю себе файлик, похожий примерно на вот вот это вот у меня сейчас на экране с кодом он будет. А я прямо буквально кладу все вот эти аннотации в текстовый файл. А в этом текстовом файле я кладу свой комментарий, а, и сохраняю саму переписку, на которую я этот комментарий оставил. То есть, например, вот здесь вот аннотация номер один. Мы просто в текстовом файлике запишем, что мой комментарий, что просто мы дали неправильную информацию. Револют не даёт кредиты в Британии, это галлюцинация. А пользователь спросил, могу ли я получить, значит, кредит. Ну и мы почему-то сгаллюцинировали, ответили, что можешь, что вообще абсолютная неправда. Вот. И так далее. А и просто пишем очень простой скриптик, который нам все вот эти аннотации сдапит в файлик, да? Ну, это мы получаем файлик какого-то там, ну, какого-то размера. А, естественно, читать это всё руками, особенно когда вы в реальной жизни, вы это, скорее всего, будете делать не один, скорее всего, в реальной жизни у вас будет штук 500 трейсов, э, вот такого рода, которые вы и пять ваших коллег разметите, да, вы, естественно, это всё читать не будете. Это очень долго, сложно и довольно бесполезно. Поэтому, что вы делаете? Берёте вот просто текстовый файл этот. И на самом деле для первой итерации, для того, чтобы понять какие-то базовые вещи, которые вам достаточно, чтобы стартануть, вы кладёте этот файлик в в клода, ну или в любую другую lmсистему, которая вам нравится, а и просите сделать категории ошибок. Ну и вот из того файла, который мы получили путём ручной разметки вот этого тестового чатбота, мы уже можем получить вот такого рода набор категорий. То есть мы уже можем получить наш тег про галлюцинации, тег про financial advice, тег про ответы, когда мы отвечаем, скажем так, за пределами вообще скоупа финансового ассистента. То есть, когда мы там пишем код, разговариваем про мемы и так далее, когда мы не спрашиваем уточняющие вопросы, когда мы говорим слишком длинно и так далее, да? То есть здесь на само на самом деле у этого есть научное название. Там научное название, по-моему, из социологии. Вообще у этого процесса, это open codдинг, открытое кодирование. Это вот эти фреформ э-э ответы. А, э-э, категориальное кодирование - это когда мы получаем, собственно говоря, вот эти лейблы. А, ну это можно делать вручную, можно делать автоматически. Я рекомендую для первой рации делать автоматически. А на самом деле современные лмки справляются с этим отлично. Вы можете целую книгу трейсов своих размеченных сложить в современную модель и получить эти категории. Очень часто они будут у вас довольно булшитными. Ну, вы просто руками их прочитаете и выкиньте лишними. Выкиньте лишнее. А вот что мы получили после этого упражнения. Самое главное, да, самый главный аутком у нас какой? Мы теперь знаем, на основе нашей собственной ручной работы, что очень важно, да, это не какая-то автоматизация, это наша ручная работа, результаты, которые иследуют из нашего контекста, из нашей головы, из нашего понимания продукта. Э мы знаем ключевые виды ошибок, с которыми мы уже сталкиваемся, которые мы уже смогли найти. А, ну из этого уже напрямую следует, во-первых, улучшение, которые мы можем делать, да? Ну, потому что на самом деле каждую из этих ошибок можно просто посмотреть глазами и написать там какие-то изменения в промт или какие-то изменения в агенты, которые позволят нам её не допускать дальше. А, либо, что довольно важно, каждый из мы можем каждый из этих ошибок превратить в автоматизированную метрику, потому что я, конечно же, не хочу сидеть и каждый день читать трейсы, чтобы понимать, как часто мы, например, даём financial advice. Да, мне этого бы не хотелось. Я хотел бы это автоматизировать. А, ну и здесь вступает в дело концепт, который называется LLM is a judge. LM судья. Ну, концепт на самом деле очень простой. Если мы знаем, что у нас часто возникает вот такой тип ошибки, а что мы часто даём, например, финансовые советы, ну, надо сделать отдельный промпт, который берёт ваш трейс, кушает его и говорит, есть там финансовый совет или нет. Э-э, и дальше вы, собственно говоря, его можете в параллели со своим продакшн- кодом держать и считать, как часто у вас такие случаи возникают. Аэ, он, ну, пример такого промпта, на самом деле, он выглядит очень просто. Вот у меня здесь есть примерчик. Может выглядеть примерно вот так. То есть мы на вход принимаем запрос пользователя и ответ. А и при принимаем вот так, применяем вот такой промт, в котором мы определяем, что такое financial advice, например, которого не должно быть в наших ответах. А, и применяем это к нашему к нашему ответу и в бул переменной, да, потому что, ну, это на самом деле просто классификация, поэтому у вас в аутпуте по факту может быть один true false. Ну, принимаем решение, да или нет. Вот. Ну, и, соответственно, если мы вот это вот это называется judge по сути и это мы можем применять каждому нашему трейсу. >> Ему категории нужны обязательно или можно без категории? То есть зачем мы вот предыдущий шаг делали? Ну, предыдущий шаг мы делали для того, чтобы понять, какие категории у нас есть, да, потому что на самом деле понятно, что, ну, про некоторые категории ты, конечно, можешь их просто придумать на Литу и в совсем игрушечном примере это сделать легко, но в реальном мире это обычно не так, потому что в реальном мире, когда ты дашь свой продукт настоящим пользователям, которые будут спрашивать у него вообще не те вопросы, про которые ты думал, что они их будут спрашивать, и будут писать какую-то ерунду, а ещё будут пытаться сломать твоего бота специально, потому что все это всегда делают и всегда просят там, я не знаю, поговорить про каки-нибуд непотребные топики, например, да, ты, скорее всего, без ручного вот этого процесса выведения категории из данных ты, скорее всего, хорошее покрытие не получишь. Вот. А э можно быстренько вопрос из чата? Да. Если задача креативность текста, то как бороться с ludge? Баюс, ну, с Байсом Chше. >> Ну, у меня нет, если честно, у меня нет на это хорошего вопроса, потому что я не эксперт в креативной индустрии. Я не знаю, что такое креативный текст. Но м обычно в любом случае всегда, если даже ты не можешь написать определение своего критерия прямое, да, то есть ты не можешь прямо сказать, что текст является креативным, если текст не является креативным, если да, если ты не можешь это сделать, а ты всегда как минимум можешь дать определение через примеры. и и делать shot промтинг в джаджах. Это всегда работает довольно хорошо. То есть ты всегда можешь загнать в свой промпт, вместо того, чтобы писать прямое определение, как, например, у нас написано здесь на экране, ты всегда можешь загнать туда 30 примеров текста, который тебе кажется хорошим, 30 примеров текста, который тебе кажется плохим. Ну и есть шанс, что это будет работать нормально. Но вот конкретно тест tйст BAS вещи, там такие как креативность, это, конечно, супер сложный вопрос. И, наверное, на эту тему есть какая-то наука более серьёзная. Но мой первый шаг был бы, наверное, таким делать это чисто через примеры. >> Окей, пойдём дальше. >> Вот. Ну, собственно говоря, мы вот уже находимся на самом деле на стадии, когда у нас есть вот такой джадж, да, мы можем его применить к любому нашему трейсу, и мы как минимум можем посчитать, как часто у нас возникает ошибка определённого типа. А, ну поздравляю. Если мы можем это сделать для каждого типа ошибки, которые у нас есть, мы уже можем получить какие-то разумные метрики. Мы как минимум можем посчитать, как часто мы ошибаемся в каждой категории ошибок, которые кажутся нам интересными. Ну, дальше мы натравливаем это на нашу продакшн, на нашу продакшн-систему и смотрим на этот э результат ээ каждую неделю. И каждую неделю, если мы живём с реальными юзерами, мы просто пересматриваем список категорий, с которыми мы работаем. И в принципе, конечно же, то, что я сейчас показал, это очень сильно примитивизированный пример. Но на самом деле в реальной жизни, когда у вас там есть продукт, котором какие-то там тысячи человек в час чатится, оно на самом деле выглядит точно так же. Только у вас не ээ 10 трейсов в качестве примеров, а 10.000. И категории у вас побольше, но тем не менее фундаментально, на самом деле, ничем не отличается. Вот. Но у нас всё равно, естественно, дальше возникнет последний вопрос, наверное, да, это о'кей, мы научились считать, как часто мы ошибаемся каждым конкретным образом. Ну, считать-то недостаточно, надо с этим что-то делать, да. Ну, и дела, что с этим можно делать? Ну, >> да. То есть как допиривать нашего агента, да, чтобы он больше так не делал, >> да? Это самый самый самый важный вопрос, потому что на самом деле ради этого же все всё упражнения мы и делаем, потому что просто знать, что у нас ничего не работает, не очень полезно. Для этого даже не нужно делать никакие умные системы. Обычно и так понятно. Э, вот, значит, ну, подходов, э, к улучшению агентов, на самом деле, ключевых есть, наверное, два. Э, и звучит это всё довольно просто, да, это автоматиче автоматизированный и неавтоматизированный. Значит, неавтоавтоматизированный подход - это сидеть руками писать промпты. На самом деле, на практике, э, я бы сказал, что в 90% случаев это оптимальный вариант. Оптимальный. Почему? А потому что когда ты руками аккуратно пишешь промпты для своего агента, у тебя появляется намного более качественно, интуитивное понимание того, как и почему он работает. И когда ты руками борешься с каждой ошибкой и руками пишешь промпт, у тебя появляется более качественная интуиция о том, как твоя илмка работает и как она воспринимает prompt changes. Поэтому, на самом деле, я бы не рекомендовал э гнаться за автоматизацией этого процесса, потому что, мне кажется, для продуктового понимания, собственно говоря, своей собственной системы очень важно, на самом деле, делать это вручную, хотя звучит не очень но тем не менее есть и весёлый способ, а не только скучный способ. Значит, весёлый способ обладает смешным названием буквально джепа. Ээ, ну, есть много, на самом деле, алгоритмов, но просто самый модный и самый сильный из них - это джепа сейчас. А значит, это есть класс алгоритмов, которые умеют оптимизировать промпты, грубо говоря, как они все работают. Это, на самом деле, разные способы оптимизировать процесс переписывания промкталкой. То есть, фактически, э, все эти алгоритмы - это, ну, чуть-чуть более умные версии перебора шагов, в которых вы в другой лэмке говорите: "Вот тебе там аутпута прошлой лмки, попробуй переписать её промпт, чтобы стало лучше". Ну, конкретно вот этот алгоритм, почему он самый популярный на самом деле, наверное, и скорее всего самый prodдакш ready, аэ он работает следующим образом. А он получает, вы даёте ему на вход стартовый промт. Я вот тут подготовил примерчик с ним. Я написал стартовый промт, в котором у нас агент состоит из двух частей. Агент состоит из кусочка, который пишет SQL-код. Это тот же самый пример, что и наш прошлый агент. И из кусочка, который, собственно говоря, даёт ээ даёт итоговый ответ. Кусочек, который даёт итоговый ответ. Его промпт выглядит вот так. Ты финансовый ассистент. user тебе вопрос, а ты должен написать одну один SQL запрос к его банкстйтменту, используй данные, чтобы ответить пользователю на простом английском языке. Это как бы наш базовый промт, да? Понятно, что в нём будет куча проблем, потому что он никаким образом не учитывает наши критерии, что, например, нельзя давать financial advice, что нельзя писать код на Питоне там для пользователей и так далее, да? Ну вот у нас есть наш автоматический эвалюатор, то есть у нас есть наш джадж - это кусочек кода, который смотрит на ответ модельки и говорит, есть ли там что-то, что нам не нравится. В этом случае это в качестве примера мы возьмём, э, что мы будем скорить, собственно говоря, финансовые советы. А вот и если мы добавим к его аутпуту текстовое объяснение, почему что-то не так, то есть вот в это поле, собственно говоря, этот джадж запишет, что а не так. А, например, я поставил этому ответу, что он, что в нём содержатся финансовые советы, потому что потому что потому что, да, если мы это сделаем, то мы можем вот этот фидбэк использовать для итеративной оптимизации промкта, потому что мы можем этот фидбэк, э, собственно говоря, фактически добавить в некотором роде в наш исходный промот. Ну, и вот эта логика - это примерно то, что делает вот этот -эпа алгоритм. Соответственно, чтобы он работал, вам что нужно? Вам нужен джадgж. который отвечает ризонингом, который, то есть, пишет текст о том, что не так с ответом, и вам нужен стартовый промт. Больше вам, в принципе, ничего не нужно. Значит, если его запустить, а, то, а ему ещё нужен набор примеров. То есть это набор примеров, которые набор запросов, которые мы будем отправлять в систему. Ответы для них не нужны, на самом деле. Вам ответ сгенерит ваш собственный агент, а отскорите вы его джаджем. Поэтому вам вам нужно руками только написать набор запросов. А-а, и после этого вы запускаете этот алгоритм. Этот алгоритм начинает просто агрессивно перебирать разные модификации и варианты промптов до тех пор, пока он не сможет получать с точки зрения джаджа идеальный фидбэк. Ну и вот я запустил его для того, чтобы по оптимизировать автоматический промпт из вот этого короткого базового промпта, да, чтобы он больше не давал финансовых советов. Ну и у нас получилась вот такая конструкция. Те сейчас тут перенос, чтобы это читалось проще. Вот это полный результат оптимизации, да? Давайте сейчас я это разнесу. То есть на самом деле весь вот этот кусок, по сути, вот это всё, а был написан автоматически с помощью э оптимизирующего алгоритма. Ну и как вы на самом деле можете видеть, он автоматически без какого-либо вообще участия с нашей стороны. Мы только дали джаджа, который является вообще отдельной моделькой какой-то, да, и мы дали просто примеры входных запросов. Он автоматически понял, что нужно там отвечать на вопросы пользователя по фактам. Нельзя давать financial advice, дал какое-то определение и даже какой-то набор примеров, да, не рекомендую там стратегии какие-то конкретные, не рекомендую там отложить деньги на чёрный день и так далее. и рассказал, что делать, если пользователь у нас, значит, спрашивает про топики, кото на которые мы не хотим отвечать. Вот. >> Слушай, мог то же самое сделать тот же клод или кодекс, и чем тут именно помогла нам эта >> Мог, мог, абсолютно точно мог. Э-э, единственное, на самом деле, чем этот алгоритм помогает, и вообще вся весь всё вот это направление алгоритмов автоматической оптимизации промптов, а оно помо, он помогает тем, что они покрывают э более широкий более широкой, э, сорри, а они генерируют больше вариантов для перевода. То есть, если ты отправишь клода, о'кей, просто оптимизируй пром скорее всего тебе сгенерит один какой-то вариант. Может быть, прогонит его против против ивалов, может быть, потом сгенерит ещё один вариант. Да, все вот эти алгоритмы, они делают в некотором вроде древовидную оптимизацию. Они сгенерят тебе сотню разных вариантов этого промпта. Все их прогонят, дальше возьмут, возьмут из них кусочки, которые работают, попробуют этот промт смутировать, прогнать ещё раз. Где это на самом деле нужно? На практике. На практике это, на самом деле, нужно -э в случаях, э, когда вы и так уже простыми какими-то итерациями дошли до реально хорошего промпта, длинного и большого, и вы, во-первых, его уже вручную не очень хорошо можете автоматизировать и оптимизировать и не очень понимаете, что там, где уже написано. А, во-вторых, э когда у вас ваш промот будет реально длинным, неспециализированная система, какой-нибудь просто клод уже с этим справляться не будет. Ну вот простой жизненный пример. У меня в моём агенте вот который мы, например, в революте делали, у меня промпт был, а, ну, 30.000 токенов примерно. 30.000 токенов - это >> здоро, >> ну, много страниц текста, короче, дофига. Это вот э в этом промпте вручную навигироваться было уже просто на самом деле невозможно. И вот когда вы доходите до этого уровня, прямо специализированные системы, которые как конкретно работают с оптимизацией промптов, они реально полезны. До этого, на самом деле, вот эту задачу, конечно же, можно было бы на этом уровне решить просто открыв любой EA чат и сказав: "Подбери промпт". Это 100%. Но в момент, когда вы выходите немножко за этот скейлale, это уже так работать перестаёт. А, собственно горя, на самом деле на этом у меня демка закончилась. А, >> смотри, 48. Ой, опус 48 видел? >> Да, у меня только что на экране была. Ну всё, поехали тестить, собственно говоря. Вот смотри,
На этом у меня демка на самом деле закончилась. Давайте про какие-нибудь вопросы и в свободной форме поговорим и пообщаемся.
Ага. Ну у меня на самом деле такой вопрос, он вроде и в чате тоже звучал. А то есть получается сейчас LM нужна была для самого агента, чтобы его потестить. LM нужна была для здесь judge и LM ещё нужна была жопе. То есть получается, мы три раза прогоняем. То есть, ну, как бы первый вопрос: для всех ли ты используешь вот этот GFS? И во-вторых, вообще сколько уходит на один такой зако, ну, денег, токенов?
Ну, это, ну, это супер сильно зависит от того, ну, от вашего скейла, от вашего агента, да. Ну, э, я могу, ну, я, мне, наверное, нельзя, к сожалению, делиться прямо прямыми костами из реального там продакшена, к сожалению, да. Но аэ по порядково-э ну по агенты, ээ, значит, смотрите, я на немножко пивот на вопрос. Мне кажется, обсуждать просто косты довольно бесполезно, потому что косты зависят фундаментально от размера ваших промктов, от размера ваших аутпутов, это зависит от продукта. Поэтому у каждого продукта они, конечно же, будут разные. Наверное, хороший вопрос, более правильный, — это какую модель надо выбирать, да, чтобы эти косты оптимизировать, и надо ли их вообще оптимизировать, да? Наверное, вот это вопрос, который чуть более релевантен. Э, ну, потому что очевидно, что там косты у саппорт-чатбота или косты там у голосового продажника, они просто, ну, могут отличаться на порядок. Поэтому поговорить про эти косты смысла особо нет. А к выбору моделек, э ну мой личный опыт показывает, что всё, что хуже, чем три FLSH, просто бесполезно довольно на практике, если честно. Ну если вы решаете задачи какие-то, ну реально агентные задачи с тулколингом достаточно высокой сложности. Аэ опять же, естественно, это всё довольно бест на конкретной области, но в общем, по моему ощущению, всё остальное просто всё ещё довольно неюзабельно. Из open-sourceных моделек это, ну, первое, которая меня реально впечатлила, это GLM 4.7. Она хорошая. Вот поэтому для меня это всегда бейзлайн. Дальше есть вопрос про косты и про цены. А, ну вот про цены я обычно про это думаю так, что обычно всегда есть выбор делать либо селф-хостинг, да, то есть брать хардвар и само что-то деплой через VLM условно или что-то подобное, либо платить за APIшку. APIшку там неважно с open-sourceной моделькой или там платить OpenAI или Гуглу. А, и здесь, на самом деле, моя логика очень простая. Для того, чтобы селф-хостинг, если нет только какого-то бесплатного, условно говоря, железа, имел смысл, надо иметь возможность получать стопроцентную утилизацию GPU, по сути. Потому что если у вас нет столько лода, чтобы иметь почти стопроцентную утилизацию GPU, то вы, скорее всего, не получите эффективной цены на токен с учётом всех простоев, хотя даже сравнимый с любым провайдером, там, допустим, open-sourceных моделей, вроде, допустим, Fireworks, Nebius или ещё кого-то.
А вот. Да, тоже слышал, что нужно сначала понять, что точно вы без этой модели, то есть всё уже работает, бизнес, что она нужна, и тогда уже можно принимать решение о каком-то постойде, что и окупится. А раньше лучше тем.
>> Да. Оно на самом деле не факт, что окупится даже даже так с учётом текущих цен на аренду GPU, если вы живёте на аренде, то и с учётом того, насколько рады все провайдеры продавать servers, там на самом деле вообще не факт, что даже при стопроцентной утилизации будет что-то сходиться. Но это, конечно, зависит от конкретных договорённостей.
Ну ладно. Может, вернёмся к Валс, да? Был опыт из жизни, когда прямо реально что-то хорошее поймалось, без чего были бы какие-то там финансовые потери или что-то типа того, или это вообще стандартный случай, который постоянно происходит? А, ну, того, чтобы хорошее поймалось, такого не было. Было, чтобы поймалось плохое и неприятное. Но вот мои последние 2 года я делал агентов в банке. И как я думаю многим многие знают, банки очень сильно трясутся на тему комплаенса, особенно в Европе, где вообще законодательство довольно жёсткое. И одна из главнейших и серьёзнейших проблем, с которой вот я сталкивался — это оценка качества с точки зрения соответствия э некоторым представлениям юристов о законодательных нормах. И вот это, на самом деле, э даже не технически интересная проблема, а интересна операционно, потому что как это вообще выглядит на практике. Вот есть у тебя какой-то legal департамент, где сидят там 100 человек, может быть, ты из них общаешься с десятком, и у них есть какие-то представления о том, какой какие ответы правильные, какие неправильные, какие рисковые и что говорить можно, что нельзя, а ещё что можно говорить ещё нельзя в какой стране, кстати, потому что что можно говорить в Германии, а что можно говорить в Британии — это тоже разные вещи, да.
Вот. Вот, Но есть вопрос: а как ты вообще свою систему будешь оценивать на соответствие этим э правилам? И пока тебе эти лигалы не скажут, собственно говоря, что ты всё оценил правильно, они тебе не дадут ничего зрили. Поэтому эту задачу её нельзя проигнорировать, к сожалению. Э вот как я как к этому, собственно говоря, вообще операционно подходить и как это решать? Ну, на самом деле, примерно так же, как я сейчас показывал, ну, только делая это через других людей. Ну вот, э, мы, а-э, реально заставляли legal людей эвалить ответы, писать forms, что с ними так, что с ними не так. А после этого делали LM judges из этого, э, которые работали на основе примеров. То есть мы просто показывали прямо примеры, что вот это compliant ответ. И вот, собственно говоря, комментарии от юриста, почему он compliant. Вот этот ответ не compliant, комментарии от юриста, почему он compliant. И вот эти все примерчики в таком виде складывались в LM judges. Дальше им показывался новый ответ и спрашивали: "О'кей, с этим всё хорошо или нет?" И вот таким образом, на самом деле, можно построить системку, которая, э, динамически собирает, э, judges под конкретный под конкретный сетап, потому что ты можешь ответы и комментарии от твоих legal коллег собрать в просто по факту две отдельных таблички из них на лету там собирать какой-то промпт, да, для judge. Вот это, на самом деле, это не весёлая история про то, как что-то интересное нашлось, но эта история важная, потому что без таких очень унылых и скучных вещей ничего просто в prod не едет. А вот и я бы сказал, да, что на самом деле вот из прикладных болей истории, связанные с легальными вопросами, это, наверное, самое страшное, с чем я встречался. Э потому что это это на самом деле даже близко немножко к креативному тексту, про который нам раньше спрашивали, потому что у всех, даже в одном юридическом департаменте одной компании, у разных людей очень разные интерпретации того, что легально, что нелегально. Потому что, скажем так, задача сравнения и я и какого-то я и ответа с какими-то регуляциями, она не решается бинарно. Вот. И поэтому это хорошо довольно делать через примеры. Вот такая история была. А у тебя у тебя есть какие-нибудь крутые истории с этим связанные, которые ты можешь рассказать?
Ну, у меня скорее у коллег. Да, то есть ну, наверное, тут агенты больше внутренние, не такие серьёзные, когда у тебя там тысячи пользователей в revolute. Вот. Но тем не менее тоже пилим агентов и то есть один из них должен был финансовые данные выдавать, то есть там какие-то внутренние расчёты сложные и на выход там 10 чисел должно выходить. Э и агент постоянно, ну то есть вообще уже хотели в prod запускать, но коллеги молодцы, они начали с эвалов и вот нашли, что около одной циферки почему-то минус один постоянно вылезал, ни откуда не возьмись. Вот. Ну и да, там разобрались, проблему пофиксили, но если бы они эвал не делали, то на глаз всё было супер, потому что там вроде как ничего сложного не было, да? То есть обычные расчёты, обычный вывод таблички, а здесь минус один вылезает. Ну вот, да, очень помогло.
Найс, найс, найс. А, да, забавная история, действительно.
Да. И ещё с чем и я сталкивался и коллеги, бывало, что, а, ну, то есть приходилось вот эти, э, ну, как бы вот эти, вот эти примеры, да, самим писать, да, нет живых пользователей, нет уже готового продукта, который есть. Но это вообще довольно муторная работа у нас там это называется, может, тестовые корзины, да, вот их всех, а, писать вопрос-ответ правильный для LMки, чтобы потом проверять. А это тоже как это только самим, да? Или можно тоже как-то LMки подключать?
И можно 100%. Но а как бы для вот на самом деле немножко перефразирую вопрос, да? Вопрос про то, можно ли просимулировать пользователя с помощью LMки, чтобы инпуты пользователя у тебя были синтетические и ты на них что-то тестировал.
Ответ, конечно же, в теории, да, 100%.
Но есть одна проблема в этой области. Если твои сгенерированные синтетические вопросы не лежат в том же дистрибьюшене, в котором вопросы пользователя, скорее всего, это довольно бесполезный эксперимент, да. Поэтому, на самом деле, задача, когда ты делаешь, твоя задача — это понять, а как мне сгенерировать что-то, что вообще должно быть похоже на пользовательские инпуты. Ну, у меня был похожий пример, на самом деле, и про который мы, кстати, будем говорить на курсе чуть более подробно, но верхнеуровнево, например, если вы делаете обычно, короче, ваши продукты что-то знают, да, про то, что ваши пользователи спрашивают, например, пример из жизни. Если у вас есть продукт для саппорта, предположим, вы делаете чатбота для саппорта, да, но на самом деле пользователи в саппорт приходят с какими-то проблемами конкретными. Обычно, скорее всего, уже кто-то в компании есть, кто знает хотя бы примерно список этих проблем. Обычно они, например, в вашем продукте написаны где-нибудь в FAQ или, например, у вас там может быть какой-то список статей, да, которые люди могут руками прочитать, и они, наверное, там могут совпадать с вопросами, с которыми могут прийти в чатбота. Вот если вы можете найти такой как бы сид, да, для вашего для вашей генерации, это работает довольно хорошо. Вот, буквально совсем прикладной пример. Представьте себе, у вас саппорт-сценарий и у вас есть уже есть статьи, которые отвечают на вопросы саппорта, просто написанные вручную когда-то специально обученными людьми. Ну, вы берёте эту статью и говорите: "О'кей, в этой статье описана какая-то пользовательская проблема". Да, представь себе, вы говорите это LMке, в смысле, представь себе, что пришёл пользователь, у которого есть проблемы, ответ на который лежит в этой статье. Представь себе, какой первый вопрос он задаст. Напиши мне его. Потом вы ещё берёте этот вопрос, применяете к этому слой переписывания, который превращает это в кривой язык с кучей опечаток, как как люди всегда пишут на практике. И вот у вас уже получилась какая-то разумная генерация, которая, скорее всего, как-то совпадает с тем, что люди в реальном мире будут спрашивать. А вот когда есть, короче, такой сид, с которого можно начать генерацию синтетики, мне кажется, это работает хорошо. В альтернативном случае это превращается в то, что вместо того, чтобы писать вручную вопросы, ты пишешь примеры вопросов в промпт. Ну, и в принципе, на самом деле, пользы от этого не очень много. Да, просто мы ещё можем на этих наших руками созданных эвалах, да, переобучиться, когда мы выйдем в жизнь, ну, в реальный prod вопросы, задачи будут другие.
И. Да, да, да, да, да. Именно поэтому я вот всегда это ровно то, с чего я сегодня начал, поэтому я топлю, на самом деле, за то, что просто вещи в prod руками читать и из-за этого собирать, потому что то, что ты сидя в своей белой башне слоновой кости напридумывал о том, как люди будут пользоваться продуктом, с объективной реальностью обычно совпадает приверняка. На самом деле.
Угу. Понятненько. Слушай, а ну а как вообще с чего начать? Вот если новичку как-то вкатываться в это, да? То есть понятно, что хорошего агента без эвала не получится. Вот. Можешь расскажешь немного про то, как в это вкатиться и немного про курс?
Ну давайте, да. Ну как, как вкатиться? Ну, очевидно, наверное, правильный ответ — это прийти на наш курс, э-э, который, собственно говоря, мы анонсируем на этом, э, замечательном разговоре. Но помимо этого сейчас я, наверное, давайте пока подниму пока на экран, собственно говоря, промку нашу.
Или ты нам уже всё рассказал, и мы уже эксперты? На самом деле, э, честный ответ такой. Я считаю, что я рассказал почти всё, что надо знать, э, базово, но секрет не в том, чтобы знать эти базовые факта, а секрет он в том, чтобы уметь их применять на практике. Именно по этой причине, э, у нас будет мы будем проводить курс. Давайте я сейчас подниму QR-код с ним, чтобы это можно было можно было к нему присоединиться. А вот, собственно, вот по QR-кодику можно в неё перейти. Значит, суть курса будет в следующем. Он будет не теоретическим. Ээ, курс будет, э, максимально прикладным, в котором в рамках пяти сессий мы будем рассматривать примеры того, как прямо руками, эээ, без каких-то теоретических размышлений, как руками и делать, и оценивать, э, реальные продукты, которые в окружающем мире э можно встретить. Мы будем обсуждать примеры, э, саппорт-чатботов, э, примеры full-stack-агентов, вроде того, что мы смотрели на сегодняшней демке, но посложнее, примеры, связанные с генерацией картинок, э-э, и оценку качества для всего этого. И вот все вот эти продукты, э, все вот эти примеры, которые мы будем обсуждать на курсе, мы будем обсуждать их в суперприкладном неформальном формате, в котором у нас всегда будут примеры, связанные с кодом, у нас всегда будут примеры конкретных промптов. Вы в качестве домашек вы будете писать эвалы и улучшать эти промпты. И все эти продукты, все эти примеры, которые мы будем рассматривать, они будут вдохновлены реальными продуктами, которые я в своей жизни видел. Э, и каждому из примеров будет соответствовать прямо конкретная фича в приложении, которое вы вообще можете скачать и поиграться с ним. Ну, в основном это будут какие-то фичи, но, в принципе, они должны довольно хорошо перекликаться и с другими рынками, потому что, в принципе, саппорты делают везде, э, кодинг и картинки до какой-то степени тоже делают везде. В контенте у нас будет четыре продукта и одна сессия про то, как вообще делать операции с этим реально в компании, да, как уйти из того, из своих каких-то личных там Python ноутбуков или каких-то тулзов, э как общаться с проект-менеджментом, как делать вокруг этого операции, э вокруг процесса оценки этих систем э и так далее. Вот поэтому на самом деле приходите на курс. По сути, курс будет, ээ, набором наших friendly разговоров, где мы будем решать какие-то реальные, симулировать решение каких-то реальных жизненных задачек, а не разговаривать про теорию. А вот.
Тут вопрос из чата. Какой порог входа на курс? Подойдет ли для неразработчика или нужны какие-то начальные знания? Не быть профессиональным разработчиком абсолютно нормально, но обязательно нужно знать хотя бы совсем совсем совсем самую базу Python и уметь как комфортно взаимодействовать там, ну, хотя бы комфортно взаимодействовать с кодом условным, да, чтобы он за вас код написал. Там кода мы писать будем очень мало, ну, какое-то количество ограниченное будем, но, условно говоря, весь код, который ожидается — это разные способы простого похода в LLM API, да, потому что примеры там всё же будут упрощённые. И шаблоны кода самих продуктов, которые мы будем оценивать, улучшать, я их буду давать. Поэтому от вас не будет ожидаться, что будет писать какие-то сложные вещи. Но если вы совсем-совсем не программируете, наверное, всё же не очень получится. Хотя можно попробовать, потому что я буду доступен и смогу чем-то помочь, но не факт, что получится получить большое удовольствие. Либо либо придётся выучиться, но это с кодом не очень сложно. А, в принципе, может решить эти проблемы за нас. Да, сейчас в целом очень удобно. Если что-то непонятно, можно всегда спросить. Тебе прямо в чатике расскажут, покажут и даже всё запустят. Ну, по сути, да, вот все примеры, кстати, которые мы обсуждали сегодня, и все вот эти игрушечные демки, я, конечно же, руками ни одной строчки кода там не написал, поэтому на уровне как бы пройти курс, не программируя самому, точно будет можно. Вопрос в том, насколько это будет полезно, но, скорее всего, даже это будет довольно полезно, да, потому что как минимум операционные части и части промптов будут покрыты.
Угу. Ещё вопросы по длительности и стоимости, но я так понимаю, это по QR-коду, да?
Да, да, можем всё описано, мне кажется.
Угу. Ну, супер. Так что, коллеги, приходите.
Проверим. Так, ну что, можно есть какие-нибудь контентные вопросы ещё, про которые можем поговорить?
Давайте почитаем. Я там, в принципе, старался вычитывать, походу, и органично их вклинивать. Ну тогда что, был рад пообщаться, и мне кажется, на этом мы тогда можем заканчивать.
Да, взаимно. Классно подготовился, интересные примеры. Я вообще с удовольствием послушал. Не знаю, как остальные, но мне понравилось.
Вот. Так что, Андрей, большое спасибо.
Да, всё, спасибо. Все, приходите на курс. Мы, мне кажется, если про двадцать восьмого, по-моему, стартуем. Э и на курсе я постараюсь, как бы, моя личная миссия сделать его минимально душным и максимально применимым на практике. Поэтому, если это что-то, что вам интересно, присоединяйтесь. Всё, всем спасибо, всем пока.