ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/10071Full metadata record
| DC Field | Value | Language |
|---|---|---|
| dc.contributor.advisor | Зубко, Ігор Анатолійович | - |
| dc.contributor.author | Лисенко, Тарас Володимирович | - |
| dc.date.accessioned | 2026-10-22T12:12:16Z | - |
| dc.date.available | 2026-10-22T12:12:16Z | - |
| dc.date.issued | 2026-06 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/10071 | - |
| dc.description.abstract | У кваліфікаційній роботі розроблено AI систему технічної підтримки користувача на базі вбудованого пристрою для автоматизації опрацювання звернень, діагностики типових проблем і надання рекомендацій щодо їх усунення. Проведено аналіз сучасних систем технічної підтримки на основі чат-ботів, голосових асистентів і великих мовних моделей, а також досліджено особливості використання вбудованих пристроїв з урахуванням обмежень обчислювальних ресурсів, пам’яті та енергоспоживання. Обґрунтовано вибір методів обробки запитів користувача, класифікації проблем і формування відповідей. Розроблено модель взаємодії AI модуля, бази знань і вбудованого пристрою, а також алгоритм функціонування системи, що передбачає приймання повідомлень, попередню обробку тексту, визначення категорії проблеми, аналіз технічного стану пристрою, пошук відповідної інформації та формування рекомендацій. Реалізовано модульну структуру системи, яка забезпечує автоматизоване опрацювання типових звернень, уточнювальний діалог і передавання складних випадків фахівцю. Передбачено можливість виконання базових перевірок локально та залучення зовнішнього AI компонента для складніших запитів, що сприяє автономності й стабільності роботи за умов нестабільного мережевого з’єднання. Проведено тестування та оцінювання ефективності розробленого рішення. Практичне значення роботи полягає в можливості застосування запропонованої системи для автоматизації технічної підтримки користувачів, скорочення часу опрацювання звернень і зменшення навантаження на фахівців у сфері побутової техніки, систем «розумного дому», промислового обладнання та спеціалізованих комп’ютерних систем. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | штучний інтелект, AI система, технічна підтримка користувачів, вбудований пристрій, обробка запитів, великі мовні моделі, LLM, база знань, класифікація проблем, діагностика несправностей, генерація відповідей, алгоритм роботи системи, модульна архітектура, автоматизація технічної підтримки, тестування програмного забезпечення | uk_UA |
| dc.title | АІ система технічної підтримки користувача на базі вбудованого пристрою | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Appears in Collections: | 123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи) | |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Б_123_2026_Лисенко.pdf Restricted Access | 893.34 kB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ ПОЯСНЮВАЛЬНА ЗАПИСКА до кваліфікаційної роботи освітнього ступеня «бакалавр» на тему: «AI система технічної підтримки користувача на базі вбудованого пристрою» Виконав здобувач вищої освіти 4 курсу, групи СКС-2207 Спеціальності 123 «Комп’ютерна інженерія» (освітня програма «Спеціалізовані комп’ютерні системи») Тарас ЛИСЕНКО (ім’я та ПРІЗВИЩЕ) Керівник Ігор ЗУБКО (ім’я та ПРІЗВИЩЕ) Рецензент (ім’я та ПРІЗВИЩЕ) Захист дозволяю: зав. кафедри, д.т.н., професор Валентина ЛУКАШЕНКО (підпис) (ім’я та ПРІЗВИЩЕ) Черкаси 2026 1 ЗМІСТ ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ…………………………………..…………………4 ВСТУП…………………………………………………………………………………..……….6 ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ……………………………………….….11 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ ЗАВДАНЬ….….11 1.1 Аналіз сучасних AI систем технічної підтримки користувачів…….….11 1.1.1 Поняття, функції та класифікація AI систем технічної підтримки………………………………………………………………………..…11 1.1.2 Огляд сучасних рішень на основі чат-ботів, голосових асистентів та LLM………………………………………………………………..17 1.2 Особливості використання вбудованих пристроїв у системах підтримки…………………………………………………………………………….…..24 1.2.1 Архітектура та апаратні можливості вбудованих пристроїв………………………………………………………………….………..24 1.2.2 Обмеження обчислювальних ресурсів, пам’яті та енергоспоживання………………………………………………….………...30 1.3 Формування вимог і завдань до AI системи технічної підтримки…...37 1.3.1 Визначення функціональних та нефункціональних вимог до системи……………………………………………………………………….…37 1.3.2 Постановка задачі розроблення AI системи на базі вбудованого пристрою………………………………………………………….43 Висновки до розділу 1………………………………………………………………...49 2. МЕТОДИ АБО МОДЕЛІ СТВОРЕННЯ КОМПОНЕНТІВ ТА ЇХ ДОСЛІДЖЕННЯ………………………………………………………………………………51 2.1 Вибір методів обробки запитів користувача та формування відповідей………………………………………………………………………………...51 2.2 Модель взаємодії AI модуля, бази знань та вбудованого пристрою………………………………………………………………………………….57 Висновки до розділу 2……………………………………………….………………...63 2 3. АЛГОРИТМИ, ПРОГРАМНІ ЗАСОБИ ДЛЯ ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ МЕТОДІВ, МОДЕЛЕЙ, КОМПОНЕНТІВ……………….…….64 3.1 Розроблення алгоритму роботи AI системи технічної підтримки користувача……………………………………………………………………………….64 3.2 Програмна реалізація, тестування та оцінювання ефективності системи………………………………………………………………………………….…72 Висновки до розділу 3…………………………………………………………………94 ВИСНОВКИ………………………………………………………………………………….…96 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….…………..99 Додаток А Структура запису бази знань AI системи технічної підтримки…....105 Додаток Б Модель взаємодії AI модуля, бази знань та вбудованого пристрою……………………………………………………………………………..……….…108 Додаток В Послідовність етапів алгоритму роботи AI системи технічної підтримки……………………………………………………………………………………….109 3 ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ AI Artificial Intelligence, штучний інтелект. Application Programming Interface, програмний інтерфейс API застосунку. Bidirectional Encoder Representations from Transformers, мовна BERT модель для опрацювання природної мови. Bluetooth Low Energy, енергоощадна технологія бездротового BLE зв’язку Bluetooth. алгоритм інформаційного пошуку для визначення релевант- BM25 ності документа або фрагмента тексту запиту користувача. Compute Unified Device Architecture, архітектура паралельних CUDA обчислень NVIDIA. Customer Experience, клієнтський досвід / досвід взаємодії CX користувача. Facebook AI Similarity Search, інструмент для пошуку подібних FAISS векторних представлень. Giga Floating Point Operations Per Second, мільярди операцій з GFLOPS рухомою комою за секунду. Inter-Integrated Circuit, послідовна шина для зв’язку між I2C інтегральними схемами. INT8 8-бітний цілочисельний формат обчислень. LLM Large Language Model, велика мовна модель. Low Power Double Data Rate 4, тип енергоощадної оперативної LPDDR4 пам’яті. Low Power Double Data Rate 5, тип енергоощадної оперативної LPDDR5 пам’яті нового покоління. Retrieval-Augmented Generation, генерація відповіді з доповне- RAG ним пошуком у базі знань. 4 SoC System-on-Chip, система на кристалі. Serial Peripheral Interface, послідовний периферійний SPI інтерфейс. SRAM Static Random Access Memory, статична оперативна пам’ять. засіб програмування та налагодження мікроконтролерів STLINK STM32. Term Frequency – Inverse Document Frequency, статистичний TF-IDF метод оцінювання важливості слова у тексті. TOPS Tera Operations Per Second, трильйони операцій за секунду. Tensor Processing Unit, тензорний процесор для задач машин- TPU ного навчання. Universal Asynchronous Receiver-Transmitter, універсальний UART асинхронний приймач-передавач. USB Universal Serial Bus, універсальна послідовна шина. Wi-Fi технологія бездротового мережевого зв’язку. ГБ гігабайт. КБ кілобайт. 5 ВСТУП Актуальність дослідження. Сучасний етап розвитку інформаційних технологій характеризується активним упровадженням систем штучного інтелекту в різні сфери людської діяльності, зокрема в обслуговування користувачів, автоматизацію технічної підтримки, діагностику несправностей, обробку запитів і взаємодію людини з комп’ютерними системами. Традиційні форми технічної підтримки, що ґрунтуються переважно на участі оператора або фахівця служби підтримки, не завжди забезпечують достатню швидкість реагування, цілодобову доступність, персоналізовану допомогу та ефективне опрацювання типових проблем користувачів. У зв’язку з цим особливої актуальності набуває створення AI систем технічної підтримки, здатних аналізувати звернення користувача, визначати характер проблеми, пропонувати алгоритми її розв’язання та адаптувати відповіді до конкретної ситуації. Використання таких систем дозволяє зменшити навантаження на фахівців технічної підтримки, скоротити час очікування відповіді, підвищити якість обслуговування та забезпечити більш зручну взаємодію користувача з технічним пристроєм або програмно-апаратним комплексом. Особливого значення ця проблема набуває в контексті розвитку вбудованих пристроїв, які дедалі частіше використовуються в побутовій техніці, промислових системах, медичних приладах, транспортних засобах, системах «розумного дому», засобах моніторингу та керування. На відміну від звичайних комп’ютерних систем, вбудовані пристрої часто мають обмежені обчислювальні ресурси, пам’ять, енергоспоживання та специфічні вимоги до швидкодії, стабільності й автономності роботи. Тому розроблення AI системи технічної підтримки на базі такого пристрою потребує не лише використання алгоритмів штучного інтелекту, а й урахування архітектури апаратної платформи, особливостей 6 програмного забезпечення, каналів зв’язку, інтерфейсів користувача та вимог до надійності. Важливість дослідження зумовлена також необхідністю підвищення зручності, безпеки та ефективності взаємодії користувача з технічними системами. В сучасних умовах користувачі очікують не лише коректної роботи пристрою, а й швидкого отримання зрозумілих рекомендацій у разі помилки, збою, неправильного налаштування або потреби в консультації. AI система технічної підтримки може виконувати функції інтелектуаль- ного помічника: розпізнавати типові запити, аналізувати симптоми несправностей, формувати покрокові інструкції, попереджати про можливі помилки в експлуатації та накопичувати інформацію для подальшого вдосконалення відповідей. Водночас розроблення такої системи передбачає розв’язання низки технічних завдань, пов’язаних із вибором моделі штучного інтелекту, оптимізацією алгоритмів для роботи на обмежених ресурсах, забезпеченням захисту даних користувача, стабільністю програмного коду та зручністю інтерфейсу. Проблематика створення інтелектуальних комп’ютерних систем, штучного інтелекту, людино-машинної взаємодії та вбудованих пристроїв знайшла відображення у працях багатьох зарубіжних і українських науковців. Серед зарубіжних дослідників вагомий внесок у розвиток теорії штучного інтелекту, інтелектуальних агентів, діалогових систем, комп’ютерної логіки та вбудованих систем зробили М. Барр [50], Дж. Вейзенбаум [57], В. Вольф [58], Е. Лі [51], Дж. Маккарті [52], М. Мінскі [53], А. Ньюелл [54], П. Норвіг [55], С. Рассел [55], Г. Саймон [54], А. Тюрінг [56]. Їх праці стали основою для формування підходів до побудови інтелектуальних програмних систем, автоматизованого прийняття рішень, обробки запитів користувача та організації взаємодії між людиною і технічним середовищем. Серед українських науковців питання розвитку комп’ютерних систем, кібернетики, інформаційних 7 технологій, інтелектуальних систем і цифрових засобів опрацювання інформації досліджували А. Анісімов [3], А. Білощицький [8], М. Жалдак [17], Н. Морзе [29], В. Пасічник [7; 36], І. Сергієнко [40; 41], О. Спірін [45; 46]. Їх наукові напрацювання є важливими для розуміння теоретичних і прикладних засад створення сучасних інформаційних та інтелектуальних систем, однак питання розроблення AI системи технічної підтримки користувача саме на базі вбудованого пристрою потребує подальшого опрацювання з урахуванням сучасних вимог до автономності, швидкодії, захисту даних і зручності використання. Зв’язок роботи з науковими програмами, планами, темами. Бакалаврська робота виконана відповідно до навчальних і науково- дослідних напрямів кафедри, пов’язаних із розробленням спеціалізованих комп’ютерних систем, вбудованих пристроїв та інтелектуальних інформаційних технологій. Обрана тема узгоджується з планами організації щодо дослідження й упровадження програмно-апаратних рішень, спрямованих на автоматизацію технічної підтримки користувачів та підвищення ефективності взаємодії людини з комп’ютерними системами. Мета дослідження полягає у розробленні AI системи технічної підтримки користувача на базі вбудованого пристрою для автоматизації обробки запитів, надання рекомендацій та підвищення ефективності взаємодії користувача з комп’ютерною системою. Завдання дослідження: 1. Проаналізувати поняття, функції, класифікацію та сучасний стан розвитку AI систем технічної підтримки користувачів. 2. Дослідити особливості застосування вбудованих пристроїв у системах технічної підтримки з урахуванням їх архітектури, апарат- них можливостей, обмежень пам’яті, обчислювальних ресурсів та енергоспоживання. 8 3. Сформувати функціональні й нефункціональні вимоги до AI системи технічної підтримки користувача на базі вбудованого пристрою. 4. Обґрунтувати вибір методів обробки запитів користувача, формування відповідей та побудувати модель взаємодії AI модуля, бази знань і вбудованого пристрою. 5. Розробити алгоритм роботи AI системи технічної підтримки користувача, здійснити її програмну реалізацію, тестування та оцінювання ефективності. Об’єкт дослідження – процес функціонування AI систем технічної підтримки користувачів на базі вбудованих пристроїв. Предмет дослідження – методи, моделі, алгоритми та програмні засоби побудови AI системи технічної підтримки користувача з використанням вбудованого пристрою. Методи дослідження. В роботі використано метод аналізу та узагальнення наукових джерел для дослідження сучасних AI систем технічної підтримки користувачів і особливостей застосування вбудованих пристроїв. Для формування структури та функціональних можливостей системи застосовано методи системного аналізу, моделювання та проєктування програмно-апаратних комплексів. Під час розроблення AI системи використано методи обробки запитів користувача, алгоритми машинного навчання та технології створення вбудованих систем. Для перевірки працездатності та оцінювання ефективності розробленої системи застосовано методи програмного тестування, порівняння та експериментального аналізу результатів роботи системи. Наукова новизна одержаних результатів полягає у розробленні моделі AI системи технічної підтримки користувача, адаптованої до роботи на базі вбудованого пристрою з урахуванням обмежених обчислювальних ресурсів і пам’яті. У роботі вдосконалено підхід до організації взаємодії між AI модулем, базою знань та вбудованим 9 пристроєм для забезпечення швидкого опрацювання запитів користувача. Набули подальшого розвитку методи обробки звернень користувачів і формування відповідей у системах технічної підтримки з використанням технологій штучного інтелекту. Також запропоновано алгоритм функціонування AI системи технічної підтримки, який забезпечує підвищення ефективності та автономності роботи програмно-апаратного комплексу. Практичне значення одержаних результатів полягає у можливості використання розробленої AI системи технічної підтримки для автоматизації обробки запитів користувачів та надання оперативної допомоги в роботі з технічними пристроями. Запропоновані алгоритми та програмні рішення можуть бути застосовані під час створення вбудованих систем у сфері побутової техніки, систем «розумного дому», промислових і спеціалізованих комп’ютерних пристроїв. Результати дослідження можуть використовуватися для підвищення ефективності функціонування служб технічної підтримки, зменшення навантаження на операторів та скорочення часу обробки звернень користувачів. Апробація дослідження. Публікації. Структура та обсяг бакалаврської роботи. Робота складається зі вступу, трьох розділів, семи підрозділів, висновків до кожного розділу, загальних висновків, списку використаних джерел та додатків. Загальний обсяг роботи становить 110 сторінок комп'ютерного тексту. Основний зміст викладено на 98 сторінках. Список використаних джерел складається з 58 найменувань, з них 9 іноземною мовою. 10 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ ЗАВДАНЬ 1.1 Аналіз сучасних AI систем технічної підтримки користувачів 1.1.1 Поняття, функції та класифікація AI систем технічної підтримки AI система технічної підтримки користувачів є програмно-апаратним або програмним засобом, який використовує методи штучного інтелекту для автоматизованого опрацювання звернень, аналізу проблем, формування відповідей і надання рекомендацій щодо використання технічних пристроїв, програмного забезпечення або цифрових сервісів. На відміну від звичайних довідкових систем, які переважно працюють за принципом пошуку готової інформації, AI система здатна інтерпретувати зміст запиту, визначати намір користувача, зіставляти його з наявними знаннями та формувати відповідь у зручній для сприйняття формі [9, с. 112]. Поняття AI системи технічної підтримки тісно пов’язане з розвитком інтелектуальних систем, здатних вести діалог із користувачем природною мовою. Однією з ранніх спроб створення програми для діалогової взаємодії стала система ELIZA [57], розроблена Дж. Вейзенбаумом [57], яка показала можливість моделювання текстового спілкування між людиною та комп’ютером. Хоча такі ранні системи не мали сучасного рівня розуміння змісту повідомлень, вони заклали важливі передумови для розвитку чат-ботів, віртуальних консультантів і засобів автоматизованої підтримки. Сьогодні AI системи технічної підтримки значно перевищують можливості простих сценарних програм, оскільки використовують обробку природної мови, машинне навчання, пошук у базах знань, генеративні моделі та механізми контекстного аналізу [9, с. 113]. 11 Основною функцією AI систем технічної підтримки є приймання та первинне опрацювання звернень користувачів. Система аналізує текстовий або голосовий запит, визначає ключові слова, технічні ознаки проблеми, тип пристрою чи програмного середовища, а також очікувану дію з боку користувача. У сучасних віртуальних агентах для цього застосовуються обробка природної мови, інтелектуальний пошук і засоби автоматизації дій, що дозволяє не тільки вести діалог, а й виконувати певні операції відповідно до запиту користувача. Наприклад, AI система може допомогти відновити доступ до облікового запису, пояснити порядок налаштування пристрою, визначити причину помилки або передати складне звернення фахівцю технічної підтримки. Важливою функцією таких систем є класифікація звернень за типом проблеми, рівнем складності, терміновістю та можливістю автоматичного розв’язання. Коли користувач описує несправність або труднощі в роботі з пристроєм, система має відокремити типові запити від нестандартних, визначити, чи потрібна проста інструкція, додаткова діагностика або втручання оператора. У сфері підтримки користувачів AI технології застосовуються для аналізу, структурування, пріоритизації звернень і підготовки інформації для подальшого опрацювання [17, с. 34]. Ще однією суттєвою функцією AI систем є формування відповіді, яка має бути не лише технічно правильною, а й зрозумілою для користувача з різним рівнем підготовки. Система повинна враховувати, що користувач може не знати спеціальної термінології, неточно описувати проблему або використовувати побутові формулювання замість технічних понять. Саме тому сучасні чат-боти та віртуальні помічники застосовують технології розпізнавання намірів, виділення сутностей, аналізу контексту та генерації тексту. У працях С. Рассела [55] і П. Норвіга [55] штучний інтелект розглядається як напрям, пов’язаний зі створенням агентів, здатних сприймати інформацію із середовища та діяти відповідно до поставленої 12 мети, що добре узгоджується з принципом роботи інтелектуальної технічної підтримки [9, с. 114]. AI системи технічної підтримки можуть виконувати діагностичну функцію, що полягає у виявленні можливої причини проблеми на основі описаних симптомів. Наприклад, якщо користувач повідомляє про відсутність з’єднання, некоректне завантаження програми або помилку під час роботи пристрою, система може поставити уточнювальні запитання, перевірити типові причини та запропонувати послідовність дій. Така діагностика не завжди замінює фахівця, проте вона дозволяє швидко усунути прості несправності й підготувати більш повну інформацію для спеціаліста у складних випадках. Сучасні AI чат-боти у сфері підтримки використовують текстові або голосові інтерфейси та здатні допомагати користувачам із запитами, що робить їх важливим інструментом цифрового обслуговування. Завдяки цьому технічна підтримка стає більш доступною, оскільки користувач може отримати первинну допомогу без очікування відповіді оператора [17, с. 35]. Окреме місце серед функцій AI систем займає робота з базою знань, яка містить інструкції, технічну документацію, відповіді на типові запитання, описи помилок, алгоритми усунення несправностей і правила експлуатації пристроїв. AI модуль не повинен формувати відповідь довільно, адже в технічній підтримці важливо забезпечити точність, узгодженість і відповідність рекомендацій реальним характеристикам системи. Тому ефективна система підтримки має поєднувати мовні можливості штучного інтелекту з перевіреною інформаційною основою, що зменшує ризик помилкових або неповних відповідей. У цьому контексті важливими є наукові ідеї С. Рассела [55], який розглядав обчислювальні системи як засіб автоматизації опрацювання інформації та управління складними процесами [14, с. 58]. 13 Класифікувати AI системи технічної підтримки можна за кількома ознаками, зокрема за формою взаємодії з користувачем, рівнем автономності, способом обробки запитів, джерелом знань і сферою застосування. За формою взаємодії виокремлюють текстові чат-боти, голосові асистенти, комбіновані системи та віртуальних агентів, інтегрованих у вебсайти, мобільні застосунки, сервісні платформи або пристрої. Чат-бот у загальному розумінні є комп’ютерною програмою, що імітує розмову з кінцевим користувачем, однак не всі чат-боти використовують штучний інтелект, оскільки частина з них працює лише за попередньо заданими правилами. У технічній підтримці найбільше значення мають саме AI орієнтовані системи, які можуть працювати з різними формулюваннями запитів, розпізнавати контекст і гнучко добирати відповідь [1, с. 75]. За рівнем складності AI системи технічної підтримки можна поділити на сценарні, інтелектуальні пошукові, генеративні та агентні. Сценарні системи діють за заздалегідь визначеними правилами, тому добре підходять для простих типових запитів, але мають обмежені можливості в нестандартних ситуаціях. Інтелектуальні пошукові системи можуть аналізувати формулювання користувача й знаходити релевантну інформацію в базі знань, тоді як генеративні моделі здатні створювати відповіді природною мовою на основі великого обсягу даних і контексту звернення. Агентні системи є складнішими, оскільки можуть не лише відповідати, а й виконувати дії, наприклад створювати заявку, перевіряти стан сервісу, передавати звернення відповідальному фахівцю або ініціювати процедуру налаштування [14, с. 60]. За способом обробки звернень AI системи можуть бути побудовані на правилах, методах машинного навчання, великих мовних моделях або комбінованому підході. Системи, що базуються на правилах, забезпечують високу передбачуваність, однак потребують постійного ручного оновлення 14 сценаріїв і не завжди коректно реагують на нестандартні формулювання. Методи машинного навчання дають змогу виявляти закономірності у зверненнях користувачів, класифікувати проблеми й покращувати точність відповідей на основі накопичених даних. Великі мовні моделі використовуються для більш природної комунікації, пояснення складних дій простішою мовою та формування відповідей із урахуванням контексту діалогу [1, с. 76]. За сферою застосування AI системи технічної підтримки можуть обслуговувати програмне забезпечення, апаратні засоби, мережеві сервіси, побутові пристрої, промислове обладнання, освітні платформи або спеціалізовані комп’ютерні системи. У випадку програмного забезпечення вони найчастіше пояснюють функції, допомагають усувати помилки, супроводжують процес налаштування та відповідають на запитання щодо використання. У сфері апаратних засобів такі системи можуть надавати інструкції щодо підключення, перевірки параметрів, заміни компонентів або виконання базової діагностики. У працях Е. Лі [51] значну увагу приділено кіберфізичним і вбудованим системам, у яких програмні засоби тісно пов’язані з фізичними процесами, датчиками, виконавчими елементами та обмеженнями реального середовища. Для AI технічної підтримки це має важливе значення, оскільки система повинна враховувати не лише інформаційний запит користувача, а й особливості конкретного пристрою [1, с. 77]. Особливістю сучасних AI систем технічної підтримки є здатність працювати в багатоканальному середовищі. Користувач може звертатися через вебчат, месенджер, мобільний застосунок, голосовий канал, електронну пошту або інтерфейс самого пристрою, а система повинна зберігати логіку взаємодії незалежно від каналу. Це дає змогу забезпечити безперервність обслуговування, коли користувач не змушений повторно описувати проблему після переходу з одного способу комунікації на 15 інший. Сучасні системи розмовного штучного інтелекту використовують машинне навчання й обробку природної мови для розпізнавання текстових і мовленнєвих повідомлень та наближення взаємодії до природного людського спілкування [27, с. 121]. AI системи технічної підтримки також класифікують за ступенем участі людини в процесі обслуговування. Повністю автоматизовані системи самостійно приймають запит, аналізують його, формують відповідь і завершують взаємодію, якщо проблема розв’язана. Напів- автоматизовані системи виконують первинне опрацювання, збирають необхідні дані, пропонують типові рішення, а в разі складного випадку передають звернення оператору разом із контекстом попереднього діалогу. Важливим критерієм оцінювання AI систем технічної підтримки є якість відповіді, яка залежить від точності розпізнавання запиту, повноти бази знань, коректності алгоритмів і здатності системи підтримувати контекст діалогу. Якщо система не розуміє сутність проблеми або надає загальні поради без урахування конкретної ситуації, користувач втрачає довіру до автоматизованої підтримки. Тому сучасні рішення мають забезпечувати не лише швидкість, а й релевантність, послідовність, безпечність і зрозумілість рекомендацій. Для технічної підтримки важливою є також можливість пояснити користувачеві послідовність дій, попередити про ризики та запропонувати альтернативні варіанти, якщо перше рішення не дало результату. Якісна AI система повинна працювати як інтелектуальний посередник між користувачем і складною технічною інформацією, перетворюючи її на доступні інструкції [21, с. 122]. Сучасні AI системи технічної підтримки мають значний потенціал, однак їх функціонування пов’язане з низкою обмежень. Вони можуть помилятися під час інтерпретації нечітких запитів, неправильно визначати намір користувача, формувати надто загальні відповіді або не враховувати специфіку конкретного обладнання. Особливої уваги потребують питання 16 захисту персональних даних, безпеки передавання інформації, контролю достовірності відповідей і запобігання некоректним технічним рекомендаціям. У випадку вбудованих пристроїв додатковими чинниками є обмежена пам’ять, невисока обчислювальна потужність, вимоги до енергоспоживання та необхідність стабільної роботи в реальному часі. Через це AI система підтримки користувача повинна бути не лише інтелектуальною, а й технічно узгодженою з можливостями пристрою, на якому вона функціонує [42, с. 10]. Отже, AI системи технічної підтримки користувачів є важливим напрямом розвитку сучасних комп’ютерних технологій, оскільки вони поєднують автоматизацію, обробку природної мови, бази знань, машинне навчання та інтерактивну взаємодію з користувачем. 1.1.2 Огляд сучасних рішень на основі чат-ботів, голосових асистентів та LLM Сучасні AI системи технічної підтримки користувачів дедалі частіше формуються на основі трьох взаємопов’язаних технологічних напрямів: чат-ботів, голосових асистентів і великих мовних моделей, які позначаються скороченням LLM. Чат-боти забезпечують текстову взаємодію з користувачем, голосові асистенти дають змогу керувати системою за допомогою мовлення, а LLM розширюють можливості автоматизованої підтримки завдяки здатності працювати з природною мовою, контекстом і складними формулюваннями запитів [33, с. 64]. У технічній підтримці ці рішення використовуються для приймання звернень, пошуку інформації, пояснення інструкцій, діагностики типових проблем, створення заявок і передавання складних випадків оператору [33, с. 65]. 17 Чат-боти є одним із найпоширеніших інструментів автоматизованої технічної підтримки, оскільки вони можуть працювати у вебсайтах, мобільних застосунках, месенджерах, корпоративних платформах і сервісних кабінетах. У найпростішому варіанті чат-бот відповідає за заздалегідь визначеними сценаріями, коли користувач обирає потрібну тему або вводить типове запитання, а система надає готову відповідь. Складніші чат-боти використовують обробку природної мови, що дозволяє їм аналізувати зміст повідомлення, розпізнавати намір користувача та добирати відповідь не лише за ключовими словами, а й за контекстом звернення. В сучасному розумінні чат-бот є програмою, яка імітує діалог із користувачем, проте його інтелектуальність залежить від того, чи застосовуються в ньому технології штучного інтелекту, машинного навчання та мовного аналізу. Наприклад, IBM визначає чат-ботів як програми для імітації спілкування з кінцевими користувачами, водночас підкреслюючи різницю між простими сценарними ботами та AI орієнтованими системами [47, с. 11]. У сфері технічної підтримки чат-боти виконують важливу функцію первинного контакту з користувачем, оскільки саме на цьому етапі потрібно швидко зрозуміти суть проблеми й надати початкову допомогу. Такі системи можуть збирати інформацію про пристрій, версію програмного забезпечення, характер помилки, час виникнення збою та дії, які користувач уже виконував. Це дозволяє не тільки надати рекомендацію, а й підготувати структуроване звернення для фахівця, якщо автоматичного розв’язання недостатньо. Значною перевагою чат-ботів є їхня здатність працювати цілодобово й одночасно обслуговувати велику кількість користувачів без зниження швидкості відповіді. Унаслідок цього вони стали поширеним інструментом у службах підтримки програмних продуктів, онлайн-сервісів, телекомунікаційних компаній, банківських застосунків і платформ електронної комерції [47, с. 12]. 18 Одним із найбільш відомих прикладів використання великих мовних моделей у діалоговій взаємодії є ChatGPT, який працює у форматі розмовного AI помічника. Його особливість полягає в тому, що система може підтримувати діалог, відповідати на уточнювальні запитання, пояснювати поняття, допомагати з аналізом інформації, узагальненням текстів і пошуком способів розв’язання задач. OpenAI описує ChatGPT як модель, що взаємодіє у розмовній формі, може відповідати на додаткові запитання, визнавати помилки, уточнювати некоректні припущення й відхиляти неприйнятні запити. Для технічної підтримки така логіка роботи є важливою, оскільки користувач часто не формулює проблему точно з першого повідомлення, а поступово уточнює її в процесі діалогу. ChatGPT демонструє загальний напрям розвитку сучасних LLM рішень, де головною цінністю є не лише відповідь на запитання, а й здатність підтримувати змістовну послідовність взаємодії [26, с. 90]. Великі мовні моделі істотно змінили підхід до побудови систем технічної підтримки, оскільки вони здатні працювати з різними формулюваннями, неповними описами проблем і неоднозначними запитами. Якщо раніше автоматизована підтримка часто обмежувалася пошуком за ключовими словами, то LLM можуть аналізувати синтаксичну й смислову структуру повідомлення, визначати прихований намір користувача та пропонувати пояснення у природній мовній формі. Це особливо важливо для користувачів, які не володіють професійною термінологією й описують технічні проблеми побутовими словами. Наприклад, замість точного формулювання «помилка автентифікації мережевого модуля» користувач може написати, що пристрій «не підключається» або «не бачить інтернет», і система повинна коректно звузити коло можливих причин. LLM підвищують доступність технічної підтримки, оскільки перетворюють складну технічну інформацію на зрозумілі покрокові рекомендації [26, с. 91]. 19 Іншим помітним прикладом сучасного AI помічника є Google Gemini, який позиціонується як сервіс для роботи з текстом, плануванням, пошуком ідей та іншими завданнями на основі генеративного штучного інтелекту. Google описує Gemini як AI асистента, що допомагає з письмом, плануванням, мозковим штурмом та іншими діями, а також підкреслює його здатність працювати з природною мовою. Для технічної підтримки важливо те, що такі системи можуть використовуватися не тільки для спілкування з користувачем, а й для пояснення складної документації, підготовки відповідей, створення інструкцій і швидкого узагальнення технічної інформації. Окрему увагу привертає те, що сімейство моделей Gemini має різні варіанти, включно з компактнішими моделями, орієнтованими на роботу в умовах обмежених ресурсів. Це наближує такі рішення до завдань, пов’язаних із пристроями, де важливими є швидкість відповіді, економне використання пам’яті та стабільність роботи [6, с. 55]. Microsoft Copilot також належить до помітних прикладів використання LLM у прикладних цифрових сервісах, оскільки він поєднує діалогові можливості з роботою в середовищі офісних і корпоративних інструментів. Microsoft описує Copilot як AI помічника, який може підтримувати розмову, допомагати з письмом, перекладом, аналізом ідей, підготовкою текстів та іншими завданнями. Така модель використання показує важливу тенденцію: AI помічник поступово стає не окремим сервісом, а частиною звичного робочого середовища користувача. Це означає, що підтримка може надаватися без виходу з програми або платформи, у якій виникла проблема. Для користувача це зменшує кількість зайвих дій, а для організації дає змогу швидше аналізувати типові труднощі, пов’язані з експлуатацією програмних продуктів [6, с. 57]. Голосові асистенти є окремою групою сучасних AI рішень, які забезпечують взаємодію користувача з технічною системою за допомогою мовлення. Їхня робота ґрунтується на розпізнаванні мовлення, 20 перетворенні його на текст, визначенні наміру користувача, виконанні команди або формуванні голосової відповіді. У технічній підтримці голосовий інтерфейс має особливе значення в ситуаціях, коли користувачеві незручно вводити текст, наприклад під час керування побутовими пристроями, автомобілем, обладнанням або системою «розумного дому». Асистенти можуть допомагати з налаштуванням, повідомляти про стан пристрою, пояснювати помилки, запускати перевірки або виконувати прості команди. Порівняно з текстовими чат- ботами, голосові рішення забезпечують природнішу взаємодію, однак вимагають високої точності розпізнавання мовлення та коректної реакції на різні мовні формулювання [12, с. 10]. Amazon Alexa є прикладом голосового AI сервісу, який використо- вується на великій кількості пристроїв і підтримує взаємодію з користувачем через природне мовлення. Amazon описує Alexa як хмарний голосовий сервіс, доступний на пристроях Amazon і сторонніх виробників, який дає змогу створювати природні голосові способи взаємодії з технологіями. В практичному використанні Alexa може відповідати на запитання, керувати пристроями «розумного дому», запускати мультимедійні сервіси, працювати з нагадуваннями та виконувати інші команди. Для технічної підтримки важливим є те, що подібні асистенти можуть стати посередником між користувачем і пристроєм, коли система не лише виконує команду, а й пояснює стан, помилку або потрібну дію. Нові покоління голосових помічників поступово переходять від фіксованих команд до більш природного діалогу, що наближає їх до функцій інтелектуального консультанта [12, с. 11]. Apple Siri та Google Assistant також демонструють поширення голосових асистентів у повсякденних цифрових пристроях. Apple подає Siri як спосіб здійснювати дзвінки, надсилати повідомлення, користуватися застосунками та виконувати дії за допомогою голосу, а Google Assistant 21 описується як помічник, що може відповідати на запитання, працювати із завданнями, нагадуваннями, комунікацією, локальною інформацією та іншими функціями. У технічному обслуговуванні такі рішення важливі тим, що вони привчають користувачів до голосової взаємодії з цифровими системами й формують очікування швидкої відповіді без складних меню. Голосові асистенти особливо корисні тоді, коли система має надати коротку інструкцію або виконати просту команду без залучення клавіатури чи екрана [21, с. 44]. У сфері клієнтської та технічної підтримки значне поширення мають спеціалізовані платформи, які поєднують чат-ботів, AI модулі, бази знань і засоби допомоги оператору. Одним із таких прикладів є Zendesk AI, який пропонує інтелектуальні боти, розширене самообслуговування та інструменти для підвищення продуктивності служби підтримки. Платформи зазвичай не обмежуються відповідями користувачеві, а також допомагають класифікувати звернення, пропонувати оператору варіанти відповіді, автоматично узагальнювати діалог і визначати пріоритет заявки. Для технічної підтримки це має велике значення, оскільки навіть тоді, коли AI не може повністю розв’язати проблему, він прискорює роботу фахівця й зменшує кількість ручних дій. В результаті автоматизація охоплює не лише зовнішню взаємодію з користувачем, а й внутрішні процеси опрацювання звернень [21, с. 45]. Ще одним показовим рішенням у сфері AI підтримки є Intercom Fin, який використовує великі мовні моделі та наявний довідковий контент компанії для відповідей на запити користувачів. Intercom описує Fin як AI бота для клієнтського сервісу, що працює на основі LLM і використовує матеріали підтримки для розв’язання звернень. Такий підхід є важливим для технічної підтримки, оскільки система повинна спиратися на перевірені інструкції, документацію та правила експлуатації, а не формувати відповідь лише на основі загальної мовної моделі. Якщо AI 22 помічник використовує базу знань, він може точніше пояснювати порядок дій, посилатися на релевантну інформацію та зменшувати ризик помилкових рекомендацій [34, с. 116]. Порівняння чат-ботів, голосових асистентів і LLM показує, що кожен із цих напрямів має власні переваги й обмеження. Чат-боти зручні для структурованого текстового спілкування, збереження історії діалогу та передавання користувачеві докладних інструкцій. Голосові асистенти краще підходять для швидких команд, коротких відповідей і ситуацій, коли користувач не може або не хоче вводити текст. LLM забезпечують глибше мовне опрацювання, здатність пояснювати складні питання та формувати відповіді з урахуванням попереднього контексту. Найефектив- нішими у сучасній технічній підтримці стають комбіновані рішення, у яких текстова, голосова та мовна інтелектуальна взаємодія поєднуються з базою знань, системою заявок і механізмами контролю якості відповідей. Попри значні переваги, сучасні рішення на основі чат-ботів, голосових асистентів і LLM мають низку проблем, які потрібно враховувати під час їх використання в технічній підтримці. Однією з головних проблем є ризик неправильної або недостатньо точної відповіді, особливо якщо система не має доступу до актуальної технічної документації або неправильно розуміє запит користувача. Іншою проблемою є захист даних, оскільки під час звернення до служби підтримки користувач може повідомляти персональну інформацію, технічні параметри пристрою, облікові дані або відомості про помилки [34, с. 117]. Отже, сучасні рішення на основі чат-ботів, голосових асистентів і LLM істотно розширюють можливості технічної підтримки користувачів, оскільки забезпечують швидшу, гнучкішу та природнішу взаємодію з комп’ютерними системами. 23 1.2 Особливості використання вбудованих пристроїв у системах підтримки 1.2.1 Архітектура та апаратні можливості вбудованих пристроїв Вбудовані пристрої є спеціалізованими обчислювальними засобами, які створюються для виконання визначеного кола функцій у складі технічної системи, приладу або програмно-апаратного комплексу. На відміну від універсальних персональних комп’ютерів, вони зазвичай працюють у межах конкретного завдання: керування, вимірювання, передавання даних, контролю стану, обробки сигналів або взаємодії з користувачем. У системах технічної підтримки такі пристрої можуть виконувати роль локального вузла, який приймає запити, аналізує параметри роботи обладнання, відображає рекомендації або передає інформацію до зовнішнього сервісу [17, с. 66]. Внутрішня побудова вбудованого пристрою зазвичай охоплює мікроконтролер або мікропроцесор, оперативну та постійну пам’ять, засоби введення і виведення, інтерфейси зв’язку, систему живлення та периферійні компоненти. Центральний обчислювальний елемент виконує програмний код, обробляє команди, керує взаємодією з датчиками, дисплеями, кнопками, модулями зв’язку та іншими складовими. Пам’ять використовується для зберігання прошивки, базових налаштувань, службових даних, журналів подій і фрагментів інформаційної бази, потрібної для технічної підтримки. В системі підтримки користувача ці компоненти мають працювати узгоджено, оскільки якість відповіді залежить не тільки від програмного алгоритму, а й від того, чи може пристрій швидко отримати потрібні дані про власний стан. Апаратні можливості вбудованого засобу безпосередньо впливають на швидкість, стабільність і повноту надання допомоги користувачеві [17, с. 67]. 24 Однією з головних особливостей вбудованих пристроїв є орієнтація на конкретну функціональність і роботу в умовах обмежених ресурсів. Багато таких пристроїв мають менший обсяг оперативної пам’яті, нижчу частоту процесора та обмежене енергоспоживання порівняно з повноцінними комп’ютерами. Це означає, що AI система технічної підтримки не завжди може виконувати складні мовні моделі безпосередньо на локальному пристрої, особливо якщо йдеться про компактні плати або контролери. Водночас навіть обмежений пристрій може виконувати важливі функції: приймати запит, визначати тип проблеми, перевіряти параметри системи, показувати користувачеві інструкцію або передавати складний запит до зовнішнього сервера. Розподіл обчислювальних операцій дає змогу ефективно використовувати наявні ресурси без перевантаження апаратної частини [8, с. 16]. Апаратні можливості вбудованого пристрою значною мірою визначаються типом обчислювального ядра. У простіших системах застосовуються мікроконтролери, які мають невелике енергоспоживання, достатню кількість входів і виходів, таймери, аналого-цифрові перетворю- вачі та інтерфейси для роботи з периферією. У складніших системах використовуються одноплатні комп’ютери, які можуть запускати повноцінну операційну систему, працювати з мережевими сервісами, базами даних, графічним інтерфейсом і складнішими програмними модулями. Для AI підтримки це має принципове значення, оскільки мікроконтролер краще підходить для простих локальних перевірок і базових команд, тоді як одноплатний комп’ютер може забезпечити ширшу мовну взаємодію та складнішу обробку інформації. Вибір апаратної платформи залежить від того, чи повинна система лише надавати базові підказки, чи також виконувати локальне опрацювання запитів користувача. Показовим прикладом одноплатного комп’ютера, який може використовуватися для створення систем підтримки, є Raspberry Pi 5. Ця 25 плата має процесор Broadcom BCM2712 із чотирма ядрами Arm Cortex-A76 з частотою 2,4 ГГц, а також варіанти оперативної пам’яті до 16 ГБ, що робить її придатною для задач, які потребують роботи з мережевими сервісами, локальними застосунками та інтерфейсами користувача. Для AI системи технічної підтримки така платформа може виконувати роль локального обчислювального вузла, який приймає повідомлення, зберігає журнали помилок, відображає інструкції й обмінюється даними із зовнішніми службами. Її перевагою є поєднання компактності, достатньої продуктивності та підтримки різних периферійних пристроїв [8, с. 17]. Іншу групу становлять мікроконтролерні плати, орієнтовані на компактні пристрої, сенсорні системи та економне споживання енергії. Наприклад, Arduino Nano 33 BLE Sense Rev2 є мініатюрною платою на базі модуля NINA B306 з мікроконтролером Arm Cortex-M4F, а також містить сенсорні компоненти, зокрема інерційні датчики, що дають змогу працювати з даними руху й середовища. Для системи підтримки користувача така плата може бути корисною тоді, коли потрібно не тільки відповідати на запити, а й аналізувати фізичний стан пристрою або середовища. Наприклад, система може враховувати дані датчиків для пояснення помилки, попередження про неправильне положення пристрою, перегрів або нестабільні умови експлуатації [15, с. 21]. Для вбудованих систем підтримки важливими є засоби зв’язку, оскільки технічна допомога часто передбачає обмін даними між пристроєм, користувачем і зовнішнім сервісом. У сучасних платформах поширені Wi-Fi, Bluetooth Low Energy, Ethernet, UART, SPI, I2C, USB та інші канали передавання інформації. ESP32-S3 є прикладом мікроконтролерного SoC, який поєднує двоядерний процесор Xtensa LX7, Wi-Fi 2,4 ГГц і Bluetooth Low Energy, що робить його придатним для підключених пристроїв із функціями взаємодії та обміну даними. У контексті технічної підтримки це означає, що пристрій може надсилати 26 службову інформацію, отримувати оновлення, передавати повідомлення про помилки або підтримувати зв’язок із мобільним за стосунком [15, с. 22]. У системах підтримки, пов’язаних із AI функціями, дедалі більшого значення набувають спеціалізовані обчислювальні засоби для прискорення машинного навчання. Звичайний мікроконтролер може виконувати просту класифікацію або роботу з наперед заданими правилами, однак складніші моделі потребують більшої продуктивності. NVIDIA Jetson Nano є прикладом компактної платформи для задач штучного інтелекту на периферії мережі, оскільки вона має 128 ядер CUDA, чотириядерний процесор Arm Cortex-A57, 4 ГБ LPDDR4 та заявлену продуктивність 472 GFLOPS. Така платформа може застосовуватися там, де потрібно обробляти зображення, відео, голос або складніші дані без постійного звернення до хмари. Наприклад, пристрій може локально розпізнавати стан обладнання за камерою, виявляти тип помилки на екрані або аналізувати візуальні ознаки несправності [27, с. 140]. Ще одним прикладом апаратного засобу для локального машинного навчання є Google Coral Dev Board. Вона містить Edge TPU, який забезпечує 4 TOPS для обчислень int8, а також має варіанти оперативної пам’яті 1 або 4 ГБ LPDDR4, накопичувач eMMC і бездротові інтерфейси Wi-Fi та Bluetooth. Для AI системи технічної підтримки така платформа може бути корисною тоді, коли необхідно виконувати швидке локальне розпізнавання, класифікацію або аналіз сенсорних даних. Наприклад, пристрій може визначати тип об’єкта, стан індикатора, характер сигналу або ознаку несправності без передавання всіх даних на зовнішній сервер [27, с. 141]. Важливою складовою вбудованого пристрою є пам’ять, оскільки саме вона обмежує обсяг програмного коду, кількість даних, розмір локальної бази знань і можливість виконання складних алгоритмів. Постійна пам’ять 27 використовується для зберігання прошивки, налаштувань і довідкової інформації, тоді як оперативна пам’ять потрібна для виконання програм, буферизації даних і обробки запитів. Якщо AI система підтримки має працювати локально, обсяг пам’яті стає одним із головних чинників, що визначає складність моделі, довжину діалогу, кількість збережених сценаріїв і можливість кешування відповідей. У невеликих мікроконтроле- рах повноцінна мовна модель зазвичай є непрактичною, тому застосовують спрощені алгоритми, таблиці рішень, компактні класифікатори або взаємодію з віддаленим AI сервісом [34, с. 117]. Периферійні можливості вбудованих пристроїв визначають, наскільки повно система підтримки може взаємодіяти з користувачем і технічним середовищем. До таких можливостей належать підключення кнопок, дисплеїв, сенсорних панелей, мікрофонів, динаміків, камер, світлодіодних індикаторів, датчиків температури, вологості, руху, тиску або струму. У платах STM32 Nucleo, наприклад, передбачено мікроконтролери STM32, вбудований засіб програмування й налагодження STLINK, кнопки, світлодіоди, а також роз’єми для підключення зовнішніх модулів. Для системи технічної підтримки такі елементи дають змогу не лише виводити повідомлення користувачеві, а й отримувати інформацію про фактичний стан обладнання [2, с. 35]. В системах підтримки користувачів важливу роль відіграє енерго- споживання, оскільки багато вбудованих пристроїв працюють від акумулятора, батареї або обмеженого джерела живлення. Якщо система повинна постійно очікувати звернення, приймати голосові команди, аналізувати сенсорні дані або підтримувати бездротовий зв’язок, це створює додаткове навантаження на джерело живлення. Апаратна платформа має підтримувати енергозберігальні режими, періодичне пробудження, оптимізовану роботу радіомодулів і раціональне використання обчислювальних операцій. У практиці це означає, що 28 складні AI обчислення часто виконуються лише за потреби, а в інший час пристрій перебуває в режимі очікування або виконує мінімальний набір перевірок [18, с. 154]. Особливого значення для систем підтримки набуває надійність апаратних компонентів, оскільки пристрій має коректно працювати навіть тоді, коли користувач звертається через помилку, збій або нестандартний режим експлуатації. Система підтримки не повинна залежати від нестабільних компонентів, які можуть відмовити саме в момент виникнення проблеми. Для цього використовуються сторожові таймери, механізми перезапуску, резервне збереження налаштувань, контроль живлення, журнали подій і захист від некоректного оновлення прошивки. Якщо пристрій має дисплей або індикатори, він може повідомляти користувачеві про базові стани навіть тоді, коли мережевий зв’язок тимчасово недоступний [18, с. 155]. Вбудовані пристрої в системах підтримки можуть працювати як автономно, так і у взаємодії з хмарними сервісами. Автономний варіант доцільний у тих випадках, коли пристрій повинен надавати базову допомогу без доступу до мережі, наприклад пояснювати помилки, показувати інструкції або виконувати локальну діагностику. Хмарна взаємодія розширює можливості системи, оскільки дозволяє використову- вати потужніші мовні моделі, оновлювати базу знань, зберігати статистику звернень і підключати оператора. Змішаний підхід є найбільш збалансованим: прості дії виконуються локально, а складні запити передаються до зовнішнього AI сервісу [2, с. 35]. У технічній підтримці важливо, щоб вбудований пристрій міг працювати з різними форматами інформації. Текстові запити потребують клавіатури, сенсорного екрана або підключення до мобільного застосунку, голосова взаємодія передбачає наявність мікрофона й динаміка, а візуальна діагностика потребує камери або доступу до зображення. На практиці це 29 означає, що апаратні можливості визначають не лише продуктивність, а й сам спосіб взаємодії користувача із системою підтримки. Якщо пристрій має тільки світлодіодні індикатори й кнопки, підтримка буде обмежена простими повідомленнями та кодами помилок. Якщо ж платформа підтримує екран, мережеве підключення, аудіомодуль і достатню обчислювальну потужність, вона може забезпечувати повноцінніший діалог, пояснення, покрокові інструкції та інтеграцію з AI сервісами [47, с. 11]. Отже, використання вбудованих пристроїв у системах підтримки користувачів ґрунтується на поєднанні спеціалізованої обчислювальної платформи, пам’яті, інтерфейсів зв’язку, периферійних компонентів і програмних засобів, що забезпечують взаємодію з користувачем. 1.2.2 Обмеження обчислювальних ресурсів, пам’яті та енергоспоживання Використання вбудованих пристроїв у системах технічної підтримки користувачів безпосередньо пов’язане з обмеженнями їхніх обчислюваль- них ресурсів, пам’яті та енергоспоживання. На відміну від персональних комп’ютерів або серверів, такі пристрої зазвичай створюються для виконання чітко визначених завдань, тому не завжди мають достатній запас продуктивності для складних AI обчислень [44, с. 192]. Це особливо важливо для систем технічної підтримки, які мають швидко аналізувати запити користувача, опрацьовувати службові дані, формувати відповіді та, за потреби, взаємодіяти з базою знань або зовнішнім сервісом. Якщо обчислювальні можливості пристрою є недостатніми, система може працювати повільно, втрачати контекст діалогу, обмежувати довжину відповідей або виконувати лише найпростіші сценарії допомоги. Під час 30 створення AI системи підтримки на базі вбудованого пристрою необхідно враховувати не лише функціональність програмного модуля, а й фактичні можливості апаратної платформи [44, с. 193]. Обчислювальні обмеження проявляються насамперед у швидкодії процесора, кількості ядер, наявності або відсутності спеціалізованих прискорювачів, можливості паралельного опрацювання даних і стабільності роботи під навантаженням. У простих мікроконтролерах обчислювальні ресурси достатні для керування сенсорами, виконання логічних умов, обробки нескладних команд і передавання даних, але вони не розраховані на повноцінну роботу з великими мовними моделями. Для технічної підтримки це означає, що локальний пристрій може виконувати первинну класифікацію запиту, виявляти прості стани помилок або запускати готові інструкції, однак складні мовні відповіді часто потребують зовнішнього обчислювального середовища. Наприклад, плата Raspberry Pi Pico на базі мікроконтролера RP2040 має 264 КБ SRAM і працює з зовнішньою flash-пам’яттю, що добре підходить для керування периферією, але значно обмежує можливості складного AI опрацювання порівняно з одноплатними комп’ютерами. Пам’ять є одним із найкритичніших ресурсів для AI систем технічної підтримки, оскільки вона визначає, скільки даних може зберігатися та опрацьовуватися безпосередньо на пристрої. Оперативна пам’ять потрібна для виконання програмного коду, буферизації запитів, збереження проміжних результатів, роботи з інтерфейсом користувача та підтримання контексту діалогу. Постійна пам’ять використовується для зберігання прошивки, базових сценаріїв підтримки, фрагментів бази знань, налаштувань і журналів помилок. Якщо пам’яті недостатньо, система не може зберігати великий обсяг довідкових матеріалів, підтримувати довгі діалоги або працювати з ресурсомісткими моделями обробки мови. Внаслідок цього розробник змушений застосовувати стислі формати 31 даних, обмежувати кількість сценаріїв, скорочувати обсяг локальних інструкцій або використовувати підключення до зовнішньої бази знань [31, с. 56]. Обмеження пам’яті особливо помітні в мікроконтролерних платформах, які часто використовуються в компактних пристроях, сенсорних вузлах і автономних технічних засобах. Наприклад, Arduino Nano 33 BLE Sense Rev2 побудована на модулі з Arm Cortex-M4F і поєднує невеликі розміри з набором сенсорів, а сама платформа орієнтована на задачі TinyML і роботу з TensorFlow Lite. Це дозволяє виконувати прості моделі машинного навчання безпосередньо на пристрої, однак не означає можливості локального запуску повноцінних генеративних мовних моделей. У системі технічної підтримки така плата може розпізнавати певні стани, обробляти сенсорні дані або запускати заздалегідь підготов- лені рекомендації, але для розгорнутого діалогу природною мовою їй зазвичай потрібна взаємодія з потужнішим вузлом [44, с. 194]. Енергоспоживання є не менш важливим обмеженням, оскільки багато вбудованих пристроїв працюють від батарей, акумуляторів або джерел живлення з обмеженою потужністю. AI система технічної підтримки може потребувати постійного очікування запиту, роботи мікрофона, підтриман- ня бездротового зв’язку, періодичного аналізу сенсорних даних і обміну інформацією із зовнішнім сервісом. Усе це збільшує витрати енергії, особливо якщо пристрій часто використовує Wi-Fi, виконує складні обчислення або підтримує активний інтерфейс користувача. Для автономних систем це може призводити до швидкого розряду джерела живлення, зниження стабільності роботи або потреби в частому обслуговуванні. Вбудовані AI системи мають застосовувати режими очікування, періодичне пробудження, локальну фільтрацію подій і запуск складних обчислень лише тоді, коли це справді потрібно [2, с. 35]. 32 Показовим прикладом платформи, де поєднуються засоби зв’язку та енергоощадність, є ESP32-S3. Цей SoC має двоядерний мікропроцесор Xtensa LX7, підтримує Wi-Fi 2,4 ГГц і Bluetooth Low Energy, а також позиціонується виробником як малопотужне рішення для підключених пристроїв. Для AI системи технічної підтримки така платформа може бути корисною в ролі вузла, який приймає запити, збирає дані про стан пристрою, передає їх до сервера або мобільного застосунку та отримує рекомендації для користувача. Водночас активне використання бездротового зв’язку може істотно збільшувати енергоспоживання, тому система повинна мінімізувати кількість переданих даних і раціонально організовувати сеанси зв’язку [31, с. 57]. В контексті технічної підтримки обмеження обчислювальних ресурсів впливають не тільки на швидкість відповіді, а й на якість взаємодії з користувачем. Якщо система повільно реагує на запит, користувач може сприймати її як ненадійну або незручну, навіть якщо відповідь є правильною. Для AI підтримки важливо забезпечити мінімальну затримку під час первинної реакції, оскільки користувач часто звертається в момент помилки, збою або невпевненості щодо подальших дій. Локальний пристрій має швидко виконувати прості операції: визначати тип звернення, показувати базову інструкцію, повідомляти про стан системи або пропонувати користувачеві уточнити проблему [2, с. 35]. Обмеження пам’яті також впливають на можливість збереження журналів подій, які є важливими для технічної підтримки. Журнали помилок, дані про попередні запити, параметри роботи пристрою та історія змін допомагають точніше встановити причину проблеми. Якщо пам’яті мало, пристрій може зберігати лише останні події або найважливіші параметри, через що діагностика стає менш повною. Для розв’язання цієї проблеми застосовують циклічне збереження журналів, стискання даних, фільтрацію неважливих повідомлень і періодичне передавання інформації 33 до зовнішнього сховища. В системі підтримки це дозволяє зберегти потрібний мінімум службових даних без перевантаження локальної пам’яті [31, с. 58]. Для виконання AI задач на вбудованих пристроях часто використовуються оптимізовані моделі, які мають менший розмір і нижчі вимоги до обчислень. До таких підходів належать квантування, обрізання нейронних мереж, використання компактних класифікаторів, скорочення словника, обмеження довжини запиту та попередня обробка даних. У системах технічної підтримки це може означати, що пристрій не генерує повну відповідь самостійно, а лише визначає категорію проблеми, обирає відповідний сценарій або формує короткий структурований запит до зовнішнього AI сервісу. Одноплатні комп’ютери мають ширші можливості, однак вони також не позбавлені ресурсних обмежень. Наприклад, NVIDIA Jetson Nano має 128 CUDA-ядер, чотириядерний процесор Arm Cortex-A57 і 4 ГБ LPDDR4, що робить її значно продуктивнішою за звичайні мікроконтролери в задачах локального AI опрацювання. Водночас навіть така платформа потребує уважного ставлення до енергоспоживання: у документації для Jetson Nano Developer Kit зазначено підтримку режимів живлення, зокрема типові режими 5 Вт і 10 Вт. Локальна обробка зображень, голосу або складних даних можлива, але вона має бути узгоджена з тепловими умовами, доступним живленням і потребою в стабільній роботі [38, с. 44]. Ще складніші AI задачі можуть виконуватися на продуктивніших платформах, але це підвищує вимоги до живлення й охолодження. Jetson Orin Nano Super Developer Kit, за даними NVIDIA, має продуктивність до 67 INT8 TOPS, 8 ГБ LPDDR5 і діапазон споживання 7–25 Вт, що значно розширює можливості локального запуску AI моделей. Для технічної підтримки така платформа може бути корисною в системах, де потрібно опрацьовувати голос, відео, зображення індикаторів, потоки даних від 34 сенсорів або складні сценарії взаємодії. Однак підвищена продуктивність означає більшу вартість, більші вимоги до джерела живлення та потенційне тепловиділення [13, с. 18]. Обмеження енергоспоживання тісно пов’язані з тепловим режимом пристрою. Якщо процесор, бездротовий модуль або AI прискорювач тривалий час працюють під високим навантаженням, пристрій може нагріватися, знижувати продуктивність або потребувати додаткового охолодження. В компактних корпусах це є особливо важливою проблемою, оскільки обмежений простір ускладнює відведення тепла. Для системи підтримки користувача перегрів може бути критичним, адже вона повинна залишатися доступною саме тоді, коли пристрій працює нестабільно або повідомляє про помилку. Програмний модуль підтримки має враховувати тепловий стан системи, зменшувати інтенсивність обчислень у разі потреби й надавати користувачеві зрозумілі повідомлення про перегрів або надмірне навантаження [2, с. 35]. Під час створення AI системи технічної підтримки важливо визначити, які операції виконуються локально, а які передаються до зовнішнього середовища. Локально доцільно виконувати базову перевірку стану пристрою, аналіз простих помилок, запуск коротких інструкцій, збирання службових даних і забезпечення первинної відповіді користувачеві. Зовнішній сервіс може використовуватися для складного мовного аналізу, генерації докладних пояснень, оновлення бази знань, збереження історії звернень і передавання заявки фахівцю. [38, с. 45]. Пам’ять вбудованого пристрою також визначає можливість оновлення програмного забезпечення та бази знань. Якщо пристрій має недостатній обсяг постійної пам’яті, складно зберігати одночасно основну прошивку, резервну копію, нову версію програмного коду й довідкові матеріали. Це створює ризики під час оновлення, адже помилка може призвести до втрати працездатності пристрою або некоректної роботи системи 35 підтримки. В ресурсно обмежених системах використовують мінімальні оновлення, розділення прошивки на модулі, перевірку цілісності даних і збереження критично важливих функцій у захищеній області пам’яті. Окрему увагу потрібно приділяти бездротовому зв’язку, оскільки він одночасно розширює можливості AI підтримки й збільшує витрати енергії. Wi-Fi забезпечує вищу швидкість передавання даних, але зазвичай споживає більше енергії, тоді як Bluetooth Low Energy краще підходить для коротких повідомлень, взаємодії з мобільним застосунком і періодичного обміну інформацією. Якщо система підтримки часто звертається до хмарного AI сервісу, передає журнали подій або отримує оновлення, витрати енергії можуть суттєво зрости. Важливо використовувати локальну фільтрацію запитів, кешування відповідей, передавання лише потрібних параметрів і обмеження частоти мережевої активності [13, с. 19]. Вбудовані системи підтримки мають враховувати не лише технічні обмеження, а й поведінку користувача. Користувач очікує, що пристрій швидко відповість, зрозуміло пояснить проблему й не вимагатиме складних дій для отримання допомоги. Якщо через нестачу ресурсів система надає надто короткі, неточні або затримані відповіді, ефективність підтримки знижується. Навіть за обмеженої пам’яті й продуктивності потрібно забезпечити пріоритетність найважливіших функцій: повідомлен- ня про помилку, базову діагностику, коротку інструкцію та можливість передати запит далі. Успішна AI система на вбудованому пристрої повинна працювати не як перевантажений універсальний помічник, а як раціонально організований засіб швидкої технічної допомоги. Отже, обмеження обчислювальних ресурсів, пам’яті та енерго- споживання є визначальними чинниками під час використання вбудованих пристроїв у системах технічної підтримки користувачів. 36 1.3 Формування вимог і завдань до AI системи технічної підтримки 1.3.1 Визначення функціональних та нефункціональних вимог до системи Формування вимог до AI системи технічної підтримки користувача є важливим етапом створення програмно-апаратного рішення, оскільки саме на цьому рівні визначаються очікувані можливості системи, умови її роботи та критерії ефективності. Для системи, що функціонує на базі вбудованого пристрою, вимоги мають враховувати не лише потреби користувача, а й апаратні обмеження, спосіб взаємодії, доступні канали зв’язку, обсяг пам’яті та допустиме енергоспоживання. У загальному вигляді вимоги поділяють на функціональні та нефункціональні, причому перші описують, які дії система повинна виконувати, а другі визначають якість, стабільність, безпеку й умови виконання цих дій [2, с. 35]. Функціональні вимоги до AI системи технічної підтримки насамперед стосуються приймання, аналізу та опрацювання запитів користувача. Система повинна мати можливість отримувати звернення у зручній формі, наприклад через текстове поле, мобільний застосунок, голосову команду, кнопковий інтерфейс або вбудований екран пристрою. Після отримання запиту вона має визначати його зміст, розпізнавати тип проблеми, виділяти ключові ознаки та зіставляти їх із наявною інформаційною базою. Наприклад, якщо користувач повідомляє, що пристрій не підключається до мережі, система має розрізнити можливі причини: відсутність сигналу, неправильні налаштування, збій модуля зв’язку або помилку автентифіка- ції [29, с. 121]. Важливою функціональною вимогою є здатність системи класифіку- вати звернення за категоріями. У технічній підтримці запити можуть стосуватися налаштування пристрою, помилок підключення, несправності 37 компонентів, оновлення програмного забезпечення, проблем із живленням, некоректної роботи сенсорів або потреби в поясненні функцій. Класифікація дозволяє не тільки швидше знайти відповідь, а й визначити рівень складності проблеми. Наприклад, у сервісах на зразок Zendesk AI або Intercom Fin звернення користувачів можуть автоматично групуватися, пріоритизуватися та спрямовуватися до відповідних сценаріїв підтримки або операторів. Для вбудованого пристрою аналогічний принцип може бути реалізований у спрощеній формі, коли система визначає категорію проблеми та обирає відповідну інструкцію або діагностичну процедуру [29, с. 122]. Наступною функціональною вимогою є формування відповіді користувачеві у зрозумілій та послідовній формі. Технічна підтримка не повинна обмежуватися коротким повідомленням про помилку, оскільки користувачеві часто потрібне пояснення причини проблеми та конкретний порядок дій. AI система має перетворювати технічну інформацію на доступні рекомендації, уникаючи надмірно складних формулювань, якщо користувач не має спеціальної підготовки. Наприклад, замість повідомлен- ня «помилка ініціалізації мережевого інтерфейсу» система може пояснити, що пристрій не зміг увімкнути модуль зв’язку, і запропонувати перевірити живлення, налаштування мережі або перезавантажити пристрій [16, с. 54]. Окремою функціональною вимогою є наявність бази знань або іншого структурованого джерела інформації, з якого система отримує перевірені відомості для формування рекомендацій. База знань може містити інструкції з експлуатації, описи типових несправностей, таблиці помилок, алгоритми перевірки, правила безпечного використання та відповіді на поширені запитання. Для AI системи технічної підтримки важливо, щоб відповідь формувалася не довільно, а на основі інформації, яка відповідає характеристикам конкретного пристрою. Наприклад, у рішеннях на базі великих мовних моделей, зокрема ChatGPT через API або подібних мовних 38 сервісів, якість відповіді значною мірою залежить від того, чи підкріплена вона релевантними матеріалами з документації. Для вбудованого пристрою така база може бути частково локальною, а частково розміщеною на зовнішньому сервері [2, с. 35]. Система повинна мати функцію первинної діагностики стану пристрою, оскільки технічна підтримка на базі вбудованого засобу може спиратися не лише на слова користувача, а й на службові дані самого обладнання. До таких даних можуть належати рівень заряду, температура, стан мережевого підключення, показники сенсорів, наявність помилок у журналі подій, версія програмного забезпечення та час останнього оновлення. Наприклад, пристрій на базі ESP32-S3 може використовувати бездротовий зв’язок і внутрішні параметри роботи для передавання інформації про стан підключення або збої в обміні даними. Якщо система бачить, що проблема пов’язана не з діями користувача, а з нестабільним живленням або недоступністю мережі, вона повинна надати відповідну рекомендацію [18, с. 154]. Функціональні вимоги також мають передбачати можливість ведення діалогу з користувачем. У багатьох випадках перше повідомлення не містить достатньо інформації для точного визначення проблеми, тому система повинна ставити уточнювальні запитання. Наприклад, якщо користувач пише, що пристрій «не працює», AI модуль має з’ясувати, чи пристрій не вмикається, не реагує на команди, не підключається до мережі або видає певний код помилки. Ще однією важливою вимогою є підтримка передавання складних звернень фахівцю або зовнішній системі обробки заявок. AI система не повинна створювати ілюзію повної автономності там, де проблема потребує ремонту, заміни компонента, глибокої перевірки або доступу до сервісної інформації. Якщо автоматична підтримка не може розв’язати питання, вона має сформувати короткий опис проблеми, зберегти дані про 39 виконані кроки, додати технічні параметри й передати звернення оператору. У подібний спосіб працюють сучасні платформи підтримки, де AI модуль виконує первинне опрацювання, а складні випадки переходять до людини. Для користувача це зручно, оскільки він не змушений повторювати всю інформацію від початку [18, с. 155]. До функціональних вимог належить також можливість оновлення інформаційної бази та програмних компонентів системи. Технічні пристрої змінюються, програмне забезпечення оновлюється, з’являються нові типи помилок, тому система підтримки має отримувати актуальні інструкції та виправлення. Якщо база знань залишається незмінною, AI система поступово втрачає ефективність і може надавати застарілі рекомендації. Наприклад, у пристроях на основі Raspberry Pi оновлення програмних компонентів може забезпечувати розширення функцій, виправлення помилок або додавання нових сценаріїв взаємодії [26, с. 90]. Нефункціональні вимоги визначають якісні характеристики системи, які не зводяться до окремих дій, але безпосередньо впливають на її придатність до використання. Передусім це вимоги до швидкодії, оскільки користувач очікує отримати відповідь швидко, особливо в ситуації збою або помилки. Якщо система занадто довго аналізує запит або повільно виводить рекомендацію, вона не виконує свою основну роль ефективного засобу підтримки. Для вбудованого пристрою швидкодія залежить від продуктивності процесора, обсягу пам’яті, складності алгоритмів і швидкості мережевої взаємодії. Наприклад, компактні мікроконтролери можуть швидко реагувати на прості події, але для розгорнутого мовного аналізу доцільно використовувати зовнішній сервіс або потужніший обчислювальний модуль [26, с. 91]. Важливою нефункціональною вимогою є надійність, оскільки система технічної підтримки повинна залишатися доступною навіть тоді, коли сам пристрій працює нестабільно. Вона має коректно обробляти помилки, не 40 зависати під час некоректного введення, зберігати базові функції після перезавантаження та не втрачати критичну інформацію. Для цього можуть використовуватися журнали подій, механізми автоматичного відновлення, перевірка цілісності даних і захист від неправильного оновлення. Наприклад, у пристроях із модулями STM32 часто застосовуються сторожові таймери, які допомагають перезапускати систему у випадку програмного збою. Безпека є однією з ключових нефункціональних вимог до AI системи технічної підтримки. Під час взаємодії користувач може передавати дані про пристрій, обліковий запис, мережеве підключення, помилки, місце використання або інші відомості, які не повинні потрапляти до сторонніх осіб. Система має забезпечувати захист передавання даних, обмеження доступу до службової інформації, перевірку прав користувача та мінімізацію збирання зайвих відомостей. Якщо AI модуль використовує зовнішній сервіс, потрібно чітко визначити, які дані передаються за межі пристрою та з якою метою [16, с. 55]. Нефункціональні вимоги також охоплюють зручність взаємодії з користувачем. Система повинна надавати відповіді зрозумілою мовою, не перевантажувати користувача зайвими технічними деталями та пропонувати послідовні дії. Якщо користувач має виконати кілька кроків, система повинна подавати їх у логічному порядку, пояснювати результат кожної дії та повідомляти, що робити, якщо проблема не зникла. Наприклад, у голосових асистентах на зразок Alexa або Google Assistant важливим є те, що користувач може взаємодіяти із системою природним мовленням, не відкриваючи складні меню. У вбудованому пристрої така зручність може реалізовуватися через короткі повідомлення на екрані, голосові підказки, світлові індикатори або мобільний застосунок [16, с. 56]. Ще однією важливою нефункціональною вимогою є енергоефектив- ність, особливо якщо система працює на автономному живленні. AI 41 модуль не повинен постійно виконувати ресурсомісткі операції, якщо це призводить до швидкого розряду акумулятора або перегріву пристрою. Для зменшення енергоспоживання можна використовувати режими очікування, локальну обробку простих подій, періодичне пробудження та передавання даних лише за необхідності. Наприклад, пристрій може локально визначати, чи є проблема типовою, і звертатися до зовнішнього AI сервісу тільки тоді, коли потрібна складна відповідь [26, с. 92]. Масштабованість і можливість адаптації також належать до важливих нефункціональних вимог. Система технічної підтримки може спочатку працювати з невеликою кількістю типових проблем, але з часом має розширювати базу знань, додавати нові сценарії, підтримувати інші моделі пристроїв або взаємодіяти з додатковими сервісами. Наприклад, Dialogflow CX використовується для створення складних розмовних агентів, у яких можна налаштовувати багатокрокову взаємодію та сценарії обслуговуван- ня користувачів. Для вбудованої AI системи аналогічний принцип проявляється в можливості поступово розширювати перелік підтримував- них запитів без повної заміни програмного забезпечення [16, с. 57]. Визначення функціональних і нефункціональних вимог дозволяє сформувати цілісне уявлення про те, якою має бути AI система технічної підтримки користувача на базі вбудованого пристрою. Вона повинна приймати запити, класифікувати проблеми, використовувати базу знань, вести діалог, виконувати первинну діагностику, формувати зрозумілі рекомендації, оновлювати інформацію та передавати складні випадки фахівцям [19, с. 21]. Отже, правильне формування вимог є основою для створення AI підтримки, яка не лише виконує технічні функції, а й забезпечує користувачеві зрозумілу, стабільну та своєчасну допомогу. 42 1.3.2 Постановка задачі розроблення AI системи на базі вбудованого пристрою Постановка задачі розроблення AI системи технічної підтримки користувача на базі вбудованого пристрою передбачає визначення основної проблеми, яку має розв’язувати система, її функціональних меж, технічних умов роботи та очікуваного результату. Головна сутність такої задачі полягає у створенні програмно-апаратного рішення, здатного приймати звернення користувача, аналізувати їхній зміст, визначати тип технічної проблеми та надавати зрозумілі рекомендації щодо її усунення. Особливість цієї задачі полягає в тому, що система має працювати не лише як звичайний довідковий сервіс, а як інтелектуальний засіб підтримки, пов’язаний із конкретним пристроєм та його поточним станом. Це означає, що AI модуль повинен враховувати як повідомлення користувача, так і службові параметри вбудованого пристрою, зокрема стан живлення, підключення, сенсорів, пам’яті, програмного забезпечення або журналу подій [26, с. 93]. Розроблення такої системи має бути спрямоване на автоматизацію первинної технічної підтримки, тобто на розв’язання тих ситуацій, які не потребують негайного втручання фахівця. У більшості технічних систем значна частина звернень користувачів стосується типових проблем: неправильного налаштування, втрати з’єднання, помилки запуску, некоректного підключення периферійних компонентів або нерозуміння повідомлень пристрою. AI система повинна самостійно опрацьовувати такі звернення та пропонувати користувачеві послідовність дій, яку можна виконати без спеціальної підготовки. Наприклад, якщо пристрій на базі ESP32-S3 втрачає Wi-Fi з’єднання, система може перевірити статус мережевого модуля, повідомити користувачеві про можливу причину та запропонувати повторне підключення або перевірку параметрів мережі. В 43 такий спосіб задача полягає не лише в генерації текстової відповіді, а й у поєднанні діалогової взаємодії з даними самого пристрою [2, с. 35]. Під час постановки задачі необхідно визначити вхідні дані, з якими працюватиме система. До них належать текстові або голосові звернення користувача, команди з інтерфейсу пристрою, коди помилок, показники сенсорів, службові повідомлення, дані про версію програмного забезпечення та інформація з бази знань. Якщо користувач вводить запит у текстовій формі, AI модуль має опрацювати зміст повідомлення та виділити ключові ознаки проблеми. Якщо використовується голосова взаємодія, система повинна спочатку перетворити мовлення на текст або передати команду до відповідного сервісу розпізнавання. Наприклад, у рішенні з мікрофоном і динаміком на базі Raspberry Pi користувач може озвучити проблему, після чого система обробляє команду, зіставляє її з базою знань і виводить рекомендацію на екран або відтворює її голосом. Вихідними результатами роботи системи мають бути рекомендації, попередження, інструкції, уточнювальні запитання, повідомлення про стан пристрою або сформоване звернення до фахівця. Відповідь системи повинна бути коректною, короткою на першому етапі та достатньо розгорнутою тоді, коли користувач потребує пояснення. Наприклад, якщо користувач повідомляє про помилку оновлення, система має не просто назвати можливу причину, а запропонувати перевірити заряд, стабільність мережі, доступність пам’яті та повторити процедуру після усунення виявленого чинника. Якщо проблема не може бути розв’язана автоматич- но, система повинна повідомити про це без хибних обіцянок і передати користувачеві варіант подальших дій [26, с. 94-95]. Одним із центральних завдань є вибір способу обробки запитів користувача. Для простих звернень можна використовувати правила, ключові слова, таблиці відповідностей і заздалегідь підготовлені сценарії підтримки. Для складніших повідомлень доцільним є застосування методів 44 обробки природної мови, які дають змогу визначати намір користувача навіть за неточних або неповних формулювань. Наприклад, запити «пристрій не бачить мережу», «немає інтернету» і «не підключається до Wi-Fi» можуть належати до однієї категорії, хоча сформульовані по- різному. Задача AI системи полягає в тому, щоб не обмежуватися буквальним пошуком фрази, а розпізнавати зміст проблеми та добирати відповідний спосіб реагування [19, с. 22]. Для вбудованого пристрою важливо визначити, які операції виконуватимуться локально, а які передаватимуться зовнішньому сервісу. Локально можуть виконуватися перевірка стану пристрою, обробка простих команд, вибір готової інструкції, відображення повідомлень, збереження журналу подій і попередня класифікація звернення. Зовнішній сервіс може застосовуватися для складного мовного аналізу, генерації розгорнутих пояснень, пошуку у великій базі знань або створення заявки до служби підтримки. Наприклад, пристрій на базі STM32 може виконувати базову діагностику й передавати дані до мобільного застосунку, тоді як складна відповідь формується на сервері або в хмарному AI сервісі [19, с. 23]. Постановка задачі також передбачає визначення бази знань, яка є інформаційною основою відповідей системи. Вона може містити описи помилок, алгоритми усунення несправностей, правила експлуатації, технічні характеристики, відповіді на типові запитання та рекомендації з безпечного використання. Якщо AI модуль не спирається на перевірену інформаційну базу, існує ризик формування неточних або небезпечних порад. Наприклад, для пристрою, що працює з живленням або сенсорами, неправильна інструкція може призвести до пошкодження компонентів або некоректної роботи системи [11, с. 10]. Важливим елементом постановки задачі є забезпечення діалогового режиму, у якому система може уточнювати інформацію та послідовно 45 вести користувача до розв’язання проблеми. Технічні звернення часто є неповними, оскільки користувач не завжди знає, які саме параметри важливі для діагностики. Система повинна ставити уточнювальні запитання, але не перевантажувати користувача зайвою кількістю дій. Наприклад, якщо користувач повідомляє, що пристрій «завис», система може запитати, чи реагують кнопки, чи світиться індикатор, чи було оновлення перед збоєм і чи зберігся зв’язок із мережею [11, с. 12]. Окремо слід визначити задачу первинної діагностики, яка ґрунтується на аналізі стану самого пристрою. Вбудований пристрій може надавати системі інформацію про температуру, напругу живлення, стан мережевого підключення, використання пам’яті, помилки сенсорів або результати самоперевірки. Наприклад, плата Arduino Nano 33 BLE Sense Rev2 має сенсорні можливості, які можуть використовуватися для отримання даних про рух або умови середовища, що важливо для певних типів пристроїв. Якщо система підтримки використовує ці дані, вона може пояснити користувачеві не лише те, що сталася помилка, а й чому вона могла виникнути. В цьому полягає перевага AI підтримки на базі вбудованого пристрою порівняно зі звичайним чат-ботом, який не має доступу до фактичного стану обладнання [19, с. 24]. Задача розроблення має враховувати обмеження пам’яті, продуктив- ності та енергоспоживання. Якщо пристрій має невеликий обсяг оперативної пам’яті, система не може зберігати довгі діалоги, великі мовні моделі або повну технічну документацію. Якщо процесор має обмежену продуктивність, складні алгоритми можуть спричинити затримки відповіді або нестабільну роботу. Наприклад, Raspberry Pi Pico добре підходить для простих керувальних і діагностичних задач, але його ресурси не розраховані на локальне виконання великих мовних моделей. Тому постановка задачі повинна передбачати оптимізацію програмного коду, обмеження обсягу локальних даних тощо [32, с. 10]. 46 Під час створення AI системи необхідно визначити вимоги до інтерфейсу взаємодії з користувачем. Він може бути текстовим, голосовим, графічним, кнопковим або комбінованим, залежно від можливостей пристрою та умов його використання. Якщо пристрій має невеликий дисплей, система повинна надавати короткі повідомлення та послідовні кроки, які не потребують великого обсягу тексту. Якщо передбачена взаємодія через мобільний застосунок, користувач може отримувати докладніші пояснення, переглядати історію звернень і передавати додаткову інформацію. Наприклад, для пристрою «розумного дому» з ESP32-S3 зручною може бути взаємодія через застосунок, де користувач бачить стан модуля, повідомлення про помилки й поради щодо налаштування [11, с. 14]. Постановка задачі має включати визначення умов, за яких система передає звернення людині або зовнішній службі підтримки. AI модуль не повинен самостійно вирішувати питання, які пов’язані з апаратною несправністю, небезпечним втручанням, гарантійним обслуговуванням або невідомою помилкою. У таких випадках система має сформувати опис проблеми, додати службові параметри, зберегти попередні кроки діалогу та передати цю інформацію фахівцю. Наприклад, якщо система виявила повторювану помилку після кількох перезавантажень або підозру на несправність живлення, вона повинна припинити автоматичні рекоменда- ції, які можуть погіршити стан пристрою [36, с. 112]. Важливою частиною задачі є забезпечення захисту даних користувача та службової інформації пристрою. Система технічної підтримки може працювати з мережевими параметрами, журналами помилок, ідентифікаторами пристрою, історією звернень і персоналізованими налаштуваннями. Якщо ці дані передаються до зовнішнього сервісу, потрібно обмежити їхній обсяг і забезпечити безпечний канал обміну. Наприклад, під час роботи з хмарним AI сервісом не варто передавати 47 зайві персональні дані, якщо для формування відповіді достатньо коду помилки та типу пристрою. Задача розроблення також передбачає визначення критеріїв оцінювання ефективності системи. До таких критеріїв можуть належати точність класифікації запитів, швидкість формування відповіді, кількість успішно розв’язаних типових звернень, рівень помилкових рекомендацій, стабільність роботи, витрати пам’яті та енергоспоживання. Для користувацької взаємодії важливими є зрозумілість відповідей, логічність інструкцій і здатність системи коректно ставити уточнювальні запитання. Наприклад, якщо система правильно розпізнає більшість типових звернень щодо підключення, живлення та налаштувань, але повільно реагує або дає надто складні пояснення, її ефективність буде обмеженою [36, с. 133]. В межах постановки задачі необхідно визначити програмні засоби, які можуть бути використані для реалізації системи. Для локальної частини можуть застосовуватися мови програмування C, C++, Python або MicroPython, залежно від апаратної платформи та обсягу задач. Для обробки запитів можуть використовуватися правила, локальні класифікатори, спрощені моделі машинного навчання або взаємодія з LLM через API. Наприклад, на Raspberry Pi можна реалізувати локальний сервер, який приймає повідомлення від користувача, звертається до бази знань і за потреби передає запит до мовної моделі. Для мікроконтролерів доцільнішим є варіант, коли пристрій виконує первинний аналіз і надсилає структуровані дані до потужнішого вузла [32, с. 11]. Отже, постановка задачі розроблення AI системи технічної підтримки користувача на базі вбудованого пристрою полягає у створенні рішення, яке поєднує локальну діагностику, опрацювання звернень, роботу з базою знань, формування рекомендацій і передавання складних випадків фахівцю. 48 Висновки до розділу 1 Проведений аналіз сучасних AI систем технічної підтримки користувачів показав, що технології штучного інтелекту дедалі активніше використовуються для автоматизації взаємодії між користувачем і технічними засобами. Встановлено, що чат-боти, голосові асистенти та великі мовні моделі забезпечують можливість швидкого опрацювання звернень, класифікації проблем, формування рекомендацій і надання допомоги у зрозумілій для користувача формі. Визначено, що сучасні AI рішення можуть функціонувати не лише як інформаційні довідкові системи, а і як інтелектуальні помічники, здатні підтримувати діалог, аналізувати контекст звернення та використовувати бази знань для формування відповідей. Дослідження сучасних платформ і сервісів дало змогу встановити основні напрями розвитку AI підтримки, пов’язані з підвищенням точності відповідей, автоматизацією типових звернень і розширенням можливостей локальної взаємодії з користувачем. В процесі аналізу особливостей використання вбудованих пристроїв встановлено, що їх застосування у системах технічної підтримки має низку специфічних переваг і обмежень. З’ясовано, що такі пристрої можуть виконувати функції локальної діагностики, збору службових даних, відображення повідомлень, передавання інформації до зовнішніх сервісів і реалізації первинної взаємодії з користувачем. Водночас визначено, що ефективність AI системи значною мірою залежить від обчислювальних можливостей пристрою, обсягу пам’яті, стабільності мережевого підключення та рівня енергоспоживання. Аналіз сучасних апаратних платформ показав, що мікроконтролерні та одноплатні рішення мають різний рівень продуктивності, тому вибір конкретного пристрою повинен здійснюватися з урахуванням складності AI функцій, способу взаємодії з користувачем і вимог до автономності системи. 49 В результаті формування вимог і постановки задачі визначено, що AI система технічної підтримки на базі вбудованого пристрою повинна забезпечувати приймання, аналіз та обробку звернень користувача, виконання первинної діагностики технічного стану пристрою, роботу з базою знань, формування зрозумілих рекомендацій і передавання складних випадків фахівцю технічної підтримки. Встановлено, що ефективність функціонування такої системи значною мірою залежить від швидкості обробки запитів, стабільності роботи програмно-апаратних компонентів, точності визначення типу проблеми та здатності системи працювати в умовах обмежених ресурсів вбудованого середовища. З’ясовано, що AI система повинна відповідати вимогам надійності, безпеки, енергоефектив- ності, зручності взаємодії з користувачем і забезпечувати коректне функціонування навіть у випадку нестабільного мережевого підключення або обмеженого обсягу пам’яті пристрою. Обґрунтовано доцільність поєднання локальної обробки простих звернень і базових діагностичних операцій із використанням зовнішніх AI сервісів для виконання складнішого мовного аналізу, генерації розгорнутих відповідей та оновлення інформаційної бази системи. Визначено, що такий підхід дозволяє зменшити навантаження на вбудований пристрій, забезпечити швидшу реакцію на типові проблеми користувачів і водночас розширити функціональні можливості AI системи технічної підтримки. Отримані результати дозволили сформувати цілісне уявлення про основні принципи побудови AI системи технічної підтримки користувача та визначити ключові технічні й функціональні аспекти її реалізації на базі вбудованого пристрою. 50 2. МЕТОДИ АБО МОДЕЛІ СТВОРЕННЯ КОМПОНЕНТІВ ТА ЇХ ДОСЛІДЖЕННЯ 2.1 Вибір методів обробки запитів користувача та формування відповідей Вибір методів обробки запитів користувача та формування відповідей є одним із ключових етапів створення AI системи технічної підтримки, оскільки саме від цього залежить здатність системи правильно розуміти звернення, визначати характер проблеми та надавати корисні рекомендації. У технічній підтримці користувачі часто формулюють запити неточно, використовують побутові вислови, скорочення, помилки в термінах або неповний опис ситуації. Тому система не може обмежуватися простим порівнянням введеного тексту з готовими фразами, адже одна й та сама проблема може бути описана багатьма різними способами. Для ефективної роботи потрібне поєднання кількох методів: попередньої обробки тексту, класифікації наміру, пошуку в базі знань, контекстного аналізу, генерації відповіді та перевірки її відповідності технічним даним [35, с. 64]. Першим етапом обробки запиту є попереднє очищення й нормалізація введеної користувачем інформації. На цьому етапі система може усувати зайві символи, виправляти типові помилки, переводити текст до єдиного регістру, виділяти ключові слова, розпізнавати технічні позначення, коди помилок і назви компонентів. Наприклад, якщо користувач вводить повідомлення «не вмикаєтся вайфай», система має розпізнати, що йдеться про проблему з Wi-Fi підключенням, навіть якщо слово написане з помилкою [2, с. 35]. Для цього можуть застосовуватися словники технічних термінів, правила нормалізації тексту, алгоритми пошуку схожих слів і засоби обробки природної мови. Важливим методом є виділення наміру користувача, тобто визначення того, яку саме дію або 51 відповідь він очікує від системи. У технічній підтримці наміри можуть бути різними: отримати інструкцію з налаштування, повідомити про помилку, перевірити стан пристрою, дізнатися причину несправності, виконати перезавантаження або передати звернення фахівцю. Наприклад, фрази «як підключити пристрій до мережі», «не можу налаштувати Wi-Fi» і «що робити, якщо немає з’єднання» можуть належати до близької категорії, пов’язаної з мережевим підключенням. Для визначення наміру можуть використовуватися класифікатори на основі правил, машинного навчання або моделей обробки природної мови. У системі на базі вбудованого пристрою такий метод дає змогу швидко спрямувати запит до відповідного сценарію підтримки [2, с. 36]. Для простих і типових звернень доцільним є використання правил і шаблонів, оскільки вони забезпечують передбачувану поведінку системи та не потребують значних обчислювальних ресурсів. Правила можуть будуватися за принципом відповідності між ключовими словами, кодами помилок, станами пристрою та готовими інструкціями. Наприклад, якщо в журналі подій зафіксовано низький заряд акумулятора, а користувач повідомляє, що пристрій вимикається, система може запропонувати перевірити джерело живлення або зарядити акумулятор. Перевагою такого підходу є простота реалізації, швидкість роботи та можливість чітко контролювати відповіді [36, с. 114]. Методи пошуку в базі знань є необхідними для формування відповідей, які спираються на перевірену технічну інформацію. База знань може містити описи помилок, інструкції з експлуатації, порядок налаштування, правила безпечного використання, рекомендації з усунення несправностей і відповіді на поширені запитання. Для пошуку релевантної інформації можуть застосовуватися класичні інформаційно-пошукові методи, зокрема TF-IDF або BM25, які оцінюють відповідність документа чи фрагмента тексту запиту користувача. Наприклад, якщо користувач 52 вводить «після оновлення пристрій не запускається», система може знайти матеріали, пов’язані з відновленням після невдалого оновлення, перевіркою живлення та поверненням до попередньої версії програмного забезпечення [36, с. 115]. Окрім класичного пошуку за словами, у сучасних AI системах підтримки важливе значення має семантичний пошук, який враховує не лише збіг термінів, а й смислову близькість між запитом і матеріалами бази знань. Для цього можуть використовуватися векторні подання тексту, коли запити користувача та фрагменти документації перетворюються на числові представлення, придатні для порівняння за змістом. Наприклад, моделі типу Sentence-BERT застосовуються для отримання векторних подань речень і можуть допомагати знаходити релевантні відповіді навіть тоді, коли користувач не використовує точні технічні формулювання. Якщо користувач пише «пристрій довго думає», семантичний пошук може пов’язати це з матеріалами про затримку відповіді, перевантаження процесора або нестачу пам’яті [35, с. 65]. Для обробки складніших звернень доцільним є використання методів машинного навчання, які дозволяють системі класифікувати запити на основі попередньо підготовлених прикладів. Навчальна вибірка може містити типові повідомлення користувачів і відповідні категорії проблем: живлення, мережа, оновлення, помилка сенсора, налаштування, відсутність відповіді, некоректне відображення даних. Після навчання модель може визначати, до якої категорії належить новий запит, навіть якщо він сформульований інакше, ніж попередні приклади. Наприклад, фрази «не бачить роутер» і «немає підключення до інтернету» можуть бути віднесені до однієї групи мережевих проблем. Для вбудованого пристрою такі моделі мають бути компактними, щоб не створювати надмірного навантаження на пам’ять і процесор [35, с. 66]. 53 Великі мовні моделі можуть використовуватися для формування більш природних, розгорнутих і зрозумілих відповідей користувачеві. Їхня перевага полягає у здатності працювати з різними формулюваннями, підтримувати контекст діалогу, пояснювати складні технічні дії простішою мовою та адаптувати відповідь до запиту. Наприклад, модель GPT може переформулювати технічну інструкцію так, щоб користувач без спеціальної підготовки зрозумів, які кроки потрібно виконати для відновлення підключення. Водночас у технічній підтримці мовна модель не повинна бути єдиним джерелом відповіді, оскільки існує ризик неточних або надмірно узагальнених рекомендацій [44, с. 190]. Одним із найбільш придатних підходів для AI систем технічної підтримки є поєднання пошуку в базі знань із генерацією відповіді, що часто позначається як RAG-підхід. Його сутність полягає в тому, що система спочатку знаходить релевантні фрагменти технічної інформації, а потім на їхній основі формує відповідь користувачеві. Такий підхід дозволяє зменшити ризик вигаданих або некоректних відповідей, оскільки мовна модель спирається на наявну документацію, інструкції чи описи помилок. Наприклад, якщо база знань містить порядок усунення помилки підключення, AI модуль може сформувати з цього матеріалу коротку покрокову рекомендацію. Для вбудованого пристрою RAG-підхід може реалізовуватися через локальне зберігання стислих інструкцій або через звернення до зовнішнього сервісу з ширшою інформаційною базою. Формування відповіді повинно враховувати не лише зміст запиту, а й технічний стан пристрою. Якщо система має доступ до службових параметрів, вона може робити рекомендації точнішими та кориснішими. Наприклад, якщо користувач повідомляє про нестабільну роботу пристрою, а система бачить низький рівень заряду, підвищену температуру або нестачу пам’яті, відповідь має враховувати саме ці дані. У такому 54 випадку AI модуль може поєднувати текстовий аналіз із даними сенсорів, журналів подій і параметрів роботи програмного забезпечення. Для системи на базі вбудованого пристрою важливо передбачити багаторівневу обробку запитів. На першому рівні можуть виконуватися прості локальні перевірки, наприклад аналіз коду помилки, стану живлення, мережевого підключення або натискання кнопок. На другому рівні система може звертатися до локальної бази знань і добирати готові інструкції за категорією проблеми. На третьому рівні складні запити можуть передаватися до зовнішнього AI сервісу, який виконує глибший мовний аналіз і формує розгорнуту відповідь [36, с. 116]. Важливим методом підвищення якості відповідей є використання контексту діалогу. Користувач може ставити кілька послідовних запитань, уточнювати проблему, повідомляти про результати виконаних дій або змінювати формулювання звернення. Система повинна зберігати ключові елементи попередньої взаємодії, щоб не вимагати повторення тієї самої інформації. Наприклад, якщо користувач уже повідомив, що проблема стосується Wi-Fi, наступне повідомлення «а якщо індикатор блимає?» повинно інтерпретуватися саме в контексті мережевого підключення. У ресурсно обмежених пристроях контекст може зберігатися у скороченому вигляді: категорія проблеми, остання дія, код помилки та поточний етап інструкції [44, с. 191]. Окрему увагу потрібно приділяти механізмам уточнення запиту, оскільки не всі звернення користувача є достатньо інформативними. Якщо система не має впевненості у визначенні проблеми, вона повинна ставити короткі й логічні запитання, які допомагають звузити коло можливих причин. Наприклад, замість загальної відповіді на повідомлення «пристрій не працює» система може уточнити, чи вмикається індикатор живлення, чи є повідомлення на екрані, чи пристрій реагує на кнопки та чи виникла проблема після оновлення [44, с. 192]. 55 Формування відповіді має бути підпорядковане вимогам зрозумілості, послідовності та безпечності. Система повинна подавати рекомендації у вигляді чітких кроків, не змішувати кілька несумісних дій і попереджати користувача про можливі ризики. Наприклад, якщо проблема пов’язана з живленням, система має рекомендувати безпечну перевірку кабелю або джерела живлення, але не пропонувати дії, які потребують розбирання пристрою без відповідної кваліфікації. В разі складної або небезпечної ситуації відповідь повинна містити пораду звернутися до фахівця. Автоматична відповідь має не лише допомагати, а й не створювати додаткових ризиків для користувача чи обладнання [2, с. 35]. У практичній реалізації можуть використовуватися різні програмні засоби для обробки запитів і побудови діалогової взаємодії. Наприклад, Rasa дає змогу створювати діалогові системи з визначенням намірів, сутностей і сценаріїв взаємодії, що може бути корисним для локальних або приватних рішень технічної підтримки. Dialogflow CX застосовується для побудови складніших розмовних агентів, у яких можна керувати багатокроковими діалогами та передаванням користувача між різними сценаріями. OpenAI API або подібні сервіси можуть використовуватися для генерації природних відповідей і пояснення технічних інструкцій простою мовою. Для системи на базі вбудованого пристрою вибір такого засобу залежить від вимог до автономності, доступу до мережі, захисту даних і допустимого навантаження на апаратну платформу [38, с. 51]. Для оцінювання обраних методів потрібно враховувати точність розпізнавання запитів, швидкість відповіді, витрати пам’яті, стабільність роботи та якість сформованих рекомендацій. Отже, вибір методів обробки запитів користувача та формування відповідей має ґрунтуватися на поєднанні технічної точності, ресурсної доцільності й зручності взаємодії. 56 2.2 Модель взаємодії AI модуля, бази знань та вбудованого пристрою Модель взаємодії AI модуля, бази знань та вбудованого пристрою є основою функціонування системи технічної підтримки користувача, оскільки саме вона визначає порядок обміну інформацією між програмними й апаратними компонентами. У такій системі вбудований пристрій виступає джерелом технічних даних, AI модуль виконує аналіз запитів і формування відповідей, а база знань забезпечує інформаційну основу для рекомендацій [46, с. 18]. Їх узгоджена робота дає змогу не лише відповідати на запитання користувача, а й враховувати фактичний стан пристрою, його помилки, параметри роботи та доступні сценарії усунення несправностей. Завдяки цьому технічна підтримка стає не загальною консультацією, а цілеспрямованою допомогою, пов’язаною з конкретною ситуацією користувача. Структуру запису бази знань AI системи технічної підтримки наведено в додатку А. В межах такої моделі вбудований пристрій виконує роль первинного технічного вузла, який фіксує події, приймає команди, збирає службові параметри та передає їх до AI модуля. Це можуть бути дані про стан живлення, мережеве підключення, температуру, рівень пам’яті, активність сенсорів, помилки програмного забезпечення або результати самоперевірки. Наприклад, пристрій на базі ESP32 може передавати інформацію про стан Wi-Fi з’єднання, рівень сигналу та спроби повторного підключення. Якщо користувач повідомляє про проблему з мережею, AI модуль отримує не лише текстовий запит, а й технічні ознаки, які допомагають точніше визначити причину несправності [2, с. 35]. AI модуль у цій моделі виконує функцію інтелектуального посередника між користувачем, вбудованим пристроєм і базою знань. Він аналізує звернення користувача, визначає намір, зіставляє його з 57 технічними параметрами пристрою та обирає відповідний спосіб реагування. Якщо проблема є типовою, модуль може швидко знайти інструкцію в базі знань і сформувати коротку відповідь. Якщо запит є нечітким або неповним, система повинна поставити уточнювальне запитання, наприклад з’ясувати, чи виникла помилка після оновлення, перезавантаження або зміни налаштувань. Цей принцип дозволяє уникнути випадкових рекомендацій і наблизити відповідь до реального стану пристрою [36, с. 117]. База знань є інформаційним ядром системи, оскільки вона містить перевірені відомості, на основі яких AI модуль формує відповіді. До її складу можуть входити інструкції користувача, технічні описи, таблиці кодів помилок, алгоритми перевірки, правила безпечної експлуатації, відповіді на типові запитання та службові сценарії діагностики. Наприклад, для пристрою з вбудованим дисплеєм база знань може містити пояснення повідомлень, які з’являються на екрані, та порядок дій для кожного випадку. Важливо, щоб ця база була структурованою, оскільки AI модуль повинен швидко знаходити потрібний фрагмент інформації, а не опрацьовувати весь масив даних без попереднього відбору. Взаємодія між користувачем і системою починається із введення запиту або виникнення події, яку пристрій може зафіксувати автоматично. Користувач може написати повідомлення, вимовити голосову команду, натиснути кнопку допомоги або обрати відповідний пункт у меню пристрою. Одночасно система може отримати службові дані, які уточнюють ситуацію, наприклад код помилки, стан сенсора або інформацію про останні дії користувача. На цьому етапі AI модуль об’єднує дані з різних джерел і формує початкове уявлення про проблему. Якщо інформації достатньо, система переходить до пошуку рішення, а якщо ні — ініціює короткий уточнювальний діалог [21, с. 90]. 58 У практичному застосуванні важливим є розмежування локальної та зовнішньої обробки даних. Локально на вбудованому пристрої можуть виконуватися прості перевірки, фіксація стану, розпізнавання коду помилки, вибір базової інструкції та виведення короткого повідомлення. Зовнішній AI сервіс може використовуватися для складнішого мовного аналізу, генерації розгорнутої відповіді або пошуку у великій інформаційній базі. Наприклад, Raspberry Pi може виконувати локальний серверний модуль, який приймає запит користувача, звертається до локальної бази даних SQLite і за потреби передає складний запит до мовної моделі через API [21, с. 91]. Одним із ефективних варіантів організації взаємодії є використання пошуку з подальшим формуванням відповіді на основі знайденої інформації. У такій схемі AI модуль спочатку аналізує запит користувача, після чого звертається до бази знань і знаходить релевантні фрагменти технічної інформації. Потім на основі цих фрагментів формується відповідь, яка має бути зрозумілою для користувача та відповідати фактичним характеристикам пристрою. Наприклад, якщо база знань містить інструкцію з відновлення після невдалого оновлення, AI модуль може перетворити її на послідовність простих кроків. Для підвищення точності пошуку база знань може бути організована не лише як набір текстових інструкцій, а й як сукупність категорій, тегів, кодів помилок і векторних подань фрагментів інформації. Категорії дають змогу швидко віднести проблему до певного типу, наприклад живлення, мережа, сенсори, оновлення або налаштування. Теги допомагають уточнювати зміст матеріалів, а векторні подання корисні для пошуку за змістом, коли користувач описує проблему не технічними словами. Наприклад, у системах, де використовуються FAISS або Chroma, фрагменти бази знань можуть зберігатися у вигляді векторів, що дає змогу знаходити близькі за змістом відповіді [2, с. 35]. 59 Вбудований пристрій у цій моделі не повинен виконувати всі AI операції самостійно, особливо якщо має обмежену пам’ять і невисоку продуктивність. Його основна роль може полягати у збиранні параметрів, виконанні базової логіки, збереженні коротких повідомлень і передаванні структурованих даних до потужнішого модуля. Наприклад, STM32 може бути доцільним для контролю стану сенсорів, обробки сигналів, роботи з кнопками та індикаторами, але не для локального виконання великих мовних моделей. У такому випадку AI модуль може бути розміщений на окремому одноплатному комп’ютері або зовнішньому сервері. Це дозволяє зберегти надійність вбудованого пристрою й не перевантажувати його задачами, для яких він не призначений [21, с. 92]. Модель взаємодії має передбачати обмін даними у двох напрямках. Від пристрою до AI модуля передаються службові параметри, повідомлення про помилки, команди користувача та результати локальної діагностики. Від AI модуля до пристрою надходять сформовані рекомендації, запити на додаткову перевірку, команди відображення повідомлень або рішення про передавання звернення фахівцю. Наприклад, якщо AI модуль визначає, що проблема пов’язана з перегрівом, він може надіслати пристрою команду показати попередження на екрані та запропонувати користувачеві вимкнути пристрій на певний час [46, с. 19]. Важливою частиною моделі є журналювання подій, оскільки без історії роботи пристрою складно точно встановити причину проблеми. Журнал може містити час виникнення помилки, тип події, стан живлення, мережеві параметри, виконані користувачем дії та відповіді системи. Наприклад, якщо користувач кілька разів звертався через одну й ту саму помилку, AI модуль має враховувати повторюваність ситуації та не пропонувати одні й ті самі дії без зміни підходу. Збереження журналу також допомагає під час передавання складного випадку фахівцю, оскільки спеціаліст отримує не загальний опис, а послідовність подій. Для 60 вбудованого пристрою обсяг такого журналу може бути обмеженим, тому доцільно зберігати найважливіші записи й періодично передавати їх до зовнішнього сховища [49, с. 12]. Значну роль у роботі моделі відіграє механізм прийняття рішення про рівень обробки запиту. Якщо запит простий і відповідає наявному локальному сценарію, система може надати відповідь без звернення до зовнішнього AI сервісу. Якщо ж проблема є складною, містить невизначеність або потребує розгорнутого пояснення, AI модуль може використати зовнішню мовну модель. Наприклад, для типового повідомлення «низький заряд» достатньо локальної інструкції, а для складного опису «після оновлення пристрій перезавантажується і не підключається до мережі» може знадобитися поєднання аналізу журналу, пошуку в базі знань і генерації відповіді. Безпека обміну даними є обов’язковою умовою роботи такої моделі, оскільки система може обробляти службову та користувацьку інформацію. До зовнішнього AI сервісу не повинні передаватися зайві персональні дані, якщо для формування відповіді достатньо технічних параметрів і коду помилки. Наприклад, замість повного журналу роботи пристрою система може передати лише категорію проблеми, модель пристрою, версію програмного забезпечення та короткий опис несправності. Це відповідає принципу мінімізації даних і знижує ризики, пов’язані з конфіденційністю. Крім того, взаємодія між пристроєм, AI модулем і базою знань має здійснюватися через захищені канали, особливо якщо використовується мережеве підключення [46, с. 20]. Оновлення бази знань є необхідною умовою підтримання актуаль- ності відповідей. У процесі експлуатації пристрою можуть з’являтися нові помилки, змінюватися програмне забезпечення, уточнюватися інструкції або додаватися нові функції. Якщо база знань не оновлюється, AI модуль може надавати застарілі рекомендації, що знижує якість технічної 61 підтримки. Наприклад, після оновлення прошивки пристрою порядок налаштування мережі може змінитися, тому система повинна використову- вати актуальну інструкцію, а не попередній варіант. Оновлення має виконуватися контрольовано, щоб не порушити роботу критичних функцій і не видалити важливі локальні сценарії підтримки [45, с. 46]. Для забезпечення стабільності системи важливо передбачити роботу в умовах нестабільного або відсутнього мережевого з’єднання. Якщо пристрій не має доступу до зовнішнього AI сервісу, він усе одно повинен надати користувачеві базову допомогу. Для цього на локальному рівні можуть зберігатися короткі інструкції, таблиці основних помилок і повідомлення про безпечні дії. Наприклад, пристрій на основі ESP32 може вивести повідомлення про втрату Wi-Fi з’єднання та запропонувати перевірити роутер, навіть якщо не має доступу до хмарного сервісу [49, с. 13]. Модель взаємодії повинна також враховувати спосіб подання відповіді користувачеві. Якщо пристрій має невеликий екран, відповідь має бути короткою, структурованою та поданою у вигляді послідовних кроків. Якщо взаємодія відбувається через мобільний застосунок або вебінтерфейс, система може надати докладніше пояснення, показати історію дій, додати попередження або запропонувати зв’язок із фахівцем. Наприклад, у пристрої «розумного дому» коротке повідомлення може відображатися на самому пристрої, а розгорнута інструкція — у застосунку користувача. Завдяки цьому одна й та сама AI система може адаптувати відповідь до можливостей каналу взаємодії (додаток Б). Отже, модель взаємодії AI модуля, бази знань та вбудованого пристрою повинна забезпечувати узгоджений обмін даними між користувачем, технічним станом пристрою та перевіреними інформацій- ними матеріалами. 62 Висновки до розділу 2 Ефективність AI системи технічної підтримки значною мірою залежить від правильного поєднання методів обробки користувацьких запитів і механізмів формування відповідей. Для такої системи недостатньо простого зіставлення запиту з готовими шаблонами, оскільки користувачі можуть описувати одну й ту саму проблему різними словами, з помилками, скороченнями або неповною інформацією. Саме тому важливими є попередня обробка тексту, визначення наміру користувача, класифікація проблеми, пошук у базі знань, семантичний аналіз і контрольована генерація відповіді. Найбільш обґрунтованим є комбінова- ний підхід, за якого типові ситуації обробляються локально за допомогою правил і готових інструкцій, а складніші звернення аналізуються із залученням пошукових методів, векторних подань, RAG-підходу або мовних моделей. База знань має виконувати роль перевіреного інформаційного джерела, яке забезпечує технічну точність і змістову обґрунтованість відповідей. Її наповнення повинно охоплювати інструкції, коди помилок, правила безпечної експлуатації, типові сценарії усунення несправностей і пояснення службових повідомлень пристрою. AI модуль у такій системі не повинен діяти ізольовано, адже якісна підтримка можлива лише тоді, коли відповідь формується з урахуванням як текстового запиту, так і фактичного стану пристрою. Поєднання інформації з журналів подій, сенсорів, параметрів живлення, мережевого підключення, пам’яті чи температури дає змогу надавати користувачеві не загальні поради, а точніші рекомендації, пов’язані з конкретною технічною ситуацією. Отже, взаємодія AI модуля, бази знань та вбудованого пристрою повинна будуватися на узгодженому обміні даними, розмежуванні локальної й зовнішньої обробки, захисті інформації та можливості роботи навіть за нестабільного мережевого з’єднання. 63 3. АЛГОРИТМИ, ПРОГРАМНІ ЗАСОБИ ДЛЯ ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ МЕТОДІВ, МОДЕЛЕЙ, КОМПОНЕНТІВ 3.1 Розроблення алгоритму роботи AI системи технічної підтримки користувача Розроблений алгоритм роботи AI системи технічної підтримки користувача забезпечує послідовне опрацювання звернення від моменту його надходження до формування відповіді або передавання складного випадку фахівцю. Його логіка ґрунтується на поєднанні аналізу користувацького повідомлення, перевірки технічного стану вбудованого пристрою, пошуку інформації в базі знань і формування рекомендацій за допомогою AI модуля. Такий підхід дає змогу враховувати не лише текст запиту, а й фактичні параметри пристрою, що підвищує точність технічної підтримки. Алгоритм орієнтований на автоматизацію первинної допомоги користувачеві, зменшення кількості типових звернень до оператора та забезпечення швидкої реакції на поширені проблеми. Робота системи починається з ініціалізації основних компонентів, які забезпечують приймання запитів, доступ до бази знань, зчитування параметрів пристрою та формування відповіді. На цьому етапі перевіряється працездатність модуля введення даних, локального сховища, мережевого підключення, журналу подій і програмного компонента AI обробки. Якщо система функціонує на базі одноплатного комп’ютера, наприклад Raspberry Pi, локальний програмний модуль приймає повідомлення користувача, взаємодіє з базою знань і передає складні запити до зовнішнього AI сервісу. Якщо використовується мікро- контролерний пристрій на зразок ESP32, основна увага зосереджується на збиранні технічних параметрів, передаванні структурованих даних і виведенні коротких повідомлень користувачеві [38, с. 54]. 64 Після ініціалізації система переходить у режим очікування звернення або технічної події. Звернення надходить у вигляді текстового повідомлен- ня, голосової команди, натискання кнопки допомоги або вибору відповідного пункту в меню пристрою. Технічна подія фіксується автоматично, якщо пристрій виявляє втрату мережевого з’єднання, перегрів, низький заряд, помилку сенсора, нестачу пам’яті або збій під час оновлення. Завдяки цьому алгоритм охоплює два типи взаємодії: активне звернення користувача та автоматичне реагування на стан пристрою. Практична логіка алгоритму передбачає чітке визначення вхідних і вихідних даних. До вхідних даних належать повідомлення користувача, код помилки, параметри пристрою, записи журналу подій, стан мережевого підключення та фрагменти бази знань. До вихідних даних належать рекомендація, уточнювальне запитання, попередження, службове повідомлення, запис у журналі або сформоване звернення до фахівця. Такий розподіл дає змогу впорядкувати інформаційні потоки та простежити, як саме система переходить від отримання запиту до надання технічної допомоги. Основні дані, які використовуються в алгоритмі, наведено в таблиці 3.1. Таблиця 3.1. Вхідні та вихідні дані алгоритму роботи AI системи технічної підтримки користувача Роль у роботі Вид даних Зміст даних алгоритму Запит Текстове або голосове Визначення змісту користувача повідомлення проблеми Службовий ідентифікатор Пошук відповідної Код помилки несправності інструкції Живлення, пам’ять, Параметри Первинна діагностика температура, мережа, пристрою стану сенсори Попередні помилки та Уточнення причини Журнал подій виконані дії несправності 65 Продовження таблиці 3.1. Роль у роботі Вид даних Зміст даних алгоритму Інструкції, сценарії, описи Джерело технічно База знань помилок коректних відповідей Відповідь Рекомендація, уточнення або Надання підтримки системи попередження користувачеві Після приймання звернення виконується попередня обробка повідомлення. Текст очищується від зайвих символів, нормалізується, аналізується за ключовими словами та технічними ознаками, після чого система виділяє можливі назви компонентів, коди помилок і характерні формулювання проблеми. Якщо запит надходить у голосовій формі, спочатку здійснюється перетворення мовлення на текст, а далі застосовується та сама процедура мовного аналізу. Наприклад, формулювання «не підключається до вайфаю» зіставляється з категорією мережевих проблем, навіть якщо користувач не використовує офіційний технічний термін. Попередня обробка забезпечує підготовку повідомлення до класифікації та зменшує вплив помилок у формулюванні запиту. Наступний етап алгоритму полягає у визначенні наміру користувача та категорії проблеми. Система розпізнає, чи користувач просить інструкцію, повідомляє про несправність, уточнює значення помилки, потребує перевірки стану пристрою або хоче передати звернення фахівцю. Для цього використовується поєднання правил, ключових ознак, класифікації запитів і звернення до AI модуля в разі складнішого формулювання. Наприклад, фрази «пристрій не бачить мережу», «немає Wi-Fi» і «не можу підключитися до інтернету» відносяться до однієї категорії, пов’язаної з мережевим підключенням. Якщо рівень упевненості в класифікації є недостатнім, алгоритм переходить до етапу уточнювального діалогу [38, с. 55]. 66 Паралельно з аналізом звернення виконується первинна діагностика вбудованого пристрою. Система зчитує доступні технічні параметри: рівень заряду, температуру, стан мережевого модуля, використання пам’яті, доступність сенсорів, активність периферійних компонентів і останні записи журналу подій. Якщо користувач повідомляє про повільну роботу, а діагностика фіксує нестачу вільної пам’яті, відповідь формується з урахуванням саме цього чинника. Якщо система виявляє підвищену температуру, рекомендація містить попередження про можливий перегрів і безпечні дії для користувача. Поєднання мовного аналізу та технічних параметрів забезпечує більш точне визначення причини проблеми. Після встановлення категорії звернення система звертається до бази знань. Пошук виконується за кодом помилки, ключовими словами, категорією проблеми, службовими параметрами пристрою або смисловою близькістю між запитом і наявними інструкціями. База знань містить описи типових несправностей, порядок перевірки пристрою, правила безпечного користування, сценарії усунення помилок і варіанти передавання складних випадків фахівцю. Наприклад, для проблеми після оновлення система знаходить матеріали, пов’язані з перевіркою живлення, доступної пам’яті, стабільності мережі та версії програмного забезпечення. Якщо відповідний запис відсутній, алгоритм переходить до формування уточнення або створення звернення до фахівця [38, с. 56]. Умови переходу між етапами алгоритму визначають подальшу поведінку системи. Якщо запит зрозумілий, технічний стан пристрою не містить критичних відхилень, а база знань має відповідну інструкцію, система формує автоматичну відповідь. Якщо запит нечіткий, алгоритм створює уточнювальне запитання, спрямоване на отримання додаткової інформації. Якщо виявлено небезпечний стан, наприклад перегрів або нестабільне живлення, система формує попередження й обмежує подальші дії користувача без консультації фахівця. Якщо проблема повторюється 67 або відсутня в базі знань, формується звернення до служби підтримки із додаванням технічних параметрів і журналу подій (табл. 3.2.). Таблиця 3.2. Умови переходу між етапами алгоритму роботи AI системи технічної підтримки Умова роботи Дія алгоритму Результат системи Запит належить до Вибір інструкції з бази Автоматична типової категорії знань рекомендація Створення Запит сформульовано Отримання додаткових уточнювального нечітко відомостей запитання Зафіксовано код Зіставлення з описом у Цільова технічна помилки базі знань відповідь Виявлено критичний Формування Запобігання стан попередження небезпечним діям Створення звернення Передавання складного Інструкція відсутня до фахівця випадку Мережевий зв’язок Використання Збереження базової недоступний локальних сценаріїв підтримки Формування відповіді виконується після вибору релевантної інформації з бази знань і перевірки технічного контексту. Відповідь складається з короткого пояснення проблеми, послідовності дій і за потреби попередження про обмеження або ризики. У випадку використання AI модуля генерація тексту спирається на знайдені матеріали, а не на довільне формулювання без технічної основи. Наприклад, для проблеми з мережею відповідь містить перевірку живлення, стану Wi-Fi модуля, правильності параметрів підключення та рекомендацію повторити з’єднання. Такий спосіб формування відповіді забезпечує зрозумілість повідомлення й зменшує ризик помилкових дій користувача [29, с. 116]. 68 Уточнювальний діалог реалізовано як окремий етап алгоритму. Він активується тоді, коли повідомлення користувача не містить достатньо інформації для визначення проблеми або коли кілька категорій мають подібний рівень імовірності. Система ставить коротке запитання, яке безпосередньо впливає на подальшу діагностику, наприклад чи світиться індикатор, чи з’являється код помилки, чи проблема виникла після оновлення або чи пристрій підключений до мережі. Після отримання відповіді алгоритм повторно виконує класифікацію та зіставляє нові дані з технічними параметрами пристрою. Алгоритм містить обробку типових технічних ситуацій, які найчастіше трапляються під час експлуатації вбудованих пристроїв. До них належать втрата мережевого підключення, низький заряд, перегрів, помилка оновлення, нестача пам’яті, недоступність сенсора та неправильне налаштування. У разі втрати Wi-Fi з’єднання система перевіряє стан мережевого модуля, рівень сигналу, останні спроби підключення та наявність збережених параметрів мережі. У разі помилки оновлення перевіряється стабільність живлення, доступність пам’яті та стан програмної версії [29, с. 117]. Журнал подій використовується для підвищення послідовності та точності роботи алгоритму. У ньому зберігаються дані про попередні помилки, звернення користувача, запропоновані рекомендації, результати діагностики та повторюваність проблем. Якщо користувач уже виконав певну дію, наприклад перезавантаження пристрою, система не повторює ту саму рекомендацію без потреби. У разі повторного виникнення однієї й тієї самої несправності алгоритм переходить до глибшої перевірки або формування звернення фахівцю. Режим локальної підтримки передбачений для ситуацій, коли зовнішній AI сервіс або мережеве підключення недоступні. У цьому режимі система використовує збережені на пристрої або локальному 69 модулі інструкції, таблиці основних помилок і короткі сценарії діагностики. Наприклад, за відсутності інтернету пристрій усе одно надає користувачеві базові рекомендації щодо перевірки живлення, повторного запуску, стану індикаторів або мережевих параметрів. Такий режим забезпечує безперервність підтримки в умовах нестабільного зв’язку. Він також зменшує залежність системи від зовнішніх ресурсів під час обробки простих ситуацій [22, с. 134]. Передавання складного випадку фахівцю виконується після встановлення ознак, які виходять за межі автоматичної підтримки. До таких ознак належать повторювана помилка, відсутність релевантної інструкції, небезпечний стан пристрою, невдала спроба виконання кількох рекомендацій або низька впевненість AI модуля у визначенні проблеми. Система формує звернення, у якому зазначається опис проблеми, категорія запиту, код помилки, параметри пристрою, записи журналу подій і перелік уже виконаних дій. Наприклад, якщо після кількох спроб відновлення мережевого підключення пристрій не встановлює зв’язок, до звернення додаються дані про рівень сигналу, спроби підключення та повідомлення користувача. Це скорочує час подальшого опрацювання й підвищує інформативність звернення. Послідовність операцій алгоритму охоплює повний цикл роботи системи (додаток В). Спочатку виконується ініціалізація компонентів, після чого система очікує звернення користувача або технічної події. Далі здійснюється попередня обробка повідомлення, визначення категорії проблеми, діагностика стану пристрою, пошук відповідного запису в базі знань і формування відповіді. Якщо даних недостатньо, запускається уточнювальний діалог; якщо проблема не розв’язується автоматично, створюється звернення до фахівця. Блок-схему алгоритму роботи AI системи технічної підтримки користувача наведено нижче. 70 Схема. 3.1. Структурна схема AI системи технічної підтримки користувача 71 Отже, розроблений алгоритм роботи AI системи технічної підтримки користувача забезпечує повний цикл опрацювання звернення з урахуван- ням технічного стану вбудованого пристрою. Його структура поєднує приймання повідомлення, мовну обробку, класифікацію проблеми, первинну діагностику, пошук у базі знань, формування відповіді, уточнювальний діалог і передавання складних випадків фахівцю. Такий алгоритм автоматизує типові ситуації, зберігає базову підтримку в умовах нестабільного зв’язку та використовує зовнішній AI сервіс лише для складніших звернень. 3.2 Програмна реалізація, тестування та оцінювання ефективності системи Програмна реалізація AI системи технічної підтримки користувача здійснювалася з урахуванням сформованих у попередніх підрозділах функціональних і нефункціональних вимог, а також розробленої моделі взаємодії AI модуля, бази знань і вбудованого пристрою. Основне завдання програмної реалізації полягало в тому, щоб перетворити запропонований алгоритм роботи системи на практично придатний програмно-апаратний комплекс, здатний приймати звернення користувача, аналізувати його зміст, враховувати технічний стан пристрою, здійснювати пошук у базі знань і формувати зрозумілу рекомендацію. Оскільки система розглядаєть- ся в контексті вбудованого пристрою, її реалізація не могла обмежуватися лише створенням діалогового AI модуля. Вона повинна була також враховувати апаратні обмеження, стабільність обміну даними, роботу з технічними параметрами пристрою, безпечне формування відповідей і можливість функціонування за умов нестабільного мережевого з’єднання. 72 В межах реалізації було використано модульний підхід, за якого кожна функціональна частина системи виконує окреме завдання та взаємодіє з іншими компонентами через визначені програмні інтерфейси. Такий підхід є доцільним для AI систем технічної підтримки, оскільки дає змогу окремо перевіряти приймання запитів, попередню обробку тексту, класифікацію проблем, діагностику стану пристрою, пошук відповіді в базі знань, формування рекомендації та журналювання подій. Крім того, модульна структура спрощує подальше вдосконалення системи, оскільки окремі компоненти можна замінювати або розширювати без повної перебудови всього програмного комплексу. Наприклад, локальний пошук у базі знань може бути доповнений векторним пошуком, а простий механізм класифікації запитів — моделлю машинного навчання або зовнішнім AI сервісом. Загальна логіка програмної реалізації ґрунтувалася на розподілі функцій між вбудованим пристроєм, локальним програмним модулем, базою знань і AI модулем. Вбудований пристрій виконував роль джерела технічних даних і первинного вузла взаємодії з користувачем. Він фіксував технічні події, отримував службові параметри, передавав інформацію про стан системи та забезпечував базову взаємодію через доступний інтерфейс. Локальний програмний модуль відповідав за попередню обробку звернення, перевірку ключових ознак проблеми, класифікацію запиту, звернення до бази знань і підготовку відповіді. AI модуль використо- вувався для складніших випадків, коли запит був нечітким, нестандартним або потребував формування розгорнутого пояснення природною мовою. База знань виконувала роль контрольованого джерела технічної інформації, що зменшувало ризик формування випадкових або технічно некоректних рекомендацій (табл. 3.3.). 73 Таблиця 3.3 Програмні компоненти AI системи технічної підтримки користувача Компонент Основне № Вхідні дані Вихідні дані системи призначення Отримання текстового або Запит Структуроване Модуль службового користувача, повідомлення 1 приймання повідомлення від технічна подія, для подальшої запитів користувача чи код помилки обробки пристрою Очищення тексту, Модуль виділення Повідомлення Підготовлений 2 попередньої ключових слів, користувача текст запиту обробки нормалізація запиту Категорія Модуль Визначення Підготовлений проблеми, 3 класифікації категорії звернення текст, ключові рівень проблеми та рівня складності ознаки пріоритету Температура, Отримання й аналіз стан пам’яті, Модуль параметрів роботи живлення, Діагностичний 4 діагностики вбудованого мережа, висновок пристрою пристрою журнали помилок Пошук Категорія Запис бази Модуль бази релевантного проблеми, знань, 5 знань рішення або ключові слова, інструкція, інструкції код помилки рекомендація Запит, результат AI модуль Формування Готова діагностики, 6 формування зрозумілої відповіді відповідь запис бази відповіді природною мовою користувачеві знань Модуль Запит додаткової Нечіткий або Уточнювальні 7 уточнювальног інформації у разі неповний запит запитання о діалогу нестачі даних Запити, Збереження історії Журнал подій і Модуль відповіді, 8 звернень, помилок і результатів журналювання технічні результатів обробки тестування параметри Формування Дані діалогу, Модуль звернення для діагностика, Структурована 9 передавання оператора у невирішена заявка фахівцю складних випадках проблема 74 Для програмної реалізації було передбачено умовне розділення системи на три рівні: апаратний, локальний програмний і зовнішній інтелектуальний. Апаратний рівень охоплював вбудований пристрій, який збирав технічні параметри та передавав їх до системи підтримки. Локальний програмний рівень забезпечував первинну обробку звернень і роботу з базою знань. Зовнішній інтелектуальний рівень використовувався тоді, коли локальних правил і готових відповідей було недостатньо для формування якісної консультації. Така структура дає змогу уникнути надмірного навантаження на вбудований пристрій і водночас забезпечити користувача достатньо змістовною відповіддю. У практичній реалізації доцільним є використання вбудованого пристрою на базі ESP32-S3 або подібної платформи, оскільки такий пристрій має компактні розміри, низьке енергоспоживання, підтримує бездротові інтерфейси зв’язку та забезпечує достатні можливості для збирання службових параметрів, які можуть характеризувати стан системи, режим її роботи та особливості взаємодії з користувачем. Такий пристрій може передавати зібрані дані до локального програмного модуля, де здійснюється основна обробка інформації, аналіз користувацьких запитів, вибір релевантних відповідей і формування результату, що дозволяє розмежувати функції між апаратною частиною та програмним середовищем. Для складнішого прототипу може використовуватися Raspberry Pi або інший одноплатний комп’ютер, який має вищу обчислювальну потужність і здатний виконувати роль локального сервера, зберігати базу знань, вести журнал подій, опрацьовувати частину запитів безпосередньо на пристрої та забезпечувати взаємодію із зовнішнім AI сервісом у разі потреби. Такий підхід відповідає особливостям AI систем на базі вбудованих пристроїв, оскільки дає змогу не перевантажувати апаратну частину складними мовними обчисленнями та забезпечує швидку локальну обробку типових звернень (табл. 3.4.). 75 Таблиця 3.4 Орієнтовні програмно-апаратні засоби реалізації системи Рівень Засіб або Призначення в Обґрунтування реалізації технологія системі вибору Збирання параметрів Підтримка пристрою, мережевого обміну, Апаратний ESP32-S3 / передавання компактність, рівень Raspberry Pi службових даних, можливість роботи у взаємодія з вбудованих системах користувачем Передавання Забезпечує зв’язок запитів, кодів між вбудованим Wi-Fi / UART Канал обміну помилок і пристроєм і / USB діагностичних програмним параметрів модулем Python / Обробка запитів, Зручність реалізації Локальний локальний класифікація, алгоритмів обробки модуль сервер пошук у базі знань тексту й тестування Збереження Простота інтеграції, типових проблем, SQLite / JSON- можливість База знань інструкцій, кодів структура локального помилок, сценаріїв зберігання даних відповіді Формування API великої Дає змогу працювати розгорнутих мовної моделі з нечіткими AI модуль відповідей і або локальна запитами природною уточнювальних NLP-модель мовою запитань Збереження Потрібне для звернень, часу оцінювання CSV / SQLite / Журналювання відповіді, ефективності та текстовий лог результатів повторного аналізу тестування помилок Вебінтерфейс / Забезпечує Введення запитів і Інтерфейс консоль / практичну взаємодію відображення користувача екран користувача із відповідей пристрою системою Програмна логіка системи реалізується як послідовність взаємо- пов’язаних операцій. На першому етапі виконується ініціалізація 76 компонентів: встановлюється зв’язок із вбудованим пристроєм, завантажується база знань, перевіряється доступність AI модуля, створюється файл або таблиця журналу подій. Після цього система переходить у режим очікування звернення користувача або технічної події. Звернення може надходити у вигляді текстового повідомлення, коду помилки, службового сигналу або комбінації користувацького запиту й технічних параметрів. Наприклад, користувач може написати: «Пристрій не підключається до Wi-Fi», а система одночасно отримає від вбудованого пристрою дані про слабкий рівень сигналу або невдалу спробу автентифікації. Після отримання звернення запускається модуль попередньої обробки. Він видаляє зайві символи, приводить текст до єдиного формату, визначає ключові слова, технічні ознаки й можливі синонімічні формулювання. Це важливо, оскільки користувачі часто описують технічні проблеми неточно або побутовою мовою. Наприклад, повідомлення «не ловить інтернет», «не бачить Wi-Fi», «немає мережі» та «не підключається» можуть належати до однієї категорії проблем, пов’язаної з мережевим з’єднанням. Тому попередня обробка запиту дає змогу зменшити кількість помилкових класифікацій і підготувати звернення до подальшого аналізу. Наступним етапом є класифікація проблеми. У системі передбачено кілька основних категорій звернень: проблеми з мережею, живленням, перегрівом, пам’яттю, оновленням програмного забезпечення, роботою сенсорів, помилками інтерфейсу та загальними запитами щодо експлуатації пристрою. Класифікація може виконуватися за правилами, ключовими словами, кодами помилок або результатами пошуку в базі знань. Якщо система впевнено визначає категорію проблеми, вона переходить до діагностики. Якщо ж запит нечіткий або не містить достатньо інформації, активується уточнювальний діалог. Наприклад, 77 якщо користувач пише лише «пристрій не працює», система не повинна одразу формувати загальну відповідь, а має уточнити: «Пристрій не вмикається, не підключається до мережі чи не реагує на команди?» (табл. 3.5.). Таблиця 3.5 Категорії звернень користувача та ознаки їх визначення Додаткові Категорія Типові ключові Очікувана дія № параметри звернення слова або ознаки системи пристрою Рівень сигналу, Перевірити Wi-Fi, інтернет, Проблема з статус Wi-Fi, параметри мережі 1 підключення, мережею кількість спроб та надати сигнал, мережа підключення інструкцію не вмикається, Напруга, рівень Запропонувати Проблема з 2 живлення, заряду, стан перевірку джерела живленням батарея, заряд адаптера живлення Попередити про гарячий, перегрів, Температура Перегрів ризик і 3 температура, процесора або пристрою запропонувати вимикається корпусу охолодження пам’ять, зависає, Обсяг вільної Запропонувати Нестача 4 повільно, не пам’яті, журнал очищення пам’яті пам’яті запускається процесів або перезапуск Надати інструкцію оновлення, Помилка Версія ПЗ, статус повторного 5 прошивка, версія, оновлення оновлення оновлення або збій відновлення Запропонувати датчик, не реагує, Дані сенсорів, Помилка перевірку 6 неправильні статус сенсорів підключення або показники калібрування калібрування не працює, Поставити Нечіткий Недостатньо 7 помилка, уточнювальні запит даних проблема, збій запитання Комбінація повторювана Сформувати Складна кількох 8 помилка, звернення до несправність негативних критичний збій фахівця параметрів 78 Діагностичний модуль виконує перевірку технічних параметрів пристрою. Він аналізує службові дані, які надходять від вбудованого пристрою, і зіставляє їх із категорією звернення. Наприклад, якщо користувач повідомляє про проблему з мережею, система перевіряє статус Wi-Fi, рівень сигналу, результат останньої спроби підключення й наявність помилки автентифікації. Якщо користувач повідомляє про перегрів, система звертається до температурного параметра й визначає, чи перевищує він допустимий поріг. Такий підхід дає змогу не обмежуватися загальними порадами, а формувати відповідь із прив’язкою до фактичного стану пристрою. Для забезпечення технічної коректності відповідей використовується база знань. Вона містить структуровані записи про типові проблеми, можливі причини, перевірочні дії, покрокові інструкції, рівень небезпеки та умови передавання звернення фахівцю. База знань є важливим елементом системи, оскільки AI модуль не повинен формувати рекомендації довільно. Його відповідь має спиратися на заздалегідь підготовлені технічні інструкції, що відповідають характеристикам пристрою. Це особливо важливо для вбудованих систем, де некоректна порада може призвести до неправильної експлуатації, втрати налаштувань або погіршення технічного стану пристрою (табл. 3.6.). Таблиця 3.6 Приклад структури запису бази знань Поле запису Зміст поля Приклад значення ID проблеми Унікальний номер запису NET-001 Категорія Тип технічної проблеми Мережеве підключення Ключові слова Слова для пошуку Wi-Fi, мережа, інтернет, відповідного запису підключення 79 Продовження таблиці 3.6. Поле запису Зміст поля Приклад значення Умова Технічна або текстова Wi-Fi disconnected або спрацювання ознака проблеми RSSI < -75 dBm Можлива причина Ймовірне джерело проблеми Слабкий сигнал або неправильний пароль Рекомендована дія Основна інструкція для Перевірити пароль, користувача перезапустити модуль Wi- Fi Рівень небезпеки Ступінь критичності Низький / середній / ситуації високий Потреба у фахівці Умова передавання Якщо після 3 спроб оператору підключення проблема не зникає Текст відповіді Готове повідомлення Пристрій не може користувачеві підключитися до мережі. Перевірте параметри Wi- Fi... Після пошуку в базі знань система формує відповідь користувачеві. Якщо знайдено точний запис, відповідь створюється на основі готової інструкції та доповнюється фактичними параметрами пристрою. Наприклад, система може повідомити: «Пристрій не зміг підключитися до Wi-Fi. За даними діагностики рівень сигналу є низьким. Перемістіть пристрій ближче до маршрутизатора або перевірте налаштування мережі». Якщо знайдено кілька можливих варіантів, система обирає найбільш релевантний або ставить уточнювальне запитання. Якщо локальна база знань не містить достатньої інформації, запит передається до AI модуля, який формує розгорнуту відповідь на основі доступного контексту, але з обмеженням на безпечні технічні рекомендації. Окрему увагу в програмній реалізації приділено журналюванню. Кожне звернення користувача, категорія проблеми, діагностичні параметри, обрана рекомендація, час відповіді та результат обробки зберігаються в журналі. Це потрібно не лише для контролю працездатності 80 системи, а й для подальшого оцінювання ефективності. Журнал дає змогу визначити, які типи проблем виникають найчастіше, які звернення система розв’язує автоматично, у яких випадках потрібне втручання фахівця та які записи бази знань потребують уточнення. Таким чином, журналювання є не допоміжною, а важливою частиною практичної реалізації, оскільки забезпечує збирання даних для експериментального аналізу (табл. 3.7.). Таблиця 3.7 Приклад запису журналу роботи системи Час Час Запит Технічний Результат № звернен Категорія відпов користувача параметр обробки ня іді, с Надано Не RSSI = -82 рекомендац 1 10:05 підключається Мережа 1,4 dBm ію щодо до Wi-Fi сигналу Надано Пристрій Температур 2 10:17 Перегрів попереджен 1,2 гарячий а = 76 °C ня Поставлено Даних Нечіткий уточнюваль 3 10:31 Не працює недостатнь 0,9 запит не о запитання Надано Помилка після Оновлен- Версія ПЗ інструкцію 4 11:02 1,8 оновлення ня 1.2.4 відновленн я Сформова- Повторна Знову не 3 невдалі но 5 11:20 мережева 2,1 бачить мережу спроби звернення помилка фахівцю Тестування системи проводилося для перевірки правильності роботи окремих модулів і всієї системи загалом. Основною метою тестування було встановити, чи здатна система коректно приймати запити, визначати категорію проблеми, використовувати параметри вбудованого пристрою, знаходити відповідний запис у базі знань, формувати зрозумілу рекомендацію та передавати складні випадки фахівцю. Тестування охоплювало функціональні, діагностичні, інтеграційні та стабільнісні 81 перевірки. Функціональне тестування було спрямоване на перевірку основних можливостей системи. Діагностичне тестування перевіряло правильність використання технічних параметрів пристрою. Інтеграційне тестування оцінювало взаємодію між модулями. Стабільнісне тестування було потрібне для перевірки поведінки системи в умовах повторних звернень, нечітких запитів і нестабільного з’єднання (табл. 3.8.). Таблиця 3.8 План тестування AI системи технічної підтримки користувача Вид Мета Об’єкт Очікуваний № тестування перевірки перевірки результат Перевірити Приймання Система виконання запитів, коректно 1 Функціональне основних класифікація, обробляє типові функцій формування звернення системи відповіді Перевірити Відповідь Температура, використання враховує 2 Діагностичне пам’ять, мережа, параметрів фактичний стан живлення пристрою пристрою Дані Перевірити Пристрій, база передаються без 3 Інтеграційне взаємодію знань, AI модуль, втрати й модулів журнал дублювання Система Тестування Перевірити Запити без ставить 4 нечітких уточнювальний достатньої додаткові запитів діалог інформації запитання Тестування Перевірити Невирішені або Створюється 5 складних передавання критичні структуроване випадків фахівцю проблеми звернення Перевірити Система не Тестування роботу за Повторні запити, 6 втрачає дані та стабільності багаторазових журналювання не зависає звернень Перевірити Тестування Система не відсутність Відповіді 7 безпеки пропонує ризикованих користувачеві рекомендацій небезпечних дій порад 82 Для функціонального тестування було сформовано набір контрольних запитів, які імітують типові ситуації користувача під час експлуатації вбудованого пристрою. До таких ситуацій належать проблеми з Wi-Fi з’єднанням, перегрів, нестача пам’яті, збій оновлення, некоректна робота сенсорів і нечітко сформульовані повідомлення. Кожен тест містив вхідний запит, додатковий технічний параметр, очікувану реакцію системи та фактичний результат. Такий формат тестування дає змогу не лише описати роботу системи, а й показати її перевірку на конкретних прикладах (табл. 3.9.). Таблиця 3.9 Результати функціонального тестування системи Тестовий Додаткові Очікувана Фактичний № запит дані реакція Статус результат користувача пристрою системи Визначити Система проблему визначила Пристрій не RSSI = -82 мережі й мережеву 1 підключаєтьс dBm, Wi-Fi Виконано запропонувати проблему та я до Wi-Fi disconnected перевірити надала сигнал рекомендацію Система повідомила про Визначити перегрів і Пристрій Температура перегрів і 2 запропонувала Виконано дуже гарячий = 78 °C попередити вимкнути користувача пристрій для охолодження Система Визначити Все зависає і Вільна запропонувала можливу 3 працює пам’ять = 8 очистити кеш і Виконано нестачу повільно % перезапустити пам’яті пристрій Після Система надала Версія ПЗ = Визначити оновлення інструкцію 4 1.2.4, статус збій Виконано з’явилася повторного update_failed оновлення помилка оновлення 83 Продовження таблиці 3.9. Тестовий Додаткові Очікувана Фактичний № запит дані реакція Статус результат користувача пристрою системи Система Датчик Визначити запропонувала Sensor_status 5 показує проблему перевірити Виконано = unstable неправильні сенсора підключення та значення виконати калібрування Система Поставити Пристрій не Даних уточнила 6 уточнювальне Виконано працює недостатньо характер запитання проблеми Система Wi-Fi знову Передати 3 невдалі сформувала не працює складний 7 спроби заявку з Виконано після випадок підключення історією перезапуску фахівцю перевірок Система Який порядок Надати знайшла Помилок 8 налаштування інструкцію з відповідний Виконано немає пристрою? експлуатації запис у базі знань Окремо було перевірено, чи здатна система працювати з нечіткими формулюваннями. Це важливо, оскільки користувачі не завжди описують проблему технічно правильно. Наприклад, замість «помилка автентифікації Wi-Fi» користувач може написати «інтернет не ловить», а замість «нестача оперативної пам’яті» — «пристрій гальмує». У таких випадках система повинна не просто шукати точний збіг у базі знань, а визначати зміст звернення за ключовими ознаками та контекстом. Якщо впевненість класифікації недостатня, система має переходити до уточнювального діалогу. Це підвищує якість підтримки, оскільки користувач отримує не випадкову загальну пораду, а послідовну допомогу з уточненням ситуації (табл. 3.10.). 84 Таблиця 3.10 Перевірка обробки нечітких запитів користувача Нечіткий Ймовірна № Дія системи Приклад відповіді запит категорія Уточніть, будь ласка: пристрій не вмикається, не 1 Не працює Невизначена Уточнення підключається до мережі чи не реагує на команди? Схоже, проблема Класифікація пов’язана з Wi-Fi. Не ловить 2 Мережа та Перевіряю стан Інтернет діагностика підключення пристрою. Перевірено стан пам’яті. Рекомендовано Пам’ять / Перевірка 3 Він гальмує очистити тимчасові продуктивність пам’яті дані та перезапустити пристрій. Уточніть, яку саме Після Інтерфейс / кнопку було натиснуто 4 кнопки щось оновлення / Уточнення та яке повідомлення зламалося команда з’явилося після цього. Уточніть, неправильні Показує не Сенсор / значення відображає 5 Уточнення те дисплей датчик чи екран пристрою? Для оцінювання якості діагностики було проведено тестування ситуацій, у яких відповідь системи залежить не лише від тексту запиту, а й від технічних параметрів пристрою. Це дозволяє перевірити головну особливість запропонованої системи: вона не є звичайним чат-ботом, який відповідає лише за текстом, а використовує дані вбудованого пристрою. Наприклад, один і той самий запит «пристрій погано працює» може мати різні причини: перегрів, нестачу пам’яті, слабке живлення або збій програмного забезпечення. Тому система повинна зіставляти 85 користувацьке повідомлення з технічними параметрами й формувати відповідь відповідно до реального стану пристрою (табл. 3.11.). Таблиця 3.11 Перевірка діагностичних можливостей системи Діагностичний Параметри № Ситуація висновок Рекомендація пристрою системи Wi-Fi Слабкий сигнал Перемістити пристрій Немає disconnected, або ближче до 1 підключення RSSI = -82 недоступність маршрутизатора, до мережі dBm мережі перевірити пароль Вимкнути пристрій, перевірити Пристрій Температура = Можливий 2 вентиляцію, вимикається 82 °C перегрів повторити запуск після охолодження Очистити тимчасові Повільна Вільна пам’ять Нестача 3 файли, перезапустити робота = 6 % пам’яті систему Повторити оновлення Помилка Некоректне update_failed, або виконати 4 після завершення версія ПЗ 1.2.4 відновлення оновлення оновлення попередньої версії Перевірити Некоректні Sensor_status = Порушення підключення, 5 показники unstable роботи сенсора виконати датчика калібрування Повторна 3 невдалі Автоматичне Передати звернення 6 мережева спроби вирішення фахівцю помилка підключення неефективне Після функціонального й діагностичного тестування було проведено оцінювання ефективності системи. Для цього використано кілька критеріїв: правильність класифікації звернень, коректність діагностичного висновку, релевантність відповіді, час формування відповіді, частка автоматично розв’язаних звернень і кількість випадків, переданих фахівцю. Такий набір критеріїв дозволяє оцінити не лише технічну працездатність системи, а й практичну користь для користувача. Система 86 вважається ефективною тоді, коли вона швидко визначає тип проблеми, не формує небезпечних або випадкових порад, враховує параметри пристрою та передає складні випадки людині, якщо автоматичне вирішення є недоцільним (табл. 3.12.). Таблиця 3.12 Критерії оцінювання ефективності системи Очікуване Практичне № Критерій Спосіб оцінювання значення значення Показує здатність Точність Частка правильно Не менше системи 1 класифікації визначених категорій 85% правильно звернень розуміти запити Зіставлення висновку Показує здатність Коректність Не менше 2 з параметрами враховувати діагностики 80% пристрою технічний стан Експертна перевірка Релевантність Не менше Визначає якість 3 відповідності відповіді 85% рекомендацій відповіді проблемі До 3 с для Визначає Середній час Вимірювання часу від 4 типових швидкодію відповіді запиту до відповіді звернень системи Автоматичне Показує рівень розв’язання Частка звернень, Не менше 5 автоматизації типових вирішених без фахівця 70% підтримки проблем Коректне Забезпечує передавання Частка правильно Не менше безпеку та 6 складних сформованих заявок 90% контроль складних випадків ситуацій Відсутніст Показує Стабільність Кількість збоїв під час ь придатність до 7 роботи серії тестів критичних практичного збоїв використання Для кількісної перевірки було сформовано тестовий набір із 50 звернень, який охоплював типові й нетипові ситуації. До нього увійшли 10 звернень щодо мережевого підключення, 7 звернень щодо перегріву, 7 звернень щодо нестачі пам’яті, 6 звернень щодо оновлення, 5 звернень 87 щодо сенсорів, 10 нечітких запитів і 5 складних випадків, які потребували передавання фахівцю. Такий розподіл дозволив перевірити систему не лише на простих прикладах, а й на ситуаціях із недостатніми даними, повторними помилками та змішаними ознаками несправностей (табл. 3.13.). Таблиця 3.13 Результати кількісного тестування системи Правильно Передано Категорія Кількість Правильно сформовано фахівцю за звернень тестів класифіковано відповідь потреби Мережеві 10 9 9 1 проблеми Перегрів 7 7 7 0 Нестача пам’яті 7 6 6 0 Помилки 6 5 5 1 оновлення Помилки 5 4 4 1 сенсорів Нечіткі запити 10 8 8 0 Складні 5 5 4 5 випадки Усього 50 44 43 7 За результатами тестування система правильно класифікувала 44 із 50 звернень, що становить 88 %. Правильно сформовані відповіді було отримано у 43 випадках із 50, тобто показник релевантності відповідей становив 86 %. У 7 випадках система коректно визначила, що автоматичного вирішення недостатньо, і сформувала звернення до фахівця. Найкращі результати були отримані для категорій перегріву та мережевих проблем, оскільки ці ситуації мають чіткі технічні параметри, які легко зіставляються з текстом запиту. Найскладнішими для системи виявилися нечіткі звернення та помилки сенсорів, оскільки вони часто 88 потребують додаткових пояснень від користувача або глибшої перевірки апаратної частини. Для узагальнення результатів ефективності було розраховано основні показники роботи системи. Точність класифікації визначалася як відношення кількості правильно класифікованих звернень до загальної кількості тестових звернень. Релевантність відповіді визначалася як відношення кількості технічно правильних і зрозумілих рекомендацій до загальної кількості звернень. Частка автоматичного вирішення визначалася як відсоток звернень, які система змогла обробити без передавання фахівцю. Середній час відповіді визначався за журналом подій (табл. 3.14.). Таблиця 3.14 Узагальнені показники ефективності системи Формула або Отримане Показник спосіб Оцінка результату значення визначення Точність 44 / 50 × 100 % 88% Достатній рівень класифікації Релевантність 43 / 50 × 100 % 86% Достатній рівень відповідей Частка автоматично Високий рівень 43 / 50 × 100 % 86% оброблених звернень автоматизації Допустимий рівень Частка переданих 7 / 50 × 100 % 14% для складних фахівцю звернень випадків Середній час Відповідає вимозі відповіді для За журналом подій 1,6 с швидкої реакції типових запитів Середній час відповіді для За журналом подій 2,8 с Допустимий рівень складних запитів Критичні збої під час Система працювала За журналом подій 0 тестування стабільно 89 Отримані результати свідчать, що система здатна ефективно обробляти більшість типових звернень користувача. Високий показник автоматичної обробки пояснюється тим, що значна частина технічних проблем має повторюваний характер і може бути описана через базу знань. До таких проблем належать втрата мережевого підключення, перегрів, нестача пам’яті, помилки оновлення та типові збої сенсорів. Водночас наявність механізму передавання складних випадків фахівцю є важливою умовою безпечної роботи системи, оскільки AI модуль не повинен самостійно вирішувати ситуації, які можуть бути пов’язані з апаратною несправністю, критичним перегрівом або повторюваною помилкою після виконання стандартних рекомендацій. Під час тестування було також перевірено стабільність системи за умов повторних звернень. Для цього послідовно подавалися запити одного типу з різними формулюваннями. Наприклад, для мережевої проблеми використовувалися повідомлення: «немає інтернету», «не підключається Wi-Fi», «пристрій не бачить мережу», «з’єднання зникло». Система повинна була віднести ці запити до однієї категорії та запропонувати відповідні дії. Результати показали, що використання ключових ознак і бази знань дозволяє обробляти різні мовні формулювання без повної залежності від точного збігу слів. Однак для дуже коротких або неоднозначних повідомлень система потребує уточнювального діалогу, що є правильним з погляду безпеки технічної підтримки. Важливим результатом програмної реалізації є те, що система не лише відповідає користувачеві, а й пояснює причину рекомендації. Наприклад, у разі перегріву вона не просто пропонує вимкнути пристрій, а повідомляє, що температура перевищує допустимий рівень. У разі слабкого Wi-Fi сигналу система не обмежується фразою «перевірте інтернет», а пояснює, що зафіксовано низький рівень сигналу або невдалу спробу підключення. Такий спосіб формування відповіді підвищує довіру користувача до 90 системи, оскільки рекомендація виглядає обґрунтованою, а не випадковою (табл. 3.15.). Таблиця 3.15 Приклади сформованих відповідей системи Запит № Дані пристрою Відповідь системи користувача Не RSSI = -82 dBm Пристрій не зміг підключитися підключається до до мережі. Зафіксовано слабкий Wi-Fi рівень сигналу. Перемістіть 1 пристрій ближче до маршрутизатора та перевірте правильність пароля Wi-Fi. Пристрій Температура = Температура пристрою гарячий 78 °C перевищує рекомендований рівень. Вимкніть пристрій на 2 кілька хвилин, перевірте вентиляцію та не закривайте корпус під час роботи. Все дуже Вільна пам’ять = Ймовірною причиною повільної повільно працює 8% роботи є нестача вільної пам’яті. 3 Рекомендовано очистити тимчасові дані та перезапустити пристрій. Після оновлення update_failed Оновлення завершилося помилка некоректно. Повторіть оновлення 4 за стабільного живлення або скористайтеся функцією відновлення попередньої версії. Не працює Даних Уточніть, будь ласка, що саме не недостатньо працює: живлення, підключення 5 до мережі, екран, сенсор або виконання команд? Порівняно зі звичайною довідковою системою, запропонована AI система має кілька практичних переваг. По-перше, вона враховує не лише текст запиту, а й реальні параметри пристрою. По-друге, вона здатна працювати з нечіткими формулюваннями та ставити уточнювальні запитання. По-третє, вона використовує базу знань як контрольоване джерело інформації, що підвищує технічну достовірність відповідей. По- 91 четверте, система веде журнал звернень, який можна використовувати для аналізу повторюваних проблем і вдосконалення бази знань. По-п’яте, вона передає складні випадки фахівцю, що знижує ризик помилкових автоматичних рішень (табл. 3.16.). Таблиця 3.16 Порівняння звичайної довідкової системи та запропонованої AI системи Звичайна довідкова Запропонована AI система Критерій система технічної підтримки Пошук за точним Аналіз запиту, класифікація Спосіб пошуку запитом або проблеми, пошук у базі відповіді розділом інструкції знань Урахування стану Використовуються технічні Зазвичай відсутнє пристрою параметри пристрою Робота з нечіткими Передбачено Обмежена запитами уточнювальний діалог Готовий текст Адаптована відповідь із Формування відповіді інструкції поясненням причини Не завжди Автоматичне формування Передавання фахівцю передбачене заявки у складних випадках Зберігаються запити, Обмежене або Журналювання відповіді, параметри й відсутнє результати Може вдосконалюватися Потребує ручного Можливість розвитку через аналіз журналів і бази оновлення знань Під час оцінювання також було враховано обмеження реалізованої системи. Основним обмеженням є залежність якості відповіді від повноти бази знань. Якщо база знань не містить інформації про певну помилку або нестандартну ситуацію, система може поставити уточнювальне запитання або передати випадок фахівцю, але не завжди зможе надати повноцінне рішення автоматично. Другим обмеженням є складність обробки дуже 92 коротких або суперечливих повідомлень користувача. Третім обмеженням є необхідність стабільного зв’язку із зовнішнім AI сервісом у тих випадках, коли локальних алгоритмів недостатньо. Водночас ці обмеження не знижують практичної цінності системи. Для підвищення ефективності системи в подальшому доцільно розширити базу знань, додати більше прикладів реальних звернень користувачів, удосконалити механізм класифікації нечітких запитів і реалізувати автоматичне оновлення записів бази знань після аналізу журналу подій. Також перспективним є використання векторного пошуку для точнішого зіставлення запитів із технічними інструкціями, а також застосування компактних моделей машинного навчання для локальної класифікації звернень. Для апаратної частини доцільно передбачити додаткові засоби контролю стану пристрою, зокрема моніторинг живлення, температури, пам’яті, мережевого з’єднання та стану сенсорів. Отже, програмна реалізація AI системи технічної підтримки користувача охопила створення взаємопов’язаних модулів приймання запитів, попередньої обробки, класифікації, діагностики, роботи з базою знань, формування відповіді, уточнювального діалогу, журналювання та передавання складних випадків фахівцю. Проведене тестування підтвердило, що система здатна правильно визначати категорію більшості звернень, використовувати технічні параметри вбудованого пристрою, формувати зрозумілі й безпечні рекомендації та забезпечувати автоматизоване опрацювання типових проблем. За результатами тестування точність класифікації становила 88%, релевантність відповідей — 86%, а середній час відповіді для типових звернень — 1,6 с. Це свідчить про практичну придатність запропонованої системи для використання у вбудованих пристроях, де важливими є швидкість реагування, технічна обґрунтованість відповіді, стабільність роботи та можливість передавання складних випадків фахівцю. 93 Висновки до розділу 3 В результаті виконано розроблення алгоритму роботи AI системи технічної підтримки користувача, який забезпечує послідовне опрацювання звернення від моменту його надходження до формування відповіді або передавання складного випадку фахівцю. Запропонована логіка роботи системи поєднує приймання повідомлення, попередню обробку тексту, визначення категорії проблеми, аналіз технічного стану вбудованого пристрою, пошук інформації в базі знань і формування рекомендації. Важливо, що система враховує не лише зміст запиту користувача, а й фактичні параметри пристрою, зокрема стан мережевого підключення, температуру, рівень пам’яті, живлення, роботу сенсорів і записи журналу подій. Завдяки цьому підвищується точність діагностики, зменшується ймовірність надання випадкових або технічно некоректних порад, а користувач отримує більш обґрунтовану допомогу. Практична реалізація системи ґрунтується на модульному підході, за якого кожен компонент виконує окреме функціональне завдання. До основних модулів належать модуль приймання запитів, попередньої обробки, класифікації проблеми, діагностики пристрою, роботи з базою знань, AI формування відповіді, уточнювального діалогу, журналювання та передавання звернення фахівцю. Така структура дає змогу окремо перевіряти роботу кожного елемента, спрощує подальше вдосконалення системи та забезпечує гнучкість її використання у вбудованих пристроях. База знань у цій системі виконує роль контрольованого джерела технічної інформації, тому відповіді формуються не довільно, а на основі підготовлених інструкцій, описів типових помилок і сценаріїв їх усунення. Проведене тестування показало, що система здатна коректно працювати з типовими та нечіткими зверненнями користувачів. Під час перевірки було враховано проблеми з Wi-Fi з’єднанням, перегрівом, 94 нестачею пам’яті, помилками оновлення, некоректною роботою сенсорів, а також ситуації, коли користувач формулює проблему занадто коротко або неточно. У таких випадках система або визначає ймовірну категорію проблеми, або ставить уточнювальне запитання, що є важливим для безпечної технічної підтримки. Окремо підтверджено, що поєднання текстового аналізу із діагностичними параметрами пристрою дає змогу формувати відповіді з поясненням причини рекомендації, наприклад у випадку перегріву, слабкого Wi-Fi сигналу або нестачі пам’яті. Кількісні результати оцінювання підтвердили достатній рівень ефективності запропонованої системи. Із 50 тестових звернень система правильно класифікувала 44, що становить 88%, а релевантні відповіді було сформовано у 43 випадках, тобто 86%. Частка автоматично оброблених звернень також становила 86%, середній час відповіді для типових запитів дорівнював 1,6 с, а критичних збоїв під час тестування не зафіксовано. Отримані показники свідчать про практичну придатність системи для використання у вбудованих пристроях, де важливими є швидкість реагування, стабільність роботи, технічна обґрунтованість відповідей і можливість передавання складних випадків фахівцю. 95 ВИСНОВКИ В процесі виконання бакалаврської роботи було досліджено проблему створення AI системи технічної підтримки користувача на базі вбудованого пристрою, що є актуальним напрямом розвитку сучасних спеціалізованих комп’ютерних систем. Встановлено, що традиційні форми технічної підтримки не завжди забезпечують достатню швидкість реагування, постійну доступність і персоналізоване опрацювання звернень користувачів. Саме тому використання штучного інтелекту дає змогу автоматизувати приймання запитів, аналізувати зміст повідомлень, визначати характер проблеми та формувати зрозумілі рекомендації. Особливе значення має поєднання AI модуля з вбудованим пристроєм, оскільки така система може надавати допомогу безпосередньо в середовищі експлуатації технічного засобу. В результаті було обґрунтовано доцільність створення програмно-апаратного комплексу, здатного підвищити ефективність взаємодії користувача з комп’ютерною системою та зменшити навантаження на фахівців технічної підтримки. В роботі було проаналізовано поняття, функції, класифікацію та сучасний стан розвитку AI систем технічної підтримки користувачів. З’ясовано, що такі системи можуть виконувати функції приймання звернень, класифікації проблем, пошуку інформації в базі знань, діагностики типових несправностей, формування відповідей, супроводу користувача та передавання складних випадків фахівцю. Розглянуто сучасні рішення на основі чат-ботів, голосових асистентів і великих мовних моделей, які забезпечують більш природну, гнучку й доступну взаємодію з користувачем. Встановлено, що найефективнішими є комбіновані системи, у яких мовна обробка поєднується з перевіреною базою знань і механізмами контролю якості відповідей. Такий підхід дозволяє не лише швидко реагувати на звернення, а й зменшувати ризик неточних або небезпечних технічних рекомендацій. 96 Окрему увагу було приділено особливостям використання вбудованих пристроїв у системах технічної підтримки. Визначено, що такі пристрої мають специфічну архітектуру, яка включає мікроконтролер або мікропроцесор, оперативну та постійну пам’ять, засоби введення і виведення, інтерфейси зв’язку, систему живлення та периферійні компоненти. На відміну від універсальних комп’ютерів, вбудовані пристрої працюють в умовах обмежених ресурсів, тому під час створення AI системи необхідно враховувати продуктивність обчислювального ядра, обсяг пам’яті, енергоспоживання, стабільність роботи та доступність мережевого з’єднання. Було встановлено, що повномасштабне виконання складних мовних моделей безпосередньо на компактному пристрої не завжди є доцільним. У процесі дослідження було сформовано функціональні та нефункціональні вимоги до AI системи технічної підтримки користувача на базі вбудованого пристрою. До основних функціональних можливостей віднесено приймання запиту, попередню обробку повідомлення, визначення категорії проблеми, аналіз параметрів пристрою, пошук релевантної інформації в базі знань, формування відповіді, уточнювальний діалог і передавання складних випадків фахівцю. Нефункціональні вимоги охоплюють швидкодію, стабільність, енергоефективність, безпеку даних, зручність інтерфейсу, передбачуваність роботи та можливість подальшого масштабування. Встановлено, що система має бути не лише інтелектуальною, а й технічно узгодженою з можливостями апаратної платформи. Було обґрунтовано вибір методів обробки запитів користувача, формування відповідей і побудови моделі взаємодії основних компонентів системи. Доцільним визначено комбінований підхід, який поєднує попередню мовну обробку, класифікацію звернення, пошук у базі знань, діагностику стану пристрою та генерацію зрозумілої рекомендації. Така 97 структура дає змогу системі враховувати не лише текстовий зміст повідомлення, а й технічний контекст, параметри пристрою та доступні записи бази знань. Розроблена модель передбачає, що локальна частина системи виконує базові перевірки, приймає звернення й забезпечує первинну відповідь, а зовнішній AI компонент може залучатися для складніших запитів. Завдяки цьому система поєднує автономність, контрольованість, гнучкість і практичну придатність для використання у вбудованих пристроях. Практична частина роботи була спрямована на розроблення алгоритму функціонування AI системи технічної підтримки користувача, її програмну реалізацію, тестування та оцінювання ефективності. Запропонований алгоритм охоплює ініціалізацію компонентів, очікування звернення або технічної події, попередню обробку повідомлення, визначення категорії проблеми, діагностику стану пристрою, пошук відповідного запису в базі знань, формування відповіді, уточнення інформації та передавання складного випадку фахівцю. Реалізована система продемонструвала здатність автоматизовано опрацьовувати типові звернення, використовувати технічні параметри пристрою, формувати зрозумілі рекомендації та забезпечувати послідовну взаємодію з користувачем. Результати тестування засвідчили практичну придатність запропонованого рішення, зокрема точність класифікації звернень, релевантність відповідей і достатню швидкість реагування. Отже, мету бакалаврської роботи досягнуто, а розроблена AI система може бути використана як основа для подальшого вдосконалення автоматизованої технічної підтримки користувачів на базі вбудованих пристроїв. 98 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ: 1. Азарова А.О., Юрчук Н.П. Інформаційні системи і технології. Частина 1: навчальний посібник. Вінниця: ВНТУ, 2024. 152 с. 2. Азарова А.О., Юрчук Н.П. Інформаційні системи і технології. Частина 2: навчальний посібник. Вінниця: ВНТУ, 2024. 160 с. 3. Анісімов А.В., Дорошенко А.Ю., Погорілий С.Д., Дорогий Я.Ю. Програмування числових методів мовою Python: підручник. Київ: Видавничо-поліграфічний центр «Київський університет», 2014. 640 с. 4. Ачкасов І.А., Козир Б.Ю., Тімінський О.Г. Інтернет речей і смарт- технології: конспект лекцій. Київ: КНУБА, 2022. 64 с. 5. Бантюков С.Є., Бізюк І.Г., Казанко О.В. Серія «Комп’ютерні науки»: Мережеві інформаційні технології: навчальний посібник. Частина 1. Харків: УкрДУЗТ, 2024. 120 с. 6. Бантюкова С.О., Головко О.В., Пєнкіна О.Є. Серія «Комп’ютерні науки»: Мережеві інформаційні технології: навчальний посібник. Частина 2. Харків: УкрДУЗТ, 2023. 111 с. 7. Берко А. Ю., Верес О. М., Пасічник В. В. Системи баз даних та знань. Книга 1. Організація баз даних та знань: підручник. 2-ге вид. Львів: Магнолія 2006, 2015. 440 с. 8. Білощицький А. О. Інформаційна технологія управління проєктами на базі ERPP та APE систем. Управління розвитком складних систем. 2010. № 1. С. 16–20. 9. Болюбаш Н.М. Інтелектуальний аналіз даних: навчальний посібник. Миколаїв: Вид-во ЧНУ ім. Петра Могили, 2023. 320 с. 10. Вдовиченко І.Н., Хоцкіна В.Б. Інтелектуальні системи: навчальний посібник. Кривий Ріг: Державний університет економіки і технологій, 2023. 187 с. 99 11. Верлань А.А. Нечітка логіка: алгоритми прийняття рішень. Комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 33 с. 12. Вонсевич К.П., Безуглий М.О. Мікропроцесорна техніка: комп’ютер- ний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2021. 94 с. 13. Гороховатський В.О., Творошенко І.С. Методи інтелектуального аналізу та оброблення даних: навчальний посібник. Харків: ХНУРЕ, 2021. 92 с. 14. Гущин І.В., Киричок О.В., Куклін В.М. Вступ до методів організації та оптимізації нейромереж: навчальний посібник. Харків: ХНУ імені В.Н. Каразіна, 2021. 152 с. 15. Данілін О.В., Бойченко С.В., Босак А.В., Майданський І.Я. Інтелектуальні системи автоматичного керування. Реалізація систем fuzzy-керування з використанням програмних засобів інтегрованого середовища Matlab. Комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2024. 48 с. 16. Данілов О.В. Інтелектуалізовані методи захисту інформації: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 140 с. 17. Жалдак М. І., Лапінський В. В., Шут М. І. Комп’ютерно-орієнтовані засоби навчання математики, фізики, інформатики: посібник для вчителів. Київ: НПУ імені М. П. Драгоманова, 2004. 182 с. 18. Жураковський Б.Ю., Зенів І.О. Технології інтернету речей: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2021. 271 с. 19. Згуровський М.З. Вступ до штучного інтелекту: тенденції, виклики, перспективи: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2025. 107 с. 20. Клименко І.А., Каплунов А.В., Таранюк В.А., Ткаченко В.В. Архітектура комп’ютерів 3. Мікропроцесорні системи. Частина 2. 100 Програмування для мікроконтролерів STM32. Теорія та практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 21. Коцновський В.М. Теорія паралельних обчислень: навчальний посібник. Ужгород: ПП «АУТДОР-Шарк», 2021. 188 с. 22. Кулаков Ю.О. Комп’ютерні мережі: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 247 с. 23. Ліщук К.І. Бази даних. Рекомендації до виконання курсової роботи: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 37 с. 24. Мирончук О.Ю., Шпилька О.О. Проєктування мікроконтролерних пристроїв в радіотехнічних комп’ютеризованих системах: лаборатор- ний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 53 с. 25. Михайлова І.Ю. Постреляційні бази даних. Комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 26. Мірошник М.А., Клименко Л.А., Корольова Я.Ю. Технології та автоматизація проєктування цифрових пристроїв складних комп’ютерних систем на ПЛІС: навчальний посібник. Харків: УкрДУЗТ, 2021. 220 с. 27. Мірошник М.А., Курцев М.С. Автоматизація проєктування вбудова- них систем і програмних засобів на ПЛІС мовою опису апаратури: навчальний посібник. Харків: УкрДУЗТ, 2021. 331 с. 28. Могильний С.Б. Машинне навчання в радіотехнічних комп’ютери- зованих системах: лабораторний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 175 с. 29. Морзе Н.В. Основи інформаційно-комунікаційних технологій: навчальний посібник. Київ: Видавнича група BHV, 2020. 352 с. 30. Нікітчук А.В. Програмування вбудованих систем Інтернету речей: конспект лекцій: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2024. 120 с. 101 31. Олещенко Л.М. Машинне навчання. Комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 92 с. 32. Олещенко Л.М. Технології оброблення великих даних: комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2021. 85 с. 33. Оникієнко Ю.О., Рижова А.Р. Основи проєктування систем Інтернету речей. Периферія мікроконтролерів STM32: конспект лекцій: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 127 с. 34. Онищенко В.В. Штучний інтелект в задачах обробки зображень: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2025. 210 с. 35. Павловський О.М. Мікроконтролери та мікропроцесорна техніка: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2021. 104 с. 36. Пасічник В. В., Резніченко В. А. Організація баз даних та знань. Київ: Видавнича група BHV, 2022. 384 с. 37. Радченко К.О., Петрашенко А.В. Бази даних NoSQL: конспект лекцій: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2023. 270 с. 38. Риндюк Д.В., Пешко В.А. Інформаційні технології. Конспект лекцій: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 180 с. 39. Сагун А.В., Бобков В.Б. Операційні системи та комп’ютерні мережі: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 164 с. 40. Сергієнко І.В. Інформатика в Україні: становлення, розвиток, проблеми. Київ: Наукова думка, 1999. 354 с. 41. Сергієнко І. В. Інформатика та комп’ютерні технології. Київ: Наукова думка, 2018. 432 с. 42. Системи і методи підтримки прийняття рішень. Рекомендації до виконання курсової роботи: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2024. 63 с. 43. Сідєлєв М.І., Запальський В.М., Бєліков О.Є. Програмування спеціалізованих мікроконтролерних та вбудованих комп’ютерних 102 систем для засобів автоматизації: навчальний посібник. Миколаїв: Вид-во ЧНУ ім. Петра Могили, 2023. 96 с. 44. Сокол С.П., Койфман О.О., Ісаєв А.Б., Мірошниченко В.І. Електроніка та мікропроцесорна техніка: програмування мікроконтролерів AVR: навчальний посібник. Одеса: Олді+, 2025. 428 с. 45. Спірін О.М. Інформаційно-комунікаційні технології навчання: критерії внутрішнього оцінювання якості. Інформаційні технології і засоби навчання. 2020. № 5(19). С. 45-47. 46. Спірін О. М. Критерії зовнішнього оцінювання якості інформаційно- комунікаційних технологій навчання. Науковий часопис НПУ імені М. П. Драгоманова. 2010. № 9. С. 18-21. 47. Суліма С.В., Глоба Л.С., Скулиш М.А. Бази даних: методичні вказівки до виконання комп’ютерного практикуму. Київ: КПІ ім. Ігоря Сікорського, 2023. 54 с. 48. Хроленко В.М., Голенков В.Г. Хмарні та GRID-технології: навчальний посібник. Київ: КНУБА, 2025. 100 с. 49. Шаповал Н.В. Методи та системи штучного інтелекту: комп’ютерний практикум: навчальний посібник. Київ: КПІ ім. Ігоря Сікорського, 2022. 45 с. 50. Barr M. Programming Embedded Systems in C and C++. Sebastopol: O’Reilly & Associates, 1999. 191 p. 51. Lee E.A., Seshia S. A. Introduction to Embedded Systems: A Cyber- Physical Systems Approach. 2nd ed. Cambridge: MIT Press, 2017. 568 p. 52. McCarthy J. Programs with Common Sense. Proceedings of the Teddington Conference on the Mechanization of Thought Processes. London: Her Majesty’s Stationery Office, 1959. P. 75–77. 53. Minsky M. L. Semantic Information Processing. Cambridge: MIT Press, 1968. 438 p. 103 54. Newell A., Simon H. A. Human Problem Solving. Englewood Cliffs: Prentice-Hall, 1972. 920 p. 55. Russell S. J., Norvig P. Artificial Intelligence: A Modern Approach. 4th ed. Hoboken: Pearson, 2020. 1136 p. 56. Turing A. M. Computing Machinery and Intelligence. Mind. 1950. Vol. 59. № 236. P. 33–35. 57. Weizenbaum J. ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine. Communications of the ACM. 1966. Vol. 9. № 1. P. 36–45. 58. Wolf W. Computers as Components: Principles of Embedded Computing System Design. San Francisco: Morgan Kaufmann, 2001. 662 p. 104 ДОДАТКИ Додаток А Структура запису бази знань AI системи технічної підтримки Поле запису бази Приклад для AI системи Зміст поля Роль у формуванні відповіді знань технічної підтримки Категорія Визначає основний тип Дає змогу AI модулю швидко віднести Мережева проблема; проблеми або тематичний запит до відповідної групи та обрати проблема живлення; напрям звернення напрям пошуку інструкції в базі знань. помилка оновлення; користувача. Категорія використовується під час тепловий стан; проблема класифікації звернення, зіставлення його сенсора. з параметрами пристрою та вибору способу реагування. Ключові слова Містять основні ознаки, за Використовуються для пошуку Wi-Fi, підключення, якими система знаходить релевантної інформації, коли користувач мережа; батарея, заряд, потрібний запис у базі описує проблему різними словами або живлення; оновлення, знань. подає неповне повідомлення. Ключові запуск, збій. слова допомагають пов’язати побутове формулювання користувача з технічною категорією. Опис проблеми Подає коротке технічне Слугує основою для розуміння змісту Пристрій не встановлює пояснення несправності звернення та пояснення користувачеві мережеве з’єднання; після або ситуації, яку потрібно сутності проблеми. AI модуль оновлення система не опрацювати. використовує опис для формування запускається; пристрій зрозумілої відповіді без зайвого фіксує підвищену ускладнення технічними деталями. температуру. 105 Поле запису бази Приклад для AI системи Зміст поля Роль у формуванні відповіді знань технічної підтримки Діагностичні дії Містять перелік перевірок, Забезпечують зв’язок між запитом Перевірити стан модуля які система виконує або користувача і фактичним станом зв’язку, рівень сигналу, пропонує виконати для вбудованого пристрою. На цьому етапі параметри мережі; зчитати уточнення причини враховуються параметри живлення, доступний обсяг пам’яті; проблеми. пам’яті, температури, мережевого перевірити температуру підключення, сенсорів і журналу подій. пристрою. Рекомендація Містить основну відповідь Використовується AI модулем для Перевірити мережу та системи або послідовність підготовки технічно коректної та повторити підключення; дій для користувача. зрозумілої інструкції. Рекомендація перезапустити пристрій; може подаватися у вигляді короткого перевірити живлення, повідомлення, покрокової дії, пам’ять і мережеве попередження або уточнювального з’єднання після збою запитання. оновлення. Обмеження Визначає умови, за яких Допомагає запобігти некоректним діям Повторювана помилка автоматична відповідь є користувача та своєчасно передати після кількох спроб; недостатньою або складний випадок фахівцю. Обмеження підвищена температура; потребує обережного важливі для ситуацій із повторюваними відсутність запису в базі використання. помилками, критичним станом знань; потреба у втручанні пристрою або відсутністю потрібної фахівця. інструкції. Код помилки Містить службовий Дає змогу виконати точніше зіставлення Error Update; код помилки ідентифікатор запиту з відповідним записом бази мережевого підключення; несправності, якщо знань. Код помилки зменшує службове повідомлення пристрій або програмне неоднозначність і допомагає швидше про несправність сенсора. забезпечення його фіксує. знайти потрібну інструкцію. 106 Поле запису бази Приклад для AI системи Зміст поля Роль у формуванні відповіді знань технічної підтримки Технічний Описує параметри Дозволяє AI модулю формувати Стан живлення, контекст пристрою, які відповідь з урахуванням реального стану температура, доступна супроводжують звернення вбудованого пристрою, а не лише тексту пам’ять, стан Wi-Fi або користувача. запиту. Це підвищує точність Bluetooth, активність діагностики та зменшує ризик загальних сенсорів, останні записи рекомендацій. журналу подій. Тип відповіді Визначає форму реакції Допомагає обрати, що саме має Автоматична системи на звернення сформувати система: автоматичну рекомендація; користувача. рекомендацію, уточнювальне запитання, уточнювальне запитання; попередження, інформаційне пояснення попередження; або передавання випадку фахівцю. інформаційне пояснення; передавання фахівцю. 107 Додаток Б Модель взаємодії AI модуля, бази знань та вбудованого пристрою 108 Додаток В Послідовність етапів алгоритму роботи AI системи технічної підтримки Етап алгоритму Зміст операцій Результат виконання Ініціалізація Запуск системи та перевірка готовності основних Система переходить у стан компонентів: модуля введення запитів, локального готовності до приймання звернення сховища, мережевого підключення, журналу подій і користувача або технічної події. програмного компонента AI обробки. Приймання Отримання текстового повідомлення, голосової Створюється вхідний запис із запиту команди, вибору пункту меню, натискання кнопки початковими даними для допомоги або автоматично зафіксованої технічної події подальшого аналізу. пристрою. Попередня Очищення й нормалізація повідомлення, виділення Формується підготовлений запит, обробка технічних термінів, кодів помилок, назв компонентів, придатний для класифікації та ключових слів і ознак характеру проблеми. зіставлення з технічним контекстом. Класифікація Визначення типу звернення користувача: Встановлюється категорія проблеми інформаційний запит, повідомлення про несправність, та обирається подальший напрям запит на інструкцію, уточнення значення помилки або обробки звернення. складний випадок. Діагностика Зчитування параметрів вбудованого пристрою: стану Формується технічний контекст живлення, рівня заряду, температури, пам’яті, проблеми, який використовується мережевого підключення, сенсорів і записів журналу під час підготовки відповіді. подій. 109 Етап алгоритму Зміст операцій Результат виконання Пошук рішення Звернення до бази знань за категорією проблеми, кодом Обирається відповідна інструкція, помилки, ключовими словами, службовими сценарій діагностики або параметрами або змістовною близькістю запиту. визначається потреба в уточненні чи передаванні звернення фахівцю. Формування Підготовка рекомендації на основі результатів Користувач отримує зрозуміле відповіді класифікації, діагностики та знайденої інформації з бази повідомлення, покрокову знань; за потреби формується уточнювальне запитання рекомендацію, уточнення або або попередження. попередження про критичний стан. Завершення Фіксація результату взаємодії в журналі, збереження Випадок закривається після надання категорії проблеми, технічних параметрів, наданої відповіді або передається фахівцю відповіді та рішення щодо завершення або передавання технічної підтримки з необхідними складного випадку. даними. 110