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

AI-разработка через циклы обратной связи Никто заранее не знает, какой промпт вам написать, какие тулы дать агенту и на какой LLM его запустить. Не знаю даже я. Хорошая новость: для успеха вам и не нужно это знать. Нужно построить процесс, который покажет, где вы ошиблись и что исправить. Я правда считаю этот пост самым полезным советом, который я могу дать по разработке агентов. И который мы с командой нашли за этот год. Почему нет инструкции по сборке агента Было бы приятно: берёте Qwen такого-то размера, кладёте в контекст столько-то токенов, подключаете семь тулов. Поздравляю, бухгалтерия автоматизирована. Но — нет. Всё зависит от задачи. А пока вы собирали лучшие практики для одной модели, вышла следующая, которой половина этих практик только мешает. Поэтому вместо поиска идеальной архитектуры вам нужен поиск источника обратной связи. Что-то, что покажет: здесь агент справился, а здесь полез не в ту базу и уверенно насоветовал всякого безобразного. Как выглядит цикл Допустим, агент помогает сотрудникам разбираться в документах. Человек спрашивает про возврат товара. Агент лезет в старую базу регламентов и приносит инструкцию, которая не действует уже полгода. Сотрудник пишет: «По возвратам надо смотреть в другую базу». Отлично. Нет, агент отработал плохо. Отлично, что теперь вы знаете, что исправлять. Дальше разбираетесь: агент не понял описание тула? Не знал, какая база актуальная? Или нужную базу ему вообще забыли подключить? Исправляете причину, проверяете на этом и других примерах, выкатываете обновление. Получается цикл: Агент поработал → получили обратную связь → разобрали ошибки → внесли изменения. Больше так не ошибаемся. И в новый цикл. Кстати, часть этого цикла вы тоже можете автоматизировать агентами (про это пост и будут еще). Но это для продвинутых, начните сначала с человеками. Кто скажет, что агент накосячил - Асессоры. Разбирают ответы по вашим критериям и отмечают ошибки. Важно, чтобы сами одинаково понимали, что ошибка. Иначе получите дискуссионный клуб (подробнее в посте). - LLM-as-judge. Другая модель оценивает работу агента. Только сначала проверьте, что её оценки согласуются с человеческими (подробнее в посте). - Ваш сотрудник. Тот самый, которому вы автоматизируете работу. Он часто лучше асессора знает, почему ответ бесполезен: регламент устарел, исключение не учтено, в эту систему вообще нельзя писать без согласования. - Ваш клиент. «Тупой бот, позови оператора» — тоже обратная связь. Не самая подробная, зато искренняя. В AI много внимания уделяют первым двум вариантам. Они полезны, но разметка стоит денег, а критерии ещё нужно придумать и поддерживать. Поэтому не игнорируйте людей, которые уже работают с агентом. Они каждый день находят вам ошибки. Бесплатно. И от души. На чём фокусироваться в разработке Как только вы сделали цикл, все о чем важно думать — как сделать его короче. Нужно как можно быстрее получать фидбек и как можно быстрее проворачивать изменения. Заметили проблему, поняли причину, исправили, проверили. И делаете так постоянно, пока не будет работать. В классическом ML это знакомая история: собрали ошибки, поправили данные, переобучили модель. Удобно соревноваться на задачах, где правильный ответ уже известен, нужно научить LLM его воспроизводить. В реальной работе ответ часто ещё нужно найти. Поэтому такие советы сложно найти в статьях/конференциях. Но знаете где можно? Правильно, у меня.

Видеозапись моего доклада Стратегия внедрения AI-агентов на Gigaconf. На нашем с командой опыте обсудили, как строить агентский заводик. Чтобы систематично на нем выпекать агентов. Как выглядит CJM на этом заводике, какие вакансии на нем открыты и как его уже можно автоматизировать. Теперь вы точно знаете, чем заняться в выходные. Если остались вопросы по масштабированию агентов в компании, пишите в личные сообщения.

