Всеволод Викулин | AI разбор

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-инженеров, бэкенд-разработчиков, продуктовых аналитиков и продакт-менеджеров. До встречи!

Если вдруг вы устали читать мою духоту, то теперь можете ее еще и послушать! В эту субботу 23 мая буду выступать на Data Fest 2026 в секции Data Strategy. Секция пройдет в главном зале, мой доклад в 13:40. Поговорим, как выбирать кейсы в агентах и про реальную автоматизацию в них. Приходите! После выступления пообщаемся (с теми кто не ставит клоунов мне на посты)))

Почему я ненавижу векторный поиск Возьмите любую статью, где автор делал RAG. Откройте схему архитектуры. Держу пари: там будут эмбеддинги, векторное хранилище и поиск по нему. Обязательно будет. Я долго думал, почему люди так любят это дело. Рефлексировал, общался с коллегами, прочитал гору книг по психологии. Мне кажется, теперь я все понял. Почему все (но не я) любят сравнивать эмбеддинги Это очень удобная ментальная модель. Вы не знаете, как сравнивать два текста в вашей задаче — я, кстати, чаще всего в своей тоже не знаю. Задача сравнения текстов вообще чертовски сложная: два человека иногда не могут договориться, про одно и то же говорят или нет. И тут приходит эмбеддер. Чёрный ящик, который обещает: дай мне оба текста — я скажу, похожи они или нет. Сложная задача сравнения двух многогранных текстов сводится к сравнению расстоянию между двумя векторами по 512 чисел. Перечитайте это предложение ещё раз. Вы точно уверены, что она сводится? Модель удобная. Она обещает, что теоретически сможет идеально сравнить два текста. Просто добавляй побольше данных, делай побольше эмбеддер, учи его подольше. Вот, кстати, еще 200 интересных статей, как этот эмбеддер можно обучать... Когда ментальная модель встречает реальность У сравнения эмбеддингов есть ряд ограничений, которые не лечатся ни большим датасетом, ни новой архитектурой. — Точные совпадения. Пользователь спросил «iPhone 16 Pro» — он не хочет «iPhone 16. Семантически оба айфоны, даже оба новые. Но это совершенно разные продукты. Реклама меня уверяла. Ведь так? — Отрицание. «Телефон, но не iPhone» — попробуйте заставить эмбеддинг адекватно обработать «не». Отрицание должно переворачивать все сравнения с ног на голову (как будет работать двойное отрицание, я пока не понял). — Числа и даты. Ищете квартиру в Москве дешевле 20 млн? Квартира за 19.5 млн сильно не изменит свой эмбеддинг, когда собственник поднимет стоимость до 20.5. — То, чего нет в обучающих данных эмбеддера. «Всеволод Викулин» плохо матчится эмбеддингом с текстом «лучший AI-практик в мире». Мы с вами всё понимаем, модель — пока нет. По крайней мере, пока не прочитает этот канал. Как делать поиск, если не векторно Векторный поиск никуда не девается — он занимает своё место, просто не соло. 1. Сначала проверьте, нужен ли поиск вообще. Если все ваши знания влезают в 5–10 тысяч токенов — просто положите их в промпт. Один раз объяснили, чем хорош Викулин и оно запомнило. 2. Если документов немного — оценивайте все документы другой LLM-кой. Берёте дешёвую маленькую модель, даёте ей запрос и документ, просите оценить релевантность. 3. Если документов много — используйте несколько методов поиска: — полнотекстовый (по словам и н-граммам) — не знает семантики, зато точно находит «iPhone 16 Pro» — структурированный (SELECT WHERE price < 20kk) — для чисел и фильтров — поиск по оглавлениям — LLM разбивает базу на темы, потом выбирает нужную тему. Люди так делали c книгами до изобретения Ctrl+F — поиск тулами — даёте LLM grep и наслаждаетесь — гибридный поиск — смесь нескольких вариантов — поиск по графу — разбирали пример — (еще есть много чего, в том числе и векторный поиск) 4. Если качества не хватает, делаете реранкер. Берёте простой поиск, получаете топ-N кандидатов, и дальше их переранжирует LLM из пункта 2. Кстати, пример архитектуры хорошего поиска мы уже разбирали в посте. Резюме Пока писал этот пост, понял кое-что понял. Я ненавижу не векторный поиск. Я ненавижу, когда люди скидывают ответственность за качество своего продукта на самый популярный в индустрии чёрный ящик. Нарисовали эмбеддер, дальше только данные подкидывать, а он разберется. Не разберется. Нужно самому принимать решение, которое будет лучше всего работать в конкретной задаче. Может, у меня синдром гиперконтроля?. Надо сходить провериться.

