Материал: Плагіат

Гіперплощина може будуватися різними способами, але у методі SVM вагові коефіцієнти і налаштовуються таким чином, щоб об'єкти класів лежали якнайдалі від поділяючої гіперплощини. Іншими словами, алгоритм максимізує відстань між об’єктами різних класів та гіперплощиною, які розташовані до неї найближче (рисунок 2.3).

Рис. 2.3 – Графічне представлення роботи методу SVM (опорних векторів)

Для налаштування вагових коефіцієнтів в SVM, для того щоб гіперплощина знаходилась якнайдалі від точок вибірки ширина смуги має бути максимальною. Вектор – вектор нормалі до поділяючої гіперплощини.

В рамках атестаційної роботи, SVM використовувався для вирішення задачі бінарної класифікації заявок на отримання банківських кредитів.

Комбіноване використання методу CART та SVM

У разі комбінованого використання методів CART та SVM на початковому етапі було вирішено використовувати метод на основі дерева рішень. За допомогою нього були проставлені вагові коефіцієнти для кожної з ознак, що дозволило виділити найбільш та найменш вагомі параметри моделі.

Для початку, необхідно було провести навчання методу. Відбувається ініціалізація параметрів користувача, зокрема який служить для відсіювання ознак, що мають значення важливості .

На вхід до методу подаються дані, проходить поверхневий аналіз даних, де метод перевіряє, чи є пропущені значення у даних, що поступили. Якщо пропущені значення є, то відбувається їх заповнення відповідно до медіанного значення цієї ознаки, якщо медіанне значення не дає результат, що близький до справжнього, то метод відсіює ознаку повністю, для того щоб покращити прогнози після навчання. Після того як пусті значення заповнені, алгоритм проводить нормалізацію даних, для подальшого аналізу.

Детальніше розглянемо на прикладі. Існує декілька типів клієнтів:

• клієнти, що виплачували кредити вчасно (тип С);

• клієнти, що не брали кредити (тип Х);

• клієнти, що брали позику, та мають заборгованість протягом від 1 до 29 днів (тип 0);

• клієнти, що брали позику, та мають заборгованість протягом від 30 до 59 днів (тип 1);

• клієнти, що брали позику, та мають заборгованість протягом від 60 до 89 днів (тип 2);

• клієнти, що брали позику, та мають заборгованість протягом від 90 до 119 днів (тип 3);

• клієнти, що брали позику, та мають заборгованість протягом від 120 до 149 днів (тип 4);

• клієнти, що брали позику, та мають заборгованість протягом від 150 днів, та вважаються безнадійними (тип 5).

Для побудови найбільш безпечної моделі, було прийнято рішення визначити типи С та Х, як надійних, а типи 0, 1, 2, 3, 4, 5 вважати боржниками. На рисунку 2.4 представлено, як позначені ці класи у методі. Тобто на виході методу буде клас, чи клієнт надійний, чи клієнт боржник.

Рис. 2.4 – Відношення типу клієнта, до його класу, де 0 – надійний, 1 – боржник.

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

Далі дані розбиваються на навчальну та тестову вибірки, і йдуть на вхід до класифікатора CART, який проводить класифікацію, та розставляє для кожної з ознак. Після отримання вагових коефіцієнтів, ознаки проходять відсіювання, при . Дані остаточно оброблені, після чого ставиться задача бінарної класифікації, для вирішення якої було обрано використовувати метод SVM. Метод опорних векторів класифікацію та видає остаточний результат, чи можна схвалювати заявку на кредит. На рисунку 2.5 представлений алгоритм, використаний для навчання методу, який комбінує в собі CART та SVM.

Рис. 2.5 – Алгоритм навчання комбінованого методу на основі CART та SVM

3. Визначення функціональних вимог системи

В рамках атестаційної роботи було вирішено, що система представляє собою веб-орієнтований додаток, спроектований на клієнт-серверній архітектурі. Мається на увазі, що розроблену систему будуть використовувати співробітники банку, та вносити клієнтські дані для аналізу заявок на отримання банківських кредитів.

Для визначення функціональних вимог системи, було обрано стандарт методології IDEF0 (I-CAM DEFinition) [31]. Модель IDEF представляє собою ієрархічну модель опису бізнес-процесів. Процеси моделі можна декомпозувати до тих пір, поки не буде досягнута необхідна кількість деталей. На рисунку 3.1 представлена концептуальна діаграма функції системи.

Рисунок 3.1 – Концептуальна діаграма функції «Автоматизація прийняття рішень, щодо видачі банківських кредитів» з точки зору користувача

Для продуктивної обробки та аналізу даних, необхідно зібрати дані, які будуть корисні для отримання ефективного прогнозу. Під корисними даними, передбачається така інформація, яка має вагу щодо вирішення надання чи відмови у позиці. Загалом, кожна людина, що приходить до банку, в очікуванні отримати кредит, надає первинні дані, які потрапляють до системи. Ця інформація, що необхідна для заповнення передбачена системою і вважається корисною. Подається для заповнення у вигляді форми, дані вводяться за допомогою співробітника банку. На рисунку 3.2 представлені декомпозиція основної функції системи.

Рисунок 3.2 – Діаграма декомпозиції, що представляє функції системи

