Стоимость за успешную AI‑задачу: лучшая продуктовая метрика

Почему подсчёт токенов вводит команды в заблуждение

Графики по токенам легко полюбить. Они дают команде аккуратную линию на дашборде, простую цифру расходов и ощущение, что траты под контролем.

Это чувство комфорта может скрывать плохое продуктовое решение. AI‑функция может использовать меньше токенов и при этом тратить больше времени, вызывать больше повторных запросов и оставлять больше пользователей в тупике.

Низкое потребление токенов часто означает, что модель сказала меньше, а не что она решила проблему. Бот поддержки может ответить в 60 токенов расплывчатой фразой вроде «пожалуйста, обратитесь в поддержку». Это выглядит дешево на графике, но клиент всё равно открывает тикет, агент всё равно читает переписку, и команда всё равно платит за полное взаимодействие.

Более длинный ответ может стоить дороже за запрос и при этом быть лучшим результатом. Если модель использует 300 токенов, чтобы решить проблему, заполнить нужные поля и сэкономить агенту две минуты редактирования, такой запрос дешевле с точки зрения того, что действительно важно пользователям.

Команды склонны тяготеть к графикам токенов, потому что они доступны с первого дня. Продуктовую ценность считать сложнее. Нужно смотреть, завершил ли пользователь задачу, пришлось ли человеку исправлять вывод и удержался ли результат после проверки.

Несколько ошибок повторяются снова и снова. Команды вознаграждают более короткие ответы, даже если они уклоняются от реального вопроса. Они считают только стоимость модели за вызов, игнорируя повторы, последующие подсказки и ручную доработку. Они также трактуют каждый вызов как равный, хотя некоторые вызовы завершают задачу, а некоторые создают дополнительную работу.

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

Именно поэтому стоимость за успешную AI‑задачу — лучший ракурс, чем голый подсчёт токенов. Токены показывают, что модель съела. Они не говорят, получил ли пользователь что‑то, чем он реально может пользоваться.

Если дешёвый запрос приводит к другому запросу, а затем ещё к одному, он никогда не был дешёвым.

Что считается успешной задачей

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

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

Частичная работа должна иметь отдельную категорию. «Почти правильно» всё ещё может помогать, но это не то же самое, что «сделано». Если модель пишет ответ, в котором пропущена одна деталь политики и человек должен исправить это перед отправкой, считайте это ассистированной работой, а не завершённой задачей.

Чёткие правила «зачтено/не зачтено» решают большинство проблем. Для каждого типа задачи нужен простой стандарт, по которому двое людей поставят одинаковую оценку:

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

Правило должно исходить из точки зрения пользователя, а не усилий модели. Длинный умный ответ всё ещё может провалиться. Короткий ответ может пройти, если он чисто решает задачу.

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

Это делает метрики AI гораздо честнее. Вы прекращаете поощрять активность и начинаете измерять завершённую работу.

Определите задачу до того, как измерять

Люди не покупают AI‑фичу, чтобы генерировать токены. Они используют её, чтобы закончить работу. Если вы хотите, чтобы число вроде «стоимость за успешную AI‑задачу» имело смысл, сначала опишите эту задачу простым языком.

Хорошее описание задачи звучит так, как сказал бы пользователь: «подготовь ответ на этот запрос о возврате», «преврати заметки звонка в обновление CRM» или «правильно классифицируй этот счёт». Слабое описание похоже на внутреннее событие системы, например «запустить модель» или «сгенерировать 800 слов». Вывод модели — лишь часть работы. Задача считается завершённой, когда пользователь получает полезный результат.

Определите финишную черту до релиза фичи. Если ждать до запуска, команды обычно выбирают то, что проще посчитать. Это превращается в метрики объёма вместо метрик результата. Решите заранее, что значит успех, кто его проверяет и когда задача считается завершённой.

Для большинства команд определение задачи требует трёх вещей: цели пользователя, условия прохождения и метода проверки.

Возьмём почтовую поддержку как пример. «Написать ответ» слишком расплывчато. «Написать ответ, который агент отправляет с незначительными правками» — лучше. Теперь есть ясное конечное состояние, и вы можете тестировать на реальной работе, а не гадать.

Разделяйте типы задач

Не смешивайте очень разные работы в одну корзину. Краткий ответ по FAQ, спор по оплате и требование об отмене подписки могут все лежать в «поддержке клиентов», но у них разная сложность, риск и показатели успеха. Если объединять их, усреднение скроет, что именно делает фича хорошо.

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

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

Как вычислять метрику

Начните с пачки реальной работы, а не демо. Недели обычно хватает, если задача встречается часто. Вытащите каждую попытку для этой задачи, включая грязные случаи, которые люди любят игнорировать.

Используйте полные затраты

Сложите всё, что использовала задача. Включите плату за модель, вызовы инструментов или API и стоимость повторов, когда первый ответ провалился. Затем добавьте человеческое время на проверку, исправление и передачу.

