Хорошее собеседование на ML Engineer или инженера по ИИ проверяет не знание модных слов, а способность видеть скрытые допущения. Кандидату дают вопрос про accuracy, RAG, drift или fine-tuning, а на самом деле смотрят, заметит ли кандидат утечку данных, неверную метрику, сломанный split, дорогой inference или опасные права агента.
Ниже - 100 вопросов с краткими ответами, разбитых на 5 уровней по 20 штук. Первый уровень проверяет базу данных и статистики, второй - метрики и обучение моделей, третий - продакшен и MLOps, четвертый - LLM, RAG и ИИ-агентов, пятый - вопросы с подвохом для проверки инженерной зрелости.
Если ответ звучит как «возьмем модель побольше», собеседование уже пошло плохо. В реальной работе модель живет не в ноутбуке, а в системе с данными, API, правами, логами, откатами, latency, мониторингом и пользователями, которые ломают самые аккуратные предположения.
Уровень 1. Данные, статистика и базовая постановка задачи
- Что такое train, validation и test set?
Train используют для обучения, validation - для выбора модели и threshold, test - для финальной честной оценки. Если test участвует в настройке, итоговая метрика становится завышенной.
- Почему preprocessing до train-test split опасен?
Scaler, imputation, target encoding и отбор признаков, посчитанные на всем датасете, протаскивают информацию из test set в train set. Правильный путь - fit только на train, transform на validation и test.
- Почему нельзя случайно перемешать временной ряд перед split?
Модель увидит будущее и покажет красивую метрику на тесте. Для временных данных используют разбиение по времени, backtesting или walk-forward validation.
- Когда нужен group split?
Group split нужен, если объекты одного пользователя, пациента, устройства или компании могут попасть и в train, и в test. Без такого split модель может запомнить профиль, а не выучить закономерность.
- Почему высокая корреляция признака с таргетом еще не делает признак полезным?
Признак может появляться после события или кодировать ответ. Например, «дата блокировки карты» хорошо предсказывает мошенничество, но в момент решения такого поля еще нет.
- Что такое утечка данных?
Утечка возникает, когда модель во время обучения получает информацию, которой не будет в момент реального предсказания. Итоговая метрика выглядит лучше, чем будущая работа в продакшене.
- Почему дубликаты в датасете опасны?
Если похожие или одинаковые объекты попали в train и test, модель узнает примеры. Особенно часто проблема встречается в изображениях, логах, медицинских данных и пользовательских событиях.
- Можно ли просто удалить выбросы?
Иногда можно, но не автоматически. Выброс может быть ошибкой сенсора, атакой, VIP-клиентом, редким заболеванием или главным положительным классом.
- Что опаснее, пропуски или неверные значения?
Неверные значения часто опаснее. Пропуск виден, а ошибочный возраст, валюта или класс выглядят как нормальный факт и тихо портят обучение.
- Почему медиана иногда полезнее среднего?
Среднее легко тянут экстремальные значения. Для зарплат, чеков, latency и времени доставки медиана лучше показывает типичный случай.
- Почему p95 и p99 важны для latency?
Среднее значение скрывает хвост. Пользователи часто страдают не от среднего ответа, а от редких, но болезненных задержек.
- Что такое baseline?
Baseline - простая начальная модель или правило для сравнения. Без baseline невозможно понять, дала ли сложная модель реальную пользу.
- Почему большая модель не всегда лучше простой?
Большая модель дороже, медленнее и чаще переобучается на малых данных. Если сигнал простой, логистическая регрессия или градиентный бустинг могут быть практичнее.
- Что такое переобучение?
Модель слишком хорошо подстраивается под train set и хуже работает на новых данных. Переобучение видно по разрыву между train и validation quality.
- Что такое недообучение?
Модель слишком простая или плохо обучена и не ловит закономерность даже на train set. Обычно проблема видна по плохим train и validation метрикам одновременно.
- Почему больше данных не всегда улучшает модель?
Шумные, старые, смещенные или плохо размеченные данные могут ухудшить качество. Объем помогает, когда новые данные похожи на будущий поток и закрывают реальные сценарии.
- Почему качество разметки важнее выбора модели?
Модель учится на метках. Если инструкции мутные, классы пересекаются, а разметчики спорят, сложная архитектура просто лучше выучит хаос.
- Что такое inter-annotator agreement?
Показатель показывает, насколько разметчики согласны друг с другом. Низкое согласие часто говорит, что классы плохо определены или задача неоднозначна.
- Что такое Simpson's paradox?
Общий тренд может исчезнуть или поменять знак при разбиении по сегментам. Поэтому метрики надо смотреть не только в среднем, но и по важным группам.
- Как понять, что задача вообще подходит для ML?
Нужны повторяющиеся данные, измеримая цель, приемлемая цена ошибки и способ получить feedback. Если правило простое и стабильное, обычная логика может быть лучше модели.
Уровень 2. Модели, метрики и ошибки оценки
- Accuracy 99% означает, что модель хорошая?
Нет. При доле положительного класса 1% модель, которая всегда отвечает «нет», уже даст 99% accuracy. Для редких событий нужны precision, recall, PR-AUC и цена ошибок.
- Чем precision отличается от recall?
Precision показывает, какая доля положительных предсказаний оказалась верной. Recall показывает, какую долю реальных положительных случаев модель нашла.
- Когда recall важнее precision?
Recall важнее, когда пропуск опасен. Например, медицинский скрининг или антифрод могут предпочесть больше ложных тревог, чем пропуск критичного случая.
- Когда precision важнее recall?
Precision важнее, когда ложное срабатывание дорого. Например, блокировка клиента, ручная проверка или удаление контента требуют аккуратности.
- Почему ROC-AUC может вводить в заблуждение?
При сильном дисбалансе ROC-AUC может выглядеть прилично, хотя модель плохо находит редкий положительный класс. Часто полезнее смотреть precision-recall curve.
- Почему F1-score не всегда бизнес-метрика?
F1 симметрично смешивает precision и recall, а бизнес-ошибки редко симметричны. Ложная блокировка и пропущенная атака почти всегда стоят по-разному.
- Можно ли подбирать threshold на test set?
Нельзя, если test set нужен для финальной оценки. Threshold выбирают на validation set, а test оставляют для последней проверки.
- Почему меньший loss не гарантирует лучший продукт?
Loss оптимизирует математическую цель. Продукту может быть важнее верх ранжирования, редкий сегмент, стоимость ошибки или стабильность.
- Что такое calibration?
Калибровка показывает, соответствуют ли прогнозные вероятности реальной частоте событий. Если среди объектов с прогнозом 90% событие случается в 60% случаев, модель некалибрована.
- Почему хорошее ранжирование не равно хорошей вероятности?
Модель может верно упорядочивать объекты по риску, но давать неверные абсолютные вероятности. Для кредитного риска, медицины и лимитов такое различие критично.
- Что такое Brier score?
Brier score оценивает качество вероятностных предсказаний. Но интерпретировать его надо вместе с задачей, сегментами и calibration curve.
- Зачем нужна confusion matrix?
Матрица показывает true positive, false positive, true negative и false negative. По ней проще увидеть, какую именно ошибку делает модель.
- Что такое cross-validation?
Cross-validation делит данные на несколько разбиений и оценивает модель на разных фолдах. Метод помогает понять устойчивость результата.
- Когда обычная cross-validation вредна?
Она вредна при временных рядах, группах пользователей или связанных объектах. Тогда нужны time series split, group split или другая схема проверки.
- Почему target encoding может дать утечку?
Если считать средний таргет категории на всем датасете, модель получает подсказку из будущего test set. Target encoding нужно делать внутри фолдов или только по train.
- Почему one-hot encoding ломается в продакшене?
В проде появляются новые категории. Пайплайн должен уметь обрабатывать unknown values, иначе сервис упадет или закодирует объект неверно.
- Когда high-cardinality признаки становятся проблемой?
Большое число категорий раздувает размерность и повышает риск переобучения. Помогают hashing, аккуратный target encoding, эмбеддинги или доменная агрегация.
- Почему feature importance может обмануть?
Важность зависит от модели, корреляций и способа расчета. Два взаимозаменяемых признака могут делить важность, а прокси-признак может скрывать чувствительный атрибут.
- Что такое shortcut learning?
Модель находит легкий обходной сигнал вместо нужной закономерности. Например, классификатор снимков может учиться по водяному знаку клиники, а не по патологии.
- Что такое Goodhart's law в ML?
Когда метрика становится целью, команда начинает оптимизировать метрику, а не реальный результат. Поэтому рядом с основной метрикой нужны guardrail-метрики.
Уровень 3. Обучение, MLOps и продакшен
- Почему ноутбук с моделью еще не ML-система?
Ноутбук не решает воспроизводимость, версионирование, API, latency, мониторинг, права доступа, откаты и деградацию качества.
- Что нужно версионировать кроме весов модели?
Данные, код обучения, preprocessing, признаки, схему входа, зависимости, Docker-образ, threshold, post-processing и метрики эксперимента.
- Зачем нужен model registry?
Model registry хранит версии моделей, метаданные, статусы, артефакты и связи с экспериментами. Без реестра сложно понять, что именно работает в проде.
- Что такое model card?
Model card описывает назначение модели, данные, метрики, ограничения, известные риски и условия применения. Такой документ помогает не использовать модель вне контекста.
- Что такое data contract?
Data contract фиксирует схему, типы, допустимые значения и SLA данных. Если upstream меняет поле без согласования, модель может тихо сломаться.
- Что такое train-serving skew?
Модель обучалась на признаках, рассчитанных одним способом, а в проде получает признаки из другого пайплайна. Разница в join-логике, времени или дефолтах портит качество.
- Как ловить train-serving skew?
Нужно сравнивать распределения train и production признаков, проверять схемы, логировать версии фичей и тестировать preprocessing как часть системы.
- Что такое data drift?
Data drift означает, что распределение входных данных изменилось. Например, поменялись пользователи, сезон, устройство, канал трафика или upstream-система.
- Что такое concept drift?
Concept drift означает, что связь между признаками и целевой переменной изменилась. Модель получает похожие признаки, но прежняя закономерность больше не работает.
- Если drift detector молчит, модель здорова?
Нет. Detector видит только выбранные признаки, статистики и пороги. Может измениться связь с таргетом, качество разметки или поведение продукта.
- Что делать, если ground truth приходит через месяц?
Используют прокси-сигналы: распределения признаков, confidence, долю объектов около threshold, жалобы, бизнес-метрики и ручную разметку выборки.
- Почему автоматическое переобучение опасно?
Автотренировка может закрепить ошибочную разметку, сезонный шум, data poisoning или сбой upstream-сервиса. Нужны quality gates, baseline и откат.
- Что такое shadow deployment?
Новая модель получает копию реального трафика, но не влияет на пользователя. Команда сравнивает качество, latency и ошибки до включения в продукт.
- Почему canary deployment полезен для ML?
Canary ограничивает ущерб. Новая модель получает малую долю трафика, а команда сравнивает метрики, ошибки и latency до полного раската.
- Что такое fallback?
Fallback - безопасный запасной путь. Если модель недоступна или не уверена, система может вернуть правило, старую модель или отправить случай на ручную проверку.
- Почему rollback модели не всегда прост?
Старая модель может требовать другую схему признаков, другой preprocessing или старый threshold. Откат надо проектировать до релиза.
- Что логировать в ML-сервисе?
Версию модели, версию фичей, схему входа, prediction, confidence, latency, ошибки preprocessing, идентификатор запроса и ветку эксперимента.
- Какие метрики нужны ML-сервису?
Нужны latency, traffic, errors, saturation, доля fallback, распределения предсказаний, drift-сигналы, качество по delayed labels и стоимость inference.
- Почему p99 latency важнее средней?
Средняя latency скрывает хвосты. Для онлайн-рекомендаций, антифрода и LLM-ответов p95 и p99 часто важнее среднего значения.
- Когда модель лучше не деплоить, даже если offline score вырос?
Когда рост нестабилен, inference дорогой, улучшение видно только на неважном сегменте, нет мониторинга, нет отката или модель нарушает требования объяснимости.
Уровень 4. LLM, RAG, агенты и безопасность
Вопросы про prompt injection, ИИ-агентов, персональные данные, доступ к инструментам и безопасность предназначены для легального и ответственного использования. Нельзя применять такие знания для слежки, несанкционированного доступа, взлома, нарушения правил сервисов или незаконного обхода ограничений. При работе с данными и безопасностью нужно соблюдать законы своей страны, особенно России.
- Почему LLM уверенно врет?
Языковая модель предсказывает правдоподобное продолжение текста, а не проверяет факт как база знаний. Уверенный тон не равен доказательству.
- RAG всегда снижает галлюцинации?
Нет. RAG помогает, если retrieval нашел релевантный контекст, chunking выбран разумно, reranking работает, а модель не выходит за пределы источников.
- Почему плохой RAG опаснее обычной галлюцинации?
Плохой RAG может дать видимость доказательства. Пользователь видит ссылку или фрагмент документа и доверяет ответу, хотя модель исказила смысл.
- Что такое chunking?
Chunking делит документы на фрагменты для поиска. Слишком маленькие chunks теряют контекст, слишком большие ухудшают точность retrieval и повышают стоимость.
- Зачем нужен reranking?
Reranker заново сортирует найденные фрагменты по релевантности. Такой слой часто улучшает качество RAG, если первичный поиск возвращает много шума.
- Что такое embedding drift?
Embedding drift возникает, когда меняется модель эмбеддингов или распределение документов. Старый индекс может начать хуже находить релевантные фрагменты.
- Почему большое контекстное окно не решает все?
Большой контекст повышает latency и стоимость, а модель все равно может пропустить важный фрагмент, смешать версии документов или неправильно расставить приоритеты.
- Когда fine-tuning хуже RAG?
Fine-tuning плохо подходит для часто меняющихся фактов и больших корпоративных баз знаний. Для ответов по документам обычно начинают с RAG.
- Когда fine-tuning полезен?
Fine-tuning полезен для формата, стиля, классификации, доменной терминологии и устойчивых паттернов. Для свежих фактов он обычно хуже retrieval.
- Что такое LLM evals?
Evals - набор тестов для проверки качества LLM-системы. Они должны включать типовые запросы, крайние случаи, безопасность, регрессии и проверку источников.
- Почему human eval недостаточен?
Ручная оценка дорогая, медленная и субъективная. Нужна комбинация ручной оценки, автоматических тестов, golden set и продакшен-метрик.
- Почему LLM-as-a-judge надо использовать осторожно?
Модель-судья может ошибаться, быть предвзятой и предпочитать уверенные длинные ответы. Ее выводы надо калибровать на ручной разметке.
- Что такое prompt injection?
Prompt injection возникает, когда пользовательский или внешний текст меняет поведение модели. Особенно опасны документы, веб-страницы и письма внутри RAG или агентского сценария.
- Почему prompt injection нельзя закрыть только промптом?
Промпт - не надежная граница безопасности. Защита должна жить в приложении: права, allowlist инструментов, sandbox, подтверждение действий и аудит.
- Почему агент с инструментами опаснее чат-бота?
Чат-бот пишет текст. Агент может вызвать API, отправить письмо, изменить запись, удалить файл или оформить заказ.
- Как ограничивать права ИИ-агента?
Нужны минимальные права, allowlist действий, лимиты, разделение чтения и записи, human approval для опасных операций и журнал аудита.
- Что такое insecure output handling?
Система небезопасно использует вывод модели в коде, SQL, shell-команде, HTML или API-вызове. Вывод LLM надо валидировать как недоверенный ввод.
- Можно ли обучать модель на пользовательских данных без проверки?
Нет. Нужны правовые основания, согласие или договоры, режим персональных данных, лицензии, удаление чувствительных полей и контроль доступа.
- Температура 0 гарантирует одинаковый ответ?
Не всегда. На результат влияют версия модели, инфраструктура, настройки sampling, системный промпт и обновления провайдера.
- Почему стоимость LLM-сервиса может резко вырасти?
Длинные контексты, ретраи, агенты с циклами, плохой retrieval и отсутствие кеширования быстро увеличивают число токенов и задержку.
Уровень 5. Вопросы с подвохом и инженерная зрелость
- «Возьмем модель побольше» - хороший план?
Не сам по себе. Большая модель может стоить дороже, отвечать медленнее и не исправить плохие данные, неверную метрику или утечку.
- «Добавим больше данных» - всегда правильный ответ?
Нет. Если данные смещены, шумные или плохо размечены, дополнительный объем увеличит проблему.
- «Поднимем accuracy» - корректная цель?
Не всегда. Цель должна быть связана с бизнес-ошибкой, сегментами, threshold, guardrail-метриками и downstream-эффектом.
- Почему модель с лучшей общей метрикой может быть хуже?
Она может ухудшить критичный сегмент: новый регион, редкий класс, дорогих клиентов или уязвимую группу пользователей.
- Почему A/B-тест может провалить модель с хорошим offline score?
Offline score не видит реакцию пользователей, UX, feedback loop и конкуренцию с другими системами. Продукт может ухудшиться при росте ML-метрики.
- Что такое feedback loop?
Модель влияет на данные, по которым потом обучается. Рекомендательная система показывает однотипный контент и сама сужает будущие сигналы.
- Почему синтетические данные не всегда спасают?
Синтетика может повторять bias исходных данных, не закрывать редкие сценарии и создавать слишком чистые примеры, которых не бывает в продакшене.
- Почему data augmentation может навредить?
Аугментация может менять смысл класса. В медицине, документах и промышленных дефектах не каждое искажение допустимо.
- Почему explainability не равна truth?
Объяснение показывает, как модель или метод интерпретации описали решение. Оно не доказывает причинность и не гарантирует отсутствие прокси-признаков.
- Почему SHAP нельзя принимать как абсолютную истину?
SHAP зависит от фона, корреляций, модели и допущений метода. Результат надо проверять доменной экспертизой и анализом ошибок.
- Почему fairness нельзя проверить одной средней метрикой?
Модель может быть хорошей в среднем и плохой для отдельной группы. Нужны сегменты, разные типы ошибок и контекст применения.
- Когда персонализация ухудшает продукт?
Когда модель сужает выбор, усиливает прошлое поведение, ломает новизну или не дает пользователю выйти из старого профиля.
- Почему real-time inference не всегда нужен?
Он дороже и сложнее batch inference. Если решение не требует мгновенного ответа, пакетный расчет может быть дешевле и стабильнее.
- Почему batch prediction тоже может быть рискованным?
Данные могут устареть до момента применения. Для лимитов, фрода и динамических цен задержка меняет смысл предсказания.
- Как понять, что продукт реально использует модель?
Нужны логи вызовов, версия модели в запросах, доля решений с участием модели и проверка, что старые правила не перетирают prediction.
- Почему мониторинг только качества модели недостаточен?
Нужно смотреть latency, ошибки, стоимость, долю fallback, дрифт, схему входа и бизнес-метрики. Качество без эксплуатационных сигналов не спасает сервис.
- Почему модель может деградировать без изменения кода?
Меняются пользователи, сезонность, источники данных, политика продукта, конкуренты и поведение злоумышленников. Код тот же, среда уже другая.
- Что делать, если модель ошиблась в критичном решении?
Нужны разбор инцидента, сохраненные входы, версия модели, версия фичей, лог решения, ручная проверка, откат и обновление тестов.
- Что должно быть в postmortem ML-инцидента?
Таймлайн, причина, затронутые сегменты, ущерб, версия данных и модели, почему мониторинг не сработал, план предотвращения и владельцы задач.
- Как отличить сильного ML Engineer на собеседовании?
Сильный кандидат говорит не только про модель, но и про данные, метрику, проверку гипотезы, стоимость inference, риски продакшена и способ отката.
Как отвечать на такие вопросы
Сильный ответ строится одинаково: найти скрытое допущение, назвать риск, предложить проверку и объяснить последствие для продакшена. На вопрос «почему 99% accuracy может быть плохой» не надо десять минут пересказывать confusion matrix. Достаточно сказать: при дисбалансе классов accuracy может быть пустой, надо смотреть precision, recall, PR-AUC, стоимость ошибок и рабочий threshold.
Слабый кандидат отвечает набором терминов: «добавим регуляризацию, нормализацию, кросс-валидацию и XGBoost». Сильный кандидат связывает метод с причиной. Регуляризация нужна при переобучении, group split нужен при утечке между пользователями, canary нужен для ограничения ущерба, RAG нужен для доступа к внешним знаниям, но не является гарантией правды.
| Уровень | Что проверяет | Красный флаг |
|---|---|---|
| 1 | Данные, split, утечки и базовую статистику | Кандидат сразу обучает модель и не проверяет данные |
| 2 | Метрики, validation, threshold и интерпретацию качества | Кандидат выбирает accuracy для любой задачи |
| 3 | MLOps, мониторинг, latency, drift и релизы | Кандидат говорит только про notebook |
| 4 | LLM, RAG, агентов и безопасность | Кандидат верит промпту как защите |
| 5 | Системное мышление и работу с неопределенностью | Кандидат ищет самую большую модель вместо проверяемой гипотезы |
Перед собеседованием полезно прогнать каждый ответ через короткий фильтр: какие данные доступны в момент предсказания, какая ошибка дороже, где возможна утечка, как проверить гипотезу, что случится в продакшене и как откатиться. Если ответ не проходит этот фильтр, кандидат, скорее всего, знает термин, но не управляет системой.
Главный подвох собеседования на инженера по ИИ прост: интервьюер ищет не человека, который верит в магию моделей, а инженера, который отличает эксперимент от продукта, метрику от цели, промпт от защиты, демо от сервиса и уверенный ответ модели от проверенного факта.
