В следващите минути ще говорим за този проект от край до край, базиран на прогнозиране на заема.

Разработете алгоритъм за прогнозиране на неизпълнението на клиент за заеми за превозни средства чрез идентифициране на ключови атрибути.

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

Като начало е важно да споменем, че компаниите са екипи, които вече работят, така че ако ще направим модел, той трябва да бъде представен като продукт и по същия начин трябва да бъде разположен в облак с помощта на на докери и облачно изпълнение. По принцип говоря за CI/CD тръбопровод, което означава, че веднага щом ангажирам нещо оттук автоматично, вашето внедряване трябва да се случи в облака.

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

def risk(df):

    risk_col = []

    for i in df['PERFORM_CNS.SCORE.DESCRIPTION']:
      if ('Very Low' in i):
          risk_col.append('Very Low Risk')
      elif ('Low' in i):
          risk_col.append('Low Risk')
      elif ('Medium' in i):
          risk_col.append('Medium Risk')
      elif ('High' in i):
          risk_col.append('High Risk')
      elif ('Very High' in i):
          risk_col.append('Very High Risk')
      else: 
          risk_col.append('Not Scored')
    
    df['risk'] = risk_col
    return risk

Ние също използваме chi2, за да изберем важността на функциите.

from sklearn.feature_selection import SelectKBest,chi2

n = SelectKBest(score_func = chi2, k = 'all')
catcols = n.fit(df1, train_df['loan_default'])
plt.figure(figsize = (7,5))
sns.barplot(x = catcols.scores_, y = df1.columns)
plt.title('Best Categorical Features')
plt.show()

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

from sklearn.ensemble import ExtraTreesClassifier

model = ExtraTreesClassifier()
model.fit(df1, train_df['loan_default'])

В частта за анализ на цифровите характеристики не можем да изпуснем данните за вторичната сметка, тъй като те се изискват от институциите преди отпускане на заем.

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

Правейки същата стъпка от следващата корелационна топлинна карта, можем да видим, че някои от характеристиките са силно корелирани (›0,75) една с друга.

От горната корелационна топлинна карта можем да видим, че някои от характеристиките са силно корелирани (›0,75) помежду си.

• — — изплатена сума и цена на актива — 0,75

• — — perform_cns.score и риск — 0,98

• — — средна_възраст_на_акт и дължина_на_кредитната_история — 0,83

• — — брой_сметки и активни_сметки — 0,76

  • — — sanctioned_amount и psdisbursed_amount — 1

Оставяме тези функции, защото не са най-високо класирани.

to_drop = ['asset_cost','PERFORM_CNS.SCORE','AVERAGE.ACCT.AGE','no_of_accts','psdisbursed_amount','DELINQUENT.ACCTS.IN.LAST.SIX.MONTHS']
train_df=train_df.drop(columns=to_drop)
test_df=test_df.drop(columns=to_drop)

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

# Removing few more outliers/extreme values

train_df = train_df[train_df['disbursed_amount']<250000]
train_df = train_df[train_df['outstanding_amount']<40000000]
train_df = train_df[train_df['sanctioned_amount']<0.800000e+08]
train_df = train_df[train_df['install_amt']<=5.000000e+06]

В частта за моделиране използваме стандартен скалер и фактора на инфлация на дисперсията. Един проблем с корелацията на топлинната карта е сигурността на причинно-следствената връзка. Наличието на 2 характеристики с мултиколинеарност и ако стойностите на VIF са ≥ 10 се счита за проблем

from statsmodels.stats.outliers_influence import variance_inflation_factor as vif
vf = [vif(Xscaled.values, i) for i in range(X.shape[1])]
pd.DataFrame(vf, index=train_df.drop('loan_default',axis=1).columns, columns=['vif'])

Със Sckit-learn създадохме различни модели:

  • — — линейни регресии
  • — — Произволен класификатор на гори
  • — — LightGBM
  • — — XGBOOST
  • — — подреждане с StackingClassifier, което се състои в подреждане на изхода на индивидуалния оценител и използване на класификатор за изчисляване на крайната прогноза.