Эта последняя часть важнее, чем многие команды ожидают. Если AI сэкономил 30 секунд, но руководитель поддержки потратил четыре минуты на исправление результата, задача не была дешёвой.

Вам не нужна идеальная финансовая модель на первом этапе. Простая почасовая ставка для проверяющего — достаточна, если вы применяете одно и то же правило каждый раз.

cost per successful AI task =
(total model cost + tool call cost + retry cost + human review cost)
/
(number of tasks that met the success rule)

Считайте в знаменателе только задачи, прошедшие ваше правило успеха. Если AI набросал 500 ответов, но только 320 соответствовали вашему бару, делите на 320. Не учитывайте черновики, попытки или частичные победы в знаменателе.

Здесь команды часто себя обманывают. Низкий счёт по модели может выглядеть хорошо до тех пор, пока вы не включите повторные попытки, ручные исправления и случаи, которые так и не дошли до клиента.

Разделяйте показатель там, где меняется работа

Держите метрику отдельно по типам задач. Ответ на сброс пароля, запрос о возврате и отчёт об ошибке могут быть в одной очереди поддержки, но автоматизировать их стоит по‑разному.

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

Используемая так «стоимость за успешную AI‑задачу» даёт ясное сравнение между подсказками, моделями и изменениями рабочего процесса. Оно показывает, сколько стоит одно завершённое полезное дело.

Простой пример из службы поддержки

Команда поддержки использует ассистента для черновиков ответов на входящие тикеты. Ассистент обрабатывает рутинные вопросы: сброс пароля, вопросы по оплате и обновления доставки. Агенты проверяют черновик, вносят небольшие правки и отправляют.

В течение недели команда отслеживает использование токенов. Они также считают то, что полезнее: сколько тикетов ассистент помог решить без долгих переписок или ручных перезаписей.

Две недели могут выглядеть так:

• Неделя 1: 2.1 миллиона токенов, $420 расходов на модель, 760 решённых тикетов
• Неделя 2: 1.3 миллиона токенов, $270 расходов на модель, 610 решённых тикетов

Если команда остановится на этих данных, Вторая неделя выглядит лучше. Использование токенов упало примерно на 38%, а расходы на модель снизились на $150.

Но агенты чувствуют изменения сразу. На Неделе 1 подсказка даёт модели заметки по политике, правила статусов заказов и несколько примеров ответов. Черновики длиннее, но агенты тратят около 45 секунд на их доработку.

На Неделе 2 кто‑то укоротил подсказку, чтобы сократить расходы. Черновики стали дешевле, но и более расплывчатыми. Теперь агенты тратят около 95 секунд на исправление тона, добавление пропущенных шагов и уточнение деталей. Больше клиентов отвечает снова, потому что первый ответ не решил проблему.

Если вернуть труд в расчёт, картина меняется.

Предположим, команда платит около $30 в час за поддержку. Если Неделя 1 создаёт 12.5 часов редактирования — это $375 труда. Общие расходы составляют $795. Делим на 760 решённых тикетов — и получаем около $1.05 за успешную AI‑задачу.

Если Неделя 2 создаёт 26.4 часа редактирования, труд вырастает до $792. Общая сумма становится $1,062. Делим на 610 решённых тикетов — и значение подскакивает примерно до $1.74.

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

Где подсчёт токенов всё ещё полезен

Данные по токенам важны, потому что быстро показывают потери. Если после правки подсказки функция стала использовать вдвое больше токенов, команда должна остановиться и проверить изменения до того, как счёт вырастет.

Раздутие подсказок легко пропустить. Команды продолжают добавлять инструкции, примеры, заметки по безопасности и полный чат‑хистори в каждый запрос. Модель может и работать, но приложение платит за много текста, который даёт мало или совсем ничего. Токены делают это видимым.

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

Скорость — ещё одна причина внимательно отслеживать токены. Большие подсказки обычно замедляют ответы, и пользователи замечают задержку раньше, чем рост счёта по модели. Инструмент поддержки, дающий ответ за четыре секунды, кажется удобным. Тот же инструмент за 12 секунд раздражает, даже если качество ответа примерно то же.

Несколько проверок ловят большинство распространённых проблем:

• Сравнивайте расход токенов по подсказкам, которые решают одну и ту же задачу.
• Отслеживайте задержку рядом с использованием токенов во время тестов.
• Следите за внезапными скачками после изменений подсказки или поиска.
• Проверьте, действительно ли больший контекст улучшает процент успеха.

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

Тем не менее токены принадлежат диагностике, а не итоговому табло. Если одна версия использует больше токенов, но решает значительно больше клиентских проблем правильно, она может быть лучшим продуктовым выбором. Низкое потребление токенов само по себе не победа.

Когда вы отслеживаете стоимость за успешную AI‑задачу, данные по токенам помогают объяснить, почему число изменилось. Они показывают, где утекали деньги и время. Но они не скажут, выполнила ли фича свою задачу.

Распространённые ошибки, искажающие показатель

