Что такое семантический кэш ответов LLM

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

Механизм: вектор, порог, выдача

Основу составляет эмбеддинг. В обзоре Redis на redis.io описано, что система переводит текст запроса в вектор — числовое представление смысла, и два вопроса с разными словами, но одним содержанием дают близкие векторы. Дальше идёт поиск по сходству: новый вектор сравнивается с векторами прошлых запросов, хранящимися в векторной базе, и измеряется близость по смыслу. При попадании система возвращает сохранённый ответ сразу, без обращения к модели.

Числовая сторона у Redis такая: эмбеддинги обычно имеют 768 или 1536 измерений, а близость измеряется косинусным сходством. Порог, при превышении которого ответ берётся из кэша, в обзоре указан как 0,85–0,95. Этот ориентир относится к метрике сходства в обзорной статье; документация RedisVL на redis.io прямо говорит, что подходящий порог семантического сходства не является фиксированной величиной и зависит от модели эмбеддингов, свойств входного запроса и бизнес-задачи.

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

Полезно развести три вещи, которые часто путают. Точный кэш сопоставляет ключи. В приложении ключ должен учитывать все значимые части запроса и контекста. Семантический кэш сопоставляет смысл и работает на перефразировках. Кэширование префиксов промпта и KV-кэш ускоряют обработку одного и того же длинного контекста внутри модели. Это разные слои, и семантический кэш принимает решение перед вызовом модели.

Проверьте направление шкалы API. В Azure API Management параметр score-threshold работает как порог расстояния: меньшее значение требует большего сходства, а значения выше порога не используют кэш. Это отличается от условной шкалы сходства в нашем журнале, где больше означает ближе. Числа между такими шкалами напрямую не переносятся.

Практический вывод для читателя: семантический кэш отвечает на вопрос «задавали ли уже похожий вопрос», и не отвечает на вопрос «верен ли сохранённый ответ сейчас». Второй вопрос закрывает политика.

Учебный вход: запись, запросы, эталон проверки

Возьмём учебную запись. Значения заданы для разбора. Редакция кэш не запускала.

Запись C1
tenant: school-A
lang: ru
version: v1
вопрос: «Когда открыта лаборатория?»
ответ: «Пн–Пт 09–18, документ L1»

К этой записи приходят четыре запроса. Q1 «В какие часы работает лаборатория?» имеет те же атрибуты: тот же tenant, тот же язык, та же версия. Q2 «Подскажите часы работы лаборатории» приходит от school-B. Q3 «В какое время работает лаборатория?» приходит с version=v2. Формулировки различаются; скоры ниже заданы условно для проверки политики. Q4 спрашивает «Открыта ли лаборатория в праздник?».

Учебный журнал выглядит так. Условные скоры сходства: Q1 — 0,96, Q2 — 0,99, Q3 — 0,98, Q4 — 0,95. Условный порог — 0,9. Все четыре запроса проходят числовой порог. Скоры придуманы для разбора, значение 0,9 не является универсальной рекомендацией, а большее значение означает большее сходство.

Дальше работает политика. Q2 отклоняется по tenant: ответ school-A не выдаётся пользователю school-B. Q3 отклоняется по версии: запись сделана для v1, а запрос идёт к v2. Q4 требует нового ответа, потому что старый ответ не покрывает календарный контекст праздника. Q1 остаётся кандидатом: свежесть ещё нужно проверить, поскольку время записи, TTL и состояние L1 во входе не заданы.

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

Обратите внимание на Q2: у него самый высокий скор в журнале, и он отклонён. Это и есть главный урок примера. Числовая близость отвечает за похожесть формулировки, а решение о выдаче принимает политика по атрибутам.

Структурная корректность и фактическая правильность

Это два разных свойства, и их полезно проверять отдельно.

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

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

