Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/8031
Full metadata record
DC FieldValueLanguage
dc.contributor.advisorЗаспа, Григорій Олександрович-
dc.contributor.authorАрхіпов, Максим Олександрович-
dc.date.accessioned2026-03-12T12:41:00Z-
dc.date.available2026-03-12T12:41:00Z-
dc.date.issued2024-12-09-
dc.identifier.urihttps://er.chdtu.edu.ua/handle/ChSTU/8031-
dc.description.abstractАНОТАЦІЯ Архіпов Максим Олександрович Побудова інтелектуального програмного агента для пошуку інформації у чат-боті 121 – Інженерія програмного забезпечення Черкаський державний технологічний університет Черкаси, 2024 У магістерській роботі представлено розробку інтелектуального програмного агента для пошуку інформації у чат-боті з використанням методів пошуку, орієнтованих на сучасні технології. Основна увага приділена реалізації Retrieval-Augmented Generation системи, яка інтегрується з платформою Slack для забезпечення зручного інтерфейсу користувача. У роботі досліджено сучасні підходи до побудови систем інформаційного пошуку, обґрунтовано вибір технологій Python, ChromaDB та FastAPI, а також визначено переваги використання векторної бази даних для зберігання й обробки користувацьких документів. Було розроблено ефективну архітектуру програмної системи, яка включає підтримку адміністративних функцій для оновлення бази знань та інтеграцію з NLP-моделями для підвищення точності відповідей. Проведено серію експериментів, спрямованих на оцінку впливу метаданих на функціонування системи, зокрема, її швидкодію, точність відповідей, адаптивність до змін бази знань та зручність для кінцевих користувачів. Результати підтвердили ефективність впроваджених методів, що дозволило забезпечити високу якість роботи системи. Розроблена система має високу надійність, масштабованість та зручність у використанні. Вона може застосовуватись у різних доменах для інтеграції з корпоративними чи освітніми середовищами, забезпечуючи користувачів швидким та точним доступом до релевантної інформації.uk_UA
dc.description.abstractABSTRACT Arkhipov Maksym Oleksandrovich Building an intelligent software agent for searching information in a chatbot 121 – Software Engineering Cherkasy State Technological University Cherkasy, 2024 The master's thesis presents the development of an intelligent software agent for information retrieval in a chatbot using search methods oriented towards modern technologies. The primary focus is on the implementation of the Retrieval-Augmented Generation system, which integrates with the Slack platform to provide a convenient user interface. The work investigates contemporary approaches to building information retrieval systems, justifies the choice of technologies such as Python, ChromaDB, and FastAPI, and defines the advantages of using a vector database for storing and processing user documents. An efficient software architecture was developed, which includes support for administrative functions to update the knowledge base and integration with NLP models to improve the accuracy of responses. A series of experiments were conducted to evaluate the impact of metadata on the system's performance, particularly its speed, response accuracy, adaptability to changes in the knowledge base, and user-friendliness. The results confirmed the effectiveness of the implemented methods, ensuring high-quality system performance. The developed system demonstrates high reliability, scalability, and ease of use. It can be applied in various domains for integration with corporate or educational environments, providing users with fast and accurate access to relevant information.uk_UA
dc.language.isoukuk_UA
dc.subjectінженерія програмного забезпеченняuk_UA
dc.subjectінтелектуальний агентuk_UA
dc.subjectRAGuk_UA
dc.subjectчат-ботuk_UA
dc.subjectвекторна база данихuk_UA
dc.subjectметаданіuk_UA
dc.subjectNLPuk_UA
dc.subjectFastAPIuk_UA
dc.subjectChromaDBuk_UA
dc.subjectsoftware engineeringuk_UA
dc.subjectintelligent agentuk_UA
dc.subjectRAGuk_UA
dc.subjectchatbotuk_UA
dc.subjectvector databaseuk_UA
dc.subjectmetadatauk_UA
dc.subjectNLPuk_UA
dc.subjectFastAPIuk_UA
dc.subjectChromaDBuk_UA
dc.titleПобудова інтелектуального програмного агента для пошуку інформації у чат-ботіuk_UA
dc.typeMaster Thesisuk_UA
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)



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

Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
 
на тему:  «Побудова інтелектуального програмного агента для пошуку 
інформації у чат-боті»  
 
Виконав: магістрант 2 курсу, групи МПЗ-2304 
Спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Магістрант Архіпов М.О. 
 (прізвище та ініціали) 
Керівник Заспа Г.О. 
 (прізвище та ініціали) 
Рецензент Розпутній А.В. 
 (прізвище та ініціали) 
 
 
 
 
Черкаси 2024 
 
 
 
        Черкаський державний технологічний університет  
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем  
Кафедра  програмного забезпечення автоматизованих систем  
Освітній рівень магістр  
Спеціальність 121 «Інженерія програмного забезпечення»   
Освітня програма Інженерія програмного забезпечення  
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
Голуб С.В.    
«___» ___________ 2024 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ МАГІСТРАНТА 
             Архіпов Максим Олександрович  
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) Побудова інтелектуального програмного агента для пошуку 
інформації у чат-боті  
Керівник проекту (роботи) Заспа Григорій Олександрович, к.т.н., доцент  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 07 » жовтня 
2024 року №299/04 
2. Строк подання магістрантом проекту (роботи)    09 грудня 2024  
3. Вхідні дані до проєкту (роботи) стандарти програмного забезпечення; процеси управління; 
вимоги до проєкту; календарне планування проєкту; управління ресурсами  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Вступ; Існуючі методи та засоби розв’язання поставлених завдань; Теоретичні та 
експериментальні дослідження; Впровадження результатів досліджень у практику 
проектування програмного забезпечення інформаційних систем; Конструювання та тестування 
програмного забезпечення; Висновки; Список використаних джерел; Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту)  
Титульний слайд; Слайд «Вступ»; Слайд «Вступ (продовження)»; Слайд «Існуючі засоби 
інформаційно-пошукових систем серед  заданої бази знань»; Слайд «Існуючі засоби 
інформаційно-пошукових систем серед  заданої бази знань (продовження)»; Слайд «Теоретичні 
дослідження»; Слайд «Гіпотеза»; Слайд «Дослідження»; Слайд «Результати дослідження»; 
Слайд «Первинні та детальні вимоги»; Слайд «Діаграма прецедентів»; Слайд «Діаграма 
прецедентів (продовження)»; Слайд «Проектування логічної структури»; Слайд «Проектування 
логічної структури (продовження)»; Слайд «Архітектурне проектування»; Слайд «Архітектурне 
проектування (продовження)»;  Слайд «Моделювання поведінки системи»; Слайд 
«Моделювання поведінки системи (продовження)»; Слайд «Структурна та функціональна 
 
 
схеми»; Слайд «Структурна та функціональна схеми (продовження)»; Слайд «База знань»; 
Слайд «Інтерфейс користувача»; Слайд «Тестування»; Фінальний слайд.  
6. Консультанти розділів проекту (роботи) 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02.09.2024  
 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів випускної Примітки 
п/п роботи 
1 Постановка задачі 05.09.2024 виконано 
2 Підготовка завдання 13.09.2024 виконано 
3 Погодження завдання 16.09.2024 виконано 
4 Затвердження завдання 14.10.2024 виконано 
 Основна стадія   
1 Підбір матеріалів 31.10.2024 виконано 
2 Аналіз шляхів вирішення поставленої задачі 01.11.2024 виконано 
3 Розрахунок основних параметрів роботи 08.11.2024 виконано 
4 Вибір кінцевого варіанту проектного рішення 18.11.2024 виконано 
5 Оформлення первісної редакції роботи 25.11.2024 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з керівником 29.11.2024 виконано 
2 Оформлення пояснювальної записки роботи в кінцевій 09.12.2024 виконано 
редакції 
3 Попередній захист роботи 09.12.2024 виконано 
4 Затвердження роботи 09.12.2024 виконано 
5 Рецензування роботи 10.12.2024 виконано 
6 Захист роботи 12.12.2024  
 
Магістрант _____________________            Архіпов М.О.  
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________             Заспа Г.О.  
  (підпис)   (прізвище та ініціали) 
  
 
 
АНОТАЦІЯ 
Архіпов Максим Олександрович 
Побудова інтелектуального програмного агента для пошуку інформації у 
чат-боті 
121 – Інженерія програмного забезпечення 
Черкаський державний технологічний університет 
Черкаси, 2024 
У магістерській роботі представлено розробку інтелектуального 
програмного агента для пошуку інформації у чат-боті з використанням методів 
пошуку, орієнтованих на сучасні технології. Основна увага приділена реалізації 
Retrieval-Augmented Generation системи, яка інтегрується з платформою Slack для 
забезпечення зручного інтерфейсу користувача. 
У роботі досліджено сучасні підходи до побудови систем інформаційного 
пошуку, обґрунтовано вибір технологій Python, ChromaDB та FastAPI, а також 
визначено переваги використання векторної бази даних для зберігання й обробки 
користувацьких документів. Було розроблено ефективну архітектуру програмної 
системи, яка включає підтримку адміністративних функцій для оновлення бази 
знань та інтеграцію з NLP-моделями для підвищення точності відповідей. 
Проведено серію експериментів, спрямованих на оцінку впливу метаданих 
на функціонування системи, зокрема, її швидкодію, точність відповідей, 
адаптивність до змін бази знань та зручність для кінцевих користувачів. 
Результати підтвердили ефективність впроваджених методів, що дозволило 
забезпечити високу якість роботи системи. 
Розроблена система має високу надійність, масштабованість та зручність у 
використанні. Вона може застосовуватись у різних доменах для інтеграції з 
корпоративними чи освітніми середовищами, забезпечуючи користувачів 
швидким та точним доступом до релевантної інформації.  
Ключові слова: інженерія програмного забезпечення, інтелектуальний агент, 
RAG, чат-бот, векторна база даних, метадані, NLP, FastAPI, ChromaDB. 
  
 
 
ABSTRACT 
Arkhipov Maksym Oleksandrovich 
Building an intelligent software agent for searching information in a chatbot 
121 – Software Engineering 
Cherkasy State Technological University 
Cherkasy, 2024 
The master's thesis presents the development of an intelligent software agent for 
information retrieval in a chatbot using search methods oriented towards modern 
technologies. The primary focus is on the implementation of the Retrieval-Augmented 
Generation system, which integrates with the Slack platform to provide a convenient 
user interface. 
The work investigates contemporary approaches to building information retrieval 
systems, justifies the choice of technologies such as Python, ChromaDB, and FastAPI, 
and defines the advantages of using a vector database for storing and processing user 
documents. An efficient software architecture was developed, which includes support 
for administrative functions to update the knowledge base and integration with NLP 
models to improve the accuracy of responses. 
A series of experiments were conducted to evaluate the impact of metadata on the 
system's performance, particularly its speed, response accuracy, adaptability to changes 
in the knowledge base, and user-friendliness. The results confirmed the effectiveness of 
the implemented methods, ensuring high-quality system performance. 
The developed system demonstrates high reliability, scalability, and ease of use. It 
can be applied in various domains for integration with corporate or educational 
environments, providing users with fast and accurate access to relevant information.  
Keywords: software engineering, intelligent agent, RAG, chatbot, vector 
database, metadata, NLP, FastAPI, ChromaDB. 
 
 
 
 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОСИЛАНЬ ............................................................................... 5 
ВСТУП ................................................................................................................................... 6 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ .............................................................................................................................. 9 
1.1 АНАЛІЗ ІСНУЮЧИХ МЕТОДІВ ТА ЗАСОБІВ ІНФОРМАЦІЙНОГО ПОШУКУ СЕРЕД НАДАНИХ 
ДАНИХ .................................................................................................................................. 9 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ...................................................................................... 18 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ............ 20 
2.1 ТЕОРЕТИЧНІ ДОСЛІДЖЕННЯ ......................................................................................... 20 
2.1.1 Аналіз сфери пошукових систем ...................................................................... 20 
2.1.2 Формулювання теорії та гіпотези дослідження .............................................. 24 
2.1.3 Побудова моделі дослідження ........................................................................... 24 
2.1.4 Проведення математичного дослідження ........................................................ 28 
2.1.5 Аналіз теоретичних рішень ............................................................................... 30 
2.1.6 Формулювання висновків .................................................................................. 32 
2.2 ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ. ........................................................................... 33 
2.2.1 Перший експеримент: оцінка точності відповідей із використанням 
метаданих ..................................................................................................................... 34 
2.2.2 Другий експеримент: аналіз швидкодії системи із додаванням метаданих . 37 
2.2.3 Третій експеримент: перевірка адаптивності системи при оновленні бази 
знань з використанням метаданих ............................................................................. 39 
2.2.4 Четвертий експеримент: перевірка зручності надання джерел інформації у 
відповідях ..................................................................................................................... 41 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ....................................................................................... 43 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ............................................................................................................................. 44 
3.1 МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ ........................................................................ 44 
3.1.1 Предметна область моделювання. Модель предметної області. Словник  
   
ЧДТУ 242313.001 ПЗ 
Зм. Лист № документа№ Підпис Дата
РЗомз.р обЛ.и ст Адрохкіпуомве Мнт.аО . Дата  Літ. Лист Листів 
Керівник Заспа Г.О. Побудова інтелектуального Д  
. Н
 програмного агента для пошуку Д ФІТІС, 
Н.контр.       Півень О.Б. 
інформації у чат-боті 
Затв. Голуб С.В.  кафедра ПЗАС, МПЗ-2304 
 
 
предметної області ...................................................................................................... 44 
3.1.2 Елементи моделювання предметної області .................................................... 47 
3.1.3 Робоча область моделювання ............................................................................ 50 
3.2 ФОРМУВАННЯ ТА АНАЛІЗ ВИМОГ ................................................................................. 51 
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги ........................................................................................................................... 51 
3.2.2 Формування вимог за допомогою діаграми прецедентів ............................... 54 
3.3 ПРОЕКТУВАННЯ ЛОГІЧНОЇ СТРУКТУРИ ПРОГРАМНОГО КОМПЛЕКСУ ............................ 57 
3.3.1 Діаграма класів ................................................................................................... 57 
3.3.2 Діаграма пакетів ................................................................................................. 59 
3.3.3 Діаграма компонентів ........................................................................................ 60 
3.3.4 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання .................................................................................................................. 62 
3.4 МОДЕЛЮВАННЯ ПОВЕДІНКИ СИСТЕМИ ........................................................................ 63 
3.4.1 Діаграма діяльності ............................................................................................ 63 
3.4.2 Діаграма послідовності ...................................................................................... 65 
3.4.3 Діаграма комунікації .......................................................................................... 67 
3.4.4 Діаграма скінченного автомату ......................................................................... 69 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ...................................................................................... 72 
РОЗДІЛ 4 КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ .............................................................................................................. 73 
4.1 РОЗРОБКА ПРОГРАМНОГО КОМПЛЕКСУ ........................................................................ 73 
4.1.1 Обґрунтування вибору засобів реалізації ........................................................ 73 
4.1.2 Опис структурної та функціональної схем ...................................................... 77 
4.1.3 Опис логічної схеми системи ............................................................................ 80 
4.1.4 Розробка бази даних ........................................................................................... 81 
4.1.5 Розробка інтерфейсу користувача ..................................................................... 82 
4.1.6 Опис розробки програмних компонентів ........................................................ 84 
4.2 ТЕСТУВАННЯ СИСТЕМИ ................................................................................................ 86 
4.2.1 Модульне тестування ......................................................................................... 86 
4.2.2 Інтеграційне тестування .................................................................................... 88 
4.2.3 Системне тестування ......................................................................................... 89 
4.2.4 Приймальне тестування ..................................................................................... 90 
  
 
 
4.3 ПРИКЛАДИ ВПРОВАДЖЕНОГО ПРОГРАМНОГО КОМПЛЕКСУ .......................................... 90 
ВИСНОВОК ДО ЧЕТВЕРТОГО РОЗДІЛУ ................................................................................. 94 
ЗАГАЛЬНІ ВИСНОВКИ .................................................................................................. 95 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................................... 97 
ДОДАТОК А ...................................................................................................................... 101 
ДОДАТОК Б ...................................................................................................................... 103 
ДОДАТОК В ....................................................................................................................... 117 
ДОДАТОК Г ....................................................................................................................... 119 
 
 
 
  
 
ЧДТУ 242313.001 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОСИЛАНЬ  
Абревіатура Пояснення 
HTTP/HTTPS Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure  
REST Representational State Transfer  
API Application Programming Interface 
UML Unified Modeling Language 
ПЗ Програмне Забезпечення 
JSON JavaScript Object Notation 
UI User Interface 
WEB From WWW (World Wide Web) 
SSPL Server Side Public License 
NLP Natural Language Processing 
LLM Large Language Model 
GPT Generative Pre-trained Transformer 
RAG Retrieval-Augmented Generation 
TF-IDF Term Frequency–Inverse Document Frequency 
BM25 Best Matching 25 
KNN K-Nearest Neighbors 
BERT Bidirectional Encoder Representations From Transformers 
PaLM Pathways Language Model 
 
  
 5 
ЧДТУ 242313.001 ПЗ 
ВСТУП 
Актуальність теми. Інженерія програмного забезпечення в цілому та 
сучасні інформаційні системи стикаються з викликами швидкого та релевантного 
пошуку даних серед великих обсягів інформації. Створення інтелектуальних 
агентів, здатних інтегрувати методи обробки природньої мови з алгоритмами 
пошуку, стає ключовим завданням у галузі штучного інтелекту. Retrieval-
Augmented Generation (RAG) забезпечує ефективний пошук і формування 
відповідей і подальше вдосконалення, зокрема шляхом використання метаданих, 
відкриває нові горизонти у підвищенні точності і контекстуальності відповідей. 
Зв’язок роботи з науковими програмами, планами, темами. Дослідження 
виконано у межах наукового напрямку, в рамках якого працює кафедра 
програмного забезпечення автоматизованих систем. Воно спрямоване на 
вдосконалення процесу розробки інтелектуальних інформаційних систем. 
Результати роботи відповідають державним пріоритетам у галузі цифровізації та 
розвитку штучного інтелекту в Україні. 
Мета і завдання дослідження. Метою роботи є удосконалення методу 
розробки програмного забезпечення пошукових систем шляхом побудови 
інтелектуального програмного агента для пошуку інформації через чат-бота з 
використанням архітектури Retrieval-Augmented Generation, що підвищує 
релевантність та точність відповідей завдяки застосуванню метаданих. 
Для досягнення цієї мети необхідно виконати такі завдання: 
– проаналізувати існуючі методи та засоби розв’язання задач пошуку 
інформації в пошукових системах; 
– дослідити зміни в якості та релевантності отриманої інформації при 
використанні методу Retrieval-Augmented Generation з додаванням 
метаданих до контексту інформації бази знань; 
– розробити API для обробки Slack запитів через HTTP-протокол; 
– реалізувати RAG-систему з використанням метаданих; 
– створити Slack-Bot та інтегрувати API для забезпечення зручної 
взаємодії користувачів з пошуковою системою; 
 6 
ЧДТУ 242313.001 ПЗ 
– створити частину адміністративного API для оновлення бази знань; 
– підключити векторну базу даних для збереження інформації у вигляді 
чанків перетворених у вектора; 
– протестувати систему та оцінити її ефективність. 
Об’єкт дослідження. Процеси розробки інтелектуальних програмних 
агентів для пошуку інформації. 
Предмет дослідження. Архітектурний підхід Retrieval-Augmented 
Generation до побудови інтелектуальних агентів для пошуку і подання у зручному 
для людини вигляді інформації по конкретно заданій базі знань із використанням 
метаданих. 
Методи дослідження. У роботі застосовано методи порівняння і 
спостереження для аналізу сучасних рішень; моделювання та абстрагування для 
побудови RAG-системи; системний підхід для інтеграції компонентів; 
експериментальний метод для оцінки ефективності впровадженого рішення. 
Наукова новизна отриманих результатів. Удосконалено метод Retrieval-
Augmented Generation шляхом додавання метаданих до контексту інформації бази 
знань, що дозволило зробити результати інформаційного пошуку більш точними 
та підвищити релевантності відповідей, а також надають користувачам 
можливість отримувати додаткову інформацію щодо джерел знайденого контексту.  
Практичне значення отриманих результатів. Використання 
удосконаленого методу Retrieval-Augmented Generation дозволило створити 
інформаційну систему, яка формує відповіді з покращеним контекстом, 
забезпечуючи вищу якість взаємодії з користувачем. Розроблена система 
забезпечує ефективний пошук інформації у чат-ботах завдяки інтеграції RAG з 
метаданими. Вона може бути використана в бізнесі для автоматизації 
консультаційних послуг, у сфері освіти для створення інтелектуальних помічників 
студентів, а також у державному управлінні для надання оперативних довідкових 
послуг громадянам. Інтеграція API зі Slack-Bot забезпечує легку адаптацію до 
існуючих робочих платформ, розширюючи можливості комунікації в організаціях 
та підвищуючи їх продуктивність. Також є варіант використання системи 
 7 
ЧДТУ 242313.001 ПЗ 
індивідуальними особами чи групами осіб, що займаються розробкою 
програмного забезпечення, з метою поліпшення роботи з даними, що 
накопичуються в процесі розробки програмного забезпечення. 
Особистий внесок автора. Всі дослідження, експерименти, проєктування 
та розробка програмного забезпечення в рамках даної роботи виконано автором 
особисто. 
Публікації. В ході досліджень було опубліковано тези на тему 
«Інтелектуальна генерація тексту на основі архітектурного підходу Retrieval-
Augmented Generation з використанням метаданих» у збірнику матеріалів одеської 
ІХ міжнародної науково-практичної конференції.  
 8 
ЧДТУ 242313.001 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Аналіз існуючих методів та засобів інформаційного пошуку серед 
наданих даних 
Інженерія програмного забезпечення вимагає роботу з великою кількістю 
документів та інформації. Пошукові системи є ключовими інструментами для 
знаходження цієї інформації в Інтернеті, і вони можуть бути класифіковані на 
кілька типів, залежно від їхнього функціонування та методів збору даних. Одна з 
новітніх технологій у цій сфері – це генерація тексту на основі знайденої 
інформації, яка інтегрує механізми пошуку з великими мовними моделями. 
Було проведено детальний аналіз існуючих систем, які реалізують різні 
підходи до розв'язання завдань аналізу, пошуку та генерації тексту на основі 
знайдених даних. До уваги бралися сучасні технології, що базуються на 
машинному навчанні, повнотекстовому пошуку, семантичному аналізі та обробці 
природної мови. Системи, такі як Elasticsearch, OpenSearch, Solr, а також 
платформи на основі GPT і трансформерів, демонструють високий рівень 
ефективності в задачах обробки великих обсягів інформації. Проведений аналіз 
дозволив виявити сильні сторони цих систем, їх обмеження, а також визначити 
перспективи для інтеграції та вдосконалення подібних рішень у різних галузях 
[1][2][3][4][5]. 
Elasticsearch - це розподілена система пошуку та аналітики на основі Lucene. 
Вона створена для ефективного індексування великих обсягів даних і швидкого 
пошуку за ними. Elasticsearch є чудовим інструментом, проте починаючи з версії 
7.10 компанія, що розробляє продукт, змінила ліцензію з Apache 2.0 на SSPL. І у 
2021 році компанія Amazon створює свій власний форк системи під назвою 
OpenSearch [1]. 
OpenSearch багато у чому є нащадком Elasticsearch, адже був розроблений на 
його базі (до версії 7.10). OpenSearch – це відкрита платформа для пошуку та 
 9 
