Себестоимость запроса к агенту и цена его ошибки

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

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

Дневник курса, урок 21. Пригодится разобранное раньше: бюджеты и лимиты на рассуждение (урок 2) — откуда в счёте берётся множитель; контроль расходов и метрики качества (урок 7) — чем этот счёт вообще измеряют; режимы отказа в проде (урок 11) — что ломает экономику после запуска. Пост читается отдельно: все термины вводятся заново.

1. Демо и продукт: два разных критерия успеха

Демо оценивают на благополучном сценарии — том самом happy path, который докладчик выбрал сам и прогнал заранее десяток раз. Критерий там бинарный, сработало или не сработало. Продукт оценивают по поведению на реальном объёме, каждый день, на пользователях, которые придумывают запросы, не предусмотренные сценарием показа. Разрыв между этими двумя режимами измеряется не качеством модели, а тем, что происходит с ошибкой.

Отраслевая статистика с этим согласуется. Gartner в релизе от 25 июня 2025 года прогнозирует, что до конца 2027 года более 40% агентных проектов свернут или выведут из эксплуатации. Названы три причины, и все три лежат вне модели. Это рост затрат, размытая бизнес-ценность и недостаточный контроль рисков. Ни одна не звучит как «нейросеть оказалась слабовата».

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

К тому же прогнозу прилагается наблюдение про рынок. Под этикеткой автономных агентов регулярно продают чат-ботов и RPA-скрипты — роботов, которые повторяют записанную последовательность действий в интерфейсе и ничего не решают сами. Реальным автономным планированием, по оценке Gartner, обладают порядка 130 вендоров из тысяч представленных. Такой подмене придумали название по образцу гринвошинга, когда обычный товар переупаковывают в экологичный. Вышла перекраска под агента — обёртка новой технологии на старой начинке; в отчёте это зовут agent washing. Вывод отсюда неприятный. Рамка, по которой мы отличаем продукт от демонстрации, нужна и для собственных решений, и для оценки того, что приносят нам на подпись.

2. Что считать юнитом: задача с результатом против открытого диалога

Юнит-экономика сводит прибыль и убыток не по компании целиком, а по одной единице работы. Сколько принесла и сколько съела вот эта конкретная штука, повторённая тысячу раз. Работает такой расчёт только там, где у работы есть измеримая граница: вход, обработка, результат. У агента, устроенного вокруг диалога, границы нет, и все дальнейшие расчёты придётся строить на допущениях.

Различие между двумя типами агентов обычно подают как продуктовое, а платят за него финансисты. Диалоговый агент (chat-oriented) устроен вокруг разговора. Сценарий открытый, пользователь ведёт беседу куда хочет, а успех измеряется субъективно: по удовлетворённости, естественности ответа, ощущению, что собеседник помогает. Ассистент, который объясняет новичку код, живёт именно так, и это нормально. Целевой агент (goal-oriented) устроен вокруг задачи. На входе метаданные и документы, на выходе описание таблицы, разобранное обращение, заполненная форма. Успех у него объективен и меряется точностью и долей результатов, ушедших без правок.

Что же тогда считать юнитом? Честно посчитать выходит только у второго типа. Юнитом здесь работает один осмысленный запрос с результатом, он же единица того, что бизнес продаёт. Формула на первый взгляд тривиальна.

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

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

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

Считают ценность через альтернативу. Выгода приходит с трёх сторон. Экономия (автоматизировали существующий процесс, ручного труда стало меньше), ускорение (людей столько же, но они производят больше) и новый процесс (раньше такого просто не делали). Быстрее всего оценивать так. Взять время специалиста, которое агент заменил, и умножить на стоимость часа. Возьмём типовой кейс, где агент описывает таблицы корпоративного каталога данных. В учебном расчёте выходит 2,5 минуты машинной работы против 4 часов аналитика; дальше подставляете ставку.

Есть и величина, которой в формуле прибыльности нет, хотя решения от неё зависят. Это доля создаваемой ценности, которую забирает ваша цена. Считается она делением цены запроса на ценность действия. Если агент снял с клиента работы на 10 000 рублей, а выставили ему 9 000, доля равна 0,9. Сервис бывает маржинальным и при этом забирает у клиента почти всю выгоду. Такой сервис уязвим перед первым же конкурентом, который придёт с половинным тарифом. Низкая доля означает обратное — запас для повышения цены, о котором никто не знал.

