Как понять, нужен ли вашему продукту ИИ (часть 1)
Кажется, что в каждый продукт нужно встраивать ИИ — иначе за рынком не успеть. Из-за этого команды нередко начинают обсуждать модели и архитектуру раньше, чем отвечают на более важный вопрос: какую задачу вообще нужно решить?
Разберемся, как подойти к поиску решения системно и выбрать технологию, которая действительно выполняет задачу, а не просто добавляет в продукт модное слово «ИИ».
Не выбирайте решение, пока не ответите на вопрос: «Какую бизнес-метрику мы хотим изменить?»
Практика крупных компаний показывает: далеко не каждый ИИ-проект приносит измеримый результат. Поэтому прежде чем обсуждать решения и конкретные модели, стоит понять, есть ли у проекта понятный экономический эффект:
➡️ увеличить конверсию;
➡️ поднять продажи;
➡️ сократить время обработки документов;
➡️ снизить трудозатраты операторов.
Пока нет ответа на этот вопрос, обсуждать GPT, Qwen, RAG или ИИ-агентов просто рано.
Не всякая задача требует LLM
Сегодня слово «ИИ» почти автоматически ассоциируется с генеративными моделями. Но это лишь одна из технологий, которая не всегда релевантна задаче. Разберем, в каких случаях используются разные решения.
ML = машинное обучение
Если задача сводится к прогнозу, классификации или рекомендациям:
➡️ спрогнозировать спрос, успешность продажи, нагрузку контакт-центра;
➡️ оценить вероятность покупки или отмены доставки;
➡️ определить риск оттока;
➡️ сегментировать пользователей;
➡️ расставить клиентов контакт-центра по приоритету.
Это типичные задачи, где классический ML дешевле, стабильнее и понятнее в эксплуатации.
LLM = большие языковые модели
Если необходимо работать с большим количеством текста:
➡️ анализировать документы;
➡️ искать информацию;
➡️ готовить саммари;
➡️ менять тональность коммуникации;
➡️ генерировать ответы или код.
При этом важно помнить, что LLM — это не база знаний. Она умеет очень убедительно продолжать текст. Но если нужной информации нет в обучающих данных или она устарела, модель начинает достраивать ответ самостоятельно. Отсюда и появляются галлюцинации.
RAG = поисковая дополненная генерация
LLM, которая для ответа может обращаться к заданным источникам данных. Полезна, когда нужна точность с опорой на собственную базу знаний:
➡️ответ по внутренним регламентам и процессам;
➡️помощь на встречах по вопросам о продуктах;
➡️поддержка.
Дообучать LLM на общедоступной информации излишне дорого. Кроме того, весь открытый интернет уже давно оказался в обучающих выборках крупнейших моделей — это означает дефицит качественных данных.
Поэтому компании чаще используют RAG — модели дают доступ к корпоративным источникам: базе знаний, Confluence, Jira, CRM, регламентам и другим документам. В результате она отвечает на основе актуальной информации, может ссылаться на источник и значительно реже ошибается.
ИИ-агент
Ключевое отличие: чат просто отвечает, а агент планирует и выполняет действия через подключенные сервисы.
Пользователь собирается в отпуск: один агент может подобрать тур, второй — найти и купить билеты, третий — добавить поездку в календарь и отправить подтверждения на почту.
Команда небольших специализированных агентов, оркестрируемых верхнеуровневым «координатором», во многих сценариях оказывается эффективнее, чем попытка собрать одного универсального помощника. А еще они быстро развиваются, и управление ими становится проще.
В следующей части разберем частые ошибки при поиске ИИ-технологии. И фреймворк, который поможет сделать правильный выбор.
По мотивам мастер-класса «Нужен ли вашему продукту искусственный интеллект?» Михаила Войтко на ProductSense’25
@productsense