ЧДТУ 242313.001 ПЗ 
аналітики, яка з'явилася у 2021 році як форк Elasticsearch і Kibana. Вона створена 
для роботи з великими обсягами даних, надаючи користувачам потужний 
інструмент для пошуку, візуалізації та аналітики [2].  
Сфери використання Elasticksearch та OpenSearch: 
– аналітика журналів: відстеження подій і аналіз логів системи в 
реальному часі; 
– моніторинг продуктивності: збір метрик і даних про роботу системи; 
– пошук у додатках: розробка потужних пошукових систем для сайтів чи 
мобільних додатків; 
– корпоративний пошук: впровадження інструментів для внутрішнього 
пошуку в документах, базах знань тощо. 
OpenSearch поділено на компоненти.  
Core: розподілена пошукова і аналітична система. Підтримує 
повнотекстовий пошук, фільтрування та агрегацію даних. Використовує 
зворотний індекс для швидкого пошуку [6]. 
Dashboards (рис. 1.1) - це візуалізація даних у реальному часі. Альтернатива 
Kibana. Містить інтерактивні графіки, таблиці, карти та інформаційні панелі [7]. 
 
Рис. 1.1 – Приклад сторінки OpenSearch Dashboard 
 10 
ЧДТУ 242313.001 ПЗ 
Система плагінів. OpenSearch підтримує плагіни, що додають функціонал 
машинного навчання (наприклад, для аномалій), аудиту і безпеки (керування 
ролями, шифрування, тощо) та моніторингу (дані про стан системи) [8]. 
Екосистема. Підтримує широкий набір API, що робить її сумісною з 
існуючими додатками, які використовували Elasticsearch (приклад на рис. 1.2), що 
полегшує перехід Elasticsearch до OpenSearch. 
 
Рис. 1.2 – Приклад модального вікна пошуку Elasticsearch  
 
До мінусів OpenSearch та Elasticsearch можна віднести високу 
ресурсозатратність, складність у налаштуванні й оптимізації. А також наступні:  
– відсутність інтеграції з нейромережами та генеративними моделями, 
адже використовується класичний підхід до пошуку (TF-IDF [9], BM25 
[10]) та аналізу даних, орієнтуючись на статичні індекси. OpenSearch 
знаходить документи, але не може синтезувати нову інформацію; 
– менш гнучка робота з неструктурованими даними. Розглянуті 
інструменти оптимізовані для роботи з текстовими даними, що добре 
 11 
ЧДТУ 242313.001 ПЗ 
структуровані (наприклад, JSON, документи). Для роботи з 
мультимодальними даними  
(текст, зображення, аудіо) потрібно значно більше кастомізації; 
– обмежена контекстуальність у запитах. OpenSearch та Elasticsearch 
оперують точними текстовими збігами або ключовими словами. Для 
отримання відповіді користувачеві потрібно формулювати чіткі запити. 
Вони не використовують семантичний пошук через векторизацію запитів 
і документів, забезпечуючи кращу обробку розмовної мови та нечітко 
сформульованих запитів; 
– відсутність динамічного навчання. Так як жоден з розглянутих 
інструментів не використовує генеративні моделі, які можуть динамічно 
навчатися, адаптуючи свої результати до контексту запитів або нових 
даних, вони не можуть адаптувати свої алгоритми на основі нових даних 
або фідбеку від користувачів без повторної індексації; 
– високі вимоги до ручного налаштування. OpenSearch та Elasticsearch 
потребують налаштування і підтримки, щоб забезпечити якісний пошук 
(вибір правильних токенізаторів, фільтрів, аналітики); 
– обмеження у відповіді на складні запити. Розглянуті програмні продукти 
не можуть забезпечити об’єднання інформації з кількох релевантних 
джерел і генерувати єдину відповідь. При роботі зі складними запитами 
від користувачів, «пошуковики» видають нечіткі відповіді або не 
надають корисної інформації взагалі; 
– відсутність векторного пошуку «з коробки». Через те, що вони 
традиційно працюють зі строковими індексами (TF-IDF, BM25) то для 
використання векторного пошуку потрібна інтеграція з додатковими 
плагінами, такими як, наприклад, OpenSearch KNN [11], але це обмежена 
функціональність у порівнянні з сучасними підходами; 
– відсутність генерації відповідей. Перелічені інструменти можуть лише 
повертати документи або їхні фрагменти, залишаючи інтерпретацію 
інформації на користувача. 
 12 
ЧДТУ 242313.001 ПЗ 
Elasticsearch та OpenSearch є чудовими рішеннями для традиційних задач 
пошуку та аналітики завдяки масштабованості та відкритій екосистемі. Проте 
сучасні 
вимоги користувачів значно більші. Зручність використання систем штучної 
генерації тексту та менші вимоги до оформлення запитів до пошукових систем 
зменшують кількість помилок при пошуку та збільшують точність відповідей та 
швидкість взаємодії з подібними системами.  
Для ширшого охоплення області дослідження, розглядаються корпоративні 
системи знань і їх найвідоміші представники SharePoint, Confluence та Notion 
(рис. 1.3).  
 
Рис. 1.3 – Логотипи найвідоміших корпоративних систем знань  
 
SharePoint, Confluence і Notion – це три популярні платформи для 
управління інформацією, співпраці команд і організації роботи. Хоча вони мають 
схожі функції, кожна платформа орієнтована на різні сценарії використання і має 
свої сильні та слабкі сторони. 
Microsoft SharePoint – це корпоративна платформа для управління контентом 
та документами. Вона інтегрується з іншими продуктами Microsoft (наприклад, 
Office 365) і використовується для створення корпоративних сайтів, бібліотек 
документів і систем обміну інформацією. SharePoint є потужним інструментом для 
 13 
ЧДТУ 242313.001 ПЗ 
великих організацій, що потребують централізованого управління документами та 
створення внутрішніх корпоративних порталів. Ця платформа дозволяє 
створювати бібліотеки документів із функцією версійності, автоматизувати бізнес-
процеси. Однак для новачків SharePoint може бути складним у налаштуванні, і 
його вартість часто вища, ніж у інших рішень [12]. 
Confluence – це продукт Atlassian для управління знаннями, створення 
документації та спільної роботи в команді. Він підходить для технічних команд і 
IT-спеціалістів. Ця платформа організовує інформацію у вигляді сторінок і 
просторів, які зручно використовувати для створення документації, протоколів 
зустрічей або технічних довідників. Її головною перевагою є інтеграція з іншими 
продуктами Atlassian, зокрема Jira, що дозволяє ефективно вести проєкти. 
Водночас Confluence краще підходить для текстового контенту і менш зручний 
для нефахівців або команд, які працюють над креативними проєктами [13]. 
Notion – це сучасна, гнучка платформа для організації завдань, управління 
проєктами та зберігання інформації. Вона популярна серед креативних команд, 
малого бізнесу та окремих користувачів. Серед інших Notion виділяється своєю 
гнучкістю та простотою у використанні, завдяки чому він ідеально підходить для 
невеликих команд, фрілансерів чи творчих професій. Ця платформа дозволяє 
структурувати інформацію у вигляді блоків, які можуть містити текст, таблиці, 
списки, бази даних чи календарі. Вона забезпечує зручну організацію даних, а 
також можливість співпраці в реальному часі. Однак Notion менш ефективний при 
роботі з великими обсягами даних або інтеграцією зі складними системами, як це 
пропонують SharePoint чи Confluence [14][15]. 
Проте вони мають певні недоліки, які можуть впливати на продуктивність та 
зручність роботи. Основною проблемою таких систем є необхідність ручного 
пошуку й обробки даних. Користувачеві часто потрібно знати, де саме 
знаходиться інформація, як правильно сформулювати запит або яким чином 
організовані дані в системі. Це може призводити до затримок, особливо якщо 
обсяги збереженої інформації значні або структура її зберігання є складною. 
Ще однією проблемою є обмежена здатність цих платформ до інтеграції 
 14 
ЧДТУ 242313.001 ПЗ 
даних із різних джерел в одному запиті. Наприклад, у SharePoint чи Confluence 
доведеться самостійно переглядати кілька документів, щоб зібрати повну картину 
чи знайти зв'язки між різними шматками інформації. Також ці платформи 
вимагають від користувача навичок організації даних і постійної підтримки 
актуальності контенту. Якщо структура даних стає надто складною або недбало 
підтримується, ефективність роботи суттєво знижується. Це створює додаткове 
навантаження, оскільки користувачі не завжди можуть швидко адаптуватися до 
змін або швидко знайти потрібне. 
Також недоліком є їхня нездатність надавати розгорнуті, контекстуальні 
відповіді на запитання користувача. Ці системи зберігають дані у вигляді 
документів, сторінок або баз даних, але отримання потрібної інформації вимагає 
від користувача самостійного пошуку, аналізу й синтезу. Наприклад, навіть якщо у 
системі є вся необхідна інформація, вона часто розпорошена між кількома 
файлами чи записами, і користувач повинен вручну витратити час на збирання цієї 
інформації в єдину відповідь.  
До обмежень також можна віднести відсутність можливості інтерактивної 
взаємодії з даними. Користувачі не можуть "поспілкуватися" зі своїми даними у 
формі діалогу, ставлячи уточнюючі запитання чи отримуючи пояснення в 
контексті початкового запиту. Інформація в таких системах статична, і робота з 
нею більше схожа на традиційний пошук у бібліотеці, ніж на інтерактивний 
досвід. Це ускладнює використання платформ для вирішення складних чи 
багатокрокових завдань, де важливим є не лише доступ до інформації, але й її 
глибоке розуміння та швидка адаптація до запитів користувача. 
Генеративні чат-боти на прикладах ChatGPT та Claude. Були розглянуті 
рішення з застосуванням чат-ботів з системою генерації тексту. Розгляд цих 
систем є логічним та важливим аспектом даного дослідження, адже це системи, на 
базі яких будуються RAG системи та завдяки яким взагалі зʼявилася ідея побудови 
аналогічних систем. 
ChatGPT і Claude – це дві сучасні системи штучного інтелекту, орієнтовані 
на розуміння та генерацію тексту (рис. 1.4). Вони належать до категорії LLM і 
 15 
ЧДТУ 242313.001 ПЗ 
використовуються для автоматизації завдань, що потребують обробки природної 
мови, спілкування з користувачами та створення контенту. Обидві системи 
розроблені провідними компаніями у сфері штучного інтелекту та мають свої 
особливості в реалізації [16]. 
 
Рис. 1.4 – Логотипи ChatGPT та Claude 
 
ChatGPT розроблений компанією OpenAI. Це одна з найпопулярніших 
мовних моделей, яка базується на GPT, зокрема на її останніх версіях, таких як 
GPT-4. ChatGPT створений для роботи з текстовими запитами користувачів, 
генеруючи відповіді, що є максимально релевантними, креативними та 
контекстуальними. OpenAI використовує величезні обсяги текстових даних для 
навчання моделі, що дозволяє їй бути багатофункціональною. Вона підходить для 
написання текстів, перекладів, генерації ідей, пояснення складних понять та 
багато іншого. ChatGPT інтегрується в різні продукти, наприклад, Microsoft 
використовує його в своїх рішеннях, таких як Copilot у Word і Excel [17]. 
Claude, розроблений компанією Anthropic, є конкурентом ChatGPT і 
базується на подібних технологіях трансформерів. Ідеологія Anthropic спрямована 
на створення "безпечного й гуманного штучного інтелекту", тому Claude особливо 
наголошує на етиці у взаємодії з користувачами. Як і ChatGPT, Claude створений 
для роботи з текстом: написанням, аналізом, поясненням та творчими завданнями. 
 16 
ЧДТУ 242313.001 ПЗ 
Anthropic прагне зробити свою модель більш чуйною, орієнтованою на потреби 
користувача, одночасно мінімізуючи ризики неправильного використання 
технології [18]. 
Основні відмінності між цими системами залежать від їх підходів до 
безпеки, навчання та специфічної оптимізації для завдань користувачів. ChatGPT 
часто вважається потужнішою моделлю для складних завдань завдяки своїй 
масштабності, тоді як Claude наголошує на доступності, етичності та чуйності у 
відповіді. Обидві системи є прикладами новітніх досягнень у сфері штучного 
інтелекту, які активно використовуються у бізнесі, освіті та повсякденному житті. 
Обмеження та недоліки ChatGPT Claude. Однією з ключових проблем є те, 
що ці системи можуть вигадувати інформацію. Через особливості генеративних 
моделей, вони іноді формулюють відповіді, що виглядають переконливо, але не 
мають фактичної основи. Це створює ризики для завдань, де важливі точність і 
надійність, особливо якщо користувач не може перевірити достовірність відповіді. 
Ще одним важливим аспектом є актуальність інформації. Оскільки ці моделі 
навчаються на статичних наборах даних, їхні знання обмежуються часом 
останнього оновлення. Вони не здатні самостійно отримувати нову інформацію чи 
оновлювати свою базу знань, що робить їх менш корисними для вирішення 
завдань, пов'язаних із динамічними або сучасними подіями. У порівнянні з 
системами, які можуть інтегруватися з актуальними джерелами, ці моделі 
обмежені в забезпеченні релевантних даних. 
Також варто зазначити, що використання таких моделей вимагає значних 
обчислювальних ресурсів. Високі потреби у пам'яті й обчисленнях можуть 
зробити їх менш оптимальними для роботи в середовищах з обмеженими 
ресурсами. Вони не завжди ефективно використовують обсяг пам'яті для 
зберігання контексту або обробки великих запитів, що може призводити до 
обмеження їх функціональності у складних або довготривалих взаємодіях. 
Окрім цього, у таких систем спостерігається низький рівень персоналізації. 
Вони забезпечують загальні відповіді, але не можуть ефективно адаптуватися до 
індивідуальних потреб або особливостей кожного користувача. Це робить 
 17 
ЧДТУ 242313.001 ПЗ 
взаємодію менш гнучкою й може створювати бар'єри в завданнях, де важлива 
деталізована й персоналізована підтримка. Відсутність можливості розширювати 
базу знань і глибше налаштовувати відповіді на основі унікальних запитів також 
обмежує їхнє застосування у спеціалізованих сферах. 
Усі розглянуті системи мають суттєві обмеження, які впливають на їхню 
ефективність у вирішенні складних або спеціалізованих завдань. Основні 
проблеми включають неточність інформації через можливість вигадування фактів, 
обмеження у забезпеченні актуальності й релевантності даних, а також залежність 
від статичних баз знань, які неможливо легко оновлювати чи розширювати. Окрім 
цього, високі вимоги до обчислювальних ресурсів і слабка персоналізація 
відповідей знижують їхню придатність до використання в індивідуальних або 
динамічних сценаріях. Ці недоліки свідчать про необхідність пошуку підходів, які 
могли б забезпечити точнішу, більш актуальну й адаптивну взаємодію з даними. 
Висновок до першого розділу 
У розділі було проведено аналіз сучасних систем пошуку інформації, таких 
як Elasticsearch, OpenSearch, SharePoint, Confluence, Notion, ChatGPT, Claude та 
інших. Попри їхню популярність і широкий функціонал, ці рішення мають певні 
обмеження, які відкривають можливості для подальшого вдосконалення. 
Однією з головних проблем є обмеження в адаптації до нових даних, 
оскільки процес оновлення бази знань часто є складним і вимагає значних 
ресурсів, що ускладнює підтримку актуальності інформації. Також було виявлено, 
що більшість систем орієнтовані на точний збіг ключових слів, що обмежує їхню 
здатність надавати релевантні відповіді на запити, сформульовані природною 
мовою. Інтеграція таких систем із зовнішніми додатками та їх масштабованість 
також можуть бути ускладнені, особливо якщо це потребує значних фінансових чи 
технічних витрат. 
Ще одним важливим недоліком є те, що системи мають високі вимоги до 
навчання користувачів або адміністраторів, що уповільнює їх впровадження у 
робочі процеси. Нарешті, певні системи, особливо орієнтовані на англомовних 
 18 
ЧДТУ 242313.001 ПЗ 
користувачів, стикаються з труднощами в локалізації та підтримці специфічних 
мовних особливостей, таких як українська мова, що обмежує їхню доступність і 
ефективність. 
Таким чином, виявлені недоліки цих систем вказують на потребу 
вдосконалення методів інформаційного пошуку, що відповідає викликам 
сучасності та потребам галузі програмної інженерії.  
 19 
ЧДТУ 242313.001 ПЗ 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1 Теоретичні дослідження 
У цьому розділі здійснюється аналіз теоретичних основ дослідження, 
формалізовано задачі, пов’язані із застосуванням метаданих у системах RAG. 
Особливу увагу приділено можливостям інтеграції метаданих у пошукову систему 
для покращення якості результатів, підвищення релевантності відповідей та 
адаптації під специфічні потреби користувачів. 
Розглядається використання семантичного пошуку, який дозволяє визначати 
зв’язки між концепціями, навіть якщо вони не явно виражені, а також векторних 
баз даних, що забезпечують ефективне зберігання та швидкий пошук інформації 
на основі семантичної близькості. 
Теоретична частина охоплює аналіз методів побудови RAG-систем, зокрема 
процесів поділу даних на чанки, створення та збереження векторних 
представлень, а також застосування метаданих для уточнення контексту 
пошукових запитів. Це створює основу для розробки ефективної інформаційно-
пошукової системи, здатної надавати високоякісні відповіді в складних 
інформаційних середовищах. 
2.1.1 Аналіз сфери пошукових систем 
Аналіз сфери пошукових систем охоплює оцінку сучасних технологій, 
ринкових гравців, тенденцій і викликів у цій галузі. Сфера пошуку є ключовою 
для організації інформації та забезпечення доступу до знань, і постійно 
еволюціонує завдяки технологічному прогресу та змінюваним потребам 
користувачів. 
Існуючі пошукові системи можна поділити на дві групи. Традиційні та нові 
пошукові системи. 
Традиційні пошукові системи залишаються основою сучасного інтернету. 
Найбільшим гравцем у цій галузі є Google, що володіє часткою ринку понад 90% у 
багатьох країнах. Його успіх пояснюється використанням передових алгоритмів 
ранжування, таких як RankBrain і BERT, які дозволяють краще розуміти запити 
 20 
ЧДТУ 242313.001 ПЗ 
користувачів і надавати релевантні результати. Завдяки таким технологіям Google 
став синонімом пошуку в Інтернеті [19][20]. 
На другому місці знаходиться Bing, розроблений компанією Microsoft. Bing 
відрізняється тісною інтеграцією з продуктами Microsoft, такими як веб-браузер 
Edge і операційна система Windows. Хоча його частка ринку значно менша, ніж у 
Google, Bing активно розвивається, додаючи нові функції, включаючи штучний 
інтелект для покращення пошуку [21]. 
Ще одним учасником традиційного ринку є Yahoo, який свого часу був 
одним із піонерів пошукових систем. Наразі Yahoo має меншу популярність, однак 
продовжує утримувати свою нішу серед користувачів, які звикли до його 
інтерфейсу та специфічних функцій [22]. 
На азіатських ринках провідну позицію займає Baidu, який є лідером у 
Китаї. Завдяки адаптації до локального контексту, включаючи підтримку 
китайської мови та інтеграцію з місцевими сервісами, Baidu забезпечує 
ефективний пошук для мільярдів користувачів [23]. 
Нові пошукові системи. Останні роки ознаменувалися появою 
альтернативних пошукових платформ, які намагаються змінити традиційний 
підхід до пошуку. Однією з найвідоміших серед них є DuckDuckGo. Ця система 
орієнтована на конфіденційність користувачів, не зберігає історію пошуку та не 
відстежує активність в Інтернеті. DuckDuckGo привертає увагу людей, які цінують 
приватність, і стає популярним вибором для тих, хто хоче уникнути націленої 
реклами. 
Ще одним новатором є Neeva, який пропонує підпискову модель без 
реклами. Замість монетизації через рекламодавців Neeva фокусується на 
персоналізації та високій якості пошуку, забезпечуючи користувачів досвідом, що 
не залежить від комерційних інтересів. Цей підхід дозволяє створювати 
платформу, де користувач знаходиться в центрі уваги [24]. 
Серед нових гравців також виділяється You.com, який інтегрує нейронні 
мережі та генеративні моделі для покращення якості результатів. Ця система 
дозволяє користувачам налаштовувати свій пошук відповідно до власних 
 21 
ЧДТУ 242313.001 ПЗ 
вподобань і надає інтерактивний інтерфейс для взаємодії з результатами. 
Інтеграція технологій штучного інтелекту робить You.com цікавим вибором для 
тих, хто шукає новий 
досвід [25]. 
Далі розглядаються основні технологічні тренди, які визначають розвиток 
пошуку в останні роки. 
Технології штучного інтелекту стали ключовим елементом пошукових 
систем, дозволяючи їм розуміти складні запити та надавати точні відповіді. 
Одним із важливих напрямків є використання генеративних моделей 
великих мовних моделей, таких як GPT, PaLM, Claude тощо. Ці моделі 
інтегруються в пошукові системи, як-от Google Bard чи Bing AI, щоб створювати 
відповіді, що враховують контекст запиту. Замість простого списку посилань вони 
надають структуровані та змістовні пояснення, які значно полегшують пошук 
інформації [26] [27]. 
Також активно розвивається семантичний пошук, що замінює точне 
співпадіння слів на аналіз значення запиту. Наприклад, система може зрозуміти, 
що «найкращі місця для подорожей у листопаді» означає рекомендації 
туристичних напрямків, які мають комфортний клімат у цей період. 
Ще одним важливим аспектом є персоналізація. Пошукові системи 
враховують історію запитів, географічне положення, уподобання користувачів, 
щоб адаптувати результати. Це дозволяє забезпечити більш релевантний досвід, 
однак викликає занепокоєння щодо конфіденційності даних. 
Сучасні технологічні тренди демонструють, що пошукові системи стають 
дедалі складнішими та розумнішими. Інтеграція штучного інтелекту дозволяє 
вирішувати багато задач, які раніше здавалися неможливими. Однак разом із цим 
виникають виклики, такі як забезпечення конфіденційності та доступності для 
різноманітних груп користувачів. Майбутнє пошуку лежить у балансі між 
інноваціями та етичними принципами, що ставлять користувача в центр уваги. 
Серед технологій та технік, які використовуються при пошуку інформації 
хочеться виокремити метод retrieval-augmented generation [28][29][30]. Це метод,  
 22 
