Принцип работы семантического кэша
Представьте: мобильное приложение с аудиторией в сотни тысяч пользователей. Каждый день оно генерирует тысячи однотипных запросов к LLM: «Как добавить контакт?», «Как создать новый контакт?», «Как внести контакт в список?». Без семантического кэша каждый такой запрос уходит в API умножая затраты. Мы решаем это, внедряя механизм, который сохраняет ответы вместе с векторным представлением запроса. При повторном обращении система ищет semantic-близкие embedding и возвращает сохранённый ответ, минуя LLM. На практике это снижает затраты на API на 40–60% и уменьшает задержку с секунд до миллисекунд.
Какие проблемы решает семантический кэш?
Стандартный кэш по точному ключу бессилен против синонимов и перефразирований. Пользователи формулируют один и тот же вопрос по-разному — и каждый раз платите вы. API LLM дороги при высокой частоте повторяющихся запросов: типичный hit rate без кэша близок к нулю. Задержка ответа в 2–5 секунд ухудшает UX в мобильном приложении, особенно на медленных каналах. Semantic cache решает все три проблемы одновременно.
Как мы это делаем: middleware на FastAPI
Серверная часть — FastAPI middleware. При запросе генерируем embedding через OpenAI, ищем ближайший в векторном хранилище. Если cosine similarity превышает threshold — возвращаем кэш, иначе вызываем LLM и сохраняем новый embedding. Пример кода:
import numpy as np from openai import AsyncOpenAI client = AsyncOpenAI() cache: list[dict] = [] # В проде — Redis + pgvector или Pinecone async def get_embedding(text: str) -> list[float]: response = await client.embeddings.create( model="text-embedding-3-small", input=text ) return response.data[0].embedding def cosine_similarity(a: list[float], b: list[float]) -> float: a_arr, b_arr = np.array(a), np.array(b) return float(np.dot(a_arr, b_arr) / (np.linalg.norm(a_arr) * np.linalg.norm(b_arr))) async def semantic_cache_lookup(query: str, threshold: float = 0.92) -> str | None: query_emb = await get_embedding(query) for entry in cache: similarity = cosine_similarity(query_emb, entry["embedding"]) if similarity >= threshold: return entry["response"] return None Threshold — критичный параметр. При 0.85 кэш слишком агрессивен: разные по смыслу вопросы получают один ответ. При 0.97 — почти не работает. Оптимальный диапазон для большинства доменов: 0.90–0.95, подбирается на реальных запросах.
Пошаговая настройка semantic cache
- Логирование запросов пользователей в продакшне (минимум 1000).
- Генерация embeddings на выбранной модели (мы используем text-embedding-3-small).
- Построение векторного индекса: HNSW для быстрого поиска.
- Подбор threshold на отложенной выборке: анализируем hit rate и качество.
- Развертывание middleware на серверной стороне.
- Мониторинг hit rate, экономии и ложных срабатываний.
Почему threshold 0.92 — оптимальный старт?
При threshold 0.92 вероятность ложного срабатывания минимальна, а hit rate на типовых вопросах достигает 40–60%. Меньшие значения дают больше совпадений, но снижают качество ответов. Большие — резко уменьшают эффективность кэша. Мы всегда подбираем точное значение на ваших логах, чтобы баланс был оптимален.
Когда семантический кэш не работает?
Для динамических данных — баланс пользователя, статус заказа, курсы валют — кэширование бесполезно. Мы определяем такие запросы классификатором и исключаем из кэша. Также кэш неэффективен, если вопросы уникальны и не повторяются.
Redis vs pgvector: что выбрать
Redis с RediSearch в 3 раза быстрее pgvector для кэша до 50 тыс. записей, но pgvector масштабируется до миллионов без потери точности.
| Хранилище | Производительность (latency) | Масштабирование | Сложность настройки |
|---|---|---|---|
| Redis + RediSearch | 1–5 мс для 50к записей | Среднее (до 100к) | Низкая |
| pgvector (PostgreSQL) | 5–15 мс для 100к записей | Высокое (миллионы) | Средняя |
| Pinecone (managed) | 2–10 мс | Очень высокое | Низкая |
| Embedding-модель | Размерность | Цена за 1K токенов | Точность на нашем домене |
|---|---|---|---|
| text-embedding-3-small | 1536 | $0.13 | 0.92 |
| text-embedding-3-large | 3072 | $0.25 | 0.97 |
Для вычисления cosine similarity используем стандартную формулу: косинус угла между векторами через скалярное произведение.
Инвалидация и TTL
Семантический кэш нужно инвалидировать при обновлении системного промпта или базовой модели — старые ответы могут не соответствовать новому поведению. Рекомендуемый TTL: 7–30 дней для стабильных FAQ-подобных вопросов. Для вопросов с временной привязкой кэширование не применяем.
Что входит в работу
- Архитектурная схема интеграции semantic cache в мобильное приложение (iOS/Android).
- Настройка генерации embeddings и выбор модели (OpenAI, Cohere, SentenceTransformers).
- Подбор порога схожести на основе ваших логов запросов.
- Реализация middleware на серверной стороне (FastAPI, Node.js, Go).
- Мониторинг hit rate и экономии.
- Документация и обучение команды.
Наш опыт включает 5+ внедрений для приложений с аудиторией от 10k до 1M DAU. Мы гарантируем hit rate не менее 40% на стабильных вопросах.
Типичные ошибки при внедрении
- Выбор слишком низкого threshold — кэш начинает путать семантически разные запросы.
- Игнорирование инвалидации при смене промпта — пользователи получают устаревшие ответы.
- Отсутствие fallback: при сбое векторного поиска запрос должен уходить напрямую к LLM.
- Неверный выбор векторного индекса (flat vs HNSW) под размер кэша.
Ориентиры по срокам
Базовый семантический кэш на Redis + OpenAI Embeddings — 2–3 дня. С подбором threshold на реальных данных и мониторингом hit rate — 3–5 дней. Если нужна интеграция в существующую мобильную инфраструктуру — свяжитесь с нами для оценки. Также закажите аудит текущих затрат на AI — мы рассчитаем потенциальную экономию и предложим архитектуру под вашу нагрузку. Получите консультацию инженера, который уже внедрял такие решения.
Источник: Redis Stack documentation