Почему в R&D выживают только параноики Сложно управлять разработкой, когда не знаешь, получится ли вообще что-то разработать. Даже психологически. В AI такое возникает постоянно. Неважно, внедряете вы первого в компании AI-ассистента, копилота для аналитика или агента-тестировщика, — вы попадаете в R&D. Сегодня обсудим, как им управлять, чтобы прийти к успеху. Ну или хотя бы не проиграть все деньги в этом казино. Что такое R&D Это когда непонятно, реально ли то, что вы задумали. Лезть в такое имеет смысл, когда есть гипотеза, на которой можно заработать очень много денег. Самый понятный пример — фарма. Провести новое лекарство через все клинические испытания может стоить сотню миллионов долларов. Успешно проходит примерно 1 из 10, остальные девять отправляются в корзину (вместе с деньгами). Но одно вышедшее лекарство окупает весь этот карнавал научной мысли. В AI такое случается, когда вы берётесь за проект, который никто ни в вашей компании, ни в соседних ещё не делал. В смысле, не делал успешно. Как управлять такой разработкой В фарме клинические испытание сначала проводят на небольшой группе, потом побольше, потом еще побольше. Дорогие исследования ставят на самый конец, чтобы не тратить кучу денег на бесперспективную технологию. Вот ровно также нужно делать и вам в AI. Представьте, что вы параноик. У вас в голове должен быть список причин, почему проект провалится (блокеров). Планируйте разработку через испытания, чтобы причины как можно скорее подтверждались. Ну или, если повезет, — не подтвердились. Вначале — самые дешевые испытания. Допустим, мы делаем на опенсорсе AI-ассистента, который собирает подборки интересных товаров. Что может пойти не так? Блокер 1 (самый вероятный): это нафиг не нужно вашим пользователям. Как проверить? Возьмите частотные запросы вроде «айфон {?} Pro Max» и напишите на них 1000 ответов экспертами. Покажите их пользователям и посмотрите, будут ли они переходить в товары. Не взлетело — разбираемся почему. Не поняли, как поправить, — закрываем проект. Поздравляю, вы уберегли себя от вкапывания месяцев разработки в никуда. Блокер 2: эксперты такое написать могут, а LLM ещё нет. Промптим самый свежий Opus или GPT, сохраняем ответы в офлайн-базу, повторяем эксперимент. Анализируем. Не поняли, в чём фейл, — что делаем? Правильно, закрываем. Сэкономленный рубль — заработанный рубль! Блокер 3: на Opus такое сделать можно, а на опенсорсе нельзя… думаю, вы поняли. …и так, пока не сделаете ассистента. Чем сильнее менеджер, тем больше причин провалов он заранее предусмотрит. Вместо резюме  Далеко не всем вообще нужно лезть в AI R&D. Я бы даже сказал, почти никому. Если на кону не куча денег, просто не лезьте туда. Большая ошибка — когда компании, которым НАФИГ НЕ НУЖЕН AI-АНАЛИТИК, бегут собирать его первыми. Скорее всего, не соберут. А если каким-то чудом соберут, не получат ничего, кроме самоудовлетворения. Побудьте немножко ждуном. Подождите, пока компании с бо́льшим штатом аналитиков соберут эти копилоты, а потом за чашкой чая (ведь чая?) узнайте все их секретики. И вот потом сделаете. С бюджетом в 10 раз меньше. Этот эффект известен далеко за пределами AI: первооткрывателем быть выгодно не всегда. Графический интерфейс Mac подсмотрен у Xerox, а Стив Джобс отвечал: «Мы никогда не стеснялись воровать великие идеи». И заработал на этом кучу денег. Может, и вам пора воровать идеи из этого канала? Все проверены, рекомендую.