def unit_economics(cfg: dict) -> dict:
    tokens = (cfg["in_tokens"] / 1000 * cfg["price_in_1k"]
              + cfg["out_tokens"] / 1000 * cfg["price_out_1k"])
    infra = (cfg["infra_month"] + cfg["support_month"]) / cfg["requests_month"]
    amort = cfg["build_cost"] / cfg["requests_lifetime"]

    cost = tokens + infra + amort                    # себестоимость запроса
    value = cfg["manual_minutes"] / 60 * cfg["hour_rate"]   # ценность действия

    return {
        "cost": cost,
        "value": value,
        "margin": value - cost,
        # цена для клиента делится на его же выгоду
        "value_share": cfg["price_per_request"] / value,
    }

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

3. Себестоимость запроса: четыре слагаемых и восемь слоёв

Себестоимость одного запроса складывается минимум из четырёх частей, и амортизация разработки оказывается сопоставима с токенами. В учебном расчёте на кейсе описания таблиц это видно так: 6 млн рублей, потраченных на продукт, при 2 млн запросов за продуктовый цикл дают 3 рубля на каждый запрос.

Разложим по частям:

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

В инфраструктуру входят хостинг моделей, векторная база, поисковый индекс и обычная СУБД. Поддержка — это мониторинг, дежурные инженеры и разбор инцидентов. Амортизация собирает единовременные траты на бэкенд, фронтенд и исследовательскую часть, размазанные по ожидаемому числу запросов. Считать её нужно циклами, обычно месячными, потому что без ограничения по времени жизни продукта делить не на что, и расчёт превращается в спор о вечности.

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

Вторая ошибка стоит отдельного разбора, и дело тут не в арифметике. Исследовательская часть не кончается, потому что циклов разработки у такого продукта два, и идут они параллельно.

  ML-цикл                          продуктовый цикл
  ────────────────────────────     ────────────────────────────
  спринт = набор гипотез           спринт = набор задач, 2 недели
  итог: подтвердилось или нет      итог: код в проде
  критерий готовности:             критерий готовности:
  воспроизводимый результат        покрыт тестами,
  на тестовых данных               прошёл ревью
  длина спринта — до 2 месяцев

        └──── на вход продуктовому идёт подтверждённая
              гипотеза с метриками, а не сырая идея ────►

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

FinOps Foundation — созданный при Linux Foundation орган, который стандартизирует управление облачными затратами. В разборе токен-экономики 2026 года он раскладывает себестоимость AI на восемь слоёв, а подсчёт по одним токенам называет частичным взглядом. Такая арифметика меряет предельную стоимость лишнего вызова и молчит о постоянных и полупостоянных тратах. Сойдётся ли экономика при росте объёма, решают именно они.

что приходит счётом за инференс
   1  токены: input / output / reasoning / кэш
───────────────────────────────────  ниже платят другие бюджеты
   2  GPU, векторная БД, хранилище
   3  капитальные вложения в дата-центр
   4  трафик между регионами
   5  SaaS с зашитым внутрь AI: потребление скрыто от покупателя
   6  люди: дежурство, мониторинг, прогоны оценки, ревью безопасности
   7  права на данные
   8  теневой ИИ: инструменты и агенты в обход закупок

Два слоя из этого списка стоит развернуть. Пятый занимают SaaS-инструменты с зашитым внутрь AI. Подписка выглядит фиксированной, но цена из прайс-листа, по формулировке того же разбора, перестала быть надёжным ориентиром для бюджета: плата за место задаёт только нижнюю границу, а сумму счёта двигает переменная часть. Вы покупаете место, а платите за потребление, которое внутри инструмента не разложено. Восьмой слой назван по аналогии с теневыми ИТ: агенты, подписки и ключи к API, заведённые командами мимо закупок и потому не попадающие ни в один бюджет.

Оттуда же берётся поправка на скорость. Предприятие покупает ту часть пропускной способности, что дошла до пользователя вовремя и в пригодном виде. В разборе это зовут полезной пропускной способностью (goodput), в отличие от сырой. При одинаковом тарифе токен, отданный со скоростью 5 токенов в секунду, и токен на 500 остаются экономически разными товарами.

4. Почему цены за токен падают, а расходы растут

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

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

