Как да правим таблични прогнози без обучение с NVIDIA Structured Data Models
В този урок реализираме Structured Data Models — новата библиотека на NVIDIA, която поставя няколко предварително обучени фундаментални модела за таблици зад един PyTorch интерфейс, и я използваме за генериране на прогнози без обучение. Библиотеката обвива TabICLv2 и KumoTabular за отделни таблици и KumoRelational за цели релационни бази данни, като всеки от тях отговаря чрез обучение в контекст: подаваме на модела набор от редове с етикети и редовете, за които искаме прогноза, а той връща вероятности или пълно предсказателно разпределение с един forward pass. Започваме с типизираните таблични тензори на библиотеката, сравняваме двата таблични модела с обучени базови модели от scikit-learn, използваме повторно кодиран контекст за множество заявки, извличаме калибрирани прогнозни интервали от регресия и мащабираме до двадесет класа. След това разглеждаме случаите, в които настройките по подразбиране тихомълком дават грешен резултат: рецепта за предварителна обработка, която премахва колони с времеви отпечатъци и текст, както и обяснител с два скрити капана, преди да изградим малка база данни на магазин с три таблици и да прогнозираме активността на клиентите директно от нея, включително единствения аргумент, който отделя честния релационен модел от модела с изтичане на информация. Вижте пълния код тук.
Инсталираме Structured Data Models от GitHub хранилището, фиксирано към комита, спрямо който този notebook е проверен, тъй като пакетът в PyPI е само заместител. Релационният sampler също се нуждае от pyg-lib и именно тук се появява първият капан. Wheel пакетите на pyg-lib се публикуват за всяка minor версия на PyTorch на страници с имена като torch-2.14.0+cpu, но собственият ImportError на библиотеката изгражда URL адреса от точната patch версия — torch-2.14.1+cpu, което е празна страница, така че следването на указанията му води до грешка. Вместо това изграждаме URL адреса на индекса от major и minor версията. Изпълняваме всичко на CPU, което е пътят, проверен от край до край тук, и отпечатваме моделите, предоставяни от библиотеката, заедно с размерите на checkpoint-ите и лицензите им; двата модела на Google, които библиотеката също обвива — TabFM и TimesFM 3 — са големи и с нетърговски лиценз и затова не ги използваме. Вижте пълния код тук.
Всичко в библиотеката преминава през TableTensor — подклас на PyTorch тензор, който поддържа по един типизиран блок за всеки семантичен тип: числов, категориален, дата и час, текст и идентификатор. infer_stypes определя типовете и с настройките си по подразбиране допуска две грешки при реалистична рамка с тикети за поддръжка: свободният текст в comment се превръща в категориална променлива с четиристотин нива, а идентификаторът на тикета става число, така че и двете колони биха достигнали до модела като характеристики. Подаването на флаговете за infer на текст и идентификатори отстранява проблема. Обратното преобразуване към pandas запазва всяка стойност, включително липсващите, но не и всеки тип данни: числата се връщат като float32, тъй като числовият блок е един общ float тензор; nullable целите числа стават числа с плаваща запетая с NaN, а категориалните низове се връщат като pandas category. При pandas 2.x низовите колони се отпечатват като object, а не като str, и времевият отпечатък се подава с наносекундна резолюция; същите стойности се връщат и в двата случая. Има още един капан, който е добре да знаете, преди да заредите реален лог на събития: библиотеката съхранява датите и часовете като цели числа в микросекунди, а Arrow отказва всяко преобразуване, което би премахнало цифра. Колона в наносекунди с цели секунди се преобразува без проблем, но една-единствена стойност с наносекундни цифри проваля цялата колона, затова първо закръгляме времевите отпечатъци надолу до микросекунди. Вижте пълния код тук.
Табличните модели приемат редове с етикети за контекст и редове без етикети за заявка и връщат TableTensor с по една колона с вероятности за всеки клас, именувана според етикета, така че няма стъпка за fit и няма хиперпараметри. В набора от данни за рак на гърдата, с триста реда с етикети и двеста шестдесет и девет реда за прогнозиране, TabICLv2 и KumoTabular достигат точност 0.970 и AUC съответно 0.996 и 0.995 без обучение, в сравнение с 0.970 и 0.993 за логистична регресия и 0.967 и 0.992 за gradient boosting, като и двата базови модела са обучени върху същите триста реда. num_estimators определя колко различно предварително обработени изгледа на данните усреднява моделът — това е вграденото ансамблиране на библиотеката.
Директното извикване на модела кодира контекста наново при всяко извикване. Когато едни и същи редове с етикети трябва да отговорят на множество партиди от заявки, fit кодира контекста веднъж в кеш от ключове и стойности, а predict обработва само редовете от заявката; clear освобождава кеша. Във fit не се научава нищо — тук това означава да се запомнят тези примери. Отговарянето на пет партиди по тридесет реда спрямо един и същ контекст от четиристотин реда завърши няколко пъти по-бързо по този начин на нашия CPU, а след кеширането на контекста всяка следваща партида струваше малка част от пълния forward pass. Точното съотношение зависи от машината, затова клетката го измерва, вместо да приема предварително определена стойност.
При регресия моделът не връща едно-единствено число. Той връща 999 квантилни стойности за всеки ред от заявката — пълно предсказателно разпределение, извлечено от един forward pass. В набора от данни за диабет с триста реда с етикети медианата на това разпределение има RMSE 53.6, малко по-добра от 54.3 при RidgeCV и значително по-добра от 64.7 при gradient boosting, като и двата модела са обучени върху същите редове. По-полезното свойство е калибрирането: интервалът между 10-ия и 90-ия процентил съдържа 81.0 процента от целевите стойности в тестовата извадка, а интервалът между 5-ия и 95-ия процентил — 91.5 процента, близо до номиналните им 80 и 90 процента, докато 50-процентният интервал е малко тесен — 43.7 процента.
Предварително обученият класификационен слой има фиксиран брой позиции за класове, а библиотеката обработва задачи с повече класове чрез error-correcting output codes, като разделя проблема на по-малки кодирани подзадачи и комбинира логаритмите на вероятностите. Извикващият никога не вижда тази вътрешна логика: при балансиран синтетичен проблем с двадесет класа и тридесет означени реда за всеки клас TabICLv2 връща двадесет колони с вероятности и достига точност 0.760 с един forward pass, в сравнение с 0.615 за gradient boosting, обучен върху същите редове.
Предварителната обработка в библиотеката представлява Recipe от композируеми процесори, а стандартната рецепта на TabICLv2 използва семантичния тип и има разклонения само за категориални и числови колони. Следователно колоните с времеви отпечатъци и текст никога не се превръщат в характеристики. При тикети за поддръжка, чието ескалиране зависи от момента на отваряне и от думи като refund, стандартната рецепта достига AUC 0.525 — близо до случайното познаване. Библиотеката действително извежда RuntimeWarning, който посочва пренебрегнатите типове колони. Това предупреждение обаче се показва само веднъж: появява се при първото извикване и се потиска за останалата част от процеса, така че всеки следващ модел в същия notebook или service премахва тези колони без предупреждение. Проблемът се отстранява чрез добавяне на два процесора: AddCalendarFields превръща времевия отпечатък в циклични характеристики за час и ден от седмицата и повишава AUC до 0.634, а TFIDF добавя термините от коментара и повишава AUC до 0.789.
GradientExplainer на библиотеката връща градиента на избран изход спрямо предварително обработените входове на заявката. Тестваме го върху синтетични данни, при които значение имат само три от осемте характеристики и знаците им са известни. Той има два капана, които се виждат само ако разгледаме какво получава функцията за изход. Първо, функцията се извиква веднъж за всеки estimator, като всяко извикване презаписва предишния резултат, така че при четири estimator-а функция за изход, активна само при първото извикване, води до обяснение от нули, а полученото обяснение е само за последния estimator. Второ, необработеният изход на всеки estimator има собствен ред на класовете, тъй като стандартната рецепта разбърква етикетите на класовете за всеки estimator. При обяснение с един estimator за шест различни начални стойности изборът на вероятността за клас едно чрез позицията на колоната обръща знака на всяка характеристика при двете начални стойности с обърнат ред, докато изборът по име на колоната дава правилния знак и при шестте. Усредняването по началните стойности възстановява трите реални характеристики, а шумовите характеристики остават близо до нула.
KumoRelational приема релационна база данни вместо една таблица. Генерираме малък магазин с осемстотин клиенти, шестдесет продукта и една година поръчки, при който активността на някои клиенти се срива на случайна дата, и питаме дали всеки клиент ще направи нова поръчка в рамките на тридесет дни след определен момент. RelationalData съдържа таблиците и външните ключове между тях, а sampler-ът обхожда тези ключове навън от всеки ред на задачата и събира до шестнадесет съседи на всяка стъпка. Посочването на датата на поръчката като времева колона прави обхождането времево: проверяваме, че най-късната поръчка, върната за ред на задачата с дата първи юни, е направена на тридесет и първи май, така че редовете, определящи етикета, остават недостъпни.
След това отговаряме на същия въпрос по три начина. TabICLv2 само върху таблицата с клиенти, разполагащ единствено с регион и план, достига AUC 0.556. TabICLv2 върху шест ръчно създадени характеристики на историята — поръчки и разходи през последните тридесет и деветдесет дни, дни от последната поръчка и общ брой поръчки, изчислени стриктно преди всеки cutoff — достига 0.828. KumoRelational върху необработените таблици, без ръчно създадени характеристики, достига 0.823. Релационният модел се доближава до ръчно изградената система с грешка, дължаща се почти само на закръглянето, като чете самите редове с поръчки чрез ключовете и се съобразява с времевия отпечатък на всеки ред от задачата.
Накрая изпълняваме същия релационен модел, без да декларираме времевата колона. AUC се повишава до 0.940. Без времева колона sampler-ът може да върне поръчки, направени след cutoff-а, а именно тези поръчки определят етикета, така че моделът вече не прогнозира, а прочита отговора, без да възниква грешка. В реална база данни релационен модел, който е подозрително по-добър от ръчно изградената базова система, трябва първо да бъде изпълнен повторно с декларирани всички времеви колони.
Обобщението отпечатва едноредовия резултат, върнат от всеки раздел, и трите навика, които си струва да пренесем в практиката: декларирайте внимателно семантичните типове и рецептите, избирайте класовете по име в обяснителя и обяснявайте с един estimator, както и добавяйте всяка таблица с времева колона към time_columns. След това насочва към примерите за дообучаване, RelBench и изпълнение върху GPU.
В заключение, Structured Data Models на NVIDIA изпълнява основното си обещание: при класификация, регресия, задача с двадесет класа и база данни с три таблици предварително обучените му модели се изравниха или надминаха базовите модели от scikit-learn, обучени върху същите редове, без самите те да бъдат обучавани, предоставиха калибрирани предсказателни разпределения без допълнителни усилия, а при релационния случай достигнаха точността на ръчно изградена система от характеристики, използвайки необработените таблици. Настройките по подразбиране заслужават по-внимателна проверка от самите модели. Свободният текст и идентификаторите не се откриват, освен ако изрично не ги поискате; стандартната рецепта премахва колоните с времеви отпечатъци и текст и предупреждава само веднъж за процеса; обяснителят отчита само последния estimator и изисква класовете да бъдат избирани по име; URL адресът за pyg-lib в собственото съобщение за грешка на библиотеката води към празна страница; а релационен модел без времевата си колона генерира впечатляващо, но безсмислено число. Всеки от тези проблеми има едноредово решение и всеки иначе би останал незабелязан. Това е практическият урок, който трябва да пренесем към реалните данни: проверявайте какво достига до модела, преди да се доверите на това, което излиза от него.
Вижте пълния код тук. Цялата заслуга е за изследователя на този проект. Също така не се колебайте да ни последвате в Twitter и не забравяйте да се присъедините към нашия SubReddit за машинно обучение с над 150 хиляди членове и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? Вече можете да се присъедините към нас и в Telegram.
Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.