ЧДТУ 242313.001 ПЗ 
який комбінує: 
– пошукові механізми (retrieval): знаходження релевантних даних або 
документів із великої бази знань; 
– генеративний ШІ (generation): формування осмисленої відповіді на 
основі знайдених даних за допомогою великих мовних моделей. 
Замість того, щоб покладатися виключно на внутрішні знання моделі (що 
можуть бути застарілими або неповними), RAG дозволяє системам знаходити 
актуальні дані у зовнішніх джерелах і використовувати їх для генерації точних 
відповідей. 
Алгоритм RAG працює у кілька етапів: 
– обробка запиту: користувач вводить запит, наприклад, "Які нові 
дослідження у галузі штучного інтелекту?"; 
– пошук: система знаходить релевантну інформацію з баз даних, 
документації чи веб-ресурсів; 
– генерація відповіді: генеративна модель (наприклад, GPT або PaLM) 
інтегрує знайдені дані в зв'язну відповідь, пояснюючи або узагальнюючи 
інформацію. 
Переваги RAG можна вивести з його принципу роботи: 
– актуальність інформації. Генеративні моделі часто обмежені знаннями, 
що були актуальними на момент їхнього тренування. RAG долає цю 
проблему, використовуючи актуальні дані із зовнішніх джерел; 
– контекстуальність відповідей. Метод дозволяє надавати відповіді, які 
базуються на найсвіжішій і конкретній інформації, враховуючи контекст 
запиту; 
– ефективне використання великих баз даних. RAG може інтегруватися з 
великими сховищами знань, такими як наукові бібліотеки, корпоративні 
бази даних чи веб-ресурси; 
– зменшення ризику галюцинацій. Одна з проблем генеративних моделей - 
створення вигаданих фактів. Завдяки використанню перевірених джерел 
RAG мінімізує цей ризик. 
 23 
ЧДТУ 242313.001 ПЗ 
Технологія RAG має величезний потенціал для трансформації пошуку та 
обробки інформації. У майбутньому вона може стати стандартом у створенні 
адаптивних систем, що надають користувачам більш інформативні відповіді, 
інтегруючи актуальні знання із зовнішніх джерел. 
Зі зростанням обсягів даних і популярністю генеративного штучного 
інтелекту RAG буде відігравати ключову роль у розвитку не лише пошукових 
платформ, але й багатьох інших галузей. Технологія вже сьогодні демонструє, як 
поєднання штучного інтелекту та пошукових підходів може вивести роботу з 
даними на новий рівень. 
2.1.2 Формулювання теорії та гіпотези дослідження 
Теорія: RAG як оптимальна система для чат-ботів, які працюють із 
власними документами. 
RAG поєднує інновації в пошуку та генерації тексту, забезпечуючи точність, 
адаптивність і прозорість. Інтеграція семантичного пошуку підвищує 
ефективність роботи з власними документами, що робить RAG найкращим 
рішенням для сучасних чат-ботів, які потребують роботи з великими динамічними 
базами знань. 
Гіпотеза. Використання метаданих для кожного чанка інформації в системі 
RAG значно покращить релевантність та точність відповідей, що генерує 
інтелектуальний програмний агент для пошуку інформації у чат-боті, 
забезпечуючи кращу ідентифікацію контексту та джерела інформації, а також 
дозволить покращити адаптацію системи до змін у базі знань. 
Така гіпотеза передбачає, що додавання метаданих (наприклад, часу 
додавання даних, автора, джерела інформації, тощо) до чанків даних може 
сприяти поліпшенню якості інформаційного пошуку, дозволяючи системі точніше 
визначати актуальність та контекст запитів користувачів. Додатково, метадані 
можуть слугувати додатковим механізмом на основі якого можна досліджувати та 
розширювати пошукову систему з застосуванням RAG методу. 
2.1.3 Побудова моделі дослідження 
 24 
ЧДТУ 242313.001 ПЗ 
Обʼєктом дослідження є технології розробки інтелектуальних програмних 
агентів для пошуку інформації. 
Предметом дослідження є архітектурний підхід Retrieval-Augmented 
Generation для побудови інтелектуальних агентів для пошуку і подання у зручному 
для людини вигляді інформації по конкретно заданій базі знань із використанням 
метаданих. 
Опис проблеми. Однією з основних проблем, яку ставить перед собою 
розробка інтелектуального програмного агента для пошуку інформації в чат-
ботах, є покращення точності та релевантності відповідей, які він надає 
користувачам. Враховуючи, що чат-боти все частіше використовуються в різних 
сферах (від підтримки клієнтів до наукових досліджень), їх здатність швидко і 
точно знаходити необхідну інформацію стає критично важливою для ефективності 
роботи користувачів. 
У традиційних системах пошуку інформації для чат-ботів, питання точності 
та релевантності часто не вирішуються на високому рівні, оскільки система не 
враховує контекстуальні нюанси або викидає стандартні відповіді, які можуть 
бути малоінформативними або неточними. Відповіді на запити можуть бути 
занадто загальними або не відображати саме ту інформацію, яку користувач 
шукає. 
Інтеграція системи RAG дозволяє вирішити це питання, додаючи етап 
пошуку в базі знань перед генерацією відповіді. Проте навіть при використанні 
такої системи є проблема контекстуальності та інформативності відповідей. 
Наприклад, якщо користувач отримує інформацію з різних джерел або документів, 
важливо не тільки надати саму відповідь, але й показати, звідки ця інформація 
була отримана. Це дозволить користувачам перевірити достовірність інформації, а 
також зрозуміти, з яких джерел була сформована відповідь. 
У цьому дослідженні планується розв’язати проблему точності відповідей, 
додавши до кожного чанку інформації метадані, які будуть містити важливу 
інформацію про джерело даних, час додавання в базу, автора тощо. Це дозволить 
користувачу не лише отримати відповідь на запит, але й побачити, з якого 
 25 
ЧДТУ 242313.001 ПЗ 
документа або джерела була витягнута ця інформація, що збільшить довіру до 
результатів пошуку і допоможе більш точно інтерпретувати надану відповідь. 
Таким чином, головною проблемою є покращення точності відповідей та 
підвищення їх прозорості, шляхом інтеграції метаданих, що дозволяє користувачу 
бачити джерела інформації, з яких була зібрана відповідь, та забезпечує більш 
глибоке розуміння контексту кожного чанку даних. 
Мета моделі. Метою удосконаленого методу Retrieval-Augmented Generation 
та системи, що розроблюється на основі нього, є підвищення точності відповідей, 
що надаються чат-ботом, шляхом інтеграції системи, а також покращення процесу 
пошуку та контекстуалізації результатів через додавання метаданих до кожного 
чанка інформації. Це дозволить не лише забезпечити більш точні та релевантні 
відповіді на запити користувачів, але й надати додаткову інформацію про джерела 
та контекст кожного знайденого фрагмента, що значно підвищить прозорість та 
достовірність наданих результатів. 
Для опису моделі розроблюваної системи було обрано концептуальний тип 
моделей. Вона зможе якісно надати загальну картину того, як система може 
функціонувати на високому рівні. 
Компоненти моделі та їх опис. 
– чат-бот - це основний інтерфейс, з яким користувач взаємодіє. Його мета 
– надання зрозумілого інтерфейсу для взаємодії з пошуковим агентом; 
– система RAG: поєднує два етапи – пошуку та генерації відповіді. На меті 
має покращити точність та релевантність відповідей, використовуючи як 
традиційний пошук, так і генерацію тексту; 
– база знань. Зберігає всю інформацію, з якої система отримує дані для 
відповідей. Мета цього компоненту - зберігання структурованих даних, 
серед яких ведеться пошук релевантної інформації; 
– чанк – частина інформації, з якої складається база знань. При пошуку 
відповідей може містити релевантну інформацію для відповіді. Мета 
чанків – забезпечити розбиття даних на стандартизовані за розміром 
частини,  які  можливо  легко   обробляти   та  з   якими  можна   зручно 
 26 
ЧДТУ 242313.001 ПЗ 
працювати пошуковим системам; 
– метадані: кожен чанк інформації в базі знань супроводжується 
метаданими, які можуть включати будь-яку доступну на етапі підготовки 
бази знань інформацію. Мета: покращити контекстуалізацію пошуку та 
підвищити точність результатів шляхом надання додаткової інформації 
про джерело та релевантність знайденого контенту; 
– система пошуку. Використовує векторні представлення (векторизацію) 
даних для пошуку найбільш релевантних документів або чанків 
інформації. Мета: підвищити точність пошуку шляхом семантичного 
розуміння запитів та відповідних чанків. 
Визначимо взаємозвʼязок між вище описаними компонентами (рис. 2.1).  
1 Користувач задає запит чат-боту. 
2 Чат-бот передає запит до системи RAG. 
3 Система RAG шукає відповідну релевантну інформацію у базі знань, 
використовуючи метадані для контекстуалізації пошуку та покращення 
точності результатів та застосовуючи семантичний пошук для вибору 
найбільш релевантних даних. 
4 Відповідь генерується на основі знайденої інформації. 
5 Чат-бот надає користувачеві відповідь разом із метаданими (джерело, 
автор, час тощо). 
Рис. 2.1 – Схема взаємодії компонентів в RAG  
 27 
ЧДТУ 242313.001 ПЗ 
На етапі формування моделі було визначено основні компоненти системи, їх 
функціональність та взаємозв’язки, що дозволяє забезпечити системний підхід до 
побудови інтелектуального програмного агента. Концептуальна модель надає 
високорівневу структуру, яка включає чат-бот як інтерфейс, систему RAG для 
пошуку та генерації відповідей, базу знань, структуровану на основі чанків з 
метаданими, та семантичний пошук для підвищення точності результатів. Модель 
орієнтована на вирішення двох основних проблем: покращення точності 
відповідей за рахунок використання контекстуальних метаданих та підвищення 
прозорості пошуку через надання користувачам інформації про джерела даних. 
Взаємозв’язки між компонентами моделі визначають чіткий процес обробки 
запитів, від їх надходження до генерації відповідей, що дозволяє врахувати всі 
ключові аспекти роботи системи та створює основу для її подальшої розробки і 
вдосконалення. 
2.1.4 Проведення математичного дослідження 
Система орієнтована на пошук текстової інформації серед текстових даних. 
При цьому текстові дані піддаються векторизації і в подальшому обробляються у 
вигляді векторів. Для порівняння ідентичності або схожості двох текстових чанків 
використовуватиметься метод косинусної схожості (cosine similarity).  
Вирішується задача максимізації точносності відповідей до поставлених 
питань. Функція, результат якої буде максимізуватись, це функція косинусної 
схожості. 
Косинусна схожість – це метрика, яка вимірює схожість між двома 
векторами в багатовимірному просторі, визначаючи косинус кута між ними. Її 
часто використовують у задачах текстового пошуку та класифікації для 
порівняння текстових документів, запитів і відповіді в системах інформаційного 
пошуку [31][32]. 
Формула даного методу наступна: 
 
(2.1) 
 28 
ЧДТУ 242313.001 ПЗ 
 
де 
    і     - вектори, які представляють об'єкти (наприклад, тексти, документи, 
запити, чанки). 
          - скалярний добуток двох векторів. 
      і      - евклідові норми (довжини) векторів. 
Значення косинусної схожості знаходиться в діапазоні від -1 до 1. Де 1 
позначає, що вектори повністю ідентичні за напрямком (максимальна схожість), 0 
- що вектори ортогональні (не мають спільних характеристик), а -1 - вектори 
повністю протилежні, проте у задачах пошуку зазвичай не враховується, оскільки 
працюють лише з позитивними координатами і в даному досліджені відʼємні 
значення також не будуть враховані. 
Компоненти вектора визначаються частотою термінів у запиті, або за 
допомогою інших методів векторизації, наприклад: 
– TF-IDF: вага кожного слова залежить від його частоти у запиті та у всій 
базі. 
– Векторні представлення слів (Word Embeddings [33]): кожне слово або 
текст представляється як багатовимірний вектор за допомогою моделей, 
таких як Word2Vec [34], GloVe [35], або BERT. 
Скалярний добуток визначає спільність між векторами. Розраховується як 
сума добутків відповідних компонентів векторів: 
 
(2.2) 
 
де 
Аі і Ві – компоненти векторів. 
Норма вектора визначає довжину вектора у багатовимірному просторі і 
розраховується за наступною формулою: 
 
 
 29 
ЧДТУ 242313.001 ПЗ 
 
(2.3) 
 
У задачах текстового пошуку норма використовується для нормалізації 
векторів, щоб усунути вплив їхньої довжини. 
Метод косинусної схожості є ефективним та зручним інструментом для 
пошуку і порівняння текстових даних. Його простота реалізації за допомогою 
популярних бібліотек Python робить його доступним навіть для новачків у галузі 
машинного навчання. Завдяки семантичній точності, забезпеченій використанням 
сучасних векторних моделей, метод враховує не тільки точну відповідність слів, 
але й їхній контекст, що підвищує релевантність результатів. Крім того, метод 
демонструє високу швидкість, дозволяючи обробляти великі обсяги даних, що є 
важливим для задач, пов’язаних із пошуком у масштабних базах знань. Це робить 
косинусну схожість універсальним вибором для застосування у дослідженнях 
інтелектуальних агенті для пошуку і генерації інформації. 
2.1.5 Аналіз теоретичних рішень 
У дослідженні було обрано метод Retrieval-Augmented Generation для 
вирішення проблеми пошуку інформації в чат-ботах. Основна мета RAG полягає в 
інтеграції пошукового етапу з генеративною моделлю для покращення точності 
відповідей. Крім цього, запропоновано додавати метадані до кожного чанка 
інформації, щоб забезпечити контекстуалізацію результатів пошуку. На цьому 
етапі аналізується, наскільки ці підходи можуть бути ефективними у вирішенні 
задач роботи. 
Переваги застосування RAG: 
– покращення точності відповідей. RAG дозволяє проводити пошук 
інформації у базі знань перед генерацією відповіді, що значно зменшує 
ризик видачі нерелевантних або загальних відповідей. Приклад: Якщо 
користувач задає запит на кшталт "Яка дата заснування компанії X?", 
 30 
ЧДТУ 242313.001 ПЗ 
система спочатку знаходить відповідний документ у базі знань, а вже 
потім генерує відповідь на основі знайденої інформації; 
– адаптація до різних типів запитів. Модель може працювати із запитами, 
що вимагають як простого пошуку (наприклад, витяг даних із таблиці), 
так і генерації складних текстів (пояснень, висновків). Наприклад, для 
запиту «Поясни, як працює технологія X?» система може використати 
кілька джерел у базі знань, щоб згенерувати зрозуміле пояснення; 
– контекстуалізація даних. Метадані дозволяють визначати джерело 
інформації, дату її додавання, автора, тип документа та іншу релевантну 
інформацію. Це допомагає користувачеві краще зрозуміти походження 
відповіді та її актуальність. Якщо база знань містить декілька версій 
документа, метадані дозволяють вибрати найбільш актуальну або 
релевантну до запиту інформацію; 
– прозорість відповіді. Додавання метаданих забезпечує прозорість: 
користувач може перевірити джерело інформації та її контекст. На запит 
"Які правила оподаткування діють у 2024 році?" чат-бот може вказати, 
що відповідь базується на даних із законодавчого документа, доданого 
до бази знань у жовтні 2023 року. 
Можливі обмеження використання RAG: 
– збільшення обсягу даних. Додавання метаданих до кожного чанка 
збільшує розмір бази знань, що може впливати на швидкість пошуку. 
Якщо метадані включають кілька параметрів (дата, автор, джерело, тип 
документа), обсяг даних зростає, і система може потребувати додаткових 
оптимізацій; 
– складність пошуку. Збільшення кількості параметрів для пошуку може 
ускладнити процес, особливо якщо метадані будуть надто детальними 
або недоречно структурованими. 
Оцінка застосовності RAG у поєднанні з метаданими показує, що цей підхід 
має великий потенціал для покращення точності відповідей чат-бота, особливо у 
випадках, коли необхідно забезпечити високу релевантність та прозорість 
 31 
ЧДТУ 242313.001 ПЗ 
результатів. Незважаючи на певні обмеження, методи можуть бути адаптовані для 
роботи з великими обсягами даних за рахунок оптимізації пошукових алгоритмів. 
На основі аналізу було підтверджено, що об’єднання методології RAG із 
додаванням метаданих до кожного чанка інформації є найбільш перспективним 
для забезпечення високої точності пошуку та прозорості результатів. 
Семантичний пошук і використання векторної бази даних значно перевершують 
традиційні методи ключових слів за показниками точності. При цьому, врахування 
метаданих відкриває нові можливості для поліпшення довіри користувачів до 
системи, надаючи їм контекст інформації, що отримується. 
Цей етап завершується готовністю переходу до експериментальних 
досліджень для перевірки гіпотез і теоретичних висновків у реальних умовах 
роботи системи. 
2.1.6 Формулювання висновків 
В результаті теоретичних досліджень було побудовано концептуальну 
модель інтелектуального програмного агента для пошуку інформації в чат-боті, 
що базується на методології Retrieval-Augmented Generation. Встановлено, що 
інтеграція етапу пошуку релевантних даних перед генерацією відповіді та 
використання метаданих дозволяє значно підвищити точність і прозорість 
результатів пошуку. Метадані забезпечують контекстуалізацію кожного чанка 
інформації, зокрема вказують на джерела та авторів даних, що підвищує довіру 
користувачів до відповідей системи. 
Проведений аналіз показав, що запропонована теоретична модель має 
потенціал до адаптації в різних середовищах завдяки її універсальності та 
масштабованості. Проте виявлено обмеження, пов’язані із зростанням обсягу 
даних через додавання метаданих, що потребує оптимізації алгоритмів пошуку. На 
основі отриманих результатів рекомендовано перейти до етапу 
експериментальних досліджень для практичної перевірки ефективності моделі. 
Таким чином, теоретичне дослідження дозволило сформувати фундамент 
для практичної реалізації інтелектуального агента, який забезпечує точні, прозорі 
та релевантні відповіді на основі інтеграції RAG та метаданих у процес пошуку 
 32 
ЧДТУ 242313.001 ПЗ 
 інформації. 
2.2 Експериментальні дослідження 
Оскільки досліджується вплив метаданих на різні аспекти функціонування 
системи (швидкодію, точність, адаптивність, зручність), для цього найбільше 
підходить дробовий факторний експеримент. Цей метод дозволяє ефективно 
дослідити декілька факторів та їх комбінації без проведення всіх можливих 
експериментів, що економить ресурси. Крім того, цей метод забезпечує достатньо 
даних для аналізу основних ефектів та деяких взаємодій між факторами. 
Метою є перевірка впливу використання метаданих. Тому фактор 
експерименту є наявність метаданних при чанках даних. Фактор у свою чергу має 
два рівні: метадані присутні або відсутні. 
Виходячи з вище сказаного маємо можливість скласти плани для 
дрібнофакторних експериментів. Усього планується 4 експерименти, для кожного 
з  них складено план (таблиці 2.1, 2.2, 2.3, 2.4).  
 
Таблиця 2.1 
План першого дрібнофакторного експерименту  
№ досліду Наявність метаданих Результат (точність відповіді) 
1 Відсутні Y1 
2 Присутні Y2 
 
Для другого дрібнофакторного експерименту додано додатковий фактор – 
запис/читання (таблиця 2.2). 
 
Таблиця 2.2 
План другого дрібнофакторного експерименту  
№ досліду Наявність метаданих Запис/читання Результат (швидкодія) 
1 Відсутні Запис Y1 
2 Присутні Запис Y2 
 33 
ЧДТУ 242313.001 ПЗ 
Продовження таблиці 2.2 
3 Відсутні Читання Y3 
4 Присутні Читання Y4 
 
У третьому експерименті перевірятиметься адаптивність бази знань і 
системи 
в цілому до змін даних. План експерименту оновлено (див. таблицю 2.3). 
 
Таблиця 2.3 
План третього дрібнофакторного експерименту  
№ досліду Наявність метаданих версії Результат (адаптивність) 
1 Версія відсутня Y1 
2 Версія присутня Y2 
 
Отже, для доведення гіпотези потрібно провести чотири експерименти, 
спрямовані на різні аспекти поставленої гіпотези. 
 
Таблиця 2.4 
План четвертого дрібнофакторного експерименту  
№ досліду Відображення джерела даних Результат (зручність) 
1 Відсутнє Y1 
2 Присутнє Y2 
 
2.2.1 Перший експеримент: оцінка точності відповідей із використанням 
метаданих 
Мета: визначити, чи впливає додавання метаданих до чанків інформації на 
точність і релевантність відповідей. 
Кроки експерименту: 
1 Створити дві версії бази знань: одну з метаданими і одну без них. 
 34 
ЧДТУ 242313.001 ПЗ 
2 Провести серію запитів до пошукової системи з кожним типом 
наповнень баз знань. 
3 Оцінити релевантність та якість відповідей. 
Очікуваний результат: система з метаданими має демонструвати вищий 
рівень релевантності відповідей. 
Хід експерименту: 
Було створено два сети чанків з тестовою інформацією. Перший сет містить 
метадані додані до кожного чанку (рис. 2.2 а). Другий сет – це просто текстова 
інформація у чанках, без метаданих (рис. 2.2 б).  
Було написано систему на основі векторної бази даних Chroma DB для 
проведення тестових запитів. Для цього була використана стандартна бібліотека 
від розробників ChromaDB, яка легко завантажується через pip – пакетний 
менеджер Python. Бібліотека надає весь необхідний функціонал для роботи з 
векторною базою даних, зокрема додавання, редахування та пошук чанків. 
Приклад фрагменту коду на Python на рис. 2.3.  
Далі було виконано по два запити до кожного типу баз даних: з метаданими 
(рис. 2.4 а та рис. 2.5 а) та без метаданих (рис. 2.4 б та рис. 2.5 б).  
 
 
 35 
ЧДТУ 242313.001 ПЗ 
 
Рис. 2.2 – Приклади наповнення бази знань: а) чанки з використанням 
метаданих; б) чанки без використання метаданих 
 
Рис. 2.3 – Фрагмент тестової системи на основі векторної бази даних  
а) 
б) 
 
Рис. 2.4 – Запит до ChromaDB про положення кнопки: а) з метаданими; 
б) без використання метаданих 
 36 
ЧДТУ 242313.001 ПЗ 
а) 
б) 
 
Рис. 2.5 – Запит до ChromaDB про колір кнопки: а) з метаданими; б) без 
використання метаданих 
 
