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

Первый обзор научной статьи в этом канале Я не фанат читать свежие статьи. Сам когда-то занимался физикой и понимаю: 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-гребцов, которые под ключ сделают любую кастомную интеграцию. Без кучи денег на разработку. На слабоумии и отваге. По-моему, неплохое топливо. Ну а чего вы от меня ожидали?

Чтобы ускорить инференс LLM, надо всего лишь... ЧИТАТЬ ДАЛЕЕ Не все понимают, что тормозит инференс LLM. Сейчас расскажу — и, честно говоря, дальше вы уже сможете без меня. Почти вся оптимизация следует из этого. Всему виной то, что мы... ГОНЯЕМ ВЕСА ТУДА-СЮДА Совсем базово. В GPU, как и в других вычислительных устройствах, есть два класса памяти: DRAM и SRAM (хихихи, но не так смешно как JEPA у Лекуна). DRAM — относительно дешёвая и относительно медленная. Именно туда вы загружаете модель, когда поднимаете инференс. Допустим, у вас модель на 35B параметров и вы храните её в fp16 (2 байта на вес). Значит, нужно 70 ГБ DRAM. Дальше разбираем на примере H100: там 80 ГБ. Влезло. SRAM — дорогая и быстрая. Дорогого и быстрого логично давать умеренно. В 1000 раз меньше. Зато SRAM сидит вплотную к ядрам, на которых и происходят вычисления. Поэтому веса модели перетекают из DRAM в SRAM — на H100 со скоростью 3,3 ТБ/с. Теперь самая тупая математика. Чтобы перетащить 70 ГБ весов со скоростью 3,3 ТБ/с, нужно 70 / 3300 = 21 мс. Декодинг идёт токен за токеном, то есть ради каждого проклятого токена надо каждый раз прогнать через шину эти проклятые 70 гигабайт. Поздравляю, ваша максимальная скорость — 1 / 21 мс = 47 токенов в секунду. Прочувствуйте это. Мы еще ничего не считаем. При полной загрузки 70 ГБ весов вы никак не сделаете декодинг на 1 H100 быстрее 47 ток/секунду. Это, мне кажется, действительно забавно. Вы купили за много миллионов рублей H100, которая умеет делать ОДИН КВАДРИЛЛИОН операций в секунду. Я даже гуглил это слово. А карта сидит холодная, потому что всё время уходит на перекачку весов. Это называется тупизм memory-bound режим. Чтобы не быть настолько идиотом, возникает логичная идея. Раз я уж эти проклятущие веса из DRAM в SRAM перегнал — может, я обслужу не один запрос, а сразу несколько? Веса-то одни и те же. Чтобы H100 моя родненькая не стояла холодненькая. Поздравляю, вы придумали батч. Если растить батч больше и больше, рано или поздно вы упрётесь уже в сами вычисления, в эти самые квадриллионы операций. Тогда вы попадёте в compute-bound режим. Теперь реально понятно, как ускорять — Квантизация. Храним вес не в 2 байтах, а в 1 или меньше — гонять через шину нужно вдвое меньше данных. — Спекулятивный декодинг. Маленькая модель набрасывает несколько токенов, а большая проверяет их за один проход — то есть за одну прогонку весов. — MoE-архитектура. Из памяти на каждом токене читаем только активные веса, а не всю модель (с батчом это работает хуже, обсудим потом). И много чего ещё. И всё — вокруг одной и той же проблемы. Часто, чтобы разобраться с кучей инженерных методов, надо понять всего один базовый принцип. Сегодня мы поняли его для инференса: ХВАТИТ ГОНЯТЬ ВЕСА ТУДА-СЮДА. Теперь у вас точно всё получится ^^

