У проєкті з детектором шахрайських оголошень поділ на навчальну й тестову частини зробили ДО розвідки даних. Навіщо, адже розвідка модель не навчає?
Чому так. Розвідка змінює тебе, а не дані. Побачив довгий хвіст у ціні — вирішив узяти логарифм; побачив чотири дивні рядки — вирішив їх прибрати. Кожне таке рішення підігнане під те, що ти бачив. Якщо серед побаченого був тест, він перестав бути незалежним ще до першого навчання. Однакову частку класів дає stratify, і це окреме питання; швидкість тут узагалі ні до чого.
Питання 2 / 8
Базова лінія (константа «всі оголошення чесні») дала accuracy 0.838 і F1 0.000. Як це читати?
Чому так. Обидва числа описують ту саму константу. 84 % береться просто з того, що чесних оголошень 84 %, — щоб отримати цю цифру, не треба вміти нічого. F1 = 0 тут не помилка, а точний опис: жодного шахрая не знайдено, отже recall дорівнює нулю. Саме тому базову лінію рахують першою: без неї «наша модель має 94 %» не читається.
Питання 3 / 8
Логістична регресія на вихідних стовпцях дала F1 = 0.013 при базовій лінії 0.000. Який висновок правильний?
Чому так. Правило з теми 28: якщо проста модель не відірвалась від базової лінії, складніша майже напевно теж не відірветься — вона не знайде того, чого в стовпцях немає. Це підтвердилось: одна ознака |ln(ціна ÷ типова)| підняла F1 з 0.013 до 0.835, а заміна моделі на випадковий ліс результат погіршила.
Питання 4 / 8
У проєкті метрику (F1) записали до першого навчання. Чому не можна обрати її потім, коли вже видно результати?
Чому так. Це не питання чесності, а того, як працює голова, якій показали шість чисел і попросили вибрати найкраще. Метрика має випливати з ціни помилки: пропущений шахрай коштує покупцеві грошей, хибна тривога ображає чесного продавця — звідси потрібні одночасно recall і precision, тобто F1. Технічних перешкод рахувати метрику потім немає взагалі; перешкода тільки в тому, що вибір перестане бути чесним.
Питання 5 / 8
Крос-валідація дала F1 = 0.844, тест — 0.796. Що це означає?
Чому так. Шість поєднань у сітці — шість спроб, і найкраще з шести числ уже містить дрібку везіння (тема 24). Тест цього відбору не бачив, тому й показує менше. Правильне очікування якості в бою — 0.796, а не 0.844. Міряти ще раз після зміни моделі не можна: другий погляд перетворює тест на ще одну перевірочну вибірку.
Питання 6 / 8
Колега пропонує: «Подивимось на тест ще раз, але нічого міняти не будемо — просто цікаво, де модель помиляється». Що з цим не так?
Чому так. «Просто подивитись» не буває. Побачив, що модель провалюється на дорогих телефонах, — далі або міняєш щось (і тест уже підігнаний), або не міняєш, і погляд був марний. Для «просто подивитись» існує крос-валідація: у проєкті всі 45 помилок розбирали саме на прогнозах cross_val_predict, а тест лишався закритим.
Питання 7 / 8
Розбір помилок показав: 62 % усіх помилок припадає на оголошення без ціни, а таких рядків лише 8 %. Яка дія тут правильна?
Чому так. Головна ознака побудована з ціни, а тут ціни немає — і серед цих рядків шахрайських 54 %, тобто майже підкидання монети. Ознака не допоможе, бо будувати її нема з чого. Викидати рядки теж не можна: вони існують у бою. Це рішення про продукт, і воно себе виправдало — на тесті F1 склав 0.900 на оголошеннях із ціною проти 0.606 на решті.
Питання 8 / 8
Детектор запустили, і перші два тижні він працює так, як показав тест. Що правильно очікувати далі?
Чому так. Модель у продакшні деградує завжди. Карта типових цін застаріває, бо телефони дешевшають і виходять нові моделі; а детектор, навчений на «дешева приманка», перестане працювати того дня, коли шахраї почнуть ставити ціну біля типової. Сама себе модель не донавчає — це окремий механізм, який треба збудувати. Тому план заміру якості після запуску — обовʼязковий пункт чекліста, і найчастіше порожній.