Semantic cache для LLM: архитектура, similarity threshold, invalidation и безопасность

Semantic cache ускоряет ответ ценой нового класса ошибок

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

Cache miss вызывает новый LLM-call и стоит денег. False hit мгновенно возвращает чужой, устаревший или контекстно неверный ответ. Поэтому оптимизация начинается с качества reuse decision.

Не путайте четыре вида кэширования

Эти слои имеют разные TTL, invalidation и метрики. Не называйте их одним cache hit в dashboard.

Когда semantic reuse действительно уместен

Сначала exact cache, затем semantic

Exact cache дешевле, объяснимее и имеет меньшую вероятность неверного reuse. Постройте canonical request key, измерьте повторяемость и только затем добавляйте embeddings для оставшихся запросов. Это создаёт baseline и показывает верхнюю границу дополнительной пользы.

Определите cache eligibility до lookup

Не каждый запрос должен попасть в cache. Детерминированный policy слой проверяет intent, data class, наличие персональных параметров, time sensitivity, side effects и требование свежего retrieval. Модель может помочь классифицировать, но окончательное решение принимает runtime.

Allow response caching only when:
use_case is allowlisted
AND no secrets or sensitive personal data
AND no live transaction state
AND no tool side effects
AND answer is reusable across the selected scope
AND source and policy versions are known
AND response passed validation

Otherwise bypass cache and record the reason.

Cache key обязан включать весь контекст ответа

Одинаковый вопрос может иметь разные ответы для tenant, языка, тарифа, региона, версии продукта и policy. Если эти dimensions не входят в scope, hit становится утечкой или логической ошибкой.

scope_hash = SHA256(
  tenant_id + workspace_or_public_scope
  + actor_policy_hash + locale + region
  + product_version + model_version
  + prompt_version + tool_schema_version
  + retrieval_corpus_version + safety_policy_version
  + output_schema_version
)

Vector search is executed only inside scope_hash.

Нормализация не должна удалять смысл

Можно унифицировать Unicode, пробелы и безопасные представления регистра. Нельзя бездумно удалять числа, отрицания, даты, product IDs, единицы измерения и порядок, если он влияет на запрос.

Embedding model является частью версии cache

Смена embedding model, dimensions или preprocessing меняет геометрию similarity. Не смешивайте vectors разных версий в одном поисковом пространстве. Создавайте новый namespace и прогревайте его отдельно.

• Храните provider, model ID и dimensions.
• Версионируйте normalization pipeline.
• Проверяйте supported distance metric.
• Не сравнивайте scores между разными индексами.
• Миграция проходит shadow dual lookup.

Threshold выбирается на размеченных парах

Число similarity из примера документации не является универсальным порогом. Соберите пары запросов: safe reuse, unsafe reuse и hard negatives, различающиеся одним числом, отрицанием, tenant или временем. Постройте precision/recall по threshold.

For each query pair label:
SAFE_REUSE - same correct answer under the same scope
UNSAFE_REUSE - similarity exists, but answer differs

For every candidate threshold calculate:
accepted-hit precision
accepted-hit recall
false-hit severity-weighted loss
expected saved inference cost
embedding + storage + review cost

Choose threshold under a minimum precision gate.

Один global threshold почти всегда слаб

Разные intents и языки имеют разные score distributions. FAQ о настройке может терпеть paraphrase, а вопрос со сроком или версией требует exact constraints. Применяйте threshold по use case, locale и risk tier, но не создавайте сотни необслуживаемых правил без данных.

Candidate проходит не только similarity

После vector search проверьте scope, eligibility, source versions, TTL, locale, response schema, safety flags и статус validation. Можно дополнительно использовать дешёвый reranker или rule-check по критичным сущностям.

Cache entry хранит доказательства происхождения

Недостаточно сохранить query, vector и answer. Добавьте scope, versions, timestamps, sources, validation, safety, usage и invalidation tags. Raw sensitive prompt хранится только при необходимости и по retention policy.

entry_id, scope_hash
canonical_query_hash, embedding_ref, embedding_version
response, response_schema_version
model_version, prompt_version, policy_version
source_ids_and_versions, generated_at
validated_at, validator_version, quality_status
expires_at, invalidation_tags, revoked_at
hit_count, last_hit_at
data_class, encryption_key_ref

Freshness определяется данными, а не только TTL

Фиксированный TTL удобен, но изменение документа должно инвалидировать ответ сразу. Назначьте dependency tags: product version, policy ID, catalog snapshot, source document. Событие обновления помечает связанные entries revoked либо переключает versioned namespace.

Stampede возникает и у semantic cache

После массовой invalidation много одинаковых miss одновременно идут в LLM. Используйте single-flight по canonical cluster, короткий lease на regeneration, jittered TTL и bounded refresh queue. Не заставляйте user request ждать бесконечный rebuild.

• Один leader генерирует candidate.
• Followers ждут ограниченное время или обходят cache.
• Failed generation не записывается как valid.
• Negative cache для terminal invalid requests имеет короткий TTL.
• Refresh не вытесняет interactive quota.

Tenant isolation проверяется до vector search

Запрос к общему vector index без tenant filter уже нарушает boundary, даже если результат отфильтровали позже. Используйте namespace или mandatory pre-filter и повторную ownership-проверку. Public cache - отдельный явный scope, а не запись без tenant ID.

Cache poisoning начинается с плохой записи

Если атакующий добился сохранения вредоносного или неверного ответа, semantic cache масштабирует его на похожие запросы. Кэшируйте только outputs из allowlisted workflow, прошедшие schema, safety и quality validation. Разделяйте запись и чтение правами.

Персонализация резко сужает reuse

Ответ, использующий историю, тариф, регион или права пользователя, нельзя отдавать другому actor только потому, что вопрос похож. Либо включайте эти dimensions в scope, что снижает hit rate, либо кэшируйте общий reusable skeleton и подставляйте проверенные персональные данные после.

Не кэшируйте agent plans как готовое действие

План, tool arguments и approval зависят от текущего state. Можно кэшировать read-only справочную часть или шаблон декомпозиции, но runtime заново проверяет preconditions и строит proposal. Cached output никогда не является разрешением на side effect.

• Approval не переносится между requests.
• Idempotency key не хранится как reusable response.
• Tool catalog/version входит в scope.
• Живые данные перечитываются.
• Policy decision выполняется заново.

Метрики должны отличать полезный hit от любого hit

ROI считается после учёта embeddings и ошибок

Экономия inference уменьшается на embedding calls, vector search, storage, replication, invalidation, engineering и manual review. False hit может стоить больше десятков правильных hits. Считайте ожидаемую ценность по сегментам.

net_value = avoided_LLM_cost
  + avoided_latency_value
  - embedding_cost
  - cache_storage_and_search
  - invalidation_and_operations
  - review_cost
  - severity_weighted_false_hit_loss

cost_per_accepted_answer = total_system_cost / accepted_answers

Shadow rollout отделяет поиск от выдачи

1. Соберите baseline запросов, качества, latency и cost.
2. Включите exact cache.
3. Запустите semantic lookup в shadow без выдачи.
4. Разметьте candidates и откалибруйте thresholds.
5. Разрешите low-risk FAQ небольшой cohort.
6. Показывайте provenance и feedback control.
7. Следите за false hits и freshness.
8. Расширяйте intents по одному.
9. Держите мгновенный bypass и purge.

Production-чек-лист semantic cache