Счёт за обращения к модели растёт быстрее, чем поток операций, и обычно этого не замечают, пока он не станет заметным.
Хорошая новость: в системах, которые никто специально не оптимизировал, счёт почти всегда можно сократить в разы — и часто без потери качества, а иногда с его ростом.
Из чего складывается счёт, разобрано отдельно — «Длина контекста и стоимость». Здесь семь приёмов в порядке отдачи, с оценкой каждого.
1. Сократить передаваемые фрагменты
Отдача: обычно наибольшая.
Типичная ошибка систем с поиском по документам — передавать десять найденных фрагментов вместо трёх-четырёх «чтобы наверняка».
Лечится добавлением переоценки: из двух десятков кандидатов отбираются лучшие — «Реранкинг».
Побочный эффект, который важнее экономии: качество ответов растёт. Лишние фрагменты размывают ответ.
2. Перевести простые шаги на модель поменьше
Отдача: кратная на тех шагах, где применимо.
Классификация обращения, приведение текста к формату, определение срочности — не требуют сильной модели. Разница в цене между лёгкой и тяжёлой моделью обычно кратная, а на этих задачах качество сопоставимо.
Разбор — «Малые модели для бизнес-задач». Требует общего слоя доступа, иначе маршрутизация расползётся по коду — «Шлюз моделей».
Усиленный вариант: двухступенчатая схема — лёгкая модель обрабатывает весь поток, тяжёлая подключается только там, где сработали проверки или флаг неуверенности.
3. Убрать из потока то, что решается правилами
Отдача: пропорциональна доле структурированного входа.
Часть операций не требует модели вовсе: обращение пришло из формы с указанной темой, письмо от известного отправителя, документ с текстовым слоем.
Правила обрабатывают это бесплатно, модель разбирает остаток. В моей практике это регулярно сокращало поток к модели вдвое — «Когда хватит скрипта вместо ИИ».
Почему приём недооценён: он требует разобрать состав потока, а это скучная работа, которую пропускают.
4. Кешировать
Отдача: зависит от доли повторов, иногда очень высокая.
Два уровня:
Кеш ответов. Повторяющиеся запросы не идут в модель дважды. В поддержке доля повторов бывает значительной.
Кеш неизменяемой части запроса. Если поставщик это поддерживает, длинная системная инструкция передаётся один раз и переиспользуется. При инструкции в пару тысяч токенов и большом потоке экономия существенная.
5. Сократить системную инструкцию
Отдача: умеренная, но постоянная.
Инструкция передаётся при каждом обращении. Инструкция на две страницы при десяти тысячах обращений — это две страницы, оплаченные десять тысяч раз.
Проверяется просто: удалить половину примеров и прогнать контрольный набор. Часто выясняется, что накопленное «на всякий случай» ни на что не влияет — «Промпт-инжиниринг в продукте».
6. Обрезать историю диалога
Отдача: высокая в диалоговых сценариях.
В переписке каждое следующее обращение несёт все предыдущие реплики. Стоимость диалога растёт не линейно.
Лечится передачей нескольких последних реплик вместо всей истории. Ещё лучше — структурированное состояние вместо истории: что выяснено, что решено, что осталось. Несколько строк вместо страниц.
Для агентских сценариев это основной рычаг — «Стоимость эксплуатации ИИ-агента».
7. Ограничить длину ответа и использовать пакетный режим
Отдача: умеренная.
Выход обычно дороже входа за токен. Если ответ должен быть коротким, это задаётся явно.
Пакетный режим: если ответ не нужен немедленно — ночная обработка документов, разбор отзывов, — неспешный режим у ряда поставщиков заметно дешевле.
Сводка
| Приём | Отдача | Трудоёмкость |
|---|---|---|
| Меньше фрагментов | высокая | средняя |
| Модель поменьше на простых шагах | высокая | средняя |
| Правила вместо модели | высокая | средняя |
| Кеширование | зависит от повторов | низкая |
| Короче инструкция | умеренная | низкая |
| Обрезать историю | высокая в диалогах | средняя |
| Ограничить ответ, пакетный режим | умеренная | низкая |
Порядок применения: начинать с трёх верхних, потом кеширование как самое дешёвое, остальное по обстоятельствам.
Разбор: счёт сократили втрое
Задача. Конвейер обработки обращений, около 25 000 операций в месяц. Счёт за модель вырос до величины, которая стала заметной в бюджете.
Что нашли и что сделали.
Посмотрели журнал обращений — он был, и это единственная причина, по которой разбор занял день, а не неделю.
Первое. Средний запрос содержал около 9 000 токенов, из них более половины — найденные фрагменты, по десять штук. Добавили переоценку, стали передавать четыре. Контрольный набор показал, что качество не упало, а на части вопросов выросло.
Второе. Разобрали состав потока. Треть обращений приходила из формы с указанной темой — их классификация моделью была лишней. Перевели на правило.
Третье. Классификацию оставшихся перевели на лёгкую модель, проверив на контрольном наборе, что точность не пострадала. Тяжёлая осталась только на составлении ответов.
Четвёртое. Системная инструкция за год выросла до полутора тысяч токенов. Убрали четыре примера из девяти — результат на наборе не изменился.
Пятое. Добавили кеш ответов. Доля повторяющихся вопросов оказалась около 15%.
Что получилось.
| Показатель | Было | Стало |
|---|---|---|
| Обращений к модели в месяц | 25 000 | ~16 000 |
| Средний размер запроса | ~9 000 токенов | ~3 400 |
| Доля тяжёлой модели | 100% | ~35% |
| Счёт | база | ~30% от базы |
Сколько заняло. Около недели работы. Окупилось за первый месяц.
Что стоит забрать. Ни одна из мер не была сложной. Все они не были сделаны сразу, потому что на этапе запуска счёт был небольшим и об этом не думали. Это нормально — но пересматривать стоит, когда объём вырастет.
Что настроить, чтобы это было возможно
Журнал обращений с записью размера запроса, использованной модели и стоимости. Без него разбор невозможен, а оптимизация превращается в угадывание.
Учёт по процессам — чтобы видеть, какой сценарий сколько тратит.
Слой доступа к моделям — иначе маршрутизация на разные модели неосуществима.
Лимит расходов с остановкой — защита от лавины повторов при сбое.
Контрольный набор — чтобы каждое сокращение проверялось на качестве, а не делалось вслепую.
Частые вопросы
Как снизить расходы на обращения к модели?
По убыванию отдачи: передавать меньше найденных фрагментов, перевести простые шаги на модель поменьше, убрать из потока то, что решается правилами, добавить кеширование, сократить системную инструкцию, обрезать историю диалога и ограничить длину ответа.
Не пострадает ли качество?
Часть мер его улучшает: сокращение числа передаваемых фрагментов убирает шум из контекста и делает ответы точнее. Остальные проверяются контрольным набором — каждое изменение прогоняется до и после, и ухудшившее откатывается.
Какой приём даёт больше всего?
Обычно сокращение передаваемых фрагментов при поиске по документам: это самая крупная часть запроса, и её нередко можно уменьшить в два-три раза. На втором месте — перевод простых шагов на лёгкую модель.
Почему счёт растёт быстрее числа операций?
Потому что растёт объём текста в каждом запросе: увеличивается база знаний и в контекст попадает больше фрагментов, разрастается инструкция, копится история диалога. Платят за объём, а не за число обращений.
С чего начать разбор?
С журнала обращений: посмотреть распределение размеров запросов и из чего они состоят. Обычно сразу видно, какая часть занимает больше всего. Без журнала оптимизация превращается в угадывание, и это первое, что стоит завести.
Когда пересматривать расходы?
Когда объём операций вырос в разы относительно момента запуска. На старте счёт мал и об экономии не думают — это нормально. Проблема в том, что к этому не возвращаются, и система годами работает в режиме, рассчитанном на прототип.
Что дальше
Из чего складывается счёт — «Длина контекста и стоимость». Полная картина расходов — «TCO ИИ-решения». Инфраструктура для маршрутизации — «Шлюз моделей». Когда своё железо дешевле облака — «Облако или свой сервер».
Разбор расходов существующей системы с планом сокращения — отдельная работа в рамках аудита и сопровождения решений.