Разведём это на учебном журнале. У Q1 совпали заданные атрибуты и пройден условный порог. Утверждать свежесть записи по этим данным нельзя. Если документ L1 устарел, ответ останется структурно корректным и фактически неверным. Q2 структурно корректен по всем числовым шагам, и политика его отклоняет — здесь структурная проверка сработала как защита. Q4 структурно корректен, и политика отправляет его за новым ответом, потому что календарный контекст не покрыт.

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

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

Первоисточники: что подтверждено и где границы

Внешние утверждения в этой статье опираются на конкретные документы, и каждый относится к своему продукту.

Документация Microsoft Learn по Azure API Management описывает включение семантического кэширования для LLM API: кэш возвращает ответы как на идентичные промпты, так и на промпты, близкие по смыслу, даже когда текст различается. Там же указан порядок настройки: добавить развёртывания моделей Azure OpenAI как API, создать развёртывания для Chat Completion API и Embeddings API, настроить управляемую идентификацию, подготовить экземпляр Azure Managed Redis с включённым модулем RediSearch и подключить его как внешний кэш. Документация отдельно отмечает, что модуль RediSearch включается только при создании нового кэша Azure Managed Redis, а добавить модуль в существующий кэш нельзя. Эти шаги относятся к Azure API Management и не переносятся на другие продукты.

Обзор Redis на redis.io описывает мотивацию: значительная часть расходов на LLM API приходит от повторяющихся запросов, которые пользователи задают разными словами, и традиционный кэш здесь не помогает, потому что сопоставляет точные строки. Тот же обзор приводит механику с эмбеддингами, косинусным сходством и порогом 0,85–0,95.

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

Проект GPTCache на GitHub и его документация на gptcache.readthedocs.io описывают библиотеку семантического кэша для хранения ответов LLM. Оба ресурса предупреждают, что проект находится в активной разработке и API может меняться; в README также сказано, что поддержка новых API и моделей не добавляется, а вместо этого предлагается использовать методы get и set. Там же даны примеры точного и похожего сопоставления и указано, что переменная окружения с ключом задаётся через export в Unix-подобных системах или set в Windows.

Границы здесь важны. Версии, порты, лимиты и настройки каждого продукта относятся только к нему. Модуль RediSearch — деталь Azure Managed Redis. Класс SemanticCache — деталь RedisVL. Методы get и set — деталь GPTCache. Переносить их между продуктами нельзя.

Случай, где подход не решает задачу

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

Учебный запрос Q4 «Открыта ли лаборатория в праздник?» близок по вектору к записи C1: те же слова про лабораторию и открытость, скор 0,95, порог пройден. Ответ «Пн–Пт 09–18» не подтверждает работу в конкретный праздник. Праздничный график может отличаться; во входе такого календаря нет. Нужен актуальный источник, а при его отсутствии — признание недостатка данных. Кэш не знает календаря, если календарь не входит в атрибуты записи.

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

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

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

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

Как спроектировать политику допуска

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

1. Определите, какие вопросы в вашем приложении повторяются по смыслу. Выпишите несколько пар перефразировок.
2. Перечислите атрибуты, от которых зависит правильный ответ: область пользователя, язык, версия документа, срок жизни записи, контекст даты.
3. Выберите модель эмбеддингов и хранилище векторов. Документация RedisVL показывает вариант с Redis и классом SemanticCache, документация Azure — вариант с Azure Managed Redis и модулем RediSearch, проект GPTCache — вариант с библиотекой и методами get и set.
4. Задайте порог сходства как стартовое значение и проверьте его на своих парах. Документация RedisVL указывает, что порог зависит от модели, запроса и задачи, поэтому значение подбирают на собственных проверочных данных.
5. Настройте политику допуска по атрибутам: сравнение области, языка, версии, срока жизни.
6. Заведите журнал с полями скора, области, свежести, решения и основания.
7. Прогоните учебный набор вроде Q1–Q4 и убедитесь, что Q2 и Q3 отклоняются по атрибутам, а Q4 уходит за новым ответом.