Висновки по експерименту:  
Експеримент проведено вдало, можна чітко оцінити результати проведеного 
досліду.  
У випадку відсутності метаданих, пошукова система не знає, яка версія 
оновлення даних була останньою, а яка вже застаріла та являється не релевантною 
для користувача. Тому виклик пошукового метода повертає усі чанки, де 
зустрічається будь-яка відповідна інформація. Відправивши отримані чанки у 
контексті до LLM на генерацію, модель просто не знатиме, що є релевантним, а 
яку інформацію варто опустити або помітити як застарівшу. 
Проте все змінюється з додаванням до чанків метаданих. Коли кожен чанк 
має версію і система може чітко визначити, що є актуальним, а що варто 
відфільтрувати, результат пошуку виходить релевантним і відповідає найновішим 
змінам бази знань. 
Експеримент довів, що додавання метаданих до чанків інформації впливає 
на точність і релевантність відповідей. 
2.2.2 Другий експеримент: аналіз швидкодії системи із додаванням  
 37 
ЧДТУ 242313.001 ПЗ 
метаданих 
Мета: визначити, як додавання метаданих впливає на швидкість обробки 
запитів. 
Кроки експерименту: 
1 Створити базу знань із великою кількістю чанків інформації. 
2 Виконати запис даних та пошук із використанням метаданими та без 
використання. 
3 Виміряти середній час обробки запитів у кожному варіанті. 
Очікуваний результат: додавання метаданих може незначно збільшити час 
обробки, але при оптимізації бази цей ефект буде мінімізовано. 
Хід експерименту: 
З допомогою сучасних технологій було згенеровано деяку кількість даних 
для тестів. В першому випадку, до даних було додано метадані. В другому – 
метадані відсутні. 
Було проведено ряд запитів для більшої точності заміри були усереднені. Усі 
заміри занесено до таблиці 2.5. 
 
Таблиця 2.5 
Заміри швидкодії запитів пошуку/запису до ChromaDB  
Замір №1 Замір №1 Замір №1 Замір №1 Підсумок 
Назва заміру 
(секунд) (секунд) (секунд) (секунд) (секунд) 
Запис без 
3.056 3.155 3.050 3.123 ~3.096 
метаданих 
Запис з 
3.010 2.951 3.159 3.029 ~3.037 
метаданими 
Пошук без 
0.145 0.148 0.158 0.140 ~0.147 
метаданих 
Пошук з 
0.150 0.150 0.155 0.142 ~0.149 
метаданими 
 
 38 
ЧДТУ 242313.001 ПЗ 
Висновки по експерименту:  
За результатами проведеного експерименту видно, що відмінність у часі з 
метаданими та без них мінімальна. Більше того, запис у векторну базу знань в 
середньому вийшов менший для чанків з метаданими, ніж без них. Невідомо 
достовірно, що вплинуло на пришвидшення запису, проте, є гіпотеза, що це 
відбувається за рахунок того, що Chroma – використана векторна база даних – має 
внутрішні оптимізації для збереження метаданих. У випадку, коли обсяг 
метаданих не великий, швидкість запису, порівняно з відсутніми метаданими, 
відносно однаковий, адже база даних має все рівно провести ініціалізацію комірки 
під додавання метаданих у майбутньому. 
Експеримент показав, що додавання метаданих майже не впливає на 
швидкість обробки запитів векторною базою даних, як на запис так і на пошук 
даних. 
2.2.3 Третій експеримент: перевірка адаптивності системи при оновленні 
бази знань з використанням метаданих 
Мета: перевірити, як система адаптується до змін у базі знань. 
Кроки експерименту: 
1 Додати дані до бази знань. 
2 Здійснити пошуковий запит. 
3 Оновити дані у базі знань. 
4 Повторити пошуковий запит. 
5 Оцінити точність пошуку. Переконатися, що система використала 
оновлені дані і надала релевантну відповідь. 
Очікуваний результат: система має врахувати наявність оновлення та 
використати нові дані при пошуку інформації. 
Хід експерименту: 
Для експерименту було створено два чанки даних з метаданими: один чанк 
текстової інформації містить базову інформацію про обʼєкт, другий – містить 
оновлену інформацію про той самий обʼєкт і в метаданих міститься інформацію 
про те, що чанк даних є свіжіший за попередній (рис. 2.6). 
 39 
ЧДТУ 242313.001 ПЗ 
Було виконано два пошукові запити до бази знань. Перший був зроблений до 
старої версії (рис. 2.7 а), другий – до оновленої (рис. 2.7 б).  
На рисунку 2.7 чітко видно різницю відповідей на однакові пошукові запити. 
Після того, як база даних була оновлена, нові дані поступили до пулу чанків. Так, 
як нові дані містили метедані щодо часу додавання (параметр timestamp з часом у 
вигляді цілого числа), то системи з легкістю змогла розпізнати, який чанк треба 
вивести, а 
який варто відфільтрувати. 
 
Рис. 2.6 – Чанки з початковою інформацією та оновленою  
 
Висновки по експерименту:  
Експеримент довів ефективність використання метаданих в чанках при 
динамічному оновленні даних у базі знань. 
 
а) 
б) 
Рис. 2.7 – Результати виконання запитів до бази знань: а) до 
неоновленої версії бази; б) до оновленої версії бази знань  
 40 
ЧДТУ 242313.001 ПЗ 
За допомогою експерименту було перевірено адаптивність системи до 
оновлень бази знань на основі метаданих часу або інших часових міток.  
2.2.4 Четвертий експеримент: перевірка зручності надання джерел 
інформації у відповідях 
Мета: оцінити, чи покращується якість роботи з даними у базі знань, якщо у 
відповідях повертаються джерела наданої інформації та інші метадані. 
Кроки експерименту:  
1 Створити дві версії чат-бота: одну з демонстрацією метаданих 
(наприклад, джерело, дата), іншу – без неї. 
2 Оцінити зручність та швидкість роботи з наявними джерелами даних 
в різних сценаріях. 
Очікуваний результат: надання метаданих у відповідях сильно 
пришвидшить роботу з відповідями від системи, а відповідно і роботу з базою 
знань. 
Хід експерименту: 
У якості тестових даних було використано ПДР України. Та сформовано 
пара питань до системи: 
1 «Якою стороною я повинен рухатись в Україні?» 
2 «Як передати авто іншій людині у користування?» 
На що були отримані відповіді на рисунку 2.8. 
 
 
Рис. 2.8 – Питання до чат-бота у Slack по ПДР України з 
відповідями з метаданими 
 41 
ЧДТУ 242313.001 ПЗ 
Оцінка зручності роботи з системою знань полягає в оцінці наявності 
метаданих наданих системою відносно їх відсутності. Оскільки життєві ситуації і 
сценарії використання системи можуть різнитися, то і оцінювання повинно 
проводитись з різних точок зору. Оцінювання проводиться з точки зору декількох 
сценаріїв використання системи: 
– оцінка дій у спірних ситуаціях на дорозі; 
– актуалізація змін у ПДР; 
– оперативне роз'яснення правил у складній дорожній ситуації; 
– допомога під час підготовки до іспитів на водійське посвідчення; 
Десятибальна шкала оцінювання, де 0 – позначає те, що метадані навіть 
зайві, а 10 – що без метаданих відповідь системи не має сенсу взагалі. Усі 
отримані результати були занесені до таблиці 2.6. 
 
Таблиця 2.6 
Результати оцінювання наявності метаданих у відповідях в 
різних сценаріях використання  системи 
Точка зору для оцінки Запит перший Запит другий 
оцінка дій у спірних ситуаціях на дорозі 8 9 
актуалізація змін у ПДР 3 10 
оперативне роз'яснення правил у складній 
5 5 
дорожній ситуації 
допомога під час підготовки до іспитів на 
10 10 
водійське посвідчення 
середня оцінка 6.5 8.5 
 
Висновки по експерименту: 
Даний експеримент довів необхідність та важливість наявності метаданих у 
відповідях чат-бота. Два запити до системи з базою знань по ПДР України були 
оцінені з різних життєвих ситуацій. Це пояснюється тим, що необхідність 
метаданих може варіюватись від контексту та потреб. 
 42 
ЧДТУ 242313.001 ПЗ 
За результатами оцінювання видно, що середня оцінка обох запитів вище 
середнього. Це зумовлено тим, що у кожній з ситуацій дійсно є необхідність у 
метаданих, інформації по тому, на основі чого згенеровано дану відповідь та коли 
було опубліковано документ з контекстом для відповідей. 
Експеримент доводить необхідність наявності метаданих у відповідях 
системи. Вони є не лише корисними, а й необхідними для вирішення додаткових 
суперечностей, як, наприклад, пошук додаткової інформації по питанню. 
Висновок до другого розділу 
У розділі було проведено низку експериментів, спрямованих на перевірку 
ефективності впровадження метаданих у систему інтелектуального пошуку. 
Отримані результати підтвердили, що використання метаданих значно підвищує 
якість функціонування системи. 
Перший експеримент продемонстрував, що точність відповідей системи 
зросла завдяки контекстуальному врахуванню метаданих, які покращують зв'язок 
між запитами користувачів та релевантними даними. Другий експеримент показав, 
що додавання метаданих практично не впливає на швидкодію системи, 
забезпечуючи стабільну роботу. 
Третій експеримент підтвердив високу адаптивність системи під час 
оновлення бази знань, оскільки метадані дозволили швидко і точно інтегрувати 
нові дані без втрати їх з контексту. Четвертий експеримент довів зручність для 
користувачів у наданні джерел інформації у відповідях, що підвищило прозорість 
та довіру до системи. 
Таким чином, результати експериментальних досліджень підтверджують 
ефективність впровадження метаданих, що позитивно вплинуло на точність, 
адаптивність, швидкодію та зручність використання системи. Ці висновки 
надають підґрунтя для подальшого впровадження отриманих результатів в 
інтелектуальні програмні комплекси.  
  
 43 
ЧДТУ 242313.001 ПЗ 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
3.1 Моделювання предметної області 
3.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області 
Предметною областю моделювання є створення інтелектуального 
програмного агента для пошуку інформації у чат-боті, що працює з базою знань, 
сформованою з користувацьких документів. Цей агент повинен забезпечувати 
точність, релевантність і прозорість відповідей, а також адаптацію до змін у базі 
знань. 
Розробка базується на використанні технології Retrieval-Augmented 
Generation (RAG), яка поєднує пошук релевантної інформації з бази знань із 
генерацією текстової відповіді. Особливістю є додавання метаданих до кожного 
чанка інформації, що сприяє контекстуалізації та прозорості результатів пошуку. 
Основні компоненти моделі предметної області: 
– чат-бот. Функція: прийом запитів від користувача та повернення 
відповідей. Взаємодії: передає текстовий запит до системи RAG. 
Повертає користувачу сформовану відповідь разом із метаданими; 
– система RAG. Функція: відповідає за пошук інформації у базі знань і 
генерацію тексту. Взаємодії: отримує запит від чат-бота, передає запит 
до системи пошуку та використовує результати пошуку для генерації 
відповіді; 
– база знань. Функція: зберігання інформації, яка використовується для 
пошуку відповідей. Включає чанки даних та метадані до кожного чанка 
інформація; 
– чанки інформації. Функція: основні одиниці інформації, які 
використовуються у пошуку. Особливості: зручний розмір для 
пошукових алгоритмів; кожен чанк супроводжується метаданими; 
 44 
ЧДТУ 242313.001 ПЗ 
– метадані. Функція: покращують контекстуалізацію пошуку та 
забезпечують прозорість відповідей. Прикладами метаданих є джерела 
інформації (файли, назви файлів, посилання), автор інформації, час 
створення/додавання, контекстні теги; 
– система пошуку. Функція: Знаходить найбільш релевантні чанки 
інформації за запитом користувача. Використовує технології векторизації 
тексту та семантичний пошук із використанням векторної бази даних, а 
також алгоритми оцінки схожості (наприклад, косинусна схожість). 
Взаємозв’язки між компонентами: 
Користувач -> чат-бот: користувач вводить текстовий запит через чат-бот. 
Чат-бот -> система RAG: запит передається до системи RAG для обробки. 
Система RAG -> система пошуку: система пошуку знаходить релевантні 
чанки інформації у базі знань. 
Система пошуку -> база знань: взаємодія для пошуку потрібних чанків за 
допомогою семантичного аналізу. 
База знань -> система RAG: результати пошуку (релевантні чанки з 
метаданими) передаються до системи RAG, де генерується текстова відповідь, яка 
включає інформацію та метадані. 
Система RAG -> чат-бот: відповідь повертається назад до чат-боту. 
Чат-бот -> користувач: користувач отримує відповідь разом із зазначенням 
джерел та контексту з використанням можливостей чат-боту в оформленні 
відповіді. 
Ця модель демонструє, як кожен компонент системи сприяє ефективному 
функціонуванню інтелектуального програмного агента, забезпечуючи точність, 
зручність і прозорість пошуку інформації у чат-боті. 
Словник предметної області створюється для уніфікації термінів, які 
використовуються в дослідженні. Це дозволяє чітко описати поняття та уникнути 
двозначності під час аналізу та розробки. Словник описаної предметної області 
включає наступні поняття та визначення: 
Первинні терміни:  
 45 
ЧДТУ 242313.001 ПЗ 
– чат-бот: програмний агент, який взаємодіє з користувачем через 
текстовий або голосовий інтерфейс, відповідаючи на запити та 
виконуючи завдання адміністраторів системи; 
– RAG: архітектурний підхід, який поєднує дві фази: пошук релевантної 
інформації у базі знань (retrieval) та генерацію відповіді (generation). 
– база знань: структура даних, що зберігає інформацію у вигляді чанків з 
метаданими, яка використовується системою для пошуку та формування 
відповідей; 
– чанк: фрагмент текстової інформації, невелика структурована частина 
даних у базі знань. Зазвичай це абзац або сегмент тексту, що містить 
логічно завершену думку; 
– метадані: додаткові дані, які описують властивості чанка (джерело, 
автор, дата додавання, ключові слова, тематичний тег, тощо); 
– векторизація: процес перетворення текстової, графічної або іншого типу 
інформації у вектор або масив чисел; 
– семантичний пошук: метод пошуку інформації, який враховує значення 
слів та контекст, а не просто точне співпадіння тексту. Використовує 
векторизацію тексту для оцінки схожості; 
– векторна база даних: тип бази даних, що зберігає дані у вигляді 
багатовимірних векторів, які використовуються для семантичного 
пошуку; 
– косинусна схожість: математичний метод оцінки подібності між двома 
векторами в багатовимірному просторі. Використовується для 
визначення релевантності між запитом користувача та даними в базі 
знань; 
– інтелектуальний програмний агент: система, що може самостійно 
приймати рішення, обробляти запити, виконувати пошук інформації та 
адаптуватися до змін у базі знань; 
– джерело інформації: документ або інший носій даних, з якого був 
отриманий чанк інформації; 
 46 
ЧДТУ 242313.001 ПЗ 
– контекстуалізація: процес врахування контексту для покращення 
точності пошуку та відповідей; 
– пошуковий запит або просто запит: інформація, введена користувачем у 
чат-бот для отримання відповіді; 
– генерація тексту: автоматичне створення текстової відповіді на основі 
знайденої інформації; 
– адаптивність системи: здатність системи змінювати поведінку залежно 
від змін у базі знань або у середовищі, де вона працює. 
У предметної області присутні терміни, які мають менше значення, ніж 
первинні, проте їх також варто врахувати при розробці системи і описати у даному 
словнику. Вторинні терміни: 
– точність пошуку: ступінь відповідності результату пошуку очікуванням 
користувача; 
– релевантність: відповідність знайденої інформації до заданого запиту. 
– прозорість пошуку: можливість користувача зрозуміти, звідки була 
отримана відповідь, за рахунок доступу до метаданих; 
– користувач: людина, яка взаємодіє із системою через чат-бот для пошуку 
інформації. 
– адміністратор: користувач, який має доступ до API для здійснення 
керування пошуковим агентом, наповнення бази знань, тощо. 
Таким чином, предметна область моделювання охоплює весь цикл пошуку 
інформації у чат-боті: від введення запиту до надання користувачу відповідей із 
точними джерелами, що робить цю систему зручною, прозорою та адаптивною до 
змін. 
3.1.2 Елементи моделювання предметної області 
Під час моделювання предметної області будуть застосовуватися UML-
діаграми. Уніфікована мова моделювання забезпечує можливість створювати 
діаграми, які залишаються зрозумілими незалежно від специфіки проекту, його 
мети чи мовної приналежності автора. Зокрема, були створені такі види діаграм 
[36]: 
 47 
ЧДТУ 242313.001 ПЗ 
– діаграма класів; 
– діаграма пакетів; 
– діаграма компонентів; 
– діаграма розгортання; 
– діаграми взаємодії, як-от діаграми послідовності та комунікації; 
– діаграми поведінки, серед яких діаграми прецедентів, діяльності та 
кінцевих автоматів. 
Ці діаграми забезпечують комплексне уявлення про те, як повинна 
функціонувати система і як її компоненти взаємодіятимуть між собою. 
Під час розробки застосунку планується використовувати певні фреймворки, 
які мають складну структуру взаємодії класів і компонентів. Для відображення 
цих взаємодій буде створено окремі діаграми, що допоможуть у їх візуалізації. 
UML-діаграми включають набір стандартних компонентів (рис. 3.1) та типів 
зв’язків між ними (рис. 3.2). 
Рис. 3.1 – Позначення UML діаграм [36] 
 48 
ЧДТУ 242313.001 ПЗ 
Зв’язки в UML-діаграмах слугують для відображення взаємодій між 
об’єктами або класами в системі. Вони ілюструють, як об’єкти співпрацюють, які 
з них мають залежності один від одного та яким чином взаємодіють з іншими 
елементами системи. 
В UML передбачено близько 15 типів діаграм, основні з яких представлені на рис. 
3.3. Ці діаграми поділяються на класи, що представлені на тій же діаграмі. Такий 
розподіл дозволяє оцінити ролі діаграм у загальному вигляді. 
 
Рис. 3.2 – Типи звʼязків на UML діаграмах  [36] 
 49 
ЧДТУ 242313.001 ПЗ 
Рис. 3.3 – Види UML діаграм з розподілом по класах [36] 
 
У мові моделювання UML виділяють кілька основних класів діаграм, 
призначених для візуалізації різних аспектів системи. До них належать: 
– діаграми структури; 
– діаграми поведінки; 
– діаграми варіантів використання; 
– діаграми розширення. 
Кожен із цих класів має свої особливості та використовується для 
моделювання 
окремих аспектів системи залежно від поставлених цілей. 
3.1.3 Робоча область моделювання 
Робоча область моделювання визначає сферу, в якій працює система, та 
описує її основні функціональні можливості, цільове призначення та очікувані 
результати. Для розробки інтелектуального програмного агента на базі RAG 
основною робочою областю є автоматизація процесу пошуку інформації серед 
документів користувача, забезпечення швидкого доступу до релевантних даних та 
покращення точності відповідей. 
Чат-бот із системою RAG призначений для використання в умовах, де: 
– обсяг даних великий, а їх структура складна. Наприклад, великі 
корпоративні    архіви,    навчальні     матеріали   або    бази    юридичних  
 50 
ЧДТУ 242313.001 ПЗ 
документів; 
– необхідний динамічний пошук. Система повинна швидко адаптуватися 
до змін у базі знань (додавання нових документів чи оновлення 
існуючих); 
– користувачі мають обмежений час для отримання відповіді. Чат-бот 
повинен знаходити й надавати точні відповіді в реальному часі; 
– потрібна прозорість результатів. Надані відповіді мають 
супроводжуватися метаданими, які показують джерело, автора чи час 
додавання інформації. 
Поширені сценарії використання чат-бота можуть бути наступні життєві 
ситуації: 
– пошук документації в корпоративному середовищі; 
– юридичні консультації; 
– навчальні запити; 
– медичні консультації. 
Описана модель охоплює чат-бот як інтерфейс користувача, базу знань із 
чанками інформації, доповненими метаданими, систему пошуку на основі 
семантичного аналізу та генерації відповідей. Використання метаданих дозволяє 
покращити точність, релевантність і прозорість відповідей, що є ключовими 
факторами успішної роботи системи. Запропонована модель враховує потреби 
користувачів у швидкому доступі до достовірної інформації та забезпечує 
адаптацію системи до змін у базі знань. Це створює основу для подальших 
експериментальних досліджень, спрямованих на перевірку ефективності системи 
в реальних умовах. 
3.2 Формування та аналіз вимог 
Вимоги до системи включають в себе первинні та вторинні (або детальні) 
вимоги. Кожен з рівнів поділяється на функціональні та не функціональні вимоги. 
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні  
 51 
ЧДТУ 242313.001 ПЗ 
вимоги 
Для системи інтелектуального пошуку інформації в чат-боті первинні та 
детальні вимоги можна розділити на функціональні та нефункціональні. 
Первинні функціональні вимоги занесено до таблиці 3.1. 
Нефункціональними вимогами до системи є: 
– швидкодія: система повинна повертати відповіді на запити користувачів 
за час не більше 5-10 секунд; у випадку адміністратора, файл великого 
обсягу прийнятно оброблювати до трьох-чьотирьох хвилин, проте 
користувач має бути повідомлений про затримку обробки; 
– масштабованість: система повинна мати архітектуру, яка легко 
масштабується для обробки збільшеної кількості запитів і розширення 
бази знань; 
– прозорість: користувач має знати про те, що в системі відбувається 
обробка або про помилки, які він в силах виправити та про те, що 
операція була завершена з відповідним результатом; 
 
Таблиця 3.1 
Функціональні вимоги  
№ Користувач Система 
Приймає запит, виконує пошук релевантного 
Вводить пошуковий запит у 
1 контексту та надсилає відповідь користувачу у 
запит Slack-Bot чат 
чат 
Приймає запит, перевіряє аутентифікацію, 
Адміністратор надсилає 
розбиває файл на чанки, додає метадані, 
2 файл з даними запит у запит 
векторизує, зберігає у базу знань, відповідає 
Slack-Bot чат 
користувачу про готовність 
Приймає запит, виконує пошук релевантного 
Питає про не існуючу 
контексту, перевіряє факт, що контексту не 
3 сутність в базі знань у запит 
достатньо, відповідає користувачу проханням 
у Slack-Bot 
про уточнення 
 52 
ЧДТУ 242313.001 ПЗ 
Продовження таблиці 3.1 
Адміністратор надсилає Приймає запит, перевіряє аутентифікацію, 
4 пошкоджений або порожній валідує отриманий файл, відповідає помилкою з 
файл у Slack-Bot текстом проблеми 
 
