Ошибки в промптах: 5 причин раздутого счёта за LLM

Почему счёт растёт даже при тех же ответах

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

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

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

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

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

На объёме это уже не мелочь. Если один запрос стал длиннее всего на 400 токенов, это выглядит безобидно. Но если таких запросов 50 000 в день, вы оплачиваете миллионы лишних токенов в месяц. Именно так бюджет уходит не из-за плохой модели, а из-за многословного промпта.

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

Где промпт тратит деньги зря

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

Первая утечка - повторы. Команда пишет роль модели в system, потом дублирует её в user-сообщении, а затем ещё раз вставляет те же правила в шаблон. Модель не получает новый смысл от фраз вроде "будь точным", "не выдумывай" и "отвечай кратко", если это уже сказано один раз ясно.

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

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

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

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

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

Пять ошибок, которые обходятся дороже всего

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

1. Одна просьба повторяется разными словами.

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

2. Длинный шаблон копируют в каждый запрос.

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

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

   У длинного контекста есть цена. Если пользователь уже сменил тему, старые сообщения не помогают. Но модель всё равно читает их заново. Для поддержки это типичная ошибка: вместо последних 3-4 реплик отправляют всю историю на 40 сообщений.

4. Вставляют всю справку вместо пары нужных фрагментов.

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

5. Оставляют высокий лимит ответа "на всякий случай".

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

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

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

Как сократить промпт по шагам

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

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

Дальше оставьте правила только там, где есть риск ошибки. Если модель иногда придумывает факты, добавьте одно явное условие: "Не выдумывай детали, которых нет в данных". Если вы боитесь длинных ответов, не надо писать пять похожих ограничений. Хватает одного точного правила.

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

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

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

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

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

Пример на обычной задаче поддержки

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

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

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

Клиент пишет: Хочу вернуть товар. Купил 8 дней назад, упаковку вскрыл,
чек сохранился, дефекта нет. Что мне делать?

Модель прочитает всё это, но пользы мало. Ей не нужно три раза напоминать про вежливость. И фраза про "специалиста высокого уровня" не добавляет точности.

Вторая версия короче. В ней остались только цель, тон и факты.

Ответь клиенту по возврату товара.
Тон: спокойно и вежливо.
Нужно: кратко объяснить, возможен ли возврат, и назвать следующий шаг.
Факты: покупка 8 дней назад, упаковка вскрыта, чек есть, товар без дефекта.

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

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

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

Хорошее правило здесь совсем простое: в промпте должны остаться только три вещи - что сделать, в каком тоне ответить и какие факты нельзя потерять.

Где легко ошибиться после первой правки

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

Самая частая ошибка - резать контекст без разбора. Если убрать повторы, это полезно. Если убрать факты, без которых модель не понимает задачу, она начинает додумывать. В поддержке это видно сразу: оператор просит ответить клиенту по возврату товара, а из промпта уже исчезли срок возврата, исключения и тон ответа. Токенов меньше, правок от команды больше.

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

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

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

Бывает и внутреннее противоречие. В начале промпта просят "ответь кратко", а ниже требуют объяснить решение, привести риски, исключения и пошаговый план. Модель пытается выполнить всё сразу. В итоге ответ получается длинным, неровным и дорогим. Если нужна краткость, задайте предел прямо: например, 5 пунктов и не больше 80 слов.

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

Нормальная проверка после правки короткая: сохраните 10-20 реальных примеров, сравните старый и новый ответ рядом, проверьте формат, длину и точность, а спорные случаи посмотрите отдельно. Этого обычно достаточно, чтобы понять, где вы убрали мусор, а где уже задели смысл.

Быстрая проверка перед запуском

Перед тем как открывать доступ для всей команды или лить трафик в прод, стоит пройти короткую проверку. Она занимает 10-15 минут и часто срезает заметную часть расходов без потери качества.

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

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

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

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

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

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

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

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

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

Сравнивать лучше не только цену. Смотрите сразу на четыре вещи: сколько токенов ушло на вход и на выход, сколько стоит один прогон и серия из 100 или 1000 прогонов, насколько ответ годится для работы без правок и сколько времени он занимает.

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

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

Если вы тестируете несколько моделей, удобно прогонять один и тот же набор запросов через единый интерфейс. Для такой проверки подходит и AI Router на airouter.kz: можно отправлять одинаковые запросы через один OpenAI-совместимый эндпоинт и сравнивать цену, задержку и качество без смены SDK и шаблонов.

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