ТЕХНИЧЕСКОЕ ЗАДАНИЕ: RAG с cost-aware routing

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

Разработать систему интеллектуального роутинга запросов в RAG-пайплайне, которая направляет простые запросы на быстрый и дешёвый LLM (Groq), а сложные — на мощный, но дорогой (GPT-4). Цель — снизить среднюю стоимость одного запроса не менее чем на 50% по сравнению с использованием только GPT-4, сохранив качество ответов на приемлемом уровне (оценка пользователей не хуже 4 из 5).

Ключевой результат Рабочий прототип RAG-системы с cost-aware роутингом, метрики затрат и качества собранные за неделю тестирования.

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

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

1. Для Groq используем groq Python SDK (бесплатная квота)
2. Для GPT-4 — OpenAI API (paid, но можно тестировать на small датасете)
3. Корпус знаний — скачать Markdown-документацию из открытого репозитория (например, LangChain docs)
4. Метрики cost рассчитываем как стоимость токенов * тариф
5. Для замера качества используем оценку ответа GPT-4 (LLM-as-a-judge) на выборке 100 запросов

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

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

Этап 1: Сбор и разметка датасета запросов (2–3 часа)

Действия

1. Собрать или сгенерировать 500–1000 вопросов, релевантных корпусу документов.
2. Вручную или с помощью GPT-4 mini разметить каждый вопрос как simple (0) или complex (1):
   • Простой: фактологический ответ, короткий (до 3 предложений), чёткий контекст.
   • Сложный: требует анализа, сравнения, многошагового рассуждения, ответ > 3 предложений.
3. Сохранить датасет в CSV: query, label, difficulty_score (0–1).
4. Разделить на train (70%), validation (15%), test (15%).

Ожидаемый результат этапа Файл queries_labeled.csv с размеченными запросами.

Этап 2: Разработка классификатора сложности (2–3 часа)

Действия

1. Вычислить эмбеддинги всех запросов (через text-embedding-3-small или MiniLM).
2. Обучить логистическую регрессию на train + val для предсказания label по эмбеддингам.
3. Оценить точность (accuracy ≥ 85%) и F1-score на тесте.
4. Если точность низкая — добавить дополнительные признаки:
   • длина запроса (количество символов/токенов)
   • количество вопросительных слов
   • наличие специфических паттернов («сравните», «объясните», «почему»)
5. Экспортировать модель в sklearn pickle для использования в рантайме.

# Пример обучения классификатора
from sklearn.linear_model import LogisticRegression
from sentence_transformers import SentenceTransformer

encoder = SentenceTransformer('all-MiniLM-L6-v2')
X_train = encoder.encode(train_queries.tolist())
clf = LogisticRegression(max_iter=1000)
clf.fit(X_train, train_labels)

Ожидаемый результат этапа Файл complexity_classifier.pkl и метрики качества.

Этап 3: Интеграция роутинга в RAG-пайплайн (3–4 часа)

Действия

1. Реализовать базовый RAG: загрузить документы → нарезать на чанки (500 токенов, overlap 50) → индексировать в Chroma.
2. Написать функцию route_query(query) -> str:
   • Получить эмбеддинг запроса.
   • Предсказать метку.
   • Если label == 0 → использовать Groq (mixtral-8x7b), label == 1 → GPT-4.
3. Создать единый интерфейс generate_answer(query, context):
   • Найти топ-5 чанков по косинусной близости.
   • Сформировать промпт с контекстом.
   • Отправить в выбранный LLM.
4. Реализовать логирование: query, routed_to, prompt_tokens, completion_tokens, cost, latency.
5. Написать скрипт для пакетного прогона test-датасета через пайплайн.

Ожидаемый результат этапа Работающий роутинг в RAG, файл cost_log.csv за 50 запросов.

Этап 4: Оценка cost и качества (2–3 часа)

Действия

1. Прогнать test-датасет (100 запросов) через роутинг и отдельно только через GPT-4 (baseline).
2. Собрать метрики:
   • Стоимость — суммарная цена токенов (использовать прайсинг: Groq ~$0.27/1M in, $0.79/1M out; GPT-4-turbo ~$10/1M in, $30/1M out).
   • Медианная задержка (latency).
   • Качество — с помощью LLM-as-a-judge: попросить GPT-4 оценить ответы по шкале 1–5 (относительно baseline). Рассчитать среднюю оценку.
3. Вычислить процент снижения cost: (cost_baseline - cost_routed) / cost_baseline * 100.
4. Построить график зависимости cost vs качество (scatter plot).

Ожидаемый результат этапа Отчёт в виде Jupyter Notebook с цифрами и выводами.

Этап 5: Оптимизация и итерация (2–3 часа)

Действия

1. Проанализировать ошибки классификации (запросы, которые роутер отправил не туда).
2. Попробовать улучшить классификатор:
   • Добавить порог уверенности (если вероятность < 0.6 → отправлять на GPT-4).
   • Использовать ансамбль (LogReg + правило длины).
3. Оценить влияние на cost при пороге confidence_threshold = 0.5, 0.6, 0.7.
4. Выбрать оптимальный порог по метрике cost / avg_quality.
5. Зафиксировать финальную конфигурацию в config.yaml.

Ожидаемый результат этапа Финальная конфигурация роутинга, итоговые метрики (cost -50%, quality ≥ 4.5).

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

• Датасет размечен и разделен на train/val/test.
• Классификатор обучен и показывает accuracy ≥ 85% на тесте.
• RAG-пайплайн с роутингом запускается одной командой.
• Собран CSV-лог стоимости для 100 запросов.
• Снижение среднего cost ≥ 50% относительно baseline (только GPT-4).
• Средняя оценка качества ответов (LLM-as-a-judge) ≥ 4.0 из 5.
• Написан Jupyter Notebook с анализом результатов (графики, таблицы).
• Код выложен в репозиторий с README (инструкция по запуску).

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

Основной артефакт Папка проекта rag_cost_routing/ с:

• complexity_classifier.pkl — обученный классификатор.
• rag_pipeline.py — скрипт с функциями роутинга.
• queries_labeled.csv — размеченные запросы.
• cost_log.csv — логи стоимости.
• analysis.ipynb — Jupyter Notebook с метриками и выводами.

Опционально

• config.yaml с параметрами (порог уверенности, top-k).
• Dockerfile для воспроизводимости.

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

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

Примечание: Для первого исполнения задача займёт до 20 часов из-за отладки API и сбора данных.

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

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

• Я обучил классификатор и проверил его на тестовой выборке.
• Я реализовал роутинг: простые запросы → Groq, сложные → GPT-4.
• Я залогировал стоимость хотя бы 100 запросов.
• Я проверил, что среднее снижение cost ≥ 50%.
• Я оценил качество ответов и убедился, что средняя оценка ≥ 4.0.
• Код и документация готовы к передаче (README, config, требования).