Бизнес-модель моего телеграм-канала Клянусь вам: раз в неделю мне пишут продюсеры онлайн-курсов. «Сева, у тебя такой классный контент, но ты не монетизируешь его на максимум! Давай опрос проведём, вороночку построим, курсик запишем, прибыль поделим». После быстрого ответа «Нет» они удивляются: а зачем тогда всё это, если не ради того, чтобы стричь бабло? Сейчас расскажу. Я хочу собрать самое крутое сообщество, которое внедряет AI в бизнес. По-настоящему. Не придумывает бесполезные стратегии AI-трансформации. Не вайбкодит личного ассистента для почты генерального директора. Не продаёт курсы «Как стать AI-native мясокомбинатом». Я собираю людей, которые действительно хотят менять этот мир с помощью AI, и помогаю им этого добиться. Тремя способами: — бесплатным советом (просто пишите в личку с вопросом); — совместной работой (мы нанимаем :)); — вот такими, надеюсь, не самыми бесполезными постами. Для вас я делаю этот канал, для вас пишу этот пост — и безумно благодарен вам за доверие. Нас уже 5 тысяч. Мы провели первый совместный митап. Спасибо, друзья: наше сообщество начало строиться. Отдельно благодарю Юлю — мою самую преданную подписчицу и любимую жену. Без её поддержки я бы за это точно не взялся. Ну правда, вы посмотрите на эти подарки! Торт уже во мне.

5 лет проведения собеседований в одном посте Эта картинка стоила мне 5-ти лет опыта нанимающего менеджера и 3-х лет интенсивной психотерапии. На финальной встрече я редко спрашиваю что-то про LLM. Во-первых, потому что уже до меня спросили. Во-вторых и в главных — потому что я уверен, что это не главное. Те методы NLP-разработки, которые применяем мы сейчас, год назад не использовал вообще никто. А еще через год все снова поменяется. Главное, что я ищу в кандидате, — это софты. И главный из них — бодрость. Термин я украл у бывшего руководителя из Яндекса. Уверен, что, если спросить нас обоих, мы дадим разные определения этого качества. Но при этом я уверен, что понимаем мы его одинаково. Бодрость — это когда человека просишь, и он решает. Он не просит у тебя точного ТЗ, он сам задаст все вопросы. Он не думает про Scrum и Kanban: если нужно, он сам навайбкодит себе подходящий фреймворк. Он сам найдет бездомную команду и внушит ей, что теперь для нее это самая важная задача в мире. Он думает про результат и с улыбкой относится к неопределенности его достижения. У меня даже появился тест на бодрость: если в проекте неожиданно всплывает задача, которую хрен пойми как делать, но надо очень и еще вчера — на ум приходит он. Тот самый мистер Бодрость. Выявлять это чудесное качество можно при разговоре. Слушайте, за что человек отвечал в проекте. Если МЛ-щик писал веб-приложение, потому что все разработчики были заняты, — мне он нравится. А если он еще и никогда раньше этого не делал и сам разобрался с ЧатГПТ — мое сердечко бьется сильно-сильно. Не на все задачи нужны бодрые. Во-первых, им бывает скучно, и вам придется постоянно их челленджить. Во-вторых, они не подходят для системной работы. Если составить команду только из них, они через какое-то время закопаются в своей бодрости. И разрушат вам продакшен. Помимо бодрых, нужны люди, которые умеют строить системные процессы. Долгие цели, спринты, демо, груминги… Что там еще есть? Я — не умею. Я — бодрый. Поэтому я их нанимаю :)

Как вам улучшать LLM, если я запрещаю их дообучать Я, кажется, самый большой хейтер дообучения в индустрии. Не потому что не умею — а потому что это технически очень сложная задача, которая может сломать вам жизнь LLM. Писал подробнее тут и тут. И каждый раз слышу в ответ: ты, конечно, умный, Всеволод, но вот у нас качество не 100 %. Как нам улучшать модель без обучения?! Любимая привычка двигать веса в сторону локального минимума засела в нас так крепко, что мы разучились делать все остальное. Что ж, будем меняться. 1. Самое главное — контекст. Это ровно тот же backpropagation, только через текст, а не через веса. Посмотрите на цикл: модель ошиблась → вы нашли примеры, где она ошибается (на самом деле другой агент нашел) → дописали их в контекст → перезапустили замер. Очевидные плюсы. Веса не меняются, можно сервить в одном месте. Все очень наглядно — можно глазками проверить, что сейчас меняется. Легко пофиксить, если ваш начальник увидел в проде не понравившийся ему ответ. И главное — это, черт возьми, работает. Уже есть огромное число статей, многие из которых нам придется вместе разобрать, чтобы удостовериться. 2. Второе поважности — сompute. То, насколько много вычислений вы тратите на инференс модели. Для LLM есть даже отдельные законы масштабирования, которые показывают, как растет качетво, чем больше вычислений вы наваливаете. Берите модель с параметрами побольше. Дайте ей порасуcждать подольше. Побейте задачу на подзазачи, решите разные промптами. Дорого? Оптимизируйте инференс. Есть куча методов, один из них мы обсуждали на митапе. Работы у нас с вами будет еще очень много. Только, думаю, не придется learning rate по графику подбирать. А вам это нравилось? Мне, если честно, не очень. Уж лучше json md-файлики перекладывать.

