Кэширование промптов: как проверить экономию без утечки
Кэширование промптов позволяет не пересчитывать неизменную часть запроса при каждом обращении к модели. Это полезно, когда десятки запусков используют одну длинную инструкцию, справочник терминов или формат ответа. Но кэш не является бесплатной памятью и не должен превращаться в скрытое хранилище пользовательских данных. Нужно понимать, какой префикс совпадает, по какому ключу он изолируется, сколько хранится и что происходит после изменения инструкции.
Разделите запрос на два блока
Стабильный префикс помещайте в начало: системные правила, схему ответа, неизменный публичный справочник. Динамическую часть добавляйте после него: вопрос, текущую дату, историю сессии и документ пользователя. Кэш обычно работает только при полном совпадении последовательности токенов. Один изменённый символ, пробел или автоматически добавленная дата может превратить ожидаемое попадание в промах.
Перед настройкой нарисуйте простую схему:
[версия правил][формат ответа][публичный справочник] ← стабильное
[вопрос][текущий документ][идентификатор сессии] ← динамическоеНе помещайте персональные данные и секреты в общий префикс. Если провайдер не объясняет изоляцию кэша по проекту, аккаунту и региону, кэшируйте только публичные правила.
Сначала посчитайте базовую стоимость
Предположим, стабильная инструкция занимает 3000 токенов, а вопрос — 150. При ста одинаковых запросах без кэша обрабатывается около 315 000 входных токенов. С кэшем повторно учитывается только динамическая часть, но реальная экономия зависит от тарифа, срока хранения и политики провайдера. Это пример расчёта, а не обещание конкретной скидки.
В журнале фиксируйте входные и кэшированные токены, число попаданий, промахи, задержку и цену принятого результата. Если после промаха оператор повторяет запрос дважды, эти вызовы тоже входят в стоимость. Экономия на одном обращении не равна экономии всего процесса.
Проведите контрольный эксперимент
Сделайте четыре запуска одного запроса:
- холодный прогрев без предыдущего префикса;
- повтор с точным совпадением;
- тот же префикс с изменённым вопросом;
- изменение одного символа в системном блоке.
Сохраните ответ API о попадании, размеры частей и задержку. Затем добавьте автоматически формируемую дату и повторите тест. Так станет видно, не ломает ли библиотека совпадение скрытым полем.
| Запуск | Ожидаемый статус | Что проверяем |
|---|---|---|
| Прогрев | промах | время первичного расчёта |
| Точный повтор | попадание | реальная экономия |
| Новый вопрос | попадание префикса | динамика отдельно |
| Изменённое правило | промах | корректность версионирования |
Промах после обновления правил нормален. Случайный промах из-за сериализации — дефект, который нужно исправить до масштабирования.
Версионируйте инструкции
Добавляйте номер версии в стабильный блок и в журнал. При изменении ограничения создавайте новый префикс, а старый выводите из обращения после проверки. Не пытайтесь незаметно «дописать» одно правило в середину общего текста: часть пользователей может продолжить получать старый кэш.
Сохраняйте хэш префикса вместо полного текста, если он содержит внутренние сведения. Для расследования достаточно знать, какой версии соответствовал запуск и когда она стала активной.
Приватность и изоляция
История чата, имена клиентов, договоры и внутренние цены не должны попадать в общий кэш. Проверьте, разделяются ли записи по пользователю, проекту и региону, и можно ли удалить их досрочно. Удаление исходного документа не гарантирует мгновенное исчезновение уже закэшированного контекста.
Если динамический документ содержит чувствительные данные, сначала обезличьте его локально; порядок описан в практике маскирования. Не сохраняйте полный приватный текст в журнале ради метрик — используйте хэш, размер и технический статус.
Наблюдаемость в эксплуатации
Добавьте поля prefix_version, stable_tokens, dynamic_tokens, cache_status, latency_ms, input_cost и review_status. Настройте предупреждение о резком падении доли попаданий. Причина часто находится в изменении шаблона, библиотеки, разделителей или сериализации, а не в самой модели.
Раз в неделю выбирайте несколько обезличенных запусков и проверяйте, что ответ использовал актуальную версию правил. Если модель получила старый префикс, остановите автоматический маршрут и обновите ключ кэша.
Архитектурные ошибки
Самая опасная ошибка — общий кэш для разных пользователей. Даже при одинаковом вопросе динамический контекст может смешаться. Вторая — кэширование постоянно меняющегося регламента; экономия исчезает, а устаревшее условие остаётся незаметным. Третья — изменение всей инструкции из-за одного ограничения, после чего невозможно сравнить версии.
Не пытайтесь лечить низкую долю попаданий повышением temperature. Причина обычно в структуре префикса. Для короткого одноразового вопроса настройка кэша вообще может стоить больше, чем сэкономленные токены.
Тест с намеренным рассинхроном
Перед включением кэша в рабочий маршрут проверьте, что система умеет заметить устаревший префикс. Создайте две версии правила с различимым, но безопасным маркером: например, POLICY-A и POLICY-B. Прогоните запросы в разных сессиях и убедитесь, что ответ отражает именно активную версию. Затем отключите старую версию и повторите запрос с прежним ключом. Если API продолжает отвечать по POLICY-A, у команды есть проблема с инвалидированием, а не с промптом.
Второй тест — на разделение арендаторов. Отправьте одинаковую задачу от двух тестовых пользователей, но добавьте каждому уникальный идентификатор только в динамическую часть. Ответ не должен повторять чужой идентификатор, а статус кэша должен оставаться техническим и одинаковым. Сохраните логи без содержимого сообщений, чтобы проверять изоляцию, не создавая новый архив персональных данных.
Третий тест — на деградацию. В течение часа постепенно меняйте длину вопроса и добавляйте редкие символы, не трогая стабильный блок. Постройте график доли попаданий и задержки. Резкий провал после конкретного размера указывает на ограничение провайдера или сериализатора; его нужно описать в инструкции оператора, а не скрывать усреднённой метрикой.
Как принять решение
Кэш оправдан, если стабильный контекст длинный, повторяемый и безопасный, а API сообщает проверяемый статус попадания. Откажитесь от него для уникальных персональных запросов, часто меняющихся документов и сервисов с непрозрачным сроком хранения. Сравнивайте не цену генерации, а время и стоимость принятого результата вместе с повторными проверками.
Итоговый чек-лист
- Стабильная и динамическая части разделены.
- Версия и хэш префикса фиксируются.
- Проведён тест прогрева, попадания и намеренного промаха.
- Измеряются токены, задержка и фактическая цена.
- Персональные данные и секреты исключены.
- Известны изоляция, срок хранения и удаление.
- Настроено предупреждение о падении попаданий.
- После обновления правил выполнен повторный тест.
Кэширование промптов полезно только там, где повторяется безопасный контекст. Измеряйте его журналом API, версионируйте правила и не путайте сокращение вычислений с правом хранить пользовательские данные.