Наступним кроком є взаємодія з блоком обробки даних, де проходить перевірка інформації та внесення до системи. Система передбачає використання інформації з різних джерел. Далі проводиться пошук інформації про клієнта на різних сервісах. Після видобутку всієї доступної інформації, збір даних завершено і вони передаються у блок обробки.

Будь-яка інформація, що потрапляє до системи є необробленою, тобто кожна ознака клієнта, яка може надходити до системи з інших систем чи підсистем, має проходити перевірку, перетворення, нормалізацію.

Для того, щоб метод аналізу даних для класифікації заявок на кредити відпрацьовував найбільш ефективно, система виконує перевірку даних. Наприклад, користувач залишив номер телефона, відбувається перевірка номера, чи дійсно він належить цьому користувачеві. Перевірка паспортних даних, перевірка нерухомості та ін. Кожна з ознак, що пройшла, або не пройшла перевірку подається до системі у вигляді булевої ознаки.

Деякі дані, що надає користувач, мають лише інформативний характер і при аналізі можуть дати слабий результат, але якщо їх трохи перетворити то ситуація зміниться. Наприклад, користувач вказав свій робочий телефон, система обробить ці дані та використає у якості ознаки, не сам номер, а ознаку його належності у вигляді булевого показника.

Всі дані зберігаються у базу даних, на основі СУБД Oracle, тож перед внесенням вони проходять нормалізацію до 3 нормальної форми.

Блок аналізу даних є основою для прийняття рішення, щодо підтвердження чи відхилення заявки клієнта на отримання кредиту. Дані, що потрапляють до цього блоку є обробленими, перевіреними та нормалізованими. Для аналізу даних, використовується метод на основі комбінування алгоритмів CART та SVM, який поєднує в собі деякі переваги обох методів. На рисунку 3.3 представлена декомпозиція функції «Аналіз даних». Прогнозування проходить за допомогою комбінованого методу, до якого подаються детальні дані клієнта.

Рисунок 3.3 – Діаграма декомпозиції функції «Аналіз даних»

Спочатку метод проходить навчання на вибірці всіх клієнтів, де за допомогою дерева рішень визначаються вагові коефіцієнти для кожної з ознак, далі відсіюються неважливі ознаки та дані передаються до алгоритму SVM. Після навчання, система може приступити до прогнозування, щодо видачі кредиту клієнтові. Система надає своє рішення працівнику, з додатковими метриками точності, співробітник банку приймає рішення на основі отриманих результатів.

Розроблена модель функціональних вимог, з усіма описаними функціями використана у проектуванні та розробці системи. Було виділено концептуальний зміст системи, основні функції та важливі моменти головної функції, що виконує аналіз даних.

4. Проектування системи підтримки рішень для оцінки заявок на отримання кредиту

Діаграма варіантів використання системи

При проектуванні системи важливою складовою є виділення ролей та варіантів використання системи. Діаграма варіантів використання (Use case) описує взаємовідносини і залежності між групами варіантів використання і дійовими особами, які беруть участь в процесі [32]. На рисунку 4.1 представлена Use Case діаграма системи.

Рис. 4.1 – Use Case діаграма системи

Відповідно до діаграми, наведеної вище, було виділено дві основні ролі у системі: співробітник банку, клієнт банку. Співробітник банку може використовувати наступні функції системи:

• реєстрація;

• авторизація;

• створення заявки на кредит;

• керування інформацією про клієнта, що включає в себе:

  • внесення інформації про клієнта;

  • перегляд інформації про клієнта;

• проведення аналізу заявки клієнта на кредит, що включає в себе:

  • перегляд результатів після аналізу;

  • експорт даних, отриманих після аналізу;

• керування рішенням про видачу позики, що включає в себе:

  • підтвердження заявки на кредит;

  • відмова у кредитуванні;

  • формування документу про результат.

Клієнт банку у свою чергу може користуватися наступними функціями системи:

• створення заявки на кредит;

• перегляд заявки на кредит;

• авторизація;

• перегляд рішення, щодо його заявки на кредит;

Таким чином, співробітник банку, разом з клієнтом банку, заповнюють заявку на отримання кредиту, вносять необхідну інформацію про клієнта до системи. Співробітник переглядає передбачення та необхідні метрики, сформовані системою, на основі чого, виносить рішення, підтвердити чи відмовити у кредитуванні. Клієнт, може зайти у систему та перевірити дані, що містяться про нього у системі, а також дізнатися рішення щодо отримання одержання позики.

Розробка структурної схеми інформаційної системи підтримки прийняття рішень для аналізу заявок на отримання позики

Завдяки тому, що функціональні вимоги визначені, ролі та прецеденти системи з’ясовано, веб-системи, що подібні до розроблюваної проаналізовано, було розроблену структурну схему, на якій зображені основні компоненти системи (рисунок 4.2).

Рис. 4.2 – Структурна схема компонентів системи, та їх взаємодії

На структурній схемі представлені наступні компоненти проектованої системи:

• інтерфейс користувача;

• модуль аналізу даних клієнтів, та видачі прогнозів;

• модуль керування інформацією клієнтів банку;

• модуль реєстрації та авторизації;

• модуль формування документів про результат;

• модуль персонального кабінету користувача;

• модуль взаємодії з зовнішніми ресурсами;

• база даних.