LLM Talks. LLM и агенты разработке

Текст, базовое понимание общих принципов. Поэтому мы начнём с минимальной фундаментальной базы и постепенно будем переходить к моделям, их сравнению, агентам, э, всяким толзам и прочему и прочему.

Наш первый раздел, по сути, как раз-таки и называется введение. В нём мы рассмотрим общую базу, рассмотрим какие важные тейки, важные термины, которые впоследствии важно будет использовать и важно их понимать, как это работает.

А самая первая мысль, которую хочется донести, LLM не обладает мышлением, сознанием. Они не понимают нас в классическом смысле этого слова. Ну, в действительности LLM представляет собой функцию, которая принимает на вход последовательность токенов. На выходе она возвращает распределение вероятностей, ну, собственно, для продолжения коммуникации.

LLM не обладает памятью, и то, что, как мы полагаем, помнит LLM, на самом деле содержится либо в контексте, либо в истории диалога, в базе данных, либо в retriраal. В классическом виде без применения каких-либо толзов модель буквально может оперировать только теми знаниями, на которых она была обучена.

Вы наверняка все слышали, что у модели есть какие-то параметры. По параметрам они сравниваются. Собственно, на этом слайде мы как раз-таки можем увидеть распределение количества параметров по современным моделям. Ну, и не только по современным.

Здесь приведена небольшая аналогия параметров модели с синапсами мозга. Это, естественно, не то же самое, но функциональные механизмы схожи по принципу своего действия. А как настраиваемая сила связей между сигналами. Вот. А в правой части мы как раз-таки видим перечисление популярных моделей, в том числе и исторических, с их количеством параметров.

Здесь можно интересным образом проследить прогрессию с течением времени, как мы в девятнадцатом году работали с GPT2 со 117 млн параметров и каким количеством параметров обладают современные фронтир-модели. А важно отметить, что для clotpt здесь указано приблизительное количество параметров, поскольку эти провайдеры сами не раскрывают точного значения, и оно эмпирически вычисляется сообществом. Но разница действительно колоссальная, и темпы развития только набирают обороты.

Все те задачи, с которыми модель современные модели двадцать пятого года могли не справляться, вполне вероятно, что будут справляться модели текущего года. И динамика здесь очень быстрая.

Ещё один термин, с которым, скорее всего, все сталкивались - это токены. А токен - это базовая единица работы LLM. По ним как раз-таки рассчитывается контекст, а длина ответа. Ну, и, собственно, самое важное - это весь билинг.

В верхней части слайда мы можем увидеть, как текст превращается в токены. Ну, а сам процесс он, соответственно, называется токинизацией. На вход токинизатор принял какую-то строку. На выходе мы получаем набор токенов. В данном случае текст Hello World с восклицательным знаком был побит на три токена.

А чуть ниже как раз мы можем увидеть примеры токинизации текста на русском и на английском языке с использованием самого свеженького токинизатора О200K. Вот небольшое отступление в сторону динамики. А этот токинизатор в презентации появился буквально вчера. Здесь был совершенно другой пример, с другими показателями и с другой токинизацией, другим принципом разбиения текста на токены.

Но вот совершенно недавно как раз-таки вышел, даже не знаю, уместно ли здесь говорить, вышел, начал использоваться в GPT 55 токинизатор 200K, который чуть лучше токинизирует текст на русском. И несмотря на это, мы всё равно здесь наглядно можем увидеть, что по сути тот же смысловой текст на русском языке занимает больше токенов, нежели этот же смысл в виде этой строки на английском языке. А примерная разница как раз-таки в один и два раза.

Ну, фактически этому есть две причины. Английский текст передаёт смысл плотнее, ну, и сам токен включает в себя больше символов. А важно отметить, что поскольку вся стоимость использования рассчитывается в токенах на входе и на выходе, очевидно, рационально использовать промпт на английском, особенно там, где критична стоимость, потому что экономия на здесь крайне очевидна.

Чуть посмотрим вообще на алгоритмы токинизации. Есть глобально три домена. Их можно выделить вот как три семейства токинизации. А BPE BP он объединяет частые пары символов. Wordpiece использует критерий вероятности, а Sentence Spins, по сути наиболее удобный токинизатор для мультиязычных моделей, за счёт того, что он некоторые символы и байт последовательности может преобразовывать как нижнее подчёркивание.

Важный термин и в целом механизм - это эмбединги. Абединги это, по сути, способ представления слов, предложений в виде числовых векторов. А эмбединги решают задачу поиска по смыслу. Мм, как видно на слайде, когда, например, пользователь ищет слово фразу снижение расходов, что по сути по смыслу подразумевает то же самое, что и оптимизация затрат. Но текст выглядит совершенно по-разному. Он состоит из разных слов. И вот как раз-таки благодаря эмбедингам решается задача смыслового понимания, а того, что это близкие по смыслу контекста.

Ну как это работает, в общем-то, эмбединг по сути превращает текст в вектор. А мы можем математически рассчитать геометрическую близость двух векторов. Ну, и, соответственно, путём вычисления косинусного расстояния между этими двумя векторами мы можем понять, что это два выражения близких по смыслу, хотя они написаны по-разному.

И вот у нас в правой части есть пример. Юзер спрашивает: "Как снизить расходы компании?" И вот мы видим табличку из четырёх четырёх строк, в которых как раз-таки рассчитано косинусное расстояние к каждому из других предложений. Что примечательно, третьим пунктом стоит текст на английском. Это означает, что эмбединги также помогают находить близкие по смыслу фразы и выражения на разных языках. Это очень крутая, очень полезная, в целом очень полезный инструмент. Даже механикой, наверное, это можно было бы назвать.

Ну и в целом, а чуть про вектора. Абединзинги-то сами по себе очень полезны, но в продакшн среде чаще говорится о векторах и инфраструктуре вокруг них. А слева мы видим три типовых сценария. Семантический поиск вместо ключевых слов. Ак используется, когда документация превращается в векторы, подмешивается в контекст моделей. Ну, и аналитика по неструктурированным данным без ручной разметки.

Справа здесь, по сути, представлена схема того, как у нас работают оффлайн-онлайн фаза. А давайте рассмотрим пример офлайна. А документы режутся на чанки, а по ним прогоняются через bedдиing модель ложится данные ложатся в вектор DB. А в случае с онлайном запрос тоже эмбедится, ищется похожие фрагменты. А топке - это по сути топ релевантных результатов, уходит в lлmм, и только тогда у нас формулируется, формируется ответ.

Пару слов про кластеризацию. А если в целом поиск отвечает на вопрос, как найти похожее, да, по смыслу, а кластеризация, она формулируется как как устроена вся весь массив данных. А вот на нашем примере есть какая-то система с тикетами поддержки. Саппорт, саппорт, саппорт тикеты. которые они были сгруппированы по нескольким доменам, по нескольким кластерам. Это, видимо, вопросы по платёжке, по доставке и ошибки приложения. А, соответственно, каждая точка, которая не вошла в этот в этот кластер, она относится к тому, что не что по векторному расстоянию находится далеко от тех точек, которые вошли в этот кластер. Ну, и, соответственно, их уже сложнее охарактеризовать как что-то, какая-то сущность, документ, относящийся к этой категории.

Фактически Pйpeline строится следующим образом. Мы получаем бединги, затем HDB scan, а потом LLM labeling. LLM labeling он как разтаки отвечает за навешивание вот этого лейбла по типу payments, delivery appearers для того, чтобы как-то, а, чтобы самому кластеру дать какое-то человеко читаемое имя.

Это был последний слайд по первому разделу, в котором мы познакомились с терминами. А давайте сейчас перейдём ко второму разделу. В нём мы посмотрим уже более подробно на модельки. И, а, касаемо этого, можно в целом выделить две большие группы моделей. Это, э, модели по способу размещения, либо облачные, либо локальные. Их можно сравнить в лоб. По сути, и в одной, и второй группе есть свои преимущества, свои недостатки.

Облачные модели нам позволяют сразу начать их использовать вот как есть, без каких-то инвестиций в инфраструктуру. Мы всегда получаем последнюю версию модели. Нам не нужно запариваться на тему того, что требуется как-то обновить обновить сервисы локальные где-то в нашей инфраструктуре. Ну, важно помнить, что при использовании облачных моделей все данные уходят к провайдеру. Для некоторых сценариев использования это может быть неприменимо для каких-то критичных узлов инфраструктуры в особенности. А билится каждый запрос к онлайн-модели, расходы будут постоянно расти. А не будет такого, что заплатили один раз и можем пользоваться достаточно долго. То есть по мере потребления растут, соответственно, расходы, затраты на а эту категорию расходов. Ну, и есть актуальная проблема - это доступность самого сервиса, а для каких-то регионов. А это тоже нужно учитывать при выборе того, какую модель следует использовать. Это прям очень актуальный вопрос.

Ну, и по локальному контуру можно отметить, что данные не покинут периметр реанизации, периметр сетевой, сетевой контур. А после покупки железа, соответственно, не нужно дополнительно платить за каждый токен. Один раз инвестировали вфру, переиспользуем её длительное время. А мы можем контролировать квантизацию, файнтюнить модельки. Соответственно, это всё на нашей стороне. А, ну, нюансы, соответственно, тоже видно на слайде. Для этого действительно нужны допрасходы на инфру. Инфру нужно резервировать, её нужно, а, где-то в серверной поднимать, а под это, соответственно, тоже допрасходы, а, расходы на персонал, который это обслуживает. Ну, и, очевидно, у локальных моделей, а, скажем так, меньше мощность, пока мы других терминов не ввели. А они, скажем так, отступают в своей мощности от фронтир-моделей облачных.

В каждом, в каждой из групп вы видите самые очевидные примеры лучших представителей жанра, так сказать. Ну, и в конечном итоге выбор между облачной и локальной моделью, он стоит скорее как инженерный. Важна ли нам приватность? Каковы бюджеты на использование? Какой класс задач решается? какие допустимые задержки, скорость ответа и так далее. Серебряной пули здесь нет. Нужно ориентироваться, исходя из наших потребностей.

А теперь чуть поговорим про параметры моделей. А сколько у модели параметров по сути столько весов, которые нужно держать в видеопамяти в момент запуска. На этом слайде вот всё сводится к простой оценке. По формуле, которую вы видите справа. Можно, в общем-то, вычислить по количеству параметров, э, сколько байт приходится на один параметр. И по коэффициенту квантизации мы можем вычислить потребление видеопамяти.

А, небольшое отступление в сторону квантизации. - это, а, уменьшение точности хранения весов, а, где, по сути, мы можем использовать меньшее количество, а, параметров, тем самым сократив объём потребляемой видеопамяти. А, ну, естественно, качество будет страдать в большинстве случаев, но опять же это нужно прикидывать под конкретные сценарии использования. Квантизацию обычно вот как разто выбирают весьма осознанно.

