Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов

Оценщик посчитал точность только для ответов, которые успели прийти. Медленные и упавшие запросы исчезли из знаменателя, а итоговый процент вырос. Пользователю такое улучшение не помогает: часть задач вообще не получила результата.

Разделяйте качество полученного ответа, доступность результата и общий успех на всех запущенных случаях. Эти показатели отвечают на разные вопросы и должны показываться вместе.

Сравнение состояний

Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.

Среди восьмидесяти успешно оценённых ответов доля корректных равна семидесяти из восьмидесяти, или 87,5%. Всего в этой учебной модели получено восемьдесят пять ответов: пять из них оценщик не смог проверить. Среди всех ста запущенных случаев подтверждены семьдесят успехов, то есть 70%. Сбои оценщика нельзя автоматически назвать ошибками модели. Отчёт должен явно показывать знаменатели и число неоценённых случаев.

Повтор упавшего теста тоже влияет на интерпретацию. Если успешный результат получен с третьей попытки, это не эквивалентно первому успешному ответу без дополнительного времени и расхода.

Практические проверки

Сохраните запись на каждый запланированный пример до запуска. После прогона проверьте, что ни один идентификатор не потерян. Для каждого присвойте статус генерации и статус оценки отдельно. Укажите политику повторов и общий предел времени.

Добавьте искусственный тайм-аут модели и искусственный сбой оценщика. Убедитесь, что они попали в разные категории. Не удаляйте неудачи из отчёта автоматически. Если часть примеров пересчитана, отметьте новый прогон и объясните, какие условия изменились, вместо замены первоначального результата без следа.

Ограничения и риски

Числа в таблице показывают устройство знаменателей, а не производительность конкретной системы. Решение о допустимой доле тайм-аутов зависит от сценария. Для интерактивного помощника доступность результата часто важна не меньше качества текста.

Оценка эксперимента должна учитывать завершённость запусков и работу оценщиков, а не только выбранные успешные записи. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Утечка в LLM-eval: почему перефразы одного вопроса нельзя считать независимыми тестами, Счётчик токенов не совпадает с usage LLM: как найти причину расхождения.