Програмна реалізація системи персоналізованих рекомендацій у Web-магазині електроприладів

Климчук, Владислав Андрійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7079
Title:	Програмна реалізація системи персоналізованих рекомендацій у Web-магазині електроприладів
Authors:	Півень, Олександр Борисович Климчук, Владислав Андрійович
Keywords:	інженерія програмного забезпечення;рекомендаційна система;машинне навчання;BPR;персоналізація;електронна комерція;Web-магазин;software engineering;recommendation system;machine learning;BPR;personalization;e-commerce;web store
Issue Date:	19-Dec-2025
Abstract:	АНОТАЦІЯ Климчук Владислав Андрійович Програмна реалізація системи персоналізованих рекомендацій у Web-магазині електроприладів 121 – Інженерія програмного забезпечення Черкаський державний технологічний університет Черкаси, 2025 У магістерській роботі представлено розробку програмної системи персоналізованих рекомендацій для Web-магазину на основі сучасних методів машинного навчання. Основна увага приділена впровадженню моделі Bayesian Personalized Ranking (BPR), що формує персоналізовані списки товарів відповідно до індивідуальних вподобань користувачів. Досліджено сучасні підходи до побудови рекомендаційних систем та обґрунтовано вибір технологій Java, Python і PostgreSQL. Показано переваги реляційної бази даних для структурованого зберігання даних про користувачів, товари та їх взаємодії. Розроблено архітектуру програмного комплексу з адміністративним модулем та автоматизованою рекомендаційною підсистемою, інтегрованою з моделлю BPR. Проведено експерименти щодо впливу параметрів BPR та особливостей користувацьких даних на точність рекомендацій, швидкодію та стійкість системи до оновлення інформації. Результати підтвердили ефективність застосованих методів і високу якість персоналізованих рекомендацій у Web-магазині. Розроблена система є надійною, масштабованою та зручною у використанні, придатною для веб-магазинів електроприладів, забезпечуючи користувачам швидкий та точний доступ до релевантних товарів ABSTRACT Klymchuk Vladyslav Andriyovich Software Implementation of a Personalized Recommendation System in a Web Store of Electrical Appliances 121 – Software Engineering Cherkasy State Technological University Cherkasy, 2025 The master’s thesis presents the development of a software system for personalized recommendations for a web-based store using modern machine learning methods. The main focus is on the implementation of the Bayesian Personalized Ranking (BPR) model, which generates personalized product lists according to individual user preferences. Modern approaches to building recommendation systems are analyzed, and the choice of technologies such as Java, Python, and PostgreSQL is justified. The advantages of a relational database for structured storage of data on users, products, and their interactions are demonstrated. The architecture of the software complex has been developed, including an administrative module and an automated recommendation subsystem integrated with the BPR model. A series of experiments was conducted to assess the impact of BPR parameters and the characteristics of user data on recommendation accuracy, system performance, and stability under data updates. The results confirmed the effectiveness of the applied methods and the high quality of personalized recommendations in the web store. The developed system is reliable, scalable, and user-friendly, making it suitable for web stores of electrical appliances by providing users with fast and accurate access to relevant products.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7079
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
кваліфікаційна робота магістра Климчук Владислав Андрійович.pdf Restricted Access		6.45 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
 МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
 
на тему:  Програмна реалізація системи персоналізованих рекомендацій у 
Web-магазині електроприладів 
 
 
Виконав: студент 2 курсу, групи МПЗ-2404 
Напряму підготовки  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Климчук В.А. 
 (прізвище та ініціали) 
Керівник  Півень О.Б. 
 (прізвище та ініціали) 
Рецензент  Захарова М.В. 
 (прізвище та ініціали) 
 
 
 
Черкаси 2025 
 
 
 Черкаський державний технологічний університет  
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем  
Кафедра  програмного забезпечення автоматизованих систем  
Освітній рівень  магістр  
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________ Голуб С.В. 
«___» _______________ 2025 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
  Климчук Владислав Андрійович  
(прізвище, ім’я, по батькові) 
1.Тему проекту (роботи) Програмна реалізація системи персоналізованих рекомендацій у 
Web-магазині електроприладів  
Керівник проекту (роботи) Півень Олександр Борисович к.ф.-м.н.  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 07 » 
жовтня 2025 року №307/03-03 
2. Строк подання студентом проекту (роботи) 19 грудня 2025 р.  
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси 
управління; вимоги до проекту; календарне планування проекту; управління ризиками 
проекту; управління ресурсами  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) 
Вступ  
4.1. Існуючі методи та засоби розв’язання поставлених завдань; 
4.2. Теоретичні та експериментальні дослідження;   
4.3.Впровадження результатів досліджень у практику проектування програмного 
забезпечення інформаційних систем;  
4.4. Розробка та тестування програмного забезпечення;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Титульний слайд; Слайд «Вступ»; Слайд «Вступ (продовження)»; Слайд «Теоретичні 
дослідження»; Слайд «Гіпотеза»; Слайд «Дослідження»; Слайд «Первинні та детальні вимоги»; 
Слайд «Аналіз аналогів(Rozetka)»; Слайд «Аналіз аналогів(Prom)»; Слайд «Аналіз 
аналогів(AliExpress)»; Слайд «Порівняння з аналогами»; Слайд «Порівняння з 
аналогами(Rozetka)»; Слайд «Порівняння з аналогами(Prom)»; Слайд «Порівняння з 
 
 
аналогами(AliExpress)»; Слайд «Порівняння з аналогами(Висновок)»; Слайд «Діаграма роботи 
системи»; Слайд «Діаграма компонентів»; Слайд «Діаграма скінченного автомату»; Слайд 
«Діаграма класів»; Слайд «Засоби реалізація проекту»; Слайд «Структура бази даних»; Слайд 
«Реалізація проекту(UI)»; Слайд «Реалізація проекту(IA)»; Слайд «Реалізація 
проекту(Reg/Log)»; Слайд «Тестування»;  Слайд «Висновки»; Слайд «Подяка». 
6. Консультанти розділів проекту (роботи) 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання вересень 2025 р.  
 
КАЛЕНДАРНИЙ ПЛАН 
Строк 
№ виконання 
Назва етапів випускної роботи Примітки 
п/п етапів випускної 
роботи 
1 Постановка задачі 02.09.2025 виконано 
2 Підготовка завдання 13.09.2025 виконано 
3 Погодження завдання 16.09.2025 виконано 
4 Затвердження завдання 19.09.2025 виконано 
 Основна стадія   
1 Підбір матеріалів 27.09.2025 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.10.2025 виконано 
3 Розрахунок основних параметрів роботи 10.10.2025 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.10.2025 виконано 
5 Оформлення первісної редакції роботи 25.10.2025 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 31.10.2025 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 08.12.2025 виконано 
кінцевій редакції 
3 Попередній захист роботи 16.12.2025 виконано 
4 Затвердження роботи 16.12.2025  
5 Рецензування роботи 16.12.2025  
6 Захист роботи 19.12.2025  
 
Студент _____________________  Климчук В.А. 
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________  Півень О.Б. 
  (підпис)   (прізвище та ініціали) 
 
 
АНОТАЦІЯ 
Климчук Владислав Андрійович 
Програмна реалізація системи персоналізованих рекомендацій у Web-
магазині електроприладів 
121 – Інженерія програмного забезпечення 
Черкаський державний технологічний університет 
Черкаси, 2025 
У магістерській роботі представлено розробку програмної системи 
персоналізованих рекомендацій для Web-магазину на основі сучасних методів 
машинного навчання. Основна увага приділена впровадженню моделі Bayesian 
Personalized Ranking (BPR), що формує персоналізовані списки товарів 
відповідно до індивідуальних вподобань користувачів. 
Досліджено сучасні підходи до побудови рекомендаційних систем та 
обґрунтовано вибір технологій Java, Python і PostgreSQL. Показано переваги 
реляційної бази даних для структурованого зберігання даних про користувачів, 
товари та їх взаємодії. Розроблено архітектуру програмного комплексу з 
адміністративним модулем та автоматизованою рекомендаційною 
підсистемою, інтегрованою з моделлю BPR. 
Проведено експерименти щодо впливу параметрів BPR та особливостей 
користувацьких даних на точність рекомендацій, швидкодію та стійкість 
системи до оновлення інформації. Результати підтвердили ефективність 
застосованих методів і високу якість персоналізованих рекомендацій у Web-
магазині. 
Розроблена система є надійною, масштабованою та зручною у 
використанні, придатною для веб-магазинів електроприладів, забезпечуючи 
користувачам швидкий та точний доступ до релевантних товарів. 
Ключові слова: інженерія програмного забезпечення, рекомендаційна 
система, машинне навчання, BPR, персоналізація, електронна комерція, Web-
магазин. 
 
 
ABSTRACT 
Klymchuk Vladyslav Andriyovich 
Software Implementation of a Personalized Recommendation System in a 
Web Store of Electrical Appliances 
121 – Software Engineering 
Cherkasy State Technological University 
Cherkasy, 2025 
The master’s thesis presents the development of a software system for 
personalized recommendations for a web-based store using modern machine 
learning methods. The main focus is on the implementation of the Bayesian 
Personalized Ranking (BPR) model, which generates personalized product lists 
according to individual user preferences. 
Modern approaches to building recommendation systems are analyzed, and 
the choice of technologies such as Java, Python, and PostgreSQL is justified. The 
advantages of a relational database for structured storage of data on users, products, 
and their interactions are demonstrated. The architecture of the software complex 
has been developed, including an administrative module and an automated 
recommendation subsystem integrated with the BPR model. 
A series of experiments was conducted to assess the impact of BPR 
parameters and the characteristics of user data on recommendation accuracy, system 
performance, and stability under data updates. The results confirmed the 
effectiveness of the applied methods and the high quality of personalized 
recommendations in the web store. 
The developed system is reliable, scalable, and user-friendly, making it 
suitable for web stores of electrical appliances by providing users with fast and 
accurate access to relevant products. 
Keywords: software engineering, recommendation system, machine learning, 
BPR, personalization, e-commerce, web store. 
 
 
ЧДТУ 252485.010 ПЗ 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 5 
ВСТУП 6 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ  
ПОСТАВЛЕНИХ ЗАВДАНЬ 9 
1.1 Визначення рекомендаційної системи 9 
1.2 Вплив рекомендаційних систем на аудиторію 10 
1.3 Основні підходи до побудови рекомендаційних систем 12 
1.4 Проблеми та обмеження існуючих підходів 18 
1.5 Персоналізовані рекомендації товарів на веб-сайтах електронної  
комерції 20 
1.6 Питання, що залишились невирішеними та власне місце  
магістранта у розв'язанні задачі 25 
Висновки до розділу 1 27 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ  
ДОСЛІДЖЕННЯ 28 
2.1 Теоретичні дослідження 28 
2.1.1 Застосування BPR у даній роботі 32 
2.1.2 Пошук раціонального компромісу, як елемент системного  
підходу до дослідження 35 
2.1.3 Потенційні ризики та загрози 36 
2.1.4 Розкриття невизначеностей, як елемент системного підходу до  
дослідження 38 
2.1.5 Технічний аналіз 40 
2.1.6 Теорія та гіпотеза дослідження 47 
2.2 Експериментальні дослідження 48 
2.2.1 Експериментальне середовище 48 
2.2.2 Опис елементів середовища 53 
2.2.3 Імітаційний метод 54 
 
2 
ЧДТУ 252485.010 ПЗ 
2.2.4 Дослідження мінімальної кількості даних для навчання  
звичайної та гібридної моделей рекомендацій 56 
2.2.5 Оцінка впливу додаткових ознак 58 
2.2.6 Оцінка ефективності системи 60 
2.2.7 Результати власних досліджень автора 62 
2.2.8 Результати досліджень інших авторів 63 
Висновки до розділу 2 65 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У  
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ  
ІНФОРМАЦІЙНИХ СИСТЕМ 67 
3.1 Моделювання предметної області 67 
3.1.1 Предметна область моделювання. Модель предметної області.  
Словник предметної області 67 
3.1.2 Елементи моделювання предметної області 68 
3.1.3 Робоча область моделювання 69 
3.2 Формування та аналіз вимог 71 
3.2.1 Формування вимог до програмного забезпечення. Первинні і  
детальні вимоги. Вимоги замовника і розробника. Функціональні та  
нефункціональні вимоги 71 
3.2.2 Формування вимог за допомогою діаграми прецедентів 73 
3.2.3 Проектування логічної структури програмного комплексу 75 
3.2.3.1 Діаграми класів 76 
3.2.3.2 Діаграми пакетів 79 
3.2.4 Архітектурне проектування 81 
3.2.4.1 Діаграма компонентів 82 
3.2.4.2 Розгортання програмної системи на апаратних засобах.  
Діаграма розгортання 84 
3.2.5 Моделювання поведінки системи 86 
3.2.5.1 Діаграма діяльності 86 
3.2.5.2 Діаграма послідовності 87 
3 
ЧДТУ 252485.010 ПЗ 
3.2.5.3 Діаграма комунікації 88 
3.2.5.4 Діаграма скінченного автомату 91 
Висновки до розділу 3 93 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО  
ЗАБЕЗПЕЧЕННЯ 94 
4.1 Розробка програмного комплексу 94 
4.1.1 Обґрунтування вибору засобів реалізації 95 
4.1.2 Опис структурної (функціональної) схеми 97 
4.1.3 Опис логічної схеми системи 100 
4.1.4 Розробка бази даних 100 
4.1.5 Розробка інтерфейсу користувача 104 
4.1.6 Опис розробки програмних компонентів 105 
4.2 Тестування системи 107 
4.2.1 Модульне тестування 107 
4.2.2 Інтеграційне тестування 109 
4.2.3 Системне тестування 111 
4.2.4 Приймальне тестування 112 
4.3 Приклади впровадженого програмного комплексу 114 
4.3.1 Інструкція користувача 114 
Висновки до розділу 4 120 
ЗАГАЛЬНІ ВИСНОВКИ 121 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 123 
ДОДАТОК А 126 
ДОДАТОК Б 128 
ДОДАТОК В 143 
 
  
4 
ЧДТУ 252485.010 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
РС – Рекомендаційна система; 
BPR – Bayesian Personalized Ranking; 
БД – бази даних; 
SB – Spring Boot; 
CF (Collaborative Filtering) – колаборативна фільтрація; 
E-commerce – електронна комерція; 
Cold Start Problem – проблема «холодного старту»; 
Deep Learning – глибоке навчання; 
API (Application Programming Interface) – програмний інтерфейс; 
ML (Machine Learning) – машинне навчання. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
ЧДТУ 252485.010 ПЗ 
ВСТУП 
Актуальність теми. Інженерія програмного забезпечення у сучасних 
умовах стрімкого розвитку електронної комерції персоналізовані рекомендації 
стали одним із ключових інструментів підвищення ефективності онлайн-
продажів. Великий обсяг товарів, різноманітність технічних характеристик та 
значна кількість брендів створюють інформаційне перевантаження для 
користувачів, ускладнюючи процес вибору. Рекомендаційні системи, що 
використовують методи машинного навчання, дозволяють формувати 
індивідуалізовані пропозиції, підвищувати задоволення від взаємодії з 
платформою та збільшувати конверсію. 
Особливо актуальними такі системи є для Web-магазинів 
електроприладів, де покупець має справу з широкою номенклатурою складних 
технічних товарів. Використання алгоритмів колаборативної фільтрації, 
зокрема Bayesian Personalized Ranking (BPR), дає можливість прогнозувати 
вподобання користувачів на основі їхньої поведінки, ефективно формувати 
персоналізований список товарів та покращувати якість взаємодії з 
платформою. 
Додаткову актуальність дослідження підсилює необхідність створення 
стабільної та масштабованої програмної інфраструктури для зберігання та 
обробки великих обсягів даних користувацьких взаємодій. Використання 
реляційної бази даних PostgreSQL забезпечує цілісність, структурованість та 
надійність даних, що є критично важливим для якісного навчання 
рекомендаційної моделі. Інструменти управління міграціями, такі як Flyway, 
дозволяють підтримувати узгоджений та контрольований розвиток схеми бази 
даних у процесі масштабування системи. 
Застосування сучасних технологічних рішень – Spring Boot для серверної 
частини, REST API для взаємодії між компонентами системи, модульної 
архітектури, логування та інструментів профілювання – забезпечує високу 
продуктивність, відмовостійкість та можливість подальшого розширення 
функціоналу. У комплексі ці технології створюють основу для практичного 
6 
ЧДТУ 252485.010 ПЗ 
впровадження рекомендаційної системи, здатної працювати з реальними 
навантаженнями та великим масивом даних. 
Зв’язок з науковими програмами, планами, темами. Дослідження 
виконано в межах наукового напряму кафедри програмного забезпечення 
автоматизованих систем, що передбачає розробку інтелектуальних систем 
підтримки прийняття рішень та впровадження сучасних методів машинного 
навчання у прикладних програмних рішеннях. 
Мета і завдання досліджень. Метою роботи є розроблення та 
дослідження програмної системи персоналізованих рекомендацій для Web-
магазину електроприладів, побудованої на основі алгоритму Bayesian 
Personalized Ranking (BPR) із використанням поведінкових даних та контентних 
характеристик товарів. 
Для досягнення поставленої мети необхідно виконати такі завдання: 
1. Проаналізувати сучасні методи прогнозування поведінки користувачів 
у системах електронної комерції, включаючи підходи на основі 
implicit-feedback. 
2. Розглянути моделі машинного навчання, що застосовуються у 
рекомендаційних системах, зокрема BPR та Matrix Factorization. 
3. Обґрунтувати вибір алгоритму BPR як основи моделі 
персоналізованих рекомендацій. 
4. Розробити архітектуру рекомендаційної системи та алгоритм її 
функціонування. 
5. Реалізувати програмний прототип системи на основі сучасних 
технологій (Java, Python, PostgreSQL). 
6. Провести експериментальне дослідження ефективності моделі, 
оцінити точність і порівняти її з базовими сценаріями без контентних 
ознак. 
7. Сформулювати висновки щодо доцільності використання BPR у Web-
магазинах електроприладів. 
7 
ЧДТУ 252485.010 ПЗ 
Об’єкт досліджень. Процес прогнозування вподобань користувачів у 
системах електронної комерції на основі їхніх взаємодій з товарами. 
Предмет досліджень. Програмна реалізація персоналізованих 
рекомендаційних систем у Web-магазині. 
Методи досліджень. У роботі застосовано:  
− методи порівняння та спостереження – для аналізу підходів до 
побудови рекомендаційних систем та оцінки моделей; 
− абстрагування та моделювання – для розроблення архітектури 
гібридної рекомендаційної системи; 
− формалізацію та системний підхід – для побудови структури даних, 
вибору технологій та компонування сервісів; 
− експериментальний метод – для оцінки якості моделі BPR, аналізу 
точності рекомендацій та перевірки гіпотези щодо покращення 
результатів завдяки контентним ознакам; 
Наукова новизна отриманих результатів. Наукова новизна полягає у 
вдосконаленні підходу до прогнозування вподобань користувачів шляхом 
поєднання BPR з контентними метаданими товарів у контексті 
рекомендаційних систем Web-магазинів електроприладів. Запропонована 
модель покращує якість рекомендацій у випадках обмежених даних (cold start) і 
забезпечує гнучке розширення системи. 
Практичне значення отриманих результатів. Результати можуть бути 
використані для впровадження персоналізованих рекомендацій у комерційних 
Web-платформах, що дозволить підвищити точність відбору товарів, 
покращити взаємодію користувача з інтерфейсом, збільшити конверсію та 
рівень утримання клієнтів. 
Особистий внесок автора. Усі отримані результати, зокрема проведені 
дослідження, розробка архітектури, реалізація програмного прототипу та аналіз 
ефективності моделі, виконані автором особисто. 
8 
ЧДТУ 252485.010 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
У сучасних програмно-орієнтованих екосистемах електронна комерція 
виступає одним із найбільш технологічно насичених доменів, де ключову роль 
відіграють системи обробки великих даних, прогнозування та автоматизації 
взаємодії з користувачем. Інтенсивне зростання кількості онлайн-платформ, 
різноманіття товарних позицій та складності бізнес-логіки створює відчутну 
проблему інформаційного перевантаження. Це зумовлює потребу в 
інтелектуальних ПЗ-компонентах, здатних здійснювати масштабовану обробку 
даних і формувати персоналізовані рекомендації в режимі реального часу. 
З погляду інженерії ПЗ, проблема полягає в оптимізації процесів пошуку 
релевантного контенту в умовах великих та динамічних наборів даних. Без 
автоматизованих методів ранжування і прогнозування користувач витрачає 
значно більше часу на навігацію та вибір товару, що негативно впливає на 
юзабіліті та ключові бізнес-метрики. 
Саме тому рекомендаційні системи, побудовані на методах машинного 
навчання, стали невід'ємним компонентом сучасних e-commerce архітектур. 
Вони аналізують історію поведінки користувачів, їхні взаємодії з платформою, 
контекстні параметри (час, пристрій, джерело трафіку) та формують 
персоналізовану вибірку товарів. 
Машинне навчання застосовується завдяки своїй здатності виділяти 
приховані залежності в даних і узагальнювати патерни поведінки користувачів. 
При цьому виникають типові інженерні проблеми – шум даних, неповнота 
історії взаємодій, невдалий підбір гіперпараметрів моделі, а також ризики 
underfitting і overfitting, які безпосередньо впливають на якість рекомендацій. 
1.1 Визначення рекомендаційної системи 
У контексті інженерії програмного забезпечення рекомендаційна система 
– це програмний модуль або комплекс сервісів, який реалізує механізми 
автоматичного фільтрування та ранжування інформації. Її завдання з великого 
9 
ЧДТУ 252485.010 ПЗ 
набору гетерогенних даних сформувати релевантну підмножину об’єктів для 
конкретного користувача. 
З погляду архітектури ПЗ такі системи зазвичай складаються з: 
− модуля збору даних (логування кліків, покупок, переглядів); 
− підсистеми попередньої обробки (нормалізація, фільтрація, 
агрегування); 
− модуля ML-моделі (навчання, валідація, генерація прогнозів); 
− API шару, який видає користувачеві рекомендаційний результат; 
− сервісів кешування, що пришвидшують доступ до популярних 
запитів. 
Рекомендаційна система формує списки (наприклад, top-N), де об’єкти 
відсортовані за прогнозованою релевантністю. Це може бути реалізовано як 
окремий мікросервіс, інтегрований із системою каталогів, CRM, аналітикою та 
фронтендом. 
У ML-частині система фактично навчає функцію score(user, item), яка 
оцінює, наскільки товар відповідає інтересам користувача. Для цього потрібні 
історичні дані, а якість рекомендацій залежить від їх обсягу та чистоти. Типові 
проблеми: 
− overfitting – модель занадто точно відтворює навчальні дані й погано 
узагальнює; 
− underfitting – модель недостатньо складна, не вловлює 
закономірностей; 
− sparseness – розрідженість даних (особливо у нових користувачів та 
товарів). 
Такі аспекти є критичними для розробника, оскільки впливають на 
архітектурні рішення та вибір метрик. 
1.2 Вплив рекомендаційних систем на аудиторію 
10 
ЧДТУ 252485.010 ПЗ 
З точки зору інженерії ПЗ рекомендаційні системи впливають не лише на 
бізнес-показники, а й на архітектуру й продуктивність всієї e-commerce 
платформи. Інтеграція таких систем змінює: 
− навантаження на бази даних; 
− структуру користувацьких сесій та поведінкових сценаріїв; 
− вимоги до реального часу (real-time scoring). 
Яскравим прикладом ефективності впровадження рекомендаційних 
технологій є компанія Netflix, яка повідомила, що її система рекомендацій 
щороку приносить близько 1 мільярда доларів США економічної вигоди. 
Подібну тенденцію демонструє і Amazon, де приблизно 35% загальних доходів 
формується завдяки товарам, запропонованим користувачам через 
персоналізовані рекомендації. Ці приклади свідчать, що застосування 
рекомендаційних систем стало ключовою умовою успішного розвитку бізнесу в 
інтернеті. 
Ці дані демонструють, що рекомендаційні алгоритми не є допоміжним 
модулем – це критичний елемент архітектури великих платформ. 
Для оцінки ефективності таких систем використовують низку 
аналітичних показників, серед яких: 
− коефіцієнт конверсії за рекомендаціями – частка користувачів, які 
здійснили покупку після перегляду рекомендованих товарів; 
− CTR (Click-Through Rate) – відсоток кліків на рекомендований товар 
відносно кількості його показів; 
− Revenue Share from recommendations – частина доходу, яку генерує 
система рекомендацій; 
− Items per session – скільки товарів переглядає користувач під впливом 
рекомендацій. 
За даними досліджень Wolfgang Digital, збільшення глибини сесії та 
кількості взаємодій напряму підвищує конверсію, що підтверджує правильність 
11 
ЧДТУ 252485.010 ПЗ 
використання рекомендаційних моделей як частини інженерної оптимізації 
UX/UI та бекенд-процесів. 
1.3 Основні підходи до побудови рекомендаційних систем 
У науковій літературі виділяють чотири базові підходи до побудови 
рекомендаційних систем: колаборативна фільтрація, контент-орієнтований 
підхід, підхід, заснований на знаннях та гібридні методи [2]. 
У сучасних дослідженнях до них також додають підходи, що також 
використовують глибоке навчання та методи навчання з підкріпленням. 
Контент-орієнтований підхід, є одним із ключових напрямів у побудові 
сучасних рекомендаційних систем. Її основна відмінність від колаборативної 
фільтрації полягає в тому, що система не потребує аналізу схожості між 
користувачами. Замість цього вона формує рекомендації, спираючись на 
характеристики самих об’єктів – таких як жанр, виробник, технічні параметри, 
тематика чи інші описові властивості. Алгоритм аналізує профіль користувача 
та визначає, які об’єкти найбільше відповідають його інтересам, знаходячи 
схожість між раніше переглянутими або оціненими товарами. 
Основна перевага контент-орієнтованої фільтрації полягає в її 
незалежності від даних інших користувачів, що дає змогу ефективно працювати 
навіть для нових клієнтів, про яких ще немає історії взаємодій. Проте на 
початкових етапах точність таких систем може бути нижчою, оскільки потрібен 
час для накопичення достатньої кількості даних про вподобання користувача. 
Крім того, цей підхід має певні обмеження: він залежить лише від описових 
характеристик товарів і не враховує колективний досвід інших користувачів. Це 
часто призводить до ефекту «інформаційної бульбашки», коли користувачу 
пропонуються надто схожі за змістом товари або контент, що зменшує 
різноманітність рекомендацій. 
Колаборативна фільтрація є одним із базових методів, що лежать в 
основі сучасних рекомендаційних систем. Вона ґрунтується на аналізі 
колективного досвіду користувачів, тобто співпраці між великою кількістю 
12 
ЧДТУ 252485.010 ПЗ 
агентів або джерел даних. Основна ідея полягає у використанні схожості у 
вподобаннях різних користувачів для формування прогнозів щодо їхніх 
майбутніх дій або інтересів. 
У загальному розумінні колаборативна фільтрація – це процес відбору 
інформації на основі колективної поведінки користувачів чи систем. Такий 
підхід застосовується у різних сферах, де необхідно аналізувати великі обсяги 
інформації: від фінансових аналітичних систем до платформ електронної 
комерції. У сфері e-commerce методи колаборативної фільтрації 
використовуються для створення персоналізованих рекомендацій товарів, 
фільмів, музики або іншого контенту на основі історії взаємодій користувачів. 
У прикладному аспекті колаборативна фільтрація розглядається як один 
із ключових методів прогнозування у рекомендаційних системах. Вона 
використовує відомі оцінки, відгуки або інші прояви вподобань певної групи 
користувачів для передбачення того, які об’єкти можуть зацікавити іншого 
користувача. Основна гіпотеза цього методу полягає в тому, що користувачі, 
які в минулому мали схожі оцінки або поведінку, з високою ймовірністю 
подібно оцінюватимуть об’єкти й надалі. 
Колаборативна фільтрація відрізняється від простіших статистичних 
підходів тим, що не обмежується узагальненими рейтингами чи середніми 
оцінками, а враховує індивідуальні особливості користувачів і динаміку їхніх 
інтересів. Попри ефективність цього методу, існують певні обмеження: 
складність обробки великих обсягів даних, проблема «холодного старту» для 
нових користувачів або товарів, а також зниження точності при високій 
розрідженості матриці оцінок. Саме ці проблеми зумовлюють розвиток 
комбінованих (гібридних) систем та інтеграцію методів колаборативної 
фільтрації з підходами машинного навчання [1]. 
Гібридні рекомендаційні системи поєднують декілька методів 
одночасно з метою підвищення точності прогнозів і подолання недоліків 
окремих підходів. Наприклад, колаборативна фільтрація може бути доповнена 
контентним аналізом або методами кластеризації, що дозволяє враховувати як 
13 
ЧДТУ 252485.010 ПЗ 
колективний досвід користувачів, так і характеристики самих об’єктів. Таке 
комбінування забезпечує більш гнучку та адаптивну роботу системи, особливо 
в умовах розріджених або неповних даних. 
Комбінування кількох алгоритмів у межах однієї платформи дозволяє 
мінімізувати недоліки кожного з них, тому саме гібридні варіанти найчастіше 
застосовуються у великих сервісах та інтернет-магазинах. Існує кілька 
поширених способів інтеграції методів: 
− паралельна реалізація колаборативних і контентних алгоритмів із 
подальшим поєднанням їхніх результатів; 
− включення контентних правил до колаборативної моделі; 
− застосування елементів колаборативної фільтрації в контент-
орієнтованих підходах; 
− побудова єдиної моделі, що об’єднує обидва типи методів; 
У сучасних дослідженнях значну увагу приділяють саме якості поєднання 
методів у гібридних рекомендаційних системах. Зокрема, у роботі [7] 
наголошується, що ефективність таких систем залежить не лише від вибору 
алгоритмів, а й від оптимального способу їх інтеграції та зважування внеску 
кожного методу. 
Відповідно до цього підходу, гібридна система не просто поєднує 
колаборативні й контентні алгоритми, а динамічно адаптує ваги між ними 
залежно від контексту, історії користувача та типу контенту. Така стратегія 
дозволяє зменшити вплив проблеми холодного старту, підвищити 
персоналізацію рекомендацій та покращити користувацький досвід. 
Крім того, у дослідженні зазначено, що використання методів машинного 
та глибокого навчання у гібридних моделях відкриває нові можливості для 
автоматичного налаштування параметрів і підвищення стабільності системи 
при роботі з великими даними. Це підтверджує тенденцію переходу від простих 
комбінованих моделей до інтелектуальних адаптивних систем, здатних 
самостійно оптимізувати свої рекомендаційні стратегії в реальному часі [7] 
14 
ЧДТУ 252485.010 ПЗ 
Методи глибокого навчання (Deep Learning) останніми роками стали 
одним із провідних напрямів розвитку рекомендаційних систем завдяки 
здатності моделювати складні залежності між користувачами, об’єктами та 
контекстом їхньої взаємодії. На відміну від класичних підходів, глибокі 
нейронні мережі можуть самостійно виявляти приховані закономірності у 
великих обсягах даних, не потребуючи ручного створення ознак.  
Робота таких систем ґрунтується на принципі прогнозування: мережа 
навчається визначати, які комбінації параметрів у її алгоритмах дають 
найточніші результати, а потім за допомогою методу зворотного поширення 
помилки (backpropagation) поступово вдосконалює свої ваги, «вчачись» на 
власних помилках. Це подібно до процесу навчання людини: наприклад, якщо 
модель помилково класифікує класичну п’єсу як рок-композицію, вона коригує 
свої внутрішні параметри, щоб уникати такої помилки надалі. З часом мережа 
набуває здатності робити високоточні передбачення, що робить її надзвичайно 
корисною для персоналізованих рекомендацій. 
У сфері електронної комерції та медіасервісів глибоке навчання 
застосовується для аналізу поведінки користувачів, виявлення контексту та 
прогнозування майбутніх дій. Серед найбільш поширених архітектур – 
згорткові нейронні мережі (CNN), які виділяють структурні закономірності у 
даних; рекурентні мережі (RNN), що моделюють часові залежності; а також 
графові нейронні мережі (GNN), які враховують складні взаємозв’язки між 
користувачами та об’єктами. Наприклад, модель GRU4Rec демонструє високу 
ефективність у сесійних рекомендаціях, аналізуючи короткочасні дії 
користувача під час однієї сесії [3]. 
Таким чином, глибоке навчання стало основою для створення 
інтелектуальних систем, здатних не лише враховувати минулі вподобання, а й 
динамічно адаптуватися до змін у поведінці користувачів, забезпечуючи більш 
точні та персоналізовані рекомендації. 
Навчання з підкріпленням (Reinforcement Learning, RL) – це підхід у 
сфері штучного інтелекту та машинного навчання, за якого агент навчається 
15 
ЧДТУ 252485.010 ПЗ 
приймати рішення, взаємодіючи із середовищем для досягнення певної мети. 
Його суть полягає у методі проб і помилок: агент виконує дії, отримує відгук у 
вигляді винагород або штрафів і на основі цього поступово формує оптимальну 
стратегію поведінки. На відміну від навчання з учителем або без учителя, RL не 
потребує маркованих даних – замість цього модель вчиться на власному 
досвіді. 
У контексті рекомендаційних систем методи навчання з підкріпленням 
розглядають процес рекомендацій як послідовність рішень, де система отримує 
зворотний зв’язок від користувача у вигляді винагороди. Це дозволяє не лише 
покращувати поточні рекомендації, а й оптимізувати довгострокові показники. 
Згідно з дослідженням Reinforcement Learning based Recommender 
Systems: A Survey (Afsar, Crump, Far, 2021), методи RL у рекомендаційних 
системах класифікують за типом середовища та стратегії навчання. Автори 
виокремлюють ключові компоненти таких систем – стан користувача, набір 
можливих дій (рекомендацій), функцію винагороди та механізм оновлення 
політики. У статті також наголошується, що RL-підхід дозволяє враховувати 
динамічну поведінку користувачів і контекст взаємодії, що робить його більш 
гнучким та ефективним порівняно з традиційними методами колаборативної 
або контентної фільтрації [8]. 
 