Главный множитель дают переход от чата к рассуждению и агентные нагрузки: по оценке FinOps Foundation, на одну задачу они съедают в 5–30 раз больше токенов, чем тот же вопрос, заданный в чате. Откуда берётся пятикратный, а тем более тридцатикратный множитель? Набирается он двумя эффектами подряд. Первый даёт сама модель. Рассуждающая модель перед ответом порождает цепочку размышлений, которую пользователю не показывают, зато тарифицируют по ставке обычных выходных токенов. Пользователь платит и за эту скрытую цепочку, а она бывает длиннее самого ответа. Второй добавляет агент. Одному вопросу пользователя соответствует не один вызов модели, а цикл из нескольких (планирование, вызов инструмента, разбор результата, следующий шаг), и на каждом витке весь накопленный контекст вместе с ответами инструментов уезжает на вход заново.

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

Отсюда и следствие, из-за которого разваливаются бюджеты: расход токенов не пропорционален видимой активности пользователей. Число пользователей выросло вдвое, число запросов выросло вдвое, а счёт вырос кратно сильнее, и в дашборде продукта нет ни одной метрики, которая бы это предсказала. Из отчётности компаний тот же разбор приводит порядок величин. У AT&T после перехода на мультиагентные системы суточное потребление ушло примерно с 8 до 27 млрд токенов, больше чем втрое; прибавка пришлась на этот переход, но отчётность компании не отделяет её от роста числа пользователей.

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

Экономия на модели подняла стоимость решения задачи более чем в полтора раза. Метрика на уровне вызова этого не показывает вообще. Она честно рапортует, что вариант А в два с половиной раза дешевле.

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

Технически разметка стандартизована. OpenTelemetry — открытый стандарт телеметрии, на котором держится значительная часть индустриального мониторинга. Его реестр атрибутов gen_ai.* ушёл далеко за пару «вход/выход», и новые поля объясняют ровно те расхождения между ожидаемым и фактическим счётом, о которых речь выше. Чтение и запись кэша разведены (gen_ai.usage.cache_read.input_tokens и gen_ai.usage.cache_write.input_tokens), потому что тарифицируются по-разному. Положить кусок промпта в кэш дороже обычного входного токена, прочитать его оттуда заметно дешевле, и слитые в одно число, они прячут и экономию от кэша, и цену, которую за неё заплатили. Скрытые рассуждающие токены вынесены отдельной статьёй, gen_ai.usage.reasoning.output_tokens. Агентный контур описан своими полями: gen_ai.agent.id, gen_ai.tool.name, gen_ai.conversation.id, gen_ai.conversation.compacted.

resp = client.chat.completions.create(
    model=MODEL,
    messages=messages,
    extra_headers={"X-Feature-ID": "table_description", "X-Tenant": tenant},
)

u = resp.usage                      # только официальный usage, не len(text) / 4
meter.record(
    feature="table_description",
    tenant=tenant,
    input_tokens=u.prompt_tokens,
    output_tokens=u.completion_tokens,
    cached_input=u.prompt_tokens_details.cached_tokens,
    reasoning=u.completion_tokens_details.reasoning_tokens,
    outcome="resolved",             # без этого поля считается вызов, а не исход
)

Ради последнего поля вся разметка и заводится. Сумма затрат по outcome="resolved", делённая на число закрытых задач, и есть стоимость исхода, а всё остальное остаётся красивым дашбордом.

5. Своя инфраструктура: цена считается по загрузке, а не по прайс-листу

Возьмём H100, серверный ускоритель NVIDIA, на котором обычно держат корпоративный инференс. На этом железе эффективная стоимость миллиона выходных токенов расходится от $0.21 до $15.25, больше чем в семьдесят раз. Отдельно посчитано, сколько в этом разбросе даёт одна только загрузка карты, и выяснять её стоит раньше, чем сравнивать собственный хостинг с оплатой по API.