А можно отметить, что фронтир-модели, они потребляют просто терабайты видеопамяти на свои кластера, и это прямо колоссальные объёмы ресурсов, которые выделены под функционирование этих моделей. Прям разница она крайне колоссальная в сравнении с моделями, которые можно локально у себя захостить.

На этом слайде мы по сути видим табличку. Это срез на момент двадцать шестого года, вот на текущий месяц, на апрель. Это не совсем рейтинг. Это по сути текущая средст ситуации. Потому что она меняется очень динамично. Уже завтра может выйти новая версия какой-нибудь модельки, у которой будет шире контекст, появятся другие возможности и так далее. Вот, по сути, мы видим вот, да, многомиллион, мы видим миллионные контексты у закрытых моделей. Мы видим здесь специфику их работы, возможности, специализацию. А, но тут скорее смысл всего вот этого слайда, а, показать, что лучшей модели нет. Ну, объективно, что мы можем сказать, что это лучшая модель. А есть модели, которые соответствуют конкретным задачам, и нам в первую очередь необходимо исходить из этого. Причём не всегда какие-то рекомендации по выбору могут дать точный точное решение для вашей ситуации. В большинстве случаев нужно опытным путём определять, что подойдёт именно вам, именно под ваши задачи либо под задачи бизнеса.

И, соответственно, здесь на этом слайдике, по сути приведён график. Это ориентировочная шкала по распределению моделей в диапазоне от утилитарных до фронтир. Соответственно, те, кто правы, те круче. Если баллы находятся близко, вот, например, как между Джемини и ПSI V4фш. По сути, значит, что это сопоставимый класс моделей. Ну, и разброс в данном случае он очень сильно зависит вообще от промта, который используются, инструменты, которые подключены, ну, и какие задачи вообще решаются. Вот этот вот срез он создавался как раз-таки по бенчмаркам на каких-то тестовых данных, которые были переиспользованы для всех, а для всех этих моделей. А, ну, по сути, опять же, напомню, что самая мощная модель не всегда самая лучшая для конкретной задачи. Нужно учитывать абсолютно все факторы. И, ну, естественно, самый важный из них, наверное, наиболее важный из них - это как раз-таки стоимость. Вот поэтому важно принимать конечное решение о том, какую модель использовать на конкретных конечных тестах.

И у нас здесь есть небольшая матрица выбора. А на примере того же сценария про работу саппортом, а мы можем выделить, а э некоторые параметры, критерии типа latency, стоимость токена, количество параметров, контекстное окно. А в блоке constraints вы их увидите. Ну, и, соответственно, в зависимости от комбинации параметров, ну вот ещё критерии quality, price, latency, instructions и context, мы можем путём комбинирования этих параметров прийти к выбору какой-то каких-то конкретных э моделей, которые подойдут под наши задачи. Ну, и справа есть небольшое перечисление. Если для нас важна стоимость и задержка, но при этом не так важен потолок качества, то можно предпочасть V4фш или GM V3фш. А, ну, собственно, собственно, вот весь месседж этого слайда.

Перейдём дальше. А третий раздел у нас уже такой более серьёзный. Здесь мы поговорим про агентов и слово передам Егору на эту часть.

>> Егор,

>> да, да, спасибо. А всем привет, с кем ещё не поздоровался. Сейчас, да, сейчас будет такая тема более как надстройка на ДЛМ, потому что агент - это, э, как мы знаем, обвязка на ДЛМ. сами агенты ничего не думают, не принимают никаких решений. Как мы видим на слайде, вот слева как раз-таки у нас написана модель. Это движок рассуждения. А, собственно, оно так и строится, что на уровне модели она сама только принимает решение. То есть агент - это такая связь трёх модулей, грубо говоря, из инструментов памяти и контроля. Ну, как вот на на слайде написано.

Собственно, давайте больше поговорим про инструменты. Это самая интересная часть у агента, как я считаю, потому что в целом у агента инструменты работают по средствам MCP серверов. Ээ одно из, точнее, одна из систем. А в данном кейсе у нас по контролю именно по точнее, извиняюсь, память у нас работает тоже как отдельный модуль. То есть, к примеру, у нас есть модель, допустим, chat GPT 5.5. Он обращается к инструменту ViewФай. viфаile смотрит, отправляет обратно контекст лмки. Лонка отвечает уже и принимает решение, то есть нужно ли ещё какой-то инструмент вызвать или не нужно.

А самое простой самый простой пример, которым, наверное, мы все сталкивались - это когда в чате мы спрашиваем, допустим, э, ну, к примеру, какой сейчас праздник, да? Агента, точнее, у модели нету информации о всех праздниках, так как они могут и изменяться, допустим, мало ли вдруг модели обучена, допустим, там на данных, 2024 года, в 2026 году появился новый какой-то праздник. А модель принимает решение обратиться к инструменту. То есть у неё есть инструмент, допустим, это открыть поисковик, забить какие-то туда данные, к примеру, найти праздники на, допустим, вот май 2026 года, а оно получает данные из Тулзы, Тулза передаётся обратно в контекст, подмешивается, и Лэлмка уже принимает решение, что ответить пользователю. То есть это имеется в виду подмешивание в контекст. Как разтаки вот речь немного о памяти.

Если привести пример более сложный, давай из программирования, это конкретно все мы используем, я думаю, ну, большинство тут, скорее находящихся используют курсор для написания кода или хотя бы раз использовали. Это более продвинутый пример. Там тулзов точно больше, чем просто обращение в поисковик. К примеру, это тоже, как я приводил изначально пример, это считывание файлов, запуск каких-то команд и так далее в целом. А, но тут уже важно подметить, что в данном случае применяется модуль контроля, потому что иначе у нас могут быть лимиты по циклу, как вот написано, лимиты цикла или бюджет. То есть может агент просто выйти за рамки бюджета или также зациклиться. Это классический пример, что агенты бывает зацикливаются на одной и той же задаче, не могут из неё выйти. А в данном случае вот выступает контроль и в целом у нас есть ограничения какие-то, то есть это стопусловия ретрая и rails, и политики доступа. Это больше речь уже о том, когда модели, допустим, запрещено выходить какие-то базы данных или ещё что-то.

А в целом, наверное, проагенты. Про агенты - это вот самая самая основа в плане понимания того, что это не LM. Агент - это надстройка надм, то есть это как харness, её, то есть обвязка. Можно это так закрепить для себя. А дальше я бы хотел перейти к workflow агента, чтобы больше наглядно это рассмотреть. То есть не так, как не в целом на словах, а с наглядным примером.

В данном случае у нас пример идёт это вот как есть у агента цель. То есть это пользователь запрашивает оформить возврат по заказу, аэ агент обращается к создаёт план. То есть плана план - это контроль, можно сказать, который у нас будет возвращён. То есть пока план не выполнится, ну и цель не закроется, а агент не перестанет перезапрашивать клэмке какой-то контекст передавать. В общем, ретрая не закончится, стоп-цикл, стопцикла не будет. То есть мы видим, что действие это у нас естьза. Мы запрашиваем метод из, ну, грубо говоря, какой-то метод получения статуса заказа. Потом возвращается у нас контекст в LЛМ с помощью агента. То есть агент обращается к М снова и М отвечает, что заказ отменяна плата прошла. Дальше M принимает решение, нужно ли дальше продолжать вызывать какие-то тулзы или не нужно. Если не нужно, то принимает решение остановить цикл ээ или трая больше не нужны. То есть цель выполнена. Это вот у нас пятый пятый пункт - это то, что можно запросить подтверждение. И результат, собственно, возврат создан. То есть это когда уже всё, то есть цикл закрылся, цель закрылась, агент выполнил свою задачу. Такой вот простой пример для понимания, наглядный.

А дальше вот я в самом начале сказал про MCP. Это некий механизм, некий протокол, на котором строится строится взаимодействие с внешними сервисами. Если простой пример привести, то это, например, Фигма. Допустим, мы можем из фигмы в код, из кода в Фигму получать какие-то данные с помощью MCP-сервера. То есть это некоторая, а некоторый набор функций, который удалённо работает по протоколу внутреннему JSON RPC. Он можно ознакомиться слева на схеме. А и это всё работает в целом в такой вот обвязке. То есть у нас есть некий MCP-клиент, он обращается к MCP-серверу, у которого есть ресурсы, инструменты и промты. Это, если более конкретно, можно ознакомиться также на визуальном примере насчёт инструментов и ресурсовтов. Э вообще в целом, зачем они нужны, э, и для чего это вообще всё создано в плане вот есть же агенты, и зачем это всё как бы ещё нагрождать и создавать отдельный протокол от этого. А для того, чтобы всё это можно было интегрировать, то есть разработчики отдельных сервисов могут сделать свой MCP MCP-сервер, с помощью которого агент может обращаться к нему. А в том же курсоре, Клоде и других других популярных моделей в целом ADE можно настроить MCP сервера, то есть обращения к ним. Те же Marketplйс плагины, может кто-то сталкивался, не сталкивался в курсоре настраиваются. тоже с помощью, точнее, они интегрируют тоже MCP, там везде примерно используются сервера. И этот протокол как минимум. Как-то так.

А дальше, наверное, с агентов самое самое важное, да, это промтинг, точнее. Перейдём сейчас как раз к этому, к тому, что, а, как в целом составлять промты, какие лучше примерно лучшие практики есть примерно, потому что у нас каждый день что-то новое меняется, как бы сфера не стоит на месте. И что может быть сегодня без практики, завтра уже может и не имеет смысла. Это элементарный пример. Я приведу и потом перейду к слайду. Как раз это насчёт того, что раньше раздувался, например, файл, агентмд D или дополнительная документация загружалась в репозитории. Сейчас это не имеет уже смысла. Ээ в целом существуют другие механизмы. Об этом я расскажу далее.

Собственно, а конкретно вот на этом слайде можно ознакомиться с тем, что самый самый базовый хороший принцип - это объявлять контракт с моделью, как написано. То есть это роль плюс цель, ограничение области и разложение контекста. Конкретно про разложение контекста будет тоже дальше более подробно, но если вкратце, это планирование модели, то есть, чтобы был чёткий план, как как агент должен следовать выполнению задачи, не давать ему абстрактных каких-то промтов о том, что нужно сделать что-нибудь, но я сам не знаю, что, грубо говоря. А, ну, и как вот на примере справа написано B practice, собственно, посмотри метрики Q1. Ну, то есть квартал первый. Это не очень хорошо, потому что как бы модели не ограничена область. Как раз-таки это об этом. Вот. И более-менее на данные текущее на текущее время более-менее правильный пром.

