ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать cost-aware caching для дорогих ответов GPT-4

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

Научиться проектировать и внедрять кэш, который избирательно сохраняет ответы LLM только в тех случаях, когда затраты на их генерацию высоки и вероятность повторного запроса оправдывает хранение. Это позволяет снизить расходы на GPT-4, не усложняя архитектуру для дешёвых (коротких) запросов.

Ключевой результат Система, кэширующая ответы GPT-4 при стоимости генерации > $0.01 и с вероятностью повторного запроса > 30%, обеспечивает снижение общих затрат на 30% при сохранении качества ответов (средняя оценка пользователей не ниже baseline’а).

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

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

1. Напишите симулятор генерации ответов GPT-4: случайная длительность, случайная стоимость на основе количества токенов (например, $0.03 за 1K input + $0.06 за 1K output).
2. Сгенерируйте 10 000 синтетических запросов с повторяющимися паттернами (например, 20% запросов повторяется идентично, 30% с небольшими вариациями).
3. Разверните Redis в Docker (docker run -p 6379:6379 redis:7-alpine).
4. Напишите простой HTTP-прокси на FastAPI, который перенаправляет запросы в симулятор и вставляет кэш.

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

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

Этап 1: Анализ логов и профилирование стоимости (30 минут)

Действия

1. Собрать логи реальных запросов (или использовать сгенерированные). Убедиться, что каждая запись содержит:
   timestamp, prompt_hash (MD5/SHA256), response, cost, model, tokens_total.

2. Построить распределение стоимости запросов (Pandas):

   import pandas as pd
   import matplotlib.pyplot as plt
   
   df = pd.read_csv('logs.csv')
   df['cost'].hist(bins=50)
   plt.axvline(x=0.01, color='red', linestyle='--')  # порог
   

3. Определить порог дорогого запроса: например, 90-й перцентиль стоимости.

4. Оценить повторяемость запросов: посчитать долю повторных prompt_hash в выборке.

Ожидаемый результат этапа Понимание распределения стоимости, выбор начального порога cost_threshold (например, $0.02).

Этап 2: Разработка cost-aware прокси с кэшем (1.5 часа)

Действия

1. Создать FastAPI приложение с эндпоинтом /v1/chat/completions (прокси).

2. Реализовать cost_estimator: функция, которая по prompt предсказывает стоимость ответа (например, используя количество токенов из симулятора или быстрый расчёт по tiktoken).

   def estimate_cost(prompt: str) -> float:
       # приблизительная стоимость GPT-4: $0.03/1K input + $0.06/1K output
       input_tokens = len(tiktoken.encode(prompt))
       # прогнозируем output в 2x от input (грубо)
       return (input_tokens / 1000) * 0.03 + (2*input_tokens / 1000) * 0.06
   

3. Реализовать cost_aware_cache:

   • Ключ кэша: sha256(prompt + model).
   • Если оценка стоимости < cost_threshold — пропустить кэш (дешёвые запросы не кэшируем).
   • Если выше — проверить Redis: если ключ есть и не истёк, вернуть.
   • Если нет — запросить LLM, сохранить ответ в Redis с TTL (например, 1 час) и вернуть.

4. Добавить middleware логирования: записывать в Prometheus гистограммы cost_saved, cache_hit, latency.

Ожидаемый результат этапа Работающий прокси, который кэширует только дорогие запросы.

Этап 3: Настройка Redis и политики вытеснения (30 минут)

Действия

1. Установить maxmemory в Redis (например, 1GB) и политику вытеснения allkeys-lru (только дорогие ответы будут вытесняться по LRU).

   docker run ... redis:7-alpine redis-server --maxmemory 1gb --maxmemory-policy allkeys-lru
   

2. Настроить TTL для каждой записи динамически: чем дороже запрос, тем дольше хранить (например, TTL = cost * 10000 секунд, но не более 7 дней).

3. Проверить, что Redis не переполняется, мониторинг через INFO memory.

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

Этап 4: Измерение эффекта и A/B тестирование (1 час)

Действия

1. Запустить прокси на тестовом трафике (или симуляции) в течение 1 часа без кэша (baseline). Зафиксировать среднюю стоимость запроса, latency, количество вызовов.