Работа, которая это измерила (arXiv:2606.11690, препринт от 10 июня 2026 года), начинается с претензии к жанру: «Every public LLM cost calculator we surveyed treats GPU utilization as a fixed input — entered by the user, baked in as a preset, or silently assumed at 100% — never measured against the operator’s actual load». Утилизацию берут как данность, и потому все такие расчёты занижают цену ровно в 1/U раз, где U — фактическая загрузка. Арифметика тут школьная. Аренда карты стоит одинаково и когда та выдаёт свой максимум токенов, и когда простаивает. Загружена она на четверть, значит, те же деньги делятся на вчетверо меньшее число токенов, и каждый дорожает вчетверо. Ошибка при этом всегда в одну сторону: чем меньше у вас трафика, тем сильнее калькулятор врёт в пользу собственного хостинга.

Управляет всем одна переменная, которую держит в руках оператор, — интенсивность входящего потока λ, то есть сколько запросов в секунду реально приходит. Через закон Литтла (среднее число заявок в системе равно интенсивности потока, умноженной на среднее время обслуживания) она задаёт, сколько запросов обрабатывается одновременно, а это и есть заполненность пакета на карте. Пакет здесь важен. Ускоритель считает не по одному запросу, а пакетом, прогоняя один и тот же набор внутренних параметров модели сразу на всю группу. Полупустой пакет занимает столько же тактов, сколько полный, поэтому чем меньше в нём запросов, тем дороже обходится каждый выданный токен. Ни один открытый калькулятор эту переменную не показывает.

Из этого и берётся величина, которую работа называет штрафом за недоутилизацию: во сколько раз токен на вашей загрузке дороже, чем на насыщенной карте. Штраф отвечает за одну только λ, так что смешивать его с семидесятикратным разбросом цен нельзя. При 10 rps пакет собирается почти полным, а при 1 rps карта половину времени ждёт следующего запроса, и штраф растёт. Эффект не привязан к одной установке. Он держится на 42 бенчмарках и воспроизводится на другой карте, A100 80GB PCIe, где штраф составляет 7,0–11,4×.

штраф за недоутилизацию, разы к цене токена на насыщенной карте
(меняется только входящий поток)

 36.3× ┤  ●╮  простой: очередь пуста, карта оплачена целиком
       │    ╲
   24× ┤     ●╮  λ ≈ 1 rps
       │      ╲
       │           ╲
  2.5× ┤                ●╮  λ ≈ 10 rps: пакет собирается почти полным
    1× ┤                 ╰───●  насыщение
       └──┬──┬──────────┬────┬───►  λ, запросов в секунду
          0  1          10   20

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

Ценность локального контура при этом никуда не девается, просто она не в цене за токен. Данные не уходят наружу, поведение воспроизводимо, никто не меняет версию модели у вас под руками в середине эксперимента. А экономят на отладке другим — сокращением объёма, а не переносом инференса: прогон на подвыборке вместо полного корпуса, кэш ответов на повторяющихся запросах, записанные и переигрываемые трейсы вместо живых вызовов. Тот же приём работает и на проде. Каскадная маршрутизация и кэш стабильной части промпта уводят простые запросы на младшую модель и не дают платить дважды за одно и то же начало. Обе оптимизации, впрочем, требуют работающей атрибуции, потому что без разбивки по типам запросов непонятно, какие из них «простые».

6. Галлюцинации: ограничивать ущерб вместо погони за нулём

Неверный ответ обнуляет ценность действия, а токены за него уже уплачены. Галлюцинация бьёт по обеим частям формулы прибыльности сразу. Когда агент начинает выдумывать, первым делом хочется взять модель посильнее. Помогает это не всегда. Флагман врёт втрое чаще младшей модели того же семейства, 9,3% против 3,1% на снимке открытого лидерборда Vectara от 11 мая 2026 года. Речь про gpt-5.5 и gpt-5.4-nano. В таблице младшие модели одного семейства стабильно стоят выше старших, так что одним неудачным замером это не объяснить.

Меряют там верность поданному документу, а не эрудицию. Модель просят пересказать текст и смотрят, не добавила ли она от себя. Лучший результат среза — antgroup/finix_s1_32b с 1,8%; в том же срезе gpt-5.4 и gemini-2.5-pro дают 7,0%, gpt-5.5 и qwen3-235b-a22b — 9,3%. Причин таблица не показывает, однако объяснение напрашивается. У флагмана больше выученного из обучающего корпуса и сильнее закреплена привычка выдавать полный связный ответ, поэтому на месте пробела в поданном документе он скорее достроит недостающее из того, что запомнил при обучении, чем оставит дырку. На творческой задаче это достоинство, на пересказе договора — дефект.

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