Команды часто портят эту метрику, делая её слишком простой для «победы». Если за успех считают каждый ответ модели, число будет отличным и почти ничего не значить. Ответ, который звучит плавно, но ведёт пользователя в неверном направлении, всё равно отнимает деньги, время и доверие.

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

Ручная доработка — место, где многие команды прячут реальные расходы. Агент может тратить дополнительные три минуты на исправление тона, проверку фактов или переписывание сломанных шагов. Эти минуты должны входить в метрику.

Средние значения портятся, когда команды смешивают лёгкие и тяжёлые задачи. Краткий ответ FAQ и многошаговый спор по оплате не должны лежать в одной корзине. Лёгкая работа делает среднее дешёвым, в то время как трудные кейсы продолжают проваливаться в фоне.

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

Изменения подсказок могут ломать базу даже быстрее, чем плохой подсчёт. Если вы переписали подсказку, поменяли модель или доступ к инструментам — вы изменили систему. Сохраняйте старое число для истории, но начинайте новую базу для сравнений.

Короткий аудит помогает поймать большинство проблем:

• Потребовалось ли человеку исправить ответ, прежде чем он стал пригоден?
• Включили ли вы неудачные прогоны, повторы и ошибки инструментов в общие расходы?
• Разделены ли лёгкие и тяжёлые задачи?
• Изменялась ли подсказка или рабочий процесс с последнего измерения?

Команды, которые сохраняют строгость в этих правилах, получают метрику, которой можно доверять. Те, кто ослабляет правила, обычно в итоге измеряют объём вывода, а не полезную работу.

Проверки перед тем, как доверять метрике

Аккуратная таблица может скрывать слабую метрику. Прежде чем использовать «стоимость за успешную AI‑задачу» для оценки фичи, проверьте, совпадает ли число с тем, что пользователи чувствуют в реальной работе.

Начните со скорости, но измеряйте человеческую скорость, а не скорость модели. Если AI заканчивает за восемь секунд, но пользователь всё ещё тратит четыре минуты на исправление ответа, задача не стала заметно быстрее. Засеките время реального человека с момента начала работы до момента, когда он может двигаться дальше.

Скрытый человеческий труд искажает число сильнее, чем многие ожидают. Кто‑то пишет подсказку, кто‑то проверяет крайние случаи, кто‑то чистит плохие выводы, и кто‑то отвечает разгневанному клиенту, когда модель терпит провал. Если эта работа остаётся за рамками метрики, фича выглядит дешевле, чем есть.

Простая проверка должна ответить на четыре вопроса:

• Заканчивает ли пользователь задачу быстрее от начала до конца?
• Какие ручные шаги всё ещё происходят до или после вывода AI?
• Изменился ли процент успеха после последней правки подсказки или рабочего процесса?
• Держится ли число на разных типах задач?

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

Группы задач тоже важны. Одна команда поддержки может работать с сбросом паролей, спорами по оплате и трудными слияниями аккаунтов. Если их смешивать в одно среднее, лёгкие задачи скроют провалы. Разбейте метрику по группам и посмотрите, сохраняется ли тенденция.

Здесь же помогает опытное техническое руководство. Oleg Sotnikov, через oleg.is, работает со стартапами и небольшими командами над продуктом, инфраструктурой и операциями, ориентированными на AI, и такая дисциплина измерений часто отделяет полезную фичу от дорогостоящего демо.

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

Что делать дальше

Выберите одну высокообъёмную задачу, которая уже важна для бизнеса. Хорошие кандидаты: ответы поддержки, квалификация лидов, проверка документов или первичная сортировка багов. Запускайте одно и то же определение успеха в течение двух недель, чтобы получить достаточно случаев и увидеть закономерности, а не реагировать на один удачный или неудачный день.

Держите первый тест узким. Если вы одновременно меняете подсказку, правила маршрутизации, модель и политику проверки, число ничего не скажет. Чистый первый проход делает «стоимость за успешную AI‑задачу» гораздо более доверяемой.

Затем просмотрите результат вместе с продуктом, инженерами и операциями. Продукт подскажет, помогает ли вывод клиентам. Инженеры объяснят, где система тратит деньги или время. Операции скажут, выдерживает ли рабочий поток загруженный день. Такое сочетание важно, потому что дешёвый результат может быть плохим продуктом, а высокий процент успеха — слишком медленным или дорогим в эксплуатации.

Используйте число, чтобы принять одно ясное решение:

• Оставьте фичу, если успех остаётся высоким и стоимость укладывается в маржу.
• Переработайте задачу, если люди продолжают вручную исправлять одни и те же ошибки.
• Автоматизируйте больше шагов, если AI хорошо работает, а передачи вручную съедают выгоду.
• Остановите фичу, если она не достигает цели и простые правки не помогают.

После этого переходите к следующей задаче, а не к десяти одновременно. Команды учатся быстрее, когда вырабатывают привычку измерять полезные результаты, а не спорить о графиках токенов в одиночку.