🤖 ИИ · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Сложный ·

Как оценивать качество ИИ

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 45 минут; не меньше половины заданий требуют прочитать код, конфигурацию или формализованную схему. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого решения.

Вопрос 1 из 20

Команда оценивает помощника службы поддержки только на самых частых вопросах. Какой пробел опаснее всего?

cases = {'status_order': 4200,
 'refund': 680,
 'account_takeover': 7,
 'data_leak': 3}

Редкие темы представлены слабо, но их можно оценить общей средней по частым вопросам Набор не отражает различия между каналами поддержки и длиной обращений В наборе почти нет редких обращений с высокой ценой ошибки, например блокировки счёта или утечки данных В выборке мало неоднозначных формулировок, хотя ответы на частые вопросы стабильны

Вопрос 2 из 20

Для поиска мошеннических операций пропуск опаснее ложной тревоги. Какой показатель должен получить больший вес?

TP=72
 FN=8
 FP=36
recall = TP/(TP+FN)
precision = TP/(TP+FP)

Средний F1, если ошибки обоих видов считать одинаково опасными Полнота по классу мошенничества, при отдельном контроле допустимого числа ложных тревог Общая accuracy с дополнительным порогом по числу ложных тревог Precision по всем положительным решениям без отдельного контроля пропусков мошенничества

Вопрос 3 из 20

Два эксперта оценивают ответы по шкале от 1 до 5, но один ставит балл за стиль, другой — за фактическую точность. Что исправить первым?

Разделить критерии в рубрике и дать примеры пограничных оценок Назначить более строгого эксперта эталонным и откалибровать оценки второго по нему Усреднить оценки, а разницу между экспертами учитывать как шум Сделать шкалу подробнее, чтобы каждый эксперт мог точнее выразить своё впечатление

Вопрос 4 из 20

Новая версия выиграла 51 случай из 100, старая — 49. Можно ли объявлять победу?

wins_new=51
wins_old=49

Да, если разница сохраняется при нескольких перестановках порядка ответов Да, если примеры выбраны случайно и новая версия получила больше побед Нет: различие мало, нужна оценка неопределённости и больше независимых примеров Нет, потому что 100 сравнений недостаточно для любых выводов независимо от размера эффекта

Вопрос 5 из 20

Модель распознаёт 990 обычных писем и пропускает все 10 фишинговых. Accuracy равна 99%. Как трактовать результат?

y_true = [0]*990 + [1]*10
y_pred = [0]*1000

Редкий класс слишком мал, поэтому его ошибки нельзя учитывать в итоговой оценке Метрика вводит в заблуждение: на целевом редком классе качество нулевое Accuracy корректна, но её следует дополнить средней уверенностью модели Система хороша для общего потока, а фишинговый класс можно контролировать отдельным правилом

Вопрос 6 из 20

Как уменьшить влияние порядка ответов в экспертном сравнении моделей A и B?

pair = shuffle({"left": answer_a, "right": answer_b})
reviewer.sees_model_name = False

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

Вопрос 7 из 20

Новая модель точнее, но в 3% случаев возвращает пустой ответ из-за сбоя формата. Где искать решение о выпуске?

metrics = {'semantic_score': 0.87,
 'valid_json_rate': 0.97,
 'timeout_rate': 0.006}

В совместной оценке качества и технической надёжности, а не только смысловой точности Сравнить среднюю задержку и стоимость, если пустой ответ можно повторить Оценить только примеры, где формат корректен, чтобы измерять качество содержания отдельно Выпускать по F1, а пустые ответы учитывать как отдельный технический долг после запуска

Вопрос 8 из 20

Из контрольного набора убрали все вопросы, на которых команда меняла подсказку. Что произошло?

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

Вопрос 9 из 20

Вероятность 0,9 должна примерно в девяти случаях из десяти означать верный ответ. Какое свойство проверяют?

bucket_p = 0.9
observed_accuracy = 0.61

Совпадение средней уверенности с общей accuracy без разбиения прогнозов по диапазонам вероятности Разрешающую способность метрики на примерах с высокой уверенностью Калибровку уверенности Стабильность вероятностей при повторной генерации одного и того же ответа

Вопрос 10 из 20

В парной оценке новая модель лучше по стилю, старая — по фактам. Как не потерять это различие?