Отличие от соседних тем. Эта статья про кэш готовых ответов на похожие запросы. Кэширование префиксов промпта и KV-кэш — отдельный слой внутри обработки модели, у него другая механика и другие метрики. Точный кэш — тоже отдельная тема: он сопоставляет строки и не требует эмбеддингов. Смешивать эти три механизма в одной настройке не стоит, потому что у них разные ключи и разные причины промахов.

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

Ты помогаешь спроектировать семантический кэш ответов для приложения.

Контекст:
- приложение: [ваша тема]
- пример вопроса пользователя: [ваш пример вопроса]
- сохранённый ответ: [ваш сохранённый ответ]
- атрибуты записи: [ваша область, язык, версия, срок жизни]

Сделай следующее:
1. Перечисли условия, от которых зависит правильность сохранённого ответа.
2. Отметь условия, которые не входят в перечисленные атрибуты.
3. Для каждого такого условия предложи, как проверять его перед выдачей из кэша.
4. Приведи три перефразировки исходного вопроса, которые пройдут по смыслу, и одну, которая пройдёт по смыслу и потребует другого ответа.
5. Верни таблицу: условие, входит ли в атрибуты, действие перед выдачей.

Меняйте под себя тему приложения, пример вопроса, сохранённый ответ и список атрибутов. Вариации той же задачи: разбор журнала кэша за неделю и поиск записей с высоким скором и отклонённым решением; проверка пары «вопрос — ответ» на зависимость от даты; составление списка атрибутов для нового домена; ревизия порога сходства на своих перефразировках; подготовка набора Q1–Q4 для своего продукта.

Частые вопросы

Что такое semantic caching простыми словами?

Это хранение готовых ответов и поиск их по смыслу вопроса. Система переводит запрос в вектор, сравнивает с векторами прошлых запросов и при достаточном сходстве отдаёт сохранённый ответ без вызова модели. Точный кэш для этого не подходит, потому что сопоставляет строки. Обзор Redis на redis.io описывает это на примере вопросов про возврат товара, заданных разными словами.

Как работает semantic caching в Python?

Библиотека GPTCache на GitHub и её документация на gptcache.readthedocs.io описывают семантический кэш для хранения ответов LLM. Документация RedisVL на redis.io показывает класс SemanticCache: сохранение вопроса, ответа и метаданных, политики TTL и фильтрацию записей по настраиваемым полям. Способ передачи ключей и версия API зависят от выбранной интеграции. Предупреждение об активной разработке относится к GPTCache; автоматически переносить его на RedisVL нельзя.

Какой порог сходства выбрать для semantic caching?

Документация RedisVL на redis.io указывает, что подходящий порог не является фиксированной величиной и зависит от модели эмбеддингов, свойств запроса и бизнес-задачи. Обзор Redis на redis.io приводит ориентир 0,85–0,95. Начинайте со стартового значения и проверяйте его на своих парах перефразировок. Порог из чужого продукта не переносится.

Почему semantic caching в RAG может выдать неверный ответ?

Ответ зависит от условий, которых нет в ключе кэша: версии документа, даты, области пользователя. В учебном примере запрос про праздник проходит по скору 0,95, но старый ответ про будние дни не подтверждает праздничный график. Документация RedisVL на redis.io предлагает тегировать записи через filterable_fields, чтобы разделять данные разных пользователей. Условия, не попавшие в атрибуты, требуют проверки перед выдачей.

Чем semantic caching layer отличается от кэша префиксов промпта?

Семантический слой стоит над вызовом модели и решает, нужен ли вызов вообще, сопоставляя смысл запроса. Кэш префиксов промпта и KV-кэш работают внутри обработки модели и ускоряют повторную обработку одного и того же контекста. У них разные ключи и разные причины промахов. Документация Azure API Management описывает семантический кэш как отдельную настройку поверх API.