– надійність: система має бути стійкою до відмов, зокрема забезпечувати 
стабільну роботу Slack-Bot і API, навіть за високих навантажень; 
– безпека: адмінське API повинно мати обмежений доступ, щоб 
забезпечити захист бази знань і уникнути несанкціонованих змін; 
– зручність використання: інтерфейс чат-бота має бути інтуїтивно 
зрозумілим для користувачів без необхідності спеціального навчання. 
Після проведеного аналізу первинних вимог було сформовано наступні 
функціональні та нефункціональні детальні вимоги. 
Детальні функціональні вимоги: 
– підтримка запитів різних типів: система повинна підтримувати запити як 
у вигляді запитань, так і у вигляді ключових слів; 
– обробка природної мови (NLP): система повинна коректно розпізнавати 
синоніми та варіації запитів завдяки NLP-моделям, щоб забезпечити 
точні відповіді; 
– обробка запитів на українській мові, зокрема підтримка граматичних 
особливостей; 
– покращення точності через використання метаданих: використання 
метаданих чанків повинно забезпечити контекстуальну відповідність 
відповідей, зокрема врахування тематики та категорії інформації; 
– функціонал наповнення бази знань: адмінське API повинно дозволяти 
адміністратору завантажувати нові дані з метою додавання нової 
інформації до бази знань; 
– функціонал оновлення бази знань: адмінське API повинно дозволяти 
адміністратору завантажувати оновленні дані з метою оновлення 
існуючих; 
 53 
ЧДТУ 242313.001 ПЗ 
– журнал запитів та відповідей: система повинна зберігати журнал запитів 
і відповідей для подальшого аналізу та покращення якості роботи 
(наприклад, для вдосконалення RAG-моделі); 
– логування системи: система має зберігати тексти помилок з метою їх 
подальшого аналізу та усунення. 
Також були сформовані наступні детальні нефункціональні вимоги: 
– стійкість до помилок та аварійне відновлення: система має автоматично 
відновлюватися після збоїв, а дані користувачів повинні бути збережені 
під час непередбачених відмов; 
– інтерфейс API з відкритою документацією: API повинно бути 
задокументовано, щоб полегшити його інтеграцію та використання 
іншими сервісами або розробниками; 
– модульність і розширюваність: кодова база повинна бути 
структурованою та модульною, щоб можна було додавати нові функції 
або змінювати існуючі з мінімальними зусиллями. 
Ці вимоги забезпечують всебічний підхід до розробки, інтеграції та роботи 
системи, гарантуючи її продуктивність, зручність і точність. 
3.2.2 Формування вимог за допомогою діаграми прецедентів 
У цьому підрозділі розглядається процес формування вимог до 
інтелектуального програмного агента для пошуку інформації в чат-боті, який 
використовує систему Retrieval-Augmented Generation. Для чіткого визначення 
основних функціональних вимог було застосовано метод діаграми прецедентів, 
що дозволяє наочно представити взаємодію користувача з системою та ключові 
сценарії її роботи. Діаграма прецедентів є важливим інструментом на етапі 
розробки, оскільки вона дає змогу визначити функції, які повинні бути реалізовані 
для забезпечення ефективної взаємодії між користувачем і чат-ботом, а також 
описує процеси, що здійснюються при виконанні основних завдань. 
На діаграмах прецедентів (рис. 3.4 та 3.5) представлено можливих акторів 
системи та прецедентів – функції, через які актори взаємодіють з системою. 
 54 
ЧДТУ 242313.001 ПЗ 
Рис. 3.4 – Діаграма прецедентів. Актори: користувач та адміністратор 
 
Можливі актори системи: 
– користувач: людина, яка робить запит до Slack-Bot з метою отримати 
відповідь на запитання; 
– адміністратор: користувач з правом оновлювати базу знань, який має 
відповідну роль у системі; 
– чат-бот: Slack-Bot  - програма, яка виконує запити до RAG API після 
отримання запитів від користувачів та взаємодіє з користувачем, 
повертаючи йому відповіді від RAG API. 
Взаємодія користувачів з системою може бути здійснена за допомогою будь-
якого пристрою з можливістю встановлення програмного забезпечення Slack. Це 
 55 
ЧДТУ 242313.001 ПЗ 
може бути як компʼютер, так і мобільний девайс. 
 
 
Рис. 3.5 – Діаграма прецедентів. Актор – чат-бот 
 
В результаті формування вимог за допомогою діаграми прецедентів було 
чітко окреслено основні сценарії взаємодії користувача з чат-ботом, зокрема щодо 
пошуку інформації, генерування відповідей та використання системи 
адміністратором. Діаграма прецедентів надає чітке візуальне уявлення про 
наявний фунціонал системи та є важливим інструментом для подальшої розробки 
і тестування інтелектуального агента. 
 56 
ЧДТУ 242313.001 ПЗ 
3.3 Проектування логічної структури програмного комплексу 
Результати проектування будуть надані у UML діаграмах, як: діаграми 
класів, пакетів, компонентів та розгортання. 
3.3.1 Діаграма класів 
Аналіз первинних та вторинних вимог та розгляд предметної області дає 
можливість приступити до формування логічної структури системи. 
На основі моделі предметної області сформовано діаграму класів (рис. 3.6), 
яка відображає сутності системи у програмних класах та відображає інтерфейси 
виокремлених класів та їх звʼязків. 
Діаграма класів є візуалізацією наявних класів системи. Серед класів 
присутні: 
– клас User. Клас представляє користувача, який взаємодіє з чат-ботом; 
– клас Administrator. Клас представляє адміністратора, який має розширені 
права для управління системою; 
– клас SlackApi. Клас-обгортка над стороннім інтерфейсом Slack, що 
робить можливим роботу зі Slack API не привʼязуючись до імплементації 
самого Slack. Це робить можливим розширення системи для нових 
інтеграцій з іншими додатками для обміну повідомленнями в 
майбутньому; 
– клас Chatbot. Основний клас, що відповідає за обробку запитів 
користувача та взаємодію з іншими компонентами системи; 
– клас Rag. Клас, що реалізує архітектурний підхід Retrieval-Augmented 
Generation. Надає інтерфейс для взаємодії з даною реалізацією, являється 
вхідною точкою до бази даних; 
– клас KnowledgeBase (Storage). Клас, що представляє базу знань, де 
зберігається інформація для відповідей на запити. Являється 
обгортковим класом над ChromaDB, адже включає класи цієї сторонньої 
бібліотеки і реалізує методи взаємодії з нею. Потрібен для розвʼязки від 
імплементації сторонньої бібліотеки і надання можливостей розширення  
 57 
ЧДТУ 242313.001 ПЗ 
і заміни використаної технології векторної бази даних; 
Рис. 3.6 – Діаграма класів системи 
 
– клас TextChunk. Клас, що представляє окремий чанк інформації. 
Головною особливістю є те, що включає в себе клас Metadata; 
– клас Metadata. Клас, що представляє метадані. Клас може бути 
дженериком і приймати тип даних, який буде візуалізувати дані 
збережені у метаданих. Залежить від обраної мови програмування; 
Ця структура класів дозволяє забезпечити чітке розмежування 
відповідальності між компонентами системи, підтримує модульність та гнучкість 
 58 
ЧДТУ 242313.001 ПЗ 
у розробці. При проектуванні даної діаграми було передбачено можливості 
розширення системи у майбутньому та можливість застосування шаблонів 
програмування, таких як, наприклад, Strategy. 
3.3.2 Діаграма пакетів 
Діаграма пакетів демонструє архітектурну структуру системи, поділяючи її 
на логічні модулі, кожен із яких відповідає за окрему функціональність. У додатку 
для чат-бота, що використовує систему RAG, така діаграма дозволяє чітко 
розмежувати функції між основними компонентами, зокрема: інтерфейсом 
взаємодії з користувачами, механізмами пошуку та генерації відповідей, 
управління базою знань і обробкою метаданих. Такий підхід сприяє 
масштабованості системи, полегшує її підтримку та забезпечує інтеграцію з 
платформами, такими як Slack. 
На діаграмі пакетів (рис. 3.7) представлено ключові пакети, включаючи User 
Interface, RAG (логіка пошуку й генерації), Knowledge Base Management 
(управління базою знань), Metadata Processing (обробка метаданих) і різного роду 
залежності (з англ. dependency) від сторонніх розробників, які дозволяють 
прискорити розробку системи. На діаграмі також вказані звʼязки між пакетами. 
Кожен із пакетів спроектований таким чином, щоб мінімізувати зв'язок між 
іншими пакетами системи, що дозволяє реалізувати систему за принципом 
модульності. 
 
Рис. 3.7 – Діаграма пакетів 
 59 
ЧДТУ 242313.001 ПЗ 
Розроблена діаграма пакетів відображає структуру системи, яка дозволяє 
гнучко реалізувати функціональність чат-бота з використанням RAG. Завдяки 
розподілу системи на пакети забезпечено чітке розмежування завдань між 
компонентами, що спрощує додавання нових функцій, оновлення логіки пошуку 
та обробки даних.  
Цей підхід дозволяє не лише покращити керованість системи, але й 
забезпечити її надійність, масштабованість та ефективність. Завдяки чіткому 
визначенню функцій пакетів, розробники можуть працювати над окремими 
модулями незалежно, що значно оптимізує процес розробки та інтеграції нових 
можливостей. 
3.3.3 Діаграма компонентів 
Діаграма компонентів відображає внутрішню архітектуру системи, 
демонструючи її ключові складові та зв'язки між ними. Вона допомагає зрозуміти 
структуру програмного забезпечення та забезпечує прозорість процесу реалізації, 
полегшуючи інтеграцію нових функцій. На діаграмі відображено, як запити 
користувача проходять через інтерфейс, обробляються компонентами пошуку та 
генерації відповідей, а також як система взаємодіє з базою знань і зовнішніми API. 
Таким чином, діаграма підкреслює взаємозв'язок логіки роботи чат-бота та його 
технічної реалізації. 
Основні компоненти поділено на сторонні сервіси, клієнтська частина та 
серверна частина (рис. 3.8). Клієнтська частина містить компонент Slack-Bot, що 
має у свою чергу зберігати інформацію про користувача, історію переписки з 
користувачем та налаштування профілю. Серверна ж частина відповідає за 
обробку запиту користувача, пошук інформації. За це відповідають компоненти 
RAG API та Chroma DB. Ці компоненти повʼязані з клієнтською частиною через 
сервера Slack і взаємодіють зі Slack [37] через WebHooks.  
Вебхуки (з англ. WebHooks) - це автоматизовані повідомлення, що 
надсилаються з веб-додатків до інших веб-додатків. Це потужний інструмент, 
який дозволяє розробникам інформувати кілька сервісів про оновлений контент 
або дані користувача. Це дозволяє веб-сторінкам залишатися синхронізованими, 
 60 
ЧДТУ 242313.001 ПЗ 
оскільки вебхуки дають можливість розробникам швидко з'єднувати два веб-
сервіси та автоматично передавати інформацію між ними в режимі реального часу. 
Вебхуки можна використовувати практично для будь-чого, включаючи push-
повідомлення про відправлення товару або надсилання платіжної інформації після 
здійснення покупки. Вебхуки забезпечують легкість і зручність без необхідності 
ручного введення або проміжного програмного забезпечення, роблячи веб-
розробку більш плавною, ніж будь-коли [38].  
Компонент RAG API має звʼязок з компонентом ChromaDB та надає або, 
іншими словами, запитує базу даних про релевантний до запиту користувача 
контекст. Коли ChromaDB повертає контекст, RAG API компонент може розпочати 
генерацію промпту до LLM моделі [39].  
Для того, аби здійснити запит до LLM моделі, на серверній частині 
використано HTTP/HTTPS запити до LLM API. Сторонній сервіс надає інтерфейс 
для роботи з  моделлю і можливістю співпрацювати з нею через REST API запити.  
 
 
Рис. 3.8 – Діаграма компонентів 
 
Коли RAG API матиме промпт, він відправить запит на LLM API для генерації 
відповіді по запиту користувача. У свою чергу, модель вже матиме весь потрібний 
контекст для релевантної та точної відповіді. 
Модульна архітектура, відображена на діаграмі, сприяє масштабованості та 
спрощує підтримку системи. Вона забезпечує можливість легкого оновлення 
 61 
ЧДТУ 242313.001 ПЗ 
системи та інтеграцію з іншими системами, тобто додавання додаткових модулів. 
Таким чином, діаграма компонентів є ключовим інструментом для побудови 
ефективного, надійного та гнучкого програмного забезпечення. 
3.3.4 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Діаграма розгортання подана на рисунку 3.9 і для даної системи відображає 
фізичну архітектуру програмного забезпечення, показуючи взаємозв’язок між її 
компонентами та апаратними вузлами. Вона забезпечує ясність у питанні, як 
програмна система працює в реальному середовищі. У даному випадку 
розгортання передбачає використання трьох основних серверів: сервер для 
інтеграції зі Slack, сервер для роботи з API RAG, і окремий сервер для обробки 
запитів за допомогою великої мовної моделі. Сервер для бази знань не 
передбачено для економії ресурсів та часу на розробку системи. Адже база знань 
не є чимось сладним та важкомісним. Ресурсів сервера RAG API повинно 
вистачити. І тим не менш, в архітектурі модульної системи закладено можливість 
перенесення векторної бази даних на окремий сервер. 
 
 
Рис. 3.9 – Діаграма розгортання 
 62 
ЧДТУ 242313.001 ПЗ 
Взаємодія між серверами відбувається через протокол HTTP/HTTPS, що 
забезпечує надійний і безпечний обмін даними. Така архітектура сприяє 
модульності, розподіленості обчислень і простоті масштабування системи, що є 
ключовими аспектами для забезпечення її продуктивності та адаптивності до 
навантажень. 
Розгортання системи на трьох окремих серверах дозволяє досягти розподілу 
функцій між різними вузлами, забезпечуючи оптимальну продуктивність кожного 
компонента. Сервер Slack дозволяє ефективно обробляти запити з платформи, 
сервер RAG API виступає посередником для пошуку інформації в базі знань, а 
сервер із LLM-моделлю забезпечує генерацію відповідей, використовуючи 
векторизовані дані. 
Використання HTTP/HTTPS-з’єднань між серверами забезпечує безпеку та 
зручність передачі даних у розподіленій системі. Такий підхід гарантує, що 
система є масштабованою, стійкою до можливих збоїв і готовою до інтеграції з 
додатковими компонентами у майбутньому. Діаграма розгортання, таким чином, 
служить ефективним інструментом для планування та управління фізичною 
інфраструктурою системи. 
3.4 Моделювання поведінки системи 
Результати моделювання поведінки системи будуть продемонстровані за 
допомогою UML діаграм, таких як: діаграма діяльності, послідовності, 
комунікації та скінченного автомату. 
3.4.1 Діаграма діяльності 
Діаграма діяльності (рис. 3.10) демонструє ключові кроки взаємодії 
користувача з системою, починаючи з написання запиту і завершуючи отриманням 
сформованої відповіді в чат-боті. Цей підхід дозволяє візуалізувати процеси 
системи та визначити потоки дій, що забезпечують ефективність виконання 
завдань. 
Робота системи охоплює кілька важливих етапів: введення користувачем 
запиту, передача його в систему RAG, пошук релевантного контексту в базі знань, 
 63 
ЧДТУ 242313.001 ПЗ 
формування промпту на основі знайдених даних і генерація відповіді за 
допомогою мовної моделі. Висновки передаються назад у вигляді результату до 
користувача. Ця діаграма є основою для аналізу продуктивності системи, 
оптимізації її компонентів і забезпечення прозорості виконання кожного етапу. 
 
Рис. 3.10 – Діаграма діяльності 
 
Так, як це складна система з великою кількістю взаємодій між її 
компонентами, то важливим чинником надійності є обробка помилок та ситуацій, 
коли система може зламатись і не повідомити про це користувача. Оскільки в 
вимогах до системи зазначено надійність системи, то будь-яка помилка на сервері 
повинна бути оброблена та надана відповідна інформація користувачу.  
Оброблено ситуації: 
 64 
ЧДТУ 242313.001 ПЗ 
запит користувача не має повʼязаного контексту в базі знань: сервер 
поверне 422 код помилки, що свідчить про те, що запит користувача є 
невдалим і користувацький інтерфейс зможе обробити цю помилку  
особливим чином; 
– запит користувача не є валідним: це означає, що користувач ввів занадто 
великий запит або відправив питання у вигляді, який не підтримується 
системою. 
– пошуковий запит має забагато повʼязаного контексту в базі знань: 
забагато контексту в промпті до LLM може нашкодити точності і 
лаконічності відповіді, тому усі отримані чанки будуть відфільтровані і 
повернуті лише 10 найбільш вагомих зі списку знайдених. 
Діаграма діяльності допомагає деталізувати складний процес роботи 
системи, відображаючи ключові етапи та взаємодії між компонентами. Завдяки 
цьому можна зрозуміти, як запити проходять через систему RAG і базу знань, як 
формується контекст для відповіді, і як відповіді генеруються та надсилаються 
користувачеві. 
Ця модель підкреслює важливість інтеграції пошуку релевантних даних із 
бази знань, оптимального формування промпту та використання мовної моделі 
для точних і змістовних відповідей. Візуалізація цих дій дозволяє систематизувати 
поведінку системи, знаходити потенційні вузькі місця та вдосконалювати її 
функціональність. 
3.4.2 Діаграма послідовності 
Діаграма послідовності (рис. 3.11) ілюструє ключові етапи взаємодії між 
компонентами системи під час обробки запиту користувача. У рамках цієї системи 
SlackBot слугує основним інтерфейсом для користувача, а API забезпечує обробку 
запитів і реалізує алгоритм Retrieval-Augmented Generation. Діаграма демонструє, 
як запит користувача проходить через систему, включаючи доступ до векторної 
бази даних для пошуку релевантного контексту та запити до LLM для генерації 
відповідей. 
– користувач через SlackBot формує запит і надсилає його в систему; 
 65 
ЧДТУ 242313.001 ПЗ 
– SlackBot пересилає запит до API, яке є центральним компонентом для 
обробки запитів; 
− API реалізує методологію RAG, яка розділяє процес на два основні 
етапи: спочатку API звертається до VectorDB, яка зберігає векторні 
подання даних. База шукає релевантний контекст, використовуючи 
семантичний пошук; після отримання релевантного контексту API 
формує промпт для запиту до LLM; 
 
 
Рис. 3.11 – Діаграма послідовності 
 
– LLM приймає промпт, обробляє інформацію та генерує відповідь на 
основі отриманого контексту; 
– сформована відповідь повертається до API, яке передає її назад до 
SlackBot; 
– SlackBot відображає відповідь користувачу. 
 66 
ЧДТУ 242313.001 ПЗ 
Діаграма послідовності розкриває основні аспекти взаємодії компонентів 
системи під час обробки запиту користувача. Вона підкреслює ключові ролі 
кожного елемента, включаючи SlackBot як інтерфейс, API як центр обробки, 
VectorDB як базу для семантичного пошуку контексту та LLM для генерації 
інтелектуальних відповідей. 
Ця модель забезпечує систематичний підхід до обробки запитів, який 
дозволяє досягти високої релевантності та точності відповідей. Діаграма також 
слугує інструментом для аналізу та вдосконалення системи, що особливо важливо 
для оптимізації роботи з великими обсягами даних і покращення взаємодії між 
компонентами. 
3.4.3 Діаграма комунікації 
Діаграма комунікації, подібно до діаграми послідовності, демонструє 
взаємодію між різними компонентами системи під час обробки запитів 
користувача та адміністрування бази знань. Окрім користувача, який взаємодіє з 
системою через SlackBot, на діаграмі з’являється актор Адміністратор, чия роль 
полягає в оновленні бази знань для забезпечення актуальності та точності даних. 
Діаграма комунікації (рис. 3.12) візуалізуалізує, як компоненти системи 
обмінюються повідомленнями, забезпечуючи коректну роботу чат-бота і 
управлінням базою знань. 
Послідовність кроків, враховуючи компоненти та дії: 
1 login(): користувач виконує авторизацію в системі через Slack, 
використовуючи будь-який зручний авторизаційний провайдер, ініціюючи процес 
входу.  
2 sendUserInfo(): авторизаційний провайдер повертає інформацію про 
користувача до чат-бота. 
3 submitQuery(): користувач через чат-бот надсилає текстовий запит на 
пошук інформації. 
4 processUserRequest(): чат-бот обробляє запит і передає його до NLP-
моделі для аналізу. 
 67 
ЧДТУ 242313.001 ПЗ 
5 analyzeText(): NLP-модель аналізує текст запиту для визначення 
ключових слів, контексту і пошукових параметрів, розбираючи користувацьку 
мову. 
6 search(): RAG надсилає запит до пошукової системи для знаходження 
релевантного контексту. 
7 getDocuments(): пошукова система звертається до бази знань для 
отримання релевантних документів чи даних у вигляді чанків з метаданими. 
8 searchContext(): пошукова система повертає отриманий контекст до 
RAG для подальшої генерації промпту і генерації відповіді. 
9 genResponse(): NLP-модель на основі контексту формує текст 
відповіді. 
10 showResults(): чат-бот надсилає сформовану відповідь користувачеві. 
11 login(): адміністратор виконує авторизацію в системі та подібно 
користувачу, провайдер аутентифікації повертає інформацію про людину 
sendUserInfo(). 
12 viewUsageAnalytics(): адміністратор переглядає аналітику 
використання системи, переглядає логи та користувацькі запити і відповіді від 
бота. 
13 edit/updateDocuments(): адміністратор вносить зміни до бази знань, 
додаючи, редагуючи або видаляючи інформацію. 
Діаграма комунікації наочно демонструє, як взаємодіють ключові 
компоненти системи для забезпечення її основних функцій. Вона показує, як 
користувач надсилає запити через чат-бот, які передаються до NLP-моделі, 
пошукової системи та бази знань для отримання релевантної відповіді. Окрім 
цього, адміністратора включено до процесу для оновлення та підтримки бази 
знань, а також для аналізу статистики використання через модуль аналітики. Для 
цього передбачено окрему частину API, що захищена ролями і надає доступ лише 
адміністраторам. 
Діаграма ілюструє не лише основний сценарій взаємодії користувача із 
системою,  але  й  дії  адміністратора,  що забезпечують підтримку актуальності 
 68 
ЧДТУ 242313.001 ПЗ 
даних у базі знань. 
 
 
Рис. 3.12 – Діаграма комунікації 
 
3.4.4 Діаграма скінченного автомату 
Діаграмою скінченного автомату буде відображено поведінку UI. Діаграма 
скінченного автомата на рисунку 3.13 моделює процес взаємодії звичайного 
користувача з чат-ботом у Slack-чаті, починаючи з входу в чат, і до завершення 
сесії. Стан переходів та їх дії визначені наступним чином: 
 69 
ЧДТУ 242313.001 ПЗ 
Рис. 3.13 – Діаграма скінченного автомату. Взаємодія користувач з системою 
 