Две стадии AI-трансформации Вам нужно трансформировать какую-то функцию: поддержку, бухгалтерию, разработку. Как подходить к такой объемной задаче? Мы с командой нашли рабочую схему. Рекомендую применить или хотя бы детально ознакомиться. Стадия 1. R&D На старте ничего не понятно. Ясно, что нужны агенты, а как без них. Но как именно нужны — непонятно совсем. Вам нужна небольшая и очень экспертная команда. Такая, которая умеет выдвигать гипотезы и не демотивируется, когда 99% из них проваливаются. Фокусируйте команду не на итоговой метрике (например, уровне автоматизации), а на скорости проверки одной гипотезы. Автоматизацию будете улучшать потом, когда станет понятно, что работает. В команде должен быть явный перекос в сторону сильных инженеров. Им придётся принимать много решений исключительно на интуиции. У команды должна быть высокая автономность, а ваш стиль управления — поддерживающим. Команда глубже всех погружена в новое и неизвестное, поэтому ваша роль — взгляд со стороны, чтобы подсвечивать слепые пятна. Нормально, что сразу всё не получится. Но если вы проверяете адекватные гипотезы и не бегаете по кругу, рано или поздно найдёте нужную связку. Стадия 2. Масштабирование R&D закончился успехом, но метрики процесса не изменились, потому что массово в проде еще ничего нет. Теперь технологию нужно внедрять, и главная проблема этой стадии — внедрять придётся очень много. Здесь и появляются новые роли вроде FDE, про которых я писал в статье. Тут тоже нужна экспертная команда, но уже для того, чтобы построить процессы и платформу. И фокус меняется: теперь вы качаете итоговую метрику, а значит, фокусируйтесь на скорости внедрения. Главный рычаг, который мы нашли, — агенты, ускоряющие само внедрение. Разбейте CJM внедрения на участки, найдите бутылочные горлышки и встройте агента в каждое (подробнее про эти горлышки — в книге «Критическая цепь» Голдратта). То есть секрет успешного внедрения — сразу автоматизировать команду внедрения. И R&D после первого успеха можно не сворачивать. Он может найти новые технологии, которые поднимут ROI FDE-команды в несколько раз. Что вы накапливаете во время стадий Трансформация крупной функции — очень сложный проект, и технологически, и организационно. Можете мне поверить. И упирается он не в технологии, а в экспертизу людей. На этих двух стадиях вы строите не только технологии и процессы. В первую очередь вы копите экспертизу команды — связку людей, которая прошла путь от первых гипотез до масштабного внедрения. Поэтому после первой успешной трансформации можно идти трансформировать всё остальное. Там будет совсем другая специфика, но технологические и организационные вызовы — ровно те же. И с опытной командой вы пройдёте их сильно быстрее. Только не переживайте, что это работа скоро закончится. Человечество столько насоздавало процессов. На нашем веку хватит. Даже бок о бок с агентами.

Нас ждёт очередная технологическая трансформация Угадайте, про что нобелевский лауреат по экономике Роберт Солоу сказал: «*** видны уже везде, кроме статистики производительности». Про AI-агентов? Нет. Про компьютеры. Цитата 1987-го года. Все большие технологические трансформации идут по одному сценарию. Поэтому, чтобы понять, что будет, полезно заглянуть в историю. GPT — это GPT Есть класс технологий, который экономисты называют General Purpose Technology, технологии общего назначения. Сокращённо GPT. Иронично, правда? Эта технология проникает во все сферы и меняет то, как мы живём и работаем. Примеры: паровой двигатель, электричество, компьютер. А теперь, похоже, и AI. Главное её свойство — она порождает сопутствующие инновации. На её базе появляются продукты и процессы, которые раньше были невозможны. Нельзя просто так взять и внедрить GPT Сама по себе технология общего назначения приносит мало. Деньги появляются, когда под неё перестраивают весь способ работы. Классика — электрификация заводов. В конце XIX века фабрика работала от одной большой паровой машины. Она крутила вал под потолком, а от вала ремнями приводились все станки. Сначала люди просто выкинули паровик и поставили на его место большой мотор. И ничего не изменилось. Эффект пришёл, когда до инженеров дошло: теперь мотор можно поставить на каждый станок. Исчезли валы, станки расставили по ходу производства. Производительность скакнула. Ушло на это около 40 лет. Это называется комплиментарные инвестиции. Это вложения во всё, без чего технология не работает: образование сотрудников, перестройка процессов, инфраструктура и тд. По оценкам экономистов, в ИТ-трансформации на них приходилось 90% всех вложений. Деньги будут, но не сразу В начале перестройки эффекта не видно: затраты уже есть, а отдачи ещё нет. Ученые называют это J-кривой (см. картинку). Сначала показатели проседают, скептики в этот момент кричат: пузырь, пузырь! Солоу пошутил в 1987-м, а во второй половине 90-х рост производительности в США заметно ускорился. И две трети этого ускорения экономисты приписали как раз ИТ. Компьютерам понадобилось лет десять. Электричеству — сорок. Что вам делать с AI AI будет внедряться по тем же законам. Только быстрее: заводы перестраивать не надо, а часть инфраструктуры AI вообще пишет себе сам. Сначала определитесь, где новый паровой двигатель даст вам самое большое преимущество. И уверенно перестраивайте эту сферу на AI-рельсы. Вкладываясь в экспертизу команды и инфраструктуру. Как именно это делать — обсудим вместе. И сделаем. Обещаю, быстрее, чем за 40 лет.

Друзья, многим стали писать в личку по поводу «обучения у меня». Наконец-то стал чувствовать себя знаменитым) Это спам. У меня нет никаких наставничеств/ коучингов/менторств и тд. Единственное, что у меня есть это совместный курс с ВШЭ для руководителей. Курс хардкорный. Мы там смотрим на AI-стратегию компании, найм команды и приоритизацию кейсов. Вот это не спам. Мы с командой стараемся делать его лучше каждый раз. На остальное не обращайте внимание. Берегите время и деньги.