Если вы пропустили наш митап по внедрению GenAI в обслуживание То мы его записали: YouTube и ВК. Там 4 крутецких доклада: 1. Вводный про стратегию и платформу 2. Как мы замеряем качество агентов 3. Про спекулятивный декодинг 4. GenAI поверх интерфейсов сотрудников. Рекомендую смотреть ровно в таком порядке. Ссылки на презентации на странице мероприятия. Будут еще крутые митапы, где мы будем собираться нашем уютном комьюнити и делиться, как внедрять агентиков в суровый энтерпрайз. Честно. Технологично. И с чувством юмора :)

Один контекст, что правит всеми В прошлом посте мы обсуждали, как устроена оценка агентов вообще. Сейчас я расскажу, что конкретно делаем мы. И почему я считаю, что это очень круто. О что заземляться Чтобы измерить качество агента, нужен ground truth — точка опоры, относительно которой видно, где он накосячил. Первое, что приходит в голову — взять экспертов. Cпрашивать их: хороший ответ или плохой. Идея рабочая ровно до того момента, пока вы не захотите что-то с ней сделать. Мнение эксперта живёт у него в голове. Его нельзя пересмотреть, про него можно только на кухне поспорить. Вы получаете оценку, но не получаете рычага, как ее улучшить. Регламент — другое дело. Агент отступил от правила — ошибка. Но нельзя просто так взять и написать эту базу знаний выписать. У людей куча правил, которые для них слишком очевидны, чтобы их проговаривать. Поэтому мы строим отдельный агентский пайплайн, который эти знания собирает, об этом я писал в посте. Как схема идеально замыкается — Асессор по базе размечает — смотрит на ответ агента и сверяет, где тот разошёлся с регламентом. — Агент по ней же работает — решает обращение клиента, сверяясь с правилами. — LLM-as-a-judge калибруется об разметку асессоров (напомню, они сами читают ту же базу) и тоже размечает — Теоретически, по этой же самой базе может работать не только агент, но и сотрудник. Там, где агент пасует, за дело берётся живой оператор — и работает по тому же контексту, что и LLM. Складывается в квадрат: агент и человек — те, кто действует; judge и асессор — те, кто проверяет. Четыре роли, один контекст под ними. Это делает систему невероятно гибкой. Поменял ошибку, про это сразу узнали все. Появилось новое правило, моментально проросло всей системе. Да и людей можно будет джаджами замерять :) Конечно, интерфейсы к контексту у человека и LLM разные. Для человека есть целая область: User Interface (UI). Пока Agent Interface лучшие умы еще зарождают, можно делать по старинке: дал агенту grep — и он сам выгреб нужный кусок. И реально работает! Где я вас обманул Звучит слишком идеально, чтобы быть правдой. Внимательный читатель канала уже должен понять, в чем подвох. В этой схеме мы никак не проверяем сбор самого контекста. Соберём базу криво — все наши четыре друга посыпятся одновременно. Контекст должен полным, без ошибок и противоречий. Полноту, допустим, можно обкалибровать об ответы сотрудников. Но потом надо все проверить на адекватность с помощью других людей, например, особо внимательной команды редакторов. Приятное в том, что часто проверять базу не нужно. Только переодически просматривать по регламенту. Заключение Я рассказал вам все, что знаю сам (а знаю я немного). Как собирать контекст для агентов, как об него калибровать разметчиков, и как это все работает вместе. Это же наша команда рассказывала на недавном митапе (скоро выложу видео!). Если остались вопросы, пишите в комментариях или в личные сообщения. Дальше будем активно разбирать инференс LLM.

