neptune.ai се превърна в съществена част от много инструменти на Kaggle Grandmasters. Състезанията по машинно обучение изискват ефективно организиране и проследяване на голям брой експерименти и бързо повторение. В типичните състезания на Kaggle най-добрите отбори могат да изпълнят между 1500 и 3000 експеримента, търсейки постепенни печалби в представянето. Neptune улеснява това бързо експериментиране чрез централизиране на ключови метаданни за изпълнение като параметри, показатели, артефакти и родословия за лесни заявки и анализ. Видимостта, която Neptune осигурява в динамиката на обучението на модела и показателите за ефективност, ускорява идентифицирането на ефективни архитектури и конфигурации на хиперпараметри.

Наскоро д-р Кристоф Хенкел (известен още като „Дитер“) и аз постигнахме челна позиция в „Предизвикателството за разпознаване на пръстовия правопис на американски жестомимичен език“ на Google. Аз съм AI изследовател в doubleyard компания за AI решения, а също и kaggle grandmaster (известен още като darragh), който в момента е класиран на 12-то място в класацията на състезанието, докато Кристоф е старши учен за дълбоко обучение в Nvidia в KGMON team и в момента е на 1-во място в класацията на Kaggle.

Целта на това състезание беше да се открие и преведе изписването с пръсти на американския жестомимичен език (ASL) в текст. Данните включват повече от три милиона знака, изписани с пръсти, създадени от над 100 глухи подписващи, заснети чрез селфи камерата на смартфон с различни фонове и условия на осветление. На състезателите бяха предоставени 60 000 фрази за изписване с пръсти, с 3D ключови точки на ръцете, лицето и позата и трябваше да доставят модели Tensorflow-lite за декодиране на фразата, която се подписва.

Тази статия ще разгледа пример за стека MLOps на Neptune за това предизвикателство и как обикновено провеждаме експерименти.

Както винаги, първата стъпка е да настроите github repo, slack канал, aws s3 контейнер за съхранение на големи файлове и проект Neptune, нашия стек MLOps. „Github repo“ е настроено за справка, ако искате да опитате.

Както е обяснено в репото, за да настроите вашия проект Neptune, вижте полезния бърз старт и поставете вашия API токен в .env файл, както е обяснено в репото. Освен това следвайте инструкциите за изтегляне на данни в README на репото.

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

В репото ще видите файла за обучение, train.py. „Тук“ свързваме експеримента с Neptune и регистрираме свързаните експериментални файлове.

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

Можем също да „предаваме статични конфигурации“, като например конфигурационни файлове.

Архитектурата на модела, който използвахме за разрешаване на изписване с пръсти, е модифициран енкодер SqueezeFormer[1] заедно със стандартен трансформаторен декодер, базиран на причинно-следствена връзка[2]. По-долу е тръбопроводът и можете да прочетете повече за него тук.

В този експеримент се опитваме да променим конфигурацията на енкодера да има само 4 слоя, така че копираме един от експериментите и променяме конфигурационния файл.

cp configs/cfg_dh_61g0.py configs/cfg_dh_61g3.py

И променете реда по-долу в копирания файл.

След като всичко е настроено, можете да започнете, като стартирате:

python train.py -C cfg_dh_61g3

В командния ред ще видим нашия URL разпечатан и можем да преминем към Neptune, за да видим как се представя.

# python train.py -C cfg_dh_61g3
https://app.neptune.ai/light/asl/e/ASL-55
Neptune system id : ASL-55
Neptune URL : https://app.neptune.ai/light/asl/e/ASL-55
Target checkpoint : checkpoint_ASL-55.pth
Train epoch 0: 16%|███████████████████████

Работата ни се появява в конзолата и можем веднага да влезем.

Под секцията за наблюдение можем да видим използването на паметта и изглежда, че далеч не ни липсва памет.

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

Можем да проследим загубата на работа под Графики и виждаме, че загубата намалява и все още сме в етапа на загряване на скоростта на обучение на обучението.

Нашият модел скоро достига първата епоха на валидиране, където ще видим резултата на модела, измерен от нашия метричен файл. Така че нека сравним с предишни изпълнения как се представя моделът. Ние правим това, като избираме сравнителните експерименти в секцията Runs и на всеки от тях се задава различен цвят. В това меню можем също така да добавяме нови колони към общия преглед, за да сравняваме бързо между експериментите — как са отбелязани и някои от по-важните конфигурации на експеримента.

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

Можем също да превъртим надолу до резултатите и виждаме този нов експеримент да се оценява подобно на другите сравними експерименти в първата епоха на валидиране, така че досега няма проблеми.

Ако искаме да разгледаме директно разликите в конфигурацията, можем да отидем в изгледа един до друг и да изберем само конфигурациите на експериментите, които имат разлики.

Ако се интересуваме само от някои от диаграмите, можем да създадем табло за управление, за да преминем бързо към любимия ни изглед на всеки от любимите ни показатели.

Както и да можете да увеличавате прозорците на изгледа.

Ако искате да разгледате средната стойност, групирана по определена конфигурация, можете да използвате groupby и да изберете експериментите, които бихме искали да видим в средната стойност groupby, и след това да отидете на диаграмите. В този пример групираме по слоеве на енкодер. Можем да видим по-долу загубата на нашите задачи с 6 слоя на енкодера намалява по-бързо, отколкото с 4 или 14 слоя.

Това е особено полезно, ако имаме нестабилни резултати за валидиране. В този случай можем да проведем всеки експеримент върху 5 гънки — и да осредним резултатите от различни модели за гънки и да получим по-стабилно сравнение между гънките.

Така че работата ни върви бързо, но изглежда, че кривата на загубите не се сближава достатъчно бързо. Можем да убием заданието от таблицата Run с помощта на Remote Abort. Получаваме полезно съобщение, което ни информира, че е избрана само една работа, така че потвърдете прекъсването.

Обратно в нашата виртуална машина съобщението е получено и работата е убита.

И нека актуализираме нашия екип на Kaggle за експеримента.

Тук се докоснахме само до някои от функционалностите. Можем също да регистрираме примерни данни като изображения, да улавяме изключения или да споделяме тегла на модели и много други.

По-долу е нашият действителен проект neptune.ai от състезанието. Но сега е време да приключим с това и да преминем към следващото.

Приложение

[1] S. Kim, A. Gholami, A. Shaw и др., „Squeezeformer: Ефективен трансформатор за автоматично разпознаване на реч“, arXiv preprint arXiv:2206.00888, 2022.

[2] A. Vaswani, N. Shazeer, N. Parmar и др., „Вниманието е всичко, от което се нуждаете,“ Напредък в системите за обработка на невронна информация, том. 30, 2017 г.