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

Какво е гниене на модела?

Гниене на модели, гниене на данни, гниене на AI, както искате да го наречете, не е добре! Да кажем, че сме изградили модел, който предсказва дали едно зомби е приятелско или не. Разполагаме го в облака и сега приложения по целия свят го използват, за да помогнат на широката общественост да знае с кои зомбита могат да се сприятеляват, без да бъдат ухапани. Удивително, хората изглеждат супер доволни от вашия модел, но след няколко месеца започвате да получавате гневни имейли от хора, които казват, че моделът ви е ужасен! Оказва се, че популацията на зомбитата е мутирала! Сега вашият модел е остарял, илискак! Трябва да актуализирате модела си и още по-добре да добавите начин, по който да следите състоянието на гниене на вашите модели, така че това да не се случва отново.

Не само зомбитата се променят

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

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

Да се ​​борим с гниенето на модела (с ML Engine + DataStore)

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

Използвахме Scikit-Learn, за да изградим модел на класификатора на дървото на решенията. Вижте бележника тук, за да видите точния код за това.

Сега планът е да внедрим нашия модел в ML Engine, който ще хоства нашия модел за нас в облака. (вижте как правим това с помощта на gcloud команди в бележник)

Първо ще хвърлим нашия модел в облачно хранилище:

gsutil cp model.joblib gs://your-storage-bucket/v1/model.joblib

След това създайте нов модел на ML Engine, което можете да направите с помощта на потребителския интерфейс на Google Cloud Console или с помощта на командите gcloud (които можете да видите тук използвани в бележник):

След това внедряваме нашия модел на дървото на решенията като версия 1:

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

Добре, нашият модел е разгърнат и приложенията могат лесно да извличат прогнози от него! Сега за наблюдение за гниене на модела с DataStore!

DataStore?

Представете си място в облака, където можете бързо да съхранявате милиони речници на Python и след това да правите заявки към тях (също бързо). Това е DataStore, напълно управлявана NoSQL база данни в Google Cloud Platform. Ако имате предишен опит с бази данни, може да сте свикнали внимателно да планирате точно каква структура от данни да съхранявате в таблици, след това изпитайте болката от създаването на скриптове за мигриране, за да актуализирате структурата на вашата база данни. Без тези глупости с DataStore, искам да съхранявам следните данни:

{
  "name": "Alex"
  "occupation": "Zombr trainer"
}

след това го направете (използвайки клиентската библиотека на python):

# create new entity/row
new_person = datastore.Entity(key=client.key('person'))
new_person['name'] = 'Alex'
new_person['occupation'] = 'Zombr trainer'
# save to datastore
client.put(new_person)

О, чакай, искаш ли да започнеш да съхраняваш githubs и twitters на хората? направи го:

# create new entity/row
new_person = datastore.Entity(key=client.key('person'))
new_person['name'] = 'Zack'
new_person['occupation'] = 'Zombr CEO'
new_person['github'] = 'https://github.com/zackakil'
new_person['twitter'] = '@zackakil'
# save to datastore
client.put(new_person)

и DataStore ще каже „благодаря“:

Използване на DataStore за събиране на обратна връзка за модела

Данните за обратна връзка, които ще съберем, ще изглеждат по следния начин:

{
"model": "v1",
"prediction input": [2.1, 1.4, 5.3, 8.0],
"prediction output": 1,
"was correct": False,
"time": "23-10-2018,14:45:23"
}

Тези данни ще ни кажат коя версия на нашия модел на ML Engine е използвана за генериране на прогнозата (модел), какви са входните данни за прогнозата (въвеждане на прогноза), каква е била прогнозата, направена от модела (изход за прогноза), дали прогнозата е била правилна (действителната обратна връзка от потребителя) (бе правилна) и времето, когато обратната връзка беше изпратена (време).

Ще използваме Cloud Functions отново, за да създадем друга крайна точка на уеб API, този път за получаване на данните за обратна връзка и съхраняването им в DataStore:

Сега нашата системна архитектура изглежда така:

Клиентските приложения просто трябва да добавят по интуитивен начин, за да могат потребителите да изпратят своите отзиви. В нашия случай това може да е проста подкана „палец нагоре или палец надолу“, след като потребителят получи прогноза:

Бъдете креативни с начина, по който събирате обратна връзка

Често пъти можете да направите извод за обратна връзка за вашия модел, вместо изрично да я поискате от потребителите, както направих в Zombrинтерфейса. Например, ако видим, че потребител спира да използва приложението веднага след прогноза, можем да използваме тези данни, за да посочим грешна прогноза 😬.

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

Обратната връзка се събира, сега какво?

Сега можем да анализираме данните от обратната връзка. За всяка работа по анализ на данни по подразбиране използвам Jupyter Notebooks.

Щракнете тук за пълния бележник за това как извличам данни от DataStore и анализирам обратната връзка.

Важните части от извличането на данни от DataStore са първо инсталиране на клиентската библиотека DataStore python:

pip install google-cloud-datastore

след това можете да го импортирате и да се свържете с DataStore:

from google.cloud import datastore
# connect to DataStore
client = datastore.Client('your project id')
# query for all prediction-feedback items 
query = client.query(kind='prediction-feedback') 
 
# order by the time field 
query.order = ['time'] 
 
# fetch the items 
# (returns an iterator so we will empty it into a list) 
data = list(query.fetch())

Библиотеката с автоматично конвертиране на всички данни в речници на Python:

print(data[0]['was correct'])
print(data[0]['model'])
print(data[0]['time'])
print(data[0]['input data'])
>>> True
>>> v1
>>> 2018-10-22 14:21:02.199917+00:00
>>> [-0.8300105114555543, 0.3990742221560673, 1.9084475908892906, 0.3804372006233603]

Благодарение на това, че запазихме логическо значение „беше правилно“ в нашите данни за обратна връзка, можем лесно да изчислим точността на нашия модел от обратната връзка, като разгледаме съотношението „Вярно“за това поле:

number_of_items = len(data)
number_of_was_correct = len([d for d in data if d['was correct']])
print(number_of_was_correct / number_of_items)
>>> 0.84

0,84 не е много гниене, тъй като ние първо обучихме нашия модел, който отбеляза ~0,9 точност, но това се изчислява, като се използват всички данни за обратна връзка заедно. Какво ще стане, ако направим същото изчисление на точността на плъзгащ се прозорец в нашите данни и го начертаем? (можете да видите кода за това в бележника за анализ)

Това е голям спад в производителността за най-новите отзиви.

Трябва да проучим допълнително. Нека сравним входните данни (т.е. данните за характеристиките на зомбитата) от времената с висока точност с времената с ниска точност. Добре, че събрахме и това в нашите отзиви:

А, данните изглеждат съвсем различно. Предполагам, че популацията на зомбитата е мутирала! Трябва да обучим отново нашия модел възможно най-скоро с нови данни. Добре, че събрахме входните данни в обратната връзка, можем да ги използваме като нови данни за обучение (спестява ни необходимостта ръчно да събираме нови данни). Можем да използваме информация за прогнозата, направена от модела (поле „предсказание“) и отзивите на потребителите (поле „беше правилно“), за да изведем правилния етикет на прогнозата за новите данни за обучение:

Вижте как се използва този код в долната част на бележника за анализ на обратната връзка.

С този нов набор от данни можем да обучим нова версия на нашия модел. Това е идентичен процес на обучение на първоначалния модел, но с помощта на различен набор от данни (вижте бележника) и след това качването му в ML Engine като нова версия на модела.

След като е на ML Engine, можете или да го зададете като нова версия по подразбиране на модела зомбита, така че всичките ви клиенти автоматично да започнат да изпращат своите заявки за прогнозиране към новия модел, или можете да инструктирате клиентите си да посочат името на версията в техните искания за прогнозиране:

Ако зададете модела по подразбиране на v2, тогава всички заявки за прогнозиране към „зомбита“ ще отидат към версия v2:

PREDICTION REQUEST BODY:
{
"instances":[[2.0, 3.4, 5.1, 1.0]],
"model":"zombies"
}

или вашите клиенти могат просто да бъдат по-конкретни:

PREDICTION REQUEST BODY:
{
"instances":[[2.0, 3.4, 5.1, 1.0]],
"model":"zombies/versions/v2"
}

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

Надяваме се, че това ви е дало няколко идеи за това как можете да наблюдавате вашите внедрени модели за гниене на модели. Целият използван код може да бъде намерен в github repo:



ZackAkil/rotting-zombie-model
🧟 Ресурси за борба срещу гниенето на вашите внедрени модели за машинно обучение. Предсказване на зомбита! …github.com



Обърнете се към мен @ZackAkil с всякакви мисли/въпроси относно гниенето на модела за наблюдение.