Пирамида метрик качества Когда я разбираюсь, как в проекте устроена оценка качества, меньше всего я хочу найти промпт к GPT-5: «По шкале от 1 бегемотика до 10 бегемотиков оцени, насколько этот ответ полезен пользователю». Но эта школа мысли меня как будто преследует. Прогнали на десяти примерах, вроде что-то выдаёт. LLM-as-a-judge готов, расходимся. Не расходимся. Читаем этот пост. Слои пирамиды Каждый инструмент нужно скалибровать: оценить качество относительно эталона. Мы уже разбирали в статье, что размечать можно как людьми (асессорами), так и моделями (LLM-as-a-judge). То есть калибровать надо всех: LLM, асессоров, людей, которые калибруют асессоров, людей, которые калибруют тех, кто... Ну, вы поняли. В итоге всё это складывается в понятную пирамиду. Она устроена по принципу генерализации: чем выше слой, тем быстрее схватывает разметчик. Но и тем дороже разметить каждый пример. — На вершине владелец продукта. Он же заказчик, он же бизнес-эксперт. Формулирует принципы продукта и объясняет их команде. — Продуктовая команда. Калибруется через общение с владельцем. Согласованно с этими принципами размечает несколько сотен примеров и пишет инструкцию. — Редакция. Несколько десятков доверенных разметчиков, часто в штате. Калибруется через инструкцию и общение с продуктовой командой. Генерирует контрольные задания (ханипоты). — Обычные разметчики (асессоры). Калибруются через инструкцию и ханипоты редакции. — LLM-система. Дно пирамиды. Калибровка LLM-судьи об асессоров — это отдельный AI-проект: сбор данных, проверка качества, контекст-инжиниринг. Как слои работают вместе Регулярную разметку продакшена можно целиком отдать LLM-as-a-judge. Если у вас разваливается прод, вы увидите падение даже на грубой метрике. А тонкие релизы, где качество меняется на несколько процентов, отдавайте наверх: релизы редкие, а точность нужна. Ещё лучше — гибридные схемы с эскалацией. Сначала работает нижний слой. Не уверен — передаёт наверх. Сэмплируем ответ LLM несколько раз, ответы разошлись — отдаём разметчику. Два асессора не смогли договориться — отдаём редактору за финальным вердиктом. Глубина пирамиды зависит от задачи Для простой задачи высокая пирамида не нужна. Разметили командой 200 примеров, пошли калибровать промпт судьи. Всё. Потому что на простой задаче LLM уже хорошо обобщается. Вам не надо проверять на тысяче примеров, что она точно поняла, где кошечка, а где собачка. А теперь возьмём разметку галлюцинаций. Что значит «модель врёт»? Где грань между додумыванием и следствием? Если считать галлюцинацией всё, что напрямую не следует из контекста, ваш чат-бот превратится в тупого пересказчика. Чтобы описать все грани ваших (и моих тоже) галлюцинаций, спокойно уйдёт месяц. Потом ещё месяц, чтобы объяснить это команде. А потом ещё четыре вы будете объяснять это асессорам. Надеюсь, они вас поймут. Самое дорогое — это люди посередине Откалибровать LLM-судью — это несколько недель обычного AI-проекта. Контекст-инжиниринг, проверка качества, взять модель побольше (самое любимое). Это делается легко, если есть слой, об который калиброваться. А вот обучить сотни людей — совсем другая история. Их нельзя поправить промптом (иногда мне жаль). Приходится строить целые операционные процессы: экзамен, переэкзаменовка, контрольные задания, которые перезапускаются при любом изменении инструкции. Резюме Стройте пирамиду. Точно — верхние слои и LLM-судью. Но каждый средний слой — это месяцы операционной работы с людьми. Если рассудок и жизнь дороги вам, старайтесь максимально избегать этого класса работ. Ввязывайтесь в это только, если у вас вам нужна пропускная способность больше, чем у редакции и точность больше, чем у LLM. Поэтому часто мой совет командам, что им не стоит размечать асессорами. Ведь обучать людей — это вам не промпт инжинирить.