Как я провел майские Писал огромную статью по методике внедрению AI-агентов. И сайт еще поправил. Надеюсь, у вас они прошли не хуже. В статье разберем 2 темы: как выбирать процесс и как вести разработку проекта. Внутри: - Почему у 95 % не получается довести агентов до прода. - Как связаны риск, профит и автономность агента. - В какой процесс стоит вставлять агента. - Какие есть этапы разработки агентских систем. и много чего еще. Получилось правда много, надеюсь, еще и полезно. Как обычно, вопросы пишите в комментариях или в личные сообщения.

Вообще все равно, на чем вы делаете агентов Ещё студентом я с командой участвовал в Data Science Game — непризнанном чемпионате мира по анализу данных. Сейчас его уже не проводят: зачем анализ данных, когда есть ИИ-агенты. Естественно, тогда выиграли. И вот награждение. Стою весь в белом, спонсоры жмут руки, задают вопросы. Тогда, кстати, ещё не спрашивали, как ИИ захватит мир — таких проблем перед нами не стояло. Я ждал вопросов: как выбирали целевую переменную, как приоретизировали гипотезы, или хотя бы сколько деревьев в бустинге (модель AI 2010-х). И тут встаёт руководитель французской страховой компании и спрашивает: «слушайте, все-таки, какая библиотека круче — catboost или lightgbm?» Люди обожают обсуждать инструменты. С агентами всё то же самое. Только хуже. О чем на небе все разговоры На чем же нам писать агентов?! Сейчас примерно три лагеря: — Графически: n8n, Dify, Langflow— клик-клац мышкой — Декларативно: Claude Skills, AGENTS.md — вежливо попросил в markdown — Кодом: LangGraph, CrewAI — для тех, кто любит похардкорнее Нюанс. Если у вас есть реально дорогая задача (см. примеры тут), которую агент может закрыть — вы как-нибудь справитесь. На коде, на рисовалке, хоть на ассемблере. Если бы агентов можно было кодить только на Perl — я бы первый пошел открывать вакансию. Что реально важно Если процесс дорогой, важно 3 вещи: 1. Описание процесса Агент — это очень внимательный, исполнительный человек с улицы. Он не знает ничего про вашу компанию, ваш продукт, ваших клиентов и ваши процессы. И вот этому человеку нужно настолько детально объяснить задачу и в нужный момент подсунуть нужную инструкцию, чтобы он сделал работу правильно. Это и есть контекст-инжиниринг. Все ринулись изучать фреймворки для работы с контекстом. Но фреймворк не имеет никакой ценности, если вы сами не знаете правил. Сначала вы выписываете процесс настолько детально, что его поймёт стажёр в первый день. Только потом думаете, через какой инструмент это всё запихать в LLM: в LangChain или в n8n. 2. Инструменты Тому же человеку с улицы нужно чем-то работать. Ему нужны понятные API, ручки, кнопки — то, чем он может пользоваться, чтобы выполнять задачу. И тут все рванули в MCP. Всем побольше MCP-хабов. Но без нормальных ручек протокол ценности никакой не несёт. А с ручками беда: они кривые, дублируются, не имеют описаний, в них чёрт ногу сломит. Все думают: накидаем 250 API-шек в MCP — и агенту сразу полегчает. Дайте 250 инструментов человеку с улицы и посмотрите через сколько он уволится. 3. Стоимость инференса Есть класс фреймворков, которые я люблю (и такое бывает) — это инференс-движки. vLLM, SGLang, llama.cpp — под капотом у них горы C++, CUDA-кода и низкоуровневых оптимизаций. Это та работа, которую вы сами не сделаете никогда. Сравните с n8n, которые делает интерфейсную обвязку вокруг контекст-инжиниринга. Если процесс правда дорогой — вы эту тупую обвязку напишете руками, и она будет ровно под вас. А вот написать свой движок инференса с оптимизированным KV-кэшем и батчингом — нет, не напишете. Резюме Дайте мне описание процесса, нужные ручки и дешёвый инференс — и я обещаю, что сделаю вам агента. Но не скажу, в какой ui-ке я его рисовал. Это будет моя маленькая тайна.