Дальше довольно такая интересная тема в плане экономии бюджета, потому что, ну, как Дима сказал, на токенах у нас держатся не только мбединги, кластеризация и так далее, всякие интересные механизмы, а ещё и бюджет в целом рассчитывается тоже на токенах. То есть чем меньше мы токенов будем управлять и тем меньше бюджета мы, собственно, потратим. Но не всегда значит, что меньше токенов - это лучше, да, потому что контекст всё равно режется. А самое самая, наверное, популярная вещь - это сжатие контекста. Я думаю, все вот, кто пользуется курсором, не раз замечали, что если в одном чате агента писать много сообщений или в целом довольно долгую сессию поддерживать, то, э, контекст раздувается до больших размеров, и такой небольшой самре вылазит, то, что контекст был сжат. Что вообще такое сжатие? Это буквально самаризация контекста, точнее вычленение из него главной сути всей сессии, собственно, переход, перевод её в более жатый формат, удаление мусора, грубо говоря, можно так, наверное, сказать. А, и второй пример - это ограничение на мак. То есть мы ограничиваем количество токенов, выходящих из моделей. Это тоже, собственно, будет экономить бюджет. только это уже с более серьёзной потерей качества, чем сжатие контекста, потому что тогда модель может просто сама убирать какие-то части ответа.

А тут мы перейдём к типам промпта. Э-э, самые простые примеры, всем, наверное, известные - это Zero Shot, One Shot и F Shot. Это элементарные самые, э, базовые схемы промтинга, когда у нас есть одна какая-то простая задача, буквально там изменить текст на странице один, грубо говоря, и модель, а именно агент с моделью, выполняет напрямую действие изменения текста без каких-либо относительных вводных данных.

С инструкцией это уже посложнее. Это в целом, когда у нас есть какие-то какой-то системный промт, какой-то дополнительный контекст пользователя. Возможно, да, как это написано ещё и инструменты с этим используется. А с контекстом это когда туда подмешивается ещё какие-то подмешиваются какие-то данные. Это когда приводил пример с агентами насчёт того, что может какой-то файл быть считан с помощью толзы, а и она под будет подмешано в контекст.

Про качество промтов в целом, как этот сскать большие задачи. То есть, если задача состоит из нескольких, э, из нескольких частей и и вы это понимаете, то есть нужно разделять и декомпозировать и разбивать на дополнительные планы, э, и, возможно, иной раз декомпозировать эти же планы, потому что, как показывает практика, это самое лучшее решение для того, чтобы модель прям максимально чётко прошлась по тому, что вам нужно. Основные паттерны промтов - это вот, как ээ говорил, да, насчёт декомпозиции и плана. Это самое самое, наверное, важное, что стоит подчеркнуть из этого, что задачи нужно расписывать максимально подробно, насколько это, ну, возможно в разумном, конечно же, в разумном виде, чтобы не прямо досконально, но всё же, а, чтобы в модели был чёткий план действий. То есть, самые бетпракти - это не говорить буквально там, придумая за меня что-либо, если это не творческая какая-то задача в плане дизайна или ещё что-то.

А про раг - это про знания конкретные, про модуль знаний, это больше про агентов и то, что они могут подмешивать в контекст какие-то данные из файлов из и ещё откуда-то запрашивать с интернета и так далее. Ещё, наверное, я бы хотел тут важный важный довольно мдуль выделить это конкретно, когда аm рассуждает, потом вызывает снова какие-то инструменты в агенте и оркестрирует это всё. То есть, ээ, не сразу принимает прямое решение, а идёт в рассуждение, что-то до довыясняет у пользователя и потом снова обращается в план. Это тоже довольно важная часть. Это больше, наверное, если из практических примеров, когда человека напрямую спрашивают IDA или ещё что-то, что конкретно имелось в виду. Наверное, как-то так. Основное основное рассказал, да? А файл, который я упоминал агентством D, это про то, что раньше его возможно было, возможно, он был

гораздо больше, чем сейчас. Это про то, что в любой момент те данные, что вот я сейчас рассказываю про агентствомД, могут стать неактуальны. А конкретно тем, что вот сейчас best practice - это ограничивать небольшим контекстом в виде 200-300 строк максимум в агенцим. Это как описано, зачем, что даёт и как писать. То есть нужно напрямую ограничить область м область ээ модели, чтобы она не выходила за контекст её. Это повышает в целом её отдачу. То есть infренс и более конкретики, меньше меньше проблем с неожиданными результатами.

Возможно, самая, наверное, интересная часть в разделе промкинга - это скилы. Я думаю, многие слышали, особенно те, кто работают с клодом, потому что скилы изначально появились в клоде, а конкретно утро. Скилы - это в целом набор каких-то знаний о фреймворке, области и так далее. Самый явный пример скилов - это, наверное, можно предположить сначала из технической части, потому что это всё-таки появилось впервее. Там, к примеру, фреймворки обновляются чаще, чем переобучаются модели. И чтобы поддерживать актуальность написания кода моделью, нужно обновлять скилы и её документацию. Элементарно, когда человек добавляет ээ скилл в тот или иной репозиторий к модели, то она подхватывает документацию именно из него и берёт последние актуальные данные. Ну, если само собой скилл тоже обновлён, но большинство разработчиков, вот на примере Next, который тут, собственно, представлен, они обновляют лично свои скилы и буквально пишут об этом при инициализации проекта, что если используете нейросеть или, ну, в целом LН, да, то используйте скилы для актуализации.

Думаю, думаю, могу Дим снова вернуть тебе на твоё слово.

>> Да, снова забираю слово. Егор, спасибо. Получилось очень круто. А следующий раздел, он по сути приурочен как раз-таки к обсуждению и просмотр таких самых ярких способов применения в продакшене, э, компаниями, гигантами, применение агентизации, да и в целом LЛM в разработке. Поэтому здесь мы начнём с того, что для себя чётко поймём, что агентизация может применяться вообще для любой сферы деятельности, роли в команде и так далее. Здесь на слайде очевидным образом перечислена разработка, тестирование, аналитика, поддержка deпс, sreпроцессы. Ну и по несколько примеров задач, которые можно решать в рамках этой роли с использованием агентов. У нас был, как вы помните, ранее было голосование, кто насколько применяет в целом агентов и ЛМ в своей деятельности трудовой. И была некоторая категория ответов, что оно не применимо для каких-то конкретных задач. Прямо буквально ответ звучал как это неприменимо для моих задач. Поэтому очень интересно будет в целом совместными усилиями попытаться найти всё-таки, наверное, способы либо решения, подискусировав во второй части этого доклада. Поэтому можно заранее заготовить стрики, и мы по ним поговорим.

А я выделил четыре, на мой взгляд, самых интересных примера внедрения агентизации у крупных компаний. На самом деле их кучи, а они очень интересные. Если кто-то прямо ярко заинтересовался, я могу скинуть информационную базу, которую я наковырял за всё за время подготовки. Можно будет узнать подробно, почитать побольше. Аэ, собственно, давайте вот поподробнее поговорим про каждый из этих кейсов.

А, на примере компании Stripe, а, которая процессит платежи, э, в интернете, я думаю, многие с ней сталкивались даже при покупке подписок на любую из облачных LLM. А по сути, >> кто-то даже интегрировал, >> да, кто-то даже интегрировал. В исходном состоянии инженеры STE тратили до 80% 85 да про своего времени на рутинные повторяющиеся задачи, типа обновление библиотек, рефакторинг, отправки тестов, под актуальные фичи и так далее. По сути, это отъедало рабочее время, повышало доставку печей по основному продукту, а объёмы, соответственно, устраи колоссальные, как вы все понимаете. А их решением было создать фабрику миньонов, которая работала таким образом. А их менеджер или сотрудник в Слаг отправляет задачу агенту. На 10 секунд поднимается изолированный DVБОX, в котором мультиагентные системы. А мультиагентная система - это оркестратор, который знает контекст, который отдаёт команды специальным агентом, который уже, собственно, генерит код, запускают тесты, запускают пайплайны и так далее. Так вот, а эта мультиагентная система по сути решает эту задачу, оркестрируя, а оркестрируя декомпозицию по плану. А автономно создаётся ветка, агент пушит изменения, запускается вся Cка, создаётся PR по заданному шаблону. Ну и по сути человек получает готовый пулреквест. человеку остаётся заревьювить, а, определить, что в целом задача решена корректно и смёрзть. То есть какие-то рутинные задачи закрываются именно так. И, э, вот видите такой чпок 1.300 плюс а пиаров от LLM в неделю. Это тот объём, который они делият вот с помощью этой схемки каждую неделю. А в процентном соотношении, если я правильно помню, это 20% от 20% от общего числа ихр.

Идём дальше. Uber. А тут, наверное, можно сразу начать с того, чего они достигли. Они сэкономили больше 21.000 человек и часов, а за счёт своего пайплайна валидатор Autocover Review. У них не самая лучшая инфраструктура, что они признают по части, а покрытия тестами. У них очень много эмпулреквестов на кодрев. А по тем данным, которые я нашёл, это 65.000 а пиар в месяц. Ну это всё выливается в chен реквесты. Даже здесь это сказано. А каждый change request, скорее всего, под собой держит какой-то будет содержать пиар. А, соответственно, их пайплайн решает задачу тоже в изолированном окружении, которое автоматически поднимается, а задача решается. А на втором шаге в автоcover она покрывается тестами, э, это изменение, а на следующем шаге вызывается ревью. Ну, по сути, отдельный агент, который ревитру все изменения по по фиче, по покрытию. Ну и, соответственно, создаёт последующий пиа.

У Майкрософта тоже достаточно интересная ситуация. У них очень сложная кодовая база. У них, по сути, миллионы строк на C#шарпе, на плюсах, на ассемблере. У них десятки платформ, больше 7 млн разработчиков. И по сути их продуктами пользуются миллиарды людей. Объективно им косячить нельзя, если выражаться простыми словами. И они очень активно, кстати, публикуют информацию о том, как они внедряют агентизацию в свои процессы. Они покрывают этим, а, хардкорным путём большинство из своих процессов. тоже пилят код. Агенты прогоняют пайплайны, агенты создают пиары, но у них во главе во главе угла стоит кодрев, человеческое кодрев высококвалифицированными инженерами. А то есть код генерится быстро, покрытие быстро, а все тесты вызываются, прогоняются быстро, но конечное решение всегда принимает инженер высокого класса.

И интересный пример с Airbnb. А они обновляли фреймворк-тестирование, переписывали 3.500 тестов, на которые закладывалось полтора года. С помощью своей фермы агентов и оркестратора над ними они выполнили задачу за 6 недель. Красота.

Ну и, собственно, история успеха - это круто. Но для того, чтобы хотя бы приблизиться к чему-то подобному, нужно, а, понимать, что под этим стоит. Я когда рассматривал прочее прочую историю успеха от других компаний, как раз-таки в основном натыкался на то, что на главный тейк компании годами, некоторые даже десятилетиями инвестировали а большие деньги в свою инфраструктуру, в DevOps, в Cку, в автотесты. Ну и, соответственно, это стало таким очень хорошим плацдармом для того, чтобы на это всё посадить, скажем так, агентов для того, чтобы решать задачи, валидировать результаты.