Таблиця 1.1 
Порівняння підходів до рекомендаційних систем 
Підхід Переваги Недоліки 
Контент- Не залежить від інших Обмежений описовими 
орієнтований користувачів, ефективний характеристиками, ефект 
для нових користувачів «інформаційної бульбашки», низька 
різноманітність рекомендацій 
Колаборатив Враховує колективний Проблема «холодного старту», 
на фільтрація досвід, адаптується до розрідженість матриці, обробка 
інтересів спільноти великих даних складна 
16 
ЧДТУ 252485.010 ПЗ 
Продовження табл. 1.1 
Гібридні Комбінують переваги Висока складність інтеграції, 
системи методів, зменшують потреба у ресурсах 
недоліки кожного, 
підвищують точність 
Глибоке Може виявляти приховані Ресурсоємне, потребує великих 
навчання закономірності, висока обсягів даних 
точність, динамічна 
адаптація 
Навчання з Враховує динаміку Складність реалізації у реальному 
підкріпленням поведінки користувачів, часі, потребує багато ітерацій 
оптимізує довгострокові 
показники 
 
Для розробки програмної системи персоналізованих рекомендацій у даній 
роботі обрано колаборативно-гібридний підхід, оскільки саме він забезпечує 
оптимальний баланс між точністю, гнучкістю та масштабованістю моделі. 
Такий підхід поєднує переваги класичної колаборативної фільтрації та 
додаткових методів – зокрема контентного аналізу та сучасних оптимізацій 
машинного навчання. 
Основною причиною вибору цього підходу є те, що колаборативна 
фільтрація добре враховує індивідуальні вподобання користувачів, 
ґрунтуючись на спільних закономірностях у їх поведінці. Однак її недоліки – 
розрідженість матриці взаємодій та проблема «холодного старту» – можуть 
суттєво знижувати ефективність системи, особливо в умовах реального 
інтернет-магазину, де кількість товарів та користувачів постійно зростає. 
Гібридизація дозволяє усунути ці обмеження. Застосування додаткових 
моделей (контентних ознак, кластеризації або векторних подань) дає змогу 
враховувати характеристичні параметри товарів і підсилювати колаборативну 
складову. Таким чином система отримує змогу формувати точніші та більш 
17 
ЧДТУ 252485.010 ПЗ 
різноманітні рекомендації, мінімізуючи ризик повторюваних або надто вузьких 
списків товарів. 
Ще однією перевагою є стійкість гібридних методів до неповних або 
нерівномірно заповнених даних. У роздрібній торгівлі часто трапляються 
ситуації, коли певні товари мають мало оцінок або нові користувачі лише 
розпочинають взаємодію з платформою. Гібридний підхід дає можливість 
якісно обробляти такі випадки, використовуючи як наявні дані про взаємодії, 
так і описові властивості товарів. 
Крім того, комбінування методів створює умови для динамічної адаптації 
системи: модель може автоматично коригувати ваги між різними алгоритмами 
залежно від контексту, типу товарів або активності користувача. Це підвищує 
персоналізацію та покращує користувацький досвід, забезпечуючи релевантні 
рекомендації навіть у нестандартних ситуаціях. 
Таким чином, обраний у роботі колаборативно-гібридний підхід є 
найбільш доцільним для побудови рекомендаційної системи, оскільки поєднує 
точність колаборативної фільтрації, універсальність контентного аналізу та 
стабільність гібридних моделей. Це забезпечує високу адаптивність, стійкість 
до проблеми холодного старту та можливість ефективного масштабування, що 
робить його найбільш відповідним для практичного впровадження у веб-
магазині. 
1.4 Проблеми та обмеження існуючих підходів  
У процесі аналізу існуючих методів прогнозування вподобань 
користувачів виявлено низку проблем, що обмежують ефективність сучасних 
рекомендаційних систем. Зокрема, методи колаборативної фільтрації часто 
стикаються з проблемою «холодного старту», коли для нових користувачів або 
нових товарів відсутні дані для формування рекомендацій. Крім того, ці 
системи мають низьку стійкість до розрідженості матриці оцінок, що 
ускладнює побудову точних прогнозів при великій кількості користувачів і 
товарів [1]. 
18 
ЧДТУ 252485.010 ПЗ 
Контент-орієнтовані підходи, своєю чергою, залежать від якості та 
повноти описових характеристик об’єктів, що не завжди можливо забезпечити 
в електронній комерції, особливо коли товари мають складні або суб’єктивні 
параметри. Також такий підхід може призводити до ефекту інформаційної 
бульбашки, коли користувачеві пропонуються лише схожі за змістом об’єкти, 
що зменшує різноманітність рекомендацій. 
Гібридні системи, хоча й долають обмеження окремих методів, 
потребують складної інтеграції моделей і значних обчислювальних ресурсів, 
що не завжди є економічно доцільним для невеликих компаній [4]. Методи 
глибокого навчання забезпечують високу точність, проте вони є ресурсоємними 
та потребують великих обсягів навчальних даних. У свою чергу, підходи на 
основі навчання з підкріпленням є перспективними, але їх впровадження у 
реальному часі ускладняється через тривалий процес навчання агента та 
нестабільність результатів при зміні середовища. 
Ще одним важливим обмеженням сучасних рекомендаційних систем є 
проблема конфіденційності користувачів. Для створення точних 
персоналізованих рекомендацій системи збирають великі обсяги даних про 
поведінку користувачів. Водночас користувачі можуть вважати, що система 
знає про них надто багато, що негативно впливає на їхню довіру та подальше 
користування сервісом. Саме тому сучасні РС повинні збирати інформацію 
ненав’язливо та прозоро, надаючи користувачу можливість добровільно 
ділитися додатковими даними для підвищення точності рекомендацій. 
Таким чином, актуальною є задача розробки або вдосконалення моделі 
прогнозування вподобань користувачів, яка б поєднувала переваги існуючих 
підходів, зменшувала вплив проблеми «холодного старту» та забезпечувала 
адаптацію до зміни інтересів користувачів у динамічному середовищі 
електронної комерції. 
Основні завдання, які вирішуються у межах цієї кваліфікаційної роботи: 
− аналіз існуючих методів і алгоритмів прогнозування вподобань 
користувачів; 
19 
ЧДТУ 252485.010 ПЗ 
− виявлення основних проблем і недоліків сучасних рекомендаційних 
систем; 
− вибір та обґрунтування ефективного підходу або їх комбінації для 
підвищення якості рекомендацій 
− розробка архітектури моделі прогнозування вподобань користувачів у 
системах електронної комерції 
− оцінка точності та ефективності запропонованого рішення. 
1.5 Персоналізовані рекомендації товарів на веб-сайтах електронної 
комерції 
Є багато місць, де рекомендації можуть відображатися на сайті 
електронній комерції. Основні методи рекомендацій найкраще працюють на 
головних сторінках, у кошиці, на сторінках категорії. 
Головна сторінка – це перше, що бачить користувач коли відвідує веб-
сайт через прямий трафік. Оскільки ці відвідувачі не обов'язково шукають щось 
конкретне, рекомендації на головній сторінці мають на меті інформування 
клієнтів про товари в яких клієнти можуть бути зацікавлені. 
Персональні рекомендації. Це дуже базова, але потужна логіка 
рекомендацій, яка чудово працює майже у всіх магазинах електронної комерції.  
Персоніфіковані рекомендації формуються індивідуально для кожного 
користувача на основі його попередніх покупок і історії переглядів. Вони дають 
змогу показувати саме ті товари, які можуть зацікавити конкретну людину. 
Однак для створення таких рекомендацій потрібна велика кількість даних про 
поведінку користувача, тому система стикається з труднощами під час роботи з 
новими відвідувачами – це явище відоме як проблема холодного старту. 
Популярність продукту визначається найлегше за кількістю придбаних вами 
товарів на сайті. Проте, більш досконалі системи включають не лише це, а ще й 
інші дані (кліки, перегляди, тощо) у свою логіку, щоб подати ще більш точні 
рекомендації. 
20 
ЧДТУ 252485.010 ПЗ 
Щоб забезпечити персоналізований досвід для постійних користувачів і 
водночас зацікавити нових відвідувачів, у сучасних системах рекомендацій 
застосовують підхід із “альтернативним сценарієм”. Його суть полягає в тому, 
що система спочатку перевіряє, чи має достатньо даних про конкретного 
користувача для формування персональних рекомендацій. Якщо інформації 
замало або вона відсутня, замість індивідуальних пропозицій система показує 
загальні рекомендації – наприклад, найпопулярніші товари або продукти з тієї 
категорії, яку користувач переглядав під час поточного відвідування сайту. 
Такий підхід дозволяє зберегти релевантність рекомендацій навіть без 
детальних даних про клієнта. 
Персоналізовані рекомендації на головній сторінці онлайн магазину 
Rozetka зображено на Рис.1.1. 
 
 
Рисунок. 1.1. − Приклад відображення рекомендацій товарів на головній 
сторінці інтернет-магазину Rozetka 
 
На головній сторінці інтернет-магазину Rozetka представлено блоки з 
персоналізованими рекомендаціями товарів, сформованими на основі історії 
21 
ЧДТУ 252485.010 ПЗ 
переглядів, попередніх покупок та поточних трендів. Такий підхід дозволяє 
користувачам швидше знаходити цікаві пропозиції, а магазину – підвищувати 
залученість і конверсію відвідувачів. 
Система рекомендацій на Rozetka працює на основі алгоритмів 
машинного навчання, які аналізують поведінку користувачів, історію їхніх 
переглядів і покупок. Використовуються методи колаборативного фільтрування 
для пошуку схожих користувачів та товарів, а також контентне фільтрування, 
що враховує характеристики продуктів. Алгоритм об’єднує ці дані, щоб 
формувати персоналізовані добірки товарів для кожного відвідувача, 
підвищуючи точність і релевантність рекомендацій. 
Порівняння системи рекомендацій Rozetka та BPR Hybrid зображено на 
Рис.1.2. 
 
 
Рисунок. 1.2. − Порівняння систем рекомендацій Rozetka та BPR Hybrid 
 
BPR Hybrid має перевагу в умовах обмеженої кількості взаємодій, бо 
добре працює з implicit-даними та може використовувати контентні фічі. 
22 
ЧДТУ 252485.010 ПЗ 
Персоналізовані рекомендації на головній сторінці онлайн магазину Prom 
зображено на Рис.1.3. 
 
 
Рисунок. 1.3. − Приклад відображення рекомендацій товарів на головній 
сторінці інтернет-магазину Prom 
 
На головній сторінці інтернет-магазину Prom відображаються блоки з 
рекомендаціями товарів, які формуються на основі історії переглядів 
користувача, його попередніх пошуків та популярності продуктів серед інших 
відвідувачів. Така система дозволяє користувачам швидко знаходити цікаві для 
них товари, а магазину – підвищувати конверсію та ефективність продажів. 
Система рекомендацій на Prom працює завдяки поєднанню методів 
машинного навчання та аналітики даних. Алгоритми аналізують взаємодії 
користувачів із товарами – перегляди, покупки, пошукові запити – і знаходять 
закономірності у поведінці великої кількості користувачів. На основі цих даних 
застосовується колаборативне фільтрування, яке підбирає товари, схожі на ті, 
що цікавили інших користувачів із подібними вподобаннями, а також 
контентне фільтрування, що враховує характеристики товарів для точнішого 
формування персоналізованих добірок. 
Порівняння системи рекомендацій на Prom та BPR Hybrid на Рис.1.4. 
23 
ЧДТУ 252485.010 ПЗ 
 
Рисунок. 1.4. − Порівняння систем рекомендацій Prom та BPR Hybrid 
 
BPR Hybrid значно випереджає Prom за рахунок персоналізації та 
гібридної архітектури. 
Персоналізовані рекомендації на головній сторінці онлайн магазину 
AliExpress зображено на Рис.1.5. 
 
 
Рисунок. 1.5. Приклад відображення рекомендацій товарів на головній сторінці 
інтернет-магазину AliExpress 
 
Персоналізовані рекомендації на основі колаборативного фільтрування 
працюють таким чином: система оцінює схожість товарів з тими, які 
користувач переглядав раніше, беручи до уваги не один товар, а всю історію 
переглядів користувача. При цьому взаємодії користувача з товарами можуть 
24 
ЧДТУ 252485.010 ПЗ 
зважуватися залежно від часу – більш свіжі дії мають більшу вагу. Такий підхід 
дозволяє точніше підбирати товари, які можуть зацікавити конкретного 
користувача. 
Цей підхід найкраще ілюструється на сайті AliExpress, де блоки 
персоналізованих рекомендацій формуються на основі всієї історії переглядів 
користувача та зважуються за часом взаємодії, що дозволяє точно підбирати 
товари, які можуть його зацікавити. 
Порівняння системи рекомендацій на AliExpress та BPR Hybrid на Рис.1.6. 
 
 
Рисунок. 1.6. Порівняння систем рекомендацій AliExpress та BPR Hybrid 
 
AliExpress використовує більш складні DL-моделі, але для 
малого/середнього інтернет-магазину моє рішення є оптимальним за балансом 
якість/ресурси/складність. 
Проведене порівняння показує, що розроблена гібридна модель на основі 
Cornac та алгоритму BPR: 
− перевершує Prom за якістю персоналізації; 
− наближається до рівня Rozetka при значно менших ресурсах; 
− є оптимальним рішенням для малого та середнього e-commerce 
сегменту; 
− забезпечує хорошу роботу при нестачі даних завдяки використанню 
контентних ознак. 
1.6 Питання, що залишились невирішеними та власне місце 
25 
ЧДТУ 252485.010 ПЗ 
магістранта у розв'язанні задачі 
Аналіз наукових джерел та існуючих рекомендаційних систем показав, 
що сучасні підходи мають низку обмежень, які потребують подальших 
досліджень. Зокрема, залишається актуальною проблема «холодного старту» 
для нових користувачів або товарів, коли відсутність історичних даних 
ускладнює формування точних рекомендацій. Також спостерігається низька 
різноманітність рекомендацій, що призводить до ефекту «інформаційної 
бульбашки» та зменшує зацікавленість користувачів. Високі обчислювальні 
витрати при використанні глибокого навчання та гібридних моделей 
обмежують можливості їх застосування на малих платформах, а недостатня 
динамічна адаптація до змін вподобань користувачів у реальному часі знижує 
точність прогнозів. Крім того, питання конфіденційності даних користувачів та 
оптимального поєднання методів у гібридних системах залишаються 
невирішеними та потребують додаткового дослідження. 
Власне місце магістранта у розв’язанні цих проблем полягає у 
комплексному аналізі існуючих методів прогнозування вподобань 
користувачів, виявленні їхніх обмежень та розробці моделі, яка поєднує 
переваги контентної, колаборативної та гібридної фільтрації. Запропонована 
модель забезпечує адаптацію рекомендацій до зміни інтересів користувачів, 
зменшує ефект «холодного старту» та впроваджує механізм прозорого та 
безпечного збору даних. Таким чином, робота спрямована на підвищення 
ефективності систем прогнозування вподобань користувачів і підтверджує її 
наукову та практичну значущість. 
  
26 
ЧДТУ 252485.010 ПЗ 
Висновки до розділу 1 
У першому розділі цього дослідження проведено аналіз наукових джерел 
та сучасних практичних реалізацій рекомендаційних систем показав, що ця 
галузь залишається актуальною та перспективною для подальших досліджень. 
Існуючі підходи мають як значні переваги, так і низку обмежень, серед яких 
проблема «холодного старту», низька різноманітність рекомендацій, високі 
обчислювальні витрати та питання конфіденційності даних користувачів. 
Водночас сучасні методи гібридної фільтрації, глибокого навчання та навчання 
з підкріпленням демонструють можливості підвищення точності та 
адаптивності рекомендацій. Це обґрунтовує необхідність подальших наукових 
досліджень у сфері прогнозування вподобань користувачів у системах 
електронної комерції та створення ефективних, персоналізованих і безпечних 
рекомендаційних систем. 
 
27 
ЧДТУ 252485.010 ПЗ 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1. Теоретичні дослідження 
Задача: Розробити онлайн-платформу для надання персоналізованих 
рекомендацій товарів у системах електронної комерції з використанням методів 
машинного навчання. Система має аналізувати поведінку користувачів, історію 
покупок та взаємодію з контентом для формування індивідуальних пропозицій, 
що підвищують рівень задоволеності клієнтів та ефективність продажів [5]. 
Класифікація задачі: 
Тип задачі: розробка онлайн-платформи. 
Характер задачі: проектування та розробка програмного забезпечення. 
Сфера задачі: надання безоплатної допомоги та веб-розробка. 
Метод розв'язання: використання сучасних технологій – Java для 
серверної частини, Python для обробки даних і реалізації інтелектуальних 
модулів, HTML5 для структурування веб-сторінок, Bootstrap для адаптивного 
інтерфейсу користувача та CSS для стилізації елементів [14]. Такий підхід 
дозволяє поєднати надійність серверних рішень із гнучкістю веб-технологій і 
можливостями аналітичної обробки даних. 
Цільова аудиторія: користувачі онлайн-магазинів та їх власникам 
Ідентифікація задачі: 
Основні завдання: 
− розробка інтерфейсу для користувачів системи електронної комерції. 
− реалізація механізму реєстрації, аутентифікації та персоналізації 
користувачів; 
− розробка та впровадження алгоритмів машинного навчання для 
прогнозування вподобань користувачів [12]; 
− інтеграція рекомендаційної системи з базою даних товарів та історією 
покупок [13]; 
28 
ЧДТУ 252485.010 ПЗ 
− забезпечення безпеки та конфіденційності персональних даних 
користувачів; 
− оптимізація продуктивності системи та підвищення точності 
рекомендацій. 
Прогнозування задачі: 
Кількість активних користувачів на платформі: Прогнозування може 
базуватися на історичних даних про відвідуваність сайту та активність 
користувачів. Методи часових рядів або моделі машинного навчання 
дозволяють оцінити майбутню активність та тренди поведінки користувачів. 
Кількість переглядів та взаємодій з товарами: Прогнозування поведінки 
користувачів щодо перегляду товарів і додавання їх у кошик може 
використовувати регресійні моделі та алгоритми рекомендацій для визначення 
найімовірніших дій користувача. 
Рівень персоналізованих рекомендацій: Прогнозування точності та 
ефективності рекомендацій може здійснюватися на основі аналізу попередніх 
взаємодій користувачів із системою, використовуючи колаборативну 
фільтрацію та контентний аналіз. 
Конверсія та покупки: Прогнозування ймовірності здійснення покупки на 
основі рекомендацій дозволяє оцінити ефективність роботи системи та 
оптимізувати алгоритми рекомендацій. 
Залучення нових користувачів: Прогнозування потоків нових 
користувачів може спиратися на маркетингові кампанії та історичні дані про 
зростання бази клієнтів, що дозволяє оцінювати потенційний попит на 
рекомендаційний сервіс. 
Оптимізація задачі: 
Мета оптимізації: Підвищення точності прогнозування вподобань 
користувачів та ефективності системи рекомендацій з метою збільшення 
конверсії продажів, покращення користувацького досвіду та підвищення 
залученості клієнтів. 
29 
ЧДТУ 252485.010 ПЗ 
Точність рекомендацій: Мінімізація помилкових рекомендацій і 
підвищення релевантності запропонованих товарів за допомогою оптимізації 
алгоритмів машинного навчання. 
Швидкість обробки запитів: Скорочення часу формування 
персоналізованих рекомендацій шляхом оптимізації обчислювальних процесів і 
структури даних. 
Оновлення моделі: Оптимізація частоти перенавчання моделі [9] для 
врахування змін у поведінці користувачів без втрати продуктивності системи. 
Конверсія користувачів: Максимізація кількості покупок після показу 
рекомендацій завдяки адаптивним моделі, що враховують контекст та історію 
користувача. 
Використання ресурсів: Оптимізація споживання обчислювальних 
ресурсів [18] (CPU, пам’яті, запитів до БД) при генерації рекомендацій. 
Стратегії оптимізації: 
Паралельна обробка запитів [19,17]: Передбачено використання 
багатопотокових технологій і серверних рішень (наприклад, Java Streams, 
Python multiprocessing) для одночасного опрацювання великої кількості запитів 
користувачів та швидкої генерації персоналізованих рекомендацій. 
Періодичне навчання моделі: Передбачено регулярне оновлення та 
перенавчання моделі машинного навчання на основі нових даних 
користувацької активності для підтримки актуальності прогнозів. 
Оптимізація параметрів моделі здійснювалась із використанням бібліотек 
Cornac, Pandas, NumPy та SciPy [20], що забезпечило підвищення точності 
прогнозування вподобань користувачів. 
Оптимізація ресурсів: 
Заплановано використання методів оптимізації обчислювальних ресурсів, 
зокрема контейнеризації (Docker) та ефективного розподілу навантаження між 
серверними компонентами, що дозволить підвищити стабільність роботи 
системи рекомендацій. Також передбачено інтеграцію з Google-авторизацією 
30 
ЧДТУ 252485.010 ПЗ 
для спрощення доступу користувачів та зменшення навантаження на власну 
систему аутентифікації. 
Вимірювання результатів: 
Для оцінювання ефективності оптимізації передбачено використання 
ключових показників ефективності (KPIs), серед яких: 
− середній час формування рекомендацій. 
− точність прогнозування вподобань користувачів; 
− рівень задоволеності користувачів рекомендаціями; 
− витрати системних ресурсів під час обробки запитів. 
Застосування цих стратегій оптимізації забезпечить високу ефективність і 
продуктивність системи, підвищить якість персоналізованих рекомендацій та 
зменшить затрати на підтримку роботи платформи електронної комерції. 
Математична форма класифікації для вищевказаної платформи може бути 
представлена у вигляді системи параметрів і критеріїв, що допомагають 
класифікувати та ідентифікувати основні характеристики системи, зокрема: 
Параметри класифікації: 
Рівень зацікавленості користувача: I – параметр, що визначає ступінь 
зацікавленості користувача у продукті на основі його дій. 
Кожна дія користувача оцінюється певною кількістю балів: 
− перегляд товару – 2 бал; 
− додавання товару до кошика – 3 бали; 
− придбання товару – 5 балів. 
− інше – 1 бал. 
Отже, рівень зацікавленості можна подати як функцію: 
I=f(перегляди, додавання в кошик, покупки) 
Якість рекомендацій: Q – параметр, що оцінює ефективність системи 
рекомендацій на основі взаємодій користувачів з рекомендованими товарами. 
31 
ЧДТУ 252485.010 ПЗ 
Він може розраховуватись як співвідношення кількості релевантних 
рекомендацій (що призвели до дій користувача) до загальної кількості показів 
рекомендацій. 
 
                     
Q=  
                
 
Продуктивність системи: P – параметр, що характеризує ефективність 
роботи рекомендаційного модуля. 
Може визначатися кількістю згенерованих рекомендацій за одиницю часу 
або середнім часом відповіді системи: 
P=f(час_обробки,кількість_рекомендацій) 
Критерії класифікації: 
Рівень зацікавленості користувача (I): 
− високий рівень: I > X (користувач часто взаємодіє з товарами, купує); 
− середній рівень: Y < I ≤ X (користувач додає товари до кошика, але не 
завжди купує); 
− низький рівень: I ≤ Y (користувач лише переглядає товари). 
− якість рекомендацій (Q): 
− висока якість: Q > Z (велика частка рекомендованих товарів 
призводить до дій користувача) 
− середня якість: W < Q ≤ Z. 
− низька якість: Q ≤ W. 
− продуктивність системи (P): 
− висока продуктивність: P > V (система швидко формує та оновлює 
рекомендації). 
− середня продуктивність: U < P ≤ V. 
32 
ЧДТУ 252485.010 ПЗ 
− низька продуктивність: P ≤ U. 
Таким чином, дана математична класифікація дозволяє оцінювати 
ефективність роботи рекомендаційної системи за трьома основними 
параметрами – рівнем залученості користувача (I), якістю рекомендацій 
(Q) та продуктивністю системи (P). Це допомагає визначати ефективність 
алгоритму і вчасно оптимізувати його під поведінкові зміни користувачів. 
2.1.1 Застосування BPR у даній роботі 
Однією з найбільш ефективних і широко застосовуваних технологій у 
сучасних рекомендаційних системах є модель Bayesian Personalized Ranking 
(BPR). Вона належить до класу методів колаборативної фільтрації та 
використовується для побудови персоналізованих рекомендацій на основі 
неявних даних про взаємодію користувачів із системою (перегляди, покупки, 
додавання товарів до кошика тощо). На відміну від традиційних методів 
рекомендацій, які базуються на явних оцінках (рейтингах або відгуках 
користувачів), модель BPR працює з неявними сигналами взаємодії. 
Неявні дані – це будь-які дії користувача, які можна інтерпретувати як 
прояв інтересу: перегляд сторінки товару, додавання до списку бажань, 
додавання до кошика чи купівля. 
Основна ідея BPR полягає у порівняльному ранжуванні об’єктів. Модель 
не прогнозує числову оцінку вподобань, як це роблять регресійні моделі, а 
навчається на парах об’єктів: для кожного користувача   визначається, що 
товар  , з яким він взаємодіяв, є більш релевантним, ніж товар  , з яким 
взаємодії не було. 
Тобто метою навчання є максимізація ймовірності того, що користувач 
віддасть перевагу вже відомим йому об’єктам перед невідомими. 
Метою є максимізація функції правдоподібності для всіх користувачів: 
  
                   
          