Настройки декодирования дают ещё немного, и платить за это «немного» приходится вычислениями. На Mistral-7B-Instruct-v0.1 лучевой поиск с num_beams=10 снимает треть галлюцинаций (6,8% → 4,7%) ценой десяти параллельных цепочек вместо одной: счёт растёт по вычислениям, а показанных токенов остаётся ровно столько же. Выгодна такая сделка или нет, показывает юнит-экономика.

Отдельный класс, который не ловится ни бенчмарком, ни валидатором формата, — семантические ошибки. Они возникают не от поломки, а от нехватки контекста. Вот учебная иллюстрация. У агента спрашивают, с каким счётом сборная Дании играла с нашей в 1242 году, и он бодро отвечает «2:0 в пользу сборной СССР». Ответ синтаксически безупречен, проходит любую проверку схемы, попадает в лог как успешный. Средства против таких ошибок другие. Контекст обогащают до генерации метаданными и связями между сущностями, вторым проходом ставят независимый верификатор, держат выборочный человеческий аудит именно смысловой корректности и собирают пользовательский фидбэк как данные для донастройки.

К тому же выводу исследователи пришли со стороны измерений. Работа «Towards a Science of AI Agent Reliability» (arXiv:2602.16666, 18 февраля 2026) начинается с наблюдения, что оценка агента сжимает его поведение в одну метрику успеха и тем самым прячет операционные дефекты. Доля успешных прогонов не отвечает на четыре вопроса: одинаково ли агент ведёт себя от раза к разу, выдерживает ли возмущения во входных данных, предсказуемо ли ломается и ограничена ли тяжесть его ошибки. Отсюда четыре измерения — согласованность, устойчивость, предсказуемость и безопасность, — под которые авторы предлагают двенадцать метрик. Оценив пятнадцать моделей на двух бенчмарках, они фиксируют, что недавний прирост возможностей дал лишь небольшое улучшение надёжности.

Ключевое понятие здесь — ограниченная тяжесть ошибки. Продуктовое требование формулируется не как «агент не должен ошибаться», а как «ошибка агента не должна стоить дороже X». Отсюда и формулировки в SLA. SLA — соглашение об уровне сервиса, где записаны значения, за отклонение от которых кто-то отвечает. В учебном расчёте по агенту, который описывает таблицы, SLA обещает точность от 85%. Похоже на признание слабости, но ровно до второй половины договорённости. Оставшиеся 15% заранее посчитаны, разложены по типам и заложены в цену.

7. Обратимость действия как ось архитектуры

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

К обратимым относятся неверное описание таблицы, черновик письма, рекомендация. Цена ошибки равна времени на исправление, «попробовать снова» работает, автономии можно давать больше. Необратимыми будут отправленное клиенту письмо, списание денег, удалённые данные. Цена высокая, повтор не помогает, человек нужен в контуре до действия, а не после. Посмотрим на процесс как на линию, у которой есть точка перехода. До неё всё откатываемо, после уже нет. Значительная часть проектной работы сводится к тому, чтобы отодвинуть эту точку как можно дальше вправо.

В продуктовом разговоре всё это складывают в одну шкалу «уровень автономии», а величин на ней две. Препринт «Autonomy and Agency in Agentic AI» (arXiv:2605.12105, 12 мая 2026) разводит их одной фразой: «agency (what the system can do) and autonomy (how much it acts without human involvement)». Первая ось, agency, меряет, что агенту доступно в принципе: от рассуждения над поданным контекстом (L1) до зафиксированной записи в учётные системы (L5). Вторая, автономия, — сколько он решает без человека, от работы по прямой команде (L1) до самостоятельного мониторинга (L5). Оси связаны. Чем выше автономия, тем реже ошибку кто-то поймает и поправит, и тем сильнее приходится урезать agency — набор того, что агент вообще способен сделать. Поднять автономию, не тронув agency, выходит только на бумаге.

автономия: насколько действует без человека
  L5 │  ok    !     x
  L4 │  ok    !     !
  L3 │  ok    ok    !    ←── здесь ставят чекпоинт или эскалацию
  L2 │  ok    ok    ok
  L1 │  ok    ok    ok
     └──────────────────────►  agency: что система может сделать
        L1    L3    L5

  x — исправлять ошибку некому
  agency L1 — рассуждение по поданному контексту
  agency L3 — вызов инструментов
  agency L5 — запись в учётные системы

  ограждение инструментов — урезает набор вызовов и их параметры
  отложенная запись — переводит изменение в обратимое

