Как вы сравниваете две модели, если у них разная latency (быстрая неточная vs медленная точная)?

Краткий тезис

Сравнение моделей с разной latency — это задача многокритериальной оптимизации, где скорость и качество конфликтуют. Нельзя выбрать одну метрику; нужно учитывать компромисс. Основные подходы: построение Pareto frontier, использование cost-adjusted accuracy, проведение user study при фиксированном UX, сценарная маршрутизация (model|быстрая модель для простых запросов, медленная для сложных) и SLO-driven выбор (максимизация accuracy при соблюдении latency SLO). Выбор метода зависит от бизнес-требований и профиля нагрузки.

1. Проблема: конфликт скорости и точности

В реальных ML-системах часто есть выбор между:

• Быстрая неточная модель (например, лёгкий эмбеддинг, LLM|small LLM, линейный классификатор) — низкая latency, но выше вероятность ошибок.
• Медленная точная модель (глубокая нейросеть, large LLM, ансамбль) — высокая latency, но лучшая accuracy.

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

Ключевые термины

• Latency — время от отправки запроса до получения ответа (обычно измеряется в миллисекундах).
• Accuracy — доля правильных ответов (или другая метрика качества, например F1, BLEU, faithfulness).
• Trade-off — компромисс: улучшение одной метрики часто ухудшает другую.

2. Multi-objective optimization и Pareto frontier

Multi-objective optimization — задача оптимизации нескольких целевых функций одновременно. В нашем случае две цели: минимизировать latency и максимизировать accuracy.

Pareto frontier (граница Парето) — множество точек (моделей), где ни одну метрику нельзя улучшить без ухудшения другой. Модели на frontier называются Pareto-оптимальными.

Как строить

1. Запускаем обе модели на тестовом наборе запросов.
2. Для каждой модели измеряем среднюю latency и accuracy.
3. Наносим точки на график (latency по оси X, accuracy по оси Y).
4. Выделяем точки, которые не доминируются другими (нет точки с меньшей latency и большей accuracy одновременно).

Пример:

Точки A, B, C — все на Pareto frontier, так как ни одна не доминирует другую. Выбор между ними — бизнес-решение.

Формула доминирования
Модель X доминирует модель Y, если latency_X ≤ latency_Y и accuracy_X ≥ accuracy_Y, и хотя бы одно неравенство строгое.

3. Cost-adjusted accuracy

Cost-adjusted accuracy — метрика, которая объединяет качество и стоимость (время или деньги) в одно число. Простейший вариант:

adjusted_accuracy = accuracy / latency

Но это не всегда корректно, так как latency и accuracy могут быть в разных шкалах. Лучше использовать нормированные версии или accuracy per unit cost.

Варианты

• Accuracy per millisecond: accuracy / latency (чем выше, тем эффективнее модель по скорости).
• Accuracy per dollar: если модели запускаются на платных API (например, GPT-4 дороже GPT-3.5-turbo).
• Weighted sum: w1 * accuracy - w2 * latency (веса подбираются под бизнес).

Пример расчёта

По этой метрике быстрая модель выигрывает. Но если latency не критична, можно выбрать медленную.

Недостаток метрика линейна, а восприятие времени пользователем нелинейно (например, разница между 50 и 100 ms менее заметна, чем между 1000 и 2000 ms).

4. User study (пользовательское исследование)

User study — эксперимент с реальными пользователями, где фиксируется User Experience (UX). Идея: дать обеим моделям одинаковый таймаут (например, 2 секунды). Если медленная модель не успевает, её ответ обрезается или не показывается. Затем измеряется user satisfaction (например, по шкале Likert) или task success rate.

Процедура

1. Выбрать сценарий (например, ответ на вопрос по документам).
2. Разделить пользователей на две группы: одна получает ответ от быстрой модели, другая — от медленной (с таймаутом).
3. После каждого запроса пользователь оценивает ответ (полезность, понятность).
4. Сравнить средние оценки.

Плюсы учитывает реальное восприятие, а не абстрактные метрики.
Минусы дорого, требует много пользователей, сложно контролировать confounding factors.

Результат если пользователи одинаково оценивают обе модели (или быстрая получает выше оценки из-за скорости), то быстрая модель предпочтительнее, даже если её accuracy ниже.

5. Scenario-based routing (сценарная маршрутизация)

Вместо выбора одной модели на все случаи, можно построить router (маршрутизатор), который направляет запросы к разным моделям в зависимости от сложности.

Как определить сложность запроса

• Confidence score быстрой модели: если она уверена в ответе (высокая вероятность), отдаём её ответ; если нет — отправляем медленной.
• Классификатор сложности: обучить модель предсказывать, какой запрос требует высокой точности (например, юридические вопросы vs. простые факты).
• Heuristic rules: длина запроса, наличие ключевых слов, количество сущностей.

Архитектура

Запрос → Router → [Быстрая модель] или [Медленная модель] → Ответ

Пример реализации на Python (псевдокод):