2. Включить cost-aware кэш (с выбранными порогами). Прогнать тот же набор запросов (или повторить симуляцию с теми же seed’ами).

3. Собрать метрики:

   • total_cost_saved = (общая стоимость baseline) - (общая стоимость с кэшем)
   • cache_hit_rate_dollar = доля стоимости, которую удалось сэкономить (вес по cost)
   • latency_p95

4. Провести статистический тест (t-test) на независимых выборках, чтобы убедиться, что разница cost значима (p-value < 0.05).

Ожидаемый результат этапа Численные доказательства снижения cost на ≥ 30% без существенного роста latency.

Этап 5: Оптимизация порогов и финальная настройка (30 минут)

Действия

1. Построить кривую sensitivity: для разных cost_threshold от 0.001 до 0.1 посчитать hit_rate и cost_reduction.

2. Выбрать компромисс: например, порог $0.015 даёт 32% экономии при hit rate 22%.

3. Добавить защиту от кэширования чувствительных данных (например, если prompt содержит PII — не кэшировать).

4. Зафиксировать конфигурацию в YAML:

   cache:
     enabled: true
     cost_threshold: 0.015   # $0.015
     min_repeat_probability: 0.3  # 30% – определять по истории
     ttl_base_seconds: 3600
     redis: "redis://localhost:6379/0"
   

Ожидаемый результат этапа Финальная конфигурация, дающая target 30% cost reduction.

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

• Снижение общих затрат на LLM-запросы не менее чем на 30% (измерено на тестовом наборе из 10 000 запросов).
• Доля попаданий в кэш (hit rate) по запросам, дороже порога, составляет не менее 20%.
• Средняя латентность ответа увеличилась не более чем на 100 мс (p95 не более +200 мс).
• Кэш не сохраняет запросы дешевле порога (cost_threshold), проверено юнит-тестом.
• Redis не переполняется: maximum memory не превышена ни разу за 2 часа теста.
• Написаны юнит-тесты для cost_estimator и кэширующей логики (покрытие > 80%).
• Реализован мониторинг: метрики cost_saved, cache_hit, latency выгружаются в Prometheus/Grafana (или CSV для анализа).
• Проведён A/B тест (t-test) со статистической значимостью p < 0.05.
• Документация: README с описанием архитектуры, инструкцией по запуску и настройке порога.

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

Основной артефакт Python-пакет (директория cost_aware_cache/) со следующими файлами:

• proxy.py — FastAPI приложение-прокси.
• cache.py — логика cost-aware кэша.
• cost_estimator.py — оценка стоимости запроса.
• redis_client.py — настройка Redis.
• config.yaml — финальная конфигурация.
• test/unit/ — юнит-тесты.
• notebooks/analysis.ipynb — Jupyter notebook с анализом логов, выбором порога, A/B тестированием.
• prometheus.yml — пример конфигурации для сбора метрик.

Дополнительные артефакты

• Отчёт о A/B тесте (PDF или markdown) с графиками распределения стоимости и метриками эффекта.
• Дашборд Grafana (если используете) с панелями «Cost saved», «Cache hit rate by cost bucket», «Latency».

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

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

Примечание Для первого раза заложите 6 часов (включая разворачивание окружения и написание симулятора). Время может увеличиться, если вы впервые работаете с Redis или FastAPI.

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

В таблице приведены реальные номера вопросов (из диапазона 1–900) по смежным темам.

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

• Я развернул Redis в Docker и убедился, что прокси подключается к нему.
• Я написал симулятор, который генерирует стоимость ответа случайно, но с тяжёлым хвостом.
• Я построил гистограмму стоимости и выбрал осмысленный порог (не меньше 25-го перцентиля).
• В моём кэше ключ – хэш prompt + model, а TLL разный для запросов разной стоимости.
• Я запустил A/B тест (baseline vs with cache) и получил p-value < 0.05.
• Я проверил, что latency p95 не превысила лимит +200 мс.
• Я написал хотя бы один юнит-тест для функции should_cache(cost, repeat_prob).
• Финальная конфигурация лежит в config.yaml и используется при запуске.
• В README описаны шаги для воспроизведения (установка зависимостей, запуск симуляции).