33 
ЧДТУ 252485.010 ПЗ 
де: 
−                – функція, яка нормує значення в інтервал [0,1]; 
−     – різниця передбачуваних оцінок для пари товарів; 
− λ – коефіцієнт регуляризації, який запобігає перенавчанню моделі. 
Таким чином, BPR не прагне відтворити конкретні оцінки, а навчається 
відносному порядку між товарами для кожного користувача [10]. 
 BPR належить до групи моделей колаборативної фільтрації, тобто таких, 
що використовують поведінкові дані користувачів (а не характеристики товарів 
чи профілі користувачів).  
Її суть полягає в тому, що поведінка одного користувача може бути 
корисною для прогнозування інтересів іншого користувача, якщо 
спостерігається схожість у їхніх взаємодіях із товарами. 
На відміну від класичної memory-based колаборативної фільтрації (яка 
шукає схожих користувачів або товари), BPR – це model-based підхід, тобто 
система навчається моделі, яка узагальнює закономірності у взаємодіях між 
усіма користувачами та товарами. 
Основна перевага BPR над звичайними алгоритмами полягає у тому, що: 
вона працює з неявними даними, які природно присутні в e-commerce 
(перегляди, кліки, покупки), не потребує прямого збирання оцінок (що часто 
неможливо), забезпечує персоналізоване ранжування замість простої оцінки 
популярності товарів. 
Основні переваги моделі BPR: 
− працює з неявними відгуками, що робить її ідеальною для електронної 
комерції; 
− висока масштабованість – модель добре працює навіть із великими 
наборами даних. 
− ефективне персоналізоване ранжування – користувачу пропонуються 
саме ті товари, які, з більшою ймовірністю, його зацікавлять. 
34 
ЧДТУ 252485.010 ПЗ 
− стійкість до розрідженості даних, що є критично важливим у великих 
онлайн-магазинах. 
У даній магістерській роботі модель BPR використовується як основа для 
реалізації рекомендаційної системи в електронному магазині. Система аналізує 
поведінку користувачів – перегляди, додавання товарів у кошик, покупки – та 
на основі цього формує персоналізовані рекомендації. 
Особливістю реалізованої системи є те, що користувачу можуть 
рекомендуватися товари, які переглядали інші користувачі зі схожою 
поведінкою, навіть якщо сам користувач раніше не взаємодіяв із цими 
товарами. Це дозволяє розширювати коло рекомендацій і підвищувати 
ймовірність знаходження релевантних товарів. 
Для реалізації алгоритму використано бібліотеку Cornac AI [20], яка 
підтримує модель BPR та надає інструменти для роботи з даними 
колаборативної фільтрації. Для попередньої обробки даних використано pandas, 
numpy і scipy [15], що дозволило забезпечити високу ефективність і гнучкість 
обчислень. 
2.1.2 Пошук раціонального компромісу, як елемент системного підходу 
до дослідження 
Пошук раціонального компромісу у дослідженні та розробці 
рекомендаційної системи є важливою складовою системного підходу, оскільки 
дозволяє збалансувати точність прогнозування, продуктивність моделі та 
зручність використання платформи для кінцевих користувачів. 
Якість рекомендацій: Основним компромісом у системі є баланс між 
точністю рекомендацій та швидкістю їх формування. Використання моделі BPR 
забезпечує високу персоналізацію рекомендацій, проте потребує значних 
обчислювальних ресурсів під час навчання. Тому пошук оптимальної кількості 
факторів, розмірів латентних векторів і параметрів регуляризації є ключовим 
аспектом раціонального компромісу між ефективністю моделі та її швидкодією. 
35 
ЧДТУ 252485.010 ПЗ 
Обсяг і повнота даних: Для підвищення якості прогнозування доцільно 
використовувати якомога більше історичних даних про взаємодію користувачів 
із товарами (перегляди, покупки, оцінки тощо). Однак надмірний обсяг даних 
збільшує час навчання моделі. Тому оптимальним рішенням є попередня 
обробка даних, видалення шумових або нерелевантних записів, що дозволяє 
зберегти баланс між якістю рекомендацій і швидкістю обчислень. 
Модель і ресурси: Враховуючи, що для реалізації системи 
використовувалися бібліотеки Cornac AI, pandas, numpy та scipy, було знайдено 
компроміс між складністю алгоритму і доступністю його реалізації. Таке 
рішення дозволило уникнути використання важких фреймворків і водночас 
забезпечити високу якість навчання моделі колаборативної фільтрації. 
Користувацький досвід: З боку інтерфейсу користувача важливим є 
пошук балансу між кількістю показуваних рекомендацій і їх релевантністю. 
Надмірна кількість рекомендацій може перевантажувати користувача, тоді як 
занадто мала кількість зменшує шанси знайти цікаві товари. Тому система 
налаштована на формування обмеженої вибірки найбільш релевантних об’єктів, 
що оптимізує взаємодію користувача з платформою. 
Час навчання та оновлення моделі: Ще одним компромісом є вибір між 
частотою оновлення моделі та використанням ресурсів. Постійне оновлення 
даних покращує актуальність рекомендацій, але збільшує навантаження на 
систему. Оптимальним рішенням стало періодичне перенавчання моделі з 
урахуванням нових даних користувачів. 
Масштабування системи: У майбутньому розвиток системи може 
вимагати обробки значно більшого обсягу даних. Раціональний компроміс 
полягає у початковому використанні локальних ресурсів із можливістю 
поступового переходу до масштабованих серверних рішень при збільшенні 
кількості користувачів. 
Отже, пошук раціонального компромісу у межах проекту полягає у 
досягненні оптимального балансу між точністю, продуктивністю, зручністю 
користування та ресурсною ефективністю. Це забезпечує стабільну роботу 
36 
ЧДТУ 252485.010 ПЗ 
рекомендаційної системи, зручність для користувачів і можливість подальшого 
масштабування без суттєвих витрат. 
2.1.3 Потенційні ризики та загрози 
Розробка та впровадження рекомендаційної системи на основі моделі 
BPR (Bayesian Personalized Ranking) у сфері електронної комерції пов’язана з 
низкою потенційних ризиків, які стосуються точності прогнозів, захисту даних 
користувачів, стабільності роботи системи та якості рекомендацій. 
Деякі з основних ризиків та стратегії управління ними включають: 
1 Якість та точність рекомендацій 
Ризик: Неправильні або нерелевантні рекомендації можуть призвести до 
зниження довіри користувачів до системи. Це може бути наслідком 
недостатньої кількості даних, нерівномірного розподілу активностей 
користувачів або неправильно підібраних параметрів моделі. 
Стратегія управління ризиком: Регулярне перенавчання моделі BPR з 
урахуванням нових даних користувачів, застосування перевірених метрик 
точності (AUC, Recall, Precision), а також гнучке налаштування гіперпараметрів 
моделі для досягнення оптимального балансу між точністю і швидкодією. 
2 Безпека та приватність даних: 
Ризик: Витік або несанкціонований доступ до персональних даних 
користувачів може призвести до порушення конфіденційності та втрати 
репутації системи. 
Стратегія управління ризиком: Використання захищених протоколів 
передачі даних (HTTPS), хешування та анонімізація ідентифікаторів 
користувачів, а також впровадження політики конфіденційності згідно з 
вимогами GDPR. 
3 Стабільність і продуктивність системи: 
Ризик: Високе навантаження або помилки в алгоритмі можуть призвести 
до збоїв у роботі системи або уповільнення її роботи. 
37 
ЧДТУ 252485.010 ПЗ 
Стратегія управління ризиком: Тестування системи на стресостійкість, 
використання кешування результатів рекомендацій, а також оптимізація запитів 
і даних з урахуванням принципів ефективного управління ресурсами. 
4 Нерівномірність даних користувачів: 
Ризик: Нові користувачі або товари, для яких ще немає історії взаємодії, 
можуть залишитися без релевантних рекомендацій (проблема «cold start»). 
Стратегія управління ризиком: Використання змішаного підходу – 
поєднання колаборативної фільтрації (BPR) з контентними характеристиками 
товарів, що дозволить формувати базові рекомендації навіть для нових 
користувачів. 
5 Надмірне використання ресурсів: 
Ризик: Навчання моделі BPR може потребувати значних обчислювальних 
потужностей, особливо при великій кількості користувачів і товарів. 
Стратегія управління ризиком: Оптимізація коду, використання бібліотек 
Cornac AI, numpy, pandas, scipy, що забезпечують ефективну обробку великих 
обсягів даних, а також планування навчання моделі в неробочий час. 
6 Етичні ризики та упередженість рекомендацій: 
Ризик: Модель може підсилювати популярність уже відомих товарів, 
ігноруючи менш популярні, що створює ефект «інформаційної бульбашки». 
Стратегія управління ризиком: Введення елементів випадковості або 
обмеження кількості повторних рекомендацій, щоб користувачі могли 
відкривати нові товари. 
Загалом, комплексний підхід до управління ризиками включає постійний 
моніторинг роботи моделі, аналіз якості рекомендацій і підтримку безпеки 
даних користувачів. Це дозволяє забезпечити стабільну роботу рекомендаційної 
системи, підвищити довіру користувачів і створити ефективну платформу для 
прогнозування їхніх вподобань на основі колаборативної фільтрації (додаються 
та підтверджуються джерелами: [22; 23; 11]). 
2.1.4 Розкриття невизначеностей, як елемент системного підходу до 
дослідження 
38 
ЧДТУ 252485.010 ПЗ 
Розкриття невизначеностей у процесі дослідження та розробки 
рекомендаційної системи на основі моделі BPR (Bayesian Personalized Ranking) 
є важливим етапом системного підходу, який дозволяє виявити потенційні 
труднощі, передбачити ризики та обґрунтувати прийняті рішення під час 
побудови моделі колаборативної фільтрації, зокрема: 
Вибір алгоритмічного підходу: Однією з ключових невизначеностей було 
визначення оптимального методу рекомендацій. Існує широкий спектр підходів 
– контентні, гібридні, колаборативні. У нашій роботі було обрано саме 
колаборативну фільтрацію на основі моделі BPR, оскільки вона орієнтована на 
персоналізацію результатів і враховує індивідуальні уподобання користувачів, 
навіть без наявності контентних описів товарів. Проте невизначеність полягала 
у тому, наскільки ефективно модель зможе справлятися з реальними даними, 
які містять пропуски або мають нерівномірний розподіл взаємодій 
користувачів. 
Якість та обсяг вхідних даних: Точність рекомендацій напряму залежить 
від обсягу даних про дії користувачів (перегляди, додавання до кошика, 
покупки тощо). Невизначеність полягає у тому, що різні користувачі мають 
різну активність – одні залишають багато відгуків, інші лише переглядають 
товари. Це створює проблему нерівномірності даних (data sparsity), яка може 
знизити ефективність моделі. Для подолання цього використовується підхід 
BPR, який оптимізує ранжування навіть при часткових даних, враховуючи 
порівняння між парами товарів. 
Оптимізація параметрів моделі: Під час навчання моделі BPR існує 
невизначеність у виборі оптимальних гіперпараметрів – швидкості навчання, 
кількості латентних факторів, регуляризаційних коефіцієнтів тощо. Занадто 
високе значення параметрів може призвести до переобучення (overfitting), тоді 
як занадто низьке – до недообучення (underfitting). Для мінімізації цієї 
невизначеності застосовувались бібліотеки Cornac AI, pandas, numpy, scipy, які 
забезпечують ефективне налаштування параметрів і перевірку моделі на 
реальних даних. 
39 
ЧДТУ 252485.010 ПЗ 
Масштабування системи: Зі збільшенням кількості користувачів і товарів 
постає питання масштабованості. Невизначеність полягає в тому, наскільки 
ефективно алгоритм BPR зможе працювати на великих обсягах даних без 
втрати швидкодії. Для цього важливо застосовувати методи оптимізації 
обчислень, паралельну обробку даних і збереження попередньо обчислених 
рекомендацій у кеші. 
Залежність від поведінки користувачів: Рекомендаційна система повністю 
базується на діях користувачів. Якщо користувачі змінюють свої вподобання 
або взаємодіють нехарактерним чином (наприклад, переглядають товари 
випадково), це може внести похибку у результати. Тому важливо регулярно 
оновлювати дані та перенавчати модель. 
Таким чином, розкриття невизначеностей дозволяє чітко визначити межі 
застосування моделі BPR, зрозуміти її сильні та слабкі сторони, а також 
підготувати систему до можливих змін і розширень у майбутньому. Це є 
невід’ємною складовою системного підходу до розробки рекомендаційних 
систем у сфері електронної комерції. 
2.1.5 Технічний аналіз 
Технічні аспекти створення платформи передбачають підбір інженерних 
інструментів, з використанням яких реалізація платформи є можливою. 
HTML5 
HTML5 (HyperText Markup Language) – це сучасна мова гіпертекстової 
розмітки, яка використовується для створення структури та змісту веб-сторінок. 
Вона є основою будь-якого веб-додатку чи сайту, адже визначає, як саме на 
сторінці відображатимуться тексти, зображення, відео, кнопки, форми та інші 
елементи. HTML5 дозволяє створювати логічну структуру сторінки за 
допомогою заголовків, абзаців, таблиць і блоків, що забезпечує зручність 
сприйняття інформації користувачем. 
Мова HTML також надає можливість створювати гіперпосилання, які 
забезпечують зручну навігацію між сторінками або зовнішніми ресурсами. 
40 
ЧДТУ 252485.010 ПЗ 
Завдяки підтримці мультимедійних елементів, таких як зображення, аудіо та 
відео, веб-сторінки стають більш інтерактивними та привабливими. Крім того, 
HTML5 підтримує створення форм для збору даних від користувачів – це 
можуть бути поля для входу, пошуку або реєстрації, що робить взаємодію з 
сайтом більш ефективною. 
HTML5 також дозволяє задавати метадані сторінки – мову, опис, ключові 
слова, що полегшує роботу пошукових систем і забезпечує коректне 
відображення в браузері. Важливою особливістю є повна сумісність із усіма 
сучасними браузерами, що гарантує стабільну роботу веб-додатків на різних 
пристроях. HTML5 використовується разом із CSS для оформлення 
зовнішнього вигляду сторінок і JavaScript для створення інтерактивної 
поведінки, що робить його основою клієнтської частини веб-додатків. 
Також мова розмітки застосовується для побудови форм взаємодії з 
користувачем – введення даних, перегляду товарів, залишення відгуків тощо. 
HTML забезпечує логічну навігацію системою, дозволяє переходити між 
розділами та спрощує процес взаємодії з платформою. У поєднанні з CSS 
створюється адаптивний дизайн, який забезпечує коректне відображення 
інтерфейсу як на комп’ютерах, так і на мобільних пристроях. 
Отже, HTML5 є ключовим елементом клієнтської частини системи 
прогнозування вподобань користувачів. Саме завдяки йому забезпечується 
зручний, зрозумілий та привабливий інтерфейс, через який користувач 
взаємодіє з рекомендаційною системою, що базується на алгоритмах 
машинного навчання. 
Java/ SB 
Java – це об’єктно-орієнтована високорівнева мова програмування, відома 
своєю надійністю, безпечністю та кросплатформністю. У межах цього проєкту 
Java використовується як основа для реалізації бізнес-логіки системи, обробки 
користувацьких запитів і взаємодії з базою даних. Саме на Java побудовано 
серверну частину, яка відповідає за керування даними, обробку рекомендацій і 
забезпечення стабільної роботи всієї системи. 
41 
ЧДТУ 252485.010 ПЗ 
SB, який використовується разом із Java, є сучасним фреймворком, що 
спрощує створення веб-додатків завдяки автоматичній конфігурації, 
вбудованому серверу Tomcat і підтримці REST API. Він дозволяє швидко 
створювати контролери для прийому та обробки HTTP-запитів, організовувати 
взаємодію з базою даних через Spring Data JPA, а також реалізовувати 
механізми авторизації та автентифікації користувачів за допомогою Spring 
Security. Крім того, SB забезпечує зручну інтеграцію між різними 
компонентами системи, включаючи обмін даними з Python-модулями через 
REST API. Завдяки цьому створюється модульна, гнучка система, яку можна 
легко розширювати – наприклад, для додавання нових моделей машинного 
навчання. 
Java та SB є ключовими технологіями серверної частини системи 
прогнозування вподобань користувачів, що забезпечують надійність, 
продуктивність і масштабованість проєкту. Використання Java дозволяє 
реалізувати складні алгоритми обробки даних, керувати потоками запитів і 
підтримувати високий рівень безпеки під час роботи з користувацькою 
інформацією. Мова забезпечує стабільну роботу серверної логіки навіть при 
великій кількості одночасних запитів, що є критично важливим для систем 
електронної комерції. Крім того, Java легко інтегрується з різними бібліотеками 
й зовнішніми сервісами, що дозволяє розширювати функціональність без 
значних змін у коді. 
SB у цій архітектурі виступає центральним компонентом, який забезпечує 
швидку розробку, зручне тестування та розгортання додатка. Його автоматична 
конфігурація суттєво скорочує обсяг рутинного коду, дозволяючи зосередитись 
на бізнес-логіці. У проєкті реалізовано REST API, який слугує каналом зв’язку 
між клієнтським інтерфейсом, базою даних і аналітичним модулем на Python. 
Використання Spring Data JPA спрощує роботу з базою даних, оскільки система 
автоматично генерує SQL-запити на основі визначених репозиторіїв. Це робить 
обмін даними між сервером і сховищем більш ефективним і безпечним. 
42 
ЧДТУ 252485.010 ПЗ 
SB також забезпечує можливість створення розподілених сервісів, що 
дозволяє масштабувати систему в майбутньому. Використання Spring Security 
дає змогу контролювати доступ до персональних даних користувачів, 
захищаючи систему від несанкціонованих дій. Крім того, інтеграція зі 
сторонніми аналітичними сервісами або Python-модулями відбувається через 
зручні REST-запити, що забезпечує чітке розділення відповідальностей між 
компонентами. Завдяки такій побудові архітектури Java та SB утворюють 
надійний каркас системи, який поєднує стабільність класичних рішень із 
гнучкістю сучасних підходів до розробки. 
Python 
Основна аналітична частина системи реалізована мовою Python. Це 
пояснюється тим, що Python має потужну екосистему бібліотек, які 
використовуються для машинного навчання, статистичного аналізу та побудови 
рекомендаційних систем. Python відповідає за попередню обробку даних 
користувачів, аналіз логів переглядів, покупок і вподобань, а також побудову 
моделі Bayesian Personalized Ranking (BPR). Ця модель реалізує алгоритм 
колаборативної фільтрації, який вчиться на основі пар користувач–позитивний 
товар–негативний товар і дозволяє прогнозувати, які товари можуть зацікавити 
користувача. Для побудови моделі використовуються бібліотеки NumPy, 
Pandas, scikit-learn та LightFM (або implicit), які забезпечують ефективну роботу 
з великими наборами даних. Python формує результати у форматі JSON і 
передає їх Java-сервісу через REST API, де вони обробляються й 
відображаються користувачеві. 
Python у цьому проєкті виступає як інтелектуальне ядро системи, що 
відповідає за реалізацію алгоритмів машинного навчання та формування 
персоналізованих рекомендацій. Завдяки своїй гнучкості та широкому набору 
бібліотек Python став стандартом у сфері аналізу даних і побудови моделей 
прогнозування. Його використання дозволяє легко працювати з великими 
обсягами інформації, проводити глибоку аналітику та швидко тестувати різні 
підходи до навчання моделей. У даному випадку Python забезпечує збір і 
43 
ЧДТУ 252485.010 ПЗ 
попередню підготовку даних – очищення, нормалізацію, обробку пропусків, 
кодування категоріальних змінних та створення матриць користувач–товар, які 
є основою для подальшого навчання рекомендаційної моделі. 
Ключовим елементом є модель Bayesian Personalized Ranking (BPR), яка 
реалізує підхід колаборативної фільтрації. Вона навчається на парах даних, де 
визначається, який із двох товарів користувач надає перевагу, і таким чином 
формує приховане представлення як користувачів, так і товарів. Це дозволяє 
системі виявляти закономірності у взаємодії між користувачами та продуктами 
навіть за відсутності прямих оцінок. У результаті модель може передбачати, які 
товари, з найбільшою ймовірністю, зацікавлять конкретного користувача на 
основі поведінки інших з подібними вподобаннями. 
Для реалізації обчислень використовуються бібліотеки NumPy і Pandas, 
які забезпечують ефективну роботу з великими наборами даних та матричними 
структурами. Бібліотека scikit-learn використовується для проведення 
попереднього аналізу, нормалізації даних та оцінки якості моделей, тоді як 
LightFM або implicit застосовуються для побудови самої BPR-моделі. Таке 
поєднання інструментів забезпечує високу точність, швидкість навчання та 
гнучкість у налаштуванні параметрів алгоритму. 
Результати обчислень Python формує у форматі JSON, після чого передає 
їх до серверної частини, реалізованої на Java/SB, через REST API. Це дозволяє 
зберігати чітку структуру взаємодії між модулями: Python відповідає за 
аналітику та прогнозування, а Java – за обробку результатів, взаємодію з 
користувачем і відображення рекомендацій. Такий підхід забезпечує високу 
ефективність і модульність системи, дозволяючи легко оновлювати або 
замінювати модель машинного навчання без необхідності змінювати основний 
серверний код. 
Thymeleaf 
Для візуалізації результатів і створення динамічного інтерфейсу 
використовується шаблонізатор Thymeleaf. Він інтегрується зі Spring MVC і 
дозволяє формувати HTML-сторінки безпосередньо на сервері з урахуванням 
44 
ЧДТУ 252485.010 ПЗ 
стану системи. Завдяки цьому можна динамічно відображати рекомендації, 
повідомлення чи статистику. Використання умовної логіки прямо в шаблонах 
робить розробку гнучкішою, а інтеграція з CSS і Bootstrap забезпечує сучасний 
зовнішній вигляд сторінок. 
Thymeleaf у даному проєкті виконує роль серверного механізму 
формування користувацького інтерфейсу, який поєднує динамічність 
відображення з гнучкістю розробки. Завдяки інтеграції зі Spring MVC він 
дозволяє безпосередньо передавати дані з контролерів до HTML-шаблонів, що 
робить можливим побудову сторінок, які автоматично оновлюються відповідно 
до стану системи. Це особливо важливо для рекомендаційної системи, де 
контент постійно змінюється залежно від дій користувачів і результатів моделі 
прогнозування. 
Використання умовної логіки безпосередньо в шаблонах дозволяє гнучко 
керувати відображенням елементів інтерфейсу – наприклад, показувати 
рекомендації лише тоді, коли вони доступні, або виводити повідомлення про 
оновлення даних. Thymeleaf також підтримує динамічну генерацію таблиць, 
карток товарів, повідомлень і елементів навігації, що забезпечує повну 
взаємодію між даними, отриманими з серверної частини, та візуальним 
відображенням. 
Завдяки повній сумісності з CSS і фреймворком Bootstrap Thymeleaf 
дозволяє створювати сучасний, адаптивний інтерфейс із привабливим 
дизайном. Це робить сторінки не лише функціональними, а й естетично 
приємними для користувачів. Такий підхід забезпечує зручність взаємодії з 
системою та створює позитивний користувацький досвід, що є важливим 
аспектом для веб-застосунків у сфері електронної комерції. 
Bootstrap 5 та CSS3 
Дизайн користувацького інтерфейсу побудований за допомогою Bootstrap 
5 та CSS3. Bootstrap дозволяє створювати адаптивні сторінки, які однаково 
добре виглядають як на комп’ютерах, так і на мобільних пристроях. З його 
допомогою реалізовано панель навігації, картки товарів, профіль користувача 
45 
ЧДТУ 252485.010 ПЗ 
та інтерактивні елементи інтерфейсу. CSS3 використовується для детального 
налаштування вигляду елементів – кольорів, шрифтів, відступів, анімацій та 
адаптивного дизайну через медіа-запити. Разом вони забезпечують зручний, 
інтуїтивний і привабливий інтерфейс для користувача. 
PostgreSQL 
Усі дані зберігаються в реляційній базі даних PostgreSQL, яка відома 
своєю стабільністю, безпечністю та підтримкою складних SQL-запитів. У ній 
зберігається інформація про користувачів, товари, взаємодії між ними 
(перегляди, покупки, оцінки) і згенеровані рекомендації. Доступ до бази 
здійснюється через Spring Data JPA, що дозволяє формувати SQL-запити 
автоматично на основі описаних інтерфейсів, зменшуючи обсяг ручного коду та 
підвищуючи продуктивність розробки. 
PostgreSQL у цьому проєкті виконує роль основного сховища даних, 
забезпечуючи надійність, цілісність і швидкий доступ до великої кількості 
інформації. Завдяки своїй реляційній природі PostgreSQL дозволяє ефективно 
працювати з пов’язаними таблицями, що є необхідним для реалізації логіки 
рекомендаційної системи, де важливо враховувати зв’язки між користувачами, 
товарами та їхньою взаємодією. У базі даних зберігаються ключові сутності – 
від облікових записів користувачів до історії їхніх дій, що дає змогу формувати 
персоналізовані рекомендації на основі поведінкових даних. 
Spring Data JPA, який використовується для взаємодії з PostgreSQL, 
автоматизує більшість рутинних операцій із базою даних, зокрема створення, 
оновлення та вибірку записів. Це дозволяє зосередитися на реалізації бізнес-
логіки, не витрачаючи час на написання складних SQL-запитів вручну. Крім 
того, використання ORM-підходу (Object-Relational Mapping) забезпечує 
прозоре перетворення об’єктів Java у таблиці БД, що спрощує розробку та 
підвищує зручність підтримки коду. 
PostgreSQL також підтримує транзакційність, індексацію та оптимізацію 
запитів, що забезпечує стабільну роботу навіть при великих навантаженнях. Це 
робить її оптимальним вибором для систем, які обробляють значні обсяги 
46 
ЧДТУ 252485.010 ПЗ 
даних і потребують високої надійності – як у випадку з платформою 
прогнозування вподобань користувачів у сфері електронної комерції. 
Docker у цьому проєкті відіграє ключову роль у забезпеченні 
стабільності, масштабованості та простоти розгортання системи. Завдяки 
контейнеризації кожен компонент – серверна частина на SB, аналітичний 
модуль на Python, база даних PostgreSQL та веб-сервер Nginx – працює у 
власному ізольованому середовищі, що усуває конфлікти залежностей і 
гарантує передбачувану поведінку системи на будь-якому етапі розробки або 
експлуатації. 
Використання Docker значно спрощує процес налаштування проєкту, 
оскільки усі параметри конфігурації описані у файлі docker-compose.yml. Це 
дозволяє розробникам і адміністраторам запускати систему однією командою, 
без необхідності окремо встановлювати базу даних, Python або серверну 
частину. Такий підхід підвищує ефективність командної роботи, адже всі 
учасники отримують однакове середовище, незалежно від операційної системи 
чи локальних налаштувань. 
REST API 
Обмін даними між Java та Python відбувається через REST API. Java-
сервіс надсилає HTTP-запит до Python-модуля з даними користувача, після чого 
Python обробляє їх, формує список рекомендованих товарів і повертає 
результат у форматі JSON. Отримані результати SB передає до шаблонів 
Thymeleaf, де вони візуалізуються у вигляді рекомендацій для користувача. 
Такий підхід дозволяє чітко розмежувати аналітичну частину (Python) та бізнес-
логіку (Java), забезпечуючи ефективну та стабільну взаємодію між ними. 
Отже, обраний стек технологій – Java, SB, Python, PostgreSQL, Docker, 
Thymeleaf, Bootstrap і CSS3 – дозволяє створити масштабовану, надійну та 
ефективну систему для прогнозування вподобань користувачів у сфері 
електронної комерції. Поєднання Java та Python забезпечує глибокий 
аналітичний потенціал і стабільність роботи, тоді як сучасний інтерфейс 
гарантує комфорт користувачів. Модель BPR є ядром системи рекомендацій, 
47 
ЧДТУ 252485.010 ПЗ 
яке забезпечує персоналізований підхід і підвищує ефективність електронної 
комерції за рахунок точного передбачення інтересів користувачів. 
2.1.6 Теорія та гіпотеза дослідження 
Теоретичні засади дослідження ґрунтуються на принципах побудови 
рекомендаційних систем та методах машинного навчання, які застосовуються 
для прогнозування вподобань користувачів у системах електронної комерції. 
Передбачається, що аналіз поведінки користувачів, їхніх взаємодій із товарами 
та історії переглядів дозволяє формувати персоналізовані рекомендації, які 
підвищують ефективність роботи платформи та покращують користувацький 
досвід. 
Гіпотеза дослідження полягає в тому, що інтеграція моделі машинного 
навчання, побудованої за методом колаборативної фільтрації (зокрема, 
алгоритму BPR), забезпечить точніше прогнозування інтересів користувачів. 
Це, у свою чергу, призведе до зростання рівня персоналізації пропозицій, 
задоволеності користувачів та підвищення ефективності продажів. У межах 
дослідження передбачається, що застосування такої моделі дозволить більш 
точно враховувати схожість між користувачами та їхніми попередніми діями, 
що сприятиме подальшому розвитку інформаційної системи електронної 
комерції та її адаптації до змін ринкової поведінки. 
2.2. Експериментальні дослідження 
2.2.1 Експериментальне середовище 
Принципи дії і характеристики розробленої дослідницької програмної 
системи 
Для наочного демонстрування принципу дії розробленої дослідницької 
програмної системи доцільно графічно відобразити її основні компоненти та 
взаємозв’язки між ними. У поточній реалізації система представлена у вигляді 
веб-платформи, яка включає окремі функціональні сторінки для користувачів і 
працівників. Така структурна побудова забезпечує зручність використання, 
48 
ЧДТУ 252485.010 ПЗ 
логічну організацію інтерфейсу та можливість розширення функціональності, 
такими як: 
− головна сторінка (index.html); 
− головне меню (menunavy); 
− сторінки продуктів (index.html, editProduct.html, newProduct.html); 
− сторінки замовлень (index.html, choiceProduct.html, edit.html, item.html, 
newOrder); 
− сторінки виробників(editManufacturer.html, manufacturers.html, 
newManufacturer.html); 
− сторінки працівників (employees.html, newEmployee.html, 
editEmployee.html); 
− сторінки користувачів(clients.html, editClient.html, newClient.html) 
− сторінка кошику(index.html); 
− сторінки авторизації та реєстрації; 
− сторінки фрагментів(footer.html, head.html, nav_page.html, navbar.html, 
slider.html, theme) 
Сторінки для працівника почергово показані на Рис.2.1.-2.10. 
 
 
Рисунок 2.1 – Головна сторінка 
49 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 2.2 – Список клієнтів 
 
 
Рисунок 2.3 – Список працівників 
 
 
Рисунок 2.4 – Список виробників 
50 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 2.5 – Сторінка створення товару 
 