А здесь есть набор важных важных условий для того, чтобы, ну, успешно применять в целом вот такие пайплайны по разработке автоматизированной использованием LLM. Очень важно иметь качественные C, CD и дефбоксы, где это всё будет рантаймиться. А важно иметь тесты линтеры, а важно отслеживать, сколько на всё это уходит денежных средств, устанавливать лимиты, а, фиксировать в целом, а, доступность всей этой инфраструктуры, ну, и обладать ну вот, как мы видим, MD, MCPшки к нужным системам. А я бы сюда добавил, наверное, ещё какую-нибудь базу знаний, базу документации. А, ну, и, собственно, без этого будет очень сложно. И мы прямо на перечне стопфакторов можем это наблюдать, что если у нас всякие билд всегда зелёный, даже если он не сбилдился, а для агента нет а справедливого маркера о том, что всё прошло успешно, поэтому должна быть надёжная верификация. обязательно, а, должен быть обязательно изолированный контур, потому что агент очень легко может дропнуть даже там родовую базу, как мы скоро выясним. Поэтому все подобные э истории запускаются только в изолированных окружениях, на которые даже люди не ходят. Аа, соответственно, нужно чётко понимать метрики того, что эта задача решена, что она соответствует нашим критериям качества. Для этого это всё должно быть определено, потому что задачу можно решить, как мы знаем, 10 строчек кода, можно в 200, а можно притянуть в 15 библиотек устаревших. В общем, нужны критерии качества, которые будут валидировать конечный результат. Ну и обязательно не стоит доверять на 100% конечное решение всё равно должно приниматься человеком. И важный итог, он в правом нижнем углу находится, что у нас должна быть инфраструктура доверия изменению, и это важнее, чем размер самой модели. А если мы можем чётко понять, что результат работы правильный, соответствует всем требованиям и условиям, а это гораздо важнее, нежели использование какой-то фронтир-модели, а для решения этой задачи.

Ну, что, в общем-то, и очевидно. История успеха - это круто, но также в нашем мире существуют и факал. И это тоже очень достаточно показательные, интересные примеры. Их очень много, но здесь я отобрал наиболее интересные, которые наиболее интересными показались нам. А я расскажу про парочку из них. А с самой первой плиточкой, я думаю, сталкивались абсолютно все, даже если этого не примечали. А когда вы вбиваете любой поисковой запрос в Google, а самым первым блоком вы видите в результате ответа сгенерированный лэмкой ответ. И вот был этап, когда там, во-первых, было очень много бредогенераций, было много вредных советов с каких-то нерелевантных источников. Ну, и соответственно, много курьёзных ситуаций на этом фоне возникло.

Вторая плиточка рассказывает нам про то, как один, а, фаундер стартапа по сути ковырялся в инфре с использованием агента. У него не было настроено никаких стопфакторов. И агент, подумав, что он находится в безопасной среде, дропнул продовую бдшку. При этом был дропнут volume backup, что, собственно, привело к тому, что у них сервис проставил такое достаточно продолжительное время.

Интересный пример, как, э, зациклились агенты на 47.000 долларов, когда они переписывались 11 дней в бесконечном цикле без лимита итераций и даже не было каких-то алёртов по бюджетам.

Пример, когда вот в этой плиточке предпоследний, а в саппорт бот обратился пассажир авиакомпании, а уточнив, действуют ли у них скидки по скорбному тарифу, скажем так, для перелёта а в другую страну по скорбному случаю. Чатбот ответил, что да, вполне, конечно, но достаточно забавно было ситуация, когда он в аэропорту узнал, что это действительно нет. Ну, и вокруг этого, естественно, начались судебные тяжбы. Что как так? Я на это рассчитывал.

Ну, и один из чатботов, а дилера по продаже автомобилей продал Chevrolet Tacha за 1 доллар через prompt ejection, от которого не было защиты. И вот в каждом из этих блоков мы, в общем-то, видим как раз уязвимость, чего не хватает, как можно было бы это побороть, как этого избежать. Поэтому при внедрении агентизации важно как раз-таки исследовать вот эти классы риска и принимать соответствующие контурмеры для того, чтобы этого не происходило. Потому что на каждый случай, на любую утечку данных, на проomp injection, на высокие привилегии, а всегда есть контрмера, которую крайне важно применять.

И давайте начнём плано переходить ко второй части. А в этом разделе, возможно, вы в целом обратили внимание на стилистическое оформление этой презентации. А здесь мы слегка расскажем, с помощью каких инструментов она была сгенерирована, а как мы используем в целом инструменты, доступные нам. Ну, и возможно, кто-то полезное что-то почерпнёт отсюда. Я снова передаю слово Егору, который нам расскажет про это поподробней.

>> Да, тут, как Дима подсветил, мы расскажем в целом, как мы вот начинали генерировать эту презентацию. Эта презентация конкретная стилистика сгенерирована полностью нейросетью. В целом блоки придуманы нами, но наполнение тоже отчасти сгенерировано нейросети с, наверное, процентов 60. Э самое, наверное, интересное, что вот clotддизаign вполне справляется с генерацией сайтов прототипов, но плохо справляется с генерацией презентации, ваншот фронтом, даже с готовой структурой. А из-за чего нам как раз-таки пришлось перейти в курсор для более точечных правок даже последовательно, так как курсор тоже это больше как бы для для в целом для программирования для HTML правок. Сама презентация к слову написана на HTML. А не очень справлялся в написании текстов даже с сменой модели на GPT 5.5. Хоть, хотя и странно, что в целом модель обычная GPT нормально справлялась с этим в, собственно, на сайте Open А и в итоге, как заключающий этап, мы перешли вообще к использованию кодекса, потому что в визуальном отношении, в отношении качества реализации он получился в лидирующих позициях. То есть он и нормальны тексты где-то генерировал, правил под наши нужды, и слайды генерировал тоже по структурности и считываемости лучше. В общем, вот как-то так получилось.

Почему, кстати, не уточнил, почему от Клода изначально отказались сразу практически это потому что у него актуальность текстов. Не знаю, может быть, нас поправят в этом плане в конце, потому что будет обсуждение, но клод генерировал все, весь текст 2024 года, и у нас с Димо закралось как раз подозрение насчёт того, что, возможно, обученная модель была примерно в то же время, конкретно использующаяся для клоддизайна. Вот.

Дальше я бы хотел рассказать больше про наши в целом выводы, какие инструменты вот лучше применять, но это не конкретно только на презентации основано, само собой. А я бы хотел уточнить, что, наверное, лучше всего использовать для стилистики это точно clддизайн либо кодекс, либо сейчас недавно вот вышло буквально неделю назад это Gemini 3,5. плюсом Google i Studio. Оно тоже невероятно генерирует хорошо дизайн. В целом стилистику задаёт тоже неплохо, но ни то, ни другое не справляется с нормальной структуризацией. То есть какую структуризацию ты ему не выдашь, хоть всё идеально распишешь досконально, всё равно структурировать он это грамотно не сможет. Придётся каждый слайд прорабатывать или там какие-то блоки отдельные на на то, чтобы он это реструктурировал. Самое интересное с теми же лендингами, прототипами, сайтами, то есть где у него большее количество обучения было, о справляется великолепно. А конкретно вот я бы ещё выделил, наверное, про актуализацию содержания, потому что к этому довольно большая часть времени прилагалась. У этого также я бы немножко расширил этот этот блок насчёт актуализации. Все нейросети, как мы знаем, страдают проблемой того, что у них интересные текста генерируются в плане того, что видны виден текст, когда его сгенерировала нейросеть. Если человек больше, наверное, птися раз, возможно, обращался к моделям. С этим решением тоже довольно довольно хорошо справляется, кстати, модель ча, но с правильным промтом, также как и Gi. У Gini меньше вот таких проблем, как как мы заметили вот по всему э моменту генерации.

А, Дим, я, кстати, хотел в целом думал ты тоже что-то добавишь. Вроде говорил насчёт того, что

>> Да, я поддобавлю. А путь вот по билду презентации был такой достаточно тернистый, но весьма опытный. А потому что мы пробовали действительно и ваншотать, и выборочно править всё в clдизайн, но usage-лимиты фактически выедаются очень быстро, и дизайн modд в целом там оказался забагованным. Мы это делали там, наверное, через спустя неделю либо две после такого паблик-релиза. И в дизайн моде, когда выбирали компоненты, которые подлежали правке, а фактически не было связи у контекст в контексте с а этим компонентом. То есть, по сути, в промпт попал только комментарий. А касаемо, а, дизайн мода в курсоре, а, возможно, кто-то с этим не сталкивался, но я рекомендую обратить на это внимание, особенно кто генерит демки. А кто работает плотненько с фронтом, там достаточно удобно. В браузере можно запустить runта фронта и выбирать компонент в компонент элемент страниц, который нужно поправить. А нам очень сильно помог как раз-таки база документации, которая лежала в корне в целом самого проекта, на который можно было ориентироваться. А в какой-то момент мы упёрлись в то, что у нас презентация, она в целом представляла собой в изначальном виде HTML-файл, а, на котором был весь контент, и он разросся до такого объёма, а, с которым уже хуже справлялся агент, который его долго редактировал, а, и в в контекст модели подмешивалось ещё много лишнего. А, ну, соответственно, очевидный выход его чуть декомпозировать на отдельные слайды. Затем, а затем интересным шагом было, аэ, был, аэ, интересным шагом была попытка вот как раз-таки использовать для генерации всей презентации ваншотом а Google агловый сервис. А как Егор он называется, напомни, пожалуйста, потому что я не помню. Google Studio, которая, ну, это говорил про Gemini 3,5, который, да, вот неделю назад вышел. Вот это интересно тоже было.

>> Google Studio фактически, поскольку модель, видимо, да, действительно, как сказал Егор, очень сильно обучена на как раз-таки лендингах, презентацию она ваншотнула буквально как лендинг с соответствующими стилями. Это выглядело достаточно интересно. А, ну я думаю, что пока что вот по этой части добавить больше нечего. Я думаю, что в лай обсуждении мы ещё поделимся историями. Ну, наверное, ещё дополн про пнмод, который, а, очень хорошо помог решать большие блоки задач, как раз-таки в которых было описано по восемь, по 10 пунктов, которые необходимо было предпринять. по типу выпилить нейрослоп, а позаменять какие-то стили, а добавить анимации. А когда появился большой контекст, а пн мод очень хорошо с этим справился. Это когда ещё у нас была итерация с курсором. Ну, и снова верну слово Егорун. Перейдём дальше.