Агенты, которые делают агентов Мой главный принцип в работе — фокус. Обычно самое важное кроется только в одной ключевой вещи, а всё остальное можно сделать потом, другими людьми или не делать вообще (чаще всего можно не делать). Мы долго пытались найти эту вещь в разработке агентов. Кажется, нашли. Эта ключевая вещь — контекст. А точнее, способ его построения. Неважно, какой у вас оркестратор. Не очень важно, какая под ним LLM — если у неё нет правильного контекста, даже самая мощная модель не справится. И уж совсем неважно, в какой Ui-ке вы всё это рисуете. Почему нельзя просто взять и написать контекст Потому что непонятно, что именно нужно написать. Заранее вы не можете знать что у LLM было в претрейне, а что нужно объяснить про вашу задачу. Знает ли этот стандарт принятый у вас в разработке? А этот аспект права? А слышала ли про новый банковский продукт? Поэтому проще считать, что LLM не знает ничего про вашу задачу. Самое наивное тогда решение — прийти к бизнес-эксперту и попросить выписать вообще все. Какие правила процесса, какие есть API, как их вызывать. Но эксперт не может проверить, что выдал реально всё. У любого человека есть знания, которые для него настолько очевидны, что он даже не подумает их проговорить. И вот на них агент сломается, потому что не будет знать, как действовать Как мы делаем вместо этого Не нужно разово пытаться вытащить знания из головы эксперта. Нужно строить процесс, который проверяет, насколько контекст полный. Берём ground truth — например, реальные ответы человека. Разбиваем его на отдельные утверждения. И проверяем другим агентом: подтверждается ли каждое утверждение тем контекстом, который у нас уже есть? Если не подтверждается — это сигнал. Либо бизнес-эксперту нужно дописать правило, либо разработке нужно сделать недостающий тул. И процент за процентом контекст наполняется — до состояния, с которым первый агент может работать. По сути, это и есть обучение на ответах. Только не через градиентный спуск, а через тексты. Мы восстанавливаем правила, зашитые в головах людей, в текстовый контент. Куда это все идет Команда (горжусь вами) придумала это довольно давно, но я до сих пор в шоке. Этот нехитрый трюк — самый простой способ строить агентские системы в принципе. Возьмите классификатор. Запускаете одну модель с промптом на тестовом множестве. Другая модель читает её рассуждения, смотрит на ошибки, выделяет кластеры типовых промахов, правит промпт первой модели. Повторяете до сходимости. Это чистый backprop через изменение контекста. Я не вижу ни одной причины, почему уже сейчас не делать так всегда. Если вы построили эвал, то сразу можете замкнуть цикл обратной связи на другом агенте и пойти делать что-то другое. Например, читать этот канал. Хватит рисовать агентов в вашем любимом n8n. Они уже неплохо справляются с этим сами.

Друзья, огромное спасибо, что пришли! Было невероятно круто сегодня выступать и с вами общаться после докладов! Горжусь, что нахожусь в таком классном комьюнити! Думаю, продолжим встречаться в разных форматах и обсуждать, как сделать ИИ-агентов, чтобы поменьше работать нам самим :) До встречи!!!

Кто такой хороший AI-инженер? Я не жду от хорошего инженера, что он сделает модель. Это само собой разумеется :) Разработка моделей стала практически комодити. Во-первых, есть огромное число уже готовых LLM, которые надо только запромптить. Во-вторых, если нужна своя модель, есть огромное количество готовых решений, туториалов, как модели дообучать. Да, придется покопаться, но для большинства случаев опытный разработчик за месяц разберется. В-третьих, скоро все это все равно напишет Claude :) Я жду от хорошего инженера, что он возьмет ответственность за результат проекта. От формулировки гипотезы и планирования разработки до деплоя и мониторинга качества проекта. Почему так? LLM разработка — это жесткий R&D. Никто ничего не знает заранее. Нужно уметь быстро проверять гипотезы и верстать план прямо на ходу. Это требует опыта и технической интуиции, которая есть только у опытного разработчика. Здесь потребуется смесь различных навыков. Умение видеть целевое решение, разбивать это решение на этапы, выбирать метрики качества, дизайнить эксперименты. Еще потребуются софтовые навыки. Чтобы успешно работать со смежными командами и убеждать их, что вы точно знаете, что делать (хотя на самом деле — нет). Подробно про эти навыки я написал в своей отдельной статье. Это список качеств инженера, который способен сделать результат.