Мне сегодня 31 AI-эксперт — он как вино. Хорошеет с каждым годом! А благодаря вам у меня был отличный год. Мы читали посты, ходили на конференции и откладывали в туду лист большие статьи. Спасибо вам за это. Кстати, если хотите мне что-то подарить — подарите мне внимание и прочитайте мою последнюю статью! Только ради бога, не просите просто саммери у ChatGPT. Это ровно тот контент, которым жалко делиться с ИИ.

Кто должен внедрять AI в корпорацию? Новая статья Любые технологические трансформации это сложно. В первую очередь, потому что организации требуются новые компетенции. Поэтому возникают новые профессии. Мы с командой довольно сильно продвинулись в этом. Ключевые выводы я написал в новой статье. Там вы найдете: - Почему возникают новые роли - Кто такой Forward Deployed Engineer - Что будет с профессией в будущем, и какая роль будет вместо нее Как всегда, жду ваши вопросы/мысли в комментариях или в личных сообщениях.

Решаем бизнес-кейс У большинства сложных проблем нет единственно правильного решения. На своих занятиях я люблю разбирать их в виде кейсов. Делаем автоматизацию бухгалтерии. Взяли последнюю GPT: все работает, метрики хорошие. Но данные нельзя отдавать во внешние API, поэтому пересаживаемся на опенсорс. Берем любимую версию Qwen, тюним промпт — качество сильно отстает. Перед вами встает вопрос: что делать дальше? Базовые мысли Если на GPT все работает, значит, вы уже собрали весь контекст. То есть все знания у модели есть, просто ей не хватает интеллекта, чтобы правильно их использовать. Значит, интеллект нужно как-то добавить. Каким образом это можно сделать: 1. Взять LLM побольше. 2. Дать LLM порассуждать подольше. 3. Сделать сложный харнесс: контекст-инжиниринг, мультиагентность, вот это все. 4. Дообучить модель. В чем размен каждого варианта При одинаковом качестве важны два свойства: 1. Стоимость работы: а) сколько GPU нужно купить; б) сколько людей нужно, чтобы решение не развалилось. 2. Стоимость улучшения: насколько дорого переходить на новую технологию. Разложим все четыре варианта по этим двум осям. 1. LLM побольше. Дорого из-за GPU. Поддерживать недорого: просто следим за инференсом. Улучшать дешево: просто подменяем модель и получаем тонны профита. 2. Рассуждать подольше. Также как пункт 1, только платим не столько за размер модели, сколько за токены. 3. Делать харнесс. По железу может быть дешевле пунктов 1 и 2, потому что можно работать с моделями поменьше (например, рекомендую харнесс Т-Серч, реально помогает). Но улучшать его сильно дороже: новая модель в старом харнессе может не дать аплифта, и его придется полностью переделывать. LangChain переделывал свой харнесс Open Deep Research 3 раза за год. 4. Дообучать. Инференс можно гонять на модели поменьше, зато нужна ML-команда. Вы попадаете в проблему data drift и постоянного переобучения. Новые модели тоже придется дообучать, и не факт, что это получится тем же кодом. Что выбрать Все зависит от вашей ситуации. — Если кровь из носа нужен эффект с самой дешевой экономикой прямо сейчас, делайте 4. — Если готовы немного переплатить за счастье в будущем, выбирайте 3 и старайтесь делать харнесс как можно легче. Вам все равно потом его переписывать. — Если вы богатый Буратино, идите в 1 или 2: через 5 лет скажете себе из прошлого спасибо. Это, кстати, известный принцип — The Bitter Lesson. Его в 2019 году сформулировал Ричард Саттон, один из отцов современного RL: в долгосрочной перспективе всегда выигрывают методы, которые масштабируются вычислениями. Иногда эффект автоматизации настолько мал, что правильный ответ — вообще ничего не делать. Честно сказать, что сейчас эту задачу выгоднее не автоматизировать. Подождать, пока опенсорс созреет, и тогда сорвать это сладенькое яблочко. Вы же помните, что мы решали бизнес-кейс?

