Middle Data Scientist — Питання на співбесіді data scientist

Розкажіть, як би ви обирали ознаки для моделі відтоку і уникали витоку даних.

Почніть з того, що реально відомо в момент прогнозу: ознака, порахована за даними, що існують лише після настання результату (наприклад, «дні від відкриття листа про скасування підписки», якщо такий лист надсилають уже після того, як людина вирішила піти), протягує мітку прямо у вхід і дає модель, яка чудово виглядає офлайн і провалюється в проді. Після виключення витоків список звужують доменними знаннями, кореляцією з таргетом і чимось на кшталт permutation importance, а потім перевіряють мультиколінеарність серед тих, що лишилися, замість довіри одній метриці важливості у відриві від інших.

Як працює k-fold крос-валідація і чому одного розбиття train/test недостатньо?

Дані ділять на k блоків, навчають на k-1 з них і валідують на решті, потім прогоняють усі k комбінацій і усереднюють результати. Одне розбиття дає одну шумну оцінку, яка сильно залежить від того, які рядки потрапили в тест, — вдале чи невдале розбиття може представити посередню модель чудовою, а гарну — поганою. Крос-валідація міняє обчислювальні витрати на набагато стабільнішу оцінку узагальнювальної здатності моделі, і саме її використовують для чесного порівняння моделей перед вибором.

Як би ви спроєктували A/B-тест для зміни, яка, як ви підозрюєте, дає малий ефект на малотрафіковій сторінці?

Малий очікуваний ефект при низькому трафіку — найгірше поєднання для статистичної потужності, тож перший крок — перевірити за розрахунками, чи взагалі реалізовний тест за розумний час, а не проєктувати його з надією на удачу. Якщо ні, чесні варіанти — розширити цільову аудиторію, збільшити тривалість, перейти на чутливішу метрику (неперервну проксі-метрику замість бінарної конверсії) або погодитися на більший мінімальний детектований ефект і явно зазначити, що дрібніші реальні ефекти залишаться непоміченими.

Коли ви візьмете віконну функцію, а не підзапит, щоб порахувати накопичувальний підсумок у SQL?

Віконна функція на кшталт SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) рахує накопичувальний підсумок за один прохід, не згортаючи рядки, і більшість планувальників запитів оптимізують її значно краще за еквівалентний корельований підзапит, що пересканує попередні рядки для кожного вихідного рядка. Підхід із підзапитом ще трапляється в старих кодових базах і як «наївна» відповідь на співбесіді — вміння вчасно його замінити саме по собі є сигналом зрілості в SQL.

Ви показуєте продакт-менеджеру модель з точністю 92%, і він хоче її викотити. Що перевірити, перш ніж погоджуватися?

Спершу — баланс класів: якщо 92% даних належать до мажоритарного класу, модель, яка завжди передбачає мажоритарний клас, теж дасть 92% accuracy, будучи безкорисною, тому precision, recall і confusion matrix по класах важливіші за саму accuracy. Друге — чи збігається метрика з реальною бізнес-ціною: для детекції шахрайства хибнонегативне дороге, а хибнопозитивне — дрібна прикрість, тож поріг зсувають у бік recall навіть ціною формальної accuracy, і про це кажуть явно, перш ніж модель викотять.