Всеволод Викулин

Кому можно вайбкодить и как это делать

Управление AI-агентами очень похоже на управление людьми. Это мало кто в индустрии понимает, но я попробую вас убедить на самом простом примере — вайбкодинге.

Про вайбкодинг есть два крайних мнения: от «программисты больше не нужны» до «пользы никакой, раньше писали код, теперь ревьюим Клод». Давайте разберёмся, как к этому подходить, вдохновляясь дисциплиной, которой люди хорошо овладели. Менеджментом.

Базовая теория управления от Всеволода Викулина

Есть два ключевых фактора, от которых зависит, как передать работу другому исполнителю: экспертность исполнителя в задаче и ваша экспертность в задаче.

— Вы эксперт, а исполнитель нет. Тогда вам нужно самому декомпозировать задачу до такого уровня, чтобы исполнитель был экспертен в подзадаче. Потом принять результат подзадачи, дать следующую, и так далее.

— Вы не эксперт, а исполнитель эксперт. Декомпозировать сами вы уже не можете. Но совсем не контролировать нельзя, а то наделает всякого. Вы не контролируете его по ходу работы, а ставите конкретные KPI, которые он должен выполнить. Например, пройденные тесты, скорость работы и тд. Но не забывайте тут закон Гудхарта.

— И вы эксперт, и исполнитель эксперт. Идеальная комбинация. Можно пробовать оба варианта: и KPI навесить (он же эксперт, сам разберется), и расписать, что конкретно делать, если вы считаете, что вы самый умный (у меня так).

— Ни вы, ни исполнитель не эксперты. Ну, вы понимаете, что будет.

Не вайбкодер, а багодел

Может ли менеджер навайбкодить простой личный сайт? Может, даже если он не разбирается в разработке (я, кстати, навайбкодил). Клод в этом давно экспертен, а результат легко проверить глазами.

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

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

Вместо резюме

В менеджменте агентов нет ничего уникального. Вы на самом деле всё это уже умеете делать со своими коллегами.

Хотя нет, всё-таки есть. Агент не принесёт вам оффер, что другой человек платит ему x2 за те же токены. В OpenAI до этого ещё не додумались. Пожалуйста, не подсказывайте им.

Вам LLM побыстрее или подешевле? Выберите только одно

Почему-то во всех командах, где я работал, я всегда отвечал за оценку, сколько нам надо GPU. То ли я выгляжу очень экономным, то ли авторитетным. Хотя для оценки GPU надо быть скорее везучим. Потому что оценить, во сколько нам влетит инференс — очень хитрая задача. И зависит это в первую очередь от терпения наших пользователей. Давайте вместе разбираться.

Предсказание в LLM идёт токен за токеном, слева направо. И в прошлом посте мы выяснили, что инференс LLM тормозит, потому что мы на каждый токен гоняем миллиарды весов модели по памяти видеокарты.

На самом деле, я вас тогда капелюшечку обманул. Помимо весов модели, нам придётся гонять ещё матрицу с результатами прошлых вычислений — чтобы не пересчитывать заново всё. Хранятся там K и V каждого прошлого токена, отсюда и название: KV-кэш. Подробнее про это самые любознательные инженеры могут почитать вот тут.

И иногда он даже может занимать памяти больше, чем миллиардные веса модели.

ТУТ НЕМНОГО МАТЕМАТИКИ, БОРИТЕСЬ ИЛИ ПРОПУСКАЙТЕ

KV-кэш занимает =

2 (K и V) × слои × число KV-голов × размер головы × байт × длина контекста

Допустим, у нас 60 слоёв, 8 KV-голов, размер головы 128, и храним кэш в fp16:

2 × 60 × 8 × 128 × 2 = 245 760 байт ≈ 246 КБ на токен

Тогда, если контекст 2000 на 1 запрос:

245 760 × 2000 ≈ 0,49 ГБ =

= Полгигабайта памяти. На один запрос.

Сева, ну и что нам с этих полгигабайта?

Память = размер модели + батч × размер KV-кэша

И тут ключевое: веса общие для всех запросов в батче, а KV-кэш у каждого свой. Поэтому веса делятся на всех, а кэши складываются.

Возьмём модель 35B в fp8 — это 35 ГБ. Если батч маленький, KV-кэш мал, на него можно забить. Но если батч 100, то кэш уже 50 гигабайт — больше, чем сама модель, и основное время будет уходить на его загрузку.