>> Да, тут хотелось бы немного затронуть будущее. Вот я много раз повторял, что, возможно, какие-то слова станут довольно быстро неактуальные. И как бы то ни было, возможно, и грустно отчасти, да, что не успеваешь привыкнуть к чему-то одному, а уже что-то меняется. Возможно, не все к этому быстро адаптируются. А это, собственно, вот про про то же всё самое. Собственно, актуализация происходит буквально вот уже даже не месяцами, даже, наверное, даже не годами, а месяцами. То есть постоянно что-то новое выходит, появляется э какие-то де, какие-то агенты, модели, ещё что-то новое появляется, тулзы, возможные методы оптимизации и так далее. Хотел бы, наверное, вот про актуализацию конкретну того, что, чтобы, наверное, не отставать от этого всё, посоветовать чаще, как бы то ни было банально, обращать внимание на зарубежные форумы, зарубежные в целом видео на Ютубе и ещё где-то, потому что вот, в частности, ээ в России я не особо замечаю, что это где-то пушится прямо очень активно э в масмедии. скорее только на зарубежных каких-то каналах ещё где-то, потому что элементарно вот то, что мы находили для слайдов, для презентации, это всё находилось исключительно там. Э в России я особо, ну, в целом в странах СНГ, я особо не замечал каких-то, э, нововедений. Всё довольно старенькое было. Ну, и плюсом я уточню вот как раз про ещё точнее обращу внимание про Гугла и Studio конкретно про GI модели. Про них вообще толком ничего никто не говорит, что ими можно тоже здорово всё генерировать. Стоит это гораздо дешевле. То есть те же прототипы можно делать с помощью AI студии. Вполне неплохо это получается. Я бы даже, наверное, ещё вот в контексте лендингов страниц, продаж и прототипирования, наверное, сравнил последний Gй с клодом дизайно. Вполне примерно генерирует. Может быть, да, чучуть придётся доработать в плане AI студии, но этим может помочь без проблем экспорт как бы и доработка где-то в том же кодексе тоже с дизайн-модом, на который Дима обратил внимание. Вот как-то так. В целом, наверное, подытожить хотелось бы, что нужно очень сейчас нынешнего времени нужно следить за актуализацией своих инструментов, которые используете.

>> Да, очень важно. Динамика развития крайне большая. Важно не выпасти из из контекстного окна современных трендов. И на этом у нас всё. Спасибо большое, что пришли. Спасибо за внимание. А, небольшое завершающее слово, и мы перейдём уже к фазе такого обсуждения вопросов, ну, и развития нашего диалога. А, как я и писал, у нас есть интерактивная часть, э, которой мы попросили вас заполнить. А как вы работаете с ЛМ, как используете агентов, какие лзы, что знаете, такая общая информация. На этом, кстати, мы мы успели посмотреть некоторые результаты до начала доклада. Вот. И как Егор упоминал, а вот эти вот маячки, когда очевиден сгенерированный текст, прослеживаются и в наших случаях. Это забавно. А нам интересно было собрать такую общую в целом статистику по тому, как у нас в среднем по команде используются, соответственно, данные закрытые, мы их не будем далеко никуда шарить. Но будем использовать. А, и то, о чём, в общем-то, не было упомянуто в нашем пункте для определения победителей в нашей номинации забавной, это то, что мы также ещё учтём баллы за ASС, которое было не сгенерено, а которое показалось наиболее таким эффективным нашему оценочному судье виде также лмки. Вот. А сейчас как раз Кирилл разблокирует всем остальные задания, которые есть в нашем в нашем приложении для интерактива. А мы решили, что эффективнее всего будет просто оставить до конца дня его на индивидуальное прохождение, чтобы не включать это всё вот в текущий доклад и не растягивать его. А мы не придумали, как это можно было бы конечно вписать, но, собственно, там преследуются две цели. Первое соревновательное, очевидное. Можно попробовать побороться за месячную подписку на Cursрсор Pro либо пополнение баланс Open Roer для тех, кто сможет набрать очень много баллов. А причём в совокупности баллов также из-за голосования, да, наиболее интересные кейсы, которые больше всего понравятся нашей аудитории. А второй аспект интерактива, он состоит как раз-таки в том, чтобы вы для себя могли понять, а был ли какой-то импакт от текущего доклада, а попробовать посоставлять промпты, попробовать поперетягивать карточки, квизы попроходить. В общем, весь интерактив построен как раз на всём, на всей презентации, и вы можете, ну, себя пооценивать лично для себя, для понимания своей своего, скажем так, уровня подготовки. Там есть задания по промптингу, в которых можете как раз вот под конкретную задачу, которая там описана, составить промпт, и вы получите оценку на оценку того, насколько этот промт качественный. Вот. И дабы ввести первичное ограничение по времени, поскольку есть соревновательная часть, а мы будем собирать результаты до 22:00 по Москве сегодняшнего дня. А, соответственно, подведём итоги нашего нашего дня, выделим победителей, отправим призы, а после этого разблочим для всех повторное прохождение, если кто-то хочет потренироваться в промтинге на этих же задачах. Вот. Ещё раз всем спасибо. Давайте перейдём ко второй части, где мы попробуем пообсуждать то, что мы сегодня увидели. Самое важное пошарить опыт, у кого какая есть экспертиза и кто какие может рекомендации дать. На этом моменте я думаю, что я выключу шару презентации и welcome. Если кто-то уже хочет что-то спросить либо добавить, поднимайте руки, я буду вызывать. Интересно, >> если нет желающих, я могу поскидывать. А вот давай есть желающий влице Паши Котлерова. >> Давай попробуем пока что не вкидывать, но к Домир к тебе обязательно придём. Паш, привет. >> Да, всем привет. Аэ, хотел немного, а, поводу презентации сказать. Во-первых, она очень такая красивая, интересная. Было очень интересно на неё посмотреть. Вот. Но как фронтендер могу сразу сказать, что он баланс навин. В принципе-то, а, я недавно делал примерно то же самое. И стильмки всегда очень сильно виден, особенно в дизайне. И вообще, а как, а, так как часто сталкиваюсь с фронтенд задачами, скажу, что, а, справляется он, конечно, хорошо, но только для того, чтобы накидать какую-то первоначальную примерно э расположить блоки, первоначально какую-то вёрстку сделать. Далее, если начинается хоть что-то более-менее сложное или какие-то интересные анимации и прочее, а он лэмки всегда очень плохо справляются и с какими-то такими моментами, которые, скажем так, они не видят. Вот. >> Угу. Да, интересное мнение. Я тут на самом деле могу согласиться с тем, что стиль лэмки, а в генерации каких-то ландосов, фронтендов, он в большинстве случае очевиден. Опять-таки, есть прямо куча живых примеров, где это действительно так. Но есть и случаи, где, э, у нас есть обратная ситуация, когда и анимации, и интересные всякие 3D-решения генерится лмкой. Тут, возможно, нужно подчеркнуть, что не всё сводится к Лемэмке. ЛМКА, по сути, ну, задачу не решает в этом контексте. Она подгенеривает какие-то компоненты, стили на основании своей базы. Но вот ответственность за всю прочую обвязку можно ложить на инфраструктуру, в которой это всё делается. Я думаю, что если это поимковить, то можно получить ещё лучший результат. Вот. Но даже закрыв какой-то базовый блок, когда мы генерим там пускай даже 40% того, что мы раньше делали руками, в это всё равно, очевидно, выгодно. Я думаю, с этим никто не поспорит. Хороший тайк паш. Очень хорошо. Ну что, домик? Попробуем повкидывать. Да, давайте. А, ну, в общем, я тут прописал немножечко, чтобы ничего не забыть. Первое, я тоже начинал, конечно, с курсора, но в целом я не до конца понимаю, почему пользуются. Я потом попробовал компьютерма, который сразу же в первом лестроил. И в общем, я принципиально ради никакой не видел. Учитывая, что ты и там можешь выбирать модели, которую ты хочешь, и ты обычно используешь там самые дорогие или мощные доступны. Как будто он работает вообще хорошо.

