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

Внедрение ИИ в реальную задачу

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

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

⏱ --:--

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

Вопрос 1 из 20

Компания предлагает внедрить ИИ «для повышения инновационности», но не названа операция. Какой первый вопрос?

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

Вопрос 2 из 20

Оператор вручную сортирует 50 тысяч обращений в месяц по 12 стабильным категориям. Почему это разумный кандидат?

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

Вопрос 3 из 20

Признак `final_resolution` появляется через неделю после обращения, а ответ нужен за секунды. Можно ли использовать его во входе?

prediction_time = ticket.created_at
feature_time = ticket.final_resolution_at

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

Вопрос 4 из 20

Модель стоит 0,004 евро за вызов. При 3 млн вызовов в месяц только прямой счёт составит:

monthly_calls=3_000_000
cost_per_call=0.004
direct=monthly_calls*cost_per_call

12 000 евро 750 евро, если учитывать только успешные ответы и среднюю скидку поставщика 1 200 евро, если умножить цену на 300 тысяч вызовов 120 000 евро, если принять цену за 0,04 евро вместо 0,004

Вопрос 5 из 20

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

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

Вопрос 6 из 20

Правило решает 92% случаев без ошибок, оставшиеся 8% сложны. Какой дизайн разумнее?

if rule_confident(case):
    return rule(case)
return model_or_review(case)

Оставить правило для покрываемых случаев, а модель или человека использовать для остатка Оставить модель для всех случаев, а правило использовать как проверку после ответа Заменить правило единой моделью, если она показывает сопоставимую среднюю точность Передать модели только 8% сложных случаев, не проверяя, можно ли их надёжно распознать заранее

Вопрос 7 из 20

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

if now-data.timestamp > timedelta(minutes=10):
    return fallback("stale_data")

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

Вопрос 8 из 20

Средняя задержка 300 мс, но p99 равна 8 секундам. Почему среднее недостаточно?

latency_ms = np.array(request_latencies)
stats = {
    "mean": latency_ms.mean(),
    "p95": np.quantile(latency_ms, 0.95),
    "p99": np.quantile(latency_ms, 0.99),
}

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

Вопрос 9 из 20

Перед выпуском новая модель работает параллельно и записывает решения, но не влияет на процесс. Зачем?

Чтобы измерить качество, задержку и расхождения на реальном потоке без риска действий Чтобы заменить офлайн-проверку одним периодом параллельного запуска Чтобы сравнить решения модели и оператора, но не измерять задержку и технические сбои Чтобы собирать реальные данные для дообучения без контроля согласия и прав доступа

Вопрос 10 из 20

Модель сократила ручную работу на 30%, но число жалоб выросло в четыре раза. Как оценить проект?

Жалобы следует нормировать на рост объёма и учитывать только подтверждённые ошибки Увеличение автоматизации может снизить стоимость на случай и компенсировать рост жалоб Проект успешен, если экономия труда превышает стоимость обработки жалоб Продуктовая польза не подтверждена: экономию нужно сопоставить с вредом, исправлениями и доверием

Вопрос 11 из 20

API поставщика изменил поле `score` на `confidence`. Что защищает интеграцию?

validate(response, schema=v2_schema)
assert response["model_version"] in allowed_versions

Использовать значение по умолчанию при отсутствии обоих полей и продолжать обработку Версионированная схема, контрактные тесты и отказ при неизвестном формате Читать оба поля и выбирать первое непустое, не проверяя версию ответа Добавить преобразование `score` в `confidence` на клиенте после первой ошибки

Вопрос 12 из 20

Повторный одинаковый запрос к дорогой модели безопасно кэшировать не всегда. Что проверить?

key = (
    user_scope,
    normalized_query,
    corpus_version,
    model_version,
)
cached = cache.get(key)

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

Вопрос 13 из 20

Как выбрать между моделью A: 95% качества, 2 с; B: 94,5%, 120 мс?

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

Вопрос 14 из 20

Для автоматической публикации новости допускается одна выдумка на тысячу материалов. Что нужно до запуска?

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

Вопрос 15 из 20

Пилот показал пользу только для коротких стандартных запросов. Как выпускать?

if request.tokens <= 300 and intent in validated_intents:
    use_ai()
else:
    legacy_flow()

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

Вопрос 16 из 20

Стоимость ручной проверки составляет 0,20 евро, модель — 0,01, но 40% ответов всё равно проверяются. Как считать экономику?

cost = N*model_cost + N*review_rate*review_cost + infra + expected_error_cost

Учитывать только 60% непроверяемых ответов, а стоимость проверок считать частью прежнего процесса Учитывать смешанный поток, стоимость ошибок и инфраструктуру Сравнить прямую цену модели с зарплатой оператора без стоимости ошибок и поддержки Считать экономию как разницу 0,19 евро на каждый вызов модели

Вопрос 17 из 20

У системы нет владельца, который отвечает на жалобы и утверждает изменения порога. Что это означает?

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

Вопрос 18 из 20

Какой сигнал должен автоматически остановить обработку?

if critical_error_rate > 0.002 or data_contract_failed:
    circuit_breaker.open()

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

Вопрос 19 из 20

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

Точность модели остаётся главным узким местом, потому что интеграцию можно компенсировать инструкциями пользователям Интеграция остаётся узким местом Пользовательский процесс можно не менять, если качество ответа достаточно высоко Ручное копирование следует учитывать только как временную стоимость пилота

Вопрос 20 из 20

Какой документ нужен перед окончательным выпуском?

runbook = {'metrics': Ellipsis,
 'alerts': Ellipsis,
 'owners': Ellipsis,
 'rollback': Ellipsis,
 'fallback': Ellipsis,
 'incident_steps': Ellipsis}

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

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

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

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

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