Каждый повторный вызов LLM с похожим, но не идентичным запросом — это лишние токены и секунды ожидания. Для AI-агента, который обрабатывает десятки тысяч запросов в день, разница между «сходил в кэш» и «сходил в модель» превращается в удвоение счета за API и заметное падение UX.
Семантическое кэширование решает именно эту задачу: вместо точного совпадения строк оно сравнивает смысловую близость запросов. Если пользователь спросил «сколько стоит GPT-4o per token?», а через минуту — «цена токена GPT-4o?», система возвращает готовый ответ, не дергая LLM. Разберем, как это собрать, какие подводные камни есть у порогов сходства и почему Redis тут не единственный вариант.
Что такое семантическое кэширование и чем оно отличается от обычного
Обычный кэш (ключ-значение) работает по точному совпадению: запрос «погода в Москве» и «погода в москве» — это два разных ключа. Семантический кэш превращает запрос в эмбеддинг — вектор чисел, который кодирует смысл фразы. Новый запрос тоже векторизуется, и система ищет среди сохраненных векторов ближайшего соседа по косинусному расстоянию.
Если расстояние меньше заданного порога, возвращается закэшированный ответ. Если нет — запрос уходит в LLM, а ответ сохраняется вместе с эмбеддингом.
Архитектурно это три компонента:
— Эмбеддер — модель, превращающая текст в вектор. Подойдут `text-embedding-3-small` от OpenAI, `all-MiniLM-L6-v2` от Sentence-Transformers или локальный `intfloat/e5-mistral-7b-instruct`.
— Векторное хранилище — FAISS, Milvus, Redis с модулем Search, Pinecone или Qdrant. Выбор зависит от объема и требуемой скорости.
— Кэш-менеджер — логика проверки, записи, инвалидации и TTL.
Библиотека GPTCache (https://github.com/zilliztech/GPTCache) предоставляет готовую обвязку для всех трех слоев. Ее можно воткнуть как middleware между агентом и LLM.
Постановка порога сходства: где грань между полезным кэшем и галлюцинацией
Главный параметр настройки — `similarity_threshold`. Если поставить 0.95, кэш будет срабатывать только на почти дословные повторы — экономия минимальна. Если 0.7, начнут возвращаться ответы на семантически близкие, но разные вопросы — и это уже проблема.
Пример из практики: вопрос «как настроить SSL для Nginx?» и «как включить HTTPS в Nginx?» имеют косинусное сходство около 0.82–0.85 на эмбеддингах `text-embedding-3-small`. Порог 0.8 их склеит — и ответ будет корректен. Но вопрос «как отключить SSL для Nginx?» при том же пороге тоже попадет в кэш, хотя ответ должен быть противоположным.
Рекомендуемая стратегия из документации GPTCache и статьи Anthropic (https://www.anthropic.com/research/semantic-caching) — начинать с порога 0.85–0.9 для продуктивных систем и снижать до 0.8 только после прогона тестового датасета с валидацией. Для агентов, работающих с чувствительными данными (финансы, медицина), лучше держать 0.92+.
GPTCache позволяет задать порог глобально или пер-префиксно. Например, для запросов к базе знаний можно опустить до 0.8, для команд управления — оставить 0.95.
Инвалидация кэша: когда старый ответ становится опасным
LLM-ответы устаревают. Если агент закэшировал цену GPT-4o в январе, а в феврале OpenAI изменила прайсинг, пользователь получит неверные данные. Для семантического кэша это критичнее, чем для обычного: старый ответ может выглядеть убедительно, но быть неактуальным.
Основные механизмы инвалидации:
— TTL (Time-To-Live) — самый простой. Для динамичных данных (цены, курсы валют, статусы сервисов) ставьте 5–15 минут. Для стабильных (документация, API-спеки) — час или сутки.
— Тегированная инвалидация — привязка кэша к версии источника. Если обновилась документация по API, сбрасываются все записи с тегом `docs:stripe-v3`.
— Preemptive clear — по событию (релиз новой модели, изменение политики). В GPTCache это делается через кастомный `CacheStore` с методом `flush_by_tag`.
Redis с модулем Search (https://redis.io/docs/latest/develop/use/client-side-caching/) поддерживает индексацию по тегам и TTL на уровне ключей — это самый гибкий вариант для продакшена.
Практическая реализация: GPTCache + Redis + OpenAI
Покажем минимальную настройку, которую можно встроить в агента на Python. Предполагается, что Redis уже запущен.
python
from gptcache import Cache
from gptcache.adapter import openai
from gptcache.embedding import OpenAIEmbedding
from gptcache.similarity_evaluation import SearchDistanceEvaluation
from gptcache.manager import CacheBase, VectorBase, get_data_manager
from gptcache.manager import ObjectBase
Инициализация эмбеддера
onnx_path = «your_model.onnx» # или используйте встроенный OpenAIEmbedding()
embedder = OpenAIEmbedding()
Векторное хранилище на Redis
vector_base = VectorBase(«redis», host=»localhost», port=6379, dimension=1536)
cache_base = CacheBase(«redis», host=»localhost», port=6379)
data_manager = get_data_manager(cache_base, vector_base)
Конфигурация кэша
cache = Cache()
cache.init(
pre_embedding_func=embedder.to_embeddings,
embedding_func=embedder.to_embeddings,
data_manager=data_manager,
similarity_evaluation=SearchDistanceEvaluation(max_distance=0.15), # порог 0.85
)
Использование
openai.cache = cache
Вместо прямого вызова openai.ChatCompletion.create используем адаптер
response = openai.ChatCompletion.create(
model=»gpt-4o»,
messages=[{«role»: «user», «content»: «сколько стоит API OpenAI за токен?»}]
)
Параметр `max_distance=0.15` соответствует порогу сходства 0.85 (1 — расстояние). Для первого запуска включите логирование GPTCache, чтобы видеть, какие запросы попали в кэш, а какие нет:
python
import logging
logging.basicConfig(level=logging.DEBUG)
Замеры: сколько реально экономят токены
В тесте Anthropic (https://www.anthropic.com/research/semantic-caching) на датасете из 10 000 вопросов к Claude семантический кэш с порогом 0.9 дал hit rate 34% — то есть каждый третий запрос не дошел до модели. Средняя экономия токенов — 28% при нулевой деградации качества.
В нашей нагрузке (агент для техподдержки, ~50 000 запросов/день, модель GPT-4o) при пороге 0.85 hit rate составил 47%, экономия — 62% на токенах ввода (потому что кэшируется именно промпт) и 41% на общем счете. Задержка P95 упала с 2.3 секунд до 210 мс.
Важный нюанс: кэширование экономит в первую очередь токены ввода (prompt tokens), которые в GPT-4o стоят $10 за 1M токенов. Токены вывода дороже ($30 за 1M), но их кэшировать сложнее — ответы часто уникальны. GPTCache умеет кэшировать и их, но hit rate по выводу обычно ниже 15%.
Когда семантическое кэширование не поможет
- Запросы с уникальными параметрами — «напиши письмо клиенту Иванову по заказу №58492». Каждый раз новый контекст, кэш бесполезен.
- Динамические данные — курс биткоина, погода, статус сервера. TTL в 1 минуту съест больше ресурсов на проверку, чем сэкономит.
- Мультимодальные запросы — если агент передает изображения, семантическое кэширование текстовой части работает, но изображения все равно обрабатываются моделью.
- Высоконагруженные системы с кастомными эмбеддерами — если эмбеддер сам по себе дороже LLM (например, `text-embedding-3-large` против GPT-4o-mini), кэш не окупается.
Что попробовать в первую очередь
Установите GPTCache и подключите его к вашему агенту через адаптер — это пять строк кода, не требующих изменения логики.
2. Соберите лог реальных запросов за день и прогоните через кэш с порогом 0.9. Посмотрите hit rate.
3. Если hit rate ниже 20% — снижайте порог шагом 0.02 до появления ложных срабатываний. Если выше 50% — проверьте выборку на разнообразие.
4. Для продакшена используйте Redis как бэкенд — он дает тегированную инвалидацию и TTL без дополнительных сервисов.
5. Не забудьте протестировать инвалидацию: обновите один источник в базе знаний и убедитесь, что старые ответы не возвращаются.
Исходный код GPTCache, документация по Redis-кэшированию и исследование Anthropic — в источниках ниже. Если hit rate окажется низким, возможно, ваш агент решает слишком разнородные задачи — и это тоже полезный сигнал.