Стан «Користувач заходить у чат» - це початковий стан, до якого користувач 
повинен увійти у систему підтвердивши свою особистість. Стан, в якому 
користувач починає взаємодію з чат-ботом, заходячи до Slack-чату. 
Стан «Очікування запиту». У цьому стані система очікує, поки користувач 
введе запит. Аби змінити стан, користувач вводить текст у чат. 
Стан «Обробка запиту». Запит передається на обробку до RAG API та 
системи генерації відповіді. 
Стан «Надання відповіді». У цьому стані користувач отримує відповідь на 
свій запит та стан повертається до «Очікування запиту» для нового циклу, якщо 
користувач бажає продовжити. 
Цикл взаємодії завершується, і система припиняє очікування нових запитів. 
Особливостями діаграми є петля запитів. Користувач може надсилати 
декілька запитів, залишаючись у циклі між станами «Очікування запиту», 
«Обробка запиту» та «Надання відповіді». 
Завершення сесії чітко окреслено і є моментом, коли користувач виходить з 
чату. 
Діаграма скінченного автомата для взаємодії користувача з чат-ботом у Slack  
 70 
ЧДТУ 242313.001 ПЗ 
відображає цикл роботи системи на стороні клієнта, забезпечуючи 
структурований підхід до опису поведінки чат-бота та його реакцій на дії 
користувача. Вона підкреслює, як система реагує на дії користувача, забезпечує 
відповідь або обробляє помилки, а також завершує роботу після виходу 
користувача з чату. 
Діаграма скінченного автомата на рисунку 3.14 моделює процес взаємодії 
адміністратора з чат-ботом у Slack, що відрізняється від взаємодії звичайного 
користувача завданнями та функціями. Зокрема, адміністратор не просто вводить 
запити, а займається оновленням бази знань через завантаження текстових файлів. 
Основна дія адміністратора – це завантаження файлів для оновлення бази знань, 
тоді як користувач лише вводить запити та отримує відповіді. Розраховується, що 
підготовка файлів для завантаження у бот є обовʼязком адміністратора та 
належить до його обовʼязків. Усі помилки, що будуть допущені у документації 
наданої адміністратором, є провиною адміністратора, а не системи. 
 
Рис. 3.14 – Діаграма скінченного автомату. Взаємодія адміністратора з системою 
 
З діаграм видно, що взаємодія з системою чи то адміністратором, чи то 
користувачем дуже проста. Усі стани, які були описані, є тими станами, які мають 
кожен Messager в наш час. Вся взаємодія системи зводиться до роботи з чатом у 
програмному забезпеченні Slack. 
 71 
ЧДТУ 242313.001 ПЗ 
Висновок до третього розділу 
Розділ моделювання системи забезпечує комплексне уявлення про 
структуру, поведінку та взаємодію компонентів інтелектуального програмного 
агента для пошуку інформації у чат-боті. В результаті моделювання були 
побудовані діаграми, що охоплюють ключові аспекти розроблюваної системи: її 
компоненти, пакети, класи, процеси обміну даними, сценарії використання та 
основні взаємодії між користувачами, адміністраторами та системою. 
Моделювання дозволило не лише деталізувати архітектуру системи, але й 
продемонструвало її поведінку у різних сценаріях роботи. Завдяки цьому стало 
можливим зрозуміти, як користувачі та адміністратори взаємодіють із системою, 
як відбувається пошук релевантного контексту, оновлення бази знань, генерація 
відповідей, а також забезпечення стабільної роботи компонентів у реальному 
середовищі. Проведена робота стала основою для подальшої реалізації системи, 
дозволяючи мінімізувати ризики розробки, підвищити її ефективність і 
відповідність вимогам. 
  
 72 
ЧДТУ 242313.001 ПЗ 
РОЗДІЛ 4 КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
4.1 Розробка програмного комплексу 
4.1.1 Обґрунтування вибору засобів реалізації 
Для реалізації системи було обрано мову програмування Python та векторну 
базу даних ChromaDB, оскільки вони повністю відповідають як функціональним, 
так і нефункціональним вимогам. Python є універсальною мовою програмування, 
яка широко використовується в галузі обробки природньої мови та машинного 
навчання. Завдяки багатій екосистемі бібліотек, таких як transformers, scikit-learn, 
langchain і багатьом іншим, Python спрощує інтеграцію NLP-моделей, реалізацію 
RAG-систем і роботу з великими даними. Його модульність та підтримка 
мікросервісної архітектури дозволяють легко масштабувати систему, що важливо 
для забезпечення стабільної роботи при збільшенні кількості користувачів або 
розширенні бази знань [40]. 
ChromaDB було обрано як основу для векторного пошуку завдяки її високій 
швидкодії, підтримці масштабованості та зручності інтеграції з Python. Ця база 
даних дозволяє зберігати великі обсяги векторних репрезентацій даних і швидко 
виконувати пошук релевантного контексту, що особливо важливо для реалізації 
RAG (retrieval-augmented generation). Крім того, ChromaDB підтримує гнучкі 
методи додавання та оновлення даних, що відповідає функціональним вимогам до 
системи, зокрема підтримці API для адміністративних задач. 
Можливі альтернативи та їхні недоліки. 
Мова програмування: 
– JavaScript/Node.js [41]. Популярна мова для веб-розробки, але її 
екосистема для обробки NLP та векторного пошуку менш розвинена, ніж 
у Python. Реалізація RAG-системи була б складнішою та менш 
ефективною; 
– Java. Мова забезпечує високу продуктивність, але її використання для 
NLP або інтеграції з сучасними бібліотеками (як-от HuggingFace [42]) 
 73 
ЧДТУ 242313.001 ПЗ 
значно складніше через обмежену екосистему; 
– C++. Висока продуктивність і контроль над ресурсами, але значна 
складність у розробці та довгий час реалізації роблять її менш 
придатною для створення систем RAG. 
База даних для векторного пошуку: 
– Pinecone. Високопродуктивний сервіс для векторного пошуку, але його 
використання є платним, що є недоліком для старту розроблюваного 
проєкту з обмеженим бюджетом; 
– Weaviate. Потужна альтернатива з відкритим вихідним кодом, але 
вимагає більш складної конфігурації для інтеграції та розгортання в 
локальному середовищі; 
– FAISS від Facebook. Популярна бібліотека для векторного пошуку, проте 
вона більше підходить для локального використання й не має вбудованих 
можливостей для масштабування та інтеграції з API, як ChromaDB. 
Обрані Python і ChromaDB надають збалансоване рішення для розробки 
системи, яка потребує обробки природної мови, високої швидкодії та 
масштабованості, що робить їх оптимальним вибором для реалізації вимог 
проєкту. 
FastAPI було обрано як основний бекенд-фреймворк для обробки запитів від 
Slack завдяки його швидкості, простоті використання та відповідності вимогам 
проєкту. FastAPI дозволяє створювати сучасні RESTful API з підтримкою 
асинхронної архітектури, що забезпечує високу продуктивність навіть під 
високими навантаженнями [43]. Його ключові переваги в контексті проєкту 
включають: 
Переваги FastAPI для даної системи: 
– швидкодія. FastAPI побудовано на базі Starlette (для веб-фреймворку) та 
Pydantic (для валідації даних), що забезпечує асинхронну обробку 
запитів і максимальне використання апаратних ресурсів. Це особливо 
важливо для реалізації нефункціональної вимоги швидкодії, оскільки 
дозволяє обробляти численні запити від Slack без затримок; 
 74 
ЧДТУ 242313.001 ПЗ 
– простота та гнучкість у розробці. FastAPI підтримує автоматичну 
генерацію документації (Swagger UI та ReDoc), що спрощує взаємодію з 
API для адміністратора та розробників. Це відповідає нефункціональній 
вимозі 
прозорості та зручності використання; 
– масштабованість. Архітектура FastAPI дозволяє легко інтегрувати 
мікросервіси, розділяючи систему на незалежні модулі. Це відповідає 
вимозі масштабованості, оскільки дозволяє обробляти зростаючу 
кількість запитів і розширювати функціональність системи без значних 
зусиль; 
– валідація та типізація даних: Завдяки інтеграції з Pydantic, FastAPI 
забезпечує валідацію вхідних даних «на льоту», що дозволяє 
мінімізувати помилки під час взаємодії з Slack API. Це також підвищує 
надійність і захищеність системи; 
– асинхронність. Використання асинхронного програмування дозволяє 
одночасно обробляти кілька запитів, що критично для ефективної роботи 
RAG API, коли потрібно виконувати кілька пошукових і генеративних 
завдань паралельно; 
– сумісність. FastAPI легко інтегрується з іншими бібліотеками Python, 
такими як ChromaDB і фреймворками для роботи з NLP-моделями, що 
робить його ідеальним вибором для RAG-системи. 
Альтернативи та їхні недоліки. Як альтернатива FastAPI розглядається лише 
один фреймворк – Flask. Flask є популярним і легким фреймворком, але не 
підтримує асинхронність «із коробки». У порівнянні з FastAPI, Flask потребує 
додаткових модулів для забезпечення сучасного рівня продуктивності й 
масштабованості, що ускладнює реалізацію вимоги швидкодії. 
FastAPI є найкращим вибором для реалізації бекенду системи, оскільки він 
забезпечує високу швидкодію, простоту в розробці, зручну інтеграцію з 
існуючими інструментами та відповідність усім функціональним і 
нефункціональним вимогам проєкту. У поєднанні з Python та ChromaDB, FastAPI 
 75 
ЧДТУ 242313.001 ПЗ 
дозволяє створити надійну й ефективну систему, яка легко масштабується й 
забезпечує прозорість роботи для 
кінцевих користувачів та адміністратора. 
Для надання користувачам UI було обрано Slack. Slack є потужною 
платформою для корпоративного спілкування, яка надає готову екосистему для 
інтеграції чат-ботів. Його використання для реалізації користувацького інтерфейсу 
забезпечує низку 
переваг у порівнянні з розробкою власного UI на основі HTML, CSS та JavaScript. 
Недоліки Slack у порівнянні з власним UI: 
– Slack є сторонньою платформою, що обмежує повний контроль над 
користувацьким досвідом. Власний UI може бути кастомізований до 
дрібниць; 
– Slack не підходить для користувачів, які не мають облікового запису в 
системі, тоді як власний UI може бути доступний для будь-якого веб-
користувача. 
Мінуси створення власного UI на HTML, CSS і JavaScript: 
– час розробки; 
– простота використання може бути ускладнена та неінтуїтивна за рахунок 
поганого дизайну; 
– складна інтеграція в порівнянні зі Slack Bot API; 
– вимагає додаткової роботи над забезпеченням безпеки системи; 
– усі інструменти по роботі з повідомленнями необхідно розробляти з 
нуля, що вимагає велике вкладення грошей та часу; 
– високі виктрати на розробку, що включають і розробку UI/UX, і 
інтеграцію з бекенд частиною, і підтримка та розширення проекту в 
майбутньому. 
Саме тому Slack ідеально підходить для реалізації системи користувацького 
інтерфейсу чат-бота завдяки швидкій розробці, низьким витратам, готовій 
інфраструктурі та інтеграції в існуючі бізнес-процеси. Хоча створення власного UI 
 76 
ЧДТУ 242313.001 ПЗ 
могло б надати більшу гнучкість у дизайні та доступності, це значно підвищило б 
вартість і складність розробки, що суперечить вимогам проєкту. 
4.1.2 Опис структурної та функціональної схем 
Для опису структурної та функціональної схеми буде застосовано графічне 
зображення схем. На рисунку 4.1 показано значення елементів схеми. 
 
 
Рис. 4.1 – Основні графічні символи для опису функціональної схеми: а) процес, 
підсистема; б) ручне введення; в) пристрій пам’яті з прямим доступом; г) дисплей; 
д) документ 
 
Структурна схема (рис. 4.2) відображає ключові підсистеми та їх зв'язки в 
рамках реалізації інтелектуального програмного агента для пошуку інформації у 
чат-боті на базі Slack. Основу системи складає програмний агент, який взаємодіє з 
різними модулями для забезпечення функціональності, визначеної вимогами. 
 
 
Рис. 4.2 – Структурна схема 
 77 
ЧДТУ 242313.001 ПЗ 
– система Slack забезпечує інтерфейс користувача для взаємодії з чат-
ботом, а також підтримує функції авторизації користувачів через систему 
авторизації; 
– система чат-боту є посередником між користувачем і програмним 
агентом. Її завдання – отримувати запити користувачів і передавати їх у 
програмний агент. 
– програмний агент - основний модуль, який обробляє запити, взаємодіє з 
іншими підсистемами; 
– система RAG - забезпечує пошук релевантного контексту у базі знань, 
формує промпт до LLM та оброблює пошукові запити; 
– підсистема ChromaDB – використовується, як векторна база даних для 
зберігання та швидкого пошуку структурованої інформації; 
– підсистема метаданих і підсистема чанкування тексту відповідають за 
попередню обробку даних і формування інформативних блоків із 
контекстом; 
– система Chat GPT використовується для генерації текстових відповідей 
на основі отриманого промпту від RAG; 
– підсистема обробки документів Slack дозволяє адміністраторам 
оновлювати базу знань за допомогою завантаження нових текстових 
документів; 
– система логування забезпечує журналювання запитів і операцій для 
діагностики й оптимізації. 
Розроблена структурна схема демонструє комплексний підхід до 
моделювання інтелектуального програмного агента. Її архітектура є модульною та 
легко розширюваною, що дозволяє масштабувати систему без значних витрат. 
Вибір Slack як платформи для взаємодії з користувачами та адміністрування 
забезпечує швидке впровадження інтерфейсу, а інтеграція з ChromaDB та NLP-
моделлю GPT гарантує точність і релевантність відповідей. 
Функціональна схема (рис. 4.3) відображає основні потоки даних і взаємодії 
між компонентами системи для реалізації її ключових функцій. Система умовно 
 78 
ЧДТУ 242313.001 ПЗ 
поділена на два основні процеси: процес взаємодії користувача із системою та 
процес наповнення та адміністрування бази знань. 
Процес взаємодії користувача із системою має наступні функції: 
– вхід у систему. Користувач авторизується. Авторизація інтегрована із 
Slack, що дозволяє автоматично ідентифікувати користувачів; 
– система чатів. Після авторизації користувач отримує доступ до системи 
чатів, через яку передає запит чат-боту; 
– система програмного агента. Чат-бот надсилає отриманий запит до 
програмного агента, який є основним обробником інформації. Агент 
працює з такими підсистемами: система RAG для пошуку релевантного 
контексту у базі знань; система Chat GPT, яка на основі отриманого 
контексту формує текстову відповідь; база знань; підсистема ChromaDB; 
підсистема метаданих і чанкування тексту; 
– результат пошуку. Згенерована відповідь надсилається користувачеві 
через систему чатів, забезпечуючи зручність та швидкість комунікації. 
 
 
Рис. 4.3 – Функціональна схема  
 79 
ЧДТУ 242313.001 ПЗ 
Процес наповнення та адміністрування бази знань: 
– наповнення бази знань. Адміністратор через Slack завантажує нові 
документи чи оновлює існуючі; 
– обробка даних. Завантажені документи обробляються через підсистему 
чанкування тексту й метаданих, що дозволяє оптимально інтегрувати 
нову інформацію в базу знань; 
– збереження даних. Після обробки дані зберігаються в ChromaDB для 
ефективного подальшого використання. 
Обидва сценарія передбачають відображення історії чату. Адміністратор або 
користувачі можуть переглядати історію чатів для аналізу своїх запитів та для 
існування контексту переписки з чат-ботом. 
Запропонована функціональна схема демонструє логіку роботи системи, яка 
відповідає її функціональним і нефункціональним вимогам. 
4.1.3 Опис логічної схеми системи 
Система поділяється на два основних алгоритми: алгоритм взаємодії 
користувача та алгоритм адміністрування бази знань. 
Алгоритм взаємодії користувача. 
Першим етапом роботи користувача з системою є авторизація. Користувач 
заходить у Slack-чат і проходить перевірку через інтегровану систему авторизації. 
Якщо авторизація пройшла успішно, йому надається доступ до функціоналу чат-
бота. У разі невдачі користувач отримує повідомлення про помилку авторизації. 
Після входу до системи користувач повинен підключити або додати до свого 
робочого простору у Slack відповідний чат-бот. Після чого він може розпочати 
формування текстового запиту і відправити його через систему чатів бота. Запит 
передається до системи чат-ботів, яка, у свою чергу, направляє його до системи 
програмного агента. Програмний агент відповідає за обробку запиту. Він спочатку 
передає його до системи RAG, яка здійснює пошук релевантної інформації в базі 
знань. 
База знань складається з декількох компонентів. Основою є ChromaDB, яка 
забезпечує швидкий пошук даних у векторному просторі. Для підвищення 
 80 
ЧДТУ 242313.001 ПЗ 
точності відповіді використовуються підсистеми чанкування тексту та підсистеми 
метаданих. Вони розбивають дані на структуровані частини й додають контекст 
для покращення релевантності. 
Якщо система RAG успішно знаходить дані, вони передаються до системи 
LLM, в роботі буде використано Chat GPT, яка формує відповідь на основі 
отриманої інформації. У разі неможливості знайти відповідь користувачеві 
повідомляється про недостатність контексту по заданому запитанню. Сформована 
відповідь надсилається назад до системи чатів і відображається користувачеві в 
історії чату з ботом. Після отримання відповіді користувач може сформувати 
новий запит або завершити сесію. 
Алгоритм адміністрування бази знань. 
Робота адміністратора також починається з авторизації. Він входить у Slack і 
проходить перевірку через систему авторизації. У разі успіху адміністратор 
отримує доступ до функцій оновлення бази знань. 
Для додавання нових даних адміністратор передає текстовий файл через 
інтерфейс Slack-бота. Файл приймається системою чатів і направляється до 
системи програмного агента. Програмний агент передає отримані дані до 
підсистеми чанкування тексту, яка розбиває їх на структуровані частини - чанки. 
Потім дані обробляються підсистемою метаданих, яка додає контекстну 
інформацію, таку як тематика чи категорія. 
Оброблені дані інтегруються в ChromaDB, яка є основною базою знань для 
пошуку інформації. Після успішного завершення процесу адміністратор отримує 
повідомлення про результат завантаження. У разі виникнення помилок, таких як 
некоректний формат файлу, адміністратор отримує відповідну відповідь у вигляді 
Slack-реакції на повідомлені з прикріпленими файлами, а у треді до повідомлення 
він зможе знайти опис проблеми. 
Після завершення оновлення бази знань адміністратор може продовжити 
завантаження нових даних, поставити запитання боту, як звичайний користувач 
або завершити свою роботу. 
4.1.4 Розробка бази даних 
 81 
ЧДТУ 242313.001 ПЗ 
У проекті для організації та зберігання даних використано векторну базу 
даних ChromaDB. Цей вибір обумовлений необхідністю забезпечити швидкий 
доступ до даних та ефективну роботу пошукової системи. 
Особливістю векторної бази даних є те, що вона дозволяє зберігати та 
обробляти дані у вигляді векторів, що значно підвищує швидкість і точність 
пошуку релевантної інформації. Такий підхід є оптимальним для роботи з 
великими обсягами текстових даних та забезпечення підтримки обробки 
природної мови. 
Оскільки структура векторної бази даних є досить специфічною і 
генерується автоматично під час роботи підсистем (наприклад, при чанкуванні 
тексту та додаванні метаданих), її детальний опис не є необхідним у контексті цієї 
роботи. Усі процеси створення векторів, зберігання та пошуку даних інтегровані у 
функціональну логіку ChromaDB і реалізовані в рамках існуючого програмного 
забезпечення. 
4.1.5 Розробка інтерфейсу користувача 
У рамках розробки системи як інтерфейс користувача використовується 
платформа Slack. Slack є одним із провідних інструментів для командної 
комунікації, який забезпечує гнучкий і зручний інтерфейс для взаємодії з чат-
ботом. Це рішення дозволяє зосередитися на розробці функціональної частини 
системи без необхідності створення окремого користувацького інтерфейсу з нуля, 
що суттєво економить ресурси проєкту. 
Можливості інтерфейсу Slack. Slack надає ряд інструментів, які 
використовуються для забезпечення інтерактивності та зручності: 
– чат для введення запитів (рис. 4.4); 
– відображення відповідей: бот надає відповіді у вигляді повідомлень, що 
можуть містити текст, посилання або вкладення. На рисунку 4.4 
продемонстровано відповідь чат-бота; 
– файли та вкладення: адміністратори, можуть завантажувати текстові 
файли до чату для обробки ботом (рис. 4.5); 
 82 
ЧДТУ 242313.001 ПЗ 
– інтерактивні кнопки та меню: у відповідях можуть бути інтерактивні 
елементи для зручного вибору варіантів або виконання дій; 
– статус обробки у вигляді реакцій на повідомлення (рис. 4.5): бот  
повідомляє завершення обробки або помилки у випадках, коли запит 
потребує втручання адміністратора; 
 
 
Рис. 4.4 – Інтерфейс Slack. Сторінка чат-бота 
 
 
Рис. 4.5 – Інтерфейс Slack. Чат з ботом, завантажені та оброблені 
файлові ресурси 
 83 
ЧДТУ 242313.001 ПЗ 
– журнал історії чату також продемонстровано на рисунку 4.5: користувачі 
мають змогу переглядати попередні повідомлення, що дозволяє зберігати 
контекст розмови. 
Slack забезпечує інтуїтивно зрозумілий і добре продуманий користувацький 
досвід, що дозволяє легко інтегрувати чат-бота та використовувати його 
функціональність. Завдяки цьому підходу система отримує надійний і перевірений 
інтерфейс для користувачів, а розробники можуть сфокусуватися на реалізації 
основної бізнес-логіки. 
4.1.6 Опис розробки програмних компонентів 
Основні реалізовані модулі (рис. 4.6): модуль логування, модуль реалізації 
RAG, модуль бази знань, що включає в себе підсистеми чанкування та метаданих, 
модуль App, що слугує вхідною точкою системи та реалізує API системи, виконує 
відповіді до Slack та займається валідацією запитів REST API. 
 
 
Рис. 4.6 – Файлова структура проєкту на Python 
 
Для логування системи використано зовнішній пакет logging. Для того, аби 
логи були читабельні та систематизовані, було розроблено власний формат логів. 
На рисунку 4.7 продемонстровано клас власного логеру з чітко визначеним 
форматом логів. 
 84 
ЧДТУ 242313.001 ПЗ 
 
 
Рис. 4.7 – Клас логеру. Формат логів  
 
На рисунку 4.8 продемонстровано реалізацію методів «create_prompt» та 
 «call_llm». Методи відповідають за формування промпту та відправки запиту до 
LLM моделі. Промпт спеціальним чином задає відомості про те, що питається, 
яким чином обмежуються рамки відповіді та звідки брати інформацію. Це є 
основним чинником правильної роботи RAG системи. Адже саме промпт формує 
правильне звернення до LLM, яка отримавши його буде слідувати указаним у 
ньому вимогам та правилам. 
 
 
Рис. 4.8 – Реалізація методів формування промпту до LLM 
 85 