Сынок, ты связался с плохой компанией? Мама, я ее основал Анонс: наша команда 29-го июня в офисе Т-Банка проведет митап по внедрению GenAI в операционку. У меня есть твердая уверенность, что я знаю, как это сделать. У вас есть возможность после митапа убедить меня, что я не прав :) Я подробно расскажу нашу стратегию внедрения агентов. Как трансформируем бизнес-процесс, как делаем контекст-инжиниринг, какие под капотом LLM, какие уже есть эффекты. Помимо моего, будут еще крутецкие доклады. Про контроль качества агентов, про оптимизацию LLM-инференса, про GenAI поверх интерфейсов сотрудников. После докладов, уверен, у нас будет много тем для личного обсуждения! Регистрируйтесь по ссылке. Друзья, до встречи!

Учим машину экспертным суждениям Я недавно украл у Sequoia разделение умственной работы на 2 класса: intelligence и judgment. Нормально перевести не смог. Intelligence — это когда задачу можно решить по понятной инструкции. Judgment — это когда для задачи нужны опыт и интуиция эксперта. На примере разработки. Intelligence — дописать кусок кода по подробному ТЗ от синьора. Judgment — придумать архитектуру высоконагруженного сервиса. Да, и там и там нужно уметь кодить. Но в первом случае у вас уже есть рамка и понятный способ действовать (если вы прочитали книжку по языку программированию). Для второго кейса книжки я не знаю. Человекам — Judgment. Агентам — intelligence. Вайбкодинг хорошо работает у сильных инженеров. Эксперт уже принял важные решения и упаковал их в хороший промпт, примеры, тесты. От модели требуется просто быть послушной. А если вайбкодить начинает не-разработчик, то на кейсах, где нужен judgment, агент наагентит ему таких решений, что никто не разберется. Автономным агентам нельзя отдавать judgment. Даже если написать в промпте “представь, что ты Бьёрн Страуструп”, не факт что потом C++ сервис выдержит нужную нагрузку. (Подставлять в промпт Всеволода Викулина я бы тоже не рекомендовал.) То, что вчера было judgment, сегодня уже intelligence. Когда-то сделать сайт было задачей для человека с головой и руками. Теперь это commodity. LLM уже видели достаточно кода, чтобы делать такое почти из коробки. (Я, кстати, без головы и рук тоже создал свой статический сайт). Во многих задачах экспертиза давно растворился в весах LLM. В весах лучше всего растворяется массовые знания. А ваш уникальный экспертный процесс в данных почти не встречается. Так что в нужный вам judgment LLM не умеет. И тут есть соблазн: соберём примеры лучших экспертов, дообучим модель — и она тоже станет экспертом. Ух, как я это ненавижу. Два пути, как занести judgment в агента Разберем на примере sales-агента. Первый путь — классический ML-подход. Берём лучших продажников, собираем их диалоги, дообучаем open-source модель на их ответах и надеемся, что “секретный рецепт продаж” как-то перетечёт в веса. Скорее всего, не получится. Во-первых, когда вы дообучаете модель на узком датасете, вы меняете огромную систему, которую до этого долго обучали и тестировали на куче разных задач. Скорее всего, вы ее сломаете. Нет надёжного способа выучить “тонкий секретный рецепт, как продавать ручку” так, чтобы модель не начала галлюцинировать и не сломала обобщающую способность. Во-вторых, если у вас нет явной методики продаж, то у вас нет и нормальной разметки качества. Нельзя просто собрать трёх экспертов и сказать: “Оцените в силу своей экспертности, хороший ли это ответ”. У каждого свой judgment. Разметка становится шумной. Качество — неуправляемым. Второй путь — выносим judgment в контекст. Берём экспертов по продажам и вытаскиваем из них правила: как квалифицировать лида, какие есть сценарии, как отвечать на типовые возражения. Потом всё это кладём в контекст модели либо в базу, по которой модель будет искать. Мы выносим judgment наружу и заставляем модель по нему действовать. Если вы реально вынесли все, то обычная LLM с задачей легко справится, И по тому же контексту разметчики затем смогут контролируемо размечать каечество. Ну не сказка ли? Резюме Всю работу в AI можно описать как "учим машину экспертным суждениям". В агентской разработке победил не путь “зашьём экспертизу в веса модели". Победил “разложим экспертизу во внешний контекст и научим модель им пользоваться”. Да, в этом пути куча проблем: как собирать экспертизу, как агент должен искать нужный кусок контекста, как это всё правильно оценивать. Это звучит гораздо скучнее, чем fine-tuning на лучших в мире экспертах. Зато работает.

