Unit Economics AI

Суть

Юнит — единица того, что продаёт бизнес. Для AI-сервиса это обычно один осмысленный запрос: описанная таблица, разобранное обращение, сгенерированный документ. Юнит-экономика показывает, зарабатывает сервис на этом юните или теряет.

Прибыльность юнита = Ценность действия − Стоимость запроса

Формула выглядит тривиально, но обе её половины считают неправильно. Стоимость занижают, сводя её к цене токенов. Ценность вообще не считают — «агент же полезный».

Ценность действия: считать через альтернативу

Ценность измеряется деньгами, которые клиент не потратил или заработал. Три источника:

1. Экономия — автоматизация существующего процесса: ручной труд сокращается.
2. Ускорение — люди те же, но производят больше.
3. Новый процесс — то, чего раньше не делали вообще.

Приём для оценки: взять время специалиста, которое заменил агент, и умножить на стоимость часа. В разобранном примере агент описывает таблицу за 2,5 минуты вместо 4 часов работы аналитика — дальше остаётся подставить ставку.

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

Стоимость запроса: четыре слагаемых

Стоимость запроса = токены + инфраструктура + поддержка + амортизация разработки

• Токены — input и output с учётом асимметрии цен (см. Prefill Decode Asymmetry); промпт бывает длинным из-за RAG-контекста.
• Инфраструктура — хостинг моделей, векторная БД, Elasticsearch, обычная БД.
• Поддержка — мониторинг, дежурные инженеры, разбор инцидентов (см. Support Escalation Ladder).
• Амортизация разработки — единоразовые траты на бэкенд, фронтенд и R&D, размазанные по ожидаемому числу запросов за продуктовый цикл.

Пример расчёта амортизации: 6 млн руб. разработки при 2 млн запросов = 3 руб. на запрос. Цифра ощутимая, и именно её обычно забывают.

Считать надо циклами, обычно месячными: без ограничения по времени жизни продукта амортизацию не на что делить.

Когда агент меняет качество, а не заменяет процесс. Прямая экономия часов здесь не считается, и попытка её натянуть даёт цифру, в которую никто не верит. Считать надо через альтернативу для конкретного решения: не «аналитик стал лучше», а «какое решение было бы принято без агента и сколько стоила бы разница». Часть таких эффектов измерима напрямую (доля решений, отменённых на следующем шаге; доля возвратов и переделок), часть — только косвенно через время до решения. Если ни одна из этих величин не двигается, ценности, скорее всего, нет — как бы убедительно ни звучало «стало удобнее».

Частые ошибки подсчёта

• Считают только токены, забывая поддержку и разработку.
• Считают R&D завершённым — а он продолжается весь жизненный цикл и должен сидеть в стоимости.
• Не учитывают стоимость ошибок: переделку, откат, редеплой.
• Меряют «в среднем по сервису», а не по типам запросов — средний запрос не существует, а решения принимаются по конкретным сценариям.

Cost per Outcome вместо Cost per Request

Метрика на уровне вызова обманывает, когда результат достигается не с первой попытки. Сравнение из FinOps-разбора:

Экономия на модели удвоила стоимость решения задачи. Поэтому целевая метрика — стоимость исхода, а не запроса: она автоматически штрафует за ретраи, переспросы и брошенные диалоги.

Структура шаблона расчёта

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

Значения по умолчанию в шаблоне: 3 млн + 1 млн разработки на 2 млн запросов; 150 тыс. хостинга и 100 тыс. поддержки в месяц на 200 тыс. запросов; 3000 входных и 500 выходных токенов на запрос.

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

Асимметрия токенов зашита в расчёт явно: цена входа и выхода вводятся отдельно и в обе стороны — и в себестоимости, и в тарифе (см. Prefill Decode Asymmetry).

Пример

SLA-метрики агента Data Scout, на которых считалась его экономика:

• время обработки — до 2,5 минут на таблицу;
• точность генерируемых описаний — от 85%;
• экономический эффект как метрика верхнего уровня — экономия клиенту до 50 млн руб.

Верхняя метрика здесь не техническая: именно она отвечает на вопрос, продолжать ли платить за сервис.

Три метрики платформенного уровня

Расчёт выше отвечает на вопрос про один запрос. Для разговора с продуктом и финансами нужны ещё две проекции той же экономики:

Разрыв между первой и второй строкой — то место, где обычно прячется проблема: низкая цена за тысячу токенов ничего не значит, если половина ответов уходит на переделку. Третья строка нужна потому, что именно в ней затраты сопоставимы с выручкой на пользователя, а значит с ней можно идти к продукту.

Архитектурные рычаги, которыми на эти числа влияют, собраны отдельно (FinOps AI).

Связано с

• FinOps AI — пять архитектурных рычагов и цикл управления затратами
• Showback Chargeback — как эти числа доводятся до внутренних потребителей
• Agent CostControl — инструментальная часть: как собрать данные, без которых эта формула не считается
• Cascade Routing — главный рычаг снижения стоимости запроса
• Prefill Decode Asymmetry — почему output-токены доминируют в счёте
• Cost Anomaly Alerting — что делать, когда посчитанная экономика поехала
• AgentOps — SLA и метрики, на которых держится «ценность действия»