ЧДТУ 242313.001 ПЗ 
Модулі Storage та App містять відповідно обробку збереженої у векторній 
базі даних інформації та запитів від користувачів. 
Модуль Storage має декілька сталих змінних, налаштування яких може грати 
вирішальну роль у точності відповідей. Серед яких наступні змінні зі значеннями: 
– MAX_CHARS_PER_CHUNK = 150, визначає розмір чанка у символах; 
– SIMILARITY_THRESHOLD = 0.4, визначає поріг відсіювання контексту. 
Все, що має неточність більшу за задану буде відсіяно алгоритмом;  
– DISTAHCE_FUNCTION = 'ip' # l2, ip, cosine. l2 by defaulte. Значення 
задає тип алгоритму для семантичного пошуку; 
– CHROMA_PERSIST_DIR = os.path.join(os.getcwd(), 'chroma_db') – шлях 
до файлів бази даних. 
Таким чином реалізація серверної частини має модульну архітектуру, 
вирішує усі поставлені функціональні та нефункціональні вимоги та надає весь 
вимагаємий функціонал. 
4.2 Тестування системи 
4.2.1 Модульне тестування 
Для тестування проєкту було обрано підхід модульного тестування з 
використанням бібліотеки pytest, яка забезпечує зручний і гнучкий інструментарій 
для написання тестів. Були створені юніт-тести для перевірки ключових модулів 
системи, таких як log_utils, storage та rag. Це дозволило перевірити коректність 
роботи методів на окремих етапах функціонування системи та забезпечити високу 
якість реалізації. 
Тестові файли в pytest мають певну структуру назви. Вони повинні 
починатись зі слова «test_». Розміщення при такому найменуванні не грає ролі, 
адже pytest виконує пошуку по назві файлів. Для зручності, усі тести (файли 
тестів) були розміщені у папочці tests. Для перевірки тестів необхідно в root 
папочці проєкту викликати команду «pytest tests/», яка застосована до конкретної 
папки tests [44]. 
На рисунку 4.9 вигляд ініціалізації тестів. Тестуємий модуль storage. На  
 86 
ЧДТУ 242313.001 ПЗ 
рисунку показана тестова функція. 
 
 
Рис. 4.9 – Тестовий сценарій модуля бази знань  
 
Створюється екземпляр обʼєкту класу модуля, який потім буде переданий 
параметром до тест-функцій.  
Результати тестування, це створені тестові сценарії для усіх основних 
модулів системи. Усі тести успішно проходять виклик, що показано на рисунку 
4.10.  
 
 
Рис. 4.10 – Результат виклику тестів системи  
 87 
ЧДТУ 242313.001 ПЗ 
Усі створені тести було виконано успішно, що підтвердило коректність 
роботи основних модулів системи. Це свідчить про відповідність реалізації 
поставленим вимогам та забезпечує надійність функціонування проєкту. 
4.2.2 Інтеграційне тестування 
В даному проєкті здійснюється інтеграція зі сторонніми сервісами. Так, 
здійснена інтеграція зі сервісом Slack. Для того, аби мати можливість отримувати 
події та можливість на ці події здійснити «підписку», команда розробників Slack 
реалізувала механізм вебхуки (від англ. webhooks).  
Вебхуки – це механізм, що дозволяє автоматично передавати дані між 
сервісами у відповідь на певні події. Для інтеграції системи зі Slack було 
використано вебхуки, які забезпечують обмін інформацією між чат-ботом та 
платформою. Завдяки цій інтеграції система отримує запити користувачів зі Slack і 
надсилає сформовані відповіді безпосередньо до чату. Наразі проводиться 
тестування цього функціоналу, щоб переконатися у стабільності передачі даних і 
відповідності інтеграції поставленим вимогам. 
Для здійснення тестування, система розгортається та запускається. Адреса 
сервера, на якому розгорнуто систему повинна бути задана у Slack. Для цього 
використовується адмін сторінка налаштувань чат-бота (рис. 4.11).  
Щоб перевірити, чи правильно здійснено інтеграцію, вебсторінка відправить 
запит з параметром на вказану адресу, на вказаний ендпоїнт. Наданий параметр 
повинен бути повернутий системою, в інакшому випадку тест буде провалено.  
На рисунку 4.11 тест успішно пройдено, про що свідчить «Verified» слово з 
зеленою галочкою. 
Тестування інтеграції зі Slack показало успішну роботу вебхуків. Всі запити 
користувачів коректно передаються до системи, а відповіді формуються та 
надсилаються до чату без затримок чи помилок. Це підтверджує стабільність і 
надійність інтеграції, що відповідає поставленим вимогам до функціональності 
системи. 
 
 88 
ЧДТУ 242313.001 ПЗ 
 
Рис. 4.11 – Задання адреси сервера для інтеграції зі Slack webhooks 
 
4.2.3 Системне тестування 
Системне тестування було проведено з метою перевірки роботи всієї 
системи в умовах, максимально наближених до реального використання. Для 
цього були залучені заздалегідь визначені тестові користувачі, які виконували 
сценарії взаємодії із системою через інтерфейс Slack. Користувачі тестували 
основні функціональні можливості системи: надсилання запитів до чат-бота, 
отримання відповідей, а також внесення змін до бази знань через 
адміністративний інтерфейс. Особливу увагу приділили коректності відповідей, 
швидкості їх отримання та зручності роботи з інтерфейсом. 
За результатами тестування всі користувачі залишилися задоволені роботою 
системи. Вони відзначили зручність Slack як інтерфейсу взаємодії та інтуїтивність 
процесу надсилання запитів і отримання результатів. Також було підтверджено, 
що час обробки запитів відповідає вимогам, а функціональність системи 
відповідає поставленим цілям. 
Під час проведення опитування після тестування користувачі відзначили 
високу точність відповідей, що генеруються системою. Зокрема, система 
продемонструвала здатність надавати релевантні відповіді навіть для складних 
запитів. Це підтверджує, що використання векторної бази даних ChromaDB у 
 89 
ЧДТУ 242313.001 ПЗ 
поєднанні з моделлю RAG є ефективним рішенням для забезпечення точності та 
швидкодії. 
Таким чином, результати системного тестування показали, що система 
відповідає всім заявленим функціональним і нефункціональним вимогам. Вона 
готова до використання в реальних умовах і здатна забезпечити якісний 
користувацький досвід.  
4.2.4 Приймальне тестування 
Приймальне тестування системи проводилося після розгортання додатка на 
публічному сервері. З цього моменту система була доступною для тестування в 
умовах реального використання. Процес інтеграції чат-бота в робочий процес був 
максимально простим: для початку роботи достатньо увійти в Slack під власним 
обліковим записом, додати бота до робочого простору (workspace) і почати 
взаємодію із системою. 
Під час тестування було перевірено всі основні сценарії використання, 
включаючи відправлення запитів до бота, отримання відповідей, а також 
оновлення бази знань через завантаження текстових файлів. Загалом система 
продемонструвала стабільну роботу, відповідність функціональним вимогам і 
зручність використання. 
Однак під час тестування було виявлено один важливий недолік: 
обмеженість підтримуваних форматів файлів для оновлення бази знань. На даний 
момент система дозволяє додавати нову інформацію лише через текстові файли у 
форматі «.txt». Це створює незручності для адміністратора, оскільки часто 
інформація зберігається в інших форматах, таких як «.pdf», «.docx», або «.csv». 
Розширення функціоналу системи для підтримки більшої кількості текстових 
форматів суттєво підвищило б її зручність і ефективність. 
Приймальне тестування засвідчило, що додаток готовий до використання, 
але виявило потенціал для подальшого вдосконалення. Модернізація функціоналу 
роботи з різними форматами файлів стане наступним кроком у розвитку системи. 
4.3 Приклади впровадженого програмного комплексу 
 90 
ЧДТУ 242313.001 ПЗ 
Щоб продемонструвати систему в дії, що весь функціонал доступний та 
працює, необхідно створити акаунт Slack. Після створення акаунту, увійти в нього 
та створити свій перший робочій простір.  
Slack workspace (рис. 4.12) – це віртуальний простір для командного 
спілкування та співпраці, створений на платформі Slack. Він об'єднує всі канали, 
облікові записи користувачів і ресурси, необхідні для роботи над проектами або 
управління організацією [45]. 
 
 
Рис. 4.12 – Slack workspace під назвою «diploma-project» 
 
Основна мета workspace – забезпечити зручне спільне середовище для 
обміну повідомленнями, файлом, інтеграції з іншими інструментами (наприклад, 
 91 
ЧДТУ 242313.001 ПЗ 
Google Drive, Trello або власними API), а також автоматизації рутинних завдань 
через ботів і додатки. Це допомагає покращити командну взаємодію, підвищити 
продуктивність і знизити потребу в тривалих email-листуваннях [45]. 
Далі необхідно до створеного простору додати розробленого чат-бота. Чат-
бот опубліковано в спільний доступ під назвою «requirements-rag». Чат бот можна 
легко знайти у пошуку серед інших додатків (чат-ботів, адже в Slack вони звуться 
applications) (рис. 4.13) [45].  
Після додавання бота до робочого простору, можна починати роботу з 
ботом. Взаємодія з чат-ботом у Slack проста та інтуїтивно зрозуміла. Для того щоб 
написати повідомлення чат-боту, користувачу необхідно відкрити особистий чат із 
ботом або додати його до будь-якого каналу, у якому необхідна взаємодія. Далі у 
текстовому полі написати запитання чи ключові слова та натиснути клавішу 
«Enter», щоб відправити повідомлення. Чат-бот обробить запит і поверне 
відповідь.   
Процес додавання текстового файлу для наповнення бази знань також 
максимально спрощений: 
 
 
Рис. 4.13 – Розроблений чат-бот серед списку інших додатків 
 92 
ЧДТУ 242313.001 ПЗ 
 
Рис. 4.14 – Взаємодія з чат-ботом. Приклад роботи з системою  
 
1 Увійти до облікового запису адміністратора Slack. 
2 Перейти до чату із чат-ботом. 
3 Завантажити текстовий файл через опцію «Прикріпити файл» (іконка 
скріпки або відповідна кнопка в інтерфейсі). 
4 Чат-бот обробить завантажений файл, автоматично інтегрує 
інформацію з нього в базу знань і поставить реакцію у вигляді 
«:white_check_mark:» про успішне оновлення або «:red_circle:» та напише 
помилку в разі невдачі. 
Ці кроки забезпечують простий та зрозумілий інтерфейс для взаємодії з 
системою як для звичайних користувачів, так і для адміністратора (рис. 4.14). 
 93 
ЧДТУ 242313.001 ПЗ 
Висновок до четвертого розділу 
У розділі детально розглянуто основні аспекти роботи інтегрованої системи. 
Було надано приклади інтерфейсу системи, які демонструють простоту та 
зручність використання чат-бота в Slack, як для звичайних користувачів, так і для 
адміністратора. Описано принцип взаємодії із системою, включаючи надсилання 
запитів користувачами та оновлення бази знань за допомогою текстових файлів. 
Розділ дозволяє наочно переконатися у функціональності та практичності 
реалізованого програмного комплексу, підтверджуючи його відповідність 
поставленим вимогам і зручність у використанні.  
 94 
ЧДТУ 242313.001 ПЗ 
ЗАГАЛЬНІ ВИСНОВКИ 
В рамках кваліфікаційної роботи магістра було досліджено питання 
створення інтелектуального програмного агента для пошуку інформації в чат-боті. 
Проблема пошуку релевантної інформації у великих наборах даних актуальна 
через стрімке зростання обсягів інформації, яка потребує обробки в сучасних 
інформаційних системах. Основна складність полягає у забезпеченні високої 
точності відповідей на запити користувачів при одночасному забезпеченні 
гнучкості системи до змін у базі знань. 
Метою роботи було удосконалення способів розробки програмного 
забезпечення пошукових систем шляхом побудови інтелектуального програмного 
агента для пошуку інформації через чат-бота з використанням архітектури 
Retrieval-Augmented Generation. Для вирішення поставленого завдання було 
спроектовано і реалізовано систему з використанням RAG. Інноваційний підхід 
полягав у використанні векторної бази даних ChromaDB для зберігання та пошуку 
релевантних контекстів із бази знань і їх передачі мовній моделі для генерації 
відповідей. Система була інтегрована з платформою Slack, що забезпечило 
готовий і зручний інтерфейс для кінцевого користувача без необхідності 
створення власного UI. Також було розроблено функціонал для адміністратора, що 
дозволяє оновлювати базу знань через текстові файли. 
Практичний аналіз показав високу якість реалізованої системи: система 
успішно обробляє запити користувачів за 5-10 секунд, що відповідає 
нефункціональним вимогам, а адміністративні операції, пов’язані з оновленням 
бази знань, виконуються у прийнятний час. Під час тестування, зокрема 
системного та приймального, було підтверджено точність відповідей, яка 
задовольняє вимоги користувачів. На основі відгуків тестових користувачів було 
визначено, що система є надійною та ефективною для вирішення завдань пошуку 
інформації у базі знань. 
Результати роботи можуть бути застосовані для розробки інформаційних 
систем із подібними вимогами до релевантного пошуку та інтерактивної взаємодії 
користувачів із системою. Наукова новизна полягає у впровадженні метаданих для 
 95 
ЧДТУ 242313.001 ПЗ 
оптимізації контекстуального пошуку, що дозволяє значно покращити точність і 
гнучкість роботи RAG-системи. Практичне значення роботи полягає в успішній 
інтеграції сучасних технологій (LLM, ChromaDB, Slack) для вирішення складної 
задачі. 
Рекомендації щодо подальшого використання результатів також включають 
розширення функціональності системи для обробки запитів інших типів, таких як 
аудіо та фото матеріали. Це дозволить значно підвищити зручність і 
універсальність системи, надаючи користувачам можливість отримувати відповіді 
на основі більш широкого спектру даних. Інтеграція технологій для розпізнавання 
зображень та аудіо, таких як оптичне розпізнавання тексту або автоматичне 
розпізнавання мови, дозволить забезпечити гнучкість і адаптивність системи у 
відповіді на сучасні потреби користувачів. Також система потребує розширення 
підтримуваних форматів даних для оновлення бази знань і розробку додаткових 
функцій для оптимізації роботи адміністратора. Здобуті результати можуть бути 
основою для подальших наукових досліджень у галузі використання мовних 
моделей у задачах інформаційного пошуку. 
  
 96 
ЧДТУ 242313.001 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Elasticsearch [Електронний ресурс] // Офіційна документація 
Elasticsearch – Режим доступу до ресурсу: 
https://www.elastic.co/guide/en/elasticsearch /reference/current/index.html. 
2 Opensearch [Електронний ресурс] // Офіційна документація Opensearch – 
Режим доступу до ресурсу: https://opensearch.org/. 
3 Solr [Електронний ресурс] // Офіційна документація Solr – Режим 
доступу до ресурсу: https://solr.apache.org/. 
4 GPT [Електронний ресурс] // Офіційна документація OpenAI – Режим 
доступу до ресурсу: https://platform.openai.com/docs/overview. 
5 Transformers [Електронний ресурс] // Стаття на Habr – Режим доступу до 
ресурсу: https://habr.com/ru/articles/486358/. 
6 Opensearch Core [Електронний ресурс] // Maven Repository – Режим 
доступу до ресурсу: https://mvnrepository.com/artifact/org.opensearch 
/opensearch-core. 
7 Opensearch dashboard [Електронний ресурс] // Офіційна документація 
Opensearch – Режим доступу до ресурсу: https://opensearch.org/docs/latest 
/dashboards/. 
8 Opensearch plugins [Електронний ресурс] // Офіційна документація 
Opensearch – Режим доступу до ресурсу: https://opensearch.org/docs/1.1 
/opensearch/install/plugins/. 
9 TF-IDF [Електронний ресурс] // Стаття на Habr – Режим доступу до 
ресурсу: https://habr.com/ru/companies/otus/articles/755772/. 
10 BM25 [Електронний ресурс] // Стаття на Habr – Режим доступу до 
ресурсу: https://habr.com/ru/articles/162937/. 
11 Opensearch KNN [Електронний ресурс] // Офіційна документація 
Opensearch – Режим доступу до ресурсу: https://opensearch.org/docs/latest 
/search-plugins/knn/index/. 
 97 
ЧДТУ 242313.001 ПЗ 
12 Sharepoint [Електронний ресурс] // Офіційна сторінка Microsoft – Режим 
доступу до ресурсу: https://www.microsoft.com/en-us/microsoft-
365/sharepoint/collaboration. 
13 Confluence [Електронний ресурс] // Офіційна документація Atlassian – 
Режим доступу до ресурсу: https://www.atlassian.com/software/confluence. 
14 Notion [Електронний ресурс] // Офіційна сторінка Notion – Режим 
доступу до ресурсу: https://www.notion.so/. 
15 Notion vs Confluence [Електронний ресурс] // Порівняння на Atlassian – 
Режим доступу до ресурсу: https://www.atlassian.com/software/confluence 
/comparison/confluence-vs-notion. 
16 ChatGPT landing [Електронний ресурс] // Chatbot App – Режим доступу 
до ресурсу: https://chatbotapp.ai/landing. 
17 Claude [Електронний ресурс] // Офіційна сторінка Claude – Режим 
доступу до ресурсу: https://claude.ai/login. 
18 GPT vs Claude [Електронний ресурс] // Zapier – Режим доступу до 
ресурсу: https://zapier.com/blog/claude-vs-chatgpt/. 
19 Rankbrain [Електронний ресурс] // Стаття на Backlinko – Режим доступу 
до ресурсу: https://backlinko.com/google-rankbrain-seo. 
20 BERT [Електронний ресурс] // Huggingface – Режим доступу до ресурсу: 
https://huggingface.co/docs/transformers/en/model_doc/bert. 
21 Bing [Електронний ресурс] // Офіційна сторінка Bing – Режим доступу 
до ресурсу: https://www.microsoft.com/uk-ua/bing?ep=815&form=MA13S7 
&es=158. 
22 Yahoo [Електронний ресурс] // Офіційна сторінка Yahoo – Режим доступу 
до ресурсу: https://www.yahoo.com/. 
23 Baidu [Електронний ресурс] // Стаття на Wikipedia – Режим доступу до 
ресурсу: https://ru.wikipedia.org/wiki/Baidu. 
24 Neeva [Електронний ресурс] // Офіційна сторінка Neeva – Режим 
доступу до ресурсу: https://www.neevasearchengine.com/. 
 98 
ЧДТУ 242313.001 ПЗ 
25 You.com [Електронний ресурс] // Офіційна сторінка You.com – Режим 
доступу до ресурсу: https://you.com/. 
26 Palm [Електронний ресурс] // Стаття на Google Research – Режим 
доступу до ресурсу: https://research.google/blog/pathways-language-model-
palm-scaling-to-540-billion-parameters-for-breakthrough-performance/. 
27 Google Bard [Електронний ресурс] // Офіційний блог Google – Режим 
доступу до ресурсу: https://blog.google/technology/ai/bard-google-ai-
search-updates/. 
28 RAG [Електронний ресурс] // Winder.ai – Режим доступу до ресурсу: 
https://winder.ai/llm-architecture-rag-implementation-design-patterns/. 
29 RAG [Електронний ресурс] // Jayanth K. Blog – Режим доступу до 
ресурсу: https://blog.jayanthk.in/types-of-rag-an-overview-0e2b3ed71b82. 
30 RAG [Електронний ресурс] // Marktechpost – Режим доступу до ресурсу: 
https://www.marktechpost.com/2024/04/01/evolution-of-rags-naive-rag-
advanced-rag-and-modular-rag-architectures/. 
31 Cosine Similarity [Електронний ресурс] // GeeksforGeeks – Режим 
доступу до ресурсу: https://www.geeksforgeeks.org/cosine-similarity/. 
32 Cosine Similarity [Електронний ресурс] // Towards Data Science – Режим 
доступу до ресурсу: https://towardsdatascience.com/cosine-similarity-how-
does-it-measure-the-similarity-maths-behind-and-usage-in-python-
50ad30aad7db. 
33 Word embeddings [Електронний ресурс] // IBM – Режим доступу до 
ресурсу: https://www.ibm.com/topics/word-embeddings#:~:text=Word% 
20embeddings 
%20capture%20semantic%20relationships,more%20nuanced%20understandi
ng%20of%20language. 
34 Word2Vec [Електронний ресурс] // TensorFlow – Режим доступу до 
ресурсу: https://www.tensorflow.org/text/tutorials/word2vec. 
35 Glove [Електронний ресурс] // Stanford NLP – Режим доступу до ресурсу: 
https://nlp.stanford.edu/projects/glove/. 
 99 
ЧДТУ 242313.001 ПЗ 
36 UML [Електронний ресурс] // Wikipedia – Режим доступу до ресурсу: 
https://en.wikipedia.org/wiki/Unified_Modeling_Language. 
37 Slack [Електронний ресурс] // Офіційна сторінка Slack – Режим доступу 
до ресурсу: https://slack.com/intl/en-gb/. 
38 Webhooks [Електронний ресурс] // Red Hat – Режим доступу до ресурсу: 
https://www.redhat.com/en/topics/automation/what-is-a-webhook. 
39 ChromaDB [Електронний ресурс] // Офіційна сторінка ChromaDB – 
Режим доступу до ресурсу: https://www.trychroma.com/. 
40 Python [Електронний ресурс] // Офіційна сторінка Python – Режим 
доступу до ресурсу: https://www.python.org/. 
41 Node.js [Електронний ресурс] // Офіційна сторінка Node.js – Режим 
доступу до ресурсу: https://nodejs.org/en. 
42 Huggingface [Електронний ресурс] // Офіційна сторінка Huggingface – 
Режим доступу до ресурсу: https://huggingface.co/. 
43 FastAPI [Електронний ресурс] // Офіційна сторінка FastAPI – Режим 
доступу до ресурсу: https://fastapi.tiangolo.com/. 
44 Pytest [Електронний ресурс] // Офіційна документація Pytest – Режим 
доступу до ресурсу: https://docs.pytest.org/en/stable/. 
45 Create Slack workspace [Електронний ресурс] // Slack Help Center – 
Режим доступу до ресурсу: https://slack.com/intl/en-
gb/help/articles/206845317-Create-a-Slack-workspace. 
 
 100 
 
ДОДАТОК А 
 
 ЗАТВЕРДЖЕНО: 
 Зав. кафедри ПЗАС  
 проф.  Голуб С.В. 
 ___________________________ 
 
 
 
 
ПОБУДОВА ІНТЕЛЕКТУАЛЬНОГО ПРОГРАМНОГО АГЕНТА ДЛЯ ПОШУКУ 
ІНФОРМАЦІЇ У ЧАТ-БОТІ 
 
Специфікація 
ЧДТУ.242313-001 ПЗ 
Листів 2 
 
 
Розробник ________________ Архіпов М.О. 
 
Керівник ________________ Заспа Г.О. 
 
Н.Контроль ________________ Півень О.Б. 
 
 
 
 
Черкаси 2024  
 101 
 ЧДТУ.242313-001 ПЗ  2 
