Инвалидация LLM-кэша при изменении промптов, моделей и корпоративных данных

Что именно нужно инвалидировать

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

Практичная стратегия объединяет три механизма:

• детерминированный ключ, отражающий все факторы, влияющие на ответ;
• TTL, ограничивающий максимальный возраст записи;
• версии и события, немедленно исключающие устаревшие записи.

Шаг 1. Определите состав ключа

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

Ниже — воспроизводимый пример на Python из стандартной библиотеки. Значения демонстрационные: замените их версиями из своей системы.

import hashlib
import json
import unicodedata

def normalize_text(value: str) -> str:
    value = unicodedata.normalize("NFC", value)
    return " ".join(value.split())

def build_cache_key(
    user_query: str,
    prompt_version: str,
    model_id: str,
    generation: dict,
    data_version: str,
    access_scope: str,
) -> str:
    payload = {
        "key_schema": "v2",
        "query": normalize_text(user_query),
        "prompt_version": prompt_version,
        "model_id": model_id,
        "generation": generation,
        "data_version": data_version,
        "access_scope": access_scope,
    }
    canonical = json.dumps(
        payload,
        ensure_ascii=False,
        sort_keys=True,
        separators=(",", ":"),
    )
    digest = hashlib.sha256(canonical.encode("utf-8")).hexdigest()
    return f"llm-cache:v2:{digest}"

key = build_cache_key(
    user_query="Как оформить возврат?",
    prompt_version="support-2026-07",
    model_id="provider:model-id",
    generation={"temperature": 0, "response_format": "json"},
    data_version="kb-1842",
    access_scope="tenant-7:policy-12",
)

print(key)

Сортировка полей и фиксированные разделители делают результат стабильным. Не нормализуйте текст слишком агрессивно: изменение регистра, пунктуации или порядка сообщений иногда меняет смысл.

Шаг 2. Назначьте TTL по цене устаревания

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

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

import secrets

BASE_TTL_SECONDS = 3600
JITTER_SECONDS = secrets.randbelow(301)
ttl_seconds = BASE_TTL_SECONDS + JITTER_SECONDS

Шаг 3. Зафиксируйте события принудительной инвалидации

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

• Публикация промпта: создайте новый неизменяемый prompt_version. Откат должен возвращать прежнюю версию, а не переписывать её содержимое.
• Смена модели: обновите точный model_id. Алиас вроде production недостаточен, если его цель может измениться незаметно для кэша.
• Обновление базы знаний: после успешной индексации атомарно повысьте data_version. Не делайте этого до готовности нового индекса.
• Изменение прав: повысьте версию политики или измените область доступа. Для критичного отзыва прав дополнительно удалите связанные записи.
• Исправление ошибочного ответа: занесите отпечаток записи в список запретов или удалите точный ключ.
• Изменение формата: обновите версию схемы ответа или промпта, даже если пользовательский вопрос не изменился.

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

Шаг 4. Храните метаданные вместе с ответом

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

{
  "answer": "Пример ответа модели",
  "created_at": "2026-07-29T10:00:00Z",
  "expires_at": "2026-07-29T11:03:17Z",
  "prompt_version": "support-2026-07",
  "model_id": "provider:model-id",
  "data_version": "kb-1842",
  "access_scope_hash": "sha256:...",
  "response_schema": "support-answer-v3"
}

Если используется Redis, безопасная запись с автоматическим истечением выглядит так:

SET llm-cache:v2:<sha256> '<json>' EX 3600 NX
TTL llm-cache:v2:<sha256>
UNLINK llm-cache:v2:<sha256>

<sha256> и <json> — заполнители. UNLINK удаляет только явно указанный ключ. Не применяйте FLUSHALL, FLUSHDB или массовый KEYS * в рабочей среде.

Проверка результата

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

1. Дважды создайте ключ из одинакового набора полей. Ключи должны совпасть.
2. Измените только prompt_version. Новый ключ должен отличаться.
3. Верните версию промпта и измените только model_id. Ключ снова должен отличаться.
4. Измените data_version после имитации завершённой индексации. Старый ответ не должен находиться по новому ключу.
5. Измените область доступа. Пользователь с другими правами не должен получить прежнюю запись.
6. Запишите тестовое значение с коротким TTL в изолированном тестовом экземпляре хранилища и убедитесь, что после истечения чтение возвращает промах.

base = {
    "user_query": "Как оформить возврат?",
    "prompt_version": "support-2026-07",
    "model_id": "provider:model-id",
    "generation": {"temperature": 0},
    "data_version": "kb-1842",
    "access_scope": "tenant-7:policy-12",
}

key_a = build_cache_key(**base)
key_b = build_cache_key(**base)
assert key_a == key_b

changed = dict(base)
changed["prompt_version"] = "support-2026-08"
key_c = build_cache_key(**changed)
assert key_c != key_a

В наблюдаемости полезно разделять метрики hit, miss, expired, version_miss и forced_invalidation. Рост доли попаданий сам по себе не доказывает корректность: проверяйте также возраст ответов и распределение используемых версий.

Типовые ошибки

Ключ состоит только из вопроса

Такой кэш не замечает изменения системного промпта, модели и данных. Добавьте явные версии всех влияющих компонентов.

Хешируется итоговая строка промпта без версии

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

Версия базы меняется при каждом документе

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

Права проверяются только при записи

Права могут быть отозваны до истечения TTL. Проверяйте текущую авторизацию при чтении и включайте версию политики или область доступа в ключ.

Случайная генерация кэшируется как стабильный факт

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

Массовая очистка используется для каждого релиза

Она создаёт всплеск одновременных промахов и нагрузки на модель. Версии ключей обеспечивают мгновенное логическое переключение без полной синхронной очистки.

Ограничения

• Версионирование не определяет правильный TTL автоматически: это продуктовое решение, зависящее от риска устаревания.
• Точный кэш не объединяет похожие по смыслу вопросы. Семантический кэш требует отдельных порогов сходства, оценки ошибок и более строгой изоляции данных.
• Изменение поведения поставщика при неизменном алиасе модели останется незаметным, если поставщик не предоставляет фиксируемый идентификатор версии.
• Кэширование ответа не заменяет проверку актуальных прав, политики безопасности и допустимости вывода.
• Версионная инвалидация оставляет старые данные в хранилище до истечения TTL; требования немедленного удаления требуют адресного реестра записей или обратного индекса.
• Для потоковых ответов нужно определить момент записи: обычно кэш сохраняют только после успешного завершения и проверки полного результата.

Короткий рабочий чек-лист

1. Опишите все входы, способные изменить корректный ответ.
2. Включите их версии или хеши в канонический ключ.
3. Изолируйте арендаторов, пользователей и политики доступа.
4. Назначьте TTL по риску устаревания, а не только по стоимости вызова.
5. Повышайте версии после успешной публикации промпта, модели или снимка данных.
6. Предусмотрите адресное удаление для ошибок, отзывов прав и требований удаления данных.
7. Проверьте стабильность ключа и изменение каждого значимого компонента.
8. Наблюдайте не только попадания, но и возраст, версии и причины промахов.

Итог

Надёжный LLM-кэш — это версионированный контракт. Ключ фиксирует запрос, правила, модель, параметры, снимок данных и область доступа; TTL ограничивает последствия пропущенного события; принудительная инвалидация закрывает случаи, когда ждать нельзя. Такая схема сохраняет экономию кэша, не превращая старый ответ в скрытый источник ошибок.

Другие практические материалы доступны в разделе руководств, а определения терминов — в глоссарии.