def route(query):
    # Быстрая модель даёт ответ и confidence
    fast_answer, confidence = fast_model(query)
    if confidence > 0.9:
        return fast_answer
    else:
        return slow_model(query)

Преимущества средняя latency ниже, чем у медленной модели, а accuracy выше, чем у быстрой (на сложных запросах).
Недостатки нужно обучать/настраивать router, возможны ошибки классификации.

6. SLO-driven выбор

SLO (Service Level Objective) — целевой уровень обслуживания, например: «p95 latency < 500 ms». p95 — 95-й перцентиль: 95% запросов должны обрабатываться быстрее 500 ms.

Подход

1. Задаём SLO на latency (например, p95 < 300 ms).
2. Измеряем latency обеих моделей на representative нагрузке.
3. Выбираем модель с максимальной accuracy среди тех, что удовлетворяют SLO.

Пример:

• Быстрая модель: p95 = 150 ms, accuracy = 85%.
• Медленная модель: p95 = 600 ms, accuracy = 92%.
• SLO: p95 < 300 ms → выбираем быструю модель.

Если ни одна модель не удовлетворяет SLO, нужно либо ослабить SLO, либо оптимизировать модель (квантование, прунинг, аппаратное ускорение).

Дополнительно можно использовать SLO violation rate — доля запросов, превышающих порог. Выбираем модель с минимальным violation rate при заданной accuracy.

7. Дополнительные метрики и аспекты

• Throughput (пропускная способность): сколько запросов в секунду может обработать модель. Если нагрузка высокая, быстрая модель может быть единственным вариантом.
• Cost per query: для облачных моделей (API) стоимость может быть значимой. Медленная модель может быть дороже.
• User retention: долгосрочная метрика — если пользователи уходят из-за медленных ответов, даже высокая accuracy не спасёт.
• Fairness: быстрая модель может хуже работать на underrepresented группах запросов.

Таблица сравнения подходов

8. Практический пример: сравнение GPT-3.5-turbo и GPT-4

Допустим, мы сравниваем две модели для чат-бота:

• GPT-3.5-turbo (быстрая): средняя latency 500 ms, accuracy (по human eval) 80%.
• GPT-4 (медленная): средняя latency 2000 ms, accuracy 92%.

Шаги:

1. Pareto frontier: обе точки не доминируют друг друга.
2. Cost-adjusted accuracy: GPT-3.5: 0.80/0.5 = 1.6; GPT-4: 0.92/2.0 = 0.46 → быстрая выигрывает.
3. User study: даём таймаут 1500 ms. GPT-4 часто не успевает → пользователи оценивают быструю модель выше.
4. Scenario routing: для простых вопросов (например, «какой сегодня день?») используем GPT-3.5, для сложных (анализ контракта) — GPT-4.
5. SLO-driven: SLO p95 < 1000 ms. GPT-3.5 удовлетворяет, GPT-4 нет → выбираем GPT-3.5.

Вывод в данном случае быстрая модель предпочтительнее, если latency критична.

9. Инструменты для измерения и мониторинга

• Профилирование latency: time в Python, cProfile, middleware в веб-фреймворках (например, starlette.middleware).
• Мониторинг в production: Prometheus + Grafana для сбора p50, p95, p99 latency.
• A/B тестирование: разделение трафика (например, 50% на быструю, 50% на медленную) с записью метрик.
• Оффлайн-оценка accuracy: размеченный датасет, метрики (accuracy, F1, BLEU, ROUGE).

Пример кода для замера latency

import time

def measure_latency(model, query, n=100):
    latencies = []
    for _ in range(n):
        start = time.perf_counter()
        model(query)
        end = time.perf_counter()
        latencies.append((end - start) * 1000)  # ms
    return {
        'mean': sum(latencies)/n,
        'p95': sorted(latencies)[int(n*0.95)]
    }

Пет-проект для закрепления

Задача Разработать систему A/B сравнения двух моделей (быстрая неточная vs медленная точная) для задачи ответов на вопросы по документам.

Инструменты

• Python, FastAPI (для API), Docker.
• Hugging Face Transformers (например, distilbert-base-uncased как быстрая, bert-large-uncased как медленная).
• Redis для кэширования ответов быстрой модели.
• Prometheus + Grafana для мониторинга latency.
• Датасет SQuAD или собственный.

Шаги:

1. Развернуть две модели как микросервисы.
2. Написать роутер, который по confidence быстрой модели решает, отправлять ли запрос медленной.
3. Реализовать сбор метрик: latency каждого запроса, accuracy (по золотому стандарту), confidence.
4. Построить Pareto frontier и рассчитать cost-adjusted accuracy.
5. Провести нагрузочное тестирование (например, с помощью locust) и проверить SLO.
6. Сравнить результаты и написать отчёт.

Ожидаемый результат Вы получите практическое понимание trade-off между скоростью и качеством, научитесь строить роутер и интерпретировать метрики.

Связь с другими вопросами

Навигация

• Предыдущий: 508
• Следующий: 510
• Индекс: 00. Индекс разборов