Стоит ли стартапу делать ИИ-функцию? Практический подход

«Нам нужно добавить ИИ» — сейчас одна из самых частых фраз на совещаниях по продуктовому роадмапу и одна из наименее продуманных. Здесь стоит притормозить, потому что неудачная ИИ-функция обходится дороже, чем полный отказ от ИИ: вы тратите реальное время разработчиков, добавляете реальную операционную сложность и нередко выпускаете то, что пользователи молча игнорируют.

Начинайте с проблемы, а не с технологии

Задавать стоит не вопрос «где бы нам применить ИИ», а вопрос «какая часть того, что сегодня делают наши пользователи, самая раздражающая, рутинная или плохо масштабируемая». Если вы можете чётко сформулировать эту проблему, вообще не упоминая ИИ, — вы на верном пути. Если честный ответ звучит как «конкретной проблемы нет, нам просто нужна ИИ-функция для презентации инвесторам», лучше признаться себе в этом до того, как написана первая строка кода.

Четыре вопроса, на которые стоит ответить до составления ТЗ

1. Связана ли задача по своей сути с языком, поиском закономерностей или массовыми решениями, требующими суждения?

ИИ-функции обычно окупаются в таких задачах, как суммаризация, написание черновиков, классификация, поиск или рекомендации, — то есть в вещах по природе нечётких, для которых трудно написать точные правила. Если же задача на деле сводится к ясному и стабильному набору бизнес-правил, вы быстрее получите лучший результат, просто прописав эти правила.

2. Есть ли у вас реальные данные?

Рекомендательной системе нужно реальное поведение пользователей, на котором она будет учиться. Ассистенту поддержки нужны реальная документация и реальные прошлые обращения, на которые он будет опираться в ответах. Если этого пока нет, честнее сначала собрать данные и вернуться к ИИ позже: модель, построенная на скудных или выдуманных данных, работает хуже, чем отсутствие функции вовсе, и подрывает доверие, когда ошибается.

3. Что будет, если она ошибётся?

Любая ИИ-функция время от времени ошибается — это верно даже для лучших систем, доступных сегодня. Настоящий вопрос проектирования — во что обходится такая ошибка. Неудачная рекомендация фильма — мелочь. Неверный ответ в процессе поддержки, на основании которого клиент что-то предпримет, или неверная цифра в финансовой сводке — реальная проблема. Функции с низкой ценой ошибки можно смело полностью автоматизировать. Функциям с высокой ценой нужен человек, который проверяет результат, или понятный способ, которым пользователь сам может заметить и исправить ошибку.

4. Сможете ли вы поддерживать её после запуска?

ИИ-функция — это не разовая разработка. Модели «дрейфуют» по мере того, как меняются реальные данные, расходы меняются с ростом использования, а проблема «ИИ-провайдера месяца» вполне реальна: инструмент, под который вы разрабатываете сегодня, через год может потребовать серьёзной переделки. Закладывайте в бюджет постоянное внимание к функции, а не только первоначальный спринт.

Полезная проверка на интуицию

Если убрать слово «ИИ» из описания функции, будет ли она по-прежнему звучать действительно полезно? «Автоматически распределять входящие обращения в поддержку по срочности и теме» звучит полезно и со словом «ИИ», и без него. «Добавить ИИ-чат-виджет» эту проверку не проходит: это технология в поисках проблемы, а не наоборот.

Когда это действительно оправдано

ИИ-функции оправдывают себя, когда берут то, что пользователь сейчас делает медленно и вручную, — сортировку, поиск, черновики, первичную обработку, — и делают это почти мгновенно, используя реальные данные, которые у вас уже есть. Это настоящее, обоснованное улучшение продукта, а не галочка для презентации.

Именно такой разговор о рамках задачи Burncode проводит с каждым клиентом, прежде чем браться за работу с ИИ: исходим из реальной проблемы и реально доступных данных и рекомендуем модель, только когда это действительно правильный инструмент, а не потому, что в роадмапе на этот квартал написано «добавить ИИ».