Итого очень понятный размен: больше батч — мы загрузили модель 1 раз и параллельно предсказываем весь батч. То есть больше пропускная способность видеокарты (токены в секунду), то есть можем держать больше запросов, то есть нужно меньше карт. Но при этом больше KV-кэш, дольше наш пользователь будет ждать своего ответа.

Можно легко построить график, как время между токенами зависит от пропускной способности карты (я Клод вроде справился). Если интересно, в комментах напишу промпт формулы, как такое рисовать.

Сева, а что нам делать-то?

Учиться терпению! Ну или платить. Очень простой план:

Шаг 1. Думаем, сколько пользователь готов ждать. Обычно ничего умнее, чем 5 секунд, не придумывается. Интересно, у всех так?

Шаг 2. Прикидываем пиковый RPS в сервис. Потом умножаем на 1.5, потому что прикинули плохо.

Шаг 3. Берём 1 карту, берём корзинку входных запросов (с продовым распределением, чтобы KV-кэш был честный). Бенчим ваш инстанс (команда vllm bench serve). Смотрим p50/p95/p99 перцентили. Расстраиваемся.

Шаг 4. Не хватило — делаем карты ×2, батч падает в 2 раза, время ответа падает по нашему графику. Правда, не в 2 раза, а процентов на 20, увы. Повторять до целевых 5 секунд.

Шаг 5. Видите, что вам нужно 100500 карт — сначала расстраивайтесь. А потом думаете. Может, они могут немножко подождать?))) Я там стриминг намучу, UI красивый сделаю, мемы смешные буду показывать, пока ответ загружается. И на одной H100 как-нибудь протянем...

Говорила мне мама, терпение — золото. 30 лет прошло. И только сейчас до меня дошло.

Улучшаем качество без обучения. Диаграмма контекст–compute

Я много писал про важность контекста — пришло время упаковать это в нормальную схему. Напомню: у вас два рычага — вычисления на инференсе и контекст.

Шаг 0. Берём самую жирную модель, что доступна, и включаем ризонинг, чтобы рассуждала подольше. Экономика не бьётся — пофиг, бабки не проблема.

Шаг 1. Берём датасет, прогоняем на нём наш космолёт, смотрим ошибки, собираем контент, который эти ошибки исправляет. Лучше делать это в цикле через другого агента — подробнее тут.

Шаг 2. Потом окажется, что знаний дофига, но в них сложно ориентироваться, и модель начинает тупить. Теперь мы упрощаем доступ к знаниям. Улучшаем описания тулов, добавляем заголовки и теги. Строим харнесс, чтобы подсасывать в модель только лучшее. Часть контента дропаем, часть суммаризуем. Тут в итоге должно случиться офигенное качество.

Шаг 3. Начинаем сжимать модель — и тоже через контекст. Модель меньше, но это не беда, ведь у нас есть эталон из шага 2. Теперь мы пишем контекст, но чтобы мимикририровать под ответы большой модели. Для этого можно использовать разные алгоритмы оптимизации, например, генетические алгоритмы (никогда не думал, что на полном серьезе это напишу). Написали ответ -> сравнили с большой моделью -> дифф рассуждений отправили в промпт. Да, вы правы, это очень похоже на дистилляцию. Это она и есть. Качество может просесть, но не так сильно, как кажется.

Готово, вы восхитительны.

Кстати, всё это делается прямо по API, вообще без своих GPU. Главное — чтобы был эвал, под который собирать контекст. Дальше уже дело техники.

Про детали этой техники есть много интересных идей/статей, обсудим их вместе с вами.

Бизнес-модель моего телеграм-канала

Клянусь вам: раз в неделю мне пишут продюсеры онлайн-курсов. «Сева, у тебя такой классный контент, но ты не монетизируешь его на максимум! Давай опрос проведём, вороночку построим, курсик запишем, прибыль поделим».

После быстрого ответа «Нет» они удивляются: а зачем тогда всё это, если не ради того, чтобы стричь бабло? Сейчас расскажу.

Я хочу собрать самое крутое сообщество, которое внедряет AI в бизнес. По-настоящему.

Не придумывает бесполезные стратегии AI-трансформации.
Не вайбкодит личного ассистента для почты генерального директора.
Не продаёт курсы «Как стать AI-native мясокомбинатом».

Я собираю людей, которые действительно хотят менять этот мир с помощью AI, и помогаю им этого добиться. Тремя способами:

— бесплатным советом (просто пишите в личку с вопросом);
— совместной работой (мы нанимаем :));
— вот такими, надеюсь, не самыми бесполезными постами.