Работа предлагает шесть тактик перемещения по этому полю. Четыре знакомы по любому процессу с ручным контролем: чекпоинт (остановка перед опасным шагом до подтверждения человеком), эскалация (передача случая наверх, когда агент не уверен или вышел за границы), делегирование (передача части работы агенту с более узкими правами) и выдача инструментов (набор вызовов, доступных в этом сценарии). Две оставшиеся интереснее, потому что отвечают на вопрос, который обычно решают вызовом человека. Как сделать необратимое действие обратимым? Ограждение инструментов (tool fencing) сужает уже выданное: агенту доступен не весь API, а урезанный набор операций с ограниченными диапазонами параметров. Отложенная запись (write staging) не применяет изменение сразу, а складывает его в промежуточный слой, откуда оно фиксируется отдельным шагом.

def apply_discount(order_id: str, percent: int, ctx: Context) -> dict:
    if percent > ctx.limits.max_discount:   # ограждение инструментов
        return {"status": "rejected", "reason": "over_limit",
                "max_allowed": ctx.limits.max_discount}

    change = stage_write(                   # отложенная запись
        target="orders", key=order_id,
        patch={"discount_pct": percent},
        ttl_minutes=30,
    )
    return {"status": "staged", "change_id": change.id, "commit_required": True}

Разница с человеческим подтверждением тонкая, зато денежная. Чекпоинт останавливает работу и ждёт. Сессия висит, ожидание оплачивается рабочим временем человека, а при потоке в тысячи операций в день ждать приходится долго. Отложенная запись работу не останавливает. Агент идёт дальше, изменение лежит в промежуточном слое со временем жизни, и фиксируется оно либо пакетным подтверждением, либо автоматически после успешной проверки. Ограждение инструментов работает ещё раньше: скидку в 90% агент не «попросит подтвердить», он просто не сможет её выразить, потому что контракт инструмента такого значения не принимает.

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

8. Лестница ошибок: где сбой чинится дешевле всего

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

дешевле ┌ 1  повторная генерация      — продукт сам, цена ≈ вызов
   │    ├ 2  самообучение: база знаний,
   │    │    промпты, дообучение      — продукт сам, цена отложенная
   │    ├ 3  поддержка L1 ──────────┐
   │    ├ 4  поддержка L2           ├ человек: платим рабочим временем
дороже  └ 5  разработка и ML ───────┘

Первая ступень — повторная генерация, встроенная прямо в интерфейс. Это кнопка «переделать» или автоматический повтор по вердикту модели-судьи (LLM-as-a-judge) — отдельной модели, которой показывают готовый ответ и которую просят оценить его по заданным критериям. Её оценку и берут за сигнал «переделать». Есть тонкость, без которой ступень не работает. Повторять стоит с повышенной температурой. Температура — параметр, задающий, насколько охотно модель отходит от самого вероятного продолжения. При низкой температуре модель почти детерминирована. На том же промпте она повторит тот же ход рассуждений вместе с той же ошибкой. Чуть больший разброс уводит генерацию на другую траекторию, и результат получается заметно иным. Приём не универсален, на задачах со строгим форматом рост температуры вредит, так что проверять его надо на своих сценариях.

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

Дальше идут люди. Первая линия поддержки работает по инструкции и закрывает типовое, у второй есть доступ к системе и право копать, а до разработки с ML-инженерами доезжает то, что чинится только кодом или переобучением. Наверх запрос уходит по четырём правилам: модель показывает низкую уверенность в ответе; запрос попадает в необратимую зону; по одному типу запросов ошибка повторяется (значит, дело не в случайности); запрос явно выходит за границы задачи агента.

Экономика лестницы проста, и потому её регулярно упускают. Человек — самый дорогой ресурс в цепочке. Каждое подтверждение и каждый разбор оплачиваются рабочим временем, а при высокой доле эскалаций эксперт, вручную разбирающий контекст и перепроверяющий шаги рассуждения, съедает весь эффект автоматизации. Ступени 1 и 2 стоят внизу ради того, чтобы до третьей доходило меньше; удобство пользователя тут получается побочно.