Почему даже OpenAI пошёл в консалтинг Когда я начинал, делать AI было просто: — Есть поиск — собираешь метрику качества поиска, оптимизируешь модель. — Есть рекомендации — берёшь историю покупок клиентов, оптимизируешь модель. — Есть детекция поломок — берёшь поломки... Ну, идею вы поняли. И организационно всё тоже суперпросто: команда квартал за кварталом улучшает метрику своего куска системы. Если этот кусок дорогой, команда окупается, и все счастливы. А что с LLM? Как и раньше, где-то сидит инженер OpenAI, оптимизирует мегамодель по куче хитрых бенчмарков за очень много венчурных денег. Но он, хитрюга, только выкатывает её под API. Дальше потребителю надо вкорячить этот API и оптимизировать свой процесс. И вот тогда родится Польза. Звучит заманчиво. И, кстати, вкорячивать LLM действительно стало просто. Вот только эффекты от этого никого не радуют. Почему схема ломается Частично я это объяснял в посте про платформу агентов. Если вкратце: — Иметь ручку к LLM — это только входной билет на аттракцион. Ещё нужны нормальные тулы, бизнес-правила (контекст агента) и методика оценки качества. Подробнее — в моей статье. — Ничего из этого вам никто не продаст. Не продаст чёрную коробку, которая сама навайбкодит хорошие инструменты для агента, сама поймёт ваш бизнес-процесс, сама напишет правильный контекст и сама ещё честно проверит, что всё это работает. — Кто-то с LLM-апишкой, или с любой другой платформой, должен пройти «последнюю милю внедрения». То есть прийти в конкретный процесс, разобрать его до атомов, понять, какие там реальные бизнес-правила, где лежат данные, какие нужны тулы, какие ошибки допустимы, — и потом уже под это собрать систему. Чем отвечает OpenAI API-шки плохо встраиваются в крупных клиентов, и OpenAI проигрывает долю внедрений в B2B Anthropic. Что бы вы сделали, будь у вас куча денег и нехватка экспертизы? Правильно: купили бы консалтинговую компанию, которая будет внедрять ваши API (общая сумма инвестиций 4 млрд $). Прошу прощения, «консультанты» — это не модно, поэтому в маркетинговых недрах Сан-Франциско придумали отдельную профессию — Forward Deployed Engineer. Это консультант инженер, который приходит к заказчику и проходит с ним последнюю милю: помогает собрать правильный контекст, настроить evals, спроектировать нужные тулы. Потом, конечно же, ставит клиенту правильную API-шку, внедряет её ещё в один процесс, потом ещё в один — и в итоге крупный клиент приносит столько денег, что весь этот схематоз окупается. Это, кстати, не самая свежая идея: Anthropic уже давно таких людей нанимает. Нудное резюме Нельзя просто сделать AI-платформу и надеяться, что кто-то другой героически перестроит на ней процесс, а потом напишет нам отличный отзыв на ревью. Не перестроит. Не напишет. Не потому, что он плохой, а потому, что это реально сложно. Это передовой R&D, который мало кто в мире умеет внедрять. (хотя, если у вас есть 4 млрд $, можете купить тех, кто внедрит) Платформа важна, но не как конечное решение, а как ускоритель каждого внедрения: пайплайны подбора контекста, мануалы по написанию тулов, готовые команды разметчиков для evals. Именно так мы и внедряем агентов в обслуживание Т-Банка: понимаем процессы, работаем над контекстом, проектируем тулы. И ещё делаем это на своих LLM. Если вам откликается такой подход, пишите мне: мы нанимаем NLP-инженеров, бэкенд-разработчиков, продуктовых аналитиков и продакт-менеджеров. До встречи!