Кеширование и батчинг: инженерия дешёвых запросов

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

Кеш повторяющихся запросов

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

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

Что нужно решить заранее:

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

Пачки вместо одиночных вызовов

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

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

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

В каком порядке внедрять

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

Чего не стоит делать

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

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

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

Как измерить эффект

Заведите два счётчика: сколько запросов пришло и сколько дошло до провайдера. Их отношение — самая понятная метрика экономии, её видно сразу после включения кеша.

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

Что ещё убирает запросы из счёта

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

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

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

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

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

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

Что сделать на этой неделе

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

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