Специфікація 
Позначення Найменування Примітка 
482.ЧДТУ.242313-01 12-01 Лістинг програми  
482.ЧДТУ.242313-01 34-01 Інструкція користувача  
482.ЧДТУ.242313-01 90-01 Презентація  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
 102 
 
ДОДАТОК Б 
 
  
 
 
 
ПОБУДОВА ІНТЕЛЕКТУАЛЬНОГО ПРОГРАМНОГО АГЕНТА ДЛЯ ПОШУКУ 
ІНФОРМАЦІЇ У ЧАТ-БОТІ 
 
Лістинг програми 
482.ЧДТУ.242313-01 12-01 
Листів 8 
 
 
 
 
 
Розробник ________________ Архіпов М.О. 
 
 
 
 
 
 
 
 
Черкаси 2024  
 
 482.ЧДТУ.242313-01 34-01   
Текст коду API 
Весь код програми поділено на декілька модулів. Основні з модулів будуть 
надані відповідно до ієрархії у проекті. 
 
app.py 
import time 
from datetime import datetime 
from fastapi import FastAPI, Request 
from slack_sdk import WebClient 
from slack_sdk.errors import SlackApiError 
from fastapi.responses import JSONResponse 
import os 
from dotenv import load_dotenv 
from exceptions.no_context_exception import NoContextFoundException 
from log_utils import CustomLogger 
from project_types.simple_file import SimpleFile 
from rag import Rag 
from storage import Storage 
import threading 
import requests 
 
load_dotenv() 
 
SLACK_BOT_TOKEN = os.getenv('SLACK_BOT_OAUTH_TOKEN') 
log = CustomLogger(__name__) 
app = FastAPI(debug=True) 
slack_client = WebClient(token=SLACK_BOT_TOKEN) 
storage = Storage() 
rag = Rag(storage) 
 
@app.get('/') 
async def slack_events(request: Request): 
    return JSONResponse(content={'Lerrra': 'Trully amaizing'}) 
 
@app.post('/slack/events') 
async def slack_events(req: Request): 
    request = await req.json() 
    log.debug('Request', request) 
 104 
 482.ЧДТУ.242313-01 34-01   
 
    # Handle the challenge request from Slack 
    if 'challenge' in request: 
        log.info("Handling challenge request") 
        return JSONResponse(content={'challenge': request['challenge']}) 
 
    # Check if the event is a message 
    if 'event' in request: 
        event = request['event'] 
        files =  event.get('files') 
        event_type = event['type'] 
        event_subtype = event.get('subtype') 
         
        if event_type == 'message' and 'subtype' not in event: 
            await handle_message_event(event) 
        elif event_type == 'message' and  event_subtype == 'file_share': 
            await handle_files_event(event) 
         
    return JSONResponse(content={'status': 'ok'}) 
 
async def handle_message_event(event): 
    is_bot = isinstance(event.get('bot_id'), str) 
    user = event['user'] 
    user_query = event['text'] 
    channel = event['channel'] 
 
    # Handle if the message is from the bot itself 
    if is_bot: 
        log.info(f"The message has been sent by bot itself. Ignoring") 
        return JSONResponse(content={'status': 'ignored'}) 
 
    log.info(f"Received message from user {user} in channel {channel}") 
 
    def success_callback(answer: dict): 
        # Split answer into things: answer_from_llm and array with metadata 
        answer_from_llm = answer.get('answer_from_llm') 
        chunks = answer.get('chunks', []) 
         
 105 
 482.ЧДТУ.242313-01 34-01   
        # Send answer back to the user 
        slack_client.chat_postMessage(channel=channel, text=answer_from_llm, thread_ts=event['ts']) 
        log.info("Sent answer to user") 
         
        # If metadata exists, send it in an additional message 
        if chunks: 
            metadata_message = "Sources:\n" + "\n".join([ 
                f"```\n" 
                f"File name: {chunk.metadata['file_name']}\n" 
                f"Chunk begin with: {chunk.text[:20]}...\n" 
                f"File url: {chunk.metadata['file_url']}\n" 
                f"Added to the system at: 
{datetime.fromtimestamp(chunk.metadata['created_at']).strftime('%d.%m.%Y %H:%M:%S')}\n" 
                f"```\n" 
                for chunk in chunks 
            ]) 
            slack_client.chat_postMessage(channel=channel, text=metadata_message, thread_ts=event['ts']) 
            log.info("Sent metadata to user") 
 
    def failed_callback(error: str): 
        slack_client.chat_postMessage(channel=channel, text=error, thread_ts=event['ts']) 
        log.info("Sent error to user") 
 
    thread = threading.Thread(target=async_ask_storage, args=(user_query, success_callback, failed_callback)) 
    thread.start() 
 
async def handle_files_event(event): 
    files = event.get('files', []) 
    channel = event['channel'] 
 
    def success_case(answer: str): 
        try: 
            slack_client.reactions_add(channel=channel, name='white_check_mark', timestamp=event['ts']) 
        except SlackApiError as e: 
            log.error(f"Failed to send message: {str(e)}") 
 
    def failed_case(error: str): 
        log.error(f"Failed to process files: {error}") 
 106 
 482.ЧДТУ.242313-01 34-01   
         
        try: 
            slack_client.reactions_add(channel=channel, name='red_circle', timestamp=event['ts']) 
            slack_client.chat_postMessage(channel=channel, text=f"Failed to process files: {error}", 
thread_ts=event['ts']) 
        except SlackApiError as e: 
            log.error(f"Failed to send message: {str(e)}") 
         
    thread = threading.Thread(target=async_files_download, args=(files, success_case, failed_case)) 
    thread.start() 
 
            
def async_ask_storage(user_query: str, success_callback = None, failed_callback = None):  
    try: 
        # Generate a response based on a user query 
        response = rag.ask_storage(user_query) 
        log.info(f"Response from RAG: {response}") 
         
        if success_callback: 
            success_callback(response) 
    except NoContextFoundException as e: 
        log.error(e.message) 
        nothin_found = "Sorry, I couldn't find any context for your question." 
         
        if failed_callback: 
            failed_callback(nothin_found) 
 
def async_files_download(files = [], success_callback = None, failed_callback = None):  
    try: 
        for file in files: 
            file_content = download_file(file) 
            simple_file = simplify_file(file, file_content) 
            storage.add_file(simple_file) 
             
        if success_callback: 
            success_callback('Files processed successfully') 
    except Exception as e: 
        if failed_callback: 
 107 
 482.ЧДТУ.242313-01 34-01   
            failed_callback(e) 
 
def download_file(file) -> str: 
    file_id = file['id'] 
    file_url = file['url_private'] 
    file_name = file['title'] 
    # unique_file_name = f"{round(time.time() * 1000)}_{uuid.uuid4()}.txt" 
    unique_file_name = f"{file_id}.txt" 
    headers = { 
        "Authorization": f"Bearer {SLACK_BOT_TOKEN}" 
    } 
     
    # Download the file 
    file_response = requests.get(file_url, headers=headers) 
 
    if file_response.status_code == 200: 
        file_content = file_response.content 
         
        with open(f"downloads/{unique_file_name}", "wb") as f: 
            f.write(file_content) 
            log.info(f'File {file_name} has been saved as {unique_file_name}') 
 
        log.info('File downloaded sucessfully. File content', file_content) 
 
        return file_content 
    else: 
        log.error("Error downloading file:", file_response.json()) 
        raise Exception("An error occurred while processing the files") 
 
def simplify_file(file_metadata: object, content: str) -> SimpleFile: 
    simple_file = SimpleFile( 
        id=file_metadata["id"], 
        name=file_metadata["name"], 
        value=content, 
        created_at=file_metadata["created"], 
        added_by=file_metadata["user"], 
        url=file_metadata["url_private"], 
    ) 
 108 
 482.ЧДТУ.242313-01 34-01   
    return simple_file 
 
if __name__ == '__main__': 
    import uvicorn 
    uvicorn.run('app:app', host='0.0.0.0', port=3000, reload=True) 
 
 
log_utils.py 
import json 
import logging 
import os 
 
# Create a formatter 
formatter = logging.Formatter('%(asctime)s [%(name)s][%(levelname)s] %(message)s', '%d.%m.%Y 
%H:%M:%S') 
 
class CustomLogger: 
    def __init__(self, name: str): 
        # Set up a logger 
        self.logger = logging.getLogger(name) 
        log_level = self.str_to_level(os.getenv('LOG_LEVEL', 'INFO')) 
        self.logger.setLevel(log_level) 
 
        # File handler for logging to a file 
        file_handler = logging.FileHandler('logs/app.log') 
        file_handler.setFormatter(formatter) 
        self.logger.addHandler(file_handler) 
 
        # Stream handler for logging to console 
        console_handler = logging.StreamHandler() 
        console_handler.setFormatter(formatter) 
        self.logger.addHandler(console_handler) 
 
    def info(self, msg: str, data: any = None): 
        if data: 
            self.logger.info(f"\033[94m{msg}: {self.to_json(data)}\033[0m") 
        else: 
            self.logger.info(f"\033[94m{msg}\033[0m") 
 109 
 482.ЧДТУ.242313-01 34-01   
 
    def error(self, msg: str, data: any = None): 
        if data: 
            self.logger.error(f"\033[91m{msg}: {self.to_json(data)}\033[0m") 
        else: 
            self.logger.error(f"\033[91m{msg}\033[0m") 
 
    def warning(self, msg: str, data: any = None): 
        if data: 
            self.logger.warning(f"\033[93m{msg}: {self.to_json(data)}\033[0m") 
        else: 
            self.logger.warning(f"\033[93m{msg}\033[0m") 
 
    def debug(self, msg: str, data: any = None): 
        if data: 
            self.logger.debug(f"\033[90m{msg}: {self.to_json(data)}\033[0m") 
        else: 
            self.logger.debug(f"\033[90m{msg}\033[0m") 
 
    def to_json(self, data: any) -> str: 
        if isinstance(data, str): 
            try: 
                parsed_data = json.loads(data) 
                return json.dumps(parsed_data, indent=4) 
            except json.JSONDecodeError: 
                return data 
        elif isinstance(data, (dict, list)): 
            return json.dumps(data, indent=4) 
        else: 
            return str(data) 
 
    def str_to_level(self, level_name: str = '') -> int: 
        level_name = level_name.upper() 
 
        if level_name == "CRITICAL" or level_name == "FATAL": 
            return logging.CRITICAL 
        elif level_name == "ERROR": 
            return logging.ERROR 
 110 
 482.ЧДТУ.242313-01 34-01   
        elif level_name == "WARNING" or level_name == "WARN": 
            return logging.WARNING 
        elif level_name == "INFO": 
            return logging.INFO 
        elif level_name == "DEBUG": 
            return logging.DEBUG 
        else: 
            return logging.NOTSET 
 
 
rag.py 
 
import os 
from typing import List 
from dotenv import load_dotenv 
from openai import OpenAI 
from exceptions.no_context_exception import NoContextFoundException 
from log_utils import CustomLogger 
from project_types.chunk import Chunk 
from storage import Storage 
 
load_dotenv() 
 
class Rag: 
    def __init__(self, storage: Storage): 
        self.storage = storage 
        self.client = OpenAI(api_key=os.getenv('OPENAI_API_KEY')) 
        self.log = CustomLogger(__name__) 
 
    def ask_storage(self, query: str) -> dict: 
        context = self.get_context(query) 
        self.log.info(f'Context: {context}') 
 
        if not context: 
            raise NoContextFoundException() 
 
        text_from_context = [chunk.text for chunk in context] 
        prompt = self.create_prompt(query, text_from_context) 
 111 
 482.ЧДТУ.242313-01 34-01   
        self.log.info(f'User prompt: {prompt}') 
        llm_response = self.call_llm(prompt) 
 
        return { 
            "answer_from_llm": llm_response, 
            "chunks": context, 
        } 
     
    def create_prompt(self, query: str, context: List[str]) -> str: 
        # Prepare the prompt for the LLM 
        prompt = f"Question: {query}.\nContext:" 
        for context_peace in context: 
            prompt += f"\n\t- {context_peace}" 
 
        return prompt 
    def call_llm(self, prompt: str) -> str: 
        # Call the OpenAI API to generate a response 
        response = self.client.chat.completions.create( 
            model="gpt-3.5-turbo", 
            messages=[ 
                 { 
                    "role": "system", 
                    "content": "You are a helpful expert in general knowladges. Your users are asking questions about 
information contained in a documents list." 
                    "You will be shown the user's question, and the relevant information from the document. Answer 
the user's question using only this information." 
                }, 
                {"role": "user", "content": prompt}] 
        ) 
 
        return response.choices[0].message.content 
     
    def get_context(self, query: str) -> List[Chunk]: 
        # Retrieve relevant chunks 
        return self.storage.retrieve_chunks(query) 
 
storage.py 
 
 112 
 482.ЧДТУ.242313-01 34-01   
from project_types.chunk import Chunk 
import os 
from typing import List 
import chromadb.config 
import chromadb 
import hashlib 
import nltk 
 
from log_utils import CustomLogger 
from project_types.simple_file import SimpleFile 
from nltk.tokenize import sent_tokenize 
 
nltk.download('punkt_tab') 
 
MAX_CHARS_PER_CHUNK = 150 
SIMILARITY_THRESHOLD = 0.4 
DISTAHCE_FUNCTION = 'ip' # l2, ip, cosine. l2 by defaulte 
CHROMA_PERSIST_DIR = os.path.join(os.getcwd(), 'chroma_db') 
 
class Storage:  
    def __init__(self): 
        self.log = CustomLogger(__name__) 
        # Initialize the Chroma collection 
        self.chroma = chromadb.PersistentClient(path=CHROMA_PERSIST_DIR) 
        self.chunks = self.chroma.get_or_create_collection("chunks", metadata={"hnsw:space": 
DISTAHCE_FUNCTION})  
        # Fill the database with test data 
        # self.fill_db_with_test_data() 
 
    def add_file(self, file: SimpleFile): 
        chunks = self.split_file_into_chunks(file) 
        self.remove_chunks_by_file_name(file.name) 
        self.add_chunks(chunks) 
 
    def remove_chunks_by_file_name(self, file_name: str):  
        # Remove all existing chunks with target file name 
        self.chunks.delete(where={'file_name': {'$eq': file_name}}) 
 
 113 
 482.ЧДТУ.242313-01 34-01   
    def add_chunk(self, chunk: Chunk): 
        """ 
        Add a Chunk to the Chroma vector database. 
 
        Args: 
            chunk (Chunk): The Chunk to be added. 
        """ 
        # Generate a unique ID based on the chunk's hash 
        chunk_id = hashlib.sha256(chunk.text.encode()).hexdigest()  # Create a SHA-256 hash of the chunk 
        self.chunks.add(documents=[chunk.text], metadatas=[chunk.metadata], ids=[chunk_id])  # Use the 
generated ID 
        self.log.info(f'A new chunk has been added: {chunk_id}') 
 
    def add_chunks(self, chunks: List[Chunk]): 
        """ 
        Add a list of Chunks to the Chroma vector database. 
 
        Args: 
            chunks (List[Chunk]): The list of Chunks to be added. 
        """ 
        for chunk in chunks: 
            self.add_chunk(chunk) 
 
    def retrieve_chunks(self, query: str, top_k: int = 5) -> List[Chunk]: 
        """ 
        Retrieve relevant chunks from the Chroma vector database based on the user query. 
 
        Args: 
            query (str): The user query to search for. 
            top_k (int): The number of top relevant chunks to retrieve. 
 
        Returns: 
            list: A list of relevant chunks. 
        """ 
        results = self.chunks.query(query_texts=query, n_results=top_k)  
 
        self.log.debug('Retrieved chunks', results) 
        
 114 
 482.ЧДТУ.242313-01 34-01   
        # Filter by distance 
        filtered_results = [ 
            Chunk(chunk, metadata) for (chunk, metadata), distance in zip(zip(results["documents"][0], 
results["metadatas"][0]), results["distances"][0]) 
            if distance < SIMILARITY_THRESHOLD 
        ] 
 
        return filtered_results 
 
    def split_file_into_chunks(self, file: SimpleFile) -> List[Chunk]: 
        text_chunks = self.split_text_into_chunks(file.value, MAX_CHARS_PER_CHUNK) 
        chunks = [] 
         
        for index, text_chunk in enumerate(text_chunks): 
            chunk_metadata = { 
                "file_id": file.slack_file_id, 
                "file_name": file.name, 
                "created_at": file.created_at, 
                "added_by": file.slack_user_id, 
                "file_url": file.file_url, 
                "sentence_index": index, 
            } 
            chunk = Chunk(text_chunk, chunk_metadata) 
            chunks.append(chunk) 
        return chunks 
    def split_text_into_chunks(self, text, chunk_size) -> List[str]: 
        self.log.debug('split_text_into_chunks text', text) 
 
        if isinstance(text, bytes): 
            text = text.decode('utf-8') 
 
        sentences = sent_tokenize(text) 
        chunks = [] 
        current_chunk = [] 
 
        for sentence in sentences: 
            current_chunk.append(sentence) 
            if len(' '.join(current_chunk)) >= chunk_size: 
 115 
 482.ЧДТУ.242313-01 34-01   
                chunks.append(' '.join(current_chunk)) 
                current_chunk = [] 
        if current_chunk: 
            chunks.append(' '.join(current_chunk)) 
        return chunks 
 
  
 116 
 
ДОДАТОК В 
 
  
 
 
 
ПОБУДОВА ІНТЕЛЕКТУАЛЬНОГО ПРОГРАМНОГО АГЕНТА ДЛЯ ПОШУКУ 
ІНФОРМАЦІЇ У ЧАТ-БОТІ 
 
Інструкція користувача 
482.ЧДТУ.242313-01 34-01 
Листів 2 
 
 
 
 
 
Розробник ________________ Архіпов М.О. 
 
 
 
 
 
 
 
 
Черкаси 2024  
 
 482.ЧДТУ.242313-01 34-01   
Інструкція користувача 
 
Slack – це платформа для командної роботи, яка дозволяє обмінюватися 
повідомленнями, файлами, працювати над проектами та організовувати 
спілкування в одній програмі. 
Реєстрація та вхід. Завантажте Slack на офіційному сайті або через 
мобільний застосунок (доступний для iOS та Android). 
Створіть обліковий запис, використовуючи вашу робочу електронну пошту, 
або увійдіть, якщо у вас вже є обліковий запис. 
Приєднання до робочого простору (Workspace). Ви можете приєднатися до 
існуючого робочого простору, використовуючи спеціальне посилання або 
запрошення від вашої команди. 
Якщо робочого простору ще немає, створіть новий, дотримуючись підказок 
у Slack. 
Slack дозволяє інтегрувати чат-ботів для автоматизації задач, отримання 
інформації чи взаємодії з сервісами. 
Додавання чат-бота. Виберіть потрібного бота. Для цього перейдіть у Slack 
App Directory через вебверсію Slack або за посиланням Slack Apps. 
Знайдіть чат-бот по назві «rag-requirements». 
Додайте бота до робочого простору. Для цього натисніть Add to Slack поруч 
із вибраним ботом. 
Увійдіть у свій Slack-акаунт, якщо потрібно. 
Після додавання бота він з'явиться у вашому списку контактів або каналів. 
Написання повідомлення чат-боту через особисті повідомлення. У лівій 
бічній панелі натисніть на ім'я бота. Напишіть своє запитання в текстовому полі та 
натисніть Enter. 
Додавання інформації у систему. Увійдіть у свій Slack-акаунт, якщо 
потрібно. Перейдіть у чат з обраним чат-ботом та надішліть йому файл формату 
txt. На що він повинен відповісти реакцією. Інформацію додано. 
  
 118 
 
ДОДАТОК Г 
 
  
 
 
 
ПОБУДОВА ІНТЕЛЕКТУАЛЬНОГО ПРОГРАМНОГО АГЕНТА ДЛЯ ПОШУКУ 
ІНФОРМАЦІЇ У ЧАТ-БОТІ 
 
Презентація 
482.ЧДТУ.242313-01 90-01 
Листів 13 
 
 
 
 
 
Розробник ________________ Архіпов М.О. 
 
 
 
 
 
 
 
 
Черкаси 2024  
 
 482.ЧДТУ.242313-01 90-01  2 
 
Рис. Г.1 – Титульний слайд 
 
 
Рис. Г.2 – Слайд «Вступ»
 120 
 482.ЧДТУ.242313-01 90-01  3 
 
 
Рис. Г.3 – Слайд «Вступ (продовження)» 
 
 
Рис. Г.4 – Слайд «Існуючі засоби інформаційно-пошукових систем 
серед заданої бази знань»
 121 
 482.ЧДТУ.242313-01 90-01  4 
 
 
 
Рис. Г.5 – Слайд «Існуючі засоби інформаційно-пошукових систем 
серед заданої бази знань (продовження)»  
 
 
Рис. Г.6 – Слайд «Теоретичні дослідження»
 122 
 482.ЧДТУ.242313-01 90-01  5 
 
 
Рис. Г.7 – Слайд «Гіпотеза» 
 
 
Рис. Г.8 – Слайд «Дослідження»
 123 
 482.ЧДТУ.242313-01 90-01  6 
 
 
Рис. Г.9 – Слайд «Результати дослідження» 
 
 
 
Рис. Г.10 – Слайд «Первинні та детальні вимоги»  
 124 
 482.ЧДТУ.242313-01 90-01  7 
 
 
Рис. Г.11 – Слайд «Діаграма прецедентів»  
 
 
Рис. Г.12 – Слайд «Діаграма прецедентів (продовження)»
 125 
 482.ЧДТУ.242313-01 90-01  8 
 
 
 
Рис. Г.13 – Слайд «Проектування логічної структури»  
 
 
Рис. Г.14 – Слайд «Проектування логічної структури 
(продовження)»
 126 
 482.ЧДТУ.242313-01 90-01  9 
 
 
 
Рис. Г.15 – Слайд «Архітектурне проектування» 
 
 
Рис. Г.16 – Слайд «Архітектурне проектування (продовження)»
 127 
 482.ЧДТУ.242313-01 90-01  10 
 
 
Рис. Г.17 – Слайд «Моделювання поведінки системи»  
 
 
 
Рис. Г.18 – Слайд «Моделювання поведінки системи (продовження)»
 128 
 482.ЧДТУ.242313-01 90-01  11 
 
 
Рис. Г.19 – Слайд «Структурна та функціональна схеми»  
 
 
 
Рис. Г.20 – Слайд «Структурна та функціональна схеми 
(продовження)»
 129 
 482.ЧДТУ.242313-01 90-01  12 
 
 
 
Рис. Г.21 – Слайд «База знань» 
 
 
 
Рис. Г.22 – Слайд «Інтерфейс користувача»
 130 
 482.ЧДТУ.242313-01 90-01  13 
 
 
Рис. Г.23 – Слайд «Тестування» 
 
 
 
Рис. Г.24 – Фінальний слайд 
 
 131