ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить TTL для semantic cache

1. Цель задачи

Реализовать семантический кэш ответов LLM, в котором время жизни (TTL) кэш-записи зависит от “горячности” запроса: для часто встречающихся (hot topics) TTL = 1 минута, для редких — 1 час. Настроить механизм определения популярности, хранить кэш с разными TTL и добиться hit rate ≥ 40% на тестовом наборе запросов.

Ключевой результат Рабочий прототип semantic cache с динамическим TTL, достигающий hit rate 40% на заданном датасете.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Вместо Redis используем Python-словарь с флагами expires_at для каждого ключа (семантический ключ — нормализованный эмбеддинг запроса).
2. Для генерации запросов пишем скрипт, который создаёт список из 1000 запросов: 200 уникальных “горячих” (каждый повторён 10 раз) и 800 уникальных “редких” (каждый встречается 1–2 раза).
3. Вычисление семантической близости: cosine similarity через numpy.

3. Технологический стек

4. Этапы выполнения

Этап 1: Проектирование архитектуры semantic cache с динамическим TTL (30 мин)

Действия

1. Определить структуру кэш-записи: {key: (embedding_vector, answer, expires_at, is_hot)}, где ключ — строка запроса.
2. Разработать алгоритм определения “горячности” на основе частоты обращений за последние N запросов (скользящее окно размером 200).
3. Спроектировать функцию get(query) → answer_or_none: вычисляется эмбеддинг запроса → ищется ближайший по cosine similarity (>0.9) среди кэшированных → если найден и не истёк TTL → возвращается ответ; иначе None.
4. Спроектировать функцию put(query, answer): вычисляется эмбеддинг, определяется is_hot по частоте, назначается TTL (1 мин для hot, 1 час для rare), сохраняется.

Ожидаемый результат этапа Документированная схема (псевдокод + диаграмма) функций get и put.

Этап 2: Реализация базового кэша (2 часа)

Действия

1. Загрузить embedding-модель: model = SentenceTransformer('all-MiniLM-L6-v2').
2. Реализовать класс SemanticCache:
   • __init__: инициализировать пустой словарь self.store, счётчик self.hit_ratio.
   • _embed(text) → np.ndarray: нормализованный эмбеддинг (L2-normalize).
   • _nearest(embedding, threshold=0.9) → (key, similarity): проход по self.store, поиск по cosine similarity.
   • _compute_hot_flag(query): хранить self.query_history (deque длины 200) последних уникальных запросов; если частота текущего query в истории > порога (например, >3), считать hot.
   • get(query): проверить кэш, если попадание → увеличить hit_count, вернуть answer, иначе None.
   • put(query, answer): сохранить с соответствующим TTL.
3. Написать вспомогательный скрипт generate_dataset.py для создания 1000 запросов с распределением 20% hot / 80% rare.

Ожидаемый результат этапа Работающий класс SemanticCache с методами get и put, протестированный на 10–20 запросах.

Этап 3: Настройка TTL и мониторинг hit rate (1 час)

Действия

1. Интегрировать таймер: в put записывать expires_at = time.time() + (60 if is_hot else 3600).
2. В get проверять time.time() < expires_at; иначе удалять запись.
3. Реализовать цикл эмуляции:
   • Прогнать все 1000 запросов последовательно.
   • На каждом запросе: get, если промах → put (имитируем получение ответа от LLM).
   • Собирать статистику: количество hit, miss, текущий hit rate каждые 100 запросов.
4. Вывести итоговый hit rate.

Ожидаемый результат этапа Hit rate вычислен; если <40% — переходим к этапу 4.

Этап 4: Оптимизация для достижения hit rate ≥ 40% (1–2 часа)

Действия

1. Проанализировать причины низкого hit rate:
   • Слишком высокий порог similarity? (уменьшить до 0.85)
   • Слишком узкое окно для определения hot? (расширить до 500)
   • Hot-запросы получают короткий TTL и быстро вытесняются, хотя должны оставаться? (увеличить TTL для hot до 2 минут)
2. Внести изменения:
   • Поэкспериментировать с порогом similarity (0.80–0.95).
   • Изменить размер окна (100, 200, 500).
   • Добавить механизм “renewal”: при попадании по hot-запросу обновлять TTL ещё на 1 минуту.
3. Повторно прогнать эмуляцию и замерить hit rate.
4. Зафиксировать оптимальные параметры в конфигурационном файле (YAML).

Ожидаемый результат этапа Hit rate ≥ 40% на тестовом наборе.

Этап 5: Тестирование и документирование (30 мин)

Действия

1. Написать pytest-тесты:
   • Проверка, что hot-запрос имеет TTL 1 мин, редкий — 1 час.
   • Проверка, что кэш возвращает None после истечения TTL.
   • Проверка, что hit rate на сгенерированном наборе ≥ 40% (с заданными параметрами).
   • Проверка, что при одинаковых запросах возвращается один и тот же ответ.
2. Написать README с описанием алгоритма, параметров и результатов.
3. Оформить код в виде модуля semantic_cache.py с точкой входа main.py для запуска эмуляции.

Ожидаемый результат этапа Набор тестов (зелёные) и README.

5. Критерии приемки (Definition of Done)

• Реализован класс SemanticCache с методами get и put, поддерживающий разные TTL для hot и rare запросов.
• TTL для hot-запросов равен 1 минуте, для rare — 1 час (допустимо ±5%).
• Определение “горячности” основано на частоте запросов за скользящее окно (размер конфигурируемый).
• Запуск эмуляции на тестовом наборе (1000 запросов) даёт hit rate ≥ 40%.
• Все unit-тесты проходят успешно (минимум 4 теста).
• Код покрыт комментариями и имеет README с инструкцией по запуску.
• Зависимости перечислены в requirements.txt (или pyproject.toml).
• Решение не использует внешние API (кроме загрузки модели) — полностью воспроизводимо офлайн.
• В коде обработаны краевые случаи: пустой запрос, нулевой TTL, переполнение кэша (можно ограничить размер).

6. Ожидаемый результат

• Главный артефакт Папка semantic_cache_ttl/ с файлами:
  • semantic_cache.py — реализация кэша.
  • generate_dataset.py — генератор тестового набора.
  • main.py — эмуляция и замер hit rate.
  • test_cache.py — unit-тесты.
  • requirements.txt — зависимости.
  • README.md — описание, параметры, результаты.
• Дополнительно Датасет queries.json (1000 запросов с метками hot/rare) и файл конфигурации config.yaml с оптимальными параметрами.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: Для первого выполнения может потребоваться до 7 часов из-за отладки.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я реализовал класс SemanticCache с методами get и put, которые корректно обрабатывают TTL.
• В моём решении TTL для hot-запросов составляет 1 минуту, для rare — 1 час (проверено юнит-тестом).
• Алгоритм определения hot-запросов использует скользящее окно (или экспоненциальный счётчик) и даёт разумные результаты на сгенерированных данных.
• Я запустил эмуляцию на 1000 запросов и получил hit rate ≥ 40%.
• Все unit-тесты проходят, код покрыт комментариями на русском/английском, README содержит инструкцию по запуску.