Рисунок 2.6 – Сторінка усіх замовлень 
 
Сторінки авторизованого користувача почергово показані на Рис.2.7.-
2.10. 
 
 
Рисунок 2.7 – Головна сторінка 
51 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 2.8 – Кошик з замовленими товарами 
 
 
Рисунок 2.9 – Замовлення користувача 
 
 
Рисунок 2.10 – Список всіх замовлень користувача 
 
Далі хотів би відобразити окремі фрагменти сайту притаманні усім 
сторінкам на Рис.2.11.-2.14. 
 
52 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 2.11 – Можливість зміни акаунту та локалізації сайту 
 
 
Рисунок 2.12 – Сторінка реєстрації 
 
 
Рисунок 2.13 – Сторінка авторизації 
53 
ЧДТУ 252485.010 ПЗ 
Також на сторінці авторизації присутній вхід за допомогою облікового 
запису Гугл. 
 
 
Рисунок 2.14 – Футер сайту 
 
Вище були деталізовано показані сторінки платформи з їх змістом. 
2.2.2 Опис елементів середовища 
Розроблена рекомендаційна система реалізована у вигляді веб-
платформи, яка поєднує в собі серверну частину, модуль машинного навчання 
та клієнтський інтерфейс. Кожен із цих елементів виконує окрему функцію, 
забезпечуючи цілісність і стабільність роботи системи. Основна взаємодія 
відбувається між користувачем, який переглядає товари, та аналітичним 
модулем, що формує персоналізовані рекомендації на основі поведінкових 
даних. 
Користувацька частина представлена низкою сторінок, які забезпечують 
інтуїтивну навігацію та комфортне користування платформою. Головна 
сторінка (index.html) відображає каталог товарів, актуальні рекомендації та 
загальну інформацію про систему. Меню (menunavy) дозволяє переходити між 
основними розділами – товарами, кошиком, замовленнями, профілем 
користувача та сторінкою авторизації. Сторінки продуктів (index.html, 
editProduct.html, newProduct.html) відповідають за відображення списку товарів, 
редагування їхніх характеристик і додавання нових позицій. 
Сторінки замовлень (index.html, choiceProduct.html, edit.html, item.html, 
newOrder) реалізують функції перегляду історії покупок, формування нового 
замовлення та вибору товарів. Сторінки виробників (editManufacturer.html, 
54 
ЧДТУ 252485.010 ПЗ 
manufacturers.html, newManufacturer.html) забезпечують адміністрування даних 
про компанії-виробники, тоді як сторінки працівників (employees.html, 
newEmployee.html, editEmployee.html) дозволяють керувати персоналом 
системи. 
Для користувачів передбачені сторінки (clients.html, editClient.html, 
newClient.html), що дають змогу переглядати список клієнтів, редагувати їхні 
профілі або створювати нові облікові записи. Окремо функціонує сторінка 
кошика (index.html), де відображаються вибрані товари перед оформленням 
замовлення. 
Система також містить сторінки авторизації та реєстрації, що реалізують 
захищений доступ користувачів і працівників до функціоналу платформи. Для 
повторного використання елементів інтерфейсу застосовуються фрагменти 
сторінок (footer.html, head.html, nav_page.html, navbar.html, slider.html, theme), 
які відповідають за відображення спільних частин сайту – шапки, меню, 
підвалу, слайдерів і тем оформлення. 
Такий підхід до організації структури веб-додатку дозволяє ефективно 
розділити обов’язки між різними компонентами системи, забезпечити 
модульність, простоту підтримки та можливість подальшого розширення. 
Сторінки для адміністратора та користувача, що відображають відповідні 
сценарії роботи системи, наведено на Рис. 2.1–2.14. 
2.2.3 Імітаційний метод 
Використовуючи імітаційний метод, на етапі розробки клієнтської 
частини системи мною було створено симуляційне середовище, яке дало змогу 
відтворити роботу основних компонентів платформи електронної комерції та 
проаналізувати, як користувач взаємодіє з різними її елементами (див. рис. 2.7). 
Такий підхід дозволив перевірити функціональність інтерфейсу, логіку 
відображення рекомендацій і поведінку системи за різних сценаріїв 
використання. 
Застосування імітаційних методів дало можливість експериментувати з  
55 
ЧДТУ 252485.010 ПЗ 
різними варіантами конфігурацій алгоритмів, інтерфейсу та параметрів моделі 
BPR до запуску системи у реальному середовищі, що дозволило знизити ризики 
помилок і підвищити якість кінцевого продукту. 
Реалізація користувацьких сторінок була виконана за допомогою 
технологій HTML5, CSS3 та шаблонізатора Thymeleaf, що забезпечило 
адаптивний і зручний інтерфейс. 
Різноманітне використання елементів сторінок у ролі “Користувача” та 
“Адміністратора” дозволило перевірити правильність роботи розробленої 
рекомендаційної системи. Так, “Користувач” мав можливість переглядати 
каталог товарів, переходити між розділами меню, переглядати історію 
взаємодій та отримувати персоналізовані рекомендації. Особливо важливим 
елементом було тестування модуля рекомендацій – система формувала список 
товарів на основі поведінки інших користувачів, імітуючи роботу моделі 
Bayesian Personalized Ranking (BPR). У цей момент відбувалася перевірка 
алгоритму колаборативної фільтрації: для кожного користувача система 
підбирала товари, які з високою ймовірністю могли його зацікавити, навіть 
якщо він раніше їх не переглядав. 
Водночас роль “Адміністратора” передбачала перевірку функціоналу 
керування базою користувачів і товарів, моніторинг взаємодій, а також 
контроль за роботою рекомендаційного модуля. Адміністратор мав змогу 
переглядати статистику запитів, аналізувати точність рекомендацій і, за 
потреби, оновлювати модель чи налаштування системи. 
Таким чином, імітаційний метод дозволив у безпечному тестовому 
середовищі змоделювати різні сценарії взаємодії користувачів із системою, 
оцінити якість рекомендацій, стабільність роботи серверної частини та 
ефективність обміну даними між компонентами Java/SB, Python і PostgreSQL. 
Це підтвердило працездатність реалізованого програмного засобу та його 
готовність до впровадження в реальне середовище. 
2.2.4 Дослідження мінімальної кількості даних для навчання звичайної та 
гібридної моделей рекомендацій 
56 
ЧДТУ 252485.010 ПЗ 
У даному підрозділі проведено порівняльний аналіз мінімальних обсягів 
даних, необхідних для навчання двох типів моделей рекомендацій: звичайної 
моделі, що враховує лише взаємодії користувач–товар та гібридної моделі, яка 
додатково використовує контентні характеристики товарів (категорія, бренд). 
Метою дослідження є визначення порогу кількості даних, за якого модель 
починає демонструвати прийнятну якість, а також порівняння результатів за 
ключовими метриками. 
Для моделі типу BPR / Matrix Factorization, що базується виключно на 
історії взаємодій, встановлено такі мінімальні вимоги: 
− кількість користувачів: не менше 300–500; 
− кількість товарів: не менше 300–500; 
− обсяг взаємодій: ≥ 10 000–20 000; 
− середня кількість взаємодій на користувача: ≥ 5–10. 
При меншому обсязі даних модель демонструє деградацію якості, 
латентні вектори стають нестабільними, а прогнозування – шумовим. Це 
пов’язано з високою чутливістю BPR до перекриття товарів за користувачами 
та необхідністю формування достатньої кількості позитивних і негативних пар 
для навчання. 
Гібридна модель, яка додатково використовує ознаки товарів (категорія, 
бренд), здатна навчатися на значно менших обсягах даних. Встановлено, що її 
мінімальні вимоги становлять; 
− кількість користувачів: ≥ 100–200; 
− кількість товарів: ≥ 150–200; 
− обсяг взаємодій: ≥ 2 000–5 000; 
− наявність фіч: щонайменше 2 (категорія, бренд). 
Завдяки контентним ознакам гібридна модель може коректно формувати 
товарні embeddings навіть у випадках малої кількості взаємодій або їх повної 
57 
ЧДТУ 252485.010 ПЗ 
відсутності для окремих товарів (випадок cold-start). 
Для об’єктивного порівняння було змодельовано ситуацію з обмеженим 
набором даних: 
− кількість користувачів: ≥ 100–200; 
− 10 000 взаємодій; 
− 300 товарів; 
− 200 користувачів; 
− ознаки товарів: категорія, бренд. 
Результати за метрикою Recall@10 наведено на Рис.2.15. 
 
 
Рисунок 2.15 – Результати експерименту 
 
Проведені дослідження показали, що звичайна модель рекомендацій, яка 
використовує лише історію взаємодій користувачів з товарами, потребує значно 
більшого обсягу даних для досягнення прийнятної точності. За умов 
обмеженого датасету її результативність знижується, а якість рекомендацій стає 
нестабільною. 
Гібридна модель, доповнена ознаками категорії та бренду, 
продемонструвала здатність працювати ефективно навіть при невеликій 
58 
ЧДТУ 252485.010 ПЗ 
кількості взаємодій. За однакового обсягу даних вона забезпечує у 2–3 рази 
вищі показники якості порівняно зі звичайним підходом. 
Використання додаткових контентних характеристик також значно 
полегшує проблему «cold-start» для нових товарів та дозволяє зменшити 
мінімальні вимоги до обсягу даних у 3–5 разів. 
Таким чином, у контексті малих та середніх e-commerce систем гібридні 
рекомендаційні моделі виявляються більш придатними, оскільки поєднують 
високу точність із можливістю навчання на обмежених даних. 
2.2.5 Оцінка впливу додаткових ознак 
У цьому підрозділі наведено практичні орієнтири щодо приросту метрик 
рекомендаційної моделі при додаванні інформативних ознак, а також 
сформульовано емпіричну залежність для визначення мінімально необхідного 
обсягу взаємодій користувач–товар. 
Нижче на Рис.2.16. зображено орієнтовний відносний приріст метрик 
(Recall@K, NDCG@K) для моделі BPR при додаванні фіч різної 
інформативності. 
 
 
Рисунок 2.16 – Зміна якості при додаванні ознак 
 
Інтервал приросту залежить від середньої інформативності ознак q [0,1] 
та їх незалежності. 
Мінімальна кількість взаємодій, потрібна для стабільного навчання 
моделі, оцінюється за формулою: 
59 
ЧДТУ 252485.010 ПЗ 
      
      
        
де: 
−      – орієнтовний мінімальний обсяг даних; 
− c є [2;8] – константа стабільності (рекомендовано c = 5); 
− k – розмір латентного простору; 
− I – кількість унікальних товарів; 
− F – кількість інформативних ознак; 
− q [0,1] – середня інформативність ознак; 
− γ≈0.6 – коефіцієнт ефективності ознак. 
Формула відображає зменшення вимог до обсягу взаємодій пропорційно 
корисності додаткових ознак. 
Подібні підходи до оцінки мінімального обсягу даних для стабільного 
навчання рекомендаційних моделей розглядаються в роботах з колаборативної 
фільтрації та Bayesian Personalized Ranking [10, 5, 6]. 
Приклад A. Малий магазин 
I=1000, k=20, F=2, q=0.8, c=5,  =0.6: 
            
Приклад B. Середній маркетплейс  
I=10,000, k=50k, F=3, q=0.7: 
             
Приклад C. Модель без ознак 
I=5,000, k=30, F=0 
Nreq≈750,000. 
Практичні рекомендації: 
Дві базові ознаки (категорія, бренд) забезпечують приріст якості на рівні 
20–40% та істотно зменшують проблему cold-start. 
60 
ЧДТУ 252485.010 ПЗ 
Оцінку інформативності ознак q доцільно здійснювати через AUC-аналіз, 
показники однорідності або приріст метрик у крос-валідації. 
Формула служить орієнтиром для планування збору даних та масштабу 
каталогу при впровадженні рекомендаційної системи. 
2.2.6 Оцінка ефективності системи 
Оцінка ефективності розробленої рекомендаційної системи полягає у 
визначенні ступеня відповідності її функціонування поставленим завданням – 
формуванню точних, релевантних та персоналізованих рекомендацій для 
користувачів платформи електронної комерції. Система створена для аналізу 
поведінки користувачів, виявлення їхніх прихованих уподобань і підвищення 
якості взаємодії з веб-платформою за рахунок впровадження алгоритму 
Bayesian Personalized Ranking (BPR). 
Інформаційна складова. 
Основним критерієм оцінки є якість та релевантність рекомендацій, що 
формуються системою. Для цього аналізується точність моделі – наскільки 
добре запропоновані товари збігаються з інтересами користувача. Для 
вимірювання результатів можуть використовуватись метрики, такі як 
Precision@k, Recall@k та Mean Average Precision (MAP), що дозволяють 
оцінити успішність передбачень. Крім того, важливим показником 
ефективності є швидкість формування рекомендацій, що впливає на комфорт 
користувача при роботі з платформою. 
Середовище функціонування. 
Система реалізована у вигляді веб-платформи, що функціонує на основі 
Java SB із підключенням Python-модуля через REST API. Завдяки 
використанню PostgreSQL для зберігання даних та Docker-контейнерів для 
ізольованого розгортання компонентів, забезпечується стабільна робота 
незалежно від операційного середовища. Система зберігає свою ефективність 
як у тестовому, так і у виробничому середовищі, забезпечуючи 
масштабованість і доступність для різних груп користувачів. 
61 
ЧДТУ 252485.010 ПЗ 
Фактори прямої та непрямої дії. 
До прямих факторів належать взаємодії користувачів із системою: 
перегляд товарів, кліки, покупки. Саме ці дані використовуються як вхідні для 
побудови моделі BPR. Ефективність системи у цьому контексті проявляється у 
здатності виявляти закономірності в поведінці користувачів і пропонувати 
товари, які викликають інтерес навіть у тих, хто не здійснював схожих дій 
раніше. Непрямий вплив системи проявляється у зростанні продажів, 
підвищенні рівня залученості користувачів і скороченні часу на пошук товарів. 
Ефективність рішень. 
Одним із ключових показників є швидкість і точність роботи алгоритму 
рекомендацій. В експериментальному середовищі система демонструє швидке 
формування списку персональних рекомендацій завдяки попередньому 
тренуванню моделі на історичних даних. Оптимізація виконання досягається 
завдяки ефективному використанню бібліотек Cornac, NumPy, Pandas та SciPy, 
що зменшують час обробки великих обсягів інформації. 
Взаємодія користувачів. 
Система створює зручне середовище для користувача, який може швидко 
переглядати запропоновані товари, формувати замовлення та оцінювати 
отримані рекомендації. Веб-інтерфейс, побудований із використанням 
Thymeleaf, забезпечує простоту навігації та приємний візуальний досвід, що 
позитивно впливає на залучення користувачів і тривалість їхньої активності на 
платформі. 
Безпека та конфіденційність. 
Важливим аспектом ефективності є забезпечення безпеки даних 
користувачів. Система реалізує Google OAuth-авторизацію, що дозволяє 
користувачам входити без створення додаткових облікових записів, 
використовуючи власні акаунти Google. Це мінімізує ризики несанкціонованого 
доступу та підвищує рівень довіри до платформи. 
Загалом, ефективність системи визначається за кількісними та якісними 
показниками: рівнем точності рекомендацій, швидкістю реакції системи, рівнем 
62 
ЧДТУ 252485.010 ПЗ 
задоволення користувачів і зростанням активності на платформі. У подальших 
етапах планується проведення повномасштабного тестування з реальними 
користувачами для підтвердження гіпотези про те, що використання моделі 
BPR у колаборативній фільтрації сприяє покращенню персоналізації та 
підвищенню ефективності електронної комерції. 
2.2.7 Результати власних досліджень автора 
Одним із ключових напрямів власних досліджень автора у межах даної 
роботи став аналіз сучасних українських онлайн-сервісів, що надають юридичні 
консультації. Було досліджено функціональні можливості, архітектуру, 
принципи взаємодії користувачів та рівень захисту даних у кількох популярних 
платформах, які позиціонують себе як сервіси безоплатної допомоги. Аналіз 
показав, що жоден із них не поєднує у собі таких характеристик, як гарантована 
конфіденційність консультацій, зручність комунікації між користувачами та 
юристами, а також механізм наставництва для перевірки якості консультацій і 
розвитку молодих спеціалістів. 
Результатом цього аналізу стало усвідомлення ключових недоліків 
існуючих рішень – відсутність чіткої системи контролю якості консультацій, 
складна або незручна форма комунікації між сторонами, відсутність 
підтвердження компетенцій учасників процесу. Саме ці спостереження лягли в 
основу розробки власної інформаційної системи, яка поєднує елементи 
навчання, практики та контролю якості юридичних консультацій. 
Власний внесок автора полягає у створенні підходу до організації онлайн-
консультування, який базується на принципах взаємного розвитку учасників – 
користувач отримує якісну безоплатну допомогу, юрист – реальну практику, а 
ментор – можливість наставництва та підвищення авторитету у професійній 
спільноті. Технічно це реалізовано через чітку структуризацію ролей, 
автоматизацію процесів перевірки та сертифікації, а також використання 
сучасних методів побудови інформаційних систем. 
63 
ЧДТУ 252485.010 ПЗ 
Таким чином, проведені дослідження дозволили не лише виявити слабкі 
сторони існуючих аналогів, а й запропонувати нову концепцію побудови 
юридичної онлайн-платформи, що відрізняється інноваційним підходом до 
організації процесу консультацій і створює умови для професійного зростання 
всіх учасників системи. 
2.2.8 Результати досліджень інших автора 
У роботі [24], присвяченій темі «Інформаційна технологія рекомендації 
товарів для платформи онлайн-продажів», автором проведено комплекс 
експериментальних досліджень, спрямованих на оцінювання ефективності 
рекомендаційних алгоритмів у середовищі електронної комерції. 
Основна увага в дослідженні приділяється аналізу поведінки користувачів 
платформи онлайн-продажів та побудові рекомендацій на основі історії їхніх 
взаємодій з товарами. У межах роботи реалізовано та досліджено підхід 
колаборативної фільтрації, який базується на неявних зворотних зв’язках, таких 
як перегляди товарів, додавання до кошика та факти здійснення покупки. Автор 
розглядає ці дії як індикатори зацікавленості користувачів, що дозволяє 
формувати персоналізовані рекомендації без необхідності явного оцінювання 
товарів. 
Експериментальні дослідження проводилися з використанням реального 
або наближеного до реального набору даних, який містив інформацію про 
користувачів, товари та події взаємодії між ними. У процесі експериментів було 
здійснено попередню обробку даних, включаючи очищення, фільтрацію та 
перетворення подій у формат, придатний для навчання рекомендаційної моделі. 
Для побудови рекомендацій застосовувались алгоритми, що дозволяють 
визначати схожість між товарами або користувачами на основі накопиченої 
історії взаємодій. 
Для оцінювання якості рекомендацій автор використовував стандартні 
метрики ефективності рекомендаційних систем, зокрема показники точності та 
релевантності отриманих рекомендацій. Результати експериментів показали, 
64 
ЧДТУ 252485.010 ПЗ 
що використання колаборативної фільтрації на основі поведінкових даних 
користувачів дозволяє значно підвищити якість рекомендацій порівняно з 
базовими або нефільтрованими підходами. Також було встановлено, що 
врахування різних типів взаємодій користувача з товарами позитивно впливає 
на точність рекомендацій. 
У підсумку експериментальні дослідження, представлені в роботі 
підтверджують доцільність застосування інформаційних технологій 
персоналізованих рекомендацій для платформ онлайн-продажів та 
демонструють ефективність використання поведінкових даних користувачів 
при побудові рекомендаційних сервісів. Отримані результати можуть бути 
використані як теоретичне та практичне підґрунтя для подальшого розвитку 
рекомендаційних систем у сфері електронної комерції. 
  
65 
ЧДТУ 252485.010 ПЗ 
Висновки до розділу 2 
У другому розділі було проведено комплексне теоретичне та 
експериментальне дослідження, спрямоване на обґрунтування вибору методів, 
моделей та підходів для створення системи прогнозування вподобань 
користувачів на основі алгоритмів машинного навчання. 
У теоретичній частині проаналізовано можливості застосування 
алгоритму BPR (Bayesian Personalized Ranking), який показав високу 
придатність для побудови рекомендаційних систем із неявними оцінками. 
Розглянуто принципи системного підходу, зокрема пошук раціонального 
компромісу між точністю моделі, швидкодією та обчислювальними ресурсами. 
Проаналізовано потенційні ризики впровадження, невизначеності, пов’язані з 
поведінковими даними користувачів, та особливості їхнього подолання за 
рахунок коректної підготовки даних, нормалізації та вибору відповідних 
параметрів моделі. Проведено технічний аналіз інструментів і технологій, які 
забезпечують можливість ефективної реалізації рекомендаційної системи. 
Сформульовано теоретичні положення дослідження та гіпотезу, яка стверджує, 
що застосування методів колаборативної фільтрації на основі BPR здатне 
суттєво підвищити персоналізацію та ефективність електронної комерції. 
У експериментальній частині описано архітектуру експериментального 
середовища, що включає серверну частину, базу даних, модуль збору 
поведінкових подій та модель машинного навчання. Детально розглянуто 
елементи середовища, зокрема структуру даних, параметри моделі та механізм 
обробки подій користувача. Для дослідження було застосовано імітаційний 
метод, який дозволив відтворити типову поведінку користувачів та оцінити 
реакцію моделі за різних сценаріїв. Проведено комплексну оцінку ефективності 
розробленої системи за метриками рекомендаційної точності та поведінковими 
показниками. 
Отримані результати підтвердили висунуту гіпотезу: модель BPR дійсно 
покращує якість прогнозування вподобань і забезпечує більш релевантні 
66 
ЧДТУ 252485.010 ПЗ 
персоналізовані рекомендації. Це свідчить про доцільність та ефективність 
використання даного підходу у системах електронної комерції. 
Таким чином, дослідження, виконані у розділі 2, сформували науково 
обґрунтовану основу для практичної реалізації програмної системи, що 
розробляється у подальших розділах роботи. 
67 
ЧДТУ 252485.010 ПЗ 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
3.1. Моделювання предметної області 
Важливим етапом у процесі проєктування інформаційної системи є 
моделювання предметної області – побудова спрощеної концептуальної моделі, 
що дає змогу краще зрозуміти структуру та логіку роботи системи. Основна 
мета цього етапу полягає у виявленні ключових елементів, властивостей і 
взаємозв’язків, які характеризують реальні процеси, що відображаються у 
програмному продукті. Для цього створюються різні типи моделей – логічні, 
математичні, комп’ютерні чи вербальні – які допомагають описати 
функціонування системи та забезпечують основу для її подальшої реалізації. 
3.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Модель предметної області розроблюваної системи прогнозування 
вподобань користувачів у сфері електронної комерції полягає у створенні 
механізму, що дозволяє аналізувати поведінку користувачів на платформі, 
виявляти їхні інтереси та формувати персоналізовані рекомендації товарів. 
Завдяки цій системі користувач отримує пропозиції, максимально наближені до 
його смаків, а адміністратор або власник магазину – аналітичну інформацію 
щодо популярності товарів та активності клієнтів. 
Словник предметної області включає основні поняття, що 
використовуються в процесі моделювання системи електронної комерції з 
елементами машинного навчання. До них належать: користувач – особа, яка 
взаємодіє з системою, здійснюючи перегляди, покупки або оцінки товарів; 
товар – об’єкт, що підлягає рекомендації; рейтинг – числове або логічне 
відображення вподобань користувача; взаємодія – дія користувача відносно 
товару (перегляд, додавання до кошика, покупка, оцінка); рекомендаційна 
система – модуль, що на основі зібраних даних формує перелік товарів, 
68 
ЧДТУ 252485.010 ПЗ 
імовірно цікавих користувачеві; алгоритм BPR (Bayesian Personalized Ranking) – 
метод ранжування, який дозволяє навчити модель визначати, які товари 
користувач надає перевагу порівняно з іншими. 
Формалізація моделі предметної області та визначення її ключових 
об’єктів дозволили створити концептуальну структуру системи, у якій 
відображено зв’язки між користувачами, товарами, взаємодіями та 
згенерованими рекомендаціями, що є основою подальшого проектування та 
реалізації системи. 
3.1.2 Елементи моделювання предметної області 
Одним із етапів моделювання предметної області є визначення графічних 
символів, що будуть використовуватись при побудові UML діаграм (Рис. 3.1). 
 
 
Рисунок 3.1 – Основні графічні символи UML 
 