Развернуть свою LLM или на API-шке заведется? В прошлом посте считали стоимость инференса своей LLM. Может, ну его нафиг, и будем просто OpenAI за токены платить? Вопрос не простой. Правильный ответ зависит от того, на какой стадии проект и от его ограничений. Стадий всего две. Ограничений — поболее. Теперь по порядку. Две стадии AI-проекта: MVP и масштабирование 1) MVP. Цель — получить сигнал, что продукт реально решает проблему и растит бизнес-метрику. Опросы пользователей, оффлайн-метрики, A/B-тесты — отсюда получаете сигнал. 2) Масштабирование. Сигнал получили, теперь раскатываем решение в прод. Здесь уже думаем про железо, стоимость, безопасность, SLA — всё то, на что было плевать вчера. Это две разные задачи с разными рисками. И модели под них нужны разные (подробнее про стадии проекта в статье). MVP: только API, только хардкор Главный риск на старте — закопать месяцы в проект, который вообще не надо было делать. Поэтому на стадии MVP запрещено думать про стоимость инференса, скорость работы и безопасность. Главная метрика — скорость проверки гипотезы. Каждая инвестиция в AI-инфраструктуру — бездарно потраченное время. Отсюда правило: берём самую толстую API-модель, которая есть на рынке. Если уж она задачу не вытянет, можно честно закрывать проект и идти делать следующий. Масштабирование: когда API может не тянуть Сигнал получили, продукт нужен, начинаем думать, стоит ли слезать с API. Причины для слезания: 1. Безопасность данных. 99% реальных причин ухода с API. Регуляторка, персональные данные, банковская тайна, корпоративные секреты и тд. 2. Медленно. Редкая история. Современные провайдеры используют много примочек и сильно разогнали инференс. У вас, скорее всего, сильно быстрее не получится. 3. Дорого. Платите за GPU вы постоянно, но нагрузка у вас пикообразная. Ночью пользователи спят. Днём работают. В ваш сервис реально ходят несколько часов в день, а карты постоянно в вашем P&L. В API вы платите строго за токены, что использовали. И не забудьте про команду, которая должна инференс поднять и поддерживать. Опенсорс становится дешевле если: (а) у вас реально большой трафик (б) вы умеете грамотно утилизировать железо в провалах — сдувать ночью, поднимать днём, шарить между задачами. Вывод: в 99% кейсов API дешевле, чем свой инференс. Если вам кажется иначе — посчитайте ещё раз. Как делать Масштабирование на опенсорсе 1) Пробуем самый большой опенсорс. Да, он хуже топовых API-моделей. Но разрыв меньше, чем принято думать. Если экономика сходится — вы восхитительны, можно больше ничего не делать. 2) Если экономика не сходится — дистиллируем. Учим маленькую модель на ответах большой. Это вот ровно тот кейс, где оправданно обучать свои модели. Маленькая модель запоминает паттерны большой, теряет широту (на задачах за пределами вашего домена она будет тупить), зато выигрывает порядок по железу. Но на широту вам обычно пофиг, лишь бы конкретно вашу задачу более менее решала. При правильной дистилляции реально сжать модель на порядок. Резюме: итоговый алгоритм 1. MVP → самая большая API-модель. Ищем сигнал, что продукт решает проблему. 2. Сигнал получили + с безопасностью ок + скорость норм + экономика сходится → остаёмся на API. 3. Данные отправлять нельзя → разворачиваем самый толстый опенсорс. 4. Опенсорс не лезет в экономику → дистилляция под ваш домен. 5. Всё остальное (дообучаем модель, чтобы она поумнела; поднимаем свой инференс, чтобы сэкономить на API; перебираем опенсорсы на MVP) — от лукавого.

