Юнит-экономика AI-продукта: что считать на один полезный результат
Учебная модель юнит-экономики AI-продукта: затраты на токены, повторы, проверку, инфраструктуру и поддержку; сценарии нагрузки и границы выводов.
У AI-продукта дорогим бывает не один запрос, а цепочка, которая приводит к полезному результату. Пользователь переформулирует задачу, модель отвечает повторно, сотрудник проверяет спорные случаи. Если считать только тариф первого вызова, цена продукта выглядит привлекательнее, чем его реальная работа. Начните с определения единицы результата.
Выберите единицу
Для одного сервиса единица измерения: проверенная карточка товара. Для другого: закрытый вопрос поддержки. Не называйте единицей любой ответ модели: пустой или неверный ответ не создаёт ценности. Укажите, сколько вызовов и ручных действий требуется в среднем, а затем посмотрите на длинный хвост сложных случаев.
Отделите оплаченные пользователем действия от бесплатных проб, отменённых попыток и внутренних проверок. Если повторные генерации входят в подписку, они увеличивают расходы даже без дополнительной выручки. Структура зависит от вашего продукта, поэтому универсальная «нормальная» себестоимость здесь бесполезна.
Сложите переменные расходы
В расчёт входят входные и выходные токены по действующему тарифу, дополнительные вызовы, обработка вложений, если она есть, проверка человеком и технический расход на запрос. Не переносите тариф одной модели на все задачи. Простая классификация и сложный длинный ответ потребляют ресурсы по-разному.
Проверьте счётчики на уровне отдельного сценария. Усреднение по всему сервису может скрыть пользователей, которые создают длинные запросы и многократно перезапускают генерацию. Пределы использования должны быть понятны до продажи тарифного плана, иначе интенсивное использование неожиданно меняет экономику.
Учтите постоянные затраты
Разработка, поддержка интеграции, тестирование модели, безопасность и работа с обращениями клиентов не исчезают при малой цене запроса. Для учебного расчёта их можно распределить на ожидаемый объём, но не выдавайте эту оценку за фактическую себестоимость до появления данных. Объём ниже прогноза резко меняет картину.
Не прячьте разовые расходы в графе «прочее». Укажите отдельно стоимость запуска и регулярную поддержку. Это помогает решить, стоит ли расширять продукт уже сейчас или лучше проверить спрос ручным процессом. Расчёт не заменяет бухгалтерскую и финансовую оценку компании.
Проведите учебный расчёт
Представим условный сервис, который готовит проверенную карточку. На одну карточку приходится два вызова модели и несколько минут редактора; иногда нужен третий вызов. Составьте таблицу для обычного и тяжёлого случая, подставив собственные тарифы и стоимость труда. Здесь намеренно нет готовой «выгодной» цифры: она зависит от конкретных входов.
Если подписка допускает сто карточек, считайте расходы и для пользователя, который делает пять, и для того, кто использует весь лимит. После этого проверьте, какие затраты возникнут при ошибочном ответе и ручной поддержке. Такой сценарный расчёт полезнее одного красивого среднего значения.
Свяжите цену с качеством
Самая дешёвая модель может чаще требовать переделки. Сравнивайте стоимость готового результата при одинаковой рубрике качества. При выборе модели учитывайте задержку и доступность операции: клиенту безразлична низкая себестоимость, если он не может завершить работу в нужный момент.
Для сравнения используйте проверочную подборку, не составленную из одного типа примеров. Повторите оценку при существенном изменении запросов или модели. Каталог /models показывает опубликованные условия операции, а актуальные цены проверяйте на /pricing. Финальная цена клиента должна учитывать вашу собственную структуру затрат.
Оставьте диапазон вместо одного числа
Покажите чувствительность результата к длине ответа, количеству повторов, объёму использования и доле ручной проверки. Выделите параметры, которые пока только предполагаются. Когда появятся реальные данные, замените допущения замерами. Не обещайте прибыль исходя из модельного сценария.
Если тяжёлый сценарий не укладывается в бюджет, пересмотрите ограничения тарифа, интерфейс или саму задачу. Сокращение качества ради красивой таблицы обернётся поддержкой и потерей доверия. Учебная юнит-экономика помогает выбрать следующий эксперимент, а не даёт финансовой рекомендации по цене или инвестициям.
Учтите неравномерное использование
Средний пользователь редко описывает всю нагрузку. Несколько активных клиентов могут отправлять длинные документы, запускать генерацию повторно и обращаться в поддержку чаще остальных. Постройте распределение расходов по типам использования, даже если в начале у вас только сценарные допущения. Так станет видно, какой лимит защищает сервис, а какой делает продукт бесполезным.
Проверьте поведение при превышении лимита: что видит человек, сохраняется ли его работа и может ли он заранее понять расход. Скрытая остановка в середине важной операции портит доверие. Но без границ продукт рискует неожиданными счетами. Правила должны быть частью понятного тарифного предложения, а не спрятанной реакцией на высокое потребление.
После появления реального трафика сопоставьте фактические затраты с расчётом по каждой функции. Если расхождение велико, ищите причину в длине входов, повторных вызовах или ручной проверке. Не переносите корректировку сразу на цену для клиента без анализа спроса и обязательств. Юнит-экономика показывает состояние механизма, а коммерческое решение требует отдельной работы.
Проверяйте отдельно бесплатные тесты и рабочие платные сценарии. Они могут отличаться длиной входа и числом повторов, поэтому расход на демонстрации редко описывает привычное использование продукта.
Отдельно смотрите на стоимость ошибок, которые клиент обнаруживает после получения результата. Повторный запрос может быть дешёвым, а исправление опубликованного документа или ответ поддержки обходятся дороже. В учебной модели достаточно перечислить такие случаи и отметить, какие расходы ещё не удалось измерить.
- Расход посчитан на готовый полезный результат.
- Тяжёлое использование проверено отдельно от среднего.
- Допущения и измеренные суммы подписаны раздельно.
| Сценарий | Что меняется | Что проверить |
|---|---|---|
| Обычный | Типовая длина и число вызовов | Расход на готовую единицу |
| Тяжёлый | Длинный вход и повторы | Лимиты и крайние затраты |
| Ошибка | Ручная проверка и поддержка | Стоимость исправления |