Расход токенов на один диалог упал с 75K до меньше 26K. Счёт обвалился. Модель — та же.
Копилот был выпущен. Он работал. Но трейсы из продакшена рассказывали более тяжёлую историю: средний happy-path диалог сжигал около 75 000 токенов, прежде чем подрядчик успевал финализировать заказ. Расход токенов рос быстрее, чем объём заказов, и стоимость инференса на заказ перестала сходиться с валовой маржой на заказ, которую фича должна была защищать.
Проблема была не в модели. Стек заставлял модель делать три работы одновременно: рассуждать о следующем шаге, писать текст для пользователя и решать, какой UI-элемент рендерить на каждом ходу — какие кнопки, какую карту, какое подтверждение. Каждое из этих UI-решений проходило через модель как инструкции для tool-ов, выводы tool-ов и retry-циклы. Счёт оплачивал театр оркестрации.
Мы перестроили разделение труда между LLM и окружающим приложением. Четыре структурных изменения, без смены модели, без трюков с тюнингом промпта.
В сравнении как есть с эквивалентными happy-path трейсами до проекта:
Мы делали бенчмарк на парных трейсах: один репрезентативный happy path прогнан против сборки до проекта, один эквивалентный happy path прогнан против сборки после проекта, тот же staging-бэкенд, тот же сценарий повторного заказа. Подсчёт токенов берётся из наблюдаемости слоя оркестрации, а не из ответа модели. Цифра 59% получена в чистом повторном прогоне против разогретой сборки; среднее по нескольким репрезентативным путям оказалось в диапазоне 40–60%.
Мы также отслеживали тот класс ошибок, который волновал нас больше всего — фабрикации UI, где модель либо выдумывала ID, либо пропускала рендер обязательной кнопки — по продакшен-трейсам в двухнедельном окне до и после. Этот класс присутствовал до проекта. После него он перестал появляться.
Если ваш AI-копилот ведёт пользователя через структурированный операционный поток — заказы, dispatch-и, тикеты, графики, маршруты — и месячный счёт за инференс обгоняет бизнес-обоснование фичи, есть очень хорошие шансы, что тот же паттерн применим к вам. LLM почти наверняка делает работу, которой должен владеть окружающий код, и платит за эту работу дважды: один раз чтобы её поручить, второй раз чтобы повторить, когда она сделана неправильно.
Разговор по скоупу — правильный первый шаг. Мы можем сказать вам за час, по репрезентативному trace и образцу system prompt, подходит ли этот паттерн под ваш стек и насколько большим, вероятно, будет сокращение.
Нет. То же семейство модели, тот же tier. Каждая цифра в этом кейсе достигнута на исходном выборе модели. Смена модели на столе позже, когда структурные потери убраны — но это второй ход, а не первый.
Это в верхней части того, что мы видим, и получено в чистом повторном прогоне после того, как приземлился весь набор изменений. Реалистичный диапазон по репрезентативной выборке happy-path-ов — 40–60% на копилотах диспетчерского типа. На необычно перегруженных промптом или tool-ами сетапах мы видели большие сокращения; на уже плотных стеках — меньшие.
Основные изменения приземлились примерно за четыре недели. Более длинный хвост — наблюдаемость, eval-harness, передача — занял ещё четыре–шесть. Короткий, заскоупленный, ориентированный на результат; команда клиента теперь эксплуатирует систему без нас.
Нет. Проекты требуют доступа к слою оркестрации — system prompt, определениям tool-ов и репрезентативной выборке продакшен-трейсов. Read-only достаточно для фазы аудита; write-доступ приходит позже, если мы договорились о наборе изменений.
Аудит на две–четыре недели с приоритизированным punch-list и работающим proof-of-concept по одному из пунктов. Без долгосрочных обязательств. Если punch-list вам нравится — мы делаем внедрение. Если нет — punch-list остаётся у вас.