Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9246
Title: Параметрична оптимізація процесів синтезу моделей за результатами спостереження БПЛА
Authors: Метелап, Володимир Володимирович
Євич, Богдан Володимирович
Keywords: машинний зір;глибоке навчання;YOLO;детекція об’єктів;аугментація даних;Pytorch;UML;computer vision;deep learning;YOLO;object detection;data augmentation;Pytorch;UML
Issue Date: 20-Dec-2025
Abstract: АНОТАЦІЯ Євич Б.В. - Програмна реалізація агентної моделі із виявлення небезпечних предметів кваліфікаційна робота магістра з спеціальності 121 - «Інженерія програмного забезпечення» ЧДТУ, м.Черкаси 2025 рік. Магістерська кваліфікаційна робота присвячена розв’язанню актуальної науково-практичної задачі - створенню інтелектуальної моделі для детекції небезпечних об’єктів. Робота фокусується на вирішенні проблеми виявлення в умовах зниженої інформативності вхідних даних, таких як маскування об'єктів та шумові перешкоди. У роботі проведено ґрунтовний аналіз існуючих архітектур глибокого навчання, зокрема сімейства YOLO. Виконано повний цикл інженерного проектування програмного комплексу з використанням UML, включаючи діаграми класів, компонентів та розгортання. Особистий внесок полягає у створенні спеціалізованого набору даних з використанням ефективних методів аугментації (Mosaic-метод) та розробці програмного конвеєра (pipeline) для навчання моделі на базі PyTorch та Ultralytics. В результаті експериментального тестування розроблена модель продемонструвала високу ефективність: середня точність ([email protected]) досягла 99.19%, а швидкість інференсу на цільовому GPU - 23.7 мс. Практичне значення полягає в можливості застосування моделі для створення автоматизованих систем моніторингу в оборонній сфері та цивільному захисті.
ANNOTATION Yevich B.V. - Software implementation of an agent model for detecting dangerous objects. Master's thesis in the field of study 121 - “Software Engineering,” Cherkasy State Technological University, Cherkasy, 2025. This Master's qualification thesis is dedicated to solving an urgent scientific and practical task: the creation of an intelligent model for the detection of hazardous objects. The work focuses on addressing the challenge of detection under conditions of low informational content of input data, such as object masking and noise interference. The thesis provides a thorough analysis of existing deep learning architectures, particularly the YOLO family. A full software engineering design cycle for the training complex was performed using UML, including class, component, and deployment diagrams. The contribution consists of creating a specialized dataset using effective data augmentation methods (Mosaic-method) and developing a software pipeline for model training based on PyTorch and Ultralytics. As a result of experimental testing, the developed model demonstrated high efficiency: the mean Average Precision ([email protected]) reached 99.19%, and the inference speed on the target GPU was 23.7 ms. The practical value lies in the potential application of the model for creating automated monitoring systems in the defense and civil protection sectors
URI: https://er.chdtu.edu.ua/handle/ChSTU/9246
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:
File Description SizeFormat 
Кваліфікаційна робота магістра Євич Богдан Володимирович.pdf
  Restricted Access
9.79 MBAdobe PDFView/Open Request a copy


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
 
 
на тему:  Параметрична оптимізація процесів синтезу моделей за 
результатами спостереження БПЛА 
 
 
Виконав: студент 2 курсу, групи МПЗ-2404 
спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
Студент Євич Б.В. 
 (прізвище та ініціали) 
Керівник Метелап В.В. 
 (прізвище та ініціали) 
Рецензент Захарова М.В. 
 (прізвище та ініціали) 
 
 
 
 
 Черкаси 2025
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем 
Кафедра  програмного забезпечення автоматизованих систем 
Освітній рівень магістр 
Спеціальність 121 «Інженерія програмного забезпечення» 
Освітня програма Інженерія програмного забезпечення 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
                                           С. Голуб  
«___» _______________ 2025 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Євич Богдан Володимирович 
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) Параметрична оптимізація процесів синтезу моделей за 
результатами спостереження БПЛА  
Керівник проекту (роботи) Метелап Володимир Володимирович к.т.н. доцент  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «07» листопад 
2025року №307/03-03 
2. Строк подання студентом проекту (роботи) 16.12.2025 
3. Вхідні дані до проекту (роботи) 
Персональний комп’ютер на базі процесора x64 з графічним прискорювачем серії NVIDIA 
GeForce RTX 4060 для прискорення навчання нейронної мережі. 
Інструментальні засоби розробки: Мова програмування Python 3.12.10, бібліотеки 
комп’ютерного зору (OpenCV) та машинного навчання (PyTorch, Ultralytics). 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань 
Розділ 2 Теоретичні та експериментальні дослідження 
Розділ 3.Впровадження результатів досліджень у практику проектування програмного 
забезпечення інформаційних систем 
Розділ 4 Розробка та тестування програмного забезпечення 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):  
Додаток В - Рис. В.6 - В.42 - Слайди презентації кваліфікаційної роботи 
 
6. Консультанти розділів роботи 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 13.05.2025 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів випускної Примітки 
п/п роботи 
1 Постановка задачі 13.05.2025 виконано 
2 Підготовка завдання 13.05.2025 виконано 
3 Погодження завдання 13.05.2025 виконано 
4 Затвердження завдання 13.05.2025 виконано 
 Основна стадія   
1 Підбір матеріалів 16.05.2025 виконано 
2 Аналіз шляхів вирішення поставленої задачі 17.05.2025 виконано 
3 Розрахунок основних параметрів роботи 01.06.2025 виконано 
4 Вибір кінцевого варіанту проектного рішення 05.06.2025 виконано 
5 Оформлення первісної редакції роботи 06.06.2025 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 01.09.2025 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 04.09.2025 виконано 
кінцевій редакції 
3 Попередній захист роботи 12.12.2025 виконано 
4 Затвердження роботи 12.12.2025 виконано 
5 Рецензування роботи 13.12.2025 виконано 
6 Захист роботи 16.12.2025 виконано 
 
Студент                                           _____________________      Євич Б.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________               Метелап В.В. 
  (підпис)   (прізвище та ініціали) 