Роли на этих ступенях стоит развести до первого инцидента, иначе разбор начнётся со спора, чей он:

9. Устав агента: SLA, эскалация и ответственность на бумаге

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

С метриками работает правило обратного хода. Типичный порядок такой: смотрят, что система умеет мерить, и объявляют это метриками. Правильный порядок идёт от цены ошибки. Сначала определяем, что критично бизнесу, и уже под это заводим измерение. Метрика существует ради дорогих ошибок, а заполненный дашборд получается уже побочно. Дополнений к правилу два. Расчёт автоматизировать (метрика, которую считают руками раз в квартал, ни на что не влияет) и отделять технические метрики от продуктовых. Задержка и аптайм — техника; точность и доля ответов, ушедших без правок, — продукт. Смешанные в одном дашборде, они дают зелёный аптайм при упавшей точности, то есть систему, которая выглядит здоровой ровно до звонка клиента.

У того же агента, который описывает таблицы, набор SLA в учебном расчёте выглядит так. Время обработки до 2,5 минуты на таблицу, точность генерируемых описаний от 85%, экономия клиенту до 50 млн рублей. Все три числа условные и зависят от корпуса и ставок. Важно тут другое. Третья метрика принципиально не техническая. Именно она отвечает на вопрос, продолжать ли платить за сервис, и без неё разговор о ценности агента становится бесконечным.

Границы доверия устав назначает по цене ошибки. Мощность модели тут ни при чём. Полная автономность идёт туда, где ошибка дёшева и обратима. Автономность с подтверждением — туда, где действие затратно или заметно клиенту. Только рекомендация остаётся там, где на кону деньги и юридические последствия, а ошибка необратима.

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

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

Итог

И себестоимость запроса, и цену его ошибки задаёт архитектура. Тариф провайдера отвечает лишь за часть первой, и это единственная часть, которая приходит счётом сама.

• Юнит-экономика считается там, где у работы есть вход и выход. Для агента с открытым диалогом расчёт превращается в набор допущений — это аргумент за целевую постановку задачи, а не только вопрос продуктового вкуса.
• Токены — один слой из восьми. Амортизация разработки сопоставима с ними: в учебном расчёте 6 млн рублей на 2 млн запросов дают 3 рубля на запрос, а теневой ИИ и SaaS с зашитым внутрь AI не попадают в счёт за инференс вообще.
• Исследовательская часть сидит в себестоимости постоянно: ML-цикл с гипотезами вместо фич идёт параллельно продуктовому всё время жизни продукта, и его зарплатный фонд ложится на те же запросы.
• Цены за токен падают, счета растут: спрос эластичен, а рассуждающие и агентные нагрузки съедают в 5–30 раз больше токенов на задачу, чем эквивалентный чат. Целевая метрика — деньги за закрытую задачу.
• Своё железо окупает загрузка. Недогруженная карта штрафует цену токена в 2,5–24 раза на потоке 1–10 запросов в секунду и до 36,3 раза в простое; полный разброс эффективной цены по замерам на H100 идёт от $0.21 до $15.25 за миллион выходных токенов.
• Флагманская модель галлюцинирует чаще младшей из того же семейства: на срезе Vectara от 11 мая 2026 года gpt-5.5 даёт 9,3% против 3,1% у gpt-5.4-nano. Проектировать нужно ограниченную тяжесть ошибки — вероятность к нулю не сводится.
• Архитектура выбирается по обратимости действия. Ограждение инструментов и отложенная запись делают необратимое обратимым дешевле, чем человек в контуре, — а человек остаётся самой дорогой ступенью лестницы.

FAQ

Как посчитать юнит-экономику ИИ-агента?

Прибыльность одного запроса равна ценности действия минус себестоимость запроса. Себестоимость складывается минимум из токенов (вход и выход по разным ценам), инфраструктуры, поддержки и амортизации разработки, поделённой на ожидаемое число запросов за продуктовый цикл. Ценность считается через альтернативу: сколько стоило бы получить тот же результат руками, то есть время специалиста, умноженное на стоимость его часа. Считать нужно циклами (обычно месячными) и по типам запросов, а не «в среднем по сервису», ведь среднего запроса не существует.

Почему расходы на LLM растут, хотя цены за токен снижаются?