Мой главный секрет успеха AI-проектов Не технологии. Не оркестрация, не квантизация и не дистилляция. Не chain-of-thought, не human-in-the-loop и не llm-as-a-judge. Не данные. Не нормализация, не аугментация и не токенезация. Не big data и не small data. Люди. Лучшие проекты свершались благодаря команде, которая была со мной. С нужными технологиями можно разобраться, нужные данные можно собрать, если рядом люди, на которых можно положиться. Которым важно достигать результата, которые готовы брать за него ответственность. Я сейчас ищу таких людей. Мы в Т-Банке собираем команду внедрения AI-агентов в поддержку клиентов, чтобы с их помощью полностью перестроить все текущие процессы. Внедрение агентов это не обучение LLM в игрушечной среде. Это хардкорный context engineering, оптимизация инференса, разработка метрик качества. Будет интенсивно, это я обещаю. Но вам понравится, это я обещаю тоже. Я ищу ML-инженеров (мидл/синьор). Если у вас есть: - 2+ опыта ML-разработки - любой опыт LLM-разработки - желание прокачаться в разработке и управлении в сложных инфраструктурных проектах Я ищу продуктовых аналитиков (мидл/синьор). Если у вас есть: - 2+ опыта работы продуктовым аналитиком - уверенные знания SQL и математической статистики - желание мощно разобраться в метриках качества LLM и агентских систем Присылайте свое резюме мне в личные сообщения @seva_batareika Если вдруг вы ждали понедельника, после которого пора изменить свою жизнь, то вот это именно этот понедельник.

Да вы шутите… https://www.forbes.ru/biznes/559193-ii-pomosnik-v-andeks-direkte-naucilsa-zapuskat-reklamnye-kampanii

Калькулятор LLM-инференса. Сколько стоит LLM в проде Одна из самых дорогих статей расхода в LLM-проектах — инференс. Умение правильно его оптимизировать не раз спасало экономику моих проектов. Сегодня разберём, от каких параметров зависит цена, и я поделюсь пример калькулятора, где можно получить оценку стоимости. Размер модели Размер определяется задачей. Для несложных задач с коротким входным контекстом (нормализация текста, перевод, выделение ключевой информации) — хватает моделей порядка нескольких миллиардов параметров. Быстрые, влезают на одну потребительскую карту, стоят копейки. Для задач с большим контекстом (например, сложный RAG) — нужны модели порядка десяти миллиардов параметров. Здесь уже важно качество рассуждений и умение работать с длинным контекстом. Для агентских систем, где у LLM огромный контекст и куча инструментов — работают только самые большие модели. Часто это MoE-архитектуры вроде Qwen3-235B: размер огромный, но при каждом вызове активируется только часть параметров. Из-за большего размера они могут не влезать ни то что в одну карту, но даже в сервер с 8-ми картами. Более подробно я расписывал это в отдельной PDF-ке. Забирайте. Квантизация Параметры модели можно хранить в числах разной точности. Перевести FP16 (16 бит на параметр) → FP8 (8 бит на параметр) — в два раза меньше памяти. Квантизация влияет не только на размер: сжатые веса быстрее читаются из памяти, а значит быстрее инференс. FP8 сейчас стандарт для прода — H100 поддерживает нативно, потери качества минимальные. Вечно квантизовать нельзя, после 4 бит качество уже значительно падает. KV-cache При генерации нового токена модель хранит информацию из всех предыдущих — это KV-cache. Он растёт линейно с длиной контекста и с каждым запросом в батче (точная формула в калькуляторе). KV-cache тоже можно квантизировать отдельно от весов. Веса в FP8, а KV-cache в FP16 — стандартная конфигурация. Batch size Сколько запросов GPU обрабатывает одновременно. Главный компромисс инференса. Больше батч → выше суммарная пропускная способность → меньше карт нужно → дешевле. Но каждый конкретный пользователь ждёт дольше, потому что GPU делит ресурсы между всеми в батче. Размер батча нужно подбирать под продуктовые требования скорости ответа. Размер входа Входные токены обрабатываются в фазе prefill. Это быстрая фаза — GPU считает параллельно. Но при длинном входе (RAG с документами, агент с историей) prefill тоже начинает стоить времени. На больших контекстах может занимать несколько секунд. Не бесплатно. Пока prefill не сделали, генерация не идет. Размер выхода Выходные токены генерируются в фазе decode — по одному за шаг. Это медленная фаза, decode почти всегда доминирует в латенси. На практике в десятки/сотни раз дольше. Пиковый RPS Сколько запросов в секунду система должна обслуживать в пике. Стандартная практика — закладывать запас 15-20%, чтобы система в пике не работала на пределе. Итого Все эти факторы я собрал в калькулятор, который даёт примерную оценку стоимости инференса. Внутри три вкладки с готовыми примерами на моделях Qwen3: нормализация текста (простая), RAG (средняя) и агент (сложная). Все входные параметры можно менять. Важно: калькулятор только примерная оценка для первого этапа разработки LLM-проекта. Как только появится первый прототип, производительность системы нужно честно бенчмаркать. Конечно, эти цифры — не приговор. Стоимость инференса можно серьёзно снижать: дистилляция, спекулятивный декодинг, prefix caching и тд. Но это уже тема наших следующих разговоров.