Считать модели равными, если преимущества проявляются по разным критериям Оценивать критерии отдельно и заранее задать их приоритет для задачи Свести стиль и факты в одну итоговую оценку, назначив экспертам общий вопрос «какой ответ лучше» Выбрать фактическую точность как единственный критерий, потому что стиль вторичен во всех задачах

Вопрос 11 из 20

Почему случайное деление строк на train/test плохо для обращений одного клиента, повторяющихся почти дословно?

train, test = split(rows, group_by="customer_id")

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

Вопрос 12 из 20

Автоматическая метрика краткости награждает ответ «Не знаю» на любой вопрос. Что с ней не так?

Метрика корректно измеряет краткость, поэтому проблему нужно решать только отдельным ограничением длины Метрика неприменима только к открытым вопросам, а на справочных ответах она достаточна Нужно добавить штраф за отказ, но сохранить краткость как единственный показатель качества Она измеряет только одно свойство и допускает тривиальную стратегию, не решающую задачу

Вопрос 13 из 20

Эксперты согласны в 95% простых случаев, но спорят почти во всех сложных. Что полезнее сделать?

agreement = {"easy":0.98,"hard":0.46}

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

Вопрос 14 из 20

Версия B быстрее на 200 мс, но хуже отвечает на 1% критических юридических запросов. Что делать?

release_gate = {'legal_accuracy_min': 0.97, 'p95_latency_max_ms': 1200}
B = {'legal_accuracy': 0.962, 'p95_latency_ms': 740}

Считать юридический срез слишком малым и ориентироваться на общую метрику Применить заранее заданное правило: критическая регрессия может блокировать выпуск независимо от средней скорости Перевести регрессию качества и выигрыш по скорости в денежную оценку без отдельного запрета критических ошибок Выпустить B, если средняя задержка улучшилась у большинства пользователей

Вопрос 15 из 20

Как проверить систему, которая должна уметь отказываться при нехватке сведений?

Добавить несколько бессмысленных вопросов и считать любой отказ правильным Оценивать только долю отказов, не различая оправданные и лишние Добавить примеры без ответа и оценивать как необоснованные ответы, так и лишние отказы Проверить только вопросы с известным ответом и измерить, насколько точно модель их формулирует

Вопрос 16 из 20

Почему ROUGE может плохо оценить хороший пересказ?

reference="Поставку перенесли на пятницу"
candidate="Товар прибудет на два дня позже, в конце недели"

Он опирается на совпадение слов и может штрафовать точную переформулировку Высокий ROUGE гарантирует, что пересказ сохранил смысл и факты, даже если текст почти дословный Метрика полезна только для коротких ответов и перестаёт работать при любом перефразировании ROUGE сравнивает смысл ответа с первоисточником и поэтому штрафует только фактические ошибки

Вопрос 17 из 20

Команда каждый день смотрит на закрытый тест и меняет подсказку по его результатам. Что станет с оценкой?

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

Вопрос 18 из 20

Как сравнить модели, если одна в четыре раза дешевле, но немного уступает по качеству?

models = [{'name': 'A', 'score': 0.89, 'cost': 4.0},
 {'name': 'B', 'score': 0.87, 'cost': 1.0}]
quality_floor=0.86

Сравнить стоимость миллиона запросов и число параметров, не задавая минимального качества Выбрать более точную модель, а стоимость снижать после выпуска оптимизацией инфраструктуры Выбрать дешёвую модель, если её средняя метрика отличается менее чем на один пункт Построить границу качество–стоимость и проверить, достигает ли каждая версия минимально допустимого качества

Вопрос 19 из 20

После выпуска распределение запросов изменилось: стало больше коротких голосовых расшифровок. Какой вывод?

Заменить контрольный набор свежими запросами, потеряв возможность сравнивать версии во времени Пересчитать общую метрику на прежнем тесте с весом, пропорциональным новой длине запросов Старый набор можно оставить основным, а новые голосовые запросы оценивать только по жалобам Нужна свежая оценка на новом распределении и мониторинг качества по типам запросов

Вопрос 20 из 20

Какой протокол даёт наиболее честное решение о выпуске?

protocol = {'frozen_set': 'v3',
 'primary': 'task_success',
 'gates': {'critical': 0.98, 'json': 0.995},
 'blind': True}
run(protocol)

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

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу