Семантическое кэширование: когда готовый ответ подходит новому запросу

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

Начните со справочного центра, где информация меняется редко, или с общедоступных ответов на вопросы о продукте. Большой языковой модели (LLM), которая генерирует ответ, незачем заново объяснять одни и те же опубликованные правила при каждой смене формулировки. Данные о балансе счёта, статусе заказа и действия вроде оформления возврата денег оставьте за пределами такого общего кэша.

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

Чем семантическое кэширование отличается от точного кэша и кэширования промптов

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

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

Эти уровни кэширования позволяют экономить на разных операциях:

При точном кэшировании ответов запросы «Можно ли вернуть эти наушники?» и «Подлежат ли эти наушники возврату?» обычно имеют разные ключи. Семантическое кэширование позволяет связать такие переформулировки. Ни один из этих подходов не делает безопасным устаревший ответ или ответ, взятый из неподходящей области доступа.

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

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

Как устроено семантическое кэширование ответов LLM: четыре этапа

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

1. 1

   1. Построить эмбеддинг промпта

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

   «А как насчёт моего?» — неполный ключ кэша. Если для понимания слова «моего» нужны закрытые данные заказа, обойдите общий кэш ответов.

2. 2

   2. Найти соседние векторы

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

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

3. 3

   3. Проверить порог и применимость ответа

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

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

4. 4

   4. Вернуть ответ или вызвать модель

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

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

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

Пример: допустимое попадание и похожий запрос, который должен дать промах

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

В кэше хранятся:

• Вопрос: «Можно ли вернуть наушники в невскрытой упаковке?»
• Ответ: «Да. По правилам этого магазина наушники в невскрытой упаковке подлежат возврату».
• Контекст: текущая версия правил магазина, категория «наушники», английский язык и condition=unopened.

Только для этого примера допустим, что минимальное косинусное сходство равно 0.90. Косинусное сходство сравнивает направления векторов; это не вероятность того, что ответ верен. Оценки ниже вымышлены и нужны, чтобы показать логику решения.

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

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

Какие настройки определяют безопасность повторного использования

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

Порог сходства: калибруйте по ошибочным ответам

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

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

Прежде чем менять порог, разберитесь в метрике. Redis Vector Library (RedisVL) — библиотека для создания приложений с векторным поиском Redis. В её документации distance_threshold задаётся в единицах расстояния Redis COSINE от 0 до 2: чем ниже значение, тем строже отбор. У минимального порога сходства направление обычно обратное. Справочник API RedisVL.

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

Срок жизни: истечение TTL — лишь подстраховка

Время жизни записи, или time to live (TTL), определяет, как долго её разрешено использовать до истечения срока действия. Выбирайте его исходя из того, как долго допустимо выдавать старый ответ, а не из того, как долго кэш способен его хранить.

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

Включите версию источника или правил в проверку применимости. При смене версии старые записи перестанут подходить. RedisVL позволяет задать как TTL по умолчанию, так и индивидуальное значение для записи, но подходящий срок жизни должно выбирать приложение. API кэша RedisVL.

Область доступа пользователя: идентификация требует точного совпадения

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

Для ответа по конкретной учётной записи нужна область доступа, учитывающая аутентифицированного пользователя и его текущие разрешения. Запрос «Когда у меня продление?» не должен запускать поиск среди всех, кто задал такой же вопрос. Получайте идентификационные данные из доверенной системы аутентификации приложения, а не из фразы пользователя или эмбеддинга.

Применяйте фильтры области доступа до выбора кандидата, а перед возвратом ответа проверяйте авторизацию. При изменении прав или удалении данных соответствующий путь повторного использования нужно инвалидировать. Параметры RedisVL filterable_fields и filter_expression дают базовые средства фильтрации, но не определяют вашу политику авторизации автоматически. Параметры фильтрации.

Контекст и версии: сохраняйте условия, на которых основан ответ

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

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

Варианты реализации: шлюз, схема на Redis или библиотека

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

На уровне шлюза: Kong AI Semantic Cache

Kong AI Semantic Cache — плагин в составе предложения Kong AI Gateway Enterprise, который размещает семантический кэш ответов на шлюзе, то есть в точке входа запросов к модели. Документация описывает поиск по эмбеддингам в конфигурациях с Redis или pgvector. В справочнике конфигурации доступны параметры cache_ttl, message_countback и vectordb.threshold.

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

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

Семантический кэш на Redis

Redis — хранилище данных с возможностями векторного поиска, позволяющее приложению управлять поиском и обработкой промахов. Описанный в документации RedisVL класс SemanticCache предоставляет операции check и store, метаданные, фильтры и управление TTL. Документация RedisVL.

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

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

Библиотека GPTCache

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

Это вариант для разработчика, который хочет экспериментировать с поиском и оценкой внутри приложения. Главное ограничение — ответственность за интеграцию: проверьте выбранные адаптеры на совместимость с текущим SDK модели и средой развёртывания. При их использовании по-прежнему нужны проверки области доступа и свежести. Библиотечная абстракция не гарантирует правильность семантического попадания.

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

Как рассчитать экономию на своём потоке запросов

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

Используйте один период измерения и одну валюту. Обозначим через N число запросов, допущенных до семантического слоя после обработки попаданий в точный кэш; через H — число принятых семантических попаданий; через G — стоимость генерации на запрос при упрощающем допущении, что она одинакова для всех запросов; через E — стоимость построения эмбеддинга и поиска на каждый допущенный запрос; через W — стоимость записи в кэш при промахе; через F — фиксированные расходы на инфраструктуру и эксплуатацию за период.

Расчёт выглядит так:

• Без семантического слоя: N × G
• С ним: (N − H) × G + N × E + (N − H) × W + F
• Чистая экономия: H × G − N × E − (N − H) × W − F

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

При этих допущениях условие окупаемости такое:

H > [N × (E + W) + F] / (G + W)

При неоднородной нагрузке замените H × G суммой сэкономленных затрат на генерацию для тех запросов, которые действительно дали попадания. Если часть ответов не допускается в кэш, считайте фактические записи. В соответствующие суммы включайте повторные попытки, вызовы для оценки и работу по эксплуатации. Одна лишь доля попаданий не покажет, окупилось ли повторное использование ответов.

Та же логика применима ко времени ответа. Попадания убирают генерацию из своего пути; промахи добавляют перед ней построение эмбеддинга и поиск. Измеряйте оба пути, включая задержки самых медленных запросов. Если большинство запросов уникальны, обработка в целом может замедлиться, даже когда редкие попадания возвращаются быстро.

Какие ожидания от семантического кэширования завышены?

Близость смысла не гарантирует взаимозаменяемость ответов. Кэш выбирает существующий ответ, но не устанавливает, остаётся ли он правильным, разрешённым для пользователя и актуальным.

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

Кэширование ответов также не заменяет генерацию с дополнением из поиска — retrieval-augmented generation (RAG), при которой модель получает найденные исходные материалы для подготовки ответа. Кэш можно поставить перед этим процессом, но при его обходе не выполняется и новый поиск источников. Привязывайте ответы из кэша к версиям источников либо откажитесь от повторного использования там, где нужны актуальные факты.

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

Кому пора внедрять и с чего начать

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

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

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

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

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

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

Что такое семантическое кэширование?

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

Какие три вида кэширования стоит различать?

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

Как реализовать семантическое кэширование?

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

CDN — это просто кэш?

Нет. Сеть доставки контента (CDN) распределяет доставку по разным географическим точкам; кэширование — один из её механизмов. См. архитектуру CDN от Cloudflare.

Cloudflare — это CDN или WAF?

Cloudflare предоставляет и услуги CDN, и межсетевой экран веб-приложений (WAF), который фильтрует трафик приложений. Ни одно из этих обозначений само по себе не означает семантического кэширования ответов LLM. Архитектура Cloudflare.

Чем CDN отличается от Redis?

CDN доставляет контент через периферийную сеть. Redis — хранилище данных, которое приложение может использовать для кэширования, в том числе в настроенной схеме семантического кэша. Они занимают разные места в системе.

Cloudflare — только CDN?

Нет. В своей эталонной архитектуре Cloudflare также описывает DNS, межсетевой экран и другие сервисы периферийной сети.

Kafka лучше Redis?

Они решают разные задачи. Apache Kafka — платформа для работы с потоками событий. Она не является прямой заменой описанной здесь схемы семантического кэширования ответов на Redis.

Использует ли Netflix Redis?

Да. Redis описывает, как Netflix использует Redis для очередей с приоритетами, и ссылается на публикацию Netflix о Timestone. Этот исторический пример не подтверждает использование семантического кэширования LLM и не служит причиной включать его в вашем приложении.

За практическими заметками о создании надёжных приложений с ИИ подписывайтесь на рассылку.