Наступним кроком опишемо єднальні елементи UML, що плануються до 
використання, що зображені на рисунку 3.2. 
69 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.2 – Єднальні елементи UML 
 
Представлені елементи моделювання предметної області в повній мірі 
дозволяють скласти різноманітні діаграми. 
3.1.3 Робоча область моделювання 
В якості робочої області моделювання розглянемо систему електронної 
комерції, яка використовує методи машинного навчання для прогнозування 
вподобань користувачів і формування персоналізованих рекомендацій товарів. 
Основна мета такої системи полягає в тому, щоб підвищити зручність 
користувачів під час пошуку та вибору товарів, а також збільшити ефективність 
продажів за рахунок точнішого розуміння інтересів клієнтів. 
Передбачається, що користувач заходить на веб-платформу, переглядає 
каталог товарів і взаємодіє з ними – додає до кошика, переглядає деталі або 
залишає оцінку. Усі ці дії фіксуються системою, після чого дані потрапляють 
до модуля машинного навчання, який аналізує історію переглядів, покупки та 
оцінки, щоб створити індивідуальний профіль користувача. На основі цього 
70 
ЧДТУ 252485.010 ПЗ 
профілю система формує перелік рекомендованих товарів, який динамічно 
оновлюється відповідно до змін у поведінці користувача. 
Для коректного створення системи, яка задовольняє потреби користувачів 
і власників інтернет-магазину, необхідно чітко визначити її бізнес-функції. До 
таких функцій належать: збір та зберігання даних про користувачів і товари, 
формування рекомендацій на основі алгоритмів машинного навчання, 
відображення персоналізованого каталогу, обробка замовлень і надання 
адміністративного доступу для аналітики. 
На рисунку 3.3 наведена узагальнена модель предметної області системи 
електронної комерції з модулем прогнозування вподобань користувачів. Вона 
включає основні сутності – Користувач, Товар, Замовлення, Виробник та 
Аналітичний модуль, між якими визначені зв’язки, що відображають логіку 
функціонування системи та процес прийняття рішень у межах 
рекомендаційного механізму. 
 
 
Рисунок 3.3 – Модель предметної області іnternet-магазину 
71 
ЧДТУ 252485.010 ПЗ 
3.2 Формування та аналіз вимог 
Етап формування та аналізу вимог є одним із найважливіших у процесі 
розробки системи, оскільки він полягає у визначенні того, якою має бути 
система та які функції вона повинна виконувати. Основна мета цього етапу – 
з’ясувати, узгодити та задокументувати очікування користувачів і замовників у 
чіткій та зрозумілій формі, що стане основою для подальшого проектування й 
реалізації програмного забезпечення. 
3.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги 
Формування вимог до програмного забезпечення 
На етапі формування вимог до програмного забезпечення важливо 
визначити очікування та потреби замовника, а також конкретизувати 
функціональні та нефункціональні характеристики майбутньої системи. У 
контексті системи машинного навчання для прогнозування вподобань 
користувачів в електронній комерції цей процес передбачає збір і аналіз вимог 
від замовника, які фіксуються у структурованому вигляді. Функціональні 
вимоги описують, що саме має робити система (наприклад, збір, аналіз і 
прогнозування користувацьких дій), тоді як нефункціональні визначають, як 
вона повинна працювати (швидкість, точність, безпека, масштабованість тощо). 
Після узгодження всі вимоги затверджуються і стають основою для 
проектування системи. 
Первинна вимога замовника 
Система повинна забезпечувати автоматичний аналіз поведінки 
користувачів на основі історії їх взаємодій із товарами (перегляди, покупки, 
оцінки тощо) та формувати персоналізовані рекомендації з використанням 
алгоритмів машинного навчання. Очікується, що система підвищить точність 
прогнозування вподобань і сприятиме зростанню рівня продажів в електронній 
комерції. 
72 
ЧДТУ 252485.010 ПЗ 
Детальні вимога замовника: 
− система повинна працювати в автоматичному режимі без необхідності 
ручного втручання адміністратора під час формування рекомендацій; 
− рекомендації мають формуватися з урахуванням індивідуальної 
поведінки кожного користувача; 
− система повинна підтримувати обробку великої кількості 
користувачів та товарів без суттєвого зниження продуктивності; 
− результати рекомендацій повинні оновлюватися з урахуванням нових 
дій користувачів; 
− система має забезпечувати швидку відповідь на запити рекомендацій 
у режимі реального часу; 
− повинна бути передбачена можливість інтеграції рекомендаційного 
модуля з веб-інтерфейсом платформи онлайн-продажів; 
− результати роботи системи мають бути зрозумілими та придатними 
для подальшого аналізу. 
Первинна вимога розробника 
Програмна система повинна бути реалізована з використанням сучасних 
підходів машинного навчання та мати модульну, масштабовану архітектуру, 
яка дозволяє легко модифікувати або розширювати функціональність, зокрема 
шляхом заміни або додавання нових алгоритмів рекомендацій, джерел даних та 
методів оцінювання якості. 
Детальні вимоги розробника 
− система повинна мати можливість отримувати дані про користувачів і 
товари з БД або зовнішніх джерел; 
− повинна бути реалізована попередня обробка даних – очищення, 
нормалізація, видалення пропусків; 
73 
ЧДТУ 252485.010 ПЗ 
− має бути створено модуль навчання моделей машинного навчання 
(наприклад, BPR або колаборативної фільтрації); 
− система повинна забезпечувати можливість тестування та оцінки 
якості прогнозування (наприклад, за метриками precision, recall, 
RMSE); 
− повинен бути реалізований механізм формування персоналізованих 
рекомендацій для кожного користувача; 
− система має підтримувати збереження результатів у базі даних і 
можливість подальшої інтеграції з інтерфейсом користувача; 
− необхідно забезпечити оновлення моделей у реальному часі або за 
розкладом для підтримки актуальності рекомендацій. 
Функціональні вимоги 
− збір і зберігання даних про користувачів і товари; 
− попередня обробка та фільтрація даних; 
− навчання моделей машинного навчання на основі історичних даних; 
− формування прогнозів щодо вподобань користувачів; 
− видача персоналізованих рекомендацій у вигляді списку товарів; 
− оцінювання ефективності моделі та адаптація параметрів при потребі. 
Нефункціональні вимоги 
− висока продуктивність і швидкість обробки запитів; 
− масштабованість для роботи з великими обсягами даних; 
− точність прогнозів і стабільність результатів; 
− точність прогнозів і стабільність результатів; 
− зручність інтеграції з існуючими платформами електронної комерції; 
− модульність архітектури для спрощення подальшої розробки; 
74 
ЧДТУ 252485.010 ПЗ 
− наявність документації та можливість подальшого розширення 
функціональності. 
Необхідно забезпечити оновлення моделей у реальному часі або за 
розкладом для підтримки актуальності рекомендацій. 
3.2.2 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (використання) – це графічне представлення 
взаємодії користувачів із системою, що дозволяє описати основні функції, які 
реалізовує система, та зв’язки між зовнішніми акторами й її внутрішніми 
компонентами. Вона є основою для визначення функціональних вимог і 
використовується для моделювання поведінки системи з точки зору 
користувача. 
Діаграма прецедентів розроблена з використанням мови UML і 
представлена на рисунку 3.4. 
 
Рисунок 3.4 – Діаграма прецедентів системи 
 
Опис діаграми прецедентів: 
75 
ЧДТУ 252485.010 ПЗ 
1 Користувач – основний актор, який взаємодіє із системою. Він може 
отримувати рекомендації, переглядати товари та користуватися 
персоналізованими пропозиціями. 
2 Система електронної комерції (E-Commerce System) – головний 
компонент, який забезпечує роботу системи. Вона збирає дані про користувача, 
обробляє інформацію та взаємодіє з іншими підсистемами для формування 
рекомендацій. 
3 Модуль машинного навчання (ML Module) – підсистема, яка аналізує 
зібрані дані користувача та створює індивідуальні рекомендації. Також виконує 
персоналізацію пропозицій для користувача на основі історії покупок та 
поведінки. 
4 Адміністратор (Admin) – користувач із розширеними правами, який 
може переглядати та налаштовувати персоналізовані пропозиції, контролювати 
роботу модуля машинного навчання та перевіряти ефективність рекомендацій. 
5 Функції системи (прецеденти): 
− отримання рекомендацій (Generate Recommendations) – забезпечує 
користувача добіркою товарів, що можуть його зацікавити; 
− збір даних користувача (Gather User Data) – реєструє інформацію про 
перегляди, покупки та дії користувача на сайті; 
− аналіз ефективності рекомендацій (Analyze Recommendation 
Performance) – дозволяє оцінити, наскільки точно система формує 
рекомендації; 
− персоналізація пропозицій (Personalize Offers) – створює унікальні 
маркетингові пропозиції для користувачів, ґрунтуючись на 
результатах аналізу ML-модуля. 
Діаграма прецедентів та її опис у повній мірі відображають 
функціональні можливості системи електронної комерції, окреслюють 
взаємодію між користувачами та модулями системи, що дозволяє чітко 
сформулювати вимоги до її реалізації. 
76 
ЧДТУ 252485.010 ПЗ 
3.2.3 Проектування логічної структури програмного комплексу 
Проектування логічної структури програмного комплексу – це етап 
створення узагальненої моделі системи, яка описує, як саме будуть взаємодіяти 
її основні компоненти для досягнення поставлених цілей. На цьому етапі 
визначається архітектура програмного забезпечення, його логічна побудова та 
зв’язки між окремими модулями. 
Логічне проектування дозволяє зрозуміти, які частини системи 
відповідають за обробку даних, які – за зберігання, а які – за взаємодію з 
користувачем. Також визначаються інтерфейси між компонентами, що 
забезпечують ефективний обмін даними та узгоджену роботу всієї системи. 
У контексті системи машинного навчання для прогнозування вподобань 
користувачів логічна структура може бути поділена на модулі збору даних, 
попередньої обробки, навчання моделі, формування прогнозів та представлення 
результатів. Такий поділ підвищує модульність, що спрощує подальшу 
розробку, тестування й оновлення окремих частин системи. 
Під час проектування важливо враховувати можливість масштабування – 
адже з ростом кількості користувачів або обсягу даних система повинна 
залишатися стабільною та ефективною. Грамотно спроектована логічна 
структура забезпечує гнучкість, надійність та легкість подальшого розвитку 
програмного комплексу. 
3.2.3.1 Діаграми класів 
Діаграма класів – це графічна візуалізація основних об’єктів системи та 
статичних зв’язків між ними, що описує структуру класів, їх атрибути, методи 
та відношення між компонентами. Вона показує, як елементи системи 
взаємодіють один з одним у контексті реалізації механізму персоналізованих 
рекомендацій. 
Діаграма класів розроблена з використанням мови UML і представлена на 
рисунку 3.5. 
 
77 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.5 – Діаграма класів 
 
Опис діаграми класів: 
AppUser: 
Представляє користувача системи (як клієнта, так і співробітника). 
Основні атрибути: 
id: унікальний ідентифікатор; 
username: ім’я користувача; 
email: електронна адреса (унікальна); 
password: пароль; 
role: роль користувача (клієнт, адміністратор, співробітник); 
is_email_verify: позначка підтвердження електронної пошти. 
Зв’язки: 
один користувач може створювати декілька замовлень як клієнт; 
78 
ЧДТУ 252485.010 ПЗ 
один користувач може виступати співробітником, який обробляє 
замовлення. 
Manufacturer: 
Представляє виробника товарів. 
Атрибути: 
id: ідентифікатор виробника; 
name: назва виробника. 
Зв’язки: 
один виробник може мати кілька товарів (один-до-багатьох до Product). 
Product: 
Містить інформацію про товари магазину. 
Основні атрибути: 
id, name, product_category, product_type, model, characteristic, description, 
price; 
manufacturer_id – зовнішній ключ на таблицю Manufacturer. 
Зв’язки: 
належить одному виробнику; 
може входити до кількох позицій замовлення (OrderItem). 
UserOrder 
Представляє замовлення користувача. 
Атрибути: 
id: ідентифікатор замовлення; 
employee_id: посилання на користувача, який обробляє замовлення; 
client_id: клієнт, який зробив замовлення; 
approved: стан підтвердження замовлення. 
Зв’язки: 
містить набір позицій замовлення (OrderItem); 
пов’язане з клієнтом і співробітником (AppUser). 
OrderItem: 
Відображає конкретну позицію в замовленні. 
79 
ЧДТУ 252485.010 ПЗ 
Атрибути: 
id, price, quantity; 
order_id – посилання на замовлення; 
product_id – посилання на товар. 
Зв’язки: 
належить одному замовленню; 
пов’язане з одним товаром. 
ProductEvent: 
Фіксує події, пов’язані з товарами (наприклад, створення, редагування, 
зміна ціни). 
Атрибути: 
id, user_id, product_id, event_type, created_at; 
Зв’язки: 
пов’язане з користувачем (AppUser); 
пов’язане з конкретним товаром (Product). 
Візуальні зв’язки між класами: 
AppUser ↔ UserOrder – зв’язки один-до-багатьох (як клієнт, так і 
співробітник); 
Manufacturer ↔ Product – один-до-багатьох; 
UserOrder ↔ OrderItem – один-до-багатьох; 
Product ↔ OrderItem – один-до-багатьох; 
Product ↔ ProductEvent – один-до-багатьох; 
AppUser ↔ ProductEvent – один-до-багатьох. 
Варто зазначити, що діаграма класів допомагає наочно відобразити 
взаємозв’язки та залежності між класами, що полегшує процес розробки 
системи й мінімізує ризик непорозумінь під час роботи. Однак після початку 
реалізації програмного коду структура діаграми може зазнати певних змін. Це 
природна частина розробки, яку повністю уникнути неможливо, але її можна 
мінімізувати завдяки ретельному етапу проектування. 
 
80 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.6 – Діаграма класів та їхній вміст 
 
3.2.3.2 Діаграми пакетів 
Наступним кроком представлено діаграму пакетів на рисунку 3.7. 
Рисунок 3.7 – Діаграма пакетів системи машинного навчання для 
прогнозування вподобань користувачів у системі електронної комерції. 
81 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.7 – Діаграма пакетів 
 
Діаграма включає основні пакети системи, які забезпечують поділ 
функціональності між логічними модулями та визначають взаємозв’язки між 
ними: 
ai-engine-service – пакет, який реалізує модуль машинного навчання. Він 
відповідає за аналіз поведінки користувачів, обробку даних та формування 
рекомендацій на основі моделей штучного інтелекту. Взаємодіє з пакетом ai-
engine-client для обміну даними через API. 
ai-engine-client – пакет, який слугує клієнтом до сервісу машинного 
навчання. Він надсилає дані про дії користувачів і отримує сформовані 
рекомендації, які потім відображаються в інтерфейсі користувача. 
user-service – пакет, який відповідає за управління користувачами, 
включаючи реєстрацію, автентифікацію, авторизацію та зберігання інформації 
82 
ЧДТУ 252485.010 ПЗ 
про профілі користувачів. Він взаємодіє із web-ui для отримання даних від 
користувачів та із shop-service для формування персоналізованих рекомендацій. 
shop-service – пакет, який реалізує основну логіку інтернет-магазину, 
включаючи управління товарами, замовленнями та виробниками. Взаємодіє з 
user-service для ідентифікації клієнтів і з ai-engine-service для відображення 
інтелектуальних рекомендацій. 
notification-service – пакет, який забезпечує надсилання сповіщень 
користувачам про статуси замовлень, нові рекомендації чи знижки. Працює у 
взаємодії з user-service та shop-service. 
web-ui – пакет, який реалізує інтерфейс користувача. Він об’єднує роботу 
всіх інших пакетів, надаючи користувачеві змогу взаємодіяти з системою через 
вебінтерфейс. 
common-events – пакет, що містить спільні об’єкти подій і структури 
даних, які використовуються для обміну інформацією між сервісами.). 
3.2.4 Архітектурне проектування 
Архітектурне проєктування відіграє ключову роль у створенні систем 
машинного навчання для прогнозування вподобань користувачів у системах 
електронної комерції, оскільки саме на цьому етапі визначається структура, 
взаємозв’язки компонентів та принципи функціонування всієї системи. Від 
якості архітектури залежить ефективність обробки великих обсягів даних, 
точність прогнозів та зручність взаємодії користувача із системою. 
Процес архітектурного проєктування передбачає глибоке розуміння 
предметної області – електронної комерції – та застосування технічних підходів 
у сфері штучного інтелекту. Основна мета полягає у створенні гнучкої та 
масштабованої системи, здатної адаптуватися до змін користувацьких 
уподобань і поведінкових моделей. 
Архітектура системи включає кілька ключових компонентів: модуль 
збору даних (отримує інформацію про дії користувачів – перегляди, покупки, 
оцінки); модуль попередньої обробки даних (очищення, нормалізація, 
83 
ЧДТУ 252485.010 ПЗ 
фільтрація); модуль навчання моделей машинного навчання (реалізує 
алгоритми класифікації, кластеризації чи рекомендацій); модуль прогнозування 
(видає персоналізовані рекомендації) та модуль взаємодії з користувачем 
(інтерфейс або API). 
Важливим аспектом є визначення механізмів взаємодії між цими 
модулями, зокрема способів передачі даних, синхронізації процесів і керування 
потоками запитів. Особлива увага приділяється безпеці та конфіденційності 
даних користувачів: система повинна реалізовувати автентифікацію, 
авторизацію, шифрування та захист персональної інформації. 
Крім того, архітектура повинна враховувати можливість інтеграції з 
іншими сервісами електронної комерції – наприклад, платіжними системами, 
CRM або аналітичними платформами. 
Ще одним важливим елементом архітектурного проєктування є 
забезпечення масштабованості та високої продуктивності. Система має 
стабільно працювати навіть при збільшенні кількості користувачів і обсягів 
даних, зберігаючи швидкість обробки запитів і точність прогнозів. 
Таким чином, архітектурне проєктування у контексті даної теми формує 
основу для побудови надійної, безпечної та інтелектуальної системи, здатної 
ефективно прогнозувати вподобання користувачів і підвищувати якість їхньої 
взаємодії з платформою електронної комерції. 
3.2.4.1 Діаграма компонентів 
Діаграма компонентів відображає фізичну архітектуру системи AI-Shop, 
демонструючи взаємозв’язки між основними складовими компонентами, що 
реалізують різні частини функціональності системи (рис. 3.8).  
До складу системи входять такі основні компоненти: 
Web-UI – компонент, який відповідає за взаємодію користувача з 
системою через інтерфейс. Він отримує дані від користувача, надсилає запити 
до бекенд-сервісів та відображає результати. 
User-Service – компонент, що реалізує логіку керування користувачами: 
реєстрацію, автентифікацію, авторизацію, а також управління профілями 
84 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.8 – Діаграма компонентів 
 
користувачів. 
Shop-Service – компонент, який забезпечує бізнес-логіку магазину: 
управління товарами, категоріями, замовленнями та їх обробку. 
Notification-Service – компонент, який відповідає за сповіщення 
користувачів через різні канали (електронна пошта, повідомлення тощо). 
AI-Engine-Service – компонент, який реалізує модуль штучного інтелекту 
для рекомендацій користувачам, прогнозування попиту чи аналізу поведінки. 
Common-Events – спільний компонент, який містить події та моделі, що  
використовуються для обміну даними між усіма сервісами через механізм подій 
або повідомлень. 
85 
ЧДТУ 252485.010 ПЗ 
AI-Engine-Client – клієнтський компонент, який забезпечує взаємодію між 
сервісами системи та модулем AI-Engine. 
Database – компонент, що відповідає за зберігання даних користувачів, 
товарів, замовлень і результатів роботи системи. 
Компоненти Web-UI, User-Service, Shop-Service, Notification-Service та 
AI-Engine-Service взаємодіють між собою через REST API та події, реалізовані 
у Common-Events. 
Web-UI використовує інтерфейси, надані іншими сервісами, а AI-Engine-
Client виступає посередником між бізнес-логікою магазину та аналітичним 
ядром AI. 
Таким чином, діаграма компонентів відображає логічну взаємодію 
модулів системи, допомагаючи забезпечити розподіленість, гнучкість і 
масштабованість архітектури. 
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Діаграма розгортання системи персоналізованих рекомендацій подана на 
рисунку 3.9 та відображає фізичну архітектуру програмного забезпечення, 
демонструючи взаємозв'язок між компонентами системи та апаратними 
вузлами. Вона забезпечує ясність у питанні того, як програмна система працює 
у реальному середовищі. 
 
Рисунок 3.9 –Діаграма розгортання 
86 
ЧДТУ 252485.010 ПЗ 
У моєму випадку розгортання передбачає використання трьох основних 
серверів: веб-сервер для обробки запитів користувачів, сервер рекомендаційних 
алгоритмів та сервер машинного навчання для векторної обробки даних. Базу 
векторних даних спочатку розміщено на тому ж сервері, що й сервер 
машинного навчання, для економії ресурсів та спрощення початкової 
архітектури системи. Ресурсів сервера машинного навчання повинно вистачити 
для обробки векторних запитів на етапі запуску системи. Однак, в архітектурі 
модульної системи закладено можливість перенесення векторної бази даних на 
окремий сервер у разі зростання навантаження. 
Взаємодія між серверами відбувається через протокол HTTP/HTTPS, що 
забезпечує надійний і безпечний обмін даними. Така архітектура сприяє 
модульності, розподіленості обчислень і простоті масштабування системи, що є 
ключовими аспектами для забезпечення її продуктивності та адаптивності до 
навантажень. 
Розгортання системи на трьох окремих серверах дозволяє досягти 
розподілу функцій між різними вузлами, забезпечуючи оптимальну 
продуктивність кожного компонента. Веб-сервер дозволяє ефективно 
обробляти запити користувачів веб-магазину електроприладів, сервер 
рекомендаційних алгоритмів аналізує поведінку та генериє персоналізовані 
пропозиції, а сервер машинного навчання забезпечує векторну обробку даних 
про продукти та користувачів для точного підбору рекомендацій. 
Використання HTTP/HTTPS-з'єднань між серверами забезпечує безпеку 
та зручність передачі даних у розподіленій системі. Такий підхід гарантує, що 
система є масштабованою, стійкою до можливих збоїв і готовою до інтеграції з 
додатковими компонентами у майбутньому. Діаграма розгортання, таким 
чином, служить ефективним інструментом для планування та управління 
фізичною інфраструктурою системи персоналізованих рекомендацій у веб-
магазині електроприладів. 
3.2.5 Моделювання поведінки системи 
87 
ЧДТУ 252485.010 ПЗ 
Моделювання поведінки системи – це процес побудови узагальнених 
моделей, які описують, як система функціонує, реагує на зовнішні події та 
взаємодіє з іншими компонентами чи користувачами. Під час такого 
моделювання аналізується, яким чином система обробляє події, змінює свій 
стан, а також як відбувається її комунікація з зовнішнім середовищем і 
внутрішніми модулями. 
3.2.5.1 Діаграма діяльності 
Діаграма діяльності – це тип діаграми в уніфікованій мові моделювання 
UML, що відображає послідовність дій, процесів або операцій, які виконуються 
в межах системи. Вона дозволяє описати логіку роботи системи та взаємодію 
між її складовими елементами під час виконання бізнес-процесів. 
На поданій діаграмі діяльності зображено основні етапи взаємодії клієнта 
з інтернет-магазином. Модель демонструє повний процес – від моменту 
звернення користувача до системи до надання послуги після оформлення та 
оплати замовлення. 
Зокрема, у діаграмі можна виділити дві основні гілки виконання: 
Для постійного клієнта – система здійснює пошук даних користувача в 
базі та переходить до оформлення замовлення. 
Для нового клієнта – спочатку надається інформація про компанію. Якщо 
умови прийнятні, клієнт проходить реєстрацію, після чого оформлює 
замовлення. 
Після оформлення замовлення відбувається етап оплати, а завершальним 
кроком є надання послуги клієнту. 
Таким чином, діаграма діяльності дозволяє наочно відобразити бізнес-
логіку роботи інтернет-магазину, визначити основні етапи взаємодії 
користувача із системою та забезпечити розуміння послідовності операцій, 
необхідних для успішного виконання замовлення (рис. 3.10). 
 
88 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.10 – Діаграма діяльності 
 
3.2.5.2 Діаграма послідовності 
Діаграма послідовності в рамках мови моделювання UML – це вид 
діаграми, яка відображає взаємодію між об'єктами чи компонентами системи в 
конкретному часовому порядку. Ця діаграма показує послідовність 
повідомлень, які передаються між об'єктами та порядок їх виконання. 
Діаграма послідовності (рис. 3.11) використовується для моделювання та 
візуалізації того, як об'єкти спілкуються у певній послідовності в рамках 
виконання певної функції чи процесу. Це дозволяє аналізувати та оптимізувати 
взаємодію системних компонентів. 
89 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.11 –Діаграма послідовності  
 