И я на него перешёл вообще без проблем. То есть там немножечко по-разному устроен подход, как ты разрешаешь использовать другие команды. Там может какие-то горячие клавиши немного отличаются, но в целом оно супер похоже. И отдельно там держать курсор я перестал. М там раньше у меня был визов для привычных каких-то вещей и курсор отдельно, чтобы что-то слангом поделать. В общем, сейчас у меня только взял студия кошка. А ещё из попробуй добавить, >> да, может быть там вкинешь, почему ты скоро использовать или кто-то ещё. Пробовали той другой и получито разницу. Ну как будто бы курсор очень хорошо зашёл в рынок, его большая масса начала использовать и к нему привыкать. >> И вот, >> да, насколько я понимаю, их Да-да, да. Основной point был в том, что они были первые, и поэтому они там много чего понапридумывали. Но вообще вот этот вот кодины клиенты сами по себе, они как будто неро Science. И это всё довольно неплохо копируется. У Visual Studio Code GitHub и Microsoft в конечном счёте >> довольно большое количество ресурсов. И там если какая-то большая компания хочет повторить, там повторить довольно просто. И особой большой разницы, наверное, нет. Скорее всего, да. Ну, чтодику мы изначально используем, да. >> Угу. Да. Вот это тоже хороший поинт, что мы в целом все так синхронизировались по части редактора, который используем. Тут есть вот тебе, пожалуйста, генетизированная разработка с пользованием курсора. >> Это очень хорошо вписалось, как минимум, в наших кругах. А, ну автокомплит как будто бы, наверное, тоже есть в каждом автокомплит, да, он там есть, но автокомпьто я вообще никогда не пользуюсь. Меня только раздражает меня линию выключать, поэтому я обычный контрол за или >> Угу. О'кей. У нас есть поднятые руки, возможно, мнение по поводу курсора есть. Давай, Кирилл, тебе передам слово. Ну, Павел был раньше, чем я. Паш, может ты? >> Давай, Паш. >> Да, да, без проблем. >> А, хотел сказать, что сам тоже пробовал пользоваться курсором. Мне он не понравился. В моих задачах он мне не нужен. Мне кажется, он больше для вайб-кода, когда ты сидишь и просто смотришь, какие-то задачи даёшь. А у меня же задачи более такие прикладные. Мне нужно какие-то баги, какие-то фиксы, как что-то новое разработать. Поэтому уже в имеющемся приложении, поэтому я использую просто VS-код -эдом. Вот у меня есть знакомый, который сейчас прямо вообще большой проект вайpeт прямо, но он использует использовал курсор. Сейчас полностью перешёл на антигравити. говорит просто в миллиард раз лучше с огромными лимитами для >> вот хотел добавить вообще >> интересно >> да >> давай доми ещё по поводу вот этих вот антигравити в плате того что там много токена и всё прочее короче я пробовал Но самая мощная модель, она как будто бы там то ли опус, то лит, я всё время пути. А и когда я попробовал подключить вот эту модель напрямую через антропика, у меня там 50 баксов улетело просто за час. Я так понимаю, что когда ты используешь какой-то большой редактор кода и используешь модель внутри невым прямо вот напрямую через ане какие-то отдельные контракты с этимпиком как минимум. благодаря которым тебе эти токены сильно дешевле обходятся. И вот те же самые задачи, на которых тебе там условно 50 бак хватало там дне 5п на неделю, когда ты используешь напрямую через запи, у тебя били это то же самое и летает всё за час. А это типа тоже большой плюс, когда ты используешь какие-то большие дорогие модели через больших популярных редакторов кода. >> Ну вот это отлично такое преимущество, да. А, Паша, а твой знакомый, который веб-кодит, не выделял какие-то конкретные преимущества антигравити на тусор? >> Ну, во-первых, он сказал, что лучше длиная код никто не пишет. Я, конечно, с ним могу поспорить, >> но вот он выделял это и то, что у него по сути подписки 200 баксов хватает на месяц спокойно без ухода за >> он в основном >> Ну вот у меня тоже примерно 200 выходит за них. Да, ну у него полностью бойкот проект и при этом у него по сути Клод занимается только оркестрацией и перепроверкой, если там какие-то есть ошибки и что-то тупит сильно. >> Как с Ббб там, где подсказку Б отмена всё. >> Угу. Примерно так. >> Угу. Понятно. >> Так, вернём слово Кириллу. Кто-то ещё хотел вкинуть про курсор? >> Давай Кирилл скажет, а потом вкинем про курсор. >> Ну давай. В побе кустора хотел сказать. У него есть очень такой интересный режим, называется. >> И когда тебе надо что-то отдебажить, какой-то какую-то неполадку, то он сам тебе расставляет, он анализирует ход, расставляет тебе а логи в проекте. Но эти логи очень интересно работают. Он сам, курсор тебя просит, просит пройтись по flow забогованному в, например, в юайке и попытаться его воспроизвести. Потом ты нажимаешь кнопочку "Я это сделал". >> А далее курсор смотрит, э какие логи собрал, и их анализирует сам за тебя. >> Вот. То есть ты сам в код не лезешь. Он лезет в код сам на себя, смотрит, где там по логическим веткам, куда код пошёл не туда. >> Вот туда, где я >> это очень интересно. На самом деле я open ээ стором я не пользуюсь. Я пользуюсь кодом. Там больше >> контроля над моделями и над бюджетом. >> То есть можно выбирать ээ для каких-то задач. В моей команде засасываешься >> для сложных задач более размышляющие модели для простых простых там для кодирования менее какие-то более бюджетные модели, которые там меньше думают, просто больше делают. Вот что хотел >> классно про этот режим для бак. Я я не знал. А как там управляется вот это вот по по моделям? Ты просто в руками переключаешь или он как-то сам отрешает? >> Да. Да, я руками переключаю. Я их сначала вроде смотрю, сколько они стоят, а потом потом выбираю какую модель выбрать под задачу. >> Как будто в курсоре, в капайте там тоже ты можешь убирать модели и переключаться между разными для разных задач. >> Может, можно по-другому работать. О'кей. По поводу openда, кстати, вот у меня есть класс задач, которые там связаны с какой-то локальной историей, типа что-то погрепать файли, собрать из каких-то рандомных файлов что-то новое, сбегать куда-то курлом, что-то поделать сетью. Ну, в общем, такое. Что раньше требовало гугление команд, собирание какого-нибудь скрипта либо пайскрипта генерации. Я вот такие задачи решаю как раз тоже в Open в Openкоде. И по сути достаточно быстро можно свинуться в какой-то каталог, что-то подобное собрать, повызывать shellt, а получается удобно. >> А звучит прикольно. А по поводу по поводу вот этого, а Open Code, если я правильно понимаю, что это и ничего не перепутал. Короче, это openсорсный кодингн агент, и его было интересно посмотреть, как он строит промты, там уже всё открытое, как он всё это делает. И в качестве эксперимента была мысль попробовать, а, типа на его основе делать агентов с разными там изначальными промктами и потом, а, сделать типа прокси между OpenI и протоколом, э, который можно было бы подключить в любой там UI, чат, ээ, там либо в Libру, либо куда-то. пропритарно либо куда угодно, чтобы ты с одной стороны мог сделать агентов, с другой стороны подключить их в инструмент, который с агентами изначально работать не умеет, но ты там условно выбирает модель сним какого-то агента и на самом деле обрабатывает его. Он превращает тебе ответы на open протоколе, которые типа стандарты и с ним обычно все умеют работать. Такая мысль была. А-а, кто-то ещё хотел сказать забыл. >> А если у кого >> давай >> могу вкинуть про open cд. В общем, я пробовал использовать плагин, а, о my open code. Сейчас это ох my. Это по сути, ну, настройка такая. Ты можешь использовать свои вот эти подписки двадцатидолларовые вместо AP ключей вот он коде. Но клода они банят, то есть можно подключиться к GPT точно и к антигравити. Может быть, кто-то пробовал, не знаю. >> Ну, интересный подход. Можно так достаточно экономно за счёт вот этих договорённостей у крупных провайдеров экономно что-то пилить. В целом интересно. Я не встречал такого. >> На этом на этом опанкоде я и выяснил, что можно 50 баксов за час спалить на моделях антропик. Там что ты просто типа YouTube отключаешь либо через нроутер, либо напряму. >> Ну а у них у них первых, по-моему, появился вот этот мультиагентный рой. Ты можешь выбирать, по сути, там ну задачу задавать какие-то простые для обычных моделей, сложные для, а там можно для ресча, допустим. Вот. Ну, а сейчас это всё уже есть, в принципе, и в курсоре, и в кодексе, и в плоде тоже. Поэтому я не порово довольно, по-моему, >> если я правильно понимаю, он как будто относительно поздно появился уже, >> как понимание того, что на самом деле построить вот этот лук с коди агентом, это довольно просто. Там автор этого open кода запилил просто блокпост, понял, что это просто и начал перелить вот этот инструмент. >> Опять же, если я его се не перепутал. И двигаясь дальше. Ээ мы там начинали не совсем с языковых моделей, с базовых э всяких типа, что такое бединги, э про про термины и про всё прочее. Я, короче, пробовал, а делать распознавание речи из любопытного можно добиться того, что у тебя твоя локальная модель openсоourсная будет работать лучше, чем коммерческие решения на рынке. Благодаря тюнингу параметров ты можешь свои заранее размеченные и человеком проверенные трансприбации а загонять в эту локальную модель. Благодаря тому, что у локальных моделей сильно больше параметров, которые ты можешь тюнить, чем у коммерческих, находить оптимальный свет этих параметров. И в итоге на каком-то наборе э твоих аудиофайлов встречу, ты сможешь добиться результатов лучше, чем ты смог бы добиться, в том числе, скринингом параметров каких-то коммерческих моделей. По крайней мере, на русском языке, может быть, на английском они там коммерческие лучше, но для русского вполне реально можно приходить к лучшим результатам, чем у коммерческих моделей. >> Это прямо очень интересно. Это очень интересно. >> А на каких ресурсах это вообще модель поднималась? >> А микрофон. Не знаю, так лучше будет. Нет, >> так лучше, да. О'кей. А дальше, м, в общем, когда мы куда-то пытаемся м внедрить, а нам нужно какой-то пром отработать. И тут вопрос, как вообще его оценивать, хорошо он работает или нет. И кроме этого, как его вообще тюнить потом в дальнейшем. Это же не как тестирование в обычном понимании. У нас здесь нет, э, каких-то строгих критериев. М что-то выдало, и оно нужно отдельно. То есть это скорее статистическое какое-то статистическое тестирование, типа как нагрузочное. У тебя нет там Greгen Red, у тебя всегда какой-то спектр, который ещё нужно оценить. И по сути, когда мы что-то пытаемся куда-то внедрить и пытаемся это оценить, это близко к тому, чтобы построить свой бчмарк, которых там, а, сотни открытых, по которым оценивают модели. И по сути мы делаем такой же мечмарк для нашей конкретной задачи, а на основе которого мы можем, подключая разные модели, смотреть, как у нас, э, м эти разные модели перформат. И отдельно отдельной проблемой является вот эта оценка. Э для оценки работы обычно, как правило, ну, я, наверное, так и делаются. делатся, ну, типа логично, используя какую-то другую дорогую, э, модель, когда мы используем в основной в основной задачи какие-то более дешёвые, с помощью них оценивать. Есть отдельный класс инструментов, которые ты подключаешь между своим продуктом каким-нибудь openроутером или какой-то моделью, которая трекает все запросы, которые пришли, все ответы, которые, э, в итоге LLM вернула. И те в отдельном интерфейсе показывают такие запросы. Были типа типа трейсинга, но для L моделей. А мы нигде такого ещё не использовали, но как будто бы было бы здорово в эту сторону покопать. >> Вот Дим, я мы когда подключали Либру к Клику, там как будто бы можно вот эту штуку. Это типа один из продуктов, который клип купил и развивает, но, наверное, есть какие-то другие тоже. >> Угу. >> Вообще это один спективная штука интересная, >> да? Это один из компонентов, которые как будто бы много кто использует из тех, кто занимается этим серьёзно. Но это не то, с чего ты начинаешь, или не типа не всегда это очевидно, что это что это нужно делать, когда ты там только начинаешь отбираться лм и пытаться её куда-то встраивать. >> Угу. Да, правда. >> Ещё из любопытного, опять же, если мы там начали с каких-то более классических задач, вообще LЛM вот эта вот архитектура, благодаря которой всё бустануло, трансформеров, изначально это же было не для того, чтобы продолжить текст или ответить на вопрос как следствие продолжения текста. А изобретено это было в качестве первой прикладной задачи переводчика, когда у тебя сначала твой текст, кодируется в вебдинге кодировщиком, а на одном из одного языка, а потом этот бидинг раскодируется э декодером в другой язык. И по сути вот эти вот мединги, которые у нас посередине торчат, обычной архитектуры для для дополнения текста и ответа на вопрос, они немного другую архитектуру имеют, но вот это изначально она формирует вот эти имбединги. Эти имбединги можно по сути использовать для кластеризации, когда вот, например, в том примере, про который ты изначально говорил, когда нужно какие-то лейблы проставить, решение в лоб - это ты просто делаешь какой-то промпт для какой-то мощной модели, которая тебе потом этот бенг эти теги могла бы дать. >> Угу. Более дешёвый вариант - это когда ты используешь одну из таких моделей для перевода, которые благодаря этому ты можешь использовать намного более простые и дешёвые модели, а получить для какого-то там текста, тикета или какого-то обращения бединг и потом уже этот эмбединг э покластеризовать в какие-то лейблы. Это из из такого примера, как можно относительно классическую задачу решить с помощью LLM, но совершенно не так, как кто-то бы представил, если бы услышал, что мы кластеризацию с помощью больших языковых моделей делаем. >> Дамир, не останавливайся, продолжай. А ещё, короче, есть такой чувак Карпатый, который был сооснователем Openi. Но он такой, энтузиаст обучения. Он потом из Open ушёл и сейчас недавно пришёл в Амтропик. И вот ему очень интересно что-то объяснять, показывать людям, как ЛМ работает, в том числе у него там есть фантазии по поводу того, как сделать какой-то открытый университет или что-то такое. И вот у него есть учебный проект, в котором он там в часовых, получасовых, двухчасовых видео рассказывает, как они работают. И в том числе он реимплементирует там одну из первых, а, одну из первых часть GPT. подробно очень рассказывая, как это всё внутри устроено, как устроена от архитектура, переимплементирую, условно там в 200 строк кода. Если кому-то интересно, как это работает, это тоже было бы здорово посмотреть. Я там ссылку скинул в чат. То есть ты, по сути реимплементируешь чат GPT в в очень коротком количестве строк кода. Ты можешь ней потом что-то у неё спрашивать, они тебе что-то отвечает, сам её учишь. Она там, естественно, простая, маленькая и там, конечно же, она не умная, но, во-первых, он подробно объясняет, как это работает и показывает. Кроме этого, у него есть ряд видео вступительных, типа как мы вообще к этому пришли, какие раньше были способы решения этой задачи. И вот разные способы решения этой задачи, он имплементирует это, объясняя. И потом в итоге ты приходишь к своей собственной версии чат GPT, буквально практически такой же, какой она была там в своих первых версиях, если кому-то интересно. >> Это очень интересно. Я думаю, все пойдут сегодня на YouTube смотреть эти видосы. Ну, во всяком случае, большинство точно. Ещё была история Ещё была история, что большие языковые модели используют тарабайты памяти. А я думаю, что речь тут, наверное, шла про то, что они используют терабайты памяти для того, чтобы просто серить очень много запросов. На самом деле память здесь нужна не здесь, скорее всего, речь идёт про видеопамять, которая в основном-то и нужна. >> Угу. >> На самом деле даже для больших >> мощных моделей терабайты не нужны. Терабайты, наверное, нужны, когда ты сервишь просто миллионы запросов одновременно. Ну и для обычного сервиса ты можешь рабайты использовать, если у тебя там миллион запросов в секунду приходит каких-то сложных. А на самом деле там условно нужны сотни, наверное, гигабайт. Даже для мощных моделей нужны терабайты тогда, когда ты просто их очень много параллельно обрабатываешь. Там есть отдельные подходы, как это в продакшене сервера, отдельно оптимизация. Это довольно развитая история, в том числе онрсе. Угу. Угу. А история что? Что? >> Да, тоже справедливо. >> Угу. А-а ещё про задачи, про то, что LLM плохо работает с UI. Это правда. И у этого есть довольно простое объяснение. М, вообще, в принципе, хорошо работает в той, э, в тех задачах, э, где ты можешь построить нормально цикл обработки, когда она что-то сделала, посмотрела это, смогла оценить, нашла ошибки и пошла править. С юам тут у нас естественные сложности понима появляются. Естественно, она может и код поанализировать, и сделать скриншот в браузере, что-то посмотреть, но, естественно, это будет работать априори просто в определению хуже, чем с обычным кодом, где у тебя вся работа она текстовая, что для вызова кода, что для оценки результатов, что для потом правок. И с текстом она априори будет работать всегда лучше. Вот из того, что мы пробовали уже интегрировать, мы пробовали интегрировать в один проект какую-то самаризацию по профилю по данным, чтобы там можно было задатьм какой-то вопрос на человеческом языке в рамках конкретного профиля, а туда вы промт подтянулись данные этого профиля, она потом ответила. Кроме этого мы сейчас пробуем подключать либеру чат, интегрированную с хлихаусом. для построения запросов по настоящим продовым данным. То есть ты что-то спрашиваешь, через либо чат, через MCP подключается кликхаусу, анализируется, что там вообще за таблицы есть, что за база данных, какие там колонки, пытается понять, что ты имел в виду, построить SQL запрос, в ответ показать тебе данные, построить дашборды, графики и всё прочее. Мы это только начали там, не знаю, Саша уже смотрел, не смотрел, но вот типа два примера, где мы пробовали это внедрять из того, что я знаю. >> Ну, как будто бы это всё, что я хотел рассказать. >> Ну, тут, если продолжить накидывать примеры, у нас есть, скажем, проект, в котором, по сути, используется очень активная суммаризация. Там используется внешняя лэмка. Аэ, получается массив данных, аэ, подмешивается в контекст, добавляется промт, который заранее заготовлен, там есть несколько версий промтов, которые могут использоваться. Ну и на выходе получается какая-то summary по тому, что было в контексте. О'кей, ребят, ещё какие-нибудь интересные кейсы, возможно? У кого-то есть интересно было бы не про разработку возможно поговорить. Возможно, какие-то бизнес-сценарии есть, возможно, по QA, возможно, по аналитике, если кто-то по по ролям отличном от разработки используют агенты или лмки. Есть у нас такое? >> Да, было бы очень интересно послушать, может, какие-то необычные кейсы в аналитике или в тестировании. Что-то как-то, может быть, кто-то использует, >> либо не использует, потому что я скажу, я скажу на самом деле, да, сори, я руку не поднял, но раз все молчат, и я действительно >> немножко офигел полчаса слушать чисто про разработку, >> потому что у меня-то как раз всё связано с аналитикой и в целом не только, я ещё юзаю для себя, скажем так, для души лки и всё такое. Меня вообще нормально, кстати, слышно? >> Да, хорошо. >> А то у меня ВПН >> всякое разное, как хочет, живёт. Я что хотел сказать, да? Эээ, я понимаю, что все кодеры, наверное, юзают курсор, ээ, но в моих кейсах, какие бы они ни были, ээ, если это были бы даже какие-то разработческие штуки, которые я сам там для себя в течение там пары лет пришёл, ээ, я юзаю только GPT и только Cloud. По одной простой причине в России достаточно тяжко с другими оплатами и менять регионы моих профилей, там стандартного гла, честно говоря, ломает. Я юзаю GPT и юзаю Cloud. И если раньше, например, ну, где-то год назад я мог сказать, что лидирует, ээ, от антропика какой-нибудь опус, то сейчас, ээ, как по мне, самое выгодное использовать ээ во всех каких-то задачках, которые там на аналитику, на написание больших текстов, э, на какой-то срез, суммаризацию и так далее, GPT, потому что новые модели, они Они делают это дешевле, если сравнивать там оплаты через всякие ресурсы из России и делают это не хуже, чем тот же самый CloudД. И я что заметил, ну, чисто от себя такая ремарочка, что, аэ, если GPT - это, ну, такой типичный, наверное, типичная такая лэмка, по которой можно задать любые вопросы, и она в целом, ну, плюс-минус, наверное, со всем справляется одинаково. Но тоже с нюансами, конечно, если нюансы сейчас буду всё перечислять, это будет очень долго. то у меня с Клаудом впечатление сложилось такое, что вот это, ну, такая чисто, ээ, никого бы не обидеть, зумерская, короче, нейронка, которая хорошо на самом деле работает с дизайном, но она его именно пытается сделать как какой-то, не знаю, как какой-то постоянно мессенджер с кучей смайликов и так далее. И после этого, после того, как за ней приходится кучу раз говорить ему: "Поправь то и поправь это", чтобы это не выглядело как какой-то цирк, я в итоге пришёл к джиптишке. Это если говорить конкретно про работу. В работе аналитика GPT вообще супернструмент. И я сейчас просто оглядываюсь назад, э, когда нейронки не были ещё так развиты и как было без них работать. Это очень сильно ускоряет работу. Не в том плане, что ты можешь там всё отдать на откуп нейронке, но гораздо быстрее проверить, что она тебе нагенерила, чем самому искать всю какую-то инфу по куче-куче разных источников, понятное дело. И со временем, конечно, приходит опыт как раз в описании промптов, потому что раньше, например, нейронки, если брать даже не лолмки, а какие-нибудь там stable diffusion или что-нибудь такое наподобие картинок, там всё именно по тегам работало, и поэтому, наверное, к джипетишке больше тоже было такое привычное, э, привычная работа с ней - это писать тегами и не давать ему какие-то там большие тексты, потому что он терялся и контекст терял. А сейчас, ээ, чем точнее ты именно, наверное, структурируешь запрос, а не именно как каким-то массивом тегов его отправишь, он тебе лучше и ответит. Поэтому я тут могу, короче, за себя ответить, что как для аналитика GPT сейчас топ. И тот же кодекс, э, я параллельно тут ну, давайте скажем, разрабатываю свой проект на Юнити, который - полностью там на Шарпе. И если в Шарпе я немножко шарю, то в Юнити я не шарю совсем. И весь код у меня пишет кодекс. И в целом я могу сказать, что даже за неделю он мне написал, наверное, то, что я бы сам год изучал, но при этом он тратит, какое-то непомерное количество токен, если ты просишь его работать на самой последней версии. И я, честно говоря, за меся за полмесяца я потратил почти все токены на тарифе X20 в своё время, пока у меня его не выключили. >> Непозволительная роскошь для Инди разработчиков. Да, >> да, да. Ну, я его купил по дешёвке через какой-то баг, так что это справедливо, скажем так. Сейчас я буду брать X5 в июне и посмотрю, как пойдёт там. Но, наверное, мне хватит в целом, >> потому что большую часть уже сделан. >> Ну, а если возвращаться к нашей теме, то для работы как раз с текстами, с аналитикой чего-то, с каким-нибудь ревью даже, например, того же кода, ну, GPT топ, как бы цена качества, по-моему, отлично себя показывает. Тем более там меньше, если вы находитесь в России, меньше и реже бывают какие-то такие жёсткие проверки, которые тебе просто режут доступ. И у меня такого, на самом деле, не было ещё ни разу. Но от ээ антропика я письма счастья некоторые получал. Меня, конечно, не заблочили, но пугали. >> Угу. >> Было так. Поэтому я могу сказать, что я как аналитик юзаю, конечно же, нейронки каждый день, потому что с тем объёмом, которые сейчас есть, с тем фронтом работ, которые сейчас могут попадаться, и куча разных всяких тематик, когда у нас, например, не такая большая команда, но надо в чём-то быстро разобраться, юзать конкретные >> э отдельные GPT, э, созданное там же уча GPT, куда ты можешь там дать свою какую-то БЗ без выхода VNet, например. Это очень удобно. Главное, конечно, всё проверять. >> Это >> я высказался немножко разбавим. Разбавил ваш курсор, ребят. Спасибо. Спасибо. >> Кирилл Паша держит руки. Можете, я думаю, в этой фазе в целом вклиниваться в любой удобный момент. Давайте начнём с Кириллом, а Паша подхватит. Вернёмся к курсору. Я думаю,