Для вас я делаю этот канал, для вас пишу этот пост — и безумно благодарен вам за доверие. Нас уже 5 тысяч. Мы провели первый совместный митап. Спасибо, друзья: наше сообщество начало строиться.

Отдельно благодарю Юлю — мою самую преданную подписчицу и любимую жену. Без её поддержки я бы за это точно не взялся. Ну правда, вы посмотрите на эти подарки!

Торт уже во мне.

5 лет проведения собеседований в одном посте

Эта картинка стоила мне 5-ти лет опыта нанимающего менеджера и 3-х лет интенсивной психотерапии.

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

Термин я украл у бывшего руководителя из Яндекса. Уверен, что, если спросить нас обоих, мы дадим разные определения этого качества. Но при этом я уверен, что понимаем мы его одинаково.

Бодрость — это когда человека просишь, и он решает. Он не просит у тебя точного ТЗ, он сам задаст все вопросы. Он не думает про Scrum и Kanban: если нужно, он сам навайбкодит себе подходящий фреймворк. Он сам найдет бездомную команду и внушит ей, что теперь для нее это самая важная задача в мире. Он думает про результат и с улыбкой относится к неопределенности его достижения.

У меня даже появился тест на бодрость: если в проекте неожиданно всплывает задача, которую хрен пойми как делать, но надо очень и еще вчера — на ум приходит он. Тот самый мистер Бодрость.

Выявлять это чудесное качество можно при разговоре. Слушайте, за что человек отвечал в проекте. Если МЛ-щик писал веб-приложение, потому что все разработчики были заняты, — мне он нравится. А если он еще и никогда раньше этого не делал и сам разобрался с ЧатГПТ — мое сердечко бьется сильно-сильно.

Не на все задачи нужны бодрые. Во-первых, им бывает скучно, и вам придется постоянно их челленджить. Во-вторых, они не подходят для системной работы. Если составить команду только из них, они через какое-то время закопаются в своей бодрости. И разрушат вам продакшен. Помимо бодрых, нужны люди, которые умеют строить системные процессы. Долгие цели, спринты, демо, груминги… Что там еще есть? Я — не умею. Я — бодрый. Поэтому я их нанимаю :)

Один контекст, что правит всеми

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

О что заземляться

Чтобы измерить качество агента, нужен ground truth — точка опоры, относительно которой видно, где он накосячил.

Первое, что приходит в голову — взять экспертов. Cпрашивать их: хороший ответ или плохой. Идея рабочая ровно до того момента, пока вы не захотите что-то с ней сделать. Мнение эксперта живёт у него в голове. Его нельзя пересмотреть, про него можно только на кухне поспорить. Вы получаете оценку, но не получаете рычага, как ее улучшить.

Регламент — другое дело. Агент отступил от правила — ошибка. Но нельзя просто так взять и написать эту базу знаний выписать. У людей куча правил, которые для них слишком очевидны, чтобы их проговаривать. Поэтому мы строим отдельный агентский пайплайн, который эти знания собирает, об этом я писал в посте.

Как схема идеально замыкается

— Асессор по базе размечает — смотрит на ответ агента и сверяет, где тот разошёлся с регламентом.

— Агент по ней же работает — решает обращение клиента, сверяясь с правилами.

— LLM-as-a-judge калибруется об разметку асессоров (напомню, они сами читают ту же базу) и тоже размечает

— Теоретически, по этой же самой базе может работать не только агент, но и сотрудник. Там, где агент пасует, за дело берётся живой оператор — и работает по тому же контексту, что и LLM.

Складывается в квадрат: агент и человек — те, кто действует; judge и асессор — те, кто проверяет. Четыре роли, один контекст под ними. Это делает систему невероятно гибкой. Поменял ошибку, про это сразу узнали все. Появилось новое правило, моментально проросло всей системе. Да и людей можно будет джаджами замерять :)

Конечно, интерфейсы к контексту у человека и LLM разные. Для человека есть целая область: User Interface (UI). Пока Agent Interface лучшие умы еще зарождают, можно делать по старинке: дал агенту grep — и он сам выгреб нужный кусок. И реально работает!

Где я вас обманул

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

В этой схеме мы никак не проверяем сбор самого контекста. Соберём базу криво — все наши четыре друга посыпятся одновременно.

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

Заключение

Я рассказал вам все, что знаю сам (а знаю я немного). Как собирать контекст для агентов, как об него калибровать разметчиков, и как это все работает вместе. Это же наша команда рассказывала на недавном митапе (скоро выложу видео!).

Если остались вопросы, пишите в комментариях или в личные сообщения. Дальше будем активно разбирать инференс LLM.