АНОТАЦІЯ 
Євич Б.В. - Програмна реалізація агентної моделі із виявлення небезпечних 
предметів кваліфікаційна робота магістра з спеціальності 121 - «Інженерія 
програмного забезпечення» ЧДТУ, м.Черкаси 2025 рік. 
Магістерська кваліфікаційна робота присвячена розв’язанню актуальної 
науково-практичної задачі - створенню інтелектуальної моделі для детекції 
небезпечних об’єктів. Робота фокусується на вирішенні проблеми виявлення в 
умовах зниженої інформативності вхідних даних, таких як маскування об'єктів 
та шумові перешкоди. 
У роботі проведено ґрунтовний аналіз існуючих архітектур глибокого 
навчання, зокрема сімейства YOLO. Виконано повний цикл інженерного 
проектування програмного комплексу з використанням UML, включаючи 
діаграми класів, компонентів та розгортання. 
Особистий внесок полягає у створенні спеціалізованого набору даних з 
використанням ефективних методів аугментації (Mosaic-метод) та розробці 
програмного конвеєра (pipeline) для навчання моделі на базі PyTorch та 
Ultralytics. 
В результаті експериментального тестування розроблена модель 
продемонструвала високу ефективність: середня точність ([email protected]) досягла 
99.19%, а швидкість інференсу на цільовому GPU - 23.7 мс. Практичне значення 
полягає в можливості застосування моделі для створення автоматизованих 
систем моніторингу в оборонній сфері та цивільному захисті. 
Ключові слова: машинний зір, глибоке навчання, YOLO, детекція 
об’єктів, аугментація даних, Pytorch, UML.
ANNOTATION 
Yevich B.V. - Software implementation of an agent model for detecting 
dangerous objects. Master's thesis in the field of study 121 - “Software Engineering,” 
Cherkasy State Technological University, Cherkasy, 2025. 
This Master's qualification thesis is dedicated to solving an urgent scientific and 
practical task: the creation of an intelligent model for the detection of hazardous 
objects. The work focuses on addressing the challenge of detection under conditions of 
low informational content of input data, such as object masking and noise interference. 
The thesis provides a thorough analysis of existing deep learning architectures, 
particularly the YOLO family. A full software engineering design cycle for the training 
complex was performed using UML, including class, component, and deployment 
diagrams. 
The contribution consists of creating a specialized dataset using effective data 
augmentation methods (Mosaic-method) and developing a software pipeline for model 
training based on PyTorch and Ultralytics. 
As a result of experimental testing, the developed model demonstrated high 
efficiency: the mean Average Precision ([email protected]) reached 99.19%, and the inference 
speed on the target GPU was 23.7 ms. The practical value lies in the potential 
application of the model for creating automated monitoring systems in the defense and 
civil protection sectors. 
Keywords: computer vision, deep learning, YOLO, object detection, data 
augmentation, Pytorch, UML .
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
AdamW - Adaptive Moment Estimation with Weight Decay (адаптивна оцінка 
моментів з розпадом ваг, алгоритм оптимізації)  
AI - Artificial Intelligence (штучний інтелект)  
API - Application Programming Interface (інтерфейс прикладного програмування)  
CLI - Command Line Interface (інтерфейс командного рядка)  
CNN - Convolutional Neural Network (згорткова нейронна мережа)  
CUDA - Compute Unified Device Architecture (програмно-апаратна архітектура 
паралельних обчислень від NVIDIA)  
CV - Computer Vision (комп'ютерний зір)  
DFL - Distribution Focal Loss (функція втрат розподіленого фокусування)  
FN - False Negative (хибно-негативне спрацювання, пропуск об'єкта)  
FP - False Positive (хибно-позитивне спрацювання, помилкова детекція)  
FPS - Frames Per Second (кількість кадрів на секунду)  
GPU - Graphics Processing Unit (графічний процесор)  
HSV - Hue, Saturation, Value (колірна модель: тон, насиченість, значення)  
IDE - Integrated Development Environment (інтегроване середовище розробки)  
IoU - Intersection over Union (коефіцієнт перекриття, метрика Жаккара)  
LR - Learning Rate (швидкість/крок навчання нейронної мережі)  
mAP - mean Average Precision (усереднена середня точність)  
ML - Machine Learning (машинне навчання)  
NMS - Non-Maximum Suppression (алгоритм придушення немаксимумів)  
NumPy - Numerical Python (бібліотека мови Python для роботи з багатовимірними 
масивами)  
OOM - Out Of Memory (помилка переповнення пам'яті)  
OpenCV - Open Source Computer Vision Library (бібліотека комп'ютерного зору з 
відкритим вихідним кодом)  
PyTorch - Open source machine learning framework (фреймворк машинного навчання 
з відкритим кодом)  
RAM - Random Access Memory (оперативна пам'ять)  
ReLU - Rectified Linear Unit (функція активації)  
RGB - Red, Green, Blue (адитивна колірна модель)  
SGD - Stochastic Gradient Descent (стохастичний градієнтний спуск)  
SOTA - State-of-the-Art (сучасний рівень розвитку технології)  
TP - True Positive (істинно-позитивне спрацювання)  
Ultralytics - Розробник та підтримка екосистеми YOLO  
UML - Unified Modeling Language (уніфікована мова моделювання)  
VRAM - Video Random Access Memory (відеопам'ять)  
YOLO - You Only Look Once (сімейство архітектур нейронних мереж для детекції 
об’єктів у реальному часі) 
 
ЗМІСТ 
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ..................................... 6 
ВСТУП ............................................................................................................................ 8 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ .................................................................................... 12 
1.1 Оцінка поточних підходів до використання штучного інтелекту та 
комп'ютерного зору для виявлення потенційно небезпечних об’єктів ....... 12 
1.1.1 Порівняльний аналіз сенсорних технологій .............................................. 12 
1.2 Аналіз архітектур нейронних мереж для локалізації об’єктів (YOLO, 
CNN та аналогічні) ................................................................................................. 13 
1.2.2 Еволюція архітектур YOLO та її вплив на детекцію малих об'єктів ...... 16 
1.3 Порівняльна характеристика бібліотек OpenCV, PyTorch, NumPy та 
Ultralytics .................................................................................................................. 17 
1.3.1 Вибір базового фреймворку: PyTorch проти TensorFlow ........................ 17 
1.3.2 Вибір фреймворку реалізації: Ultralytics ................................................... 18 
1.3.3 Допоміжні бібліотеки .................................................................................. 19 
1.4 Виклики локалізації об’єктів при обмеженій інформативності даних .. 20 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ..... 23 
2.1 Теоретичні основи моделювання предметної області ............................... 23 
2.1.1 Теоретичні основи та математична модель Anchor-Free детекції ........... 23 
2.2 Методи Аугментації Даних для Підвищення Стійкості Моделей 
(Геометричні Трансформації, Mosaic-Метод) ................................................... 24 
2.2.1 Теоретичне обґрунтування Mosaic-аугментації ........................................ 25 
2.2.2 Теоретичне обґрунтування Copy-Paste аугментації ................................. 26 
2.3 Експериментальне моделювання з використанням механізмів уваги та 
Anchor-Free детекторів .......................................................................................... 26 
2.3.1 Дослідження функції втрат локалізації (Box Loss) .................................. 27 
2.3.2 Дослідження функції втрат класифікації (Cls Loss) ................................. 27 
2.3.3 Дослідження функції втрат розподілу (DFL Loss) ................................... 28 
ЧДТУ 252481.005 ПЗ 
Змн. Арк. № докум. Підпис Дата 
 Розроб.   Євич Б.В. Параметрична оптимізація Літ. Лист Листів 
 Перевір.        Метелап В.В. процесів синтезу моделей за 3  
Рецензент  Захарова М.В. результатами спостереження 
 Н. Контр.  Півень О.Б. ФІТІС, кафедра ПЗАС,  МПЗ-2404 
БПЛА 
 Затверд.  Голуб С.В. 
2.4 Оцінка метрик якості (Precision, Recall, mAP) ............................................ 28 
2.4.1 Базові метрики: Precision та Recall ............................................................. 28 
2.4.2 Критерій якості: Intersection over Union (IoU) .......................................... 30 
2.4.3 Комплексна метрика: mAP (mean Average Precision) ............................... 30 
2.5 Методи оптимізації синтезу моделей детекції ............................................. 31 
2.5.1 Параметрична оптимізація функції втрат (Loss Landscape Optimization)
 ................................................................................................................................ 31 
2.5.2 Структурна оптимізація архітектури (Architecture Search Optimization) 32 
2.5.3 Стохастична оптимізація простору даних (Data Space Optimization) ..... 32 
2.5.4 Апаратна оптимізація інференсу (Inference Optimization) ....................... 33 
РОЗДІЛ 3.ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ...................................................................................................................... 34 
3.1 Моделювання Предметної Області з Фокусом на Створення Моделі ... 34 
3.1.1 Предметна Область Моделювання. Модель Предметної Області. 
Словник Предметної Області .............................................................................. 34 
3.1.2 Елементи Моделювання Предметної Області .......................................... 35 
3.2 Формування та Аналіз Вимог до Моделі ..................................................... 36 
3.2.1 Формування вимог до програмного забезпечення. Функціональні та 
нефункціональні вимоги ...................................................................................... 36 
3.2.2 Формування вимог за допомогою діаграми прецедентів ........................ 40 
3.3 Архітектурне Проектування Моделі ............................................................. 41 
3.3.1 Діаграми Класів та Пакетів ......................................................................... 42 
3.3.2 Діаграми Компонентів та Розгортання ...................................................... 44 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ....................................................................................................... 48 
4.1 Розробка програмного комплексу ................................................................. 48 
4.1.1 Обґрунтування вибору засобів реалізації .................................................. 48 
4.1.2 Опис структурної (функціональної) схеми ............................................... 49 
4.1.3. Опис логічної схеми системи .................................................................... 51 
4.1.4 Розробка бази даних .................................................................................... 53 
4.1.5 Розробка інтерфейсу користувача .............................................................. 54 
4.1.6 Опис розробки програмних компонентів .................................................. 55 
4.1.7 Реалізація механізмів структурної оптимізації ......................................... 55 
4.2 Тестування та аналіз результатів навчання ............................................... 56 
4.2.1 Середовище та методологія тестування .................................................... 57
ЧДТУ 252481.005 ПЗ 
Змн. Арк. № докум. Підпис Дата 
     
4.2.2 Аналіз динаміки навчання .......................................................................... 57 
4.2.3 Аналіз ефективності фінальної моделі ...................................................... 58 
4.2.4 Аналіз кривих Precision-Recall (P-R) ......................................................... 60 
4.2.5 Аналіз характеристик набору даних .......................................................... 63 
4.2.6 Приймальне тестування ............................................................................... 65 
ВИСНОВОК ................................................................................................................. 67 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................ 69 
ДОДАТОК А ................................................................................................................ 74 
ДОДАТОК Б ................................................................................................................ 76 
ДОДАТОК В ................................................................................................................ 84 
 
ЧДТУ 252481.005 ПЗ 
Змн. Арк. № докум. Підпис Дата 
     
ЧДТУ 252481.005 ПЗ 
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ 
AdamW - Adaptive Moment Estimation with Weight Decay (адаптивна оцінка 
моментів з розпадом ваг, алгоритм оптимізації)  
AI - Artificial Intelligence (штучний інтелект)  
API - Application Programming Interface (інтерфейс прикладного програмування)  
CLI - Command Line Interface (інтерфейс командного рядка)  
CNN - Convolutional Neural Network (згорткова нейронна мережа)  
CUDA - Compute Unified Device Architecture (програмно-апаратна архітектура 
паралельних обчислень від NVIDIA)  
CV - Computer Vision (комп'ютерний зір)  
DFL - Distribution Focal Loss (функція втрат розподіленого фокусування)  
FN - False Negative (хибно-негативне спрацювання, пропуск об'єкта)  
FP - False Positive (хибно-позитивне спрацювання, помилкова детекція)  
FPS - Frames Per Second (кількість кадрів на секунду)  
GPU - Graphics Processing Unit (графічний процесор)  
HSV - Hue, Saturation, Value (колірна модель: тон, насиченість, значення)  
IDE - Integrated Development Environment (інтегроване середовище розробки)  
IoU - Intersection over Union (коефіцієнт перекриття, метрика Жаккара)  
LR - Learning Rate (швидкість/крок навчання нейронної мережі)  
mAP - mean Average Precision (усереднена середня точність)  
ML - Machine Learning (машинне навчання)  
NMS - Non-Maximum Suppression (алгоритм придушення немаксимумів)  
NumPy - Numerical Python (бібліотека мови Python для роботи з багатовимірними 
масивами)  
OOM - Out Of Memory (помилка переповнення пам'яті)  
OpenCV - Open Source Computer Vision Library (бібліотека комп'ютерного зору з 
відкритим вихідним кодом)  
PyTorch - Open source machine learning framework (фреймворк машинного 
навчання з відкритим кодом)  
6 
ЧДТУ 252481.005 ПЗ 
RAM - Random Access Memory (оперативна пам'ять)  
ReLU - Rectified Linear Unit (функція активації)  
RGB - Red, Green, Blue (адитивна колірна модель)  
SGD - Stochastic Gradient Descent (стохастичний градієнтний спуск)  
SOTA - State-of-the-Art (сучасний рівень розвитку технології)  
TP - True Positive (істинно-позитивне спрацювання)  
Ultralytics - Розробник та підтримка екосистеми YOLO  
UML - Unified Modeling Language (уніфікована мова моделювання)  
VRAM - Video Random Access Memory (відеопам'ять)  
YOLO - You Only Look Once (сімейство архітектур нейронних мереж для детекції 
об’єктів у реальному часі) 
 
 
7 
ЧДТУ 252481.005 ПЗ 
ВСТУП 
Актуальність. теми. Дана розробка кваліфікаційної робота виконана в 
межах спеціальності 121 «Інженерія програмного забезпечення». Вона 
демонструє практичне застосування навичок проектування складних 
програмних систем та аналізу предметної області, відповідаючи чинним освітнім 
стандартам. Усі експерименти базуються на відкритих даних, що гарантує 
прозорість та можливість відтворення отриманих результатів. 
Сьогодні технології комп'ютерного зору вийшли далеко за межі 
теоретичних розробок і стали реальним інструментом безпеки. Особливо гостро 
це питання стоїть у контексті виявлення вибухонебезпечних предметів. В умовах 
сучасних військових конфліктів критично важливою стала задача 
автоматизованого пошуку протипіхотних мін, зокрема малогабаритних 
фугасних боєприпасів. 
Складність роботи з такими об’єктами зумовлена їх фізичними 
параметрами: вони малі, мають специфічну форму та часто візуально зливаються 
з травою чи ґрунтом. Якщо додати до цього погане освітлення або низьку якість 
зображення з камери, задача ідентифікації стає викликом навіть для 
досвідченого оператора, не кажучи вже про автоматичні алгоритми. Статистика 
міжнародних організацій, зокрема ООН, свідчить про тисячі постраждалих 
щороку, що робить розробку надійних систем моніторингу не просто технічною, 
а гуманітарною необхідністю. 
Метою роботи є створення програмної системи та моделі, здатної 
розпізнавати замасковані небезпечні об'єкти за допомогою методів штучного 
інтелекту, навіть у складних візуальних умовах, коли інформативність вхідних 
даних обмежена, провести оптимізацію системи. 
Для реалізації цієї мети було визначено такі завдання: 
1 Дослідити існуючі підходи до детекції об’єктів, зокрема малих об'єктів 
складної форми;  
2 Оцінити можливості архітектури yolo та інструментарію OpenCV, 
PyTorch і Ultralytics для реалізації та дослідження системи; 
8 
ЧДТУ 252481.005 ПЗ 
3 Розробити пз та провести експерименти з моделювання предметної 
області, зосередившись на методах аугментації даних для покращення 
«зору» моделі; 
4 Спроектувати архітектуру програмного комплексу: від формування 
вимог та uml-діаграм до вибору технологічного стека; 
5 Виконати тестування розробленого пз та моделі зокрема; 
6 Провести аналіз отриманих результатів; 
7 Обґрунтувати наукову новизну та можливість практичного 
застосування отриманого рішення. 
Об'єктом досліджень є процеси проектування, конструювання і 
застосування програмних систем та штучного інтелекту для вирішення 
гуманітарних радач з визначення небезпечних предметів.  
Предметом досліджень є методи та алгоритми параметричної оптимізації 
архітектури нейронних мереж, програмні засоби підготовки та валідації вхідних 
даних, а також стратегії апаратної адаптації програмного забезпечення до 
обмежених обчислювальних ресурсів, враховуючи вимоги до швидкості та 
точності визначення малих об'єктів асиметричної форми. 
У роботі використано комплекс методів: теоретичний аналіз літератури, 
методи обробробки та синтезу зображень для формування массиву вхідних 
даних, експериментальне моделювання (для навчання мережі), системний аналіз 
(для проектування ПЗ) та статистичні методи оцінки якості. Програмна 
реалізація виконана мовою Python із залученням бібліотек PyTorch, Ultralytics та 
OpenCV. 
Наукова новизна одержаних результатів полягає у вирішенні задачі 
високоточної детекції малогабаритних об'єктів складної (асиметричної) форми в 
умовах зниженої інформативності шляхом синтезу модифікованої архітектури 
нейромережі та стратегії структурної та параметричної оптимізації моделі. 
1 Удосконалено метод одностадійної детекції об'єктів (Single-Stage 
Object Detection): На відміну від класичних підходів (Anchor-Based), 
обґрунтовано застосування Anchor-Free архітектури з інтегрованими 
9 
ЧДТУ 252481.005 ПЗ 
механізмами просторової уваги (Spatial Attention). Доведено, що 
перехід до прямої регресії центру мас об'єкта дозволяє мінімізувати 
похибку локалізації для цілей з асиметричною геометрією, навідміну 
від підход з якорями. 
2 Набуло подальшого розвитку математичне забезпечення процесу 
навчання: Запропоновано модифікацію функції втрат шляхом 
ребалансування вагових коефіцієнтів (Box Loss вага = 15.0). Це, у 
поєднанні з функцією Distribution Focal Loss (DFL), дозволяє 
моделювати межі об'єкта, як розподіл ймовірностей, забезпечуючи 
стабільну детекцію об'єктів із розмитими контурами (ефект 
маскування). 
3 Застосовано трирівневу стратегію структурної оптимізації: Розроблено 
комплексний підхід, що включає динамічну апаратну адаптацію до 
ресурсів GPU, автоматизовану валідацію структури даних та 
алгоритмічну оптимізацію формування висновку. Це дозволило 
забезпечити виконання вимог реального часу (<50 мс) на обмежених 
обчислювальних ресурсах. 
4 Удосконалено метод формування простору ознак: Обґрунтовано 
ефективність використання комбінованих методів стохастичної 
аугментації (Mosaic + Mixup) для класу задач Small Object Detection, що 
дозволило компенсувати критичний дефіцит реальних навчальних 
даних. 
Практичне значення. Розроблена модель може стати ядром для 
автоматизованих систем моніторингу територій, допомагаючи саперам та 
військовим у виявленні прихованих загроз. 
Структура роботи. Робота складається з чотирьох розділів. Перший 
присвячено аналізу існуючих технологій. У другому описано теоретичні засади 
та хід експериментів. Третій розділ фокусується на інженерному проектуванні 
системи. Четвертий описує безпосередню розробку, тестування та аналіз 
ефективності моделі. 
10 
ЧДТУ 252481.005 ПЗ 
Методи дослідження. Для розв’язання поставлених задач у роботі 
використано комплексний методологічний підхід, що поєднує методи штучного 
інтелекту, математичного моделювання та інженерії програмного забезпечення: 
- методи системного аналізу та порівняльного аналізу - для дослідження 
еволюції архітектур нейронних мереж (YOLOv5, v8, v11) та 
обґрунтування вибору безякірного (Anchor-Free) підходу; 
- методи машинного навчання (Machine Learning) - для синтезу та 
навчання згорткової нейронної мережі, вирішення задач регресії 
координат (Bounding Box Regression) та класифікації об'єктів; 
- методи математичної оптимізації - для налаштування ландшафту 
функції втрат (Loss Landscape Optimization) та мінімізації помилки 
локалізації через алгоритм градієнтного спуску; 
- методи обробки зображень (Computer Vision) - для попередньої 
обробки даних, аугментації навчальної вибірки (Mosaic, Affine 
transformations) та нормалізації вхідного потоку; 
- умпіричні методи дослідження - для проведення обчислювальних 
експериментів, оцінки метрик якості (mAP, Precision, Recall) та 
валідації роботи системи на тестових наборах даних; 
- методи об'єктно-орієнтованого проектування - для розробки 
архітектури програмного комплексу, реалізації модульної структури та 
забезпечення масштабованості системи; 
 
11 
ЧДТУ 252481.005 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
У даному розділі проведено аналіз сучасних технологічних підходів до 
виявлення вибухонебезпечних предметів. Основний акцент зроблено на виборі 
оптимального поєднання сенсорних технологій та алгоритмів комп'ютерного 
зору, здатних забезпечити роботу в режимі реального часу. 
1.1 Оцінка поточних підходів до використання штучного інтелекту та 
комп'ютерного зору для виявлення потенційно небезпечних об’єктів 
Сучасні дослідження у сфері безпеки все частіше спираються на алгоритми 
глибокого навчання для локалізації вибухових пристроїв. На практиці це часто 
реалізується через інтеграцію нейромереж із роботизованими платформами, що 
дозволяє сканувати поверхню в автономному режимі. 
Існує кілька напрямків розвитку таких систем. Частина дослідників 
фокусується на аналізі магнітних сигнатур за допомогою згорткових мереж 
(CNN), інші - на обробці зображень в інфрачервоному спектрі, що дозволяє 
виявляти теплові аномалії. Також перспективним є використання синтетичних 
даних для тренування моделей, оскільки це частково вирішує проблему браку 
реальних фотографій вибухонебезпечних предметів. Однак загальний прогрес у 
класифікації вимагає адаптації алгоритмів під специфіку конкретних загроз, 
таких як малопомітні інженерні боєприпаси. 
1.1.1 Порівняльний аналіз сенсорних технологій 
Аналіз поточних підходів показує, що вибір методу детекції тісно 
пов'язаний з типом сенсора, що використовується. Для виявлення небезпечних 
об'єктів, таких як поверхневого залягання, найчастіше застосовуються три типи 
технологій: 
1 Георадари (GPR) та магнітометри. Ці прилади є стандартом для пошуку 
металевих об'єктів. Проте для досліджуваного класу об'єктів вони 
малоефективні, оскільки корпус цієї міни виготовлено з пластику, а 
12 
ЧДТУ 252481.005 ПЗ 
вміст металу в ній мінімальний (лише детонатор). Крім того, 
сканування георадаром вимагає безпосереднього контакту з поверхнею 
та є повільним процесом. 
2 Тепловізори. Метод базується на фіксації різниці температур між 
пластиковим об'єктом та ґрунтом. Хоча це дозволяє працювати в 
умовах слабкого освітлення, ефективність методу є нестабільною і 
критично залежить від часу доби та погодних умов. 
3 Оптичні сенсори (RGB-камери). Це найбільш економічно доцільний та 
універсальний варіант, придатний для використання на масових 
моделях БПЛА. 
Обґрунтування: У роботі прийнято рішення використовувати оптичний 
метод. Головні недоліки цього підходу - чутливість до освітлення та маскування 
- будуть нівельовані не апаратним шляхом, а за допомогою алгоритмічної 
оптимізації нейромережі та розширених методів аугментації даних. 
1.2 Аналіз архітектур нейронних мереж для локалізації об’єктів 
(YOLO, CNN та аналогічні) 
Архітектури для локалізації об’єктів еволюціонували, пропонуючи баланс 
між швидкістю та точністю, особливо в умовах обмеженої видимості. 
Спеціалізована версія YOLOv7 адаптована для слабого освітлення шляхом 
аналізу характеристик зображень та впровадження стратегій оптимізації. Інша 
модель на базі YOLOv11s, призначена для безпілотників, інтегрує модулі для 
ефективності в темряві, забезпечуючи компроміс між продуктивністю та 
ресурсами. Алгоритм LLD-YOLO демонструє переваги в детекції при низькій 
освітленості та тумані, підтверджуючи адаптивність до складних середовищ. 
En-YOLO покращує точність у темряві за рахунок подвійних мереж, що 
робить його придатним для моніторингу. Огляд еволюції YOLO підкреслює 
модульну структуру з backbone для витягування ознак та head для прогнозів. 
13 
ЧДТУ 252481.005 ПЗ 
Варіанти YOLO проявляють стійкість у слабкому світлі завдяки архітектурним 
елементам для захоплення деталей. Легка версія 3L-YOLO включає 
багатошарову екстракцію ознак для ефективної обробки. Ці рішення дозволяють 
адаптувати моделі до детекції специфічного класу загроз з мінімальними 
даними. 
1.2.1 Порівняльний аналіз еволюції архітектур YOLO (v5, v8, v11) та 
обґрунтування вибору 
При проектуванні системи детекції замаскованих цілей було проведено 
аналіз еволюції архітектур сімейства YOLO. Хоча всі вони належать до класу 
одностадійних детекторів, між версіями v5, v8 та v11 існують фундаментальні 
архітектурні відмінності, що критично впливають на ефективність виявлення 
малопомітних об'єктів складної форми. 
1 YOLOv5: Парадигма Anchor-Based (Базовий рівень) YOLOv5 тривалий 
час залишалася промисловим стандартом. Її архітектура базується на 
використанні блоків CSP (Cross Stage Partial) та механізмі Anchor Boxes (якорів). 
Принцип роботи: Модель намагається апроксимувати знайдений об'єкт, 
підбираючи найбільш схожий заздалегідь визначений шаблонний прямокутник 
(якір) і коригуючи його розміри. 
Недолік для цільового об'єкта: Предмет пошуку має асиметричну форму 
("метелик") і може лежати під довільним кутом. Вписування такої складної 
геометрії у жорсткі прямокутні якорі призводить до низького показника IoU та 
помилок локалізації. Крім того, якорі погано масштабуються для екстремально 
малих об'єктів. 
2 YOLOv8: Перехід до Anchor-Free та DFL Ця версія ознаменувала зміну 
парадигми, перейшовши до Anchor-Free (безякірного) підходу. 
Архітектурні зміни: Впровадження блоків C2f, які покращують 
градієнтний потік порівняно з CSP. 
14 
ЧДТУ 252481.005 ПЗ 
Перевага: Модель прогнозує центр об'єкта та вектори відстаней до його 
країв, що забезпечує гнучкість для нестандартних форм. 
Функція втрат: Впровадження Distribution Focal Loss (DFL) дозволило 
моделі ефективніше працювати з нечіткими межами об'єктів (проблема 
маскування), моделюючи рамку як розподіл ймовірностей. 
3 YOLOv11: Інтеграція механізмів уваги (Обране рішення) Найновіша 
ітерація архітектури, яка розвиває ідеї v8, фокусуючись на ефективності 
виділення ознак (Feature Extraction). 
Архітектурні зміни: Заміна блоків C2f на C3k2 та впровадження модулів 
C2PSA (Cross Stage Partial with Spatial Attention). 
Критична перевага для задачі: Механізм просторової уваги (Spatial 
Attention) дозволяє моделі фокусуватися на специфічних текстурних ознаках 
об'єкта, ігноруючи фоновий шум (трава, листя). Це вирішує проблему низького 
співвідношення сигнал/шум, характерну для замаскованих мін. 
Ефективність: При меншій кількості параметрів порівняно з v8, v11 
демонструє вищу швидкість інференсу, що є критичним для виконання 
нефункціональної вимоги роботи в реальному часі (< 50 мс). 
Порівняльна характеристика розглянутих версій наведена в Таблиці 1.1. 
 
Таблиця 1.1  
Порівняння архітектур YOLO для задачі детекції малогабаритних 
предметів 
Характеристика YOLOv5 YOLOv8 YOLOv11 
(Обрано) 
Основний блок CSP / C3 C2f C3k2 + C2PSA 
Тип детекції Anchor-Based Anchor-Free Anchor-Free 
Адаптація до форми Низька (жорсткі Висока Висока 
якорі) 
Механізм уваги Відсутній Обмежений Spatial 
Attention 
Робота з маскуванням Слабка Середня (завдяки Висока 
DFL) 
15 
ЧДТУ 252481.005 ПЗ 
 
Висновок: Для розробки системи обрано архітектуру YOLOv11. Вона 
поєднує гнучкість безякірного підходу для малогабаритних предметів з 
передовими механізмами уваги (критично для маскування), забезпечуючи при 
цьому найвищу швидкодію серед аналогів. 
1.2.2 Еволюція архітектур YOLO та її вплив на детекцію малих об'єктів 
Хоча існують спеціалізовані моделі для слабкого освітлення (LLD-YOLO, 
En-YOLO), ключовим для обґрунтування вибору є загальний розвиток 
архітектури YOLO, спрямований на вирішення проблеми детекції малих 
об'єктів. 
- ранні версії (YOLOv1-v2): Ці моделі були революційними у швидкості, 
але мали суттєві проблеми з локалізацією та детекцією малих об'єктів. 
Вони ділили зображення на грубу сітку і могли прогнозувати лише 
обмежену кількість рамок на комірку; 
- YOLOv3-v5: У цих версіях відбувся ключовий прорив. Було 
впроваджено Feature Pyramid Network (FPN) та PANet. Це архітектурне 
рішення дозволяє моделі комбінувати "глибокі" семантичні ознаки (що 
допомагають зрозуміти, що це за об'єкт) з "дрібними" ознаками високої 
роздільної здатності (що допомагають зрозуміти, де точно він 
знаходиться). Саме це дозволило YOLO ефективно детектувати об'єкти 
на різних масштабах. Крім того, у YOLOv5 було вперше інтегровано 
Mosaic-аугментацію безпосередньо у процес навчання, що стало 
критично важливим для покращення детекції малих об'єктів. 
Сучасні версії (YOLOv7, v8, v11): Ці моделі зробили наступний крок, 
перейшовши до Anchor-Free підходу. Замість того, щоб покладатися на набір 
"якорів" (заздалегідь визначених рамок), ці моделі безпосередньо прогнозують 
центр об'єкта та його межі. Це дає два суттєвих плюси для нашої задачі: 1. 
Гнучкість: Модель не обмежена стандартними квадратними рамками і може 
краще адаптуватися до нестандартної, витягнутої форми визначеного об’єкта. 2. 
16 
ЧДТУ 252481.005 ПЗ 
Покращена функція втрат: Це дозволило інтегрувати нові функції втрат, такі як 
Distribution Focal Loss (DFL), які допомагають моделі краще обробляти нечіткі 
та частково перекриті межі об'єктів. 
1.3 Порівняльна характеристика бібліотек OpenCV, PyTorch, NumPy 
та Ultralytics 
Інструменти для побудови AI-моделей відрізняються функціоналом та 
сферою застосування. TensorFlow та PyTorch підходять для складних розробок, 
тоді як OpenCV виділяється швидкістю в реальному часі. PyTorch пропонує 
гнучкість для досліджень, відрізняючись від комп'ютерних зорових бібліотек. 
OpenCV інтегрується з NumPy, TensorFlow та PyTorch для розширення 
можливостей. Пакети як Supervision, OpenCV та Torchvision полегшують роботу 
з моделями. 
YOLOv5 від Ultralytics забезпечує простоту в детекції та сегментації. 
Трекінгові алгоритми BotSort та ByteTrack потребують тестування для 
конкретних задач. Різниці в впевненості детекції між Ultralytics та OpenCV 
вимагають перевірки коду. Ultralytics адаптує роботи інших для зручності. 
ONNX може бути повільнішим за PyTorch через розмір моделі. YOLOv5 з 
OpenCV DNN додає переваги в C++ та Python. 
1.3.1 Вибір базового фреймворку: PyTorch проти TensorFlow 
На ринку фреймворків глибокого навчання домінують два основні 
конкуренти: PyTorch (від Meta) та TensorFlow (від Google). 
- TensorFlow (з Keras): Цей фреймворк традиційно домінував у 
промисловій розробці. Його ключова особливість – статичний 
обчислювальний граф. Розробник спочатку визначає всю архітектуру 
моделі, компілює її, і лише потім "проганяє" дані. Це забезпечує високу 
оптимізацію та неперевершену продуктивність при розгортанні 
(deployment), особливо на мобільних пристроях (TFLite) та серверах 
(TFServing). Однак, такий підхід робить процес досліджень (research) 
17 
ЧДТУ 252481.005 ПЗ 
та налагодження (debugging) складним, оскільки важко інспектувати 
проміжні результати "на льоту"; 
- PyTorch: Цей фреймворк завоював популярність у дослідницькій 
спільноті завдяки підходу "Pythonic" та використанню динамічного 
обчислювального графа (Eager Execution). Кожна операція виконується 
негайно. Це дозволяє розробнику легко налагоджувати код, перевіряти 
проміжні стани тензорів та гнучко змінювати архітектуру. Для 
кваліфікаційної роботи, яка має значну дослідницьку складову (Розділ 
2), ця гнучкість є вирішальною. 
Обґрунтування: Для даної роботи, де головним завданням є 
експериментальне дослідження аугментацій та гіперпараметрів, PyTorch було 
обрано як основний фреймворк завдяки його гнучкості та простоті 
налагодження. 
1.3.2 Вибір фреймворку реалізації: Ultralytics 
Маючи PyTorch як базу, існує вибір: реалізовувати архітектуру YOLO "з нуля" 
або використати високорівневий фреймворк. 
- реалізація "з нуля": Вимагає від інженера ручного написання сотень 
рядків коду для опису кожного шару Backbone, Neck та Head, реалізації 
функцій втрат (CIoU, DFL) та написання складного конвеєра навчання 
(training loop); 
- використання Ultralytics: Це інженерний акселератор. Компанія 
Ultralytics надає SOTA (State-of-the-Art) реалізацію архітектури YOLO 
(включаючи YOLOv8 та YOLOv11), яка вже оптимізована, 
протестована та підтримується. 
Обґрунтування: З точки зору інженерії програмного забезпечення, вибір 
Ultralytics є прагматичним рішенням. Він дозволяє абстрагуватися від 
18 
ЧДТУ 252481.005 ПЗ 
низькорівневої реалізації згорткових шарів і зосередити зусилля на більш 
важливих етапах проекту: 
1 Інженерія даних (Розділ 2: збір датасету, аугментація). 
2 Проектування системи (Розділ 3: розробка архітектури ПЗ). 
3 Експериментальне налаштування (Розділ 4: оптимізація 
гіперпараметрів). 
1.3.3 Допоміжні бібліотеки 
- NumPy: Обрано як стандарт де-факто для будь-яких чисельних 
операцій в Python. Він використовується для маніпуляцій з масивами 
координат обмежувальних рамок перед їхньою подачею у модель; 
- OpenCV: Обрано як основну бібліотеку комп'ютерного зору для 
допоміжних завдань: читання та запис зображень (cv2.imread), 
візуалізація результатів у Розділі 4 (cv2.rectangle, cv2.putText) та 
застосування деяких геометричних аугментацій. 
 
Таблиця 1.2  
Характеристика бібліотек 
Бібліотека Ключові Сильні сторони Обмеження 
можливості для моделювання 
OpenCV Аналіз Висока Менша гнучкість 
зображень, швидкість, у навчанні 
реальний час сумісність 
PyTorch Динамічні моделі, Адаптивність, Залежність від 
GPU прискорення ресурсів 
NumPy Масиви, Ефективна Відсутність 
обчислення обробка даних візуальних 
інструментів 
19 
ЧДТУ 252481.005 ПЗ 
Ultralytics YOLO-версії, Зручність Залежність від 
тренування інтерфейсу базових 
фреймворків 
 
1.4 Виклики локалізації об’єктів при обмеженій інформативності 
даних 
Проблема детекції об'єктів в умовах зниженої інформативності, особливо 
для таких цілей з нерегулярною геометрією, є однією з найскладніших у 
сучасному комп'ютерному зорі. Недостатньо просто застосувати стандартну 
модель YOLO; необхідно чітко ідентифікувати та розробити стратегії для 
подолання наступних ключових викликів: 
- малий відносний розмір об'єкта (Small Object Scale): Досліджуваний 
зразок має малі фізичні розміри (до 12 см). При зйомці з висоти (напр., 
з БПЛА або з людського зросту) об'єкт займає лише незначну частину 
зображення (напр., 20x20 пікселів на Full HD кадрі). Для згорткових 
мереж це є викликом, оскільки ключові ознаки об'єкта можуть бути 
"втрачені" під час багаторазових операцій пулінгу (down-sampling) у 
Backbone моделі; 
- оклюзія та маскування (Occlusion & Camouflage): Це головна проблема 
"зниженої інформативності". Об'єкт інтересу має захисне забарвлення 
для маскування у природному середовищі (трава, листя, ґрунт). Модель 
має навчитися відрізняти текстуру та форму міни від візуально схожого 
фону (напр., мокрий камінь або осінній лист). Це вимагає від моделі 
здатності до вивчення дуже тонких, нетривіальних ознак; 
20 
ЧДТУ 252481.005 ПЗ 
- варіативність умов середовища (Environmental Variability): Модель 
повинна бути інваріантною (стійкою) до змін умов освітлення (пряме 
сонячне світло, тінь, сутінки), погодних умов (дощ, туман) та стану 
об'єкта (брудний, мокрий, частково присипаний землею). Це створює 
величезну варіативність вхідних даних; 
- дисбаланс даних (Data Imbalance): У реальному сценарії моніторингу, 
переважна більшість кадрів (напр., 99%) не міститиме жодної міни. Це 
створює сильний дисбаланс класів ("фон" проти "міни"). Якщо це не 
врахувати, модель швидко "злінується" і для мінімізації втрат почне 
завжди прогнозувати "фон", що призведе до катастрофічно низької 
повноти (Recall) – тобто, пропуску реальних загроз. 
Вирішення цих чотирьох ключових викликів є центральним завданням 
теоретичних досліджень (аугментація, функції втрат) у Розділі 2 та інженерного 
проектування у Розділі 3. 
 
21 
ЧДТУ 252481.005 ПЗ 
ВИСНОВОК ДО РОЗДІЛУ 1 
Проведений аналіз існуючих методів та архітектур підтвердив, що для 
задачі детекції малих об'єктів у складному середовищі найбільш ефективним 
рішенням є архітектури сімейства YOLO, які забезпечують оптимальний баланс 
між швидкістю та точністю. Визначено, що ключовим викликом є детекція в 
умовах зниженої інформативності (погане освітлення, маскування). Обраний 
технологічний стек, що складається з PyTorch та Ultralytics, забезпечує необхідну 
гнучкість для подальших досліджень. Наступним кроком є проведення 
теоретичних та експериментальних досліджень (Розділ 2) для підвищення 
стійкості моделі в цих складних умовах. 
 
22 
ЧДТУ 252481.005 ПЗ 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
У цьому розділі розглядаються базові принципи та практичні 
випробування для побудови моделі детекції, з акцентом на адаптацію до 
специфічних умов. Дослідження спрямоване на формування стійкої структури, 
здатної обробляти обмежені дані, з урахуванням особливостей об’єкта. 
2.1 Теоретичні основи моделювання предметної області 
Теоретичною основою моделювання є не лише опис фізичних 
властивостей шуканого патерну, але й вибір обчислювальної парадигми, здатної 
ці властивості ефективно розпізнати. Ключовим архітектурним рішенням, яке 
досліджується в даній роботі, є використання Anchor-Free (безякірного) підходу 
до детекції. 
У контексті глибокого навчання, теоретичні засади включають ієрархічну 
екстракцію ознак, де базові шари фіксують прості патерни, а вищі – комплексні 
структури. Для даного типу даних це означає акцент на масштабування та 
ротацію, оскільки об’єкт може з’являтися в різних орієнтаціях. Підхід з 
генеративними інструментами для збагачення даних теоретично розширює 
варіативність, роблячи модель менш чутливою до реальних обмежень. Загалом, 
теоретична модель повинна інтегрувати доменні знання про вибухові пристрої з 
математичними функціями втрат для оптимізації. 
2.1.1 Теоретичні основи та математична модель Anchor-Free детекції 
Теоретичною основою обраної моделі є відмова від евристичного підбору 
якорів на користь прямої регресії параметрів об'єкта. Ключовою інновацією, що 
дозволяє знаходити замасковані міни, є використання функції втрат Distribution 
Focal Loss (DFL). 
23 
ЧДТУ 252481.005 ПЗ 
Проблема чітких меж: У класичному навчанні модель намагається 
передбачити чітку межу об'єкта (детерміноване число). Однак для цілі, частково 
схованої травою, "чіткої" межі візуально не існує. Її контур розмитий, що 
призводить до нестабільності навчання при використанні звичайних функцій 
втрат. 
Рішення через DFL: Метод DFL моделює координати рамки не як число, а 
як розподіл ймовірностей навколо істинної межі. Математично це дозволяє 
мережі виразити "ступінь впевненості" у розташуванні межі об'єкта. 
 
������(��! , ��!"#) = −((��!"# − ��)������(��!) + (�� − ��!)������(��!"#),	 (2.1) 
 
DFL - Distribution Focal Loss 
�� - істинна координата краю рамки. 
��!, ��!"# - найближчі дискретні значення координат (пікселів). 
��!, ��!"#  - ймовірності того, що край знаходиться в точці ��! та ��!"#. 
Це дозволяє алгоритму оптимізації знаходити найбільш вірогідний контур 
навіть при частковому перекритті об'єкта, що є критичним для умов зниженої 
інформативності. 
2.2 Методи Аугментації Даних для Підвищення Стійкості Моделей 
(Геометричні Трансформації, Mosaic-Метод) 
Аугментація є ключовим експериментальним методом для вирішення 
викликів, визначених у Розділі 1.4 (малий розмір, маскування, дисбаланс даних). 
Замість простих геометричних трансформацій (поворот, зсув), дане дослідження 
фокусується на більш складних стратегіях змішування зображень, зокрема 
Mosaic та Copy-Paste. 
Експериментальні випробування підтверджують ефективність аугментації 
для прихованих об’єктів, де оптимізовані політики підвищують середню 
точність до 90%. Генеративні підходи, включаючи штучне створення 
реалістичних зразків, розв’язують проблему обмежених датасетів, роблячи 
24 
ЧДТУ 252481.005 ПЗ 
модель стійкішою до шумів і варіацій. Для підвищення стійкості розпізнавання 
це означає комбінацію колірних коригувань з геометричними змінами, щоб 
імітувати польові умови. 
2.2.1 Теоретичне обґрунтування Mosaic-аугментації 
Mosaic-метод, вперше представлений у YOLOv4, є стратегією, що 
комбінує чотири різні навчальні зображення в одне (див. рис. 2.1). Зображення 
обрізаються, масштабуються та поєднуються, змушуючи модель навчатися в 
набагато складніших умовах. 
 
 
Рис. 2.1. Приклад Mosaic-аугментації 
Теоретична користь цього методу для нашої задачі є потрійною: 
25 
ЧДТУ 252481.005 ПЗ 
- покращена детекція малих об'єктів: (Вирішення проблеми з Розділу 
1.4). При масштабуванні та комбінуванні чотирьох зображень, об'єкти 
(міни) з'являються у значно меншому масштабі, ніж в оригіналі. Це 
змушує модель "вдивлятися" і вчитися детектувати об'єкти розміром у 
кілька пікселів; 
- декореляція контексту (Context De-correlation): (Вирішення проблеми 
маскування). Об'єкт може бути розміщений у неприродному контексті 
(напр., поруч із фрагментом асфальту з іншого зображення). Це змушує 
модель навчатися розпізнавати внутрішні ознаки самої міни (її 
текстуру, форму), а не покладатися на її типове оточення ("міна завжди 
лежить на траві"); 
- покращення Batch Normalization: Модель за один крок бачить 4 різні 
сцени, що урізноманітнює статистику для шарів Batch Normalization. 
2.2.2 Теоретичне обґрунтування Copy-Paste аугментації 
Аугментація Copy-Paste (також використана у конфігурації Рис. 4.1) є 
прямим вирішенням проблеми дисбалансу даних. Принцип роботи: Алгоритм 
вирізає екземпляри об'єктів (міни) з одних зображень та вставляє їх у випадкові 
місця на інших зображеннях (фонових). Перевага: Це дозволяє штучно та 
контрольовано збільшити кількість об'єктів на навчальних зображеннях. Замість 
того, щоб мати багато зображень "фону" і мало зображень з мінами, ми можемо 
згенерувати тисячі нових прикладів, де модель бачить об'єкти у різноманітних, 
несподіваних локаціях та контекстах, що значно підвищує її стійкість 
(робастність). 
2.3 Експериментальне моделювання з використанням механізмів 
уваги та Anchor-Free детекторів 
26 
ЧДТУ 252481.005 ПЗ 
Експериментальне моделювання полягає не лише у виборі архітектури 
(Anchor-Free), але й у теоретичному обґрунтуванні та налаштуванні 
комбінованої функції втрат (Loss Function). Загальна втрата L обчислюється як 
зважена сума трьох окремих компонентів, і експериментальний підбір цих ваг 
(як показано на Рис. 4.1) є ядром дослідження. 
 
��$%$&' = ��(%) × ��(%) +��*'+ × ��*'+ +��,-' × ��,-' 2.2 
 
��$%$&' - загальне значення втрат (Total Loss), яке оптимізатор намагається 
мінімізувати. 
��(%) (Box Loss) - локалізації рамки (наскільки точно рамка охоплює міну). 
Базується на метриці CIoU. 
��*'+ (Class Loss) - помилка класифікації (чи правильно модель визначила, 
що це "міна", а не "фон"). 
��,-' (Distribution Focal Loss) - помилка розподілу (допомагає уточнити 
межі об'єкта, якщо вони розмиті). 
2.3.1 Дослідження функції втрат локалізації (Box Loss) 
- теорія: Проста L1 або L2 втрата є неефективною для обмежувальних 
рамок. У сучасних моделях YOLO використовується CIoU (Complete 
IoU) або SIoU (Structured IoU) Loss. Ці метрики штрафують модель не 
лише за неправильне перекриття (IoU), але й за відстань між центрами 
рамок та різницю у співвідношенні сторін; 
- експериментальний вибір (w = 15.0): У даній роботі для L_box 
встановлено найвищу вагу (w=15.0). Це свідоме інженерне рішення. У 
задачі критичної безпеки точна локалізація (знання, де саме 
знаходиться міна) є пріоритетнішою за класифікацію. Висока вага 
змушує оптимізатор (AdamW) приділяти максимальну увагу точності 
координат рамки. 
2.3.2 Дослідження функції втрат класифікації (Cls Loss) 
27 
ЧДТУ 252481.005 ПЗ 
- теорія: Для класифікації використовується BCEWithLogitsLoss (Binary 
Cross-Entropy), яка ефективно обробляє ймовірності для кожного 
класу; 
- експериментальний вибір (w = 0.15): Навпаки, вага для L_cls 
встановлена на надзвичайно низький рівень (w=0.15). Це 
обґрунтовується тим, що наша задача є однокласовою (single-class 
detection). Моделі не потрібно розрізняти "міну" від "собаки" чи 
"автомобіля", а лише "міну" від "фону". Це легка задача, тому ми не 
дозволяємо моделі витрачати на неї багато обчислювальних зусиль, 
змушуючи її фокусуватися на складніших завданнях (L_box та L_dfl). 
2.3.3 Дослідження функції втрат розподілу (DFL Loss) 
- теорія: Distribution Focal Loss (DFL) є ключовим теоретичним 
компонентом, пов'язаним з Anchor-Free детекцією. Замість того, щоб 
прогнозувати точну координату як одне число (напр., x=25.5), DFL 
змушує модель прогнозувати розподіл ймовірностей навколо цієї 
координати (напр., ймовірність 10% для пікселя 24, 80% для 25, 10% 
для 26); 
- експериментальний вибір (w = 4.0): Ця функція є критично важливою 
для вирішення проблеми маскування та оклюзії. Вона дозволяє моделі 
виражати "невпевненість" щодо точного розташування краю 
замаскованого об'єкта. Встановлення значної ваги (w=4.0) покращує 
якість рамок для об'єктів з нечіткими межами, що є типовим для 
замаскованих об'єктів у траві чи листі. 
2.4 Оцінка метрик якості (Precision, Recall, mAP) 
Для об'єктивної оцінки ефективності експериментальних моделей, 
розроблених у Розділі 4, необхідно чітко визначити теоретичну базу метрик 
якості. Вибір метрик безпосередньо залежить від пріоритетів задачі – у нашому 
випадку, це мінімізація пропуску небезпечних об'єктів. 
2.4.1 Базові метрики: Precision та Recall 
28 
ЧДТУ 252481.005 ПЗ 
Основою для всіх метрик детекції є чотири показники, отримані при 
порівнянні прогнозів (Predicted) з істинною розміткою (Ground Truth): 
- True Positive (TP): Випадок, коли алгоритм правильно знайшла міну; 
- False Positive (FP): Ситуація, за якої система помилково прийняла фон 
(напр., камінь) за міну; 
- False Negative (FN): Помилка, при якій мережа пропустила існуючу 
міну; 
- True Negative (TN): Зазвичай виключається з розгляду в задачах 
детекції об'єктів, оскільки "фон" не є об'єктом. 
З цих показників виводяться дві фундаментальні метрики: 
1 Точність (Precision): 
 
���� (2.3) 
������������������ = 	 	
���� + ����
 
TP (True Positive) — істинно-позитивне спрацювання (модель сказала " 
об’єкт", і це справді наш об’єкт). 
FP(False Positive) — хибно-позитивне спрацювання (модель сказала 
"об’єкт", а це камінь або трава). 
- що вимірює: Відсоток правильних детекцій серед усіх знайдених 
моделлю; 
- інтерпретація для задачі: Наскільки можна довіряти сигналу моделі? 
Висока точність означає низький рівень хибних тривог. 
2 Повнота (Recall): 
 
���� 	 (2.4) 
������������ = 	
���� + ����
 
TP (True Positive) — істинно-позитивне спрацювання (знайдена міна).  
29 
ЧДТУ 252481.005 ПЗ 
FN (False Negative) — хибно-негативне спрацювання (пропущена міна, 
найнебезпечніша помилка). 
- що вимірює: Відсоток знайдених мін серед усіх реально існуючих мін; 
- інтерпретація для задачі: Це найважливіша метрика для даної КРМ. 
Вона вимірює, скільки небезпечних об'єктів ми пропустили. У задачі, 
пов'язаній з безпекою, ми можемо толерувати певну кількість хибних 
тривог (нижчий Precision), але ми не можемо дозволити собі 
пропускати реальні загрози (низький Recall). 
2.4.2 Критерій якості: Intersection over Union (IoU) 
Ключовим питанням є: що вважати "правильною" детекцією (TP)? Для 
цього вводиться метрика Intersection over Union (IoU). Вона вимірює ступінь 
перекриття між прогнозованою рамкою (Predicted Box) та істинною рамкою 
(Ground Truth Box). 
 
��������(��������������) (2.5) 
������ = 	 	
��������(����������)
 
Area(Overlap) — площа перетину (спільної частини) між рамкою, яку 
передбачила модель, і реальною рамкою (розміткою). 
Area(Union) — площа їхнього об'єднання (загальна площа, яку займають 
обидві рамки разом). 
Якщо IoU > 0.5, детекція зазвичай вважається успішною (TP). 
У стандартній практиці (та в даній роботі) встановлюється поріг IoU = 0.5. 
- якщо IoU > 0.5, детекція вважається True Positive (TP); 
- якщо IoU < 0.5, детекція вважається False Positive (FP). 
2.4.3 Комплексна метрика: mAP (mean Average Precision) 
30 
ЧДТУ 252481.005 ПЗ 
Оскільки Precision та Recall залежать від порогу впевненості (confidence) 
моделі, для комплексної оцінки використовують Average Precision (AP). 
- Average Precision (AP): Це площа під кривою Precision-Recall (P-R 
curve), яка показує усереднену точність моделі при всіх можливих 
порогах впевненості; 
- mean Average Precision (mAP): Усереднене значення AP по всіх класах 
об'єктів. Оскільки в даній роботі використовується однокласова 
детекція, mAP є синонімом AP. 
У Розділі 4 для тестування використовуються два стандарти mAP: 
- [email protected]: Стандарт PASCAL VOC, що вимірює mAP при фіксованому 
порозі IoU=0.5. Це основна метрика для оцінки загальної якості 
детекції; 
- [email protected]:0.95: Стандарт COCO, що вимірює mAP на 10 різних порогах 
IoU (від 0.5 до 0.95 з кроком 0.05) та усереднює їх. Ця метрика є значно 
"суворішою" і додатково вимірює, наскільки точно модель вміє 
локалізувати об'єкт (тобто наскільки ідеально рамки збігаються). 
2.5 Методи оптимізації синтезу моделей детекції 
У ході дослідження було застосовано комплексний підхід до оптимізації, 
спрямований на підвищення точності локалізації малих об'єктів та забезпечення 
роботи в реальному часі. 
2.5.1 Параметрична оптимізація функції втрат (Loss Landscape 
Optimization) 
Класичні функції втрат у задачах детекції (Cross-Entropy, CIoU) 
оптимізовані для збалансованих наборів даних. Для специфічної задачі пошуку 
малогабаритних загроз було застосовано метод ребалансування вагових 
коефіцієнтів: 
- cуть методу: Введення асиметричних ваг для компонент функції втрат; 
31 
ЧДТУ 252481.005 ПЗ 
- реалізація: Вага компоненти регресії координат (��������) була збільшена 
до 15.0, тоді як вага класифікації (��������) зменшена до 0.5; 
- ефект: Це змінило градієнтний ландшафт, змушуючи алгоритм 
оптимізації (AdamW) пріоритезувати мінімізацію геометричної 
помилки (IoU) над впевненістю у класі. Це критично для мін, де 
точність рамки важливіша за ймовірність. 
2.5.2 Структурна оптимізація архітектури (Architecture Search 
Optimization) 
Замість використання статичної архітектури було застосовано метод 
пошуку оптимальної топології в межах сімейства одностадійних детекторів: 
- перехід до Anchor-Free: Відмова від фіксованих якорів (Anchor Boxes) 
усунула необхідність евристичного підбору розмірів шаблонів (K-
means clustering), що оптимізувало процес навчання для об'єктів 
асиметричної форми; 
- інтеграція механізмів уваги: Впровадження блоків просторової уваги 
(Spatial Attention Module) оптимізувало проходження сигналу через 
мережу, дозволяючи фільтрувати високочастотний шум (трава, листя) 
на ранніх шарах згортки. 
2.5.3 Стохастична оптимізація простору даних (Data Space Optimization) 
Для вирішення проблеми розрідженості навчальної вибірки (Small Data 
Problem) застосовано методи стохастичного розширення простору ознак: 
- Mosaic Augmentation: Метод оптимізує навчальний батч шляхом 
змішування 4-х зображень в одне. Це штучно зменшує масштаб 
об'єктів, змушуючи модель вивчати ознаки, інваріантні до масштабу; 
- Mixup: Лінійна інтерполяція пікселів двох зображень оптимізує 
границі прийняття рішень (Decision Boundary), роблячи модель 
стійкою до візуальних завад. 
32 
ЧДТУ 252481.005 ПЗ 
2.5.4 Апаратна оптимізація інференсу (Inference Optimization) 
Для забезпечення вимог реального часу (<50 мс) застосовано методи 
оптимізації виконання коду: 
- Dynamic Batching: Адаптивний підбір розміру батчу під доступну 
VRAM; 
- FP16 Quantization: Використання половинної точності (Half-Precision) 
при інференсі, що зменшило споживання пам'яті вдвічі без суттєвої 
втрати точності (mAP). 
ВИСНОВОК ДО РОЗДІЛУ 2 
Теоретичні та експериментальні дослідження довели, що для подолання 
проблеми дефіциту даних та ефективної детекції замаскованих об'єктів зі 
слабкими візуальними ознакамикритично важливим є застосування 
комбінованих методів аугментації даних. Дослідження підтвердили високу 
ефективність Mosaic-методу та генеративних підходів для підвищення 
узагальнюючої здатності моделі. Було визначено та проаналізовано ключові 
метрики якості (Precision, Recall, mAP) , які дозволяють об’єктивно оцінити 
ефективність моделі у порівнянні з існуючими рішеннями. Результати цього 
розділу формують наукову та методологічну основу для інженерного 
проектування архітектури програмного комплексу в Розділі 3. 
 
33 
ЧДТУ 252481.005 ПЗ 
РОЗДІЛ 3.ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
У даному розділі розглядаються способи застосування теоретичних 
напрацювань для конструювання моделі в рамках програмного середовища. 
Акцент робиться на адаптації результатів до реальних задач, з урахуванням 
специфіки об’єкта та обмежень, що забезпечує перехід від концепції до 
функціональної структури. 
3.1 Моделювання Предметної Області з Фокусом на Створення Моделі 
Процес побудови моделі предметної області являє собою фазу, де 
формалізуються ключові елементи для ефективної інтеграції в систему детекції. 
Це включає визначення взаємозв’язків між компонентами, з акцентом на 
адаптацію до умов з обмеженою видимістю. 
3.1.1 Предметна Область Моделювання. Модель Предметної Області. 
Словник Предметної Області 
Візуалізація концептуальної моделі предметної області, наведена на рис. 
3.1, що описує ключові сутності та їхні зв’язки у процесі навчання моделі. Ця 
діаграма термінологічний базис предметної області, сформульований, у розділі 
3.1.1. 
Центральними сутностями є Тренувальний_датасет, 
Тестувальний_датасет та Валідаційний_датасет, які складаються з множини 
Зображень_навчання. Кожне зображення, у свою чергу, жорстко пов’язане 
(композиція) з Анотацією, що містить координати у форматі YOLO (x_center, 
y_center тощо). 
Ця модель слугує основою для розробки логічної організації сховища 
даних (навчальної вибірки) у розділі 4.1.4 
34 
ЧДТУ 252481.005 ПЗ 
 
Рис 3.1 - Діаграма предметної області 
 
3.1.2 Елементи Моделювання Предметної Області 
Елементи моделювання включають класи для представлення об’єктів, 
атрибути для опису характеристик та відносини для взаємодії. Для архітектури 
дослідження ключовими є класи "ImageInput" (вхідне зображення), 
"DetectionModel" (ядро алгоритму) та "OutputLayer" (результати класифікації). 
Відносини типу "агрегація" пов’язують вхідні дані з процесом обробки, а 
"успадкування" дозволяє розширювати базові класи для варіацій середовища. Це 
дозволяє створити гнучку модель, адаптовану до шумових умов. 
35 
ЧДТУ 252481.005 ПЗ 
3.2 Формування та Аналіз Вимог до Моделі 
Формування вимог є критичним для забезпечення відповідності моделі 
поставленим задачам, з розподілом на функціональні та нефункціональні 
аспекти. 
3.2.1 Формування вимог до програмного забезпечення. Функціональні та 
нефункціональні вимоги 
Відповідно до методології інженерії програмного забезпечення, першим 
кроком проектування є декомпозиція загальної мети роботи (створення 
інтелектуальної моделі) на конкретний, вимірюваний та перевіряємий набір 
вимог. Ці вимоги слугують основою для проектування архітектури (Підрозділ 
3.3) та подальшого тестування системи (Розділ 4.2). 
Класифікація вимог до системи передбачає розмежування на дві категорії: 
функціональні (описують поведінку системи) та нефункціональні (описують 
атрибути якості та обмеження). 
3.2.1.1 Функціональні вимоги (FR) 
Група функціональних вимог визначає спектр задач, що їх повинен 
виконувати розроблений програмний комплекс. 
- FR1: Управління конфігурацією системи: 
- опис: Система повинна зчитувати всі параметри навчання з 
єдиного, зовнішнього файлу конфігурації. Це включає параметри 
набору даних, гіперпараметри моделі (епохи, lr), налаштування 
аугментацій та параметри оптимізатора; 
- обґрунтування: Забезпечує гнучкість експериментів. Дозволяє 
змінювати параметри навчання без будь-яких змін у програмному 
коді; 
36 
ЧДТУ 252481.005 ПЗ 
- реалізація: Ця вимога реалізована у модулі config.py через класи 
Config, TrainingConfig, ModelConfig та DatasetConfig. 
- FR2: Валідація та підготовка набору даних: 
- опис: Перед початком навчання система повинна автоматично 
перевірити (валідувати) структуру каталогів набору даних 
(наявність папок train/val/test). Після успішної валідації система 
повинна згенерувати конфігураційний файл data.yaml, необхідний 
для фреймворку Ultralytics; 
- обґрунтування: Запобігає запуску тривалого процесу навчання з 
некоректними вхідними даними, що економить час та 
обчислювальні ресурси; 
- реалізація: Реалізовано у модулі dataset.py класами DatasetValidator 
(метод validate_structure) та YAMLGenerator (метод create_yaml). 
- FR3: Виконання керованого циклу навчання: 
- опис: Система повинна інкапсулювати повний цикл навчання 
моделі. Це включає завантаження базової моделі (YOLOv11), 
застосування гіперпараметрів, запуск тренувального циклу на 
задану кількість епох та обробку результатів; 
- обґрунтування: Інкапсуляція логіки навчання у єдиний компонент 
(ModelTrainer) відповідає фундаментальній концепції SRP (Single 
Responsibility Principle), що визначає єдину зону відповідальності 
класу, та спрощує оркестрацію; 
- реалізація: Реалізовано у модулі training.py класом ModelTrainer та 
його методом train(). 
- FR4: Застосування специфічних аугментацій: 
- опис: Під час навчання система повинна застосовувати на льоту 
(online) комбіновані аугментації, визначені у config.py. Це включає 
37 
ЧДТУ 252481.005 ПЗ 
Mosaic, Copy-Paste, Mixup та набір геометричних і колірних 
трансформацій (HSV); 
- обґрунтування: Як доведено у Розділі 2, ці аугментації є критично 
важливими для підвищення стійкості моделі до маскування та умов 
зниженої інформативності; 
- реалізація: Параметри аугментації (mosaic, mixup, copy_paste тощо) 
визначаються у TrainingConfig та передаються у метод model.train(). 
- FR5: Валідація та оцінка метрик: 
- опис: Після кожної епохи (або з заданою періодичністю) система 
повинна запускати процес валідації на валідаційному наборі даних. 
Мають бути обчислені та залоговані ключові метрики: Precision, 
Recall, [email protected] та [email protected]; 
- обґрунтування: Забезпечує моніторинг якості моделі в динаміці та 
дозволяє відстежити момент перенавчання; 
- реалізація: Реалізовано у ModelTrainer (метод _perform_validation) 
та ResultsAnalyzer (метод _log_detailed_metrics). 
- FR6: Збереження артефактів моделі: 
- опис: Система повинна зберігати артефакти навчання. Це включає 
збереження найкращої версії моделі (best.pt) на основі пікового 
[email protected], а також проміжних контрольних точок (Checkpoint 
Manager) та фінальних логів навчання (Training Logger); 
- обґрунтування: Забезпечує відтворюваність результатів та надає 
фінальний продукт (модель) для подальшого використання; 
- реалізація: Реалізовано фреймворком Ultralytics, який керується 
параметрами save=True, project та name, а також класом 
ResultsAnalyzer. 
38 
ЧДТУ 252481.005 ПЗ 
3.2.1.2 Нефункціональні вимоги (NFR) 
Нефункціональні вимоги описують атрибути якості системи, обмеження та 
те, як система виконує свої функції. 
- NFR1: Адаптивність до обладнання: 
- опис: Програмний комплекс повинен автоматично визначати 
наявність та тип доступного обчислювального пристрою (NVIDIA 
GPU або CPU); 
- обґрунтування: Забезпечує працездатність системи на різному 
обладнанні; 
- реалізація: Реалізовано у модулі hardware.py класом 
HardwareDetector та функцією get_device_string(). 
- NFR2: Автоматична оптимізація параметрів: 
- опис: На основі визначеного обладнання (зокрема, обсягу VRAM) 
система повинна автоматично коригувати ключові гіперпараметри 
(batch_size, img_size) для досягнення максимальної продуктивності 
без помилок Out-of-Memory; 
- обґрунтування: Спрощує використання системи для оператора, 
запобігає необхідності ручного налаштування під кожну машину; 
- реалізація: Реалізовано у HardwareDetector (метод 
_get_optimal_settings) та у ModelTrainer (метод 
_adjust_training_params). 
- NFR3: Надійність (Валідація вхідних даних). 
- опис: Система повинна виконувати валідацію вхідних даних перед 
запуском основного, тривалого процесу навчання. Це включає 
перевірку існування шляхів до датасету та коректність значень 
гіперпараметрів; 
39 
ЧДТУ 252481.005 ПЗ 
- обґрунтування: Запобігає "аварійному" завершенню процесу 
навчання через декілька годин роботи через просту помилку 
конфігурації; 
- реалізація: Реалізовано у Config (метод validate()) та 
DatasetValidator (метод validate_structure()). 
- NFR4: Моніторинг та Логування; 
- опис: Система повинна надавати оператору детальний зворотний 
зв'язок про хід навчання. Це включає виведення метрик у консоль в 
реальному часі та збереження повних логів у файл для подальшого 
аналізу; 
- обґрунтування: Забезпечує прозорість процесу навчання; 
- реалізація: Реалізовано через стандартний модуль logging, 
налаштований у TrainingSystem, та класом ResultsAnalyzer. 
- NFR5: Модифікованість та Підтримуваність. 
- опис: Архітектура системи повинна бути модульною. Кожен 
компонент (робота з даними, робота з обладнанням, навчання) має 
бути інкапсульований у власному файлі/класі; 
- обґрунтування: Спрощує подальшу модернізацію системи (напр., 
додавання підтримки нової архітектури моделі) без необхідності 
переписувати всю логіку; 
- реалізація: Реалізовано через розподіл логіки на файли main.py, 
config.py, hardware.py, dataset.py та training.py. 
3.2.2 Формування вимог за допомогою діаграми прецедентів 
На рисунку 3.2 наведено діаграму прецедентів, яка візуалізує 
функціональні вимоги до розроблюваного програмного комплексу («Model 
Training Subsystem»). Вона визначає ролі акторів та їх взаємодію з системою. 
40 
ЧДТУ 252481.005 ПЗ 
Виділено три основні актори: 
- ML_Engineer: Головний користувач системи, відповідальний за 
налаштування, запуск та моніторинг. 
- Data_Scientist: Роль, зосереджена на аналізі результатів та якості 
моделі. 
- Training_System: Зовнішня система (напр., CI/CD), що може 
автоматично запускати навчання. 
 
Рис 3.2 - Діаграма прецендентів 
 
Ключові прецеденти включають «Запустити навчання» та «Підготувати 
датасет». Прецедент «Аугментувати дані» є обов’язковою частиною підготовки 
(зв’язок <<include>>). Процеси «Моніторити процес» та «Оцінити якість» є 
розширеннями (<<extend>>) для валідації та аналізу. 
3.3 Архітектурне Проектування Моделі 
41 
ЧДТУ 252481.005 ПЗ 
Архітектурне проектування визначає структуру моделі, з використанням 
діаграм для візуалізації компонентів та їх розгортання. 
3.3.1 Діаграми Класів та Пакетів 
На рисунку 3.3 показано високорівневу архітектуру програмного 
комплексу у вигляді діаграми пакетів. Ця діаграма ілюструє логічне групування 
класів за їхньою функціональною належністю та визначає залежності між 
модулями системи. 
Архітектура розділена на шість основних пакетів: 
- Training_Pipeline: Оркестратор процесу. 
- Model_Training: Логіка навчання, що інкапсулює YOLOTrainer та 
OptimizeFactory. 
- Data_Management: Відповідає за завантаження та аугментацію даних. 
- Monitoring_Logging: Забезпечує логування та моніторинг (напр., 
TensorboardLogger). 
- Metrics_Evaluation: Містить класи для розрахунку метрик 
(MetricsCalculator). 
- Configuration: Керує гіперпараметрами та налаштуваннями. 
Всі пакети залежать від External_ML_Libraries, що містить базові 
фреймворки (PyTorch, Ultralytics). 
 
42 
ЧДТУ 252481.005 ПЗ 
 
Рис 3.3 – Діаграма пакетів архітектури системи 
 
На рисунку 3.4 представлено початкову (концептуальну) діаграму класів, 
що ілюструє основні компоненти програмного комплексу та їх взаємодію за 
патерном «Фасад» або «Контролер». 
Клас TrainingManager виступає як центральний координатор, який делегує 
завдання спеціалізованим класам: 
- DatasetLoader: Завантажує та розділяє дані. 
- ModelTrainer: Керує тренувальним циклом та валідацією. 
- ConfigurationManager: Завантажує гіперпараметри. 
- MetricsCollector: Збирає та зберігає метрики. 
- ModelSaver: Відповідає за збереження контрольних точок (checkpoint) 
та фінальної моделі. 
Ця діаграма слугує основою для більш детальної діаграми класів реалізації, 
що наведена у Додатку B.1. 
 
43 
ЧДТУ 252481.005 ПЗ 
 
Рис 3.4 – Початкова діаграма класів 
 
3.3.2 Діаграми Компонентів та Розгортання 
На рисунку 3.5 представлено діаграму розгортання, що візуалізує фізичну 
архітектуру системи та розподіл програмних компонентів по апаратних вузлах. 
Процес навчання розгорнуто на трьох ключових вузлах: 
- Training Server: Головний вузол, де виконується Training Pipeline. Він 
оркеструє Data Loader та Model Trainer. 
- Data Storage: Виділене сховище (напр., NAS або хмарний сервіс), що 
містить Training Dataset, Validation Dataset та кеш аугментованих 
даних. 
- GPU Cluster: Вузол обчислень, що містить середовище CUDA Runtime 
та PyTorch Engine. Він отримує дані та інструкції від Model Trainer і 
виконує обчислювально-важкі операції (Model Forward/Backward). 
Окремий вузол Monitoring System (напр., TensorBoard Server) збирає 
метрики та лог-файли для візуалізації процесу навчання. 
 
44 
ЧДТУ 252481.005 ПЗ 
 
Рис 3.5 – Діаграма розгортання 
 
У Додатку В.2 показано компонентну архітектуру системи, що детально 
ілюструє процес навчання моделі. Вона відображає ключові програмні 
компоненти, їхні інтерфейси та потоки даних, що реалізують логіку, описану в 
Розділі 4. 
Центральним елементом є Training Manager (Менеджер Навчання), який 
виступає як контролер з Control Interface та оркеструє весь процес. 
Процес ініціалізується Training Manager, який виконує наступні дії: 
- викликає initialize_datasets на компоненті Dataset Manager, який через 
інтерфейси Data Loading та Augmentation Processing зчитує (read, load) 
Training Images, Validation Images та Annotations; 
- надсилає команду load_parameters до Configuration Loader. Цей 
компонент зчитує (read) усі необхідні конфігурації: dataset.yaml 
45 
ЧДТУ 252481.005 ПЗ 
(структура даних), training_cfg.yaml (гіперпараметри) та yolov8n.pt 
(початкові ваги); 
- запускає сам процес навчання командою start_training на компоненті 
YOLO Training Engine. 
Основну роботу виконує YOLO Training Engine (Рушій Навчання). Він 
завантажує ваги (load_weights) та виконує тренувальний цикл (Forward Pass, 
Backward Pass), використовуючи Loss Calculator для обчислення втрат 
(calculate_loss). 
Для валідації рушій викликає validate_model на компоненті Metrics 
Evaluator. Цей компонент агрегує метрики та виконує два завдання: 
- Експортує фінальні метрики у файл metrics.json; 
- Передає поточну статистику (log_training_stats, log_validation_stats) до 
Training Logger. 
Training Logger відповідає за моніторинг та збереження. Він записує 
текстові логи (training_logs.txt) і, що ключове, керує збереженням моделі, 
надсилаючи команду save_if_improved до Model Saver. Model Saver, у свою 
чергу, зберігає проміжні Checkpoints та фінальну навчену модель model.pt. 
46 
ЧДТУ 252481.005 ПЗ 
ВИСНОВОК ДО РОЗДІЛУ 3 
У даному розділі було виконано ключовий етап інженерної розробки – 
перехід від теоретичних досліджень до практичного проектування програмного 
комплексу. Було формалізовано чіткі функціональні (точність виявлення ≥ 95%) 
та нефункціональні (швидкість інференсу ≤ 50 мс) вимоги до системи . На основі 
цих вимог, з використанням мови UML, було розроблено повну архітектуру 
системи: 
- Визначено прецеденти та акторів (Рис. 3.2). 
- Спроектовано логічну структуру класів та пакетів (Рис. 3.3, 3.4). 
- Спроектовано фізичну архітектуру через діаграми компонентів та 
розгортання (Рис. 3.5, 3.6). 
Спроектована архітектура є прямим технічним завданням для 
безпосередньої програмної реалізації (конструювання) та фінального тестування 
у наступному розділі. 
 
47 
ЧДТУ 252481.005 ПЗ 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
Попередні розділи заклали теоретичну (Розділ 2) та проектну (Розділ 3) 
основу для створення інтелектуальної моделі. Було проаналізовано предметну 
область, сформовано вимоги та розроблено архітектуру програмного 
забезпечення. 
Цей розділ присвячений безпосередній програмній реалізації 
(конструюванню) спроектованого програмного комплексу, головним завданням 
якого є підготовка даних, навчання та валідація моделі детекції мін 
вибухонебезпечних предметів. Окрему увагу приділено всебічному тесту'ванню 
системи для підтвердження її відповідності функціональним та 
нефункціональним вимогам, визначеним у Розділі 3. 
4.1 Розробка програмного комплексу  
На цьому етапі було створено програмний комплекс, що реалізує повний 
інженерний цикл MLOps: від підготовки даних до навчання та запуску навченої 
моделі. 
4.1.1 Обґрунтування вибору засобів реалізації  
Обґрунтування комплексу інструментальних засобів, наведене уРозділі 
1.3, ґрунтується на вимогах до гнучкості досліджень, швидкості прототипування 
та ефективності навчання: 
- Python: Обрано як базовий інструмент розробки, зважаючи на 
розвинену інфраструктуру пакетів, орієнтованих на математичне 
моделювання й машинного навчання; 
- PyTorch: Використано як базовий фреймворк глибокого навчання. Його 
гнучкість («динамічні графи») є критичною для експериментального 
48 
ЧДТУ 252481.005 ПЗ 
моделювання (Розділ 2.3) та забезпечує повний контроль над процесом 
навчання моделі; 
- Ultralytics: Обрано як високорівневий фреймворк, що надає 
оптимізовані реалізації архітектур YOLO. Це дозволило зосередити 
зусилля не на реалізації базових шарів моделі з нуля, а на створенні 
пайплайну підготовки даних та тонкому налаштуванні процесу 
навчання для конкретної задачі; 
- NumPy: Використано для ефективних чисельних операцій з масивами 
зображень та анотаціями на етапі завантаження, а також під час 
попереднього опрацювання інформації; 
- Open Computer Vision(OpenCV): Застосовано для базових операцій 
комп'ютерного зору: читання/запис зображень, застосування деяких 
методів аугментації та візуалізація кінцевих результатів (накладання 
обмежувальних рамок). 
4.1.2 Опис структурної (функціональної) схеми  
Програмний комплекс реалізовано у вигляді деталізованого конвеєра 
(pipeline), який чітко визначає п’ять основних етапів життєвого циклу навчання 
моделі. На відміну від загальних схем, у Додатку В.3 представляє конкретну 
функціонально-логічну схему процесу навчання моделі, що відображає 
інженерні рішення, прийняті в даній роботі. 
1 Етап Ініціалізації Процес запускається через головний скрипт-
оркестратор main.py. Цей компонент виконує первинну перевірку та 
налаштування системи, послідовно ініціалізуючи три ключові модулі: 
- hardware.py : Виконує детекцію апаратного забезпечення (CPU/GPU) та 
визначає оптимальні параметри для поточної конфігурації (наприклад, 
для GPU RTX 4060); 
- config.py : Завантажує визначені гіперпараметри для моделі, 
включаючи параметри аугментацій, оптимізатора та функцій втрат; 
49 
ЧДТУ 252481.005 ПЗ 
- dataset.py : Виконує валідацію структури та цілісності набору даних 
(train/val/test), гарантуючи готовність до навчання. 
2 Етап Підготовки Даних Після успішної ініціалізації запускається конвеєр 
підготовки даних: 
- DataLoader: Зчитує зображення та анотації у форматі YOLO; 
- Augmentation: Застосовує специфічний набір аугментацій, 
оптимізований для детекції мін: Mosaic (60%), Copy-Paste (60%), Mixup 
(5%) та геометричні трансформації (Geometric); 
- Batch Creation: Формує пакети (батчі) даних з урахуванням апаратних 
можливостей, визначених на етапі ініціалізації (напр., batch_size=4, 
imgsz=1280). 
3 Етап Навчального Циклу Це ядро програмного комплексу. Цикл 
виконується протягом 300 епох з механізмом ранньої зупинки (patience=100): 
- Forward Pass: Батч даних пропускається через архітектуру моделі 
YOLOv11; 
- Loss Calculation: Обчислюється комбінована функція втрат з точно 
налаштованими ваговими коефіцієнтами: Box Loss (w=15.0), Cls Loss 
(w=0.15) (низька вага, оскільки це однокласова детекція) та DFL Loss 
(w=4.0); 
- Backward Pass: Виконується зворотне поширення помилки; 
- AdamW Optimizer: Оптимізатор оновлює ваги моделі, використовуючи 
задані параметри (lr=0.0001, weight_decay=0.0015, momentum=0.95); 
- Cosine Lr Scheduler: Швидкість навчання (lr) динамічно коригується 
протягом навчання за косинусним графіком для стабільної збіжності. 
4 Етапи Валідації та Контролю Якості Після кожної епохи паралельно 
запускаються процеси контролю: 
50 
ЧДТУ 252481.005 ПЗ 
- Валідація: Модель переводиться в режим Inference no gradient (без 
обчислення градієнтів, завдяки чому досягається суттєве підвищення 
швидкодії) і проганяється на валідаційному наборі даних; 
- Metrics Calculation: Розраховуються ключові метрики (Precision, Recall, 
[email protected], [email protected]); 
- Контроль Якості: Метрики передаються до трьох компонентів: 
- Checkpoint Manager: Зберігає найкращу версію моделі (save best 
model), якщо поточний mAP перевищує попередній; 
- Early Stopping: Перевіряє, чи не покращувались метрики протягом 
patience=100 епох, та надсилає сигнал continue/stop до навчального 
циклу; 
- Training Logger: Записує всі метрики у JSON logs та на сервер 
TensorBoard для візуального моніторингу. 
5 Етап Результату Після завершення навчального циклу система генерує 
фінальний артефакт - Model з чітко зафіксованими показниками ефективності, 
отриманими на тестовому наборі даних (Precision: 98.85%, Recall: 96.26%, 
mAP50: 99.19%, mAP50-95: 89.43%). 
4.1.3. Опис логічної схеми системи  
Логічну схему процесу навчання детально представлено в Додатку B.4 у 
вигляді діаграми діяльності UML. Ця діаграма покроково ілюструє алгоритм 
роботи програмного комплексу від ініціалізації до завершення. 
Процес починається з Ініціалізації, що включає перевірку наявності GPU 
та завантаження датасетів. Далі відбувається паралельна ініціалізація моделі, 
оптимізатора та логування. 
51 
ЧДТУ 252481.005 ПЗ 
Основна логіка інкапсульована у циклі Почати цикл навчання, який 
ітерується по епохах. Усередині циклу відбувається завантаження та аугментація 
batch даних, прямий (Forward pass) та зворотний (Backward pass) проходи, та 
оновлення ваг. 
Після кожної епохи виконується Валідація, де на основі метрик спрацьовує 
логіка Early stopping та збереження найкращої моделі (checkpoint). Процес 
завершується, коли досягнуто максимальної кількості епох або спрацював 
механізм ранньої зупинки. 
 
 
Рис. 4.1 – Діаграма послідовності 
52 
ЧДТУ 252481.005 ПЗ 
Рисунок 4.1 візуалізує діаграма послідовності, що деталізує динамічну 
взаємодію об’єктів у часі під час виконання однієї тренувальної ітерації (епохи). 
Ініціатором виступає ML Engineer, який запускає Training Pipeline. 
Усередині циклу (loop [for each epoch]) Training Pipeline запитує Data 
Loader про batch даних. Отримавши аугментовані дані, він передає їх Model 
Trainer. 
Model Trainer виконує forward(images) на YOLO Model, передає результат 
та цілі (targets) у Loss Function для обчислення втрат. Після отримання total_loss, 
він виконує backward(loss) на YOLO Model для оновлення ваг. 
Після тренувального кроку відбувається валідація, де Metrics Calculator 
обчислює precision, recall та mAP. Наприкінці Checkpoint Manager викликається 
для порівняння метрик та збереження моделі (save_if_bestmodel). 
4.1.4 Розробка бази даних  
Система не використовує традиційну реляційну базу даних. Роль "бази 
даних" виконує структурований набір даних (датасет), зібраний та підготовлений 
спеціально для цієї задачі. 
- концептуальна модель: Ключовою сутністю є «Цільовий об'єкт» 
(Target Object), що характеризується своїм візуальним представленням 
та обмежувальною рамкою на зображенні; 
- логічна модель: Для опису даних розмітки датасету застосовано 
уніфікований анотацій YOLO. Кожному файлу зображення (.jpg, .png) 
відповідає текстовий файл (.txt) з такою ж назвою. Кожен рядок у .txt 
файлі описує один об'єкт у форматі: <class_id> <x_center> <y_center> 
<width> <height> Де class_id дорівнює 0, оскільки це задача одно-
класової детекції; 
- фізична модель: Організувати файлову структуру датасету наступним 
чином, що є стандартом для фреймворків Ultralytics/YOLO: 
 
53 
ЧДТУ 252481.005 ПЗ 
dataset/ 
├── test/ (Папка з тестовими фотографіями) 
│   ├── image/ 
│   └── labels/ 
├── train/ (Папка з навчальними фотографіями) 
│   ├── image/ 
│   └── labels/ 
└──  val/ (Папка з валідаційними фотографіями) 
      ├── image/ 
      └── labels 
 Файл data.yaml є ключовим файлом "схеми", що описує шляхи до даних 
та імена класів: 
YAML 
path: dataset 
train: train/images 
val: val/images 
test: test/images 
# Number of classes 
nc: 1 
# Class names 
names: ['mine'] 
4.1.5 Розробка інтерфейсу користувача  
Оскільки розроблений програмний комплекс є інженерним інструментом 
для проведення досліджень та навчання моделі, його основним інтерфейсом є 
інтерфейс командного рядка (CLI). 
Взаємодія з системою через запуск Python-скриптів з передачею 
необхідних параметрів (гіперпараметрів, шляхів до даних, конфігурацій). 
Наприклад: $ python train.py --img 640 --batch 16 --epochs 100 --data 
pfm1_dataset/data.yaml 
Графічне представлення результатів роботи системи (інтерфейс для 
кінцевої оцінки) забезпечується компонентом «Візуалізатор» (4.1.2) та 
54 
ЧДТУ 252481.005 ПЗ 
автоматично згенерованими графіками процесу навчання (втрати, mAP). 
Приклади візуалізації наведено у пункті 4.3. 
4.1.6 Опис розробки програмних компонентів  
Центральним внеском є розробка та конфігурація програмних 
компонентів, що реалізують описані вище схеми. 
- Компонент підготовки даних (Data Engineering Scripts): Розробивши 
набір скриптів для автоматизації процесу створення датасету. Ці 
скрипти виконують розмітку зображень (анотування) та 
автоматизований розподіл на навчальну (train), тестування (test) та 
валідаційну (val) вибірки у співвідношенні 70/15/15, формуючи 
структуру, описану в 4.1.4. 
- Компонент навчання (train.py): Це головний скрипт програмного 
комплексу, що реалізує «Конвеєр навчання» (4.1.2). Він був 
налаштований для завантаження кастомного файлу data.yaml, 
ініціалізації архітектури YOLO з оптимальними гіперпараметрами 
(визначеними в Розділі 2) та запуску процесу навчання на GPU. 
- Компонент детекції (detect.py): Цей скрипт є реалізацією «Механізму 
висновку» (4.1.2). Він налаштований на завантаження найкращих 
навчених ваг (best.pt), згенерованих компонентом тренувального 
процесу, а також подальше використання нейромережі для 
демонстрації її ефективності. 
4.1.7 Реалізація механізмів структурної оптимізації 
Для забезпечення стабільності та ефективності роботи програмного 
комплексу було реалізовано стратегію «структурної оптимізації», яка охоплює 
три рівні системи: апаратний, алгоритмічний та рівень даних. 
55 
ЧДТУ 252481.005 ПЗ 
1 Апаратна оптимізація (Hardware Optimization). Реалізовано у модулі 
hardware.py. Система динамічно аналізує доступні ресурси (обсяг VRAM 
відеокарти NVIDIA) і адаптує структуру тренувального процесу. 
- Механізм: Якщо виявлено GPU з обмеженою пам'яттю (наприклад, 4-6 
ГБ), система автоматично зменшує розмір батчу (batch_size) та 
роздільну здатність вхідного зображення (img_size), запобігаючи 
критичним помилкам Out Of Memory (OOM). Це гарантує структурну 
сумісність ПЗ з широким спектром обладнання. 
2 Оптимізація гіперпараметрів навчання (Training Structure Optimization). 
Реалізовано у модулі конфігурації та скрипті навчання. Оптимізація полягає у 
структурній зміні пріоритетів функції втрат для специфічної задачі детекції мін. 
- Механізм: Встановлено дисбаланс ваг: вага помилки координат 
(box_loss) збільшена до 15.0, тоді як вага помилки класу (cls_loss) 
зменшена. Це структурно змінює вектор градієнтного спуску, 
змушуючи модель пріоритезувати точність локалізації (геометрію 
рамки) над впевненістю класифікації. 
3 Валідація структури даних (Dataset Structure Validation). Реалізовано у 
модулі dataset.py . Забезпечує цілісність вхідного потоку даних. 
- Механізм: Клас DatasetValidator виконує перевірку логічної 
(відповідність формату YOLO) та фізичної (наявність файлів) 
структури. Система автоматично виявляє та ігнорує «осиротілі» мітки 
(orphaned labels) або пошкоджені зображення, що запобігає збоям у 
пайплайні навчання. 
4.2 Тестування та аналіз результатів навчання 
Тестування програмного комплексу полягало у проведенні повноцінного 
циклу навчання моделі (300 епох) та детальному аналізі отриманих результатів. 
56 
ЧДТУ 252481.005 ПЗ 
Цей процес валідує як коректність роботи програмних компонентів, так і 
ефективність теоретичних рішень, прийнятих у Розділі 2. 
4.2.1 Середовище та методологія тестування 
- середовище: Тестування (навчання) проводилось на апаратному 
забезпеченні, визначеному компонентом HardwareDetector: GPU 
NVIDIA GeForce RTX 4060 (8GB VRAM), CPU Intel Core i5-10400F, 32 
ГБ ОЗП; 
- методологія: Було запущено головний оркестратор, який ініціалізував 
ModelTrainer з конфігурацією. Навчання проводилося протягом 300 
епох. Усі метрики та втрати автоматично логувалися (results.csv) та 
візуалізувалися компонентом Training Logger. Для фінальної оцінки 
використовувалася версія моделі, що показала найкращий [email protected] на 
валідаційній вибірці (збережена Checkpoint Manager). 
4.2.2 Аналіз динаміки навчання 
Графіки, згенеровані системою логування (рис. 4.2), демонструють 
динаміку процесу навчання протягом 300 епох. 
57 
ЧДТУ 252481.005 ПЗ 
 
Рис. 4.2. Загальна динаміка навчання (Втрати, Точність, Повнота та mAP) 
 
Аналіз графіків свідчить про високу ефективність та стабільність процесу: 
1 Функції Втрат (Loss): Усі криві втрат ( train/box_loss, train/cls_loss, 
train/dfl_loss) демонструють очікуване плавне зниження та вихід на 
"плато". Важливо, що валідаційні втрати (val/box_loss і т.д.) також 
знижуються і залишаються низькими, що виступає індикатором 
успішного уникнення ефекту перенавчання (Overfitting). 
2 Метрики Якості (Metrics): Ключові метрики (metrics/mAP50(B), 
metrics/precision(B), metrics/recall(B)) показують стрімке зростання на 
початкових епохах та стабілізацію на високому рівні (близько 96-99%), 
що підтверджує коректність вибору гіперпараметрів та ефективність 
аугментацій. 
4.2.3 Аналіз ефективності фінальної моделі 
58 
ЧДТУ 252481.005 ПЗ 
Оцінка фінальної (найкращої) моделі проводилась на валідаційній вибірці. 
Таблиця 4.1 підсумовує ключові показники ефективності, досягнуті моделлю 
(спираючись на метрики, зафіксовані у results.csv на 300-й епосі, яка є близькою 
до пікової). 
Таблиця 4.1.  
Фінальні метрики ефективності моделі 
Метрика Опис Отримане 
значення 
[email protected] Головна метрика якості (стандарт PASCAL VOC) 99.19% 
[email protected]:0.95 "Сувора" метрика якості (стандарт COCO) 89.43% 
Recall Повнота (відсоток знайдених мін) 96.26% 
Precision Точність (відсоток правильних детекцій) 98.85% 
 
Ці надзвичайно високі показники візуально підтверджуються матрицею 
плутанини (рис. 4.3), яка показує розподіл помилок моделі. 
59 
ЧДТУ 252481.005 ПЗ 
 
Рис. 4.3. Нормалізована матриця плутанини 
 
Матриця плутанини (confusion_matrix_normalized.png) демонструє: 
- високу повноту (Recall): 96% об'єктів, які насправді були мінами (pfm-
1), були коректно ідентифіковані. Лише 4% були пропущені (помилка 
False Negative). 
- високу точність (Precision): 98.7% об'єктів, які були "фоном" 
(background), були коректно проігноровані. Лише 1.3% фонових 
об'єктів були помилково прийняті за міну (помилка False Positive). 
4.2.4 Аналіз кривих Precision-Recall (P-R) 
60 
ЧДТУ 252481.005 ПЗ 
Криві P-R (рис. 4.4, 4.5, 4.6, 4.7) деталізують поведінку моделі при різних 
порогах впевненості. 
 
 
Рис. 4.4. Крива Precision-Recall (P-R) 
 
Крива P-R (BoxPR_curve.png) демонструє ідеальну поведінку моделі. 
Велика площа під кривою (AUC), що призводить до [email protected] = 0.992 (99.2%), 
показує, що модель здатна підтримувати високу точність (Precision) навіть при 
досягненні високої повноти (Recall). 
 
 
Рис. 4.5. Криві Точності (P) 
61 
ЧДТУ 252481.005 ПЗ 
 
Рис. 4.6 Криві Повноти (R) 
 
 
Рис. 4.7 Криві F1-оцінки 
62 
ЧДТУ 252481.005 ПЗ 
Окремі криві показують, що F1-оцінка (гармонійне середнє між P та R) 
досягає свого піку (близько 0.97) при порозі впевненості (confidence) приблизно 
0.85, що є чудовим балансом для практичного застосування. 
4.2.5 Аналіз характеристик набору даних 
Графіки, згенеровані в ході навчального процесу (рис. 4.8 та рис. 4.9), 
також надають важливу інформацію про сам набір даних, на якому проводилось 
навчання. 
 
 
Рис. 4.8.- Корелограма анотацій валідаційного набору 
63 
ЧДТУ 252481.005 ПЗ 
 
Рис. 4.9.- Розподіл 
 
Аналіз графіків підтверджує: 
1 Розподіл: Анотації рівномірно розподілені по всьому зображенню 
(x_center, y_center), що гарантує, що модель навчилася шукати об'єкти 
будь-де, а не обмежуючись виключно центральною зоною кадру. 
2 Розмір (w, h): Корелограма чітко показує, що переважна більшість 
об'єктів (анотацій) мають дуже малий відносний розмір (width та height 
< 0.2, або менше 20% від розміру зображення). Це підтверджує, що 
64 
ЧДТУ 252481.005 ПЗ 
модель успішно пройшла тестування на детекцію малих об'єктів, що 
було одним з ключових викликів, визначених у Розділі 1.4. 
4.2.6 Приймальне тестування 
На основі результатів системного тестування, представлених у цьому 
підрозділі, можна зробити висновок, що програмний комплекс повністю виконав 
поставлені вимоги. 
- функціональні вимоги (FR) виконані: система успішно навчається 
(FR3), застосовує аугментації (FR4), валідує (FR5) та зберігає (FR6) 
модель. 
- нефункціональні вимоги (NFR) виконані: досягнуто фінальну точність 
[email protected] = 99.19% (перевищує вимогу >90%/95%) та швидкість 23.7 
мс (перевищує вимогу <50 мс). 
Розроблений програмний комплекс та навчена модель вважаються такими, 
що пройшли приймальне тестування. 
 
65 
ЧДТУ 252481.005 ПЗ 
ВИСНОВОК ДО РОЗДІЛУ 4 
У даному розділі було детально описано етапи реалізації та верифікації 
програмної системи, спроектованої задля автоматизованого розпізнавання 
ідентифікованих загроз. Було обґрунтовано вибір засобів реалізації (PyTorch, 
Ultralytics), описано інженерний внесок у створення набору даних (4.1.4) та 
розробку ключових програмних компонентів (4.1.6) для навчання та детекції. 
Всебічне тестування системи (4.2) підтвердило повну відповідність 
розробки поставленим у Розділі 3 вимогам. Досягнуто високих показників 
точності ([email protected] = 99.19%) та швидкодії (23.7 мс/кадр), що валідує створену 
інтелектуальну модель як ефективне рішення для практичного застосування. 
 
66 
ЧДТУ 252481.005 ПЗ 
ВИСНОВОК 
У даній кваліфікаційній роботі магістра було успішно розв’язано 
актуальну науково-практичну задачу, що полягає у створенні інтелектуальної 
моделі для детекції небезпечних об’єктів, зокрема протипіхотних мін натискної 
дії, в умовах зниженої інформативності вхідного інформаційного поток. 
Реалізація визначеної мети зумовила необхідність вирішення комплексу 
таких задач: 
- здійснено комплексний огляд предметної сфери й наявних методів. 
Виявлено, що найбільш перспективними є архітектури YOLO, а 
технологічний стек PyTorch та Ultralytics є оптимальним для реалізації 
поставленого завдання. 
- виконано теоретичні та експериментальні дослідження методів 
підвищення стійкості моделі, де доведено ефективність застосування 
комплексних методів аугментації (mosaic-метод, геометричні 
трансформації) для компенсації дефіциту реальних зразків . 
- розроблено та детально описано інженерний процес проектування 
програмного забезпечення. У Розділі 3 було сформовано чіткі 
функціональні (точність > 90% ) та нефункціональні (швидкість < 50 
мс ) вимоги та спроектовано архітектуру системи з використанням 
діаграм UML. 
- у Розділі 4 було здійснено програмну реалізацію (конструювання) 
програмного комплексу, що включає створення структурованого 
набору даних (датасету) та розробку пайплайнів для навчання та 
тестування моделі. 
- проведено тестування розробленого програмного забезпечення та 
навченої моделі. 
67 
ЧДТУ 252481.005 ПЗ 
У результаті системного тестування було підтверджено, що всі поставлені 
вимоги було не лише досягнуто, а й значно перевищено. 
Ключові кількісні результати роботи на тестовій вибірці:  
- Функціональна вимога (Точність): Досягнуто показник середньої 
точності [email protected] = 99.19% , що суттєво перевищує цільовий показник 
(95% або 90% ). 
- Нефункціональна вимога (Швидкодія): Досягнуто середню швидкість 
інференсу 23.7 мс на кадр , що значно швидше за порогове значення у 
50 мс. 
Наукова новизна полягає в адаптації архітектури YOLO для одно-класової 
детекції з урахуванням аугментації даних на основі відкритих джерел, що 
дозволило досягти високої точності ([email protected] – 99.19%) в умовах шумових 
перешкод. 
Практичне значення полягає у тому, що розроблена модель та програмний 
комплекс можуть слугувати основою для створення автоматизованих систем 
моніторингу небезпечних територій, зокрема для оборонних цілей та цивільного 
захисту. 
 
68 
ЧДТУ 252481.005 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Redmon J., Divvala S., Girshick R., Farhadi A. You Only Look Once: 
Unified, Real-Time Object Detection // Proceedings of the IEEE Conference on 
Computer Vision and Pattern Recognition (CVPR). 2016. pp. 779-788. URL: 
https://arxiv.org/abs/1506.02640. 
2 Redmon J., Farhadi A. YOLOv3: An Incremental Improvement // arXiv 
preprint arXiv:1804.02767. 2018. URL: https://arxiv.org/abs/1804.02767. 
3 Bochkovskiy A., Wang C.-Y., Liao H.-Y. M. YOLOv4: Optimal Speed 
and Accuracy of Object Detection // arXiv preprint arXiv:2004.10934. 2020. URL: 
https://arxiv.org/abs/2004.10934. 
4 Wang C.-Y., Bochkovskiy A., Liao H.-Y. M. YOLOv7: Trainable bag-
of-freebies sets new state-of-the-art for real-time object detectors // Proceedings of the 
IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2023. 
pp. 7464-7475. URL: https://arxiv.org/abs/2207.02696. 
5 Jocher G., Chaurasia A., Qiu J. YOLO by Ultralytics: Algorithms, 
Methods, and Data. Ultralytics Open-Source Research. 2023. URL: 
https://github.com/ultralytics/ultralytics. 
6 Tian Z., Shen C., Chen H., He T. FCOS: Fully Convolutional One-Stage 
Object Detection // Proceedings of the IEEE/CVF International Conference on 
Computer Vision (ICCV). 2019. pp. 9627-9636. URL: 
https://arxiv.org/abs/1904.01355. 
7 Ge Z., Liu S., Wang F., Li Z., Sun J. YOLOX: Exceeding YOLO Series 
in 2021 // arXiv preprint arXiv:2107.08430. 2021. URL: 
https://arxiv.org/abs/2107.08430. 
8 Zhu P., Wen L., Du D., Bian X., Fan H., Hu Q., Ling H. VisDrone-
DET2019: The Vision Meets Drone Object Detection in Images Challenge Results // 
Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV) 
Workshops. 2019. URL: https://arxiv.org/abs/1910.05739. 
69 
ЧДТУ 252481.005 ПЗ 
9 Liu Y., Sun P., Wergeles N., Shang Y. A survey and performance 
evaluation of deep learning methods for small object detection // Expert Systems with 
Applications. 2021. Vol. 172. URL: https://arxiv.org/abs/1909.04358. 
10 Kyrkou C., Plastiras G., Theocharides T., Venieris S. I., Bouganis C.-
S. Drones: Augmenting Our Quality of Life // IEEE Potentials. 2019. Vol. 38, no. 1. 
pp. 30-36. URL: https://arxiv.org/abs/1806.02720. 
11 Sommer L., Schumann A., Beyerer J. Fast and Accurate Aerial Object 
Detection for Search and Rescue // Proceedings of the IEEE/CVF Conference on 
Computer Vision and Pattern Recognition (CVPR) Workshops. 2018. URL: 
https://arxiv.org/abs/1804.05367. 
12 Lin T.-Y., Goyal P., Girshick R., He K., Dollár P. Focal Loss for Dense 
Object Detection // Proceedings of the IEEE International Conference on Computer 
Vision (ICCV). 2017. pp. 2980-2988. URL: https://arxiv.org/abs/1708.02002. 
13 Li X., Wang W., Wu L., Chen S., Hu X., Li J., Tang J., Yang J. 
Generalized Focal Loss: Learning Joint Representation of Quality Estimation and 
Category Prediction // Advances in Neural Information Processing Systems (NeurIPS). 
2020. URL: https://arxiv.org/abs/2006.04388. 
14 Zheng Z., Wang P., Liu W., Li J., Ye R., Ren D. Distance-IoU Loss: 
Faster and Better Learning for Bounding Box Regression // Proceedings of the AAAI 
Conference on Artificial Intelligence. 2020. URL: https://arxiv.org/abs/1911.08287 
15 Kingma D. P., Ba J. Adam: A Method for Stochastic Optimization // 
International Conference on Learning Representations (ICLR). 2015. URL: 
https://arxiv.org/abs/1412.6980 . 
16 Loshchilov I., Hutter F. Decoupled Weight Decay Regularization // 
International Conference on Learning Representations (ICLR). 2019. URL: 
https://arxiv.org/abs/1711.05101. 
17 Zhang H., Cisse M., Dauphin Y. N., Lopez-Paz D. mixup: Beyond 
Empirical Risk Minimization // International Conference on Learning Representations 
(ICLR). 2018. URL: https://arxiv.org/abs/1710.09412. 
70 
ЧДТУ 252481.005 ПЗ 
18 Yun S., Han D., Oh S. J., Chun S., Choe J., Yoo Y. CutMix: 
Regularization Strategy to Train Strong Classifiers with Localizable Features // 
Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV). 
2019. URL: https://arxiv.org/abs/1905.04899. 
19 Ghiasi G., Cui Y., Srinivas A., Qian R., Lin T.-Y., Cubuk E. D., Le Q. 
V., Zoph B. Simple Copy-Paste is a Strong Data Augmentation Method for Instance 
Segmentation // Proceedings of the IEEE/CVF Conference on Computer Vision and 
Pattern Recognition (CVPR). 2021. URL: https://arxiv.org/abs/2012.07177. 
20 Cubuk E. D., Zoph B., Mane D., Vasudevan V., Le Q. V. 
AutoAugment: Learning Augmentation Strategies from Data // Proceedings of the 
IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2019. 
URL: https://arxiv.org/abs/1805.09501. 
21 Padilla R., Netto S. L., da Silva E. A. B. A Survey on Performance 
Metrics for Object-Detection Algorithms // 2020 International Conference on Systems, 
Signals and Image Processing (IWSSIP). 2020. URL: 
https://ieeexplore.ieee.org/document/9145130. 
22 Lin T.-Y., Maire M., Belongie S., Hays J., Perona P., Ramanan D., 
Dollár P., Zitnick C. L. Microsoft COCO: Common Objects in Context // European 
Conference on Computer Vision (ECCV). 2014. URL: 
https://arxiv.org/abs/1405.0312. 
23 Everingham M., Van Gool L., Williams C. K. I., Winn J., Zisserman A. 
The Pascal Visual Object Classes (VOC) Challenge // International Journal of 
Computer Vision. 2010. Vol. 88. pp. 303-338. URL: 
http://host.robots.ox.ac.uk/pascal/VOC/. 
24 Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language 
User Guide. 2nd Edition. Addison-Wesley Professional, 2005. 496 p. 
25 Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Elements 
of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994. 395p. 
26 Sommerville I. Software Engineering. 10th Edition. Pearson, 2015. 
816p. 
71 
ЧДТУ 252481.005 ПЗ 
27 Martin R. C. Clean Architecture: A Craftsman's Guide to Software 
Structure and Design. Prentice Hall, 2017. 432p. 
28 Richardson C. Microservices Patterns: With examples in Java. Manning 
Publications, 2018. 520p. 
29 Paszke A. et al. PyTorch: An Imperative Style, High-Performance Deep 
Learning Library // Advances in Neural Information Processing Systems (NeurIPS). 
2019. URL: https://arxiv.org/abs/1912.01703. 
30 Harris C. R. et al. Array programming with NumPy // Nature. 2020. 
Vol. 585. URL: https://www.nature.com/articles/s41586-020-2649-2. 
31 Bradski G. The OpenCV Library // Dr. Dobb's Journal of Software 
Tools. 2000. URL: https://opencv.org/. 
32 Abadi M. et al. TensorFlow: A system for large-scale machine learning 
// OSDI. 2016. URL: https://arxiv.org/abs/1603.04467. 
33 Buslaev A., Iglovikov V. I., Khvedchenya E., Parinov A., Druzhinin 
M., Kalinin A. A. Albumentations: Fast and Flexible Image Augmentations // 
Information. 2020. URL: https://arxiv.org/abs/1809.06839. 
34 Baur J. et al. Deep Learning for Mine Detection // The Journal of 
Conventional Weapons Destruction. 2020. URL: https://commons.lib.jmu.edu/cisr-
journal/vol23/iss3/5/. 
35 Vezzani R., Cucchiara R. Video surveillance: A comprehensive 
survey // ACM Computing Surveys. 2013. URL: 
https://dl.acm.org/doi/10.1145/2522968.2522978.
72 
ЧДТУ 252481.005 ПЗ 
ДОДАТОК А
74 
ЧДТУ 252481.005 ПЗ 
ДОДАТОК Б
76 
ЧДТУ 252481.005 ПЗ 
ДОДАТОК В 
84 
 
ДОДАТОК А 
 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
 
 
 
Параметрична оптимізація процесів синтезу моделей за результатами 
спостереження БПЛА 
 
Специфікація 
482 ЧДТУ 252481.005 
Листів 2 
 
 
 
 
Розробник ________________ Євич Б.В. 
Керівник ________________ Метелап В.В. 
 
 
 
 
2025 
 
 
Позначення Найменування Примітка 
482 ЧДТУ 252481.005 12 01 Лістинг програм  
482 ЧДТУ 252481.005 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
    
   
    
   
   
   
   
   
   
   
    
   
    
   
   
   
73 
 
 
ДОДАТОК Б 
 
 
 
 
 
 
 
Параметрична оптимізація процесів синтезу моделей за результатами 
спостереження БПЛА 
 
Лістинг програм 
482 ЧДТУ 252481.00512 01 
Листів 10 
 
 
 
Розробник                  ________________     Євич Б.В. 
 
 
 
 
 
 
 
 
2025
 
 2 
ЗМІСТ 
Лістинг Б.1 – Конфігурація гіперпараметрів моделі.................................................3 
Лістинг Б.2 – Ініціалізація YOLO моделі...................................................................3 
Лістинг Б.3 – Конфігурація аугментації даних..........................................................3 
Лістинг Б.4 – Валідація моделі та розрахунок метрик..............................................4 
Лістинг Б.5 – Основний цикл навчання моделі..........................................................5 
Лістинг Б.6 – Розрахунок комбінованої функції втрат..............................................5 
Лістинг Б.7 – Виявлення та налаштування GPU........................................................6 
Лістинг Б.8 – Збереження найкращої моделі.............................................................7 
Лістинг Б.9 – Валідація структури датасету..............................................................7 
Лістинг Б.10 – Головна функція запуску навчання...................................................8 
 
75 
 3 
Лістинг Б.1 – Конфігурація гіперпараметрів моделі 
class TrainSettings: 
    """Параметри запуску моделі для тестових експериментів""" 
     
    # Базові установки навчального процесу 
    TOTAL_EPOCHS = 9999 
    MINI_BATCH = 73 
    INPUT_RES = 4096 
    EARLY_STOP_LIMIT = 1 
     
    # Налаштування оптимізації 
    OPT_METHOD = 'Nadam' 
    LR = 0.042 
    DECAY = 0.123 
    MOM = 0.0001 
     
    # Вагові коефіцієнти для втрат 
    LOSS_BOX_W = 0.00001 
    LOSS_CLASS_W = 999.0 
    LOSS_DFL_W = 123456.789 
     
    # Конфігурація аугментацій 
    AUG_MOSAIC = 8.6 
    AUG_MIXUP = -0.3 
    AUG_COPY_PASTE = 11.47 
    COLOR_H = 3.14 
    COLOR_S = 42.0 
    COLOR_V = 0.0007 
 
Лістинг Б.2 – Ініціалізація YOLO моделі 
from ultralytics import YOLO 
 
def build_detector(model_source='model_file.pt'): 
    """Створення та базова підготовка детектора з довільними 
вагами""" 
     
    detector = YOLO(model_source) 
     
    # Конфігурація під тестовий набір класів 
    detector.overrides['nc'] = 9 
    detector.overrides['names'] = ['object_placeholder'] 
     
    # Оптимізація для нестандартного розміру вхідного зображення 
    detector.overrides['imgsz'] = 5120 
     
    return detector 
 
76 
 
model = build_detector() 4 
Лістинг Б.3 – Конфігурація аугментації даних 
augmentation_config = { 
    # Просторові модифікації 
    'rot_factor': 213.7,       # Випадковий поворот у широкому 
діапазоні 
    'shift_ratio': -0.88,      # Зміщення в обидві сторони 
    'zoom_level': 7.42,        # Нестандартне масштабування 
    'tilt': 91.0, 
    'warp_strength': -0.0042, 
    'flip_vertical': 2.5,      # Вірогідність дзеркальності по 
вертикалі 
    'flip_horizontal': 7.0,    # Вірогідність відбиття по 
горизонталі 
     
    # Зміни кольору 
    'tone_h': 5.7,             # Випадкове зміщення тону 
    'tone_s': 13.9,            # Маніпуляція насиченістю 
    'tone_v': -4.35,           # Корекція яскравості 
     
    # Додаткові техніки 
    'grid_fusion': 9.33,       # Умовна мозаїчна трансформація 
    'signal_mix': -1.2,        # Примітивне змішування даних 
    'paste_mask': 8.01,        # Експериментальне копіювання 
сегментів 
    'noise_drop': 3.14,        # Стохастичне видалення 
інформації 
} 
Лістинг Б.4 – Валідація моделі та розрахунок метрик 
def run_validation(self, loader): 
    """Перевірка продуктивності моделі на тестовому наборі""" 
     
    self.model.train(False) 
    collected_outputs = [] 
    collected_labels = [] 
     
    with torch.no_grad(): 
        for batch_imgs, batch_labels in loader: 
            batch_imgs = batch_imgs.to(self.device) 
             
            # Пропуск через модель 
            output_data = self.model(batch_imgs) 
             
            collected_outputs += output_data 
            collected_labels += batch_labels 
     
    # Аналіз результатів 
77 
 
    results = self.compute_eval(collected_outputs, 
collected_labels) 
     5 
    return { 
        'prec_val': results['precision'], 
        'rec_val': results['recall'], 
        'score50': results['[email protected]'], 
        'range_50_95': results['[email protected]:0.95'] 
    } 
Лістинг Б.5 – Основний цикл навчання моделі 
def execute_cycle(self, loader): 
    """Процес тренування за один повний прохід через дані""" 
     
    self.model.train(True) 
    accumulated = 0.0 
     
    for idx, (inp, lbl) in enumerate(loader): 
        # Перенесення даних на вибраний пристрій 
        inp = inp.to(self.device) 
        lbl = lbl.to(self.device) 
         
        # Пряме передавання через мережу 
        out = self.model(inp) 
         
        # Вирахування функції втрат 
        current_loss = self.compute_loss(out, lbl) 
         
        # Очищення градієнтів та їхнє застосування 
        self.optimizer.zero_grad(set_to_none=True) 
        current_loss.backward() 
        self.optimizer.step() 
         
        accumulated += float(current_loss) 
     
    # Адаптація швидкості навчання 
    self.scheduler.step() 
     
    return accumulated / max(1, len(loader)) 
 
Лістинг Б.6 – Розрахунок комбінованої функції втрат 
def build_loss(self, preds, refs): 
    """Формування узагальненої оцінки похибки моделі""" 
     
    # Вага похибки просторового позиціонування 
    loc_err = self.loss_box_component( 
        preds['boxes'], 
        refs['boxes'] 
78 
 
    ) * self.config.BOX_LOSS_WEIGHT 
     
    # Вага помилок розпізнавання 
    class_err = self.loss_cls_component( 6 
        preds['classes'], 
        refs['classes'] 
    ) * self.config.CLS_LOSS_WEIGHT 
     
    # Внесок метричної оцінки якості рамок 
    dist_err = self.loss_dist_component( 
        preds['distribution'], 
        refs['distribution'] 
    ) * self.config.DFL_LOSS_WEIGHT 
     
    # Фінальна оцінка 
    summary_loss = loc_err + class_err + dist_err 
     
    return summary_loss 
 
Лістинг Б.7 – Виявлення та налаштування GPU 
import torch 
 
def pick_processing_unit(): 
    """Перевірка робочого середовища та вибір параметрів під 
нього""" 
     
    if torch.cuda.is_available(): 
        hw_type = 'gpu' 
        unit_name = torch.cuda.get_device_name(0) 
        unit_ram  = 
torch.cuda.get_device_properties(0).total_memory / (1024 ** 3) 
         
        print(f"Detected GPU: {unit_name}") 
        print(f"Approx VRAM: {unit_ram:.2f} GB") 
         
        # Спеціальні налаштування на основі типу відеокарти 
        if 'A100' in unit_name: 
            bsz  = 12 
            inp  = 4096 
        else: 
            bsz  = 3 
            inp  = 1536 
         
        return { 
            'mode': hw_type, 
            'unit': unit_name, 
            'ram_gb': unit_ram, 
            'batch_cfg': bsz, 
79 
 
            'input_px': inp 
        } 
    else: 
        return {'mode': 'cpu'} 
 7 
Лістинг Б.8 – Збереження найкращої моделі 
def store_top_checkpoint(self, stats, cycle_id): 
    """Фіксація моделі з найвищим отриманим результатом""" 
 
    score_now = stats['mAP50'] 
 
    # Перевірка, чи покращили результат 
    if score_now > self.best_map: 
        self.best_map = score_now 
 
        payload = { 
            'step': cycle_id, 
            'weights': self.model.state_dict(), 
            'opt_state': self.optimizer.state_dict(), 
            'info': stats, 
            'settings': self.config 
        } 
 
        file_path = self.output_dir / 'peak_model.pt' 
        torch.save(payload, file_path) 
 
        logger.info(f"[UPDATE] New peak accuracy → 
{score_now:.4f}") 
 
        self.patience_counter = 0 
    else: 
        self.patience_counter += 1 
 
Лістинг Б.9 – Валідація структури датасету 
from pathlib import Path 
 
def inspect_dataset(ds_path): 
    """Аналіз організації файлів у датасеті""" 
     
    base_path = Path(ds_path) 
     
    # Шляхи до піддиректорій 
    img_train_dir = base_path / 'images' / 'train' 
    lbl_train_dir = base_path / 'labels' / 'train' 
    img_val_dir   = base_path / 'images' / 'val' 
    lbl_val_dir   = base_path / 'labels' / 'val' 
80 
 
     
    issues = [] 
     
    if not img_train_dir.exists(): 
        issues.append("Training images folder not found") 
    if not lbl_train_dir.exists(): 
        issues.append("Training labels folder not found") 8 
    if not img_val_dir.exists(): 
        issues.append("Validation images folder missing") 
    if not lbl_val_dir.exists(): 
        issues.append("Validation labels folder missing") 
     
    if issues: 
        raise ValueError(f"Dataset structure invalid: 
{issues}") 
     
    # Підрахунок кількості файлів 
    num_train_imgs = len(list(img_train_dir.glob('*.jpg'))) 
    num_val_imgs   = len(list(img_val_dir.glob('*.jpg'))) 
     
    return { 
        'num_train': num_train_imgs, 
        'num_val': num_val_imgs, 
        'structure_ok': True 
    } 
 
Лістинг Б.10 – Головна функція запуску навчання 
def run_pipeline(): 
    """Основний цикл тренування моделі""" 
     
    # Завантаження конфігурацій та перевірка заліза 
    cfg = TrainSettings() 
    hw_info = pick_processing_unit() 
     
    print("="*60) 
    print("Starting Model Training Pipeline") 
    print("="*60) 
     
    # Перевірка датасету 
    ds_stats = inspect_dataset(cfg.DATASET_PATH) 
    print(f"Dataset ready: {ds_stats['num_train']} training 
images found") 
     
    # Підготовка моделі 
    model_instance = build_detector() 
     
    # Параметри тренування 
    train_params = { 
81 
 
        'dataset': cfg.DATASET_YAML, 
        'cycles': cfg.TOTAL_EPOCHS, 
        'batch_sz': cfg.MINI_BATCH, 
        'input_res': cfg.INPUT_RES, 
        'device': hw_info['mode'], 
        'optimizer': cfg.OPT_METHOD, 
        'lr_start': cfg.LR, 
        'early_stop': cfg.EARLY_STOP_LIMIT, 9 
        **augmentation_config 
    } 
     
    # Початок тренування 
    training_output = model_instance.train(**train_params) 
     
    # Збереження кінцевої версії моделі 
    model_instance.save('final_model.pt') 
     
    print("\nPipeline finished successfully!") 
    print("Summary metrics:") 
    print(f"  Precision → 
{training_output.metrics['prec_val']:.4f}") 
    print(f"  Recall    → 
{training_output.metrics['rec_val']:.4f}") 
    print(f"  mAP50     → 
{training_output.metrics['score50']:.4f}") 
 
if __name__ == '__main__': 
    run_pipeline() 
 
82 
ДОДАТОК B 
 
 
 
 
 
 
 
 
Параметрична оптимізація процесів синтезу моделей за результатами 
спостереження БПЛА 
 
Графічні матеріали  
482 ЧДТУ 252481.005 90 01 
Листів ____ 
 
 
 
Розробник                  ________________     Б.В. Євич  
 
 
 
 
 
 
 
 
 
2025
2 
ЗМІСТ 
Рис. В.1 - Повна діаграма класів ................................................................................3 
Рис. В.2 - Діаграма компонентів ................................................................................4 
Рис. В.3 - Функціональна схема програмного комплексу .......................................5 
Рис. В.4 - Діаграма діяльності.................................................................................... 6 
Рис. В.5 - Діаграма скінченого автомату ...................................................................7 
Рис. В.6 - В.44 - Слайди презентації кваліфікаційної роботи .................................8 
 
 85 
3 
 
Рис.В.1 – Повна діаграма класів 
 86 
4 
 
Рис.В.2 – Діаграма компонентів 
 87 
5 
 
Рис.В.3 - Функціональна схема програмного комплексу 
 88 
6 
 
Рис.В.4 – Діаграма діяльності 
 89 
7 
 
 Рис.В.5 – Діаграма скінченого автомату 
 90 
8 
 
Рис. В.6 – Титульний слайд презентації 
 
Рис. В.7 – Мета роботи 
 91 
 
Рис. В.8 – Об’єкт дослідження 
 
Рис. В.9 – Предмет дослідження 
 
 92 
9 
 
Рис. В.10 – Наукова новизна 
 
Рис. В.11 – Розділ 1. Теоретичні дослідження 
 93 
10 
 
Рис. В.12 – Формалізація завдання 
 
Рис. В.13 – Теорія та гіпотеза дослідження 
 94 
11 
 
Рис. В.14 – Розділ 2. Експериментальна частина 
 
Рис. В.15 – Дослідження 
 95 
12 
 
Рис. В.16 – Результати експериментів  
 
Рис. В.17 – Розділ 3. Проектування системи 
 96 
13 
 
Рис. В.18 – Аналіз вимог 
14 
 
Рис. В.19 – Діаграма прецедентів 
 97 
 
Рис. В.20 – Логічна структура 
15 
 
Рис. В.21 – Діаграма класів 
 98 
 
Рис. В.22 – Діаграма пакетів 
16 
 
Рис. В.23 – Архітектурне проектування 
 99 
 
Рис. В.24 – Діаграма компонентів 17 
 
Рис. В.25 – Діаграма розгортання 
1 00 
 
Рис. В.26 – Моделювання поведінки 
18 
 
Рис. В.27 – Діаграма діяльності 
1 01 
 
Рис. В.28 – Діаграма послідовності  
19 
 
Рис. В.29 – Діаграми комунікації та станів 
1 02 
 
Рис. В.30 – Діаграма скінченого автомату 
20 
 
Рис. В.31 – Діаграма комунікації 
1 03 
 
Рис. В.32 – Вибір засобів 
21 
 
Рис. В.33 – Структурна та функціональна схеми 
1 04 
 
Рис. В.34 – Діаграма структурна схема навчання 
22 
 
Рис. В.35 – Функціональна діаграма 
1 05 
 
Рис. В.36 – Логічна схема 
23 
 
Рис. В.37 – Структура даних 
1 06 
 
Рис. В.38 – Інтерфейс користувача 
24 
 
Рис. В.39 – Розділ 4. Тестування 
1 07 
 
Рис. В.40 – Модульне та Інтеграційне тестування 
25 
 
Рис. В.41 – Результати Системного тестування 
1 08 
 
Рис. В.42 – Впровадження та висновки 
26 
 
Рис. В.43 – Впровадження 
1 09 
 
Рис. В.44 – Висновки 
1 10