За да измерим ефективността на моделите, ние взехме AUC-резултат, F1-резултат от 1 и загуба на двоичен журнал като показатели за ефективност.

  • — — AUC-резултат: Този резултат ни дава добра представа за това колко добре работи моделът. Ако AUC на модел A е по-голям от този на модел B, на практика трябва да използвате модел A.
  • — — F1-резултат: Използва се за оценка на системи за двоична класификация.
  • — — Загуба на двоичен журнал: Измерва ефективността на класификационен модел, чийто резултат е вероятностна стойност между 0 и 1. Целта на нашия модел е да минимизира тази стойност. Един перфектен модел би имал log_loss от 0

Всички модели дават по-малък резултат F1, защото имаме работа с небалансирани данни, не забравяйте, че има малка група хора, които не плащат заемите си. Ето защо ние използваме SMOTE за справяне с дисбаланса.

Като разгледаме таблицата по-горе, съдържаща показателите за ефективност на различни модели, можем ясно да кажем, че логистичната регресия със SMOTE се представя много добре в сравнение с други модели. Той дава добри AUC резултати (без прекомерно оборудване) и най-добър F1-резултат (1). Въпреки че загубата на двоичен дневник е малко по-висока в сравнение с други модели.

За да завършим тази част от моделирането, използваме функцията pickle, за да запазим модела за внедряване.

pickle.dump(lr1, open('lr1.pkl', 'wb'))

След като това приключи, преминаваме към приложението във Flask. Това не е страхотното приложение в света, защото това, което искаме, е да научим как да използваме инструментите на Google Cloud и как да правим проект от край до край.

В облака на Google ще използваме тези 3 инструмента: изграждане на облак, регистър на контейнери и изпълнение на облак

Вече имам докер изображение с формата, както виждате тук. Единственото нещо, което ще направите, е да използвате докер маркер gcr.io/PROJECT_ID/IMAGE' Сега, ако се върнем към изображенията на докерите, ще видим, че идентификационният ни номер на изображението е правилен.

Между другото, преди това ще се уверя, че наистина съм направил gcloud.

Тук просто се уверете, че ако току-що сте инсталирали gcloud или сте направили нов проект, трябва да сте сигурни, че сте в правилния проект и това е правилно. Ако не, ще натиснете 1 за повторно инициализиране и ще можете да изберете проекта, който искате.

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

Качваме изображението на докер в gcloud с docker push и можем да го видим в секцията на регистъра на докерите

Следващото нещо е да създадем услуга, указваща контейнера, който искаме да използваме, който всъщност е този, който току-що сме качили. Също така, дайте му myapp като име, за да улесните урока, въпреки че можете да поставите името, което искате.

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

Във файла cloudbuild.yaml просто трябва да променим тези стойности на тези, които съответстват на всяко пространство.

steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/PROJECT_ID/IMAGE', '.']
# Push the container image to Container Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/PROJECT_ID/IMAGE']
# Deploy container image to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: gcloud
  args: ['run', 'deploy', 'SERVICE-NAME', '--image', 'gcr.io/PROJECT_ID/IMAGE', '--region', 'REGION']
images:
- gcr.io/PROJECT_ID/IMAGE

Отиваме в настройките, за да активираме тези два раздела: Service Accounts, Cloud Run

И трябва само да дадем RUN, за да работи перфектно.

Така че сега този тригер слуша за всяко време, когато направим ангажимент към хранилището на github

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

Това е този, който се провали, така че изображението всъщност е изградено правилно, просто не е било разгърнато правилно

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

Така че сега всеки път, когато направя ангажимент към това хранилище на github, всички стъпки в cloudbuild ще се изпълняват и след това, в крайна сметка, след като изграждането приключи, cloud run ще вземе това ново изображение и ще го внедри.

Така че това е всичко, което трябва да направите, за да вземете приложение за колба и да преминете през всички стъпки на CI/CD тръбопровод

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