Кому можно вайбкодить и как это делать Управление AI-агентами очень похоже на управление людьми. Это мало кто в индустрии понимает, но я попробую вас убедить на самом простом примере — вайбкодинге. Про вайбкодинг есть два крайних мнения: от «программисты больше не нужны» до «пользы никакой, раньше писали код, теперь ревьюим Клод. Давайте разберёмся, как к этому подходить, вдохновляясь дисциплиной, которой люди хорошо овладели. Менеджментом. Базовая теория управления от Всеволода Викулина Есть два ключевых фактора, от которых зависит, как передать работу другому исполнителю: экспертность исполнителя в задаче и ваша экспертность в задаче. — Вы эксперт, а исполнитель нет. Тогда вам нужно самому декомпозировать задачу до такого уровня, чтобы исполнитель был экспертен в подзадаче. Потом принять результат подзадачи, дать следующую, и так далее. — Вы не эксперт, а исполнитель эксперт. Декомпозировать сами вы уже не можете. Но совсем не контролировать нельзя, а то наделает всякого. Вы не контролируете его по ходу работы, а ставите конкретные KPI, которые он должен выполнить. Например, пройденные тесты, скорость работы и тд. Но не забывайте тут закон Гудхарта. — И вы эксперт, и исполнитель эксперт. Идеальная комбинация. Можно пробовать оба варианта: и KPI навесить (он же эксперт, сам разберется), и расписать, что конкретно делать, если вы считаете, что вы самый умный (у меня так). — Ни вы, ни исполнитель не эксперты. Ну, вы понимаете, что будет. Не вайбкодер, а багодел Может ли менеджер навайбкодить простой личный сайт? Может, даже если он не разбирается в разработке (я, кстати, навайбкодил). Клод в этом давно экспертен, а результат легко проверить глазами. А сложный сайт с базой данных и регистрацией уже не сможет. Клод всё ещё экспертен, но менеджер не сможет чётко объяснить, что именно нужно сделать. И не напишет тесты, на которых агент будет проверяться, а глазами такое не проверишь. Нечем проверить результат — получаете багодельню. Я сам видел много сайтов AI-консалтеров, где не работала половина функционала. Может ли опытный разработчик довайбкодить большую корпоративную легаси систему? Может, если разобьёт задачу на понятные куски и аккуратно объяснит Клоду, что надо делать. В этой задаче Клод пока не эксперт. И даже тесты ему не помогут. Возможно, следующие модели будут лучше навигироваться по тонне легаси-кода, но не уверен. Вместо резюме В менеджменте агентов нет ничего уникального. Вы на самом деле всё это уже умеете делать со своими коллегами. Хотя нет, всё-таки есть. Агент не принесёт вам оффер, что другой человек платит ему x2 за те же токены. В OpenAI до этого ещё не додумались. Пожалуйста, не подсказывайте им.

Кто управляет разработкой AI-проекта Несколько лет назад во время очередного запуска я понял, как называется моя профессия. Проджект-менеджер. Почему-то многие фыркают на это название. Ну, деливери-менеджер. Ну ладно, AI-деливери-менеджер. Так точно должно звучать круто. Сейчас обсудим, что это за зверь и как им стать. В чем задача? Довести проект до прода. И чтобы он был успешным для бизнеса. Как вы понимаете, учитывая плачевную статистику AI-проектов, сделать это сложно. А чтобы ваши проекты были успешными, вам одновременно надо иметь: — Техническую адекватность. Вы должны хорошо знать ML, базово — бэкенд, немного фронтенд и продакт-менеджмент. Не лучше всех в команде, но достаточно, чтобы выслушать профессионала и понять его. — Хорошие софты. Лидерство. Короче, чтобы с вами было хорошо и приятно работать. — Любовь к принятию решений. Вы не самый сильный технарь, но вы должны брать на себя ответственность за финальное решение. Вам должно быть ОК принимать решения в условиях неопределенности. И отвечать за принятое. Откуда такие берутся? На самом деле пересечение этих трех осей довольно редкое. Такой милый технарь-решала (прям мой портрет, ей-богу!). Обычно они вырастают из двух профессий. Либо ML-щики с высокой тягой к ответственности и бизнес-эффектам (ваш покорный слуга). Либо продакты с инженерным образованием и желанием прокачиваться в тех. скилах. Я видел успешные кейсы и тех, и других. Хорошим проджект-менеджером AI-деливери-менеджером можно стать за несколько лет внедрения реальных кейсов. Успешного внедрения. Карьерные перспективы Это очень-очень дефицитная профессия. Ее уже не хватает, и дальше будет не хватать все сильнее. Взять этот ваш AI, собрать команду головорезов технарей и нанести непоправимую пользу бизнесу — это будет все востребованнее. Наносить пользу можно в разных масштабах: один агентик в соло, пять агентиков с командой — и вот ты уже трансформируешь огромную операционную функцию. Дальше можно и всю компанию! А что дальше? На самом деле, с точки зрения именно менеджмента, это довольно несложная профессия. Потому что это управление твоей продуктовой командой. Короче говоря, ты босс своего проекта. Более сильное менеджерское кунфу — это управление людьми, которые вне твоей команды. Там свои отдельные техники. Про это я тоже напишу пост. Когда сам разберусь. Обязательно разберусь, вот увидите.