Из-за эластичности спроса. Удельная цена токена на фиксированном уровне возможностей падает, но корзина реально потребляемых токенов взвешена по тем уровням и объёмам, которых требуют задачи, и она не дешевеет. Главный множитель — переход от чата к рассуждению и агентным нагрузкам: по оценке FinOps Foundation, они съедают в 5–30 раз больше токенов на задачу. Потребление нелинейно относительно пользовательской активности, поэтому прогноз, построенный на числе запросов, систематически промахивается.

Что дешевле — своя инфраструктура или API?

Решает загрузка, а не владение железом. По замерам работы arXiv:2606.11690 (июнь 2026) эффективная стоимость миллиона выходных токенов на H100 расходится от $0.21 до $15.25; этот разброс собран по разным конфигурациям, и одной причиной он не объясняется. Вклад одной только загрузки измерен отдельно и назван штрафом за недоутилизацию. Он составляет 2,5–24× на низких и умеренных нагрузках 1–10 запросов в секунду и доходит до 36,3× у почти простаивающей установки. Публичные калькуляторы принимают утилизацию как данность и потому занижают цену собственного хостинга ровно в 1/U раз, где U — фактическая загрузка карты; сильнее всего это врёт на малом трафике.

Правда ли, что чем мощнее модель, тем меньше галлюцинаций?

Нет. На снимке открытого лидерборда Vectara от 11 мая 2026 года (пересказ поданного документа) gpt-5.5 показывает 9,3% галлюцинаций, а младшая gpt-5.4-nano из того же семейства даёт 3,1%; лучший результат таблицы, 1,8%, принадлежит модели на 32 млрд параметров. Бенчмарк меряет верность поданному документу, а не эрудицию, и старшие модели охотнее достраивают картину из того, что запомнили при обучении. Для агента поверх найденных документов это означает, что критерии «умнее» и «меньше выдумывает» надо проверять отдельно.

Какие действия агенту нельзя доверять без человека?

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

Что должно быть в уставе агента?

Устав отвечает на четыре вопроса. SLA с разделением технических и продуктовых метрик и хотя бы одной метрикой верхнего уровня в деньгах. Граница обратимых и необратимых действий с выбранным уровнем доверия для каждого класса задач. Бюджет на ошибку, то есть какая доля неверных результатов заранее принята и во что она оценена. И зоны ответственности по типам сбоя. Для парка из нескольких агентов документ пишется каждому свой, потому что по релизу Gartner от 26 мая 2026 года единая модель управления на всех ведёт к провалу: меры контроля должны быть пропорциональны риску.

Источники

• FinOps Foundation — Token Economics: The Atomic Unit of AI Value — восемь слоёв себестоимости AI, включая теневой ИИ, механизм эластичного спроса, оценка 5–30× токенов у рассуждающих нагрузок, полезная пропускная способность против сырой.
• FinOps for AI — раздел фреймворка · GenAI FinOps: How Token Pricing Really Works — методология учёта затрат на инференс и разбор того, как устроена тарификация.
• Beyond Per-Token Pricing — arXiv:2606.11690 — диапазон эффективной цены $0.21–$15.25 за миллион выходных токенов на H100, отдельно посчитанный штраф за недоутилизацию 2,5–24× (до 36,3× в простое) и ошибка 1/U в публичных калькуляторах.
• Autonomy and Agency in Agentic AI — arXiv:2605.12105 — разделение осей agency и автономии, уровни L1–L5 по обеим, шесть архитектурных тактик, включая ограждение инструментов и отложенную запись.
• Towards a Science of AI Agent Reliability — arXiv:2602.16666 — двенадцать метрик надёжности по четырём измерениям, понятие ограниченной тяжести ошибки, оценка пятнадцати моделей.
• Vectara Hallucination Leaderboard (HHEM) · Vectara — стратегии снижения галлюцинаций — срез долей галлюцинаций от 11 мая 2026 года и замеры декодирования на Mistral-7B.
• Gartner — прогноз по отмене агентных проектов (25.06.2025) · Gartner — про единую модель управления агентами (26.05.2026) — первоисточники прогноза «более 40% к 2027», термина agent washing и тезиса о пропорциональных контролях.
• OpenTelemetry — реестр атрибутов gen_ai.* — поля для разметки расхода токенов, включая разведённые чтение и запись кэша и отдельную статью рассуждающих токенов.

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