AI-агент, который запустит рекламу за вас. Кейс компании Spotify Предприниматель хочет запустить рекламную кампанию. Раньше — заполняешь 20 полей, интуитивно расставляешь бюджеты по форматам и молишься, что угадал. Если вы богатый предприниматель, у вас есть специальный сотрудник, тогда страдает уже он. Spotify решил это сломать. Они построили мультиагентную систему, которая превращает сообщение в чате в готовую компанию: на каких пользователей, где и какую рекламу запускать. Разбираем архитектуру и почему это тот самый тип AI-агента, который я хочу, чтобы вы научились создавать. Архитектура решения Медиапланирования состоит из множество подзадач: нужно одновременно разобраться с целью кампании, аудиторией, форматами и расписанием. Если делать это последовательно — медленно. Если в один большой промпт — ненадёжно. Это явный сигнал для применения мультиагентной системы. - GoalResolverAgent — выставляет цель кампании (охват, клики, установки) - AudienceResolverAgent — заполняет таргетинг: интересы, гео, демография - ScheduleAgent — выписывает даты компании Все эти 3 агента работают параллельно. Пока один разбирается с географией, другой уже считает бюджет. Итого — 3-5 секунд на весь pipeline. Когда все данные о компании заполнены, вот тут и начинается магия — запускается MediaPlannerAgent. Он уже формирует план компании. В чем сила? В инструментах Задача — не просто сформировать какой-то непонятный план, а чтобы рекламная компания принесла клиенту как можно больше пользы. Агент не генерирует план из головы. У него есть доступ к базе тысяч реальных кампаний, которые уже откручивались на Spotify. Он находит похожие на твою — по бюджету, длительности, аудитории — и смотрит, как они отработали. Сколько стоил один показ или клик, насколько объявления реально доходили до клиентов. На основе этого отбирает варианты, которые исторически давали лучший результат. Агент не гений, у него есть просто правильные инструменты. Он методично в них ходит и сравнивает результаты компаний с параметрами запроса. Никакого AGI. В чём профит? В клиентском опыте Spotify встроили экспертизу медиапланировщика прямо в продукт. И это самый сильный тип пользы от внедрения AI. Раньше медиаплан создавался за 15-30 минут: форма за формой, экран за экраном. Порог входа в рекламу на Spotify был высоким — нужно было разбираться в форматах, понимать, какой таргетинг работает. Теперь этот барьер исчез. Экспертиза стала частью интерфейса. Теперь рекламодатель пишет «хочу охватить молодёжь в Бразилии, бюджет €8000, август» — и получает готовый оптимизированный план за 5-10 секунд. Низкий порог входа, больше клиентов, больше рекламы, больше денег. Резюме Отличный кейс, на котором мы должны повторить 2 истины. Агент — это не волшебник. Это машина по перевариванию данных + движок принятия решений. Дай ему детальный алгоритм и нужные инструменты — сделает так хорошо, что вы не отличите от работы человека. Но результат для пользователя — магия. Экспертиза, которая раньше была за закрытой дверью, теперь доступна любому. Это меняет экономику бизнеса. Кстати, этот же сдвиг скоро будет ломать e-commerce. Поговорим об этом как-нибудь в другой раз.