Всеобъемлющая статья про инференс LLM Многие у меня спрашивают, как посчитать GPU и как после этого сохранить рассудок. Потому что насчитали столько, что даже начальник, который очень-очень любит ИИ, не окнет. Теперь у меня есть для вас решение: прочитать мою статью и начать оптимизировать насчитанное. Всю статью старался писать максимально простым языком, чтобы было понятно не только хардкорному инженеру. В ней есть: - Как устроен инференс LLM - Как оценить, сколько на него нужно GPU - Какие есть методы оптимизации - В каких движках это релизовано Читайте, делитесь с друзьями. И задавайте вовпросы в комментариях или в личные сообщения @seva_batareika.

Как стать AI-native компанией AI всегда был гонкой инфраструктуры. Если вы хотите крутые AI-продукты, пожалуйста, сделайте логирование всех данных, сложите их в огромное хранилище, потом варите из этого таблички, а сверху табличек обучайте модели на кластере. Хотите покруче — переходите на новую инфраструктуру. Через 2 года сможете. Чтобы варить лучшую AI-кашку, нужно иметь дорогой горшочек. Почти из золота. Мне, кстати, никогда это не нравилось. Я люблю 80% эффекта за 20% усилий. Поэтому мне нравится искать дырки в заборах: нетривиальные решения, которые срезают дорогие и долгие углы. Вот, например, последняя дырка в заборе — как мы описываем процесс для автоматизации через агентов. Дешево и быстро. А дорогие и долгие процессы мне не нравятся. Как-то неспортивно. Вот сейчас открылась огромная дырень в заборе технологичности. И я просто кайфую. Готовы узнать какая? AI может сам писать код. Наверное, вы ожидали инсайда покруче. Давайте еще раз. Дорогая инфраструктура — это код. AI может сам писать код. Так должно стать понятнее. Нету хорошего интерфейса для разметки? Навайбкодь его. Нет всех тулов для агентов? Навайбкодь их. Нету бизнес-описания процесса? Ах да, только что рассказывал. Конечно, мне стало тяжелее. Психологически. Стало сильно меньше отмазок, почему мой проект не взлетел. Надеюсь, так не только у меня. Ценность софта будет падать. Я допускаю, что через год Codex за 2 недели работы сделает с нуля неплохую A/B-платформу. Куда тогда инвестировать, если не в инфраструктуру? В людей. Инвестировать надо в людей. Именно этим я занимаюсь в этом канале и каждый день на работе. Один умный человек с правильными инструментами может найти дырку, пролезть в нее и вылезти обратно уже с мешком аплифтов. А если у вас есть бодрая опытная команда, она может собрать AI-экскаватор, которым уже можно дырявить огромные бетонные стены. И загребать ковшом тонны профита. AI-native — это люди. А не GPU, хранилища, кластера и крутые платформы. Главное — собрать таких людей. Ну и чтобы они потом не разбежались. Вы ведь не уйдете, правда?

