Какие данные использовали в проектах
Что проверяют
Работали ли вы с настоящими грязными данными и понимаете ли, где возникают ошибки в оценке качества.
Как отвечать
Отвечайте по конкретному проекту, а не перечнем.
Источник и объём. Откуда пришли данные: выгрузки из базы продукта, события пользователей, внешние API, открытые наборы, ручная разметка. Сколько строк, за какой период, как обновляются.
Тип. Табличные, текст, изображения, временные ряды, логи. От этого зависит всё остальное.
Качество, и это самое интересное для интервьюера: пропуски и как их обрабатывали, выбросы, дубли, несогласованные справочники, изменение формата во времени. Реальные данные почти всегда содержат сюрприз вроде поля, которое полгода назад заполнялось иначе.
Разметка. Кто размечал, сколько объектов, проверялась ли согласованность между разметчиками. Низкое согласие означает, что и модель не сможет выучить больше.
Деление на выборки. Тут кроется главная ошибка: при временной зависимости деление обязано быть по времени, иначе модель подглядывает в будущее и метрика на валидации завышена. Аналогично при повторяющихся объектах группировка должна идти по сущности, а не по строке, иначе почти одинаковые записи попадут и в обучение, и в проверку.
Утечки признаков. Признак, которого в момент предсказания ещё не существует, даёт великолепную метрику и бесполезную модель. Проверять надо специально: подозрительно высокое качество это повод для расследования.
Приватность. Персональные данные обезличиваются, доступ ограничивается, в признаки они не попадают без необходимости.
Хранение и воспроизводимость. Где лежат наборы, версионируются ли, можно ли повторить эксперимент через полгода.
Где спотыкаются
Перечисляют наборы без описания проблем с ними.
Делят временные данные случайно.
Не проверяют утечку и радуются высокой метрике.
Не могут сказать, как обновляются данные в проде.