Бюджеты токенов по этапам рабочего процесса для снижения затрат на ИИ

Почему один месячный лимит не работает

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

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

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

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

Простой пример иллюстрирует проблему. Представьте команду, которая тратит $5,000 в месяц на workflow для внутренних отчётов. Они видят только одну сумму и поэтому убирают шаг ревью, сэкономив $700. Через месяц сотрудники тратят часы на правку неаккуратных черновиков, а расходы на генерацию едва сдвинулись, потому что проблема была в retrieval, которое отправляло в каждый запрос слишком много текста.

Теперь тот же рабочий процесс с отдельными бюджетами:

• Retrieval: $1,800
• Generation: $2,500
• Review: $700

Такой вид быстро меняет разговор. Команда видит, что retrieval раздут, ревью скромно, и очевидное сокращение оказалось не самым разумным.

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

Сначала спланируйте рабочий процесс

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

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

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

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

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

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

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

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

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

Установите бюджет для retrieval

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

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

Для рутинных запросов хорошо работает небольшой дефолтный лимит. Большинству повседневных задач не нужно 20 документов и длинный обмен сообщениями. Если задача простая, дайте retrieval жёсткий бюджет и заставьте систему выбирать лучшие источники в первую очередь.

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

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

Уберите шум прежде чем повышать лимит

Многое из waste в retrieval приходит от контекста, который редко меняет ответ. Старые заметки собраний, повторяющийся текст политик, шаблонные документы и устаревшие фрагменты часто проскальзывают в подсказки, потому что их легко прикрепить. Удалите их в первую очередь — обычно вы получите тот же ответ за меньший объём токенов.

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

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

Установите бюджет для generation

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

Разделите generation на категории задач. Большинству команд нужно как минимум две: короткие рутинные ответы и более длинная работа по написанию. Именно здесь часто появляются первые экономии.

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

Разумный начальный диапазон может выглядеть так:

• Ответ в чате или поддержке: 80–150 выходных токенов
• Внутреннее резюме: 150–300
• Продающее письмо или короткий черновик: 300–600
• Черновик предложения, мемо или спецификации: 900–1,800

Эти числа не магические. Они дают чистую отправную точку. Дальше подстраивайте их по реальному использованию.

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

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

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

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

Установите бюджет для review

Ревью — то место, где команды часто переплачивают. Они отправляют каждый вывод на второй проход модели, даже когда первая задача низкорискова и легко проверяема человеком.

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

Ревью обычно оправдано, когда ИИ:

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

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

Когда вы делаете ревью, держите подсказку короткой. Длинные подсказки для ревью растрачивают токены и часто заставляют модель много рассуждать. Простые правила работают лучше: проверьте факты по источнику, отметьте отсутствующие поля, отвергните небезопасные действия и верните только pass, fail или одну короткую причину.

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

Логируйте то, что реально ловит ревью: тип задачи, стоимость ревью, процент отказов и находило ли ревью реальную проблему или просто переписало ответ другими словами. Через две–три недели паттерн обычно ясен.

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

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

Как устанавливать числа шаг за шагом

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

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

Дальше распределите каждый вызов по трем корзинам: retrieval, generation или review. Retrieval покрывает поиск, поиск чанков, эмбеддинги и сбор контекста. Generation — основной ответ или черновик. Review — второй проход, такой как критика, оценка, переписка или проверки guardrail.

Используйте обычный диапазон, а не только среднее

Средние скрывают потери. Одна плохая подсказка может сместить всё распределение, поэтому начните с середины данных. Проверьте медиану и верхнюю границу обычного диапазона для каждой корзины. Если generation для ответа поддержки обычно лежит между 2,000 и 4,000 токенов, не базируйте бюджет на редком выбросе в 12,000 токенов.

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

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

Простой rollout выглядит так:

• Вытянуть неделю логов и очистить явный шум
• Промаркировать каждый вызов как retrieval, generation или review
• Найти обычный диапазон токенов для каждой корзины
• Установить мягкие лимиты и наблюдать за ошибками, повторами и снижением качества
• Изменять по одному лимиту и ждать несколько дней перед следующим изменением

Последний шаг важен. Если вы одновременно понижаете retrieval и review, вы не поймёте, какое изменение вызвало ухудшение ответов. Маленькие шаги делают бюджет более надёжным.

Простой пример команды

Команда поддержки, обрабатывающая 4,000 вопросов в месяц, часто расходует токены на retrieval, а не на сам ответ. Большинство тикетов простые: сброс пароля, копия счета, смена email или даты подписки.

В одном случае бот подтягивал 12 документов на каждый тикет перед тем, как написать ответ. Это звучало безопасно, но было расточительно. Для типичных вопросов модели обычно нужно было 2–3 коротких фрагмента, чтобы ответить хорошо.

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

После того как команда картировала поток, они разделили бюджет по шагам вместо одного месячного лимита. Retrieval получил первое исправление. Для обычных случаев количество документов упало с 12 до 3, тогда как возвраты и биллинг оставили более глубокий retrieval и ревью.

До и после было просто:

• До: 12 документов на тикет, один проход генерации, одно ревью на все тикеты
• После: 3 документа для обычных тикетов, один проход генерации, ревью только для возвратов и изменений биллинга

Числа быстро изменились. Среднее число токенов на рутинный тикет упало с ~2,900 до ~950. Месячные расходы сократились более чем на 55%. Медианное время ответа упало с 8 секунд до 4.5, потому что модели было меньше контекста для чтения.

Команда следила за ошибками две недели. Рутнинговые ответы почти не изменились: с 3.1% до 3.3%. Ошибки по возвратам и биллингу улучшились, потому что ревью осталось там, где оно было нужно.

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

Ошибки, которые продолжают жечь токены

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

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

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

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

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

Последняя ошибка — урезать слишком сильно, пока качество не упадёт. Тогда люди запускают подсказки снова, задают дополнительные вопросы или вручную правят слабые черновики. Эти скрытые затраты могут съесть всю экономию.

Быстрый аудит поможет:

• Сравните использование токенов по retrieval, generation и review
• Найдите задачи с длинной историей и коротким выводом
• Проверьте, сколько реально меняет второй проход ревью
• Следите за повторами после ужесточения лимитов

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

Быстрые проверки перед развёртыванием

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

Начните с отчётности. Если один отчёт не может показать токены для retrieval, generation и review как отдельные числа, вы не сможете понять, какой шаг тратит деньги. Команды часто сначала винят generation, а потом выясняют, что retrieval подтягивал лишний контекст или ревью работало лишний раз.

Короткий pre‑launch чеклист:

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

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

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

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

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

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

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

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

Хорошая первая проверка проста:

• Ограничьте retrieval так, чтобы он подбирал только контекст, который люди реально читают
• Ограничьте generation так, чтобы ответы были ровно такой длины, какая нужна, а не длиннее
• Ограничьте review так, чтобы люди тратили внимание на рискованные задачи, а не на всё подряд
• Запишите стартовые числа прежде чем что‑то менять

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

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

Если команда уже тратит реальные деньги на ИИ и мелкие правки подсказок уже не помогают, внешний аудит полезен. Oleg Sotnikov на oleg.is работает как fractional CTO и советник стартапов — он помогает компаниям просмотреть AI‑воркфлоу, инфраструктуру и решения по автоматизации, чтобы резать траты без замедления полезной работы.

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