Привет! Меня зовут Миша Хаджинов — я продакт в DS-департаменте Авито и уже более семи лет занимаюсь разработкой продуктов на основе технологий машинного обучения и LLM. За это время успел пройтись по всем возможным граблям, поэтому решил поделиться опытом, как их можно было бы избежать. Расскажу о рабочем пайплайне, который поможет добиться успеха в разработке с первого раза. Статья будет полезна продактам, которые сталкиваются с ИИ впервые, а также разработчикам без профильной экспертизы.
Содержание:
Что может пойти не так во время разработки первого ИИ-продукта
Создание ИИ-фичи отличается от работы с обычным продуктом, но без опыта сложно понять это сразу и начать действовать правильно. Чаще команды, которые впервые хотят разработать продукт на основе LLM, воспринимают эти технологии как «волшебную таблетку», которая заработает сама из коробки и решит все проблемы. Из-за непонимания особенностей технологии ошибки возникают уже на старте, отчего проект рассыпается.
Обычно продакты ошибаются в своих оценках и получают один из трёх сценариев:
Не понимают, что в разработку ИИ-продукта надо вложить много сил, из-за чего планируют избыточно большой проект, который не могут собрать.
Недооценивают стоимость разработки и получают продукт за баснословные деньги либо не доходят до релиза.
Из-за нехватки ресурсов получают недостаточно качественный продукт, который дотягивают до релиза, где он и рушится.
Реальный рамочный пайплайн разработки ИИ-продукта
Шаг 1. Упаковываем ML-гипотезу
Для разработки обычного продукта часто достаточно линейной гипотезы: если сделать А, получится Б. Как правило, всё более-менее понятно. В ML, наоборот, бесконечное количество рисков и нюансов, которые влияют на результат.
В итоге линейная гипотеза превращается в более сложную: если сделать А (а ещё 1, 2, 3, 4, 5 и ∞ N), возможно, получится Б.
Чтобы учесть максимум деталей, которые влияют на конечный продукт, стоит сформулировать гипотезу максимально точно. Следует указать, что вы будете подавать на вход в модель, что нужно получить на выходе и какие для этого нужны технологии.
Отдельно важно сформировать образ того, как должен выглядеть результат работы LLM. Чем детальнее мы сможем собрать и сформулировать требования, тем более точно сможем составить промпт-инструкцию для модели и тем лучше получим результат на выходе.
Пример
Задача: суммаризировать отзывы. Если попросить LLM просто проанализировать все тексты и выписать главное — получится каша, где плюсы, минусы и особенности продукта будут перемешаны в тексте. С таким результатом работать неудобно.
В точной формулировке мы попросим проанализировать отзывы, при этом вычленить достоинства, недостатки, выкинуть неинформативные детали, объединить одинаковые свойства и выделить топ-3 из плюсов и минусов. Получится осмысленный и полезный результат.
Шаг 2. Разрабатываем подробный бизнес-сценарий
Итак, мы осознали, что у нас есть гипотеза, для решения которой лучше всего подходит ML-решение.
Стоит сразу разобраться, как пользователь будет взаимодействовать с ИИ-продуктом, чтобы получать релевантные ответы. Большая ошибка описывать бизнес-сценарий как «окно для пользователя, куда он пишет запрос и получает ответ». Так не получится учесть особенности бизнеса, а это значит, что нейросеть будет выдавать ошибки.
На этом этапе полезно учесть максимум аспектов бизнеса: что он предлагает своим клиентам, как реализует продукт или услугу и другие детали.
Пример
В одном проекте я с командой создавал ИИ-продукт, который генерировал описание для предприятий малого бизнеса. Мы обучали модель с нуля и в итоге получили описание барбершопа — «российская онлайн-платформа, специализирующаяся на продаже модной мужской обуви и аксессуаров».
Шаг 3. Правильно оцениваем потенциал
При создании нового продукта важно оценить его пользу для бизнеса. Для этого нужна метрика, которая покажет рентабельность внедрения LLM. Если продукт разрабатывает и затем использует одна и та же команда — всё в порядке, потому что она может использовать свои стандартные метрики для прогноза потенциала.
Проблемы возникают, когда фичу создают две команды, которые оценивают результаты по-разному. Одна работает с отдельным продуктом, а другая — с целым направлением, то есть разработчики создают продукт на основе технологий машинного обучения по заданию бизнеса. В такой ситуации команды могут оценивать результаты с помощью разных метрик, что мешает синхронизироваться.
Пример
Команда разработки следит, чтобы модель выдавала фактически корректные данные в 96% случаев. Продуктовая команда смотрит на конверсию в покупку и не понимает, почему при росте точности продажи не растут, а падают. Проблема в том, что модель стала точнее предсказывать мелкие детали, а не реальные потребности пользователей.
Чтобы такого не произошло, командам нужно в самом начале договориться и использовать такие метрики, которые понимают оба участника проекта.
Отличие от ROI-оценки для не ML-продукта
ROI-оценка — это отношение аплифта к потраченным ресурсам.
При оценке потенциала классического продукта продакт может опираться на похожие решения у конкурентов. Уже известно, насколько продукт востребован на рынке, и есть некоторые ожидания окупаемости. В случае с ML-фичами есть большая вероятность создать новый пользовательский опыт или полностью изменить привычные сценарии. Обычно это приводит к тому, что потенциальную ценность продукта мы закладываем в план с крайне низкой уверенностью.
Если разрабатывать продукт без понимания его востребованности на рынке, можно потратить нерационально много сил и денег на разработку. Чтобы такого не произошло, рекомендую весь процесс делить на этапы и на каждом из них уточнять оценку потенциала.
Учитывая, что каждый последующий шаг разработки кратно дороже предыдущего, вы сможете более гибко принимать решения о судьбе продукта. Если укладываетесь в бюджет — всё в порядке, а если нет, то чем раньше вы это заметите и свернёте проект, тем больше сэкономите.
Шаг 4. Выбираем модель
Сейчас на рынке существует множество ИИ-решений, поэтому у компаний есть выбор как минимум из трёх вариантов:
-
Взять решение вендора, настраиваем API, пишем промпты и начинаем пользоваться продуктом. Это самый дешёвый вариант, даже для продуктов с большой аудиторией.
Нюанс: вендоры будут использовать информацию, которая попала в ИИ для дальнейшего обучения моделей. Если компания с этим не согласна, значит, вариант не подходит.
-
Выбрать open source решение. Хороший вариант для крупной компании, у которой есть ресурсы и ML-разработчики, чтобы дообучить модель под свою доменную задачу.
Доменная задача — это конкретная прикладная проблема или цель в определённой области: например, медицина, финансы, строительство, которую нужно решить с помощью методов искусственного интеллекта.
Это самый удобный вариант, хотя и не дешёвый с точки зрения необходимых человеческих ресурсов, потому что компания будет управлять и развивать собственную технологию.
Разработать и обучить собственную модель. Это чрезвычайно дорогой вариант даже на среднем уровне, который значительно хуже рыночного.
Чтобы выбрать оптимальное решение, потребуется собрать примеры того, что надо будет загружать в LLM и протестировать первые два варианта.
Для этого понадобится провести сравнительный анализ на собранном датасете: пропустить запросы через API моделей вендоров и развёрнутой локально открытой модели. Такой подход позволит оценить не только качество и точность ответов каждого варианта, но и их скорость, стоимость эксплуатации и соответствие требованиям безопасности.
Шаг 5. Оцениваем качество
Вы сделали продукт и рассчитали нагрузку. Осталось разобраться, насколько хорошо выбранная технология решает доменную задачу. Чтобы это понять, надо найти подходящий показатель качества работы.
Лучшая метрика — ваша собственная, которая будет отражать доменную задачу. Популярные LLM-бенчмарки, скорее всего, будут нерелевантны, потому что сравнивают модели по всем направлениям использования, а задача вашей LLM — узкая.
Метрика может выглядеть по-разному. Например, в виде гайдлайна, который покажет, как оценить качество работы модели. Допустим, наша LLM суммаризирует книги по ключевым мыслям. В гайдлайне пропишем полноту выдачи — все ли мысли перечислила модель, и достоверность — соответствуют ли они тому, что написано в источнике. Эти параметры послужат основой для объективной оценки качества суммаризации, а мы сможем точно определять сильные и слабые стороны модели.
Замерять качество решения задачи можно с помощью другой более мощной модели. Она выдаст скор на основе гайдлайна или методики, которую вы выбираете для оценки — такой подход поможет управлять версионностью продукта.
Шаг 6. Думаем над цензурированием и безопасностью
Модель будет выдавать то, что от неё потребуют пользователи. Поэтому в первую очередь следует позаботиться о том, что мы как компания будем делать, если пользователи начнут генерировать и публиковать «нежелательный контент». Чтобы снять или разделить ответственность, стоит найти юриста, который понимает, что такое LLM, и определить, в какие нормативные документы надо внести дополнения об ответственности.
Кроме ответственности, существует проблема цензурирования.
Есть несколько методов, как можно ограничить выдачу по нежелательным темам:
не обращать внимания и ничего не делать. Есть вероятность, что в скором времени в интернете появятся сообщения наподобие таких: «ML от X генерирует этот ужас». Но если репутация не имеет значения, а в юридических документах прописана ответственность пользователей, то можно ничего и не цензурировать;
собрать словарь нежелательных слов и тем, а потом настроить регулярные выражения на выдачу. Если пользователь спросит у модели что-то подцензурное, LLM выдаст вместо ответа заглушку. Это не слишком изящный, но действенный способ ввести цензуру в работу нейросети;
добавить дополнительный запрос в логику промптирования. Это нужно, чтобы LLM самостоятельно проверяла корректность ответа в соответствии с заложенным в неё правилам цензуры. Наподобие такого: «проверь на соответствие таким-то законам» или «проверь, чтобы не было мата, политики или чего-то ещё». Этот более элегантный метод, который особенно хорошо работает при использовании решения от вендора, потому что их LLM уже подготовлены под подобный вид цензуры;
дообучить отдельный слой нейросети и встроить его в логику — самый эффективный метод, который можно применить только к open source решениям. Минус способа — стоимость, которая составляет около половины от того, что потребовалось на первичное дообучение open source решения.
Шаг 7. Рассчитываем нагрузку
Я рекомендую продактам заранее оценивать, сколько пользователей придут в новый сервис во время релиза. Это важно, потому что резкий наплыв желающих может перегрузить интерфейс до неработоспособности. Получается ситуация, когда потенциальные клиенты приходят, видят нерабочий сервис, уходят и уже не возвращаются.
Поэтому перед релизом стоит задать себе несколько вопросов:
Какой будет пик пользователей на первичном запуске?
Мы учли промоэффект запуска?
Получится ли выровнять этот пик, если раскатывать продукт посегментно?
Правило хорошего тона для перестраховки — реализовывать механику, которая помогает удерживать пользователей на странице в случае, если сервис не отвечает. Это очередь ожидания. Можно отправить запрос пользователя во временную очередь и показать коммуникацию: «Пожалуйста, подождите, сейчас будет результат».
Шаг 8. Запускаем модель
Вы успешно выпустили свой продукт, но на этом работа не заканчивается, потому что запуск ≠ результат по двум причинам:
Ещё нужно будет убедиться, что решение имеет положительный эффект, и оценить его. В результате сможете понять, насколько успешно прошёл запуск и приносит ли модель бизнесу пользу.
Модели деградируют из-за того, что меняется реальность, например, поведение пользователей, а ещё ИИ начинает обучаться на данных, которые сам сгенерировал. Поэтому проект нужно постоянно поддерживать и развивать. Также важно уделять внимание отслеживанию изменений пользовательских сценариев — пользователи могут как принять продукт, так и резко отвергнуть.
Если после запуска вы хотите всё снести и сделать заново — это нормально.
Коротко о главном
Многие продакты совершают ошибки, когда разрабатывают ИИ-продукт в первый раз.
Чтобы совершать меньше промахов, я рекомендую придерживаться такого пайплайна:
подробно расписать ML-гипотезу, чтобы представлять себе конкретный результат разработки;
разработать подробный бизнес-сценарий, чтобы не упустить детали и особенности бизнеса вашей компании;
правильно оценить потенциал, чтобы не разрабатывать убыточный продукт;
грамотно выбирать технологию, чтобы не переплатить и не потратить слишком много сил на разработку;
подумать над цензурированием и безопасностью, чтобы ответственность за выдачу нёс тот, кто её запросил, а не разработчик;
рассчитать нагрузку, чтобы не уронить систему на старте и не растерять из-за этого клиентов;
оценить, насколько качественно продукт решает доменную задачу;
запустить модель и, главное, поддерживать и развивать её, а не бросать после релиза.
В комментариях расскажите, а вы сталкивались с разработкой ИИ-фичей?
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.