3.2.5.3 Діаграма комунікації 
Діаграма комунікації використовується для опису взаємодії між 
об’єктами програмної системи з акцентом на структуру зв’язків та обмін 
повідомленнями між компонентами. На відміну від діаграми послідовності, яка 
фокусується на часовому порядку викликів, діаграма комунікації відображає 
логіку обміну повідомленнями між основними підсистемами рекомендаційної 
платформи та дозволяє проаналізувати розподіл відповідальностей між ними. 
У розробленій системі персоналізованих рекомендацій діаграма 
комунікації ілюструє процес формування рекомендацій для користувача під час 
його взаємодії з веб-платформою електронної комерції. Основними учасниками 
90 
ЧДТУ 252485.010 ПЗ 
комунікації є користувач, клієнтський веб-інтерфейс, серверна частина 
системи, модуль рекомендацій, база даних та модуль машинного навчання. 
Процес комунікації ініціюється користувачем, який через веб-інтерфейс 
надсилає запит на перегляд персоналізованих рекомендацій. Клієнтський 
інтерфейс формує HTTP-запит і передає його на серверну частину системи. 
Сервер виконує первинну обробку запиту, перевіряє автентифікацію 
користувача та визначає необхідність формування рекомендацій. 
Далі сервер взаємодіє з модулем рекомендацій, передаючи йому 
ідентифікатор користувача та контекстні параметри сесії. Модуль 
рекомендацій, у свою чергу, звертається до бази даних для отримання історії 
взаємодій користувача з товарами (перегляди, додавання до кошика, покупки). 
Отримані дані передаються до модуля машинного навчання, який реалізує 
алгоритм Bayesian Personalized Ranking (BPR). 
Модуль машинного навчання виконує обчислення релевантності товарів, 
формує впорядкований список рекомендацій та повертає результати до модуля 
рекомендацій. Після цього серверна частина системи надсилає сформований 
список рекомендованих товарів клієнтському інтерфейсу, де вони 
відображаються користувачеві у зручному та зрозумілому вигляді. 
Діаграма комунікації також відображає зворотний зв’язок системи: дії 
користувача (кліки, перегляди, покупки) фіксуються клієнтською частиною та 
передаються на сервер для збереження у базі даних. Ці дані в подальшому 
використовуються для оновлення та перенавчання рекомендаційної моделі, що 
забезпечує адаптивність системи до змін у поведінці користувачів. 
Таким чином, діаграма комунікації наочно демонструє узгоджену 
взаємодію між усіма ключовими компонентами програмного комплексу, 
підтверджує правильність архітектурних рішень та забезпечує розуміння 
механізму формування персоналізованих рекомендацій у системі електронної 
комерції. Її використання дозволяє спростити аналіз системи, підвищити якість 
проектування та полегшити подальший супровід і масштабування програмного 
забезпечення. 
91 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.12 – Діаграма комунікації 
 
Основні учасники: 
− користувач - кінцевий користувач веб-магазину електроприладів; 
− веб-інтерфейс - клієнтська частина (браузер або мобільний додаток); 
− серверна система - головний сервер, що координує всі процеси; 
92 
ЧДТУ 252485.010 ПЗ 
− модуль рекомендацій - спеціалізований компонент для формування 
пропозицій; 
− база даних - сховище даних користувачів та їх взаємодій; 
− модуль машинного навчання - компонент, що реалізує алгоритм BPR. 
Ключові повідомлення та процеси: 
− ініціалізація запиту; 
− формування рекомендацій; 
− відображення результатів; 
− зворотний зв'язок; 
− оновлення моделі. 
Архітектурні особливості: 
− чітка розподілена відповідальність між компонентами; 
− використання BPR алгоритму для точних рекомендацій; 
− постійне оновлення моделі на основі нових даних; 
− відокремлення логіки ML від бізнес-логіки; 
− масштабована архітектура з можливістю розподілу компонентів. 
3.2.5.4 Діаграма скінченного автомату 
Діаграма скінченного автомату (або діаграма станів) – це графічне 
відображення логіки зміни станів системи залежно від дій користувача або 
внутрішніх подій. Для інтернет-магазину така діаграма моделює поведінку 
системи під час взаємодії клієнта з процесом оформлення замовлення – від 
моменту входу до сайту до завершення покупки. 
На представленій діаграмі станів показано основні етапи життєвого циклу 
замовлення. Система переходить між станами залежно від дій користувача 
(додавання товарів у кошик, підтвердження, оплата тощо) або внутрішніх подій 
(підтвердження оплати, доставка замовлення). 
93 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 3.13 – Діаграма скінченного автомату 
 
Таким чином, діаграма скінченного автомату дозволяє візуалізувати 
послідовність змін станів замовлення та зрозуміти логіку переходів у процесі 
взаємодії користувача з інтернет-магазином (рис. 3.13). 
  
94 
ЧДТУ 252485.010 ПЗ 
Висновки до розділу 3 
У даному розділі було проведено аналіз архітектури та функціональних 
компонентів системи інтернет-магазину, що реалізує сервіс взаємодії між 
користувачами, товарами та замовленнями. Побудовано UML-діаграми, які 
відображають основні аспекти роботи системи – від структури класів та 
взаємодії пакетів до бізнес-процесів і станів об’єктів. 
Зокрема, діаграма прецедентів показала основні сценарії взаємодії 
користувача з системою; діаграма класів описала логічні зв’язки між 
сутностями; діаграма пакетів окреслила модульну структуру проєкту, що 
забезпечує масштабованість та розширюваність; діаграма діяльності 
відобразила послідовність дій користувача під час оформлення замовлення; а 
діаграма станів – основні переходи системи від перегляду товарів до 
завершення покупки. 
Отримані результати свідчать про узгодженість логіки системи, її 
структурну цілісність та можливість подальшої інтеграції з зовнішніми 
сервісами. Такий підхід дозволяє оптимізувати процес розробки, полегшити 
тестування та підвищити ефективність подальшої реалізації програмного 
забезпечення.. 
 
95 
ЧДТУ 252485.010 ПЗ 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
У цьому розділі представлено процес розробки та перевірки 
працездатності програмного забезпечення рекомендаційної системи. Основна 
увага зосереджена на практичній реалізації функціональних можливостей, що 
були сформовані на етапі аналізу вимог та проєктування. Розробка системи 
здійснювалася з урахуванням принципів сучасної інженерії програмного 
забезпечення, включаючи використання гнучких методологій управління 
проєктами, хмарних технологій та сервісноорієнтованої архітектури. 
У межах розділу послідовно описано вибір інструментів і технологій, 
процес створення архітектури, основні етапи імплементації та механізми 
взаємодії між компонентами системи. Значну увагу приділено застосуванню 
веб-сервісів та схемі обміну даними, що забезпечують масштабованість, 
модульність та розширюваність розробленого рішення. 
Окремою частиною розділу є опис побудови БД та реалізації моделі 
зберігання даних, яка забезпечує ефективне опрацювання інформації, пов'язаної 
з користувачами, товарами та рекомендаціями. 
Завершальна частина присвячена тестуванню системи: виконано 
модульне, інтеграційне та системне тестування, що дозволило перевірити 
коректність логіки, стабільність роботи та відповідність програмного 
забезпечення вимогам. Результати тестування підтвердили працездатність та 
надійність створеної рекомендаційної системи. 
4.1. Розробка програмного комплексу 
У цьому підрозділі подано опис вибору технологій, інструментів та 
архітектурних рішень, що були застосовані під час розробки рекомендаційної 
системи. Розробка програмного забезпечення здійснювалася відповідно до 
принципів гнучких методологій (Agile), із використанням хмарних технологій, 
веб-сервісів та сучасних інструментів серверної і клієнтської розробки. Під час 
96 
ЧДТУ 252485.010 ПЗ 
створення системи враховано вимоги до продуктивності, масштабованості, 
зручності підтримки та розширення функціональності. 
Процес розробки включав такі основні етапи: формування архітектури, 
вибір середовища реалізації, побудова БД, проєктування інтерфейсу 
користувача, реалізація програмних модулів та проведення тестування. Усі 
етапи виконано з урахуванням необхідності швидкого внесення змін, 
можливості ітеративного вдосконалення та використання хмарних сервісів для 
підвищення доступності та надійності системи. 
4.1.1 Обґрунтування вибору засобів реалізації 
Завершальна Вибір інструментів та програмних платформ здійснювався 
на основі вимог до рекомендаційної системи, зокрема: висока продуктивність, 
можливість обробки великої кількості даних, зручність розробки, легка 
інтеграція з веб-сервісами та доступність сучасних інструментів машинного 
навчання. 
Вибір мови програмування та середовища розробки 
Основною мовою програмування було обрано Java, що обумовлено 
такими факторами: 
− стабільність та надійність екосистеми; 
− наявність численних бібліотек для побудови веб-сервісів, роботи з 
даними та реалізації алгоритмів рекомендацій; 
− підтримка багатопотоковості та високий рівень продуктивності; 
− кросплатформеність та можливість масштабування. 
Як середовище розробки використано IntelliJ IDEA, яке забезпечує: 
− широкий набір інструментів для роботи з Java-проєктами; 
− інтеграцію з системами контролю версій; 
− зручні можливості налагодження (debugging); 
− автоматизацію збірки за допомогою Maven або Gradle. 
Вибір фреймворків та інструментів серверної частини 
Для реалізації бекенд-частини застосовано SB, оскільки він: 
97 
ЧДТУ 252485.010 ПЗ 
− спрощує створення REST-сервісів; 
− підтримує модульну архітектуру; 
− забезпечує високу швидкість розгортання; 
− має інтегровані засоби безпеки, роботи з БД та зовнішніми сервісами. 
Для створення рекомендаційної логіки може бути використаний модуль, 
що підтримує алгоритми контентної або колаборативної фільтрації. 
Вибір системи керування базами даних 
У якості СКБД обрано PostgreSQL, що обґрунтовано такими перевагами: 
− підтримка складних запитів і високої продуктивності; 
− надійність і захищеність; 
− відповідність вимогам ACID; 
− легка інтеграція зі SB через Spring Data JPA; 
− підтримка масштабування та реплікації. 
Для управління міграціями структури бази використано Flyway, що 
дозволяє гарантувати коректність схеми даних на різних середовищах. 
Вибір інструментів зберігання та обробки даних 
Для локального та хмарного розгортання використано Docker, що 
забезпечує: 
− однакове середовище розробки й продакшну; 
− легке масштабування компонентів; 
− ізоляцію сервісів у контейнерах. 
Також було використано хмарні можливості (наприклад, AWS / Google 
Cloud / Azure), що забезпечують: 
− стабільний доступ до сервісу; 
− резервне копіювання даних; 
− можливість масштабування при збільшенні навантаження. 
Вибір технологій інтерфейсу користувача 
Для побудови веб-інтерфейсу застосовано: 
− HTML5, CSS3, JavaScript – стандартні технології веб-розробки; 
98 
ЧДТУ 252485.010 ПЗ 
− Thymeleaf для створення інтерактивного інтерфейсу; 
− REST API для взаємодії клієнтської частини з сервером. 
Такий вибір забезпечує: 
− високу швидкість роботи UI; 
− адаптивність під різні пристрої; 
− зручність підтримки та модернізації. 
Вибір апаратних засобів 
Для роботи системи не потрібні потужні локальні ресурси, оскільки 
серверна логіка та обробка даних виконуються у хмарі. Мінімальні вимоги: 
− процесор: Intel Core i5 / Ryzen 5 або еквівалент; 
− ОЗП: 8–16 GB; 
− SSD: від 256 GB; 
− стабільне підключення до мережі. 
При розгортанні в хмарі використовуються віртуальні машини з 
автоматичним масштабуванням. 
4.1.2 Опис структурної (функціональної) схеми 
Структурна (функціональна) схема демонструє загальну організацію 
системи та взаємодію її основних модулів. Розроблена система електронної 
комерції складається з декількох логічно об’єднаних підсистем, кожна з яких 
виконує окрему групу функцій, але при цьому забезпечує узгоджену роботу 
всієї платформи. 
На найвищому рівні система включає модулі керування користувачами, 
каталогом товарів, замовленнями, рекомендаційним механізмом та 
адміністративною частиною. Після входу або реєстрації користувач взаємодіє з 
інтерфейсом, який надає доступ до головної сторінки, перегляду товарів, 
сортування, фільтрації, перегляду рекомендацій та керування кошиком. Модуль 
оформлення замовлення забезпечує створення, перегляд статусів та можливість 
відміни замовлення користувачем. 
99 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 4.1 – Структурна схема 
 
Підсистема рекомендацій отримує дані про взаємодію користувачів із 
товарами, аналізує їх за допомогою алгоритмів машинного навчання та формує 
індивідуальні пропозиції. Усі дані – профілі користувачів, історія замовлень, 
товари, виробники та характеристики – зберігаються у базі даних, з якою 
взаємодіє серверна частина через відповідні сервіси. Адміністративний модуль 
дозволяє керувати товарами, працівниками, виробниками та виконувати 
необхідні операції з каталогом, що забезпечує підтримку актуальності усієї 
системи. 
Сукупність цих компонентів формує цілісну структуру, що дозволяє 
забезпечити повний цикл роботи магазину – від перегляду товарів і покупки до 
формування рекомендацій та адміністрування контенту. 
100 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 4.2 – Функціональна схема 
 
Схема демонструє послідовність функціональних процесів, що 
забезпечують роботу системи персоналізованих рекомендацій: 
Вхід та авторизація: 
− користувач заходить на веб-магазин; 
− система авторизації ідентифікує користувача; 
− доступ до особистого кабінету та історії покупок. 
Первинне відображення рекомендацій: 
− після входу система автоматично відображає головну сторінку; 
− на головній сторінці показуються персоналізовані рекомендації; 
− залучаються підсистеми метаданих продуктів, аналізу поведінки та 
бази даних. 
Взаємодія користувача: 
− користувач здійснює пошук та перегляд продуктів; 
− дії користувача фіксуються та аналізуються; 
101 
ЧДТУ 252485.010 ПЗ 
− система веб-магазину передає дані про взаємодію до системи 
рекомендацій. 
Генерація персоналізованих рекомендацій: 
− система аналізує поведінку користувача; 
− застосовуються рекомендаційні алгоритми; 
− використовується машинне навчання для прогнозування; 
− дані векторизуються для порівняння; 
− аналізується схожість між продуктами; 
− використовується база знань про продукти. 
Відображення результатів: 
− система генерує персоналізовані пропозиції; 
− рекомендації відображаються користувачеві; 
− використовується аналіз схожості для точного підбору; 
− залучається база знань про продукти для якісних рекомендацій. 
Особливості системи: 
− інтеграція з веб-магазином електроприладів; 
− динамічна адаптація до поведінки користувача; 
− використання машинного навчання для точних прогнозів; 
− багаторівневий аналіз даних; 
− персоналізація на основі історії взаємодій; 
− постійне оновлення рекомендацій у реальному часі. 
4.1.3 Опис логічної схеми системи 
Логічна схема системи відображає інформаційні зв’язки між основними 
сутностями, що забезпечують роботу електронної комерції. Вона визначає, які 
102 
ЧДТУ 252485.010 ПЗ 
дані зберігаються, як організовані взаємозв’язки між таблицями БД та як 
система оперує інформацією. 
У логічній моделі однією з ключових сутностей є користувач, який має 
облікові дані, історію замовлень та поведінкові характеристики, що 
використовуються для рекомендацій. Сутність товар містить інформацію про 
назву, опис, характеристики, ціну, виробника та категорію. Один виробник 
може випускати багато товарів, тому пов’язаний з ними через відношення 
«один до багатьох». Користувач формує замовлення, яке складається з одного 
чи кількох товарів, що відображається у зв’язку через проміжну таблицю. 
Замовлення має статус, дату створення і може бути змінене або скасоване 
користувачем. 
Окреме місце в логічній схемі займає підсистема рекомендацій. Вона 
використовує дані про дії користувача – перегляди, додавання до кошика, 
покупки – формуючи на їх основі модель вподобань. Ця інформація може 
зберігатися окремими таблицями подій або агрегованими значеннями, які 
слугують вхідними даними для алгоритму машинного навчання. 
Для адміністративної частини передбачені сутності працівників, 
довідники виробників та категорій, що забезпечують підтримку і контроль 
змісту каталогу товарів. Логічна схема описує, як пов’язані всі ці елементи, і 
забезпечує структурованість та узгодженість інформації, необхідної для 
стабільної роботи системи та рекомендаційного механізму. 
4.1.4 Розробка бази даних 
Відповідно до вимог до функціоналу системи, була розроблена реляційна 
база даних. Реляційна модель була обрана через її переваги, такі як простота, 
гнучкість, зрозумілість та зручність реалізації. 
Процес проектування БД включав наступні етапи: 
Концептуальне моделювання: Було вивчено предметну область – систему 
управління складом та замовленнями. В результаті були визначені ключові 
сутності та їхні бізнес-взаємозв'язки. 
103 
ЧДТУ 252485.010 ПЗ 
Логічне моделювання: Вимоги до системи були формалізовані у вигляді 
логічної моделі даних, де були чітко визначені сутності, їхні атрибути та зв'язки 
між ними. 
Фізичне моделювання: Логічна модель була трансформована у фізичну 
схему БД, що включає таблиці, стовпці, типи даних, обмеження первинних та 
зовнішніх ключів. 
На рисунку 4.3 наведена схема БД та її зв’язки. 
 
 
Рисунок 4.3 – Схема БД 
 
