Что такое semantic cache

Semantic cache переиспользует ответ не только при полном совпадении строки, а когда новый запрос достаточно близок по смыслу к уже обработанному. Обычно запрос кодируется embedding-моделью, затем ищутся похожие записи, и ответ возвращается только при прохождении заданного threshold.

Зачем он нужен

LLM-вызовы часто дороже и медленнее обычного cache lookup. Для повторяющихся FAQ, classification, support и retrieval workflows semantic cache может снизить cost и latency, особенно когда пользователи формулируют один смысл разными словами.

Не кэшируйте всё подряд

Первый шаг — определить cacheable операции. Не стоит переиспользовать ответы, которые зависят от current time, баланса, прав пользователя, свежего inventory, состояния заказа или другого быстро меняющегося контекста.

Нормализуйте cache key

В key должны входить не только embedding запроса. Добавляйте model/version, prompt template version, locale, tenant, permission scope, relevant feature flags и версию knowledge base. Иначе похожий текст может получить ответ из другого контекста.

Выберите similarity threshold

Слишком низкий threshold увеличивает hit rate, но повышает риск semantic false positive. Слишком высокий превращает semantic cache почти в exact cache. Threshold нужно подбирать на eval dataset с реальными paraphrases и hard negatives.

Используйте двухэтапную проверку

Для чувствительных сценариев сначала найдите top-k похожих entries по embeddings, затем выполните дешёвую дополнительную проверку: rules, reranker или classifier. Это снижает риск вернуть ответ на похожий, но не эквивалентный вопрос.

TTL и invalidation обязательны

У semantic cache должен быть TTL. Кроме времени, инвалидируйте entries при смене prompt, модели, policy, документации или бизнес-данных. Versioned namespaces обычно надёжнее массового ручного удаления.

Учитывайте персональные данные

Не допускайте cross-user и cross-tenant leakage. Cache scope должен учитывать identity и permissions, а чувствительные prompts и outputs лучше не сохранять либо предварительно редактировать по data-retention policy.

Что сохранять

Полезно хранить normalized query, embedding, response, source/context IDs, model, prompt version, createdAt, expiresAt, tenant scope и quality metadata. Это делает cache объяснимым и пригодным для audit.

Observability

Отслеживайте hit rate, accepted/rejected candidates, similarity score distribution, latency saved, token/cost saved и число ошибочных hits. Высокий hit rate сам по себе не означает хороший cache.

Evals для semantic cache

Соберите пары equivalent/non-equivalent запросов. Проверяйте precision cache hits, а не только recall. Ошибочный reuse обычно дороже cache miss, поэтому production threshold лучше выбирать консервативно.

Практический production checklist

  • Явно определить cacheable endpoints.

  • Versioned cache namespace.

  • Tenant/user permission scope.

  • Embedding model version в key.

  • Threshold на основе evals.

  • TTL и event-driven invalidation.

  • Hard-negative tests.

  • PII/data-retention policy.

  • Метрики cost и latency savings.

  • Быстрый kill switch для cache layer.

Вывод

Semantic cache полезен там, где запросы повторяются по смыслу, а ответ стабилен. Его нельзя проектировать только как vector search: безопасный production cache требует scope, versioning, TTL, invalidation и evals на false-positive hits.