Первый обзор научной статьи в этом канале Я не фанат читать свежие статьи. Сам когда-то занимался физикой и понимаю: 99 % работ никогда не доходят до применения. Читать сто статей, чтобы найти золото, я не могу — я не металлоискатель. У меня свой метод. Я статейный ждун. Жду, когда компании, у которых R&D-отдел в сто раз больше моего, перепробуют все эти статьи и найдут, что реально работает. А потом хитрый ждун про это узнаёт: от знакомых, из пресс-релизов или из тех же статей, но уже от самой компании — с комментарием, где оно работает в проде. Сегодня смотрим на метод, которого я дождался, — AlphaEvolve. По слухам, его уже вовсю применяют наши большие западные коллеги. А теперь и я сам убедился в адекватности подхода. Садитесь поудобнее. Что такое AlphaEvolve Статья Google DeepMind. Идея проста. Если у вас есть метрика, которую можно посчитать автоматически, — вы можете оптимизировать под неё промпт. Не трогая веса. Генетическим алгоритмом. В статье делали для кода, но метод работает для любой задачи, где есть внятная метрика. Стартуем с одного промпта, складываем его в базу. Дальше цикл. Из базы достаётся промпт-родитель, а вместе с ним ещё несколько соседей — часть лучших, часть просто непохожих, чтобы не залипнуть в локальном оптимуме. Всё это уходит в LLM вместе с метриками качества: посмотри, что уже пробовали, предложи точечную правку промпта-родителя. Правку накладываем, считаем метрику, удачное возвращается в базу. И так тысячи раз. Что этим методом наоптимизировали в самой статье: — планировщик Borg: 0,7 % всех мощностей Google, больше года в проде — FlashAttention: в одной боевой конфигурации инференса ядро на 32 % быстрее — и даже побили рекорд перемножения комплексных матриц 4×4 Но применять можно к чему угодно. Хоть к классификации текстов: тюним промпт по F1 на обучающей выборке, финально меряем на тестовой (только не перепутайте!). Почему я думаю, что за этим будущее Одно слово. Интерпретируемость. Это основная проблема всех AI-моделей. А тут вы буквально видите, что «оптимизатор» выучивает из обучающей выборки. Когда вы оптимизируете веса, вы живёте в чёрном ящике. Может, у вас датасет смещён и модель учит вообще не то — узнаете вы об этом уже в продакшене. Когда вы оптимизируете текст, на каждой итерации видно, что именно в него вносится. И нежелательное изменение можно откатить. Ещё вы можете явно задать правила оптимизации: про это пиши, про это не пиши. Настоящий рай для любителей всё контролировать (мне, например, очень нравится). Что вам надо делать сейчас Важно: это работает, но только на крупных моделях, которые умеют в длинный контекст. Ваш любимый 1.5B Qwen не вытянет. Но на топ-тир моделях оно заводится. А если нужно подешевле, то давайте дистиллировать результат в веса любимого Qwen'а. И весь такой цикл работает по кнопке: автоматически подобрали промпт на крутой модели, автоматически продистиллировали в веса маленькой. Думаю, вскоре и обычные Qwen'ы научатся так делать. И нафига тогда я отличия Adam от SGD в универе учил?

Вам 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 лет прошло. И только сейчас до меня дошло.

Топ постов Всеволода Викулина (по мнению Всеволода Викулина) За последнее время я написал несколько действительно хороших материалов. Но мне решительно не нравится, что еще не все их прочли. Давайте это исправлять! Посты - Почему все делают AI-пилоты, которые я ненавижу - Почему вам должно быть пофиг на рисовалки агентов - Как я очень очень не люблю векторный поиск - Уже пора не делать агентов, а делать агентов, которые делают агентов - Как мы настраиваем метрики качества через пирамиду - Как оценивать инженеров через бодрость - Основный принцип инференса LLM. Разобрался, и мир абсолютно понятен Статьи - Реальная автоматизация: почему внедрения AI‑агентов проваливаются — и что с этим делать Видео - Как мы внедряем GenAI в клиентскую поддержку - Стратегия внедрия AI-агентов в корпорации

Какие команды добиваются экстраординарных результатов Я ужасный разработчик. Если бы вы видели мой код в проде, вы бы отписались от этого канала. Я довольно неплохой ML-щик: знаю много разных методов (потому что я старый)). Но многие в нашей команде сильно продвинутее меня. Но я отличный менеджер. Если брать менеджмент в ML, я бы, думаю, попал в топ-30 до 30 :) Так что иногда буду писать про управление командами. Какие команды добиваются экстраординарных результатов? Маленькие. Есть пошлое слово talent density — вот это про это. Почему так? Во-первых, бизнес-эффект нелинейно зависит от качества решения. Агент, сделанный на 10% лучше, может дать экономию на 10 тысяч % больше. А качество решения в сложных R&D-задачах определяется самым сильным человеком в команде, а не суммой всех человеков. Так что вам выгоднее, чтобы самую сложную и дорогую проблему решил один гений, а не двести средних. Во-вторых, главная мотивация сильных людей — вы не поверите — работать с сильными людьми. Поэтому если хотите кого-то нанять и удержать, придётся вырастить вокруг него интеллектуальный сад сильных коллег. Ну и приятный бонус для менеджера. Когда команда маленькая, вы можете каждую секунду направлять самого сильного человека на самую важную проблему. И убирать все препятствия, что ему мешают. Вы ведь сильный менеджер, правда? Конечно, есть большие и понятные задачи — например, интеграции чего-то с чем-то. Работа ясная, её просто очень много: надо сесть, заспекать огромный функционал и навалиться. Никакой десант гениев тут не поможет. Хотя… Есть же ИИ-агенты. Может ли один гений со ста Клод-кодами сделать работу, на которую раньше нанимали крупного интегратора? Доживу ли я до этого? Шучу, конечно доживу. Я даже думаю, что я это сделаю. Шучу. Мы это сделаем.