Фізична модель даних реалізована у вигляді наступних таблиць: 
app_user (Користувачі системи) 
id (bigint) – первинний ключ. 
username (varchar(100)) – ім'я користувача. 
104 
ЧДТУ 252485.010 ПЗ 
email (varchar(100)) – електронна пошта. 
password (varchar(100)) – хеш пароля. 
role (varchar(100)) – роль користувача в системі (наприклад, клієнт, 
співробітник, адміністратор). 
is_email_verify (boolean) – прапорець підтвердження електронної пошти. 
client_id_id (bigint) – зовнішній ключ, що посилається на сутність клієнта 
(може бути NULL для користувачів, які не є клієнтами). 
employee_id_id (bigint) – зовнішній ключ, що посилається на сутність 
співробітника (може бути NULL для користувачів, які не є співробітниками). 
manufacturers (Виробники) 
id (bigint) – первинний ключ. 
name (varchar(255)) – назва виробника. 
manufacturer_id_id (bigint) – зовнішній ключ для реалізації ієрархії або 
зв'язку (потребує уточнення в контексті бізнес-логіки). 
products (Товари/Продукти) 
id (bigint) – первинний ключ. 
name (varchar(255)) – назва продукту. 
product_category (varchar(50)) – категорія продукту. 
product_type (varchar(50)) – тип продукту. 
model (varchar(255)) – модель продукту. 
manufacturer_id (bigint) – зовнішній ключ на таблицю manufacturers. 
characteristic (varchar(255)) – характеристики продукту. 
description (varchar(255)) – опис продукту. 
price (numeric(15,2)) – ціна продукту. 
product_id_id (bigint) – зовнішній ключ для реалізації зв'язку між 
продуктами (наприклад, для комплектацій або варіацій). 
orders (Замовлення) 
id (bigint) – первинний ключ. 
employee_id (bigint) – зовнішній ключ на таблицю app_user (ідентифікатор 
співробітника, який обробляє замовлення). 
105 
ЧДТУ 252485.010 ПЗ 
client_id (bigint) – зовнішній ключ на таблицю app_user (ідентифікатор 
клієнта, який зробив замовлення). 
approved (boolean) – статус підтвердження замовлення. 
order_id_id (bigint) – зовнішній ключ для реалізації ієрархії замовлень 
(наприклад, родинські замовлення). 
order_items (Позиції замовлення) 
id (bigint) – первинний ключ. 
order_id (bigint) – зовнішній ключ на таблицю orders. 
product_id (bigint) – зовнішній ключ на таблицю products. 
price (numeric(15,2)) – ціна на момент додавання до замовлення. 
quantity (integer) – кількість одиниць товару. 
product_events (Події з товарами) 
id (bigint) – первинний ключ. 
user_id (bigint) – зовнішній ключ на таблицю app_user (користувач, який 
ініціював подію). 
product_id (bigint) – зовнішній ключ на таблицю products. 
event_type (varchar(20)) – тип події (наприклад, 'перегляд', 'додавання в 
кошик', 'покупка'). 
created_at (timestamp) – мітка часу, коли подія сталася. 
Опис зв'язків 
Таблиці orders та order_items пов'язані відношенням «один-до-багатьох»: 
одне замовлення може містити кілька позицій. 
Таблиці products та order_items пов'язані відношенням «один-до-
багатьох»: один продукт може фігурувати в різних позиціях різних замовлень. 
Таблиці app_user (як клієнт) та orders пов'язані відношенням «один-до-
багатьох»: один клієнт може мати багато замовлень. 
Таблиці app_user (як співробітник) та orders пов'язані відношенням 
«один-до-багатьох»: один співробітник може обробляти багато замовлень. 
Таблиці manufacturers та products пов'язані відношенням «один-до-
багатьох»: один виробник може випускати багато продуктів. 
106 
ЧДТУ 252485.010 ПЗ 
Таблиця product_events фіксує дії користувачів (app_user) над продуктами 
(products), реалізуючи відношення «багато-до-багатьох» між цими сутностями 
через таблицю-зв'язок. 
Така структура БД забезпечує цілісність даних, мінімізує надмірність і 
ефективно підтримує бізнес-логіку системи управління складом та 
замовленнями. 
4.1.5 Розробка інтерфейсу користувача 
Розробка інтерфейсу користувача є однією з ключових стадій 
конструювання інформаційної системи, оскільки саме через інтерфейс 
здійснюється взаємодія між користувачем та програмно-технічним комплексом. 
Під час створення інтерфейсу для системи електронної комерції особлива увага 
приділялася доступності, зрозумілості та зручності виконання основних 
операцій, пов’язаних з переглядом товарів, формуванням рекомендацій, 
роботою з кошиком та оформленням замовлень. Ефективність інтерфейсу 
визначалась здатністю передбачити потреби користувача на всіх етапах 
взаємодії – від першого входу на сайт до повторних покупок і перегляду 
персональних рекомендацій. 
Проєктування інтерфейсу здійснювалось із урахуванням принципів, 
сформульованих відомим спеціалістом у сфері usability Якобом Нільсеном. 
Зокрема, увага приділялася забезпеченню видимості стану системи, коли 
користувач на кожному кроці отримує зрозумілий зворотний зв’язок щодо 
виконання своїх дій, таких як додавання товару до кошика або підтвердження 
замовлення. Важливим фактором була відповідність інтерфейсу очікуванням 
користувача, що дозволило створити знайому й передбачувану структуру 
головної сторінки, каталогу, кошика та особистого кабінету. Значну роль 
відіграло зниження когнітивного навантаження, завдяки чому користувач може 
виконувати дії без необхідності запам’ятовувати складні шляхи переходів або 
додаткові параметри. 
107 
ЧДТУ 252485.010 ПЗ 
Під час розробки також враховувалася гнучкість та можливість 
виникнення помилок. Інтерфейс передбачає чіткі повідомлення про обмеження 
або некоректні дії, а також надає можливість легко повернутися до 
попереднього кроку без втрати даних. У процесі проєктування було 
забезпечено логічну узгодженість елементів, єдину візуальну стилістику та 
коректне відображення структурних елементів на різних пристроях, що є 
критично важливим для сучасних електронних комерційних систем. 
Окрему увагу було приділено розширюваності інтерфейсу. Оскільки 
система містить модуль рекомендацій, побудований на методах машинного 
навчання, було важливо передбачити можливість подальшого розвитку 
функціональності без змін базової архітектури. Це забезпечило здатність 
інтерфейсу підтримувати нові типи рекомендацій, додаткові фільтри, панелі 
адміністратора та інші елементи, які можуть бути впроваджені під час 
масштабування системи. Таким чином, створений інтерфейс не лише відповідає 
актуальним вимогам користувачів, але й дозволяє адаптуватися до майбутніх 
змін без необхідності суттєвого доопрацювання. 
4.1.6 Опис розробки програмних компонентів 
Розробка програмних компонентів системи персоналізованих 
рекомендацій охоплює створення взаємопов’язаних модулів, кожен з яких 
виконує визначену функцію в межах загальної архітектури. В основу реалізації 
покладено принципи модульності, розширюваності та незалежності 
компонентів, що забезпечує простоту супроводження та можливість 
масштабування системи в майбутньому. 
Ключовим елементом є модуль обробки даних, який відповідає за 
завантаження, очищення та перетворення інформації про взаємодії 
користувачів із товарами. Він формує структуровані дані для подальшого 
навчання моделі, забезпечуючи коректність і узгодженість записів. Паралельно 
функціонує модуль управління контентними ознаками, який опрацьовує 
108 
ЧДТУ 252485.010 ПЗ 
властивості товарів: категорії, технічні параметри, характеристики та інші 
атрибути, що використовуються під час побудови профілів. 
Центральним компонентом є рекомендаційний модуль, що реалізує 
колаборативно-гібридний алгоритм. Він поєднує матричну факторизацію, 
аналіз історії користувачів і контентні особливості товарів. Цей модуль виконує 
навчання моделі, формує векторні подання користувачів і товарів та генерує 
ранжовані списки рекомендацій. Його робота передбачає використання 
оптимізатора, функцій втрат і механізмів регуляризації, що дозволяє зберігати 
точність навіть за високої розрідженості даних. 
Окремою частиною системи є модуль бізнес-логіки, який керує процесом 
взаємодії між користувачем, моделлю та базою даних. Він отримує запит, 
визначає контекст, передає необхідні дані в рекомендаційний модуль і формує 
кінцевий результат для відображення на стороні веб-застосунку. Саме цей 
компонент забезпечує узгодженість роботи сервісу та його інтеграцію з іншими 
частинами програмної інфраструктури магазину. 
Не менш важливим є модуль збереження та оновлення моделей, що 
відповідає за керування станом моделі та повторне навчання на нових даних. 
Він дозволяє системі адаптуватися до змін у поведінці користувачів, 
оновлюючи параметри моделі без потреби у повному перенавчанні. 
Фронтенд-компоненти забезпечують доступ користувача до 
рекомендацій. Веб-інтерфейс відображає персоналізовані списки товарів, 
отримані від серверної частини, і реагує на взаємодію користувача, генеруючи 
нові запити або передаючи додаткові дані для покращення якості рекомендацій. 
Сукупність усіх модулів формує цілісну програмну систему, у якій кожен 
компонент виконує власну роль, але водночас тісно взаємодіє з іншими. Така 
структура забезпечує стабільність роботи, гнучкість конфігурації та можливість 
подальшого розвитку системи без суттєвого втручання у вже реалізовані 
механізми. 
109 
ЧДТУ 252485.010 ПЗ 
4.2 Тестування системи 
Тестування розробленої системи передбачало перевірку коректності 
роботи механізмів моделювання, обробки даних та прогнозування вподобань 
користувачів у середовищі електронної комерції. Метою тестування було 
підтвердження відповідності програмного забезпечення функціональним 
вимогам, стабільності його роботи, а також точності застосованих моделей 
машинного навчання. 
4.2.1 Модульне тестування 
Модульне тестування є початковим рівнем тестування програмного 
забезпечення та передбачає перевірку коректності роботи окремих компонентів 
системи. Оскільки розроблена система прогнозування вподобань користувачів 
у сфері електронної комерції складається з окремих логічних модулів (модуль 
збору даних, модуль попередньої обробки, модуль побудови моделі машинного 
навчання, модуль рекомендацій та модуль API), модульне тестування 
проводилося для забезпечення їх правильної роботи незалежно від інших 
частин системи. 
Під час модульного тестування були перевірені внутрішні структури, 
алгоритмічні блоки та обробка даних у кожному модулі. Основна увага 
приділялася перевірці таких аспектів: 
− коректність завантаження та читання даних із джерел, включно з 
перевіркою форматів, наявності пропусків та некоректних значень; 
− правильність роботи модулів попередньої обробки, зокрема 
нормалізації числових характеристик та кодування категоріальних 
ознак; 
− стабільність формування навчальних і тестових вибірок, включно з 
перевіркою розмірів вибірок, балансу класів та відсутності 
дублювань; 
− коректність роботи основних алгоритмів машинного навчання,  
110 
ЧДТУ 252485.010 ПЗ 
зокрема здатність моделі тренуватися без помилок та повертати 
числове значення прогнозу; 
− перевірка модулю формування рекомендацій, який здійснює 
ранжування товарів відповідно до отриманого прогнозу; 
− перевірка REST API, що забезпечує взаємодію з кінцевими 
користувачами або зовнішніми сервісами. 
Модульне тестування проводилося на етапі розробки програмного 
забезпечення безпосередньо розробником. Для перевірки коректності 
виконання окремих функцій використовувалися інструменти середовища 
розробки, логування та тестові сценарії з контрольними вхідними даними. 
У ході тестування було виявлено та усунено помилки, пов’язані з 
некоректною інтерпретацією відсутніх значень, неповним опрацюванням 
категоріальних даних та окремими змінами форматів під час передачі даних 
між модулями. Після внесення виправлень усі модулі продемонстрували 
стабільну та передбачувану роботу, що дозволило перейти до наступного етапу 
– інтеграційного тестування. 
 
Таблиця 4.1 
Результати модульного тестування 
Модуль Тестована Очікуваний Результат тесту 
функція результат 
authController.js Логін Користувач Успішно 
користувача успішно 
авторизується 
authController.js Реєстрація Новий Успішно 
користувача користувач 
створений 
 
111 
ЧДТУ 252485.010 ПЗ 
Продовження табл. 4.1 
messagesController.j Надсилання Повідомлення Успішно 
s повідомлення збережено у базі 
uploadsController.js Завантаження Файл успішно Успішно 
файлу збережено на 
сервері 
Utils.js Валідація даних Дані валідовані Успішно 
без помилок 
forumController.js Створення теми Тему створено у Успішно 
базі даних 
profileController.js Оновлення Дані профілю Успішно 
профілю оновлено 
користувача 
 
4.2.2 Інтеграційне тестування 
Інтеграційне тестування проводилося після завершення модульного і було 
спрямоване на перевірку узгодженої роботи всіх компонентів системи 
прогнозування вподобань користувачів у сфері електронної комерції. На цьому 
етапі перевірялося, чи правильно взаємодіють між собою модулі, які окремо 
продемонстрували стабільність і коректну роботу. Особлива увага приділялася 
процесу послідовної передачі даних між частинами системи: від отримання та 
попередньої обробки інформації до етапу навчання моделі та формування 
рекомендацій. Перевірялося, чи узгоджено функціонують операції очищення та 
нормалізації даних із механізмами машинного навчання, чи коректно модуль 
моделювання передає результати прогнозування до компонента формування 
рекомендацій та чи здатен останній стабільно генерувати персоналізовані 
результати. 
112 
ЧДТУ 252485.010 ПЗ 
Важливим елементом інтеграційного тестування стала перевірка 
взаємодії з базою даних. Тестувалося, чи правильно здійснюється читання 
історичних даних користувачів, збереження нових значень та оновлення 
інформації, необхідної для прогнозування. Було встановлено, що всі операції 
відбуваються без порушень структури даних і відповідають очікуваним 
сценаріям роботи системи. 
Крім того, тестувалася взаємодія між внутрішньою логікою системи та 
зовнішнім інтерфейсом доступу через REST API. Перевірялося, чи коректно 
передаються запити до відповідних сервісів, чи не спотворюються результати 
прогнозів. У процесі інтеграційного тестування були виявлені окремі 
неточності, пов’язані з відмінностями форматів даних між модулями. 
Після внесення відповідних удосконалень система продемонструвала 
стабільну роботу всіх компонентів у комплексі. Це підтвердило коректність 
взаємодії між модулями і дало змогу перейти до наступного етапу тестування – 
системної перевірки всієї розробленої платформи. 
 
Таблиця 4.2 
Результати інтеграційного тестування 
Результат 
Компонент 1 Компонент 2 Очікуваний результат 
тесту 
Фронтенд API Дані передаються Успішно 
коректно 
Фронтенд База даних Дані зберігаються у базі Успішно 
API База даних Запит до бази повертає Успішно 
коректні дані 
API Система Повідомлення успішно Успішно 
повідомлень доставлене 
 
113 
ЧДТУ 252485.010 ПЗ 
4.2.3 Системне тестування 
Системне тестування здійснювалося після завершення інтеграційних 
перевірок і мало на меті підтвердити працездатність розробленої системи 
прогнозування вподобань користувачів як цілісного програмного комплексу. 
На цьому етапі система розглядалася не як сукупність окремих модулів, а як 
завершений програмний продукт, який повинен виконувати всі поставлені 
функції відповідно до специфікацій та вимог, сформульованих на етапах 
проектування. 
Під час системного тестування оцінювалася здатність моделі машинного 
навчання працювати з реальними даними, поданими у різних масштабах і 
структурах. Перевірялося, чи зберігає система стабільність при збільшенні 
обсягів інформації, наскільки коректно відпрацьовуються сценарії з неповними, 
неоднорідними або непередбачуваними даними, а також чи забезпечується 
необхідний рівень точності прогнозувань. Окрему увагу приділено поведінці 
системи у режимі повного робочого циклу, що охоплює приймання даних, їх 
обробку, побудову прогнозу та формування рекомендацій для користувача. 
Особливо важливою складовою системного тестування стала перевірка 
працездатності системи як сервісу, що може бути інтегрований у реальне 
середовище електронної комерції. Було протестовано, наскільки надійно 
функціонує взаємодія між серверною частиною та зовнішніми інтерфейсами 
доступу, чи зберігається цілісність даних після їх передачі, чи коректно 
формуються відповіді API та чи відповідають вони встановленим форматам. 
Також оцінювалася продуктивність – зокрема, час формування прогнозу та 
швидкість отримання рекомендацій у стандартних і пікових умовах 
навантаження. 
У результаті системного тестування було підтверджено, що розроблена 
система виконує основні функції, задекларовані під час проєктування. Система 
стабільно підтримує повний цикл обробки даних, забезпечує коректність 
прогнозів та формування рекомендацій, демонструє передбачувану поведінку в 
типових та ускладнених сценаріях і відповідає вимогам до роботи 
114 
ЧДТУ 252485.010 ПЗ 
інформаційних систем у сфері електронної комерції. Отримані результати 
дозволили перейти до фінального етапу – приймального тестування, що 
передбачає оцінку системи з позиції потенційного замовника або кінцевого 
користувача. 
Нижче в таблиці 4.3 наведено результати системного тестування. 
 
Таблиця 4.3  
Результати системного тестування 
Результат 
Функція Очікуваний результат 
тесту 
Реєстрація користувача Новий обліковий запис створено Успішно 
Авторизація Користувач авторизується Успішно 
Видалення замовлення Замовлення успішно видалено Успішно 
Створення замовлення Замовлення створене Успішно 
 
4.2.4 Приймальне тестування 
Приймальне тестування проводилося з метою оцінити готовність 
розробленої системи до практичного використання в умовах реальної 
електронної комерції. На цьому етапі система розглядалася очима потенційного 
замовника або організації, що відповідатиме за її інсталяцію, супровід та 
подальше навчання користувачів. Основним завданням приймального 
тестування було визначити, наскільки функціональність, інтерфейси, точність 
прогнозів та стабільність роботи відповідають очікуванням і здатні забезпечити 
реальну користь у процесі формування персоналізованих рекомендацій. 
Під час приймального тестування система перевірялася в умовах, 
максимально наближених до експлуатаційних. До моделі подавалися дані, 
характерні для типового середовища електронної комерції, після чого 
оцінювався повний цикл роботи – від моменту завантаження інформації до 
115 
ЧДТУ 252485.010 ПЗ 
отримання рекомендацій для конкретного користувача. Значна увага 
приділялася зручності використання, зрозумілості інтерфейсів, послідовності 
відображення результатів, а також точності й стабільності роботи моделі 
машинного навчання при різних типах вхідних даних. Було підтверджено, що 
система коректно обробляє дані користувачів, формує прогнози відповідно до 
закладеної логіки та демонструє очікувану поведінку у всіх основних сценаріях 
взаємодії. 
Окремою частиною приймального тестування стало оцінювання 
можливостей впровадження системи в існуючі інформаційні процеси 
організації. Перевірялася зручність інтеграції через REST API, сумісність 
структури даних із типовими платформами електронної комерції та доступність 
функцій для подальшого розширення. За результатами перевірок було зроблено 
висновок, що система може бути впроваджена у реальне середовище з 
мінімальними технічними змінами. 
У наступному підрозділі подано приклади роботи системи, включаючи 
інтерфейси, приклади вхідних і вихідних даних та демонстрацію роботи моделі, 
що дозволяє наочно підтвердити результати приймального тестування та 
загальну готовність системи до використання в електронній комерції. 
 
Таблиця 4.4 
Результати приймального тестування 
Критерій Очікуваний результат Результат тесту 
Зручність інтерфейсу Інтерфейс інтуїтивно Успішно 
зрозумілий 
Продуктивність Час відповіді < 1 секунди Успішно 
Безпека Захист даних реалізовано Успішно 
Функціональність Функції виконують заявлені дії Успішно 
4.3 Приклади впровадженого програмного комплексу 
116 
ЧДТУ 252485.010 ПЗ 
У процесі реалізації програмного комплексу було виконано 
впровадження створеної системи у вигляді веб-застосунку, що дозволяє 
здійснювати прогнозування вподобань користувачів на основі методів 
машинного навчання. Інтерфейс застосунку реалізовано таким чином, щоб 
користувач міг послідовно виконувати кроки від завантаження вхідних даних 
до отримання прогнозів. Скріншоти інтерфейсу, наведені нижче, демонструють 
роботу системи на різних етапах: початкове завантаження даних, попередній 
перегляд структури набору даних, запуск навчання моделі та перегляд 
результатів рекомендованих товарів. Кожен із цих екранів ілюструє логіку 
використання та дає змогу користувачеві зрозуміти алгоритм взаємодії із 
системою. 
4.3.1 Інструкція користувача 
Після запуску веб-системи користувач потрапляє на головну сторінку, де 
відображається повний перелік доступних товарів. Інтерфейс побудований 
таким чином, щоб новий відвідувач міг одразу ознайомитися з асортиментом, 
однак для можливості оформлення замовлення необхідно пройти авторизацію. 
Система підтримує як стандартну реєстрацію та вхід за логіном і паролем, так і 
авторизацію через Google-акаунт. Після успішної автентифікації користувач 
повертається на головну сторінку, але вже з доступом до персоналізованих 
функцій системи. 
У авторизованого користувача на головній сторінці з’являється 
можливість додавати товари до кошика. Крім того, система формує персональні 
рекомендації, створені на основі алгоритмів машинного навчання, які 
враховують історію переглядів, попередні замовлення та характеристики 
подібних користувачів. 
Після додавання товарів до кошика користувач має можливість перейти 
до оформлення замовлення. У формі оформлення він підтверджує вибрані 
позиції, контактні дані та завершує покупку. У особистому кабінеті користувач 
може переглядати всі свої замовлення, відстежувати їхній статус у режимі 
117 
ЧДТУ 252485.010 ПЗ 
реального часу та за потреби скасовувати замовлення, якщо воно ще не 
оброблене. 
Головна сторінка також містить широкий набір засобів сортування та 
фільтрації, що дозволяє користувачу швидко знаходити потрібні товари. 
Підтримуються фільтри за категоріями, виробниками, типами продукції та 
іншими характеристиками, що значно підвищує зручність роботи з каталогом. 
Окрім клієнтського інтерфейсу, у системі реалізовано окремий 
адміністративний модуль. На рисунках представлено всі основні компоненти 
панелі адміністратора, через яку уповноважені працівники можуть керувати 
товарами, виробниками, клієнтами, замовленнями та іншими сутностями 
системи. Адміністратор отримує доступ до інструментів додавання, 
редагування та видалення записів, а також до аналітичної інформації, 
необхідної для підтримки актуальності каталогу та контролю роботи магазину. 
Усі наведені інтерфейси та дії користувача проілюстровані на відповідних 
скріншотах, що відображають роботу системи крок за кроком – від входу на 
сайт до оформлення замовлення й управління адміністративними функціями. 
Сторінки для працівника почергово показані на Рис.4.4.- 4.9. 
 
 
Рисунок 4.4 – Головна сторінка 
118 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 4.5 – Список клієнтів 
 
 
Рисунок 4.6 – Список працівників 
 
 
Рисунок 4.7 – Список виробників 
 
 
Рисунок 4.8 – Сторінка створення товару 
119 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 4.9 – Сторінка усіх замовлень 
 
Сторінки авторизованого користувача почергово показані на Рис.4.10.-
2.20. 
 
 
Рисунок 4.10 – Головна сторінка 
 
 
Рисунок 4.11 – Кошик з замовленими товарами 
120 
ЧДТУ 252485.010 ПЗ 
 
 
Рисунок 4.12 – Замовлення користувача 
 
 
Рисунок 4.13 – Список всіх замовлень користувача 
 
Далі хотів би відобразити окремі фрагменти сайту притаманні усім 
сторінкам на Рис.4.14. - 4.17. 
 
 
Рисунок 4.14 – Можливість зміни акаунту та локалізації сайту 
 
 
Рисунок 4.15 – Сторінка реєстрації 
121 
ЧДТУ 252485.010 ПЗ 
 
Рисунок 4.16 – Сторінка авторизації 
 
Також на сторінці авторизації присутній вхід за допомогою облікового 
запису Гугл. 
 
 
Рисунок 4.17 – Футер сайту 
 
Вище були деталізовано показані сторінки платформи з їх змістом. 
  
122 
ЧДТУ 252485.010 ПЗ 
Висновки до розділу 4 
У розділі було детально розглянуто процес розробки та тестування 
програмного комплексу, що включає як обґрунтування вибору засобів 
реалізації, так і опис структурної, функціональної та логічної схем системи. 
Було здійснено проектування БД, розробку інтерфейсу користувача та 
програмних компонентів, що забезпечують коректну роботу системи. 
Особлива увага приділялась тестуванню: модульному, інтеграційному, 
системному та приймальному, що дозволило перевірити правильність роботи 
кожного компоненту та всієї системи в цілому. Завдяки цьому було 
підтверджено відповідність розробленого програмного комплексу поставленим 
вимогам і його готовність до впровадження. 
Наведені приклади впровадженого програмного комплексу демонструють 
практичну ефективність розроблених рішень та можливість їх використання у 
реальних умовах експлуатації. Розділ підтвердив, що запропонований підхід до 
розробки та тестування забезпечує надійну, функціональну та зручну у 
використанні систему. 
123 
ЧДТУ 252485.010 ПЗ 
ЗАГАЛЬНІ ВИСНОВКИ 
У магістерській роботі виконано комплексне дослідження, проектування 
та програмну реалізацію системи персоналізованих рекомендацій для веб-
магазину, з акцентом на застосуванні сучасних методів машинного навчання та 
принципів інженерії програмного забезпечення. 
На основі аналізу сучасних підходів до побудови рекомендаційних 
систем визначено ключові проблеми галузі, серед яких – висока динамічність 
даних, неповнота інформації про користувачів, холодний старт, потреба у 
масштабуванні та забезпеченні якості моделі при зростанні обсягів даних. 
Проведено огляд існуючих методів фільтрації, гібридних архітектур та 
статистичних підходів, що дозволило обґрунтувати вибір алгоритму Bayesian 
Personalized Ranking (BPR) як базового методу для створення персоналізованих 
рекомендацій. 
У теоретичній частині сформовано наукову гіпотезу щодо можливості 
підвищення точності рекомендацій за рахунок поєднання поведінкових даних 
та додаткових ознак товарів. Проведено виявлення невизначеностей, аналіз 
ризиків, а також дослідження мінімального обсягу даних, необхідних для 
стабільного навчання BPR-моделі. Експериментальні тести підтвердили 
доцільність використання гібридного підходу та демонструють підвищення 
якості рекомендацій при додаванні контекстних та контентних ознак. Окремо 
оцінено вплив кількості взаємодій на збіжність моделі та проведено аналіз 
чутливості до шуму у даних. 
У межах програмної реалізації виконано повний цикл інженерії 
програмного забезпечення: моделювання предметної області, формування 
вимог, проектування архітектури, розробка та тестування системи. Побудовано 
UML-діаграми для класів, пакетів, компонентів, розгортання, а також 
поведінкові діаграми, що дозволило формалізувати логіку роботи системи та 
забезпечити коректність проектних рішень. 
124 
ЧДТУ 252485.010 ПЗ 
Розроблено модульну архітектуру серверної частини, реалізовано REST 
API, створено базу даних та функціональні програмні компоненти. Інтерфейс 
користувача побудований таким чином, щоб забезпечити швидкий доступ до 
рекомендованих товарів та максимально просту взаємодію з системою. 
Проведено модульне, інтеграційне та системне тестування, що підтвердило 
правильність роботи всіх компонентів програмного комплексу. 
Отримані наукові та практичні результати доводять ефективність 
використаного підходу та підтверджують можливість реального впровадження 
системи персоналізованих рекомендацій у веб-магазин. Розроблена система є 
масштабованою, стійкою до неповних даних та демонструє високу якість 
прогнозування вподобань користувачів. 
Виконана робота вирішує поставлену задачу та створює основу для 
подальшого розвитку, зокрема інтеграції з додатковими джерелами даних, 
впровадження моделей та розширення функціональності для різних типів 
онлайн-платформ.
125 
ЧДТУ 252485.010 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Burke R. Hybrid recommender systems: Survey and experiments [Текст] / R. 
Burke // User Modeling and User-Adapted Interaction. – 2002. – Vol. 12, No. 
4. – P. 331–370. 
2 Danilenko O., Kolesnyk I. Recommender systems in e-commerce platforms 
[Текст] / O. Danilenko, I. Kolesnyk. – 2021. 
3 Hidasi B. Session-based recommendations with recurrent neural networks 
[Текст] / B. Hidasi. – 2016. 
4 Lops P., Gemmis M., Semeraro G. Content-based recommender systems: State 
of the art and trends [Текст] / P. Lops, M. de Gemmis, G. Semeraro // 
Recommender Systems Handbook. – Springer, 2011. – P. 73–105 . 
5 Ricci F., Rokach L., Shapira B. Recommender Systems Handbook [Текст] / F. 
Ricci, L. Rokach, B. Shapira. – Springer, 2015 . 
6 Aggarwal C. C. Recommender Systems: The Textbook [Текст] / C. C. 
Aggarwal. – Springer, 2016. 
7 Sabiri M., et al. Hybrid Quality-Based Recommender Systems [Текст]. – 2025. 
8 Afsar M. M., et al. Reinforcement learning based recommender systems: A 
survey [Текст] / M. M. Afsar et al. // ACM Computing Surveys. – 2021. 
9 Zhang S., et al. Deep learning based recommender system: A survey and new 
perspectives [Текст] / S. Zhang et al. // ACM Computing Surveys. – 2019. 
10 Rendle S., et al. BPR: Bayesian Personalized Ranking from implicit feedback 
[Текст] / S. Rendle et al. // UAI. – 2009. 
11 Jannach D., et al. Recommender Systems: An Introduction [Текст] / D. 
Jannach et al. – Cambridge University Press, 2017. 
12 Goodfellow I., Bengio Y., Courville A. Deep Learning [Текст]. – MIT Press, 
2016. 
13 Silberschatz A., Korth H., Sudarshan S. Database System Concepts [Текст]. – 
McGraw-Hill, 2020. 
14 Oracle. Java Platform Documentation [Електронний ресурс]. – 2023. – 
Режим доступу: https://docs.oracle.com. 
126 
ЧДТУ 252485.010 ПЗ 
15 McKinney W. Python for Data Analysis [Текст] / W. McKinney. – O’Reilly 
Media, 2017. 
16 Grinberg M. Flask Web Development [Текст] / M. Grinberg. – O’Reilly 
Media, 2018. 
17 Python Documentation [Електронний ресурс]. – 2023. – Режим доступу: 
https://docs.python.org 
18 Docker Documentation [Електронний ресурс]. – 2023. – Режим доступу: 
https://docs.docker.com 
19 Java Concurrency in Practice [Текст] / B. Goetz et al. – Addison-Wesley, 
2016. 
20 Cornac Documentation [Електронний ресурс]. – 2023. – Режим доступу: 
https://cornac.preferred.ai 
21 Virtanen P., et al. SciPy 1.0: Fundamental algorithms for scientific computing 
in Python [Текст] / P. Virtanen et al. // Nature Methods. – 2020. 
22 GDPR. General Data Protection Regulation [Електронний ресурс]. – 2018. 
23 OWASP. OWASP Top 10 Web Application Security Risks [Електронний 
ресурс]. – 2023. – Режим доступу: https://owasp.org 
24 Донцова О. Є. Інформаційна технологія рекомендації товарів для 
платформи онлайн-продажів : кваліфікаційна магістерська робота / 
Черкаський державний технологічний університет. – Черкаси, 2020. 
25 Коренівський Д. Г. Дестабілізуючий ефект параметричного білого шуму в 
неперервних та дискретних динамічних системах [Текст]. – К. : Ін-т 
математики, 2006. – 111 с. 
26 Ромовська З. В., Черняк Ю. В. Сімейне законодавство України [Текст]. – 
К. : Прецедент, 2006. – 93 с. 
27 Акофф Р. Л., Магидсон Д., Зддисон Г. Д. Идеализированное 
проектирование: как предотвратить завтрашний кризис сегодня [Текст]. – 
Дніпропетровськ : Баланс Бизнес Букс, 2007. – 265 с. 
28 Психология менеджмента [Текст] / за ред. Г. С. Никифорова. – Х. : 
Гуманитарный центр, 2007. – 510 с. 
127 
ЧДТУ 252485.010 ПЗ 
29 Проблеми типологічної та квантитативної лексикології [Текст]. – 
Чернівці : Рута, 2007. – 310 с. 
30 Межгосударственные стандарты : каталог в 6 т. [Текст]. – Львів : НТЦ 
«Леонорм-Стандарт», 2005. – Т. 1. – 277 с. 
31 Ризикологія в економіці та підприємництві : матеріали міжнар. наук.-
практ. конф. [Текст]. – К. : КНЕУ, 2001. – 452 с. 
32 Панасюк М. І., Скорбун А. Д., Сплошной Б. М. Про точність визначення 
активності твердих радіоактивних відходів [Текст]. – Чорнобиль, 2006. – 
7 с. 
33 Разумовский В. А., Андреев Д. А. Управление маркетинговыми 
исследованиями в регионе [Текст]. – М., 2002. – 210 с. 
34 Кримінально-процесуальний кодекс України [Текст]. – К. : 
Парламентське видавництво, 2006. – 207 с. 
35 Якість води. Словник термінів: ДСТУ ISO 6107 [Текст]. – К. : 
Держспоживстандарт України, 2006. – 181 с. 
36 Нгуен Ші Данг. Моделювання і прогнозування макроекономічних 
показників [Текст] : автореф. дис. – К., 2007. – 20 с. 
37 Костенко Л. Й. та ін. Бібліотека і доступність інформації у сучасному 
світі [Електронний ресурс] // Бібліотечний вісник. – 2003. – №4. 
38 Adomavicius G., Tuzhilin A. Toward the next generation of recommender 
systems: A survey of the state-of-the-art and possible extensions [Текст] / G. 
Adomavicius, A. Tuzhilin // IEEE Transactions on Knowledge and Data 
Engineering. – 2005. – Vol. 17, No. 6. – P. 734–749. 
39 Koren Y., Bell R., Volinsky C. Matrix factorization techniques for 
recommender systems [Текст] / Y. Koren, R. Bell, C. Volinsky // Computer. – 
2009. – Vol. 42, No. 8. – P. 30–37. 
40 He X., et al. Neural collaborative filtering [Текст] / X. He et al. // Proceedings 
of the 26th International World Wide Web Conference (WWW). – 2017. – P. 
173–182. 
 
128 
 
ДОДАТОК А 
 
 ЗАТВЕРДЖЕНО: 
 Зав. кафедри ПЗАС  
 проф.  Голуб С.В. 
 ___________________________ 
 
 
 
 
ПРОГРАМНА РЕАЛІЗАЦІЯ СИСТЕМИ ПЕРСОНАЛІЗОВАНИХ 
РЕКОМЕНДАЦІЙ У WEB-МАГАЗИНІ ЕЛЕКТРОПРИЛАДІВ 
 
Специфікація 
482. ЧДТУ 252485.010  
Листів 2 
 
 
Розробник ________________ Климчук В.А. 
 
Керівник ________________ Півень О.Б. 
 
Н.Контроль ________________ Півень О.Б. 
 
 
 
 
Черкаси 2025  
 482. ЧДТУ 252485.010   
Специфікація 
Позначення Найменування Примітка 
482. ЧДТУ 252485.010 12-01 Текст програми  
482.ЧДТУ 252485.010 90-01 Презентація  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
130 
 482. ЧДТУ 252485.010 12-01   
ДОДАТОК Б 
 
  
 
 
 
ПРОГРАМНА РЕАЛІЗАЦІЯ СИСТЕМИ ПЕРСОНАЛІЗОВАНИХ 
РЕКОМЕНДАЦІЙ У WEB-МАГАЗИНІ ЕЛЕКТРОПРИЛАДІВ 
 
Текст програми 
482. ЧДТУ 252485.010 12-01 
Листів 15 
 
 
 
 
 
Розробник ________________ Климчук В.А. 
 
 
 
 
 
 
 
 
 
 
Черкаси 2025 
482. ЧДТУ 252485.010 12-01 
ClientController.java  
    
package ua.edu.chdtu.webui.web; 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER
 
')") 
@Controller 
    @GetMapping("/add") 
@RequestMapping("/clients") 
    public ModelAndView clientGet() { 
@Slf4j 
        return new ModelAndView("client/newClient") 
@RequiredArgsConstructor 
                .addObject("client", new AppUser()); 
public class ClientController { 
    } 
 
    
    private final AppUserService userService; 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER
    private final PasswordEncoder encoder; 
')") 
    
    @PostMapping("/add") 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER
    public ModelAndView addClient( 
')") 
            @Valid @ModelAttribute("client") AppUser 
    @GetMapping() 
client, 
    public ModelAndView 
            BindingResult bindingResult) { 
clients(@RequestParam(name = "page", defaultValue 
 
= "0") int page, 
        if (bindingResult.hasErrors()) { 
                                @RequestParam(name = "size", 
            return new 
defaultValue = "5") int size, 
ModelAndView("client/newClient") 
                                @RequestParam(name = "sort", 
                    .addObject("client", client) 
defaultValue = "id") String sort, 
                    .addObject("errors", 
                                @RequestParam(name = 
bindingResult.getAllErrors()); 
"direction", defaultValue = "asc") String direction) { 
        } 
        Pageable pageable = PageRequest.of(page, size, 
 
Sort.by(Sort.Order.by(sort)).ascending()); 
        try { 
        if ("desc".equalsIgnoreCase(direction)) { 
            client.setRoleType(RoleType.USER); 
            pageable = PageRequest.of(page, size, 
            
Sort.by(Sort.Order.by(sort)).descending()); 
client.setPassword(encoder.encode(client.getPasswor
        } 
d())); 
        Page<AppUser> clients = 
            userService.save(client); 
userService.findAllByRoleTypeIn(Set.of(RoleType.U
        } catch (Exception e) { 
SER), pageable); 
            return new 
 
ModelAndView("client/newClient") 
        return new ModelAndView("client/clients") 
                    .addObject("error", e.getMessage()); 
                .addObject("clients", clients.getContent()) 
        } 
                .addObject("pageNumber", page) 
 
                .addObject("totalPages", 
        return new ModelAndView("redirect:/clients"); 
clients.getTotalPages()) 
    } 
                .addObject("size", size) 
    
                .addObject("sort", sort) 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER
                .addObject("direction", direction); 
')") 
    } 
132 
482. ЧДТУ 252485.010 12-01 
    @GetMapping("/{id}/edit")             throw new 
    public ModelAndView ResponseStatusException(HttpStatus.NOT_FOUND, 
clientEditGet(@PathVariable("id") @Positive Long "Client not found"); 
id) {         } 
        AppUser client = userService.getById(id);  
        if (client == null) {         if (bindingResult.hasErrors()) { 
            throw new             model.addAttribute("client", client); 
ResponseStatusException(HttpStatus.NOT_FOUND,             return "client/editClient"; 
"Client not found");         } 
        }  
        ModelAndView modelAndView = new         existingClient.setName(client.getName()); 
ModelAndView("client/editClient");         existingClient.setEmail(client.getEmail()); 
        modelAndView.addObject("client", client);         
 existingClient.setPassword(client.getPassword()); 
        return modelAndView;  
    }         userService.save(existingClient); 
     
@PreAuthorize("hasAnyRole('ADMIN','MANAGER         return "redirect:/clients"; 
')")     } 
    @PostMapping("/{id}/edit")     
    public String clientEditPost( @PreAuthorize("hasAnyRole('ADMIN','MANAGER
            @PathVariable("id") @Positive Long id, ')") 
            @Valid @ModelAttribute("client") AppUser     @GetMapping("/{id}/delete") 
client,     public ModelAndView 
            BindingResult bindingResult, deleteClient(@PathVariable Long id) { 
            Model model) {         userService.deleteById(id); 
         log.warn("Orders with clientId {} deleted", id); 
        AppUser existingClient =  
userService.getById(id);         return new ModelAndView("redirect:/clients"); 
        if (existingClient == null) {     } 
} 
 
 
 
ProductController.java     private final ProductServiceImpl productService; 
package ua.edu.chdtu.webui.web;     
 @PreAuthorize("hasAnyRole('ADMIN','MANAGER
@Controller ')") 
@RequestMapping("/products")     @GetMapping("/add") 
@RequiredArgsConstructor     public ModelAndView addProductGet() { 
public class ProductController {         ModelAndView modelAndView = new 
    private final ManufacturerService ModelAndView("product/newProduct"); 
manufacturerService; 
133 
482. ЧДТУ 252485.010 12-01 
        modelAndView.addObject("product", new                 .category(productForm.getCategory()) 
Product());                 
        modelAndView.addObject("categories", .productType(productForm.getProductType()) 
productService.getCategories());                 .model(productForm.getModel()) 
        modelAndView.addObject("productTypes",                 
productService.getTypes()); .manufacturer(manufacturerService.getById(product
        modelAndView.addObject("manufacturers", Form.getManufacturer())) 
manufacturerService.getAll());                 
        return modelAndView; .characteristic(productForm.getCharacteristic()) 
    }                 .description(productForm.getDescription()) 
                    .price(productForm.getPrice()) 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER                 .build(); 
')")     } 
    @PostMapping("/add")     
    public ModelAndView @PreAuthorize("hasAnyRole('ADMIN','MANAGER
addProductPost(@ModelAttribute("product") @Valid ')") 
ProductForm productForm, BindingResult result) {     @GetMapping("/{id}/edit") 
        if (result.hasErrors()) {     public ModelAndView 
            ModelAndView modelAndView = editProductGet(@PathVariable("id") @Positive Long 
addProductGet(); id) { 
            modelAndView.addObject("errors",         Product product = productService.getById(id); 
result.getAllErrors().stream().map(DefaultMessageSo  
urceResolvable::getDefaultMessage).collect(Collecto         if (product == null) { 
rs.toSet()));             throw new 
            modelAndView.addObject("error_messages", ResponseStatusException(HttpStatus.NOT_FOUND, 
result.getAllErrors().stream().map(DefaultMessageSo "Product not found"); 
urceResolvable::getDefaultMessage).collect(Collecto         } 
rs.toSet()));  
            return modelAndView;         ModelAndView modelAndView = new 
        } ModelAndView("product/editProduct"); 
         modelAndView.addObject("product", product); 
        productService.save(getByForm(productForm));         modelAndView.addObject("categories", 
 productService.getCategories()); 
        return addProductGet()         modelAndView.addObject("productTypes", 
                .addObject("messages", List.of("Продукт productService.getTypes()); 
створено"));         modelAndView.addObject("manufacturers", 
    } manufacturerService.getAll()); 
  
    private Product getByForm(ProductForm         return modelAndView; 
productForm) {     } 
        return Product.builder()    
                .name(productForm.getName()) 
134 
482. ЧДТУ 252485.010 12-01 
@PreAuthorize("hasAnyRole('ADMIN','MANAGER         } 
')")  
    @PostMapping("/{id}/edit")         Product product = getByForm(productForm); 
    public ModelAndView editProductPost(         product.setId(id); 
            @PathVariable("id") @Positive Long id,         productService.save(product); 
            @ModelAttribute("product") @Valid         return editProductGet(id) 
ProductForm productForm,                 .addObject("messages", List.of("Продукт 
            BindingResult result збережено")); 
    ) {     } 
        if (result.hasErrors()) {  
            ModelAndView modelAndView =     
editProductGet(id); @PreAuthorize("hasAnyRole('ADMIN','MANAGER
            modelAndView.addObject("errors", ')") 
result.getAllErrors().stream().map(DefaultMessageSo     @GetMapping("/{id}/delete") 
urceResolvable::getDefaultMessage).collect(Collecto     public ModelAndView 
rs.toSet())); deleteProduct(@PathVariable Long id) { 
            modelAndView.addObject("error_messages",         productService.delete(id); 
result.getAllErrors().stream().map(DefaultMessageSo         return new 
urceResolvable::getDefaultMessage).collect(Collecto ModelAndView("redirect:/products"); 
rs.toSet()));     } 
            return modelAndView; }
 
 
OAuth2Service.java 
package ua.edu.chdtu.webui.service;         saveOAuth2User(attributes); 
  
@Slf4j         return getCustomOidcUser(oidcUser); 
@Service     } 
@RequiredArgsConstructor  
public class OAuth2Service extends OidcUserService     private OidcUser getCustomOidcUser(OidcUser 
{ oidcUser) { 
         String role = "ROLE_" + 
    private final BaseAppUserService appUserService; RoleType.USER.name(); 
         return new DefaultOidcUser( 
    @Override //                oidcUser.getAuthorities(), 
    public OidcUser loadUser(OidcUserRequest                 List.of(new 
request) throws OAuth2AuthenticationException { SimpleGrantedAuthority(role)), 
        log.trace("Load user {}", request);                 oidcUser.getIdToken(), 
        OidcUser oidcUser = super.loadUser(request);                 oidcUser.getUserInfo(), 
        Map<String, ?> attributes =                 "email" 
oidcUser.getAttributes();         ); 
     } 
135 
482. ЧДТУ 252485.010 12-01 
         try { 
    private void saveOAuth2User(Map<String, ?>             AppUser account = new AppUser( 
attributes) {                     null, 
        String email = (String) attributes.get("email");                     (String) attributes.get("name"), 
        try {                     (String) attributes.get("email"), 
            AppUser account =                     (String) attributes.get("sub"), 
appUserService.getByEmail(email);                     RoleType.USER, 
            if (account.getIsEmailVerified() == null ||                     true 
!account.getIsEmailVerified()) {             ); 
                account.setIsEmailVerified(true);             appUserService.save(account); 
                appUserService.save(account);             log.info("Registered new account: {}", 
            } account.getEmail()); 
        } catch (AppException e) {         } catch (Exception e) { 
            registerNewUser(attributes);             log.debug("OAuth2 attributes: {}", 
        } attributes); 
    }         } 
     } 
    private void registerNewUser(Map<String, ?> }
attributes) { 
  
 
 
WebSecurityConfig.java     private static final String[] STATIC_RESOURCES 
package ua.edu.chdtu.webui.config; = {"/css/**", "/img/**", "/js/**", "/webjars/**"}; 
     private static final String[] CLIENT_URLS = 
@Configuration {"/orders", "/orders/**"}; 
@EnableWebSecurity  
@EnableMethodSecurity(securedEnabled = true,     @Bean 
jsr250Enabled = true)     public SecurityFilterChain 
@RequiredArgsConstructor securityFilterChain(HttpSecurity http) throws 
public class WebSecurityConfig { Exception { 
         http 
    private final OAuth2Service oAuth2Service;                 .csrf(AbstractHttpConfigurer::disable) 
                 .authorizeHttpRequests(auth -> auth 
    private static final String[] ANONYMOUS_URLS .requestMatchers(STATIC_RESOURCES).permitAll(
= {"/login", "/registration", "/login/oauth2/code/**"}; )                        
    private static final String[] ADMIN_URLS = .requestMatchers(ANONYMOUS_URLS).permitAll(
{"/admin/**", "/employees/**", "/clients/**", )                        
"/products/**", "/swagger-ui/**", "/v3/api-docs/**"}; .requestMatchers(CLIENT_URLS).authenticated() 
    private final String[] PERMIT_ALL_URLS = {"/",                         
"/cart", "/cart/*", "/author/**", "/api/**", "/verify"}; .requestMatchers(PERMIT_ALL_URLS).permitAll() 
136 
482. ЧДТУ 252485.010 12-01 
                         
.requestMatchers(ADMIN_URLS).hasAnyRole("AD         return http.build(); 
MIN", "MANAGER")     } 
                        .anyRequest().authenticated()  
                )     @Bean 
                .formLogin(form -> form     public PasswordEncoder passwordEncoder() { 
                        .loginPage("/login")         return new BCryptPasswordEncoder(); 
                        .defaultSuccessUrl("/", true)     } 
                        .permitAll()  
                )     @Bean 
                .oauth2Login(oauth2 -> oauth2     public AuthenticationManager 
                        .loginPage("/login") authenticationManager(AuthenticationConfiguration 
                        .userInfoEndpoint(info -> config) throws Exception { 
info.oidcUserService(oAuth2Service))         return config.getAuthenticationManager(); 
                )     } 
                .logout(LogoutConfigurer::permitAll); } 
 
 
 
OrderService.java     } 
package ua.edu.chdtu.shopservice.service;  
     @Override 
@Service     public UserOrder getById(Long id) { 
@Transactional         return orderRepository.findById(id) 
@RequiredArgsConstructor                 .orElseThrow(() -> new 
public class OrderServiceImpl implements EntityNotFoundException("Order not found with ID: 
OrderService { " + id)); 
     } 
    private final ProductService productService;  
    private final OrdersRepository orderRepository;     @Override 
    private final OrderItemRepository     public void save(UserOrder order) { 
orderItemRepository;         if (order == null) { 
             throw new EntityExistsException(); 
    @Override         } 
    public List<UserOrder> getAll() {         orderRepository.save(order); 
        return orderRepository.findAll();     } 
    }      
 @Override 
    @Override     public void delete(Long id) { 
    public Page<UserOrder> getAll(Pageable         orderRepository.deleteById(id); 
pageable) {     } 
        return orderRepository.findAll(pageable);  
137 
482. ЧДТУ 252485.010 12-01 
    @Override                 .approved(false) 
    public Page<UserOrder> getByClientId(Long                 .build(); 
clientId, Pageable pageable) {  
        return orderRepository.findByClientId(clientId,         Collection<OrderItem> items = 
pageable); mapToOrderItem(order, cart.getCartItems()); 
    }  
         if (cart.getCartItems().isEmpty()) { 
    @Override             throw new AppException("Order items list is 
    public List<UserOrder> getByClientId(Long empty"); 
clientId) {         } 
        return orderRepository.findByClientId(clientId);  
    }         order.setItems(items); 
         orderRepository.save(order); 
    @Override         return order; 
    public Page<OrderItem>     } 
getOrderItemByOrderId(Long orderId, Pageable  
pageable) {     private Collection<OrderItem> 
        return mapToOrderItem(UserOrder order, 
orderItemRepository.findByOrderId(orderId, Collection<CartItem> items) { 
pageable);         if (items == null || items.isEmpty()) { 
    }             return Collections.emptyList(); 
             } 
@Transactional  
@Override         return items.stream() 
    public UserOrder createOrderFromCart(AppUser                 .map(e -> OrderItem.builder() 
client, Cart cart) {                         .order(order)                       
        if (client == null || cart == null || cart.getItems() .product(productService.getById(e.getProductId())) 
== null || cart.getItems().isEmpty()) {                         .price(e.getPrice()) 
            throw new AppException("Cart is empty");                         .quantity(e.getQuantity()) 
        }                         .build() 
                 ).toList(); 
        UserOrder order = UserOrder.builder()     } 
                .client(client) } 
 
SendEmailEventService.java     private final EmailSender mailSender; 
package ua.edu.chdtu.notificationservice.service;     private final EmailNotificationRepository 
 emailNotificationRepository; 
@Slf4j  
@Service     @Override 
@RequiredArgsConstructor     public void processEvent(StoreEvent event) { 
public class SendEmailEventService implements         EmailNotification notification = 
EventService { getEmailNotification(event); 
138 
482. ЧДТУ 252485.010 12-01 
             case OrderCreatedEvent ignored -> 
        if (notification.getEmails() == null || getEmailNotification4OrderCreatedEvent((OrderCrea
notification.getEmails().isEmpty()) { tedEvent) event); 
            log.warn("Can't send and save notification for             default -> throw new 
empty emails."); IllegalStateException("Unexpected event type: " + 
            return; event); 
        }         }; 
        try {     } 
            mailSender.send(  
                    notification.getEmails(),     private EmailNotification 
                    notification.getSubject(), getEmailNotification4EmailVerificationEvent(Email
                    notification.getMessage() VerificationEvent event) { 
            );         return new EmailNotification( 
            notification.setSuccess(true);                 Set.of(event.getUserEmail()), 
        } catch (Exception e) {                 event.getEventType(), 
            log.error("Invalid send message to emails:                 event.getInfo()); 
[{}]", notification.getEmails());     } 
            notification.setSuccess(false);  
        }     private EmailNotification 
 getEmailNotification4OrderCreatedEvent(OrderCreat
        emailNotificationRepository.save(notification); edEvent event) { 
    }         return new EmailNotification( 
                 Set.of(event.getUserEmail()), 
    private EmailNotification                 event.getEventType(), 
getEmailNotification(StoreEvent event) {                 event.getInfo()); 
        return switch (event) {     } 
            case EmailVerificationEvent ignored -> } 
                    
getEmailNotification4EmailVerificationEvent((Email
VerificationEvent) event); 
 
 
 
 
EmailNotificationSender.java     private final JavaMailSender mailSender; 
package ua.edu.chdtu.notificationservice.api;  
     @Override 
@Component     public void send(Set<String> emails, String 
@RequiredArgsConstructor subject, String message) { 
@Slf4j         String[] emailsArray = emails.toArray(new 
public class EmailNotificationSender implements String[0]); 
EmailSender { 
139 
482. ЧДТУ 252485.010 12-01 
        SimpleMailMessage msg = new         mailSender.send(msg); 
SimpleMailMessage();         log.info("Successfully send (emails: [{}], 
        msg.setSubject(subject); subject: {}, message: {})", emails, subject, message); 
        msg.setText(message);     } 
        msg.setTo(emailsArray); } 
        msg.setFrom("[email protected]"); 
 
 
 
AiEngineClient.java 
package ua.edu.chdtu.aiclient.api;                 HttpMethod.GET, 
                 entity, 
@Component                 new ParameterizedTypeReference<>() {} 
@RequiredArgsConstructor         ); 
public class AiEngineClient {  
    private final RestTemplate restTemplate;         if (response.getBody() != null) { 
             return 
    @Value("${api.key}") response.getBody().getRecommendations(); 
    private String API_KEY;         } else  { 
    @Value("${api.base-url}")             return Collections.emptyList(); 
    private String BASE_URL;         } 
     } 
    // 1. Отримати рекомендації  
    public List<Long> getRecommendations(String     // 2. Відправити подію взаємодії користувача 
userId, int count) {     public void sendInteractionEvent(String userId, 
        RestTemplate restTemplate = new String productId, String interactionType) throws 
RestTemplate(); JsonProcessingException { 
        HttpHeaders headers = new HttpHeaders();         RestTemplate restTemplate = new 
        headers.set("X-API-KEY", API_KEY); RestTemplate(); 
         HttpHeaders headers = new HttpHeaders(); 
        UriComponentsBuilder builder =         
UriComponentsBuilder.fromUriString(BASE_URL + headers.setContentType(MediaType.APPLICATION
"/ai/recommend/" + userId + "/") _JSON); 
                .queryParam("count_recommendations",         headers.set("X-API-KEY", API_KEY); 
count);  
         Map<String, Object> payload = Map.of( 
        HttpEntity<Void> entity = new                 "user_id", userId, 
HttpEntity<>(headers);                 "product_id", productId, 
                 "event_type", 
        ResponseEntity<RecommendationResponse> interactionType.toLowerCase() 
response = restTemplate.exchange(         ); 
                builder.toUriString(),  
140 
482. ЧДТУ 252485.010 12-01 
        // Серіалізація вручну в JSON         
        ObjectMapper mapper = new ObjectMapper(); headers.setContentType(MediaType.APPLICATION
        String jsonBody = _JSON); 
mapper.writeValueAsString(payload);         headers.set("X-API-KEY", API_KEY); 
  
        // Створюємо HttpEntity з JSON рядком         HttpEntity<String> request = new 
        HttpEntity<String> entity = new HttpEntity<>("{}", headers); 
HttpEntity<>(jsonBody, headers);  
         restTemplate.exchange( 
        restTemplate.postForEntity(BASE_URL +                 BASE_URL + "/ai/train/", 
"/ai/interaction/", entity, String.class);                 HttpMethod.POST, 
    }                 request, 
                 String.class 
    // 3. Перенавчити         ); 
    public void callTrainModel() {     } 
        HttpHeaders headers = new HttpHeaders(); } 
 
 
views.py     return Response({"status": "event logged"}) 
from rest_framework.decorators import api_view  
from rest_framework.response import Response  
from .models import InteractionProductEvent @api_view(["POST"]) 
from .recommender import RecommenderSystem def train_model(request): 
     """ 
recommender = RecommenderSystem()     Перевчити модель на основі всіх подій 
     """ 
@api_view(["POST"])     try: 
def log_event(request):         recommender.train() 
    """         return Response({"status": "model trained"}) 
    Логування події: перегляд, покупка, лайк     except Exception as e: 
    """         return Response({"error": str(e)}, status=500) 
    user_id = request.data.get("user_id")  
    product_id = request.data.get("product_id") @api_view(["GET"]) 
    event_type = request.data.get("event_type") def get_recommendations(request, user_id: int): 
     """ 
    if not user_id or not product_id or not event_type:     Отримання рекомендацій для конкретного 
        return Response({"error": "user_id, product_id, користувача 
event_type обов'язкові"}, status=400)     """ 
     try: 
            k = 
InteractionProductEvent.objects.create(user_id=user_ request.query_params.get("count_recommendations", 
id, product_id=product_id, event_type=event_type) 5) 
141 
482. ЧДТУ 252485.010 12-01 
        k = int(k)  # привели до int         return Response({ 
    except ValueError:             "user_id": user_id, 
        k = 5             "recommendations": recommendations 
         }) 
    try:     except Exception as e: 
        recommendations =         return Response({"error": str(e)}, status=500) 
recommender.recommend(user_id, k) 
 
 
 
recommender.py         # Маппінг у послідовні індекси 
import traceback         self.user_mapping = {u: i for i, u in 
 enumerate(users)} 
import cornac         self.reverse_user_mapping = {i: u for u, i in 
import numpy as np self.user_mapping.items()} 
from .models import InteractionProductEvent,  
Product         self.item_mapping = {p: i for i, p in 
 enumerate(products)} 
         self.reverse_item_mapping = {i: p for p, i in 
class RecommenderSystem: self.item_mapping.items()} 
    def __init__(self):  
        self.model = None         interactions = [] 
        self.user_mapping = {}  # {user_id -> uid}         for event in 
        self.reverse_user_mapping = {}  # {uid -> InteractionProductEvent.objects.select_related("prod
user_id} uct").iterator(): 
        self.item_mapping = {}  # {product_id -> iid}             if not event.product or event.product.id not in 
        self.reverse_item_mapping = {}  # {iid -> self.item_mapping: 
product_id}                 continue 
  
    def build_dataset(self):             # Встановлюємо вагу події 
 # Отримуємо всі унікальні користувачі та             weight = 1 
продукти             if event.event_type == "view": 
        users =                 weight = 2 
list(InteractionProductEvent.objects.values_list("user             elif event.event_type == "like": 
_id", flat=True).distinct())                 weight = 3 
        products = list(Product.objects.values_list("id",             elif event.event_type == "purchase": 
flat=True))                 weight = 5 
  
        if not users or not products:             interactions.append([ 
            print("No users or products found!")                 self.user_mapping[event.user_id], 
            return []                 self.item_mapping[event.product.id], 
                 weight 
142 
482. ЧДТУ 252485.010 12-01 
            ])  
     def recommend(self, user_id, k=5): 
        print(f"Built dataset with {len(interactions)}         if not self.model: 
interactions")             self.train() 
        return interactions  
         if user_id not in self.user_mapping: 
    def train(self):             print(f"User {user_id} not found") 
        interactions = self.build_dataset()             return [] 
        if not interactions:  
            raise ValueError("No interactions to train         uid = self.user_mapping[user_id] 
on.")  
         # Оцінки для всіх продуктів 
        num_users = len(set([u for u, _, _ in         scores = self.model.score(uid)  # numpy.ndarray 
interactions]))  
        num_items = len(set([i for _, i, _ in         # Продукти, які користувач уже бачив (тільки 
interactions])) валідні індекси) 
        if num_users < 2 or num_items < 2:         seen_items = [ 
            raise ValueError(f"Need at least 2 users and 2             self.item_mapping[e.product.id] 
items to train. Got {num_users} users, {num_items}             for e in 
items.") InteractionProductEvent.objects.filter(user_id=user_i
 d) 
        try:             if e.product_id in self.item_mapping 
            train_set =         ] 
cornac.data.Dataset.from_uir(interactions)         seen_items = [i for i in seen_items if i < 
            self.model = cornac.models.BPR( len(scores)] 
                k=20,  
                max_iter=50,  
                learning_rate=0.01,         # Виключаємо бачені продукти 
                lambda_reg=0.001         scores[seen_items] = -np.inf 
            )  
            print("Starting model training...")         # Топ-K продуктів 
            self.model.fit(train_set)         top_indices = np.argsort(-scores)[:k] 
            print("Model training finished successfully.")  
        except Exception:         # Повертаємо оригінальні ID продуктів 
            print("Error during model training:")         return [self.reverse_item_mapping[i] for i in 
            traceback.print_exc() top_indices] 
            raise 
  
 
docker-compose.yml services: 
version: "3.9"   postgres-db: 
     image: postgres 
143 
482. ЧДТУ 252485.010 12-01 
    restart: always     container_name: kafka 
    container_name: postgres-db     ports: 
    ports:       - "9092:9092" 
      - "5432:5432"       - "9101:9101" 
    environment:     environment: 
      POSTGRES_USER: postgres       KAFKA_NODE_ID: 1 
      POSTGRES_PASSWORD: root       CLUSTER_ID: '4L6g3nShT-eMCtK--X86sw' 
      POSTGRES_DB: ai_shop       
    networks: KAFKA_LISTENER_SECURITY_PROTOCOL_M
      - internal_net AP: 
 'CONTROLLER:PLAINTEXT,PLAINTEXT:PLAIN
  ai-engine-service: TEXT,PLAINTEXT_HOST:PLAINTEXT' 
    build:       KAFKA_ADVERTISED_LISTENERS: 
      context: ./ai-engine-service 'PLAINTEXT://kafka:29092,PLAINTEXT_HOST://l
      dockerfile: ai-engine-service.dockerfile ocalhost:9092' 
    container_name: ai-engine-service       KAFKA_PROCESS_ROLES: 'broker,controller' 
    ports:       KAFKA_CONTROLLER_QUORUM_MODE: 
      - "8000:8000" 'kraft' 
    env_file:       
      - ./ai-engine-service/.env KAFKA_CONTROLLER_QUORUM_VOTERS: 
    depends_on: '1@kafka:29093' 
      - postgres-db       KAFKA_LISTENERS: 
    volumes: 'PLAINTEXT://kafka:29092,CONTROLLER://kafka
      - ./ai-engine-service:/app :29093,PLAINTEXT_HOST://0.0.0.0:9092' 
    environment:       KAFKA_CONTROLLER_LISTENER_NAMES: 
      - 'CONTROLLER' 
DJANGO_SETTINGS_MODULE=settings.main       
    command: sh -c "python manage.py migrate && KAFKA_OFFSETS_TOPIC_REPLICATION_FACT
python manage.py runserver 0.0.0.0:8000" OR: 1 
    networks:       
      - internal_net KAFKA_OFFSETS_TOPIC_NUM_PARTITIONS: 3 
     depends_on: 
  mongo-db:       - postgres-db 
    image: mongo:6       - mongo-db 
    container_name: mongo-db     networks: 
    ports:       - internal_net 
      - "27017:27017"  
    networks:   notification-service: 
      - internal_net     build: 
       context: notification-service 
  kafka:       dockerfile: 
    image: confluentinc/cp-kafka:7.5.1 src/main/resources/notification.dockerfile 
144 
482. ЧДТУ 252485.010 12-01 
    environment: 
      - 
KAFKA_BOOTSTRAP_SERVERS=kafka:29092 
      - MONGODB_HOST=mongo-db 
      - EMAIL_HOST=smtp.gmail.com 
      - EMAIL_PORT=587 
      - [email protected] 
      - EMAIL_PASSWORD=your_password 
      - EMAIL_USE_TLS=true 
    dns: 
      - 8.8.8.8 
      - 8.8.4.4 
    depends_on: 
      - mongo-db 
      - kafka 
    networks: 
      - internal_net 
 
  web-ui: 
    build: 
      context: web-ui 
      dockerfile: src/main/resources/web-ui.dockerfile 
    environment: 
      - 
KAFKA_BOOTSTRAP_SERVERS=kafka:29092 
      - BASE_URL=http://ai-engine-service:8000 
      - API_KEY=supersecret123 
      - 
JDBC_DATABASE_URL=jdbc:postgresql://postgres
-db:5432/ai_shop 
    ports: 
      - "8080:8080" 
    depends_on: 
      - postgres-db 
    networks: 
      - internal_net 
 
networks: 
  internal_net: 
    driver: bridge 
145 
ДОДАТОК В 
 
  
 
 
 
ПРОГРАМНА РЕАЛІЗАЦІЯ СИСТЕМИ ПЕРСОНАЛІЗОВАНИХ 
РЕКОМЕНДАЦІЙ У WEB-МАГАЗИНІ ЕЛЕКТРОПРИЛАДІВ 
 
Презентація 
482.ЧДТУ 252485.010 90-01 
Листів 14 
 
 
 
 
 
Розробник ________________ Климчук В.А. 
 
 
 
 
 
 
 
Черкаси 2025 
 
 
482. ЧДТУ 252485.010 90-01 2 
 
 
 
Рис. Г.1 – Титульний слайд 
 
 
Рис. Г.2 – Слайд «Вступ» 
147 
 
482. ЧДТУ 252485.010 90-01 32 
 
 
 
Рис. Г.3 – Слайд «Вступ» 
 
 
Рис. Г.4 – Слайд «Вступ» 
148 
 
482. ЧДТУ 252485.010 90-01 42  
 
 
 
Рис. Г.5 – Слайд «Вступ» 
 
 
Рис. Г.6 – Слайд «Вступ» 
149 
 
482. ЧДТУ 252485.010 90-01 52  
 
 
 
Рис. Г.7 – Слайд «Вступ» 
 
 
Рис. Г.8 – Слайд «Вступ» 
150 
 
482. ЧДТУ 252485.010 90-01 62  
 
 
 
Рис. Г.9 – Слайд «Вступ» 
 
 
Рис. Г.10 – Слайд «Вступ» 
151 
 
482. ЧДТУ 252485.010 90-01 72  
 
 
 
 
Рис. Г.11 – Слайд «Вступ» 
 
Рис. Г.12 – Слайд «Вступ» 
152 
 
482. ЧДТУ 252485.010 90-01 82  
 
 
 
 
Рис. Г.13 – Слайд «Вступ» 
 
Рис. Г.14 – Слайд «Вступ» 
153 
 
482. ЧДТУ 252485.010 90-01 92  
 
 
 
Рис. Г.15 – Слайд «Вступ» 
 
 
Рис. Г.16 – Слайд «Вступ» 
154 
 
482. ЧДТУ 252485.010 90-01 120  
 
 
 
Рис. Г.17 – Слайд «Вступ» 
 
 
Рис. Г.18 – Слайд «Вступ» 
155 
 
482. ЧДТУ 252485.010 90-01 121  
 
 
 
Рис. Г.19 – Слайд «Вступ» 
 
 
Рис. Г.20 – Слайд «Вступ» 
156 
 
482. ЧДТУ 252485.010 90-01 122  
 
 
 
Рис. Г.21 – Слайд «Вступ» 
 
 
Рис. Г.22 – Слайд «Вступ» 
157 
 
482. ЧДТУ 252485.010 90-01 123  
 
 
 
Рис. Г.23 – Слайд «Вступ» 
 
 
Рис. Г.24 – Слайд «Вступ» 
158 
 
482. ЧДТУ 252485.010 90-01 124  
 
 
 
Рис. Г.25 – Слайд «Вступ» 
 
 
Рис. Г.26 – Слайд «Вступ»  
159
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
