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

90% компаний внедрили AI. Заработали 6% Это свежие данные McKinsey. И за год доля заработавших не сдвинулась ни на процент. Компании штампуют пилоты: суммаризация тут, чат-бот там. Каждый по отдельности неплох, но вместе они не перестраивают систему, и на уровне компании эффекта не видно. Как делать по-другому, я собрал в новой статье. Там вы найдёте: — Как перестраивать бизнес-процессы, а не посыпать их горсткой AI-пыли — Как управлять разработкой по гейтам и не проиграть все деньги в этом казино — Почему трансформацию нужно делать внутри организации — Когда, а главное, зачем строить платформу Статья длинная, но с картинками! Как всегда, жду вопросы и мысли в комментариях или в личных сообщениях.

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: в долгосрочной перспективе всегда выигрывают методы, которые масштабируются вычислениями. Иногда эффект автоматизации настолько мал, что правильный ответ — вообще ничего не делать. Честно сказать, что сейчас эту задачу выгоднее не автоматизировать. Подождать, пока опенсорс созреет, и тогда сорвать это сладенькое яблочко. Вы же помните, что мы решали бизнес-кейс?