Улучшаем качество без обучения. Диаграмма контекст–compute Я много писал про важность контекста — пришло время упаковать это в нормальную схему. Напомню: у вас два рычага — вычисления на инференсе и контекст. Шаг 0. Берём самую жирную модель, что доступна, и включаем ризонинг, чтобы рассуждала подольше. Экономика не бьётся — пофиг, бабки не проблема. Шаг 1. Берём датасет, прогоняем на нём наш космолёт, смотрим ошибки, собираем контент, который эти ошибки исправляет. Лучше делать это в цикле через другого агента — подробнее тут. Шаг 2. Потом окажется, что знаний дофига, но в них сложно ориентироваться, и модель начинает тупить. Теперь мы упрощаем доступ к знаниям. Улучшаем описания тулов, добавляем заголовки и теги. Строим харнесс, чтобы подсасывать в модель только лучшее. Часть контента дропаем, часть суммаризуем. Тут в итоге должно случиться офигенное качество. Шаг 3. Начинаем сжимать модель — и тоже через контекст. Модель меньше, но это не беда, ведь у нас есть эталон из шага 2. Теперь мы пишем контекст, но чтобы мимикририровать под ответы большой модели. Для этого можно использовать разные алгоритмы оптимизации, например, генетические алгоритмы (никогда не думал, что на полном серьезе это напишу). Написали ответ -> сравнили с большой моделью -> дифф рассуждений отправили в промпт. Да, вы правы, это очень похоже на дистилляцию. Это она и есть. Качество может просесть, но не так сильно, как кажется. Готово, вы восхитительны. Кстати, всё это делается прямо по API, вообще без своих GPU. Главное — чтобы был эвал, под который собирать контекст. Дальше уже дело техники. Про детали этой техники есть много интересных идей/статей, обсудим их вместе с вами.

Запись моего выступления на Data Fest Находится вот тут. Говорил про экономику и стратегию. Про правильные процессы и полезных в них агентов. Про платформы и форвард-деплойд инженеров. И много шутил. Местами даже удачно. Местами мне до сих пор неловко. Вам точно понравится.

Внедрить AI — это испить чашу боли. А можно ли иначе? Во-первых, я говорю только про крупные внедрения, которые видны в P&L компании. Если вы сделали ассистента, которым никто не пользуется, — это тоже больно, но по-другому. Во-вторых, я не говорю про «продуктовый AI» — это когда у вас большая поверхность в продукте и похожие задачи на входе. Рекомендательные системы, поиск, кредитный скоринг и так далее. Там тоже тяжело, но тяжело технологически. А я — про боль. Мне больно, потому что У ВСЕХ ВСЕ ПО-РАЗНОМУ. Каждый процесс в поддержке отличается от соседнего. Так же будет в бухгалтерии, в разработке и где угодно ещё. У всех миллион интеграций, и большая часть из них устроена по-своему — как будто только для того, чтобы мне было больно (подробнее читайте в моей статье). Хитрый трюк: сделать так, чтобы больно было, но не вам Платформа. Накрутить заранее миллиард кастомизаций, закопать их в двадцать слоёв интерфейса и написать три тома документации. Чтобы потом каждый смог сам себе встроить агента (если разберётся). Проблема: это очень много кода. Все возможные эвалы, интеграции, методы тюнинга промптов заставят огромную команду долго потеть. Так можно — если у вас есть венчур и умение делать продукт. У меня нет ни того, ни другого. Поэтому платформу из миллиарда строчек кода я делать не хочу. Вы не поверите, но я опять буду делать агентов. Код-агентов. — Агент, который напишет тулы под конкретную интеграцию. — Агент, который оценит итоги конкретного A/B-эксперимента. — Агент, который подберёт промпт для конкретного агента (мы разбирали тут). Звучит как фантазия спятившего менеджера, но оно заводится. Об этом я рассказывал на недавнем митапе. Моя платформа — это тончайший слой поверх галеры AI-гребцов, которые под ключ сделают любую кастомную интеграцию. Без кучи денег на разработку. На слабоумии и отваге. По-моему, неплохое топливо. Ну а чего вы от меня ожидали?