Учен по данни е „човек, който е по-добър в статистиката от всеки софтуерен инженер и по-добър в софтуерното инженерство от всеки статистик“. В „10-те най-големи грешки при кодирането, допуснати от специалисти по данни“ обсъдихме как статистиците могат да станат по-добри програмисти. Тук обсъждаме как програмистите могат да станат по-добри статистици.

Подробен изход и код за всеки от примерите е достъпен в github и в интерактивен бележник. Кодът използва библиотека за управление на работния поток на данни d6tflow и данните се споделят с библиотеката за управление на набор от данни d6tpipe.

1. Не разбирате напълно обективната функция

Учените по данни искат да изградят „най-добрия“ модел. Но красотата е в очите на наблюдателя. Ако не знаете каква е целта и целевата функция и как се държи, е малко вероятно да можете да изградите „най-добрия“ модел. И fwiw целта може дори да не е математическа функция, а може би подобряване на бизнес показател.

Решение: повечето победители в kaggle прекарват много време в разбиране на целевата функция и как данните и моделът са свързани с целевата функция. Ако оптимизирате бизнес показател, съпоставете го с подходяща математическа целева функция.

Пример: Резултатът F1 обикновено се използва за оценка на класификационни модели. Веднъж изградихме класификационен модел, чийто успех зависеше от процента на срещания, който беше правилен. Резултатът от F1 беше подвеждащ, защото показва, че моделът е правилен ~60% от времето, докато всъщност е правилен само 40% от времето.

f1 0.571 accuracy 0.4

2. Да нямате хипотеза защо нещо трябва да работи

Обикновено учените по данни искат да изградят „модели“. Те чуха, че xgboost и произволните гори работят най-добре, така че нека ги използваме. Те четат за задълбочено обучение, може би това ще подобри резултатите допълнително. Те хвърлят модели към проблема, без да са разгледали данните и без да са формирали хипотеза кой модел е най-вероятно да улови най-добре характеристиките на данните. Това също прави обяснението на вашата работа наистина трудно, защото просто хвърляте произволно модели към данни.

Решение: погледнете данните! Разберете неговите характеристики и формирайте хипотеза кой модел е вероятно да улови най-добре тези характеристики.

Пример: Без да изпълнявате каквито и да било модели, като просто начертаете тези примерни данни, вече можете да имате силна представа, че x1 е линейно свързано с y, а x2 няма голяма връзка с y.

3. Не разглеждане на данните преди интерпретиране на резултатите

Друг проблем с това да не разглеждате данните е, че вашите резултати могат да бъдат силно обусловени от отклонения или други артефакти. Това е особено вярно за модели, които минимизират сумите на квадрат. Дори и без отклонения, можете да имате проблеми с небалансирани набори от данни, изрязани или липсващи стойности и всякакви други странни артефакти на данни от реалния живот, които не сте виждали в класната стая.

Решение: толкова е важно, че си струва да го повторим: погледнете данните! Разберете как естеството на данните влияе върху резултатите от модела.

Пример: с отклонения, x1 наклонът се промени от 0,906 на -0,375!

4. Липса на наивен базов модел

Съвременните ML библиотеки почти го правят твърде лесно... Просто сменете ред код и можете да стартирате нов модел. И друг. И друг. Показателите за грешки намаляват, параметрите за настройка — страхотно — показателите за грешки намаляват още повече… С цялата фантазия на модела можете да забравите глупавия начин за прогнозиране на данни. И без този наивен бенчмарк нямате добро абсолютно сравнение за това колко добри са вашите модели, всички те може да са лоши в абсолютно изражение.

Решение: кой е най-глупавият начин да предвидите стойност? Изградете „модел“, като използвате последната известна стойност, (въртящата се) средна стойност или някаква константа, напр. 0. Сравнете производителността на вашия модел с прогнозна маймуна с нулев интелект!

Пример: С този набор от данни за времеви серии модел 1 трябва да е по-добър от модел 2 с MSE съответно от 0,21 и 0,45. Но почакай! Като се вземе само последната известна стойност, MSE пада до 0,003!

ols CV mse 0.215
rf CV mse 0.428
last out-sample mse 0.003

5. Неправилно тестване на извадка

Това е този, който може да провали кариерата ви! Моделът, който създадохте, изглеждаше страхотно в R&D, но се представя ужасно в производството. Моделът, който казахте, че ще направи чудеса, причинява наистина лоши бизнес резултати, потенциално струвайки на компанията $m+. Толкова е важно всички останали грешки, без последната да се съсредоточи върху него.

Решение: Уверете се, че сте пуснали модела си в реалистични условия на изпреварване и разберете кога ще работи добре и кога не.

Пример: В извадката произволната гора се справя много по-добре от линейната регресия с mse 0,048 спрямо ols mse 0,183, но извън извадката се справя много по-зле с mse 0,259 спрямо линейната регресия mse 0,187. Случайната гора е претренирана и няма да се представи добре на живо в продукцията!

in-sample
rf mse 0.04 ols mse 0.183
out-sample
rf mse 0.261 ols mse 0.187

6. Неправилно тестване на извадка: прилагане на предварителна обработка към пълен набор от данни

Вероятно знаете, че мощните ML модели могат да претренират. Претренирането означава, че се представя добре в извадката, но зле извън извадката. Така че трябва да сте наясно с изтичането на данни от обучението в данните от теста. Ако не сте внимателни, всеки път, когато правите инженеринг на характеристики или кръстосано валидиране, данните от влака могат да се вмъкнат в тестови данни и да надуят производителността на модела.

Решение: уверете се, че имате истински комплект за тестване без никакви течове от комплекта за обучение. Особено внимавайте за всякакви зависими от времето връзки, които могат да възникнат при производствена употреба.

Пример: Това се случва често. Предварителната обработка се прилага към пълния набор от данни, ПРЕДИ да бъде разделен на обучение и тест, което означава, че нямате истински тестов набор. Предварителната обработка трябва да се приложи отделно, СЛЕД като данните бъдат разделени на обучаващи и тестови набори, за да се превърне в истински тестов набор. MSE между двата метода (смесена CV на изходна извадка mse 0,187 срещу истинска CV на изходна извадка mse 0,181) в този случай не е чак толкова различна, тъй като характеристиките на разпределение между тренировка и тест не са толкова различни, но това може не винаги да е случай.

mixed out-sample CV mse 0.187 true out-sample CV mse 0.181

7. Неправилно тестване извън проба: данни от напречно сечение и данни от панел

Учили са ви, че кръстосаното валидиране е всичко, от което се нуждаете. sklearn дори ви предоставя някои хубави функции за удобство, така че си мислите, че сте отметнали всички полета. Но повечето методи за кръстосано валидиране правят произволна извадка, така че може да се окажете с тренировъчни данни във вашия тестов набор, което повишава производителността.

Решение: генерирайте тестови данни, така че да отразяват точно данните, върху които бихте направили прогнози при използване на живо в производствена среда. Особено с времеви редове и панелни данни вероятно ще трябва да генерирате персонализирани данни за кръстосано валидиране или да извършите тестване с преобръщане напред.

Пример: тук имате панелни данни за два различни субекта (напр. компании), които са силно свързани помежду си. Ако произволно разделите данните, вие правите точни прогнози, като използвате данни, които всъщност не сте имали на разположение по време на теста, надценявайки производителността на модела. Мислите, че сте избегнали грешка №5, като сте използвали кръстосано валидиране и сте открили, че произволната гора работи много по-добре от линейната регресия при кръстосано валидиране. Но провеждането на roll-forward out-sample test, който предотвратява изтичането на бъдещи данни в теста, отново се представя много по-зле! (произволната гора MSE преминава от 0,047 до 0,211, по-високо от линейната регресия!)

normal CV
ols 0.203 rf 0.051
true out-sample error
ols 0.166 rf 0.229

8. Без да се вземе предвид кои данни са налични в момента на вземане на решение

Когато стартирате модел в производство, той се захранва с данни, които са налични, когато стартирате модела. Тези данни може да са различни от тези, които сте предположили, че са налични в обучението. Например данните може да бъдат публикувани със закъснение, така че докато стартирате модела, други входни данни са се променили и вие правите прогнози с грешни данни или истинската ви променлива y е неправилна.

Решение: направете предварителен тест за извадка. Ако бях използвал този модел в производството, как щяха да изглеждат данните ми за обучение, т.е. какви данни имате, за да правите прогнози? Това са данните за обучение, които използвате, за да направите истински производствен тест извън извадка. Освен това, помислете, ако действате според прогнозата, какъв резултат ще генерира това в момента на вземане на решение?

9. Фино претрениране

Колкото повече време отделяте за набор от данни, толкова по-вероятно е да го претренирате. Продължавате да бърникате с функции и да оптимизирате параметрите на модела. Използвали сте кръстосано валидиране, така че всичко трябва да е наред.

Решение: След като приключите с изграждането на модела, опитайте се да намерите друга „версия“ на наборите от данни, която може да бъде заместител на истински набор от данни извън извадката. Ако сте мениджър, съзнателно пазете данни, за да не се използват за обучение.

Пример: Прилагането на моделите, обучени върху набор от данни 1, към набор от данни 2 показва, че MSE са се увеличили повече от два пъти. Все още ли са приемливи...? Това е преценка, но вашите резултати от #4 може да ви помогнат да решите.

first dataset
rf mse 0.261 ols mse 0.187
new dataset
rf mse 0.681 ols mse 0.495

10. заблуда „имам нужда от повече данни“.

Противно на интуицията, често най-добрият начин да започнете да анализирате данни е като работите върху представителна извадка от данните. Това ви позволява да се запознаете с данните и да изградите тръбопровода за данни, без да чакате обработка на данни и обучение на модела. Но учените по данни изглежда не харесват това - повече данни е по-добре.

Решение: започнете да работите с малка представителна извадка и вижте дали можете да извлечете нещо полезно от нея. Върнете го на крайния потребител, може ли да го използва? Решава ли истинска болезнена точка? Ако не, проблемът вероятно не е защото имате твърде малко данни, а във вашия подход.

За допълнителни подробности вижте изхода и кода за всеки от примерите в github и в интерактивен бележник.