Реальная стоимость внедрения ИИ в продукт

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

Статья расходов 1: первоначальная разработка

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

Статья расходов 2: оплата за каждый запрос

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

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

Статья расходов 3: конвейер данных и поиска

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

Статья расходов 4: постоянный контроль качества

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

Статья расходов 5: подстраховка со стороны людей

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

Как правильно заложить это в бюджет

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

Честный итог

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

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