Дискуссии на Conversations – это пространство обмена мнениями, свежими взглядами и ценнейшими инсайтами. За ними всегда интересно наблюдать, и мы только рады поделиться материалами! В этот раз на сцене трека «Продукты и технологии» встретились эксперты из Just AI, X5 Tech, MWS AI, Яндекс R&D и Северстали, чтобы поговорить об эффективности AI-ассистентов, актуальных трендах и подходах к внедрению решений, а также о работе с ожиданиями бизнеса.
Участники дискуссии:
-
Максим Павлов, начальник управления продуктивизации ИИ, X5 Tech
-
Максим Волошин, CPO, MWS AI
-
Андрей Бут, руководитель команды алайнмента Alice AI LLM, Яндекс R&D
-
Виктория Ефимова, владелец продукта корпоративной платформы генеративного ИИ, Северсталь
И модератор – Антон Сипачев, CTO GenAI, Just AI
Как отличить настоящую продуктивность AI-ассистентов от иллюзии ускорения и на какие метрики стоит ориентироваться? На какие тренды AI-решений обратить внимание? Как правильно выстраивать процесс внедрения моделей, чтобы избежать разрыва между ожиданиями бизнеса и реальной готовностью продукта? Как строить процесс создания решений, которые будут production-ready?
Делимся главными выводами!
Как отличить настоящую продуктивность AI-ассистентов от иллюзии ускорения? Какие метрики, помимо прямого времени выполнения задачи, показывают, что Copilot не создает техдолг и не снижает качество решений?
Максим Павлов
X5 Tech
У вас есть метрика качества, которую вы мониторите. Если она не достигает нужного уровня – значит у вас недостаточно качественное решение. AI лишь помогает достичь этого быстрее или создает иллюзию этого достижения. Поэтому возникает необходимость в дополнительных инструментах, чтобы убедиться, что это не иллюзия, а реальные цифры.
То есть, помимо Copilot, нужен еще один уровень, где вы проверяете и фиксируете метрику качества во время предзапуска, а потом мониторите ее в реальном времени, реагируя на то, что происходит.
Максим Волошин
MWS AI
Если мы делаем пользовательский продукт с элементами AI, никто не отменял GCR и корзинки с вопросами, которые надо прогонять. Когда мы переходим на следующий уровень и говорим про ROI, надо учитывать косты, даже если качество выросло.
Если мы в рамках инференса отрабатываем большие запросы, то юнит-экономика может начать ползти. Вот этот параметр очень нужно отслеживать, потому что не всегда эти +3-4% оправданы тем количеством ресурсов, которые на это тратятся.
И это без учета того, что команде, создавшей новый инструмент, нужно время, чтобы вникнуть в работу. Также нужны дополнительные специалисты, которые помогут с интеграциями. Очень многое сейчас стараются не считать, чтобы хороший финансовый эффект показать.
Виктория Ефимова
Северсталь
Вся движуха вокруг качества genAI возникла из-за того, что с ним результат достигается быстрее, а недочеты обнаруживаются раньше. И эти недочеты как раз скидывают на AI. Однако некачественные продукты выкатывали и раньше, просто позже замечали косяки. А по факту до AI люди все то же самое делали, только дольше. Поэтому проверка качества должна теми же самыми способами осуществляться.
Андрей Бут
Яндекс R&D
С появлением AI у нас немного стирается грань. Copilot очень легко подтягивает джунов и мидлов до уровня сеньора, а вот на сеньорском уровне этот выигрыш зачастую не так заметен. И ошибки, например, уровня системного дизайна плохо ловятся.
Поэтому, да, разработка ускоряется, но при этом надо менять метрики и делать более качественные приемки.
Максим Павлов
X5 Tech
У людей есть иллюзия, что AI работает «из коробки». Топ-менеджмент пробует кейсы, они срабатывают. Но когда дело доходит до массового применения, неизбежно проявляются ошибки, которых не было ранее.
А по поводу сеньорства тоже есть нюанс. В классическом процессе разработки AI-кодинг вряд ли ускорит сеньора.
Представьте: сеньор получает 100 бананов и не юзает genAI, а два джуна получают по 30 бананов, юзают genAI за 10 бананов и работают х2 больше, чем сеньор. Джуны тогда очень быстро заменят сеньоров, там будут дополнительные проблемы, и всем в итоге будет грустно. Поэтому не нужно зацикливаться на прежнем процессе разработки, его нужно пересматривать и менять.
Максим Волошин
MWS AI
Я еще подметил, что в компаниях начала формироваться новая оргструктура. Условно, у одного сеньора, помимо мидлов, теперь половина команды – не живые джуны, а инструменты, которым дают задачи.
⠀
В AI-решениях есть свои тренды. Раньше это были универсальные агенты, которые заменяют HR-а, юриста и прочих. А сейчас тенденция будто бы смещается в другую сторону. Что думаете на этот счет?
Максим Волошин
MWS AI
Стартапы – это те, кто быстро двигается, что-то проверяет, умирает, пробует заново. И сейчас они больше не гонятся за созданием универсального «AI-сотрудника», например, AI-юриста с полным скиллсетом. Они выбирают одну его задачу и делают ее end-to-end.
Так и ROI посчитать проще, чем от абстрактного помощника, который работает через раз.
Виктория Ефимова
Северсталь
С одной стороны, есть стартапы, которые прокачивают специализацию. С другой стороны находятся те, кто создает платформенные решения.
Финтех и большой продакшн занимаются созданием платформ, на базе которых можно генерить большие бизнес-приложения. Модели туда же двигаются: тот же OpenAI доказывает, что специализация начинает встраиваться в большие сущности.
Максим Павлов
X5 Tech
И при этом история стартапов, которые делают маленькие фичи, обычно плохо заканчивается. В лучшем случае их покупает большой игрок и внедряет это в себя. В другом случае большой игрок просто делает то же, что и они. Это нормальный цикл.
⠀
Как выстроить процесс внедрения AI-моделей, чтобы избежать классического сценария, где бизнес ожидает «готового AI из коробки», а на практике сталкивается с длительным процессом доведения качества и первым негативным опытом?
Виктория Ефимова
Северсталь
Разрыв между ожиданиями и реальностью в любом технологическом проекте – это норма. Наша задача сделать так, чтобы он не становился большим.
Как мы вовлекаем бизнес в генеративку? У нас есть специальная команда. Они проводят роуд-шоу по компании, показывая возможности и кейсы. Бизнес загорается идеей и возвращается с запросом: «Хочу так же!» Но тут возникает вопрос, какой именно процесс можно с помощью этих решений автоматизировать.
Поэтому сначала нужно работать с ожиданиями и объяснять, что инструмент должен встраиваться в существующие процессы или в новую идею, а не быть абстрактным решением, которое заработает само по себе.
Также нужно договориться про ответственность. Как только достигается договоренность, что бизнес-логика и конечный эффект – зона ответственности бизнеса, а качественный продукт – задача IT, сразу возникает более высокий уровень ответственности с обеих сторон.
Максим Волошин
MWS AI
Отлично работает, когда у объединенной команды внедрения есть общие метрики, за которые отвечают обе стороны, и предусмотрена премия за успех.
Да, техническая команда не может отвечать за итоговые бизнес-показатели вроде выручки, но может разделять ответственность за промежуточные метрики, такие как GCR. Если такие общие метрики подкреплены премией, мотивация работает совершенно иначе.
Виктория Ефимова
Северсталь
От генеративок уровень ожиданий настолько высок, что, несмотря на все объяснения, бизнес ждет результат здесь и сейчас.
Если идти классическим путем, интерес бизнеса угаснет за неделю. Поэтому иногда приходится объяснять, что лучше выпустить решение чуть сырее, но быстро, иначе есть риск потерять заказчика. К слову, часто модные функции нужны бизнесу здесь и сейчас, чтобы понять, что они им не нужны.
А разрыв ожиданий и реальности часто проявляется уже после внедрения: что-то пошло не так и сделали откат назад. Поэтому важно продолжать поддерживать проект после сдачи.
Андрей Бут
Яндекс R&D
И вообще важно уметь объяснять бизнесу, что не каждая новая фича действительно нужна. Большая задача для команд, которые находятся между бизнесом и технической частью, – донести, что очередная фича не обязательно даст вау-эффект. Но и нельзя отбраковывать все подряд.
Максим Волошин
MWS AI
Нужно показывать, что возможно, а что нет, чтобы предотвратить нерелевантные запросы еще на подходе. Поэтому образование – неотъемлемая часть любой платформы или продукта.
Например, если сотрудник бизнес-блока не проходит обучение, он не может вынести свою инициативу на обсуждение. Такой подход может позволить избежать множества проблем.
Максим Павлов
X5 Tech
Возвращаясь к ответственности, отмечу, если сильно разделять заказчика и техническую команду, результат часто хуже. А если сказать технической команде, что она теперь тоже отвечает за результат, то команда начнет менять свое мировоззрение. Они почувствуют ответственность и уже не согласятся делать бессмысленную работу.
Максим Волошин
MWS AI
Идеальный вариант, когда у бизнес-блока, который хочет что-то внедрить, есть своя собственная команда, способная реализовать это самостоятельно.
Но так бывает не сразу. Всегда есть определенная эволюция: сначала кто-то должен показать, как это делать, потом это делается вместе, и только после команда может работать полностью самостоятельно.
Максим Павлов
X5 Tech
Мы через это прошли и поняли, что это работает не так хорошо, как хотелось бы. Появляется автономная команда, которая вроде бы хорошо делает свое, но может быть настолько автономной, что уйдет в другой технологический стэк. В итоге получается набор команд, которые работают чуть-чуть по-разному.
⠀
Как строить процесс создания решений, которые будут production-ready? Как должен выглядеть идеальный процесс, который приведет к успеху?
Андрей Бут
Яндекс R&D
Самое важное – это набор метрик, за которыми мы следим. Моя самая большая боль – набор старых метрик, которые не должны упасть. Когда у тебя есть перпендикулярно направленные старые и новые метрики, приходится их передизайнивать, перестраивая весь процесс: от обучения модели до ее внедрения в продукт.
Еще здесь важно быть гибким. Два года назад никто не думал, что ответы должны быть человечными, мягкими, красивыми, а сейчас это становится важно и мы это контролируем.
В итоге получаются сотни, а то и тысячи разных метрик. И правильно их приоритизировать, сбалансировать и довести в нужной пропорции до финального решения – это самое важное для стабильного продукта. А вот когда делаешь пилот, все иначе: придерживаешься стартап-формата, когда есть узкая задача и цель в 2–3 метрики.
Максим Павлов
X5 Tech
Когда встает вопрос, как выкатываться в прод, возникают два пути.
Первый: каждая команда катит свой проект самостоятельно. В целом это кажется быстрее и эффективнее, но есть и минусы: поскольку каждая команда идет со своим стэком и экспертизой, она может стать обособленной. На масштабе это вызывает проблемы.
Второй способ – это централизация, когда есть общий стандарт. Это могут быть не технологии, а условия, при которых решение считается выкаченным. Мы должны понимать, какими должны быть нагрузка, метрики, а также учитывать, что может произойти, если метрика ухудшится. Если видим, что что-то просело, мы откатываемся на прошлые данные и дообучаем.
Также нужны guardrails (для LLM), потому что все равно есть риски, что что-то где-то утечет или плохо ответит и т.д. Для компьютерного зрения есть свои какие-то специальные обвязки. Масштабируемость закладывается именно на этом этапе. Вы должны понимать, каким способом вы масштабируете и указать условия. Либо вообще забиваете и надеетесь, что это произойдет. И все способы иногда работают.
Максим Волошин
MWS AI
При проектировании платформы мы хотели сделать так, чтобы песочница, с которой работают команды, была частью общего парка, т.е. если они что-то сделали, то песок один, деревяшки одни и те же.
И если нам нужно было перетащить что-то в продакшн, мы могли сразу это сделать по тем рельсам, которые уже подложены под эту песочницу. А не так, чтобы песочница где-то лежала сама по себе, мы успешно сделали пилот, а потом еще полгода его переносили его на прод.
Оставайтесь в курсе и следите за новостями о следующей Conversations с не менее интересными дискуссиями на сайте.
Автор: just_ai