что курсор для аналитиков тоже полезен. Скачиваете, подключайте MCP сервера, там от Майкрософта по работе с вордом, по работе с Экселем. Что там ещё? GRU можно подключить, MCP сервер и прямо в курсоре делать какие-то команды. Я думаю, так. Так тоже можно.

Кстати, насколько я помню, клад дектовчить MCP онлайн уж точно, а может быть даже оффлайн уже для работы с тем, что на компе стоит, >> да, обложиться плагинами для чтения XLSX, Doc, X, чтобы сразу ещё и документацию править. >> Угу. >> Дадада. >> Надо попробовать. На самом деле, как раз сейчас есть задача от Вовав Гордеева по поводу подключения всего этого дела. Я тебе, кстати, Вова, сейчас файлик, а, уже скинул, если что. Если ты >> Да, я видел. Спасибо. >> Всё, су, супер. Да, будем думать, как это по красоте всё сделать. Курсор, на самом деле, надо бы тоже попробовать. Возможно, он действительно будет удобен для каких-то аналитических задач. Просто я не пробовал и не могу как-то какие-то поинты вкидывать за или против него. >> Ну да, обязательно >> ещё столько агентов >> любого. >> Сейчас куча всего развилось. Это факт. >> Да. >> Да, >> Паш, можно строиться, я думаю. >> Да, я по поводу вот аналитики конкретно хотел сказать. У меня, может, я вас с Дамиром, с Сашей ээ постоянно это просил посмотреть концепции, которые как раз-таки были написаны с помощью лода. А по поводу аналитики я с ним общался и по поводу разных других бытовых, скажем так, и не очень задач, ну, точнее, вопросов. Могу сказать, что не знаю 5GT и я сколько раз к нему не обращался. Всё время мне хочется вернуться обратно, причём как можно скорее, потому что я начинаю вспоминать те маты, которые уже забыл. Вот. Ну, если честно, по поводу чата GP >> коллекция РЛО. Начинать тематы, которые забыл. Дадададада. >> Интересно. Я вот по своему. >> Ну, это на самом деле прикольно. Сорри, Дима, да, я скажу. Прикольно то, что в опыт работы с конкретными какими-то лмками, нейронками, он у всех настолько разный, что одну и ту же задачу в одной и той же неронке можно, ну, блин, разного темперамента человек с разным подходом и разным уровнем, скажем так, не знаю, подготовки к общению с нейронками совершенно по-разному делает. И, возможно, учитывая, что Паша разработчик и всё-таки, а я, например, аналитик, у меня мозги работают иначе, и я спрашиваю его иначе и, соответственно, получаю более удовлетворительные какие-то ответы. А Паше всё равно делаешь какой-то, э, не знаю, амаш прозрабские штуки, да, и он тебе отвечает какую-нибуд хрень, и ты, короче, едишь его. Я просто очень ко конкретно очень прямо точно задаю, ну, задаю задачу. И всегда нужно, чтобы он мне вопросы позадавал, чтобы мы с ним как бы типа пришли к одному какому-то, э, вектору, по которому будем дальше что-то делать. И здесь вот чат GPT меня вообще никогда не понимает. А тут я, кстати, соглашусь с тобой. Если конкретно так действовать, то он больше поддакивает. И если раньше cloud страдал тем же самым, но год назад я писал утилитку одну, и cloud мне за два промта выдал готовый результат, который мне GPT не мог неделю выдать, короче, например, поэтому >> ту тут, да, такое тоже возможно. Э, но сейчас, если сравнивать, не знаю, по-моему, всё-таки GPT куда-то дальше ушёл, либо я просто к нему привык и понимаю, как он отвечает, и сразу ему пишу, чтобы он не использовал грёбаное хочешь я и всё такое. >> Правда, очень много субъективного. Я, кажется, натыкался где-то на такую шуточную картинку, типа цикл возврата к различным LLM, где там есть тиха, есть клод, есть ещё там какие-то примеры. И по сути просто всё идёт по циклу каждый квартал года, >> э, в зависимости от релиза той или иной версии. Так что, да, здесь нужно ещё отслеживать версию, отслеживать э субъективные аспекты по типу того, как ты формулируешь контекст, плюс сама задача. Вот. И вот совокупность факторов, она как раз и формирует опыт, которым мы здесь пробуем обменяться.

Так, добавлю. У нас есть Рома. Ром, тебе слово. >> Да, да, да, я хотел рассказать ещё. Есть у Google AI, а такая утилитка LLM ноутбук. Ты можешь туда загрузить какое-нибудь видео, и он тебе выдаст всю выжимку по этому видео тексте либо, ну, расскажет голосом. тоже очень удобно экономить время. Там не нужно смотреть эти часовые видосы какие-то. Вот загрузил он их там. Ну, надо подождать минут пять, тоже всё зависит от видео. Вот. Но он не вытаскивает эти сообщения и комментарии. Вот хотелось бы, конечно, чтобы он ещё это делал и анализировал. Я пытался как-то сам сделать что-то подобное. В общем, ну, там получилось, ну, не очень, в общем. Вот ещё мне нравится закидывать в него какие-нибудь научные статьи по биохакингу, по каким-то новым, а суплементам. Вот. И он тоже очень хорошо это всё структурирует. Ну вот Gй GPT плохо плохо с этим справляется. Gй хорошо справляется. Клод, он прямо может прямо биохимию. М, по программированию я хотел сказать больше. Ему нужно чёткие какие-то критерии давать. Ну, ребята говорили это в презентации. В общем, и всё зависит от требований. Если ты хорошо выстроишь требования и архитектуру, то можно попасть, ну, там, с трёх-четырёх промтов примерно. Вот. Ну, собственно, всё, >> Кирилл, >> да, это интересно. Кирилл держит руку. Так, да, это слышно меня? Да, я вам задание включал, а то говорят, что выключено. Вот. А по поводу этого приложения, да, это очень важно выбирать правильную модель. Вот сейчас вы будете проходить упражнения и там задачи по промнгу, а их будет оценивать модель GPT 54 54 nano. Вот. Но изначально там стояла GPT 4 Mini. Она в три раза дешевле, но поставили э чуть более новую версию, чтобы, ну, в надежде на то, что она русский язык чуть лучше понимает. Вот поэтому, да, выбирайте. Можно вообще выбирать самую старую модель. Но главное, чтобы она выполняла ваши задачи. Она будет самая дешёвая. Ну да, там самая старая, но это неважно. Главное, чтобы задачу делала, которую вы её поставили. Так, >> да, отлично. >> Спасибо, Кирилл. Я, наверное, в заключение от себя добавлю, что я стал уже достаточно давно наблюдать за собой тренд, что, а, я крайне редко стал пользоваться Гуглом. А всё чаще я пользуюсь облачным дипсиком, если мне нужно что-то найти первичное, какую-то базовую информацию. А Deep search ча очень хорошо это подменяет. Ну, понятное дело, что это подлежит речеку и углублению, но когда нужно просто какой-то быстрый факт найти либо для себя какой-то мануал, инструкцию, для этого очень хорошо подходит подобная вещь. >> Я бы ещё про deep псик сказал. >> Обычно deep псик. Обычный псик. Обычный псик. Это >> ужас какой. >> Это это крутая, короче, замена Гуглу в России, потому что у меня, например, провайдер не грузит Google без VPN. При этом грузит почту, но не грузит сам поисковик. И не не знаю, бы видел какие-то новости вчера, что дипсик вроде хотели блочить или он не работал, но я не столкнулся. Иногда действительно быстрее зайти просто впсик, который работает от китайских братушек без ВПНА и спросить, что у него. Угу. >> Так что это норм тема вообще. >> У него часто, кстати, есть глюки, что он выдаёт ответ на китайском. Вернее, даже сейчас уже нет, но был период, когда его буквально вот так вот глючило. И в тот период много ресурсов было, на которые он ссылался тоже как раз на китайском. Паш, что ты хотел сказать? У меня у меня проблем просто с Гуглом нету. И самый, ну просто я сколько раз не пользовался дипсиком. Ты ему спрашиваешь быстрый вопрос и получаешь полотно текста, которое сидишь и читаешь, пытаешься понять, где там всё-таки ответ. А там вариантов 10 он обычно предлагает или пять хотя бы. >> Ну это можно промптом скорректировать. Очень хорошо. >> Ну опять же, когда ты быстро хочешь спросить, как будто промт писать сложнее, ну дольше. Альтернатив альтернативный подход - это зайти в Google, открыть четыре-пять источников и эту информацию. G открыт. Ээ >> JNI открыт на постоянке. У меня он бесплатный. Я в него написал быстро получил, ну, в три раза меньше текста я получил хотя бы. Ну вот, да, нормальна, но сам подход ещё обычно такие всякие чаты ещё обычно чаты предоставляют возможность указать какие-то там типа семсемного пронта, который будет распространяться на все на все экземпляры чата. Можно упросить его по стилистике, либо там по количеству вариантов, либо почему-то ещё что-нибудь по настроени. >> Ну вот в дипсике нету такого. Я вот прямо сейчас смотрю, тут нету добавить прот какой-то стандартный. >> Странно, может, тоже появится. Обычно бывает такое. >> Ну, этого буквально нет. Тебе это нужно всякий раз подмешивать в основной промт. Угу. >> Или держать заготовку или какой-то отдельный чат. >> Можно вообще проще использовать этот поиск Google. У него там есть режим EИ и это бесплатно. Либо обычный чат GPT, ну, бесплатный. В бытовых вопросах самое то. >> Ну, я как раз-таки в бытовых вопросах тоже использую чат GPT, чтобы там, не знаю, спросить там, не знаю, что есть в городе сегодня на вечер, допустим. А вот опять же у меня получается четыре-пять яишки я обычно использую. Это удобно на телефоне на кнопку, ну, события навешал, сказал голосом, он тебе выдал эту информацию быстро. В конце года этого, кстати, выпастят очки Google вместе с Xrrio, по-моему, Аура называется. И это очки дополненной реальности с Google Чипом. И там можно будет такие разные тёпложения устанавливать. И, ну, как они говорят, что это будет прорыв. Ты можешь, в общем, с дополненной реальностью можешь, ну, много что спрашивать, и там будет встроен вот этот как раз миной. Угу. Много вопросов по легальности, конечно, возникнет в большинстве стран, как будто. >> Ну, ну да, там камеры же есть. >> Угу. Да, это здорово. На самом деле очень много кейсов мы в целом разобрали, пообщались неплохо. А было бы здорово, если бы это в какой-то тренд сложилось бы, потому что раз в полгода вот подобные симки очень полезно было бы устраивать, на мой взгляд. Я думаю, что мы можем даже сохранить регламент, и если у нас прочих поинтов на обсуждение нет, на этом предлагаю и закончить. А, возвращаясь в целом к формату, я сейчас создам опросник. Мы немножко поголосуем за наиболее понравившиеся сценарии, а из живого обсуждения для того, чтобы попытаться получше определить фавориты для призового места. Ну и напомню, что разблокированы задания, можно попробовать попрактиковаться и пробовать понять, насколько вы хороши в промтинге и в целом в понимании аспектов работы ЛМ агентов. и всего прочего. Тогда на этом закончим. Всем большое спасибо за участие. Было здорово. Живо пообщались во второй части и много чего интересного, я думаю, каждый для себя здесь почерпнёт. Поэтому группу, я думаю, оставим для продолжения шейринга. Ссылок информации, если кто-то что-то будет находить, можно скидывать. И я думаю, что всем интересно будет почитать. Поэтому всем спасибо, хорошего вечера и до новых встреч. Всем пока. >> Спасибо всем.