Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9769
Full metadata record
DC FieldValueLanguage
dc.contributor.advisorБілоніг, Анатолій Вікторович-
dc.contributor.authorТерещенко, Євген Валерійович-
dc.date.accessioned2026-07-01T19:39:07Z-
dc.date.available2026-07-01T19:39:07Z-
dc.date.issued2026-06-17-
dc.identifier.urihttps://er.chdtu.edu.ua/handle/ChSTU/9769-
dc.description.abstractАНОТАЦІЯ Терещенко Євген Валерійович. Програмна система семантичного аналізу інформації в локальних текстових масивах. Кваліфікаційна робота бакалавра зі спеціальності 121 «Інженерія програмного забезпечення». Черкаський державний технологічний університет, Черкаси, 2026. Кваліфікаційна робота бакалавра на тему «Програмна система семантичного аналізу інформації в локальних текстових масивах» містить 109 сторінок, 8 таблиць, 41 рисунок, список використаних джерел з 40 найменувань, 4 додатки. Метою виконання кваліфікаційної роботи бакалавра є проектування та розробка програмної системи семантичного аналізу інформації в локальних текстових масивах, яка забезпечує інтелектуальний пошук і узагальнення змісту документів форматів PDF, DOCX та TXT на основі локальної мовної моделі без підключення до мережі Інтернет. Головні завдання при проектуванні програмної системи: 1) дослідити існуючі методи семантичного аналізу тексту та архітектурні підходи до побудови RAG-систем; 2) розробити надійний шар завантаження даних із підтримкою форматів PDF, DOCX і TXT; 3) спроектувати семантичне ядро на основі векторних ембедингів і локальної векторної бази даних ChromaDB; 4) реалізувати аналітичний модуль із підключенням локальної мовної моделі через Ollama; 5) розробити графічний інтерфейс користувача засобами CustomTkinter; 6) провести тестування системи та оцінити якість відповідей. Об'єктом роботи є процес автоматизованого семантичного аналізу інформації у локальних текстових масивах із застосуванням методів векторного представлення тексту та генеративних мовних моделей. Предметом розробки є методи, алгоритми та програмні засоби для реалізації системи семантичного пошуку та аналізу документів у форматі RAG (Retrieval-Augmented Generation), що функціонує в локальному середовищі без використання зовнішніх хмарних сервісів. Вирішено наступні поставлені задачі: 1) проаналізувати еволюцію підходів до семантичного пошуку та сучасні трансформерні архітектури; 2) розробити шар завантаження даних з надійним парсингом файлів PDF, DOCX і TXT; 3) реалізувати семантичне ядро на основі моделі sentence-transformers і ChromaDB; побудовано RAG-конвеєр із локальною моделлю llama3.1:8b; 4) розробити десктопний інтерфейс з підтримкою трьох вкладок; проведено чотири рівні тестування – модульне, інтеграційне, системне та приймальне.uk_UA
dc.description.abstractABSTRACT Tereshchenko E.V. Software System for Semantic Analysis of Information in Local Text Arrays. Bachelor's thesis in specialty 121 «Software Engineering». Cherkasy State Technological University, Cherkasy, 2026. The thesis contains 109 pages, 8 tables, 40 figures, a list of references with 41 items, 4 appendix. The purpose of the bachelor's thesis is to design and implement a software system for semantic analysis of information in local text arrays, providing intelligent search and summarization of PDF, DOCX and TXT document content using a local language model without Internet connection. The main tasks in designing the software system: 1) to investigate existing text semantic analysis methods and RAG architectural approaches; 2) to develop a reliable data ingestion layer supporting PDF, DOCX and TXT formats; 3) to design a semantic core based on vector embeddings and local ChromaDB vector database; 4) to implement an inference module with a local language model via Ollama; 5) to develop a CustomTkinter graphical user interface; 6) to conduct system testing and evaluate response quality. The object of the work is the process of automated semantic analysis of information in local text arrays using vector text representation methods and generative language models. The subject of development is the methods, algorithms and software tools for implementing a RAG (Retrieval-Augmented Generation) document search and analysis system that operates in a local environment without external cloud services. The following tasks have been solved: 1) to investigate the evolution of semantic search approaches and modern transformer architectures; to select the optimal technology stack; 2) to develop a data ingestion layer with reliable PDF, DOCX and TXT file parsing and fault tolerance; 3) to implement a semantic core based on sentence-transformers and ChromaDB; to build a RAG pipeline with a local language model; 4) to develop a desktop interface with three-tab support; to conduct four levels of testing – unit, integration, system and acceptance.uk_UA
dc.language.isoukuk_UA
dc.subjectсемантичний аналізuk_UA
dc.subjectвекторні ембедингиuk_UA
dc.subjectRAGuk_UA
dc.subjectCHROMADBuk_UA
dc.subjectSENTENCE-TRANSFORMERSuk_UA
dc.subjectOLLAMAuk_UA
dc.subjectLLAMA,uk_UA
dc.subjectлокальна мовна модельuk_UA
dc.subjectінформаційний пошукuk_UA
dc.subjectCUSTOMTKINTERuk_UA
dc.subjectPythonuk_UA
dc.subjectsemantic analysisuk_UA
dc.subjectvector embeddingsuk_UA
dc.subjectRAGuk_UA
dc.subjectCHROMADBuk_UA
dc.subjectSENTENCE-TRANSFORMERSuk_UA
dc.subjectOLLAMAuk_UA
dc.subjectLLAMAuk_UA
dc.subjectlocal language modeluk_UA
dc.subjectinformation retrievaluk_UA
dc.subjectCUSTOMTKINTERuk_UA
dc.subjectPythonuk_UA
dc.titleПрограмна система семантичного аналізу інформації в локальних текстових масивахuk_UA
dc.typeBachelor Thesisuk_UA
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)



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

Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
 
 
на тему: «Програмна система семантичного аналізу інформації в локальних 
текстових масивах»  
 
 
Виконав: студент 4 курсу, групи ПЗ-2204 
спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Терещенко Є.В. 
 (прізвище та ініціали) 
Керівник  Білоніг А.В. 
 (прізвище та ініціали) 
Рецензент  Русалівський Б.В. 
 (прізвище та ініціали) 
 
 
 
Черкаси 2026
 
                      Черкаський державний технологічний університет                       ⠀    
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем                                       
Кафедра програмного забезпечення автоматизованих систем                                                                            
Освітній рівень бакалавр                              
Спеціальність 121 «Інженерія програмного забезпечення»                          
Освітня програма Інженерія програмного забезпечення                                      
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
______________________  С. Голуб 
«___» _________________ 2026 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
                  Терещенко Євген Валерійович                       
(прізвище, ім'я, по батькові) 
1. Тему проекту (роботи)  Програмна система семантичного аналізу інформації в локальних текстових 
масивах                                                                                                                                                                    
Керівник проекту (роботи)  Білоніг А.В.  асистент                                                                                            
(прізвище, ім'я, по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від  «12»  березня  2026 року 
№56/03-03                                                                                                                                                               
2. Строк подання студентом проекту (роботи)                                                                                                   
3. Вхідні дані до проекту (роботи)  текстові документи форматів PDF, DOCX, TXT; специфікації 
бібліотек sentence-transformers, ChromaDB, Ollama, CustomTkinter; вимоги до локальної RAG-системи; 
методи векторного представлення тексту                                                                                                           
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ; Розділ 1 
– аналіз існуючих методів та засобів розв'язання поставлених завдань; Розділ 2 – впровадження 
результатів досліджень у практику проектування програмного забезпечення інформаційних систем; 
Розділ 3 – розробка та тестування програмного 
забезпечення; Висновки; Список використаних джерел; Додатки.                                                                  
5. Перелік графічного матеріалу (з точним зазначенням обов'язкових робіт проекту)  діаграма 
прецедентів, діаграма класів, діаграма пакетів, діаграма компонентів, діаграма розгортання, діаграма 
діяльності, діаграма послідовності, діаграма комунікації, автоматна модель, блок-схема алгоритму, 
діаграма структури БД.                                                                                                                                          
 
 
6. Консультанти розділів роботи 
Розділ Підпис, дата Підпис, дата 
Прізвище, ініціали та посади консультанта 
Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 7 грудня 2025 року                                                                                                        
 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ етапів 
Назва етапів випускної роботи Примітки 
п/п кваліфікаційної 
роботи 
Підготовча стадія 
1 Постановка задачі листопад 2025 виконано 
2 Підготовка та погодження завдання листопад 2025 виконано 
3 Затвердження завдання грудень 2025 виконано 
Основна стадія 
1 Аналіз предметної галузі та існуючих рішень лютий 2026 виконано 
2 Проектування архітектури. Побудова UML-діаграм березень 2026 виконано 
3 Реалізація шару завантаження даних (FileProcessor) березень 2026 виконано 
Реалізація семантичного ядра (EmbeddingService, 
4 березень 2026 виконано 
ChromaDB) 
5 Реалізація аналітичного модуля (AIController, Ollama) квітень 2026 виконано 
6 Розробка графічного інтерфейсу (CustomTkinter) квітень 2026 виконано 
7 Тестування системи квітень 2026 виконано 
Заключна стадія 
1 Оформлення пояснювальної записки травень 2026 виконано 
2 Попередній захист роботи травень 2026 виконано 
3 Затвердження та рецензування роботи травень 2026 виконано 
4 Захист роботи червень 2026  
 
Студент _____________________  Терещенко Є.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник роботи _____________________  Білоніг А.В. 
  (підпис)   (прізвище та ініціали) 
 
 
АНОТАЦІЯ 
Терещенко Євген Валерійович. Програмна система семантичного аналізу 
інформації в локальних текстових масивах. Кваліфікаційна робота бакалавра зі 
спеціальності 121 «Інженерія програмного забезпечення». Черкаський державний 
технологічний університет, Черкаси, 2026. 
Кваліфікаційна робота бакалавра на тему «Програмна система 
семантичного аналізу інформації в локальних текстових масивах» містить 109 
сторінок, 8 таблиць, 41 рисунок, список використаних джерел з 40 найменувань, 
4 додатки. 
Метою виконання кваліфікаційної роботи бакалавра є проектування та 
розробка програмної системи семантичного аналізу інформації в локальних 
текстових масивах, яка забезпечує інтелектуальний пошук і узагальнення змісту 
документів форматів PDF, DOCX та TXT на основі локальної мовної моделі без 
підключення до мережі Інтернет. 
Головні завдання при проектуванні програмної системи:  
1) дослідити існуючі методи семантичного аналізу тексту та архітектурні 
підходи до побудови RAG-систем; 
2) розробити надійний шар завантаження даних із підтримкою форматів 
PDF, DOCX і TXT; 
3) спроектувати семантичне ядро на основі векторних ембедингів і 
локальної векторної бази даних ChromaDB; 
4) реалізувати аналітичний модуль із підключенням локальної мовної 
моделі через Ollama; 
5) розробити графічний інтерфейс користувача засобами CustomTkinter; 
6) провести тестування системи та оцінити якість відповідей. 
Об'єктом роботи є процес автоматизованого семантичного аналізу 
інформації у локальних текстових масивах із застосуванням методів векторного 
представлення тексту та генеративних мовних моделей. 
Предметом розробки є методи, алгоритми та програмні засоби для реалізації 
системи семантичного пошуку та аналізу документів у форматі RAG (Retrieval-
 
 
Augmented Generation), що функціонує в локальному середовищі без 
використання зовнішніх хмарних сервісів. 
Вирішено наступні поставлені задачі:  
1) проаналізувати еволюцію підходів до семантичного пошуку та сучасні 
трансформерні архітектури;  
2) розробити шар завантаження даних з надійним парсингом файлів PDF, 
DOCX і TXT;  
3) реалізувати семантичне ядро на основі моделі sentence-transformers і 
ChromaDB; побудовано RAG-конвеєр із локальною моделлю 
llama3.1:8b; 
4) розробити десктопний інтерфейс з підтримкою трьох вкладок; 
проведено чотири рівні тестування – модульне, інтеграційне, системне 
та приймальне. 
Ключові слова: семантичний аналіз, векторні ембединги, RAG, 
CHROMADB, SENTENCE-TRANSFORMERS, OLLAMA, LLAMA, локальна 
мовна модель, інформаційний пошук, CUSTOMTKINTER, Python. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
Tereshchenko E.V. Software System for Semantic Analysis of Information in 
Local Text Arrays. Bachelor's thesis in specialty 121 «Software Engineering». Cherkasy 
State Technological University, Cherkasy, 2026. 
The thesis contains 109 pages, 8 tables, 40 figures, a list of references with 41 
items, 4 appendix. 
The purpose of the bachelor's thesis is to design and implement a software system 
for semantic analysis of information in local text arrays, providing intelligent search and 
summarization of PDF, DOCX and TXT document content using a local language 
model without Internet connection. 
The main tasks in designing the software system:  
1) to investigate existing text semantic analysis methods and RAG architectural 
approaches; 
2) to develop a reliable data ingestion layer supporting PDF, DOCX and TXT 
formats; 
3) to design a semantic core based on vector embeddings and local ChromaDB 
vector database; 
4) to implement an inference module with a local language model via Ollama; 
5) to develop a CustomTkinter graphical user interface; 
6) to conduct system testing and evaluate response quality. 
The object of the work is the process of automated semantic analysis of 
information in local text arrays using vector text representation methods and generative 
language models. 
The subject of development is the methods, algorithms and software tools for 
implementing a RAG (Retrieval-Augmented Generation) document search and analysis 
system that operates in a local environment without external cloud services. 
The following tasks have been solved:  
1) to investigate the evolution of semantic search approaches and modern 
transformer architectures; to select the optimal technology stack; 
 
 
2) to develop a data ingestion layer with reliable PDF, DOCX and TXT file 
parsing and fault tolerance; 
3) to implement a semantic core based on sentence-transformers and ChromaDB; 
to build a RAG pipeline with a local language model; 
4) to develop a desktop interface with three-tab support; to conduct four levels 
of testing – unit, integration, system and acceptance. 
Keywords: semantic analysis, vector embeddings, RAG, CHROMADB, 
SENTENCE-TRANSFORMERS, OLLAMA, LLAMA, local language model, 
information retrieval, CUSTOMTKINTER, Python. 
 
 
 
 
 
 
 
 
 
 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ................................................................. 6 
ВСТУП ..................................................................................................................... 9 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ .............................................................................. 12 
1.1 Аналіз технічної інформації ........................................................................ 12 
1.2 Актуальність задачі ...................................................................................... 15 
1.3 Аналіз існуючих програмних засобів .......................................................... 16 
Висновки до розділу 1 ........................................................................................ 20 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ .......................................................................... 21 
2.1 Моделювання предметної області ............................................................... 21 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області ......................................................................................... 21 
2.1.2 Елементи моделювання предметної області ........................................ 23 
2.1.3 Робоча область моделювання ............................................................... 25 
2.2 Формування та аналіз вимог ........................................................................ 27 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги ............................................................................................................. 27 
2.2.2 Формування вимог за допомогою діаграми прецедентів .................... 30 
2.3 Проектування логічної структури програмного комплексу ...................... 32 
2.3.1 Діаграми класів ...................................................................................... 32 
2.3.2 Діаграми пакетів .................................................................................... 34 
2.4 Архітектурне проектування ......................................................................... 35 
2.4.1 Діаграма компонентів ............................................................................ 35  
ЧДТУ 262263.024 ПЗ 
Змн. Арк. № докум. Підпис Дата 
 Розроб. Терещенко Є.В. «Програмна система Літ. Арк. Аркушів 
 Перевір. Білоніг А.В. 4 
семантичного аналізу  
 Реценз.  
інформації в локальних 
  . ФІТІС, кафедра ПЗАС,  ПЗ-2204 
Н. Контр  
 Затверд. текстових масивах» 
  
 
 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ..................................................................................................... 36 
2.5 Моделювання поведінки системи................................................................ 38 
2.5.1 Діаграма діяльності ............................................................................... 38 
2.5.2 Діаграма послідовності ......................................................................... 38 
2.5.3 Діаграма комунікації ............................................................................. 41 
2.5.4 Діаграма скінченного автомату ............................................................ 42 
Висновки до розділу 2 ........................................................................................ 45 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ................................................................................................. 46 
3.1 Розробка програмного комплексу ............................................................... 46 
3.1.1 Обґрунтування вибору засобів реалізації ............................................. 46 
3.1.2 Опис структурної (функціональної) схеми .......................................... 48 
3.1.3 Опис логічної схеми системи ................................................................ 50 
3.1.4 Розробка бази даних .............................................................................. 52 
3.1.5 Розробка інтерфейсу користувача ........................................................ 54 
3.1.6 Опис розробки програмних компонентів ............................................. 58 
3.2 Тестування системи ...................................................................................... 61 
3.2.1 Модульне тестування ............................................................................ 61 
3.2.2 Інтеграційне тестування ........................................................................ 62 
3.2.3 Системне тестування ............................................................................. 63 
3.2.4 Приймальне тестування ........................................................................ 64 
3.3 Приклади впровадженого програмного комплексу .................................... 65 
Висновки до розділу 3 ........................................................................................ 67 
ВИСНОВКИ .......................................................................................................... 68 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ........................................................... 70 
ДОДАТОК А 
ДОДАТОБ Б 
ДОДАТОК В 
ДОДАТОК Г 
 
 ЧДТУ 262263.024 ПЗ 
Змн. Арк. № докум. Підпис Дата 
     
ЧДТУ 262263.024 ПЗ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ 
ANN (Approximate Nearest Neighbor, ua. «Пошук приблизних 
найближчих сусідів») Алгоритм, що знаходить приблизно 
найближчий вектор у багатовимірному просторі за значно 
меншу кількість обчислень, ніж повний перебір. 
API (Application Programming Interface, ua. «Інтерфейс 
програмування застосунків») Набір правил і протоколів, 
що дозволяє різним програмним компонентам взаємодіяти 
між собою. 
BERT (Bidirectional Encoder Representations from Transformers) 
Трансформерна модель для обробки природної мови, яка 
формує контекстно-залежні векторні представлення 
тексту. 
BoW (Bag-of-Words, ua. «Мішок слів») Модель представлення 
тексту у вигляді вектора частот входження термінів без 
урахування порядку слів і семантичних зв'язків. 
ChromaDB Відкрита векторна база даних, орієнтована на Python-
застосунки, що забезпечує зберігання ембедингів разом з 
метаданими у персистентному режимі без потреби в 
окремому сервері. 
DOCX (Document XML) Формат файлів текстового редактора 
Microsoft Word на основі XML. 
Embedding Числовий вектор у багатовимірному просторі, що кодує 
(Ембединг) семантичний зміст тексту. Семантично близькі тексти 
мають близькі вектори. 
FAISS (Facebook AI Similarity Search) Бібліотека від Meta для 
ефективного пошуку за подібністю серед великих колекцій 
векторів. 
6 
ЧДТУ 262263.024 ПЗ 
GGUF (GPT-Generated Unified Format) Формат зберігання 
квантованих великих мовних моделей для локального 
розгортання. 
HNSW (Hierarchical Navigable Small World, ua. «Ієрархічний 
навігаційний граф малого світу») Алгоритм побудови 
багаторівневого графу для ефективного пошуку 
найближчих сусідів у векторному просторі зі складністю 
O(log n). 
IR (Information Retrieval, ua. «Інформаційний пошук») 
Наукова дисципліна, що вивчає методи пошуку, 
організації та класифікації текстової інформації. 
LLM (Large Language Model, ua. «Велика мовна модель») 
Нейромережева модель з мільярдами параметрів, навчена 
на великих текстових корпусах для генерації і розуміння 
природної мови. 
LSI (Latent Semantic Indexing, ua. «Латентно-семантичне 
індексування») Метод аналізу зв'язків між термінами і 
документами шляхом сингулярного розкладу матриці 
термін-документ. 
NLP (Natural Language Processing, ua. «Обробка природної 
мови») Галузь штучного інтелекту, що займається 
взаємодією між комп'ютерами і людською мовою. 
Ollama Інструмент для локального розгортання великих мовних 
моделей, що надає уніфікований REST API для взаємодії з 
моделями без підключення до зовнішніх сервісів. 
PDF (Portable Document Format, ua. «Формат портативних 
документів») Формат файлів для представлення 
документів незалежно від програмного забезпечення та 
апаратного забезпечення. 
7 
ЧДТУ 262263.024 ПЗ 
RAG (Retrieval-Augmented Generation, ua. «Генерація з 
підсиленням пошуком») Архітектурний патерн, що 
поєднує семантичний пошук релевантних фрагментів з 
генерацією відповіді великою мовною моделлю. 
REST API (Representational State Transfer Application Programming 
Interface) Стиль архітектури програмного забезпечення 
для розподілених систем на основі HTTP-протоколу. 
TF-IDF (Term Frequency–Inverse Document Frequency, ua. «Частота 
терміна – обернена частота документа») Статистична міра, 
що відображає важливість слова в документі відносно 
всього корпусу текстів. 
UML (Unified Modeling Language, ua. «Уніфікована мова 
моделювання») Стандартизована мова візуального 
моделювання для опису структури і поведінки програмних 
систем. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
ЧДТУ 262263.024 ПЗ 
ВСТУП 
Щороку обсяги текстових документів, що зберігаються на локальних 
комп'ютерах і серверах організацій, зростають з помітною швидкістю. Звіти, 
договори, наукові статті, внутрішні інструкції накопичується роками, і рано чи 
пізно виникає проблема: знайти потрібний документ стає важко. Традиційний 
пошук за ключовими словами тут мало допомагає, він шукає точний збіг, а не 
зміст. Якщо в запиті написано «транспортний засіб», а в документі «автомобіль» 
– система нічого не знайде, хоча мова йде про одне й те саме. 
Вирішення цієї проблеми лежить у площині семантичного аналізу тексту. 
Ідея полягає в тому, щоб представити кожен фрагмент документа у вигляді 
вектора в багатовимірному просторі, і тоді пошук перетворюється на задачу 
знаходження найближчих векторів, тобто найближчих за змістом фрагментів. 
Додати до цього локальну мовну модель, яка вміє формулювати відповіді на 
основі знайдених фрагментів і отримаємо систему, здатну відповідати на довільні 
запити щодо документації. Саме таку систему і розроблено в рамках даної 
кваліфікаційної роботи. 
Актуальність теми. Задача локального семантичного пошуку особливо 
актуальна для організацій, де конфіденційність даних є критичною вимогою: 
юридичних компаній, медичних закладів, науково-дослідних установ, 
підприємств із комерційною таємницею. Їхні документи не можуть передаватися 
на сторонні сервери, а саме це і роблять хмарні сервіси на кшталт Microsoft Azure 
Cognitive Search або Google Cloud Search. 
Водночас відкрита екосистема останніх років зробила можливим те, що 
раніше вимагало потужної хмарної інфраструктури: завдяки бібліотекам sentence-
transformers, векторній базі ChromaDB та інструменту Ollama з моделлю Llama 3.1 
можна побудувати повноцінну RAG-систему (Retrieval-Augmented Generation) 
прямо на звичайному ПК. Саме тому обрана тема є актуальною і має практичне 
значення. 
Мета і завдання розробки. Метою роботи є проектування та реалізація 
програмної системи семантичного аналізу інформації в локальних текстових 
9 
ЧДТУ 262263.024 ПЗ 
масивах, яка забезпечує інтелектуальний пошук і узагальнення змісту документів 
форматів PDF, DOCX та TXT із використанням локальної мовної моделі без 
підключення до зовнішніх сервісів. 
Для цього необхідно вирішити такі завдання: 
1 проаналізувати існуючі методи семантичного аналізу тексту, технології 
векторного пошуку та підходи до побудови RAG-систем; 
2 розробити надійний шар завантаження даних із підтримкою форматів 
PDF, DOCX і TXT, стійкий до пошкоджених файлів; 
3 спроектувати семантичне ядро на основі векторних ембедингів і 
локальної векторної бази даних ChromaDB; 
4 реалізувати аналітичний модуль із підключенням локальної мовної 
моделі llama3.1:8b через Ollama; 
5 розробити зручний графічний інтерфейс засобами CustomTkinter; 
6 перевірити систему на реальних документах і оцінити якість відповідей. 
Об'єкт і предмет розробки є процес автоматизованого семантичного 
аналізу інформації в локальних текстових масивах із застосуванням методів 
векторного представлення тексту та генеративних мовних моделей.  
Предметом розробки є методи, алгоритми та програмні засоби для 
реалізації RAG-системи, що функціонує повністю локально, без залежності від 
хмарних сервісів. 
Методи проектування та конструювання. У роботі застосовано: 
порівняльний аналіз для вибору технологічного стеку; методи об'єктно-
орієнтованого проектування та UML-моделювання для розробки архітектури; 
методи векторного представлення тексту й косинусної подібності в основі 
семантичного пошуку; метод RAG для формування відповідей на основі 
знайдених документів; модульне та інтеграційне тестування для перевірки 
коректності роботи компонентів. 
Практичне значення отриманих результатів. Розроблений комплекс 
може використовуватися як інструмент аналізу внутрішньої документації 
організацій з вимогами до конфіденційності, як навчальний стенд для 
10 
ЧДТУ 262263.024 ПЗ 
демонстрації принципів побудови RAG-систем, а також як основа для подальшого 
розширення – додаванням нових форматів файлів, механізмів розмежування 
доступу, корпоративних баз знань. 
Особистий внесок автора. Автором самостійно проведено аналіз 
предметної галузі, обрано технологічний стек, спроектовано архітектуру і 
реалізовано всі компоненти системи: парсери файлів, сервіс векторних 
ембедингів, обгортку над ChromaDB, RAG-контролер і графічний інтерфейс. 
Також проведено тестування та зроблено висновки щодо ефективності 
реалізованого підходу. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
11 
ЧДТУ 262263.024 ПЗ 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
Перш ніж переходити до проектування власної системи, необхідно 
дослідити стан предметної галузі: розглянути теоретичні основи семантичного 
аналізу тексту, наявні технологічні підходи та засоби, а також проаналізувати 
існуючі програмні рішення, що вирішують подібні задачі. Це дозволить 
обґрунтувати вибір архітектурних рішень і технологічного стеку для 
розроблюваного програмного комплексу. 
1.1. Аналіз технічної інформації 
Задача пошуку релевантної інформації в текстових колекціях є однією з 
фундаментальних у галузі інформаційного пошуку (Information Retrieval, IR). Ця 
дисципліна активно розвивається з 1950-х років і пройшла шлях від простих 
статистичних методів до глибоких нейромережевих архітектур. 
Протягом кількох десятиліть домінуючим підходом залишалася модель 
«мішок слів» (Bag-of-Words, BoW), в якій документ описується вектором частот 
входження термінів без урахування їхніх смислових зв'язків і порядку слів [1]. На 
її основі побудовано класичну метрику TF-IDF, яка зважує слова залежно від 
їхньої частоти в конкретному документі відносно всього корпусу [2]. TF-IDF і досі 
застосовується у багатьох пошукових системах як базовий алгоритм ранжування. 
Попри простоту й ефективність для певного класу задач, BoW-моделі мають 
принциповий недолік: вони не здатні вловлювати синонімію та семантичну 
близькість. Цю проблему в IR прийнято називати лексичним розривом (lexical 
gap), і саме її подолання стало головним напрямком розвитку галузі. 
Першою спробою подолати лексичний розрив стало латентно-семантичне 
індексування (LSI), запропоноване наприкінці 1980-х років. Метод використовує 
сингулярний розклад матриці термін-документ для виявлення прихованих 
семантичних зв'язків між словами [3]. Попри концептуальну елегантність, LSI має 
12 
ЧДТУ 262263.024 ПЗ 
суттєві обмеження: обчислювальну складність при великих корпусах та 
неможливість ефективного оновлення індексу [3]. 
Справжнім проривом стала поява нейромережевих моделей, насамперед 
Word2Vec (2013) [4]. Ідея полягає в тому, що слова, які вживаються у схожих 
контекстах, повинні мати близькі векторні представлення у багатовимірному 
просторі. Згодом з'явилися GloVe (2014) і FastText (2016), які розширили цей 
підхід [5]. 
Word2Vec і GloVe формують фіксований вектор для кожного слова 
незалежно від контексту. Вирішення цієї проблеми стало можливим завдяки 
трансформерній архітектурі, яка обчислює вектор слова з урахуванням усього 
оточуючого контексту. У 2017 році дослідники Google опублікували архітектуру 
Transformer, засновану на механізмі самоуваги (self-attention) [6]. На її основі у 
2018 році з'явилась модель BERT [7], а пізніше бібліотека Sentence Transformers 
[8], яка дозволяє отримувати якісні ембединги на рівні речень і абзаців із 
підтримкою понад 50 мов. 
Перш ніж документ потрапить у векторну базу, його необхідно розбити на 
менші частини – чанки (chunks). Від вибору розміру чанку безпосередньо 
залежить якість семантичного пошуку [9]. У даній роботі застосовується розбиття 
з перекриттям: розмір чанку 500 символів при перекритті 50 символів. Ці 
значення є оптимальним компромісом для документів змішаної структури. 
Для ефективного пошуку серед великих колекцій векторів застосовуються 
алгоритми пошуку приблизних найближчих сусідів (ANN). Найпопулярнішим є 
HNSW (Hierarchical Navigable Small World) зі складністю пошуку O(log n) [10]. 
Серед готових рішень виділяються FAISS – потужна бібліотека низького рівня без 
підтримки метаданих [11], та ChromaDB – відкрита векторна база даних з 
персистентним режимом і зручним API для Python-проектів [12]. 
Технологія RAG (Retrieval-Augmented Generation) поєднує семантичний 
пошук із генеративними мовними моделями [13]. RAG вирішує дві критичні 
проблеми великих мовних моделей: галюцинації і застарілість знань. Паралельно 
активно розвивається напрям локальних мовних моделей, зокрема Llama 3.1, яка 
13 
ЧДТУ 262263.024 ПЗ 
у варіанті з 8 мільярдами параметрів запускається на споживчому ПК [14]. 
Завдяки 4-бітному квантуванню вимоги до оперативної пам'яті знижуються до 6-
8 ГБ [15]. Інструмент Ollama забезпечує зручне локальне розгортання таких 
моделей через REST API [25]. 
 
Таблиця 1.1 
Порівняння підходів до векторного представлення тексту 
Модель Рік Тип ембедингу Підтримка Розмірність 
укр. мови 
TF-IDF 1972 Статистичний Так (будь-яка Розмір 
мова) словника 
Word2Vec 2013 Статичний Потребує 50-300 
(слово) навчання 
GloVe 2014 Статичний Потребує 50-300 
(слово) навчання 
BERT 2018 Контекстний Обмежено 768 
(токен) 
Sentence-BERT 2019 Контекстний Через 768 
(речення) multilingual 
paraphrase- 2020 Контекстний Так (50+ мов) 768 
multilingual (речення) 
 
Таблиця 1.2 
Порівняння векторних баз даних 
Рішення Тип Метадані Персистентність Складність 
розгортання 
FAISS Бібліотека – Ручне Низька 
збереження 
 
 
14 
ЧДТУ 262263.024 ПЗ 
Продовження таблиці 1.2 
ChromaDB Вбудована Так Автоматична Дуже низька 
БД 
Weaviate Сервер Так Автоматична Середня 
Pinecone Хмарний Так Автоматична Низька (хмара) 
SaaS 
Qdrant Сервер/хмара Так Автоматична Середня 
 
1.2. Актуальність задачі 
Аналіз технічних підходів, розглянутих у попередньому підрозділі, 
дозволяє чітко сформулювати актуальну практичну задачу. Незважаючи на 
значний прогрес у методах семантичного аналізу тексту, між теоретичними 
можливостями сучасних моделей і їх доступністю для кінцевого користувача 
існує суттєвий розрив. 
З одного боку, великі мовні моделі та хмарні сервіси типу Azure Cognitive 
Search або OpenAI API забезпечують високу якість семантичного пошуку [16, 17]. 
Проте вони вимагають постійного підключення до мережі Інтернет і передачі 
даних на зовнішні сервери, що є неприйнятним для організацій з підвищеними 
вимогами до конфіденційності: юридичних компаній, медичних установ, 
наукових організацій та підприємств із закритою документацією. 
З іншого боку, локальні рішення на кшталт бібліотек FAISS [11] або 
LangChain [22] потребують значної технічної компетентності для розгортання і не 
мають зрозумілого графічного інтерфейсу для нетехнічного користувача. Жодне 
з наявних рішень не поєднує одночасно повну локальну обробку без доступу до 
мережі, підтримку поширених форматів PDF, DOCX і TXT, вбудовану мовну 
модель і зрозумілий десктопний інтерфейс. 
Таким чином, актуальною є задача розробки програмної системи, яка 
реалізує RAG-архітектуру [13] повністю локально, забезпечує якісний 
семантичний пошук у документах довільної структури і надає зручний інтерфейс 
15 
ЧДТУ 262263.024 ПЗ 
без необхідності технічних знань для налаштування та експлуатації. 
1.3. Аналіз існуючих програмних засобів 
На ринку представлено кілька класів рішень, що частково перетинаються з 
метою даної роботи. Їхній аналіз дозволяє виявити незаповнену нішу і 
обґрунтувати доцільність розробки власної системи. 
Microsoft Azure Cognitive Search – хмарний сервіс семантичного пошуку з 
підтримкою багатьох мов [16]. Сервіс надає потужні можливості, однак для його 
використання необхідне підключення до хмарної інфраструктури Azure, що 
унеможливлює застосування у середовищах з вимогами до конфіденційності. 
Крім того, тарифікація залежить від обсягу запитів [16]. 
Elastic Semantic Search – розширення Elasticsearch із підтримкою векторного 
пошуку на основі HNSW [17]. Рішення вирізняється масштабованістю, однак його 
розгортання вимагає значної технічної компетентності і не підтримує 
генеративний аналіз без додаткової інтеграції із зовнішніми LLM-сервісами [17]. 
LangChain та LlamaIndex – найпопулярніші Python-бібліотеки для побудови 
RAG-конвеєрів [18, 19]. Вони надають готові абстракції, однак орієнтовані 
виключно на розробників і не надають готового десктопного інтерфейсу для 
кінцевого нетехнічного користувача. 
Obsidian із плагіном Smart Connections – популярний настільний інструмент 
для роботи з нотатками у форматі Markdown [20]. Суттєво обмежений форматом: 
PDF або DOCX потребують попередньої конвертації, а якість семантичного 
пошуку залежить від конфігурації зовнішнього API ембедингів. 
PrivateGPT та LM Studio – відкриті рішення для локального розгортання 
RAG-систем. PrivateGPT є найближчим концептуальним аналогом, однак 
орієнтований переважно на технічних користувачів, має складніший процес 
налаштування і не надає інтуїтивного графічного інтерфейсу. LM Studio 
зосереджений на роботі з мовними моделями і не має вбудованих механізмів 
семантичного пошуку по колекції документів. 
 
16 
ЧДТУ 262263.024 ПЗ 
Таблиця 1.3 
Порівняльний аналіз існуючих рішень 
Критерій Azure Elastic LangChain PrivateGPT Розроблювана 
система 
Локальна робота – Частково Так Так Так (повністю) 
PDF/DOCX/TXT Так Так Так Так Так 
Вбудована LLM – – Частково Так Так (Ollama) 
GUI Веб – – Веб Так 
Конфіденційність Низька Середня Залежить Висока Висока 
Укр. мова Так Так Залежить Так Так 
Простота Низька Низька Середня Середня Висока 
розгортання 
 
1.4. Аналіз способів вирішення задачі 
На основі аналізу існуючих програмних засобів і технічних підходів можна 
виділити декілька принципово різних способів вирішення поставленої задачі 
семантичного аналізу локальних текстових масивів. 
Перший спосіб це використання хмарних API для семантичного пошуку і 
генерації відповідей. Цей підхід забезпечує найвищу якість результатів, однак 
потребує постійного підключення до мережі і передачі даних на зовнішні сервери, 
що є неприйнятним при вимогах до конфіденційності. Крім того, такі рішення 
мають фінансові витрати і обмеження по обсягу запитів [16, 17]. 
Другий спосіб – класичний ключово-слівний пошук на основі TF-IDF або 
BM25 [1, 2]. Цей підхід повністю локальний і не потребує значних 
обчислювальних ресурсів, однак не розуміє семантики запиту і не знаходить 
релевантних документів при різному формулюванні тієї самої думки. 
Третій спосіб – RAG-архітектура з локальними компонентами [13]. Цей 
підхід поєднує переваги семантичного пошуку через векторні ембединги і 
генерацію відповідей через локальну мовну модель. Завдяки 4-бітному 
17 
ЧДТУ 262263.024 ПЗ 
квантуванню сучасні моделі здатні працювати на споживчому обладнанні з 8–16 
ГБ оперативної пам'яті. Цей спосіб є найбільш перспективним для реалізації 
поставленої задачі. 
Четвертий спосіб – файнтюнінг спеціалізованої мовної моделі на корпусі 
документів організації. Хоча цей підхід теоретично забезпечує найкращу якість 
для конкретної предметної галузі, він потребує значних обчислювальних ресурсів 
для навчання, великого обсягу розмічених даних і спеціальних компетенцій, що 
робить його непрактичним для більшості організацій. 
 
Таблиця 1.4 
Порівняльний аналіз способів вирішення задачі 
Спосіб Локальність Якість Складність 
пошуку розгортання 
Хмарні API Ні Висока Низька 
Ключово-слівний пошук Так Низька Низька 
RAG з локальними Так Висока Середня 
компонентами 
Файнтюнінг моделі Так Висока Дуже висока 
Аналоги (LangChain, Частково Висока Висока 
PrivateGPT) 
 
Виходячи з вимог до системи – повна локальність, якісний семантичний 
пошук і доступність для нетехнічного користувача, оптимальним є третій спосіб: 
RAG-архітектура з локальними векторними ембедингами і локальною мовною 
моделлю. Саме цей підхід покладено в основу розроблюваної системи. 
1.5. Постановка задачі 
На основі проведеного аналізу методів семантичного пошуку, технологій 
векторних ембедингів і існуючих програмних рішень можна сформулювати 
конкретне завдання даної кваліфікаційної роботи. 
18 
ЧДТУ 262263.024 ПЗ 
Аналіз показав, що жодне з розглянутих рішень не задовольняє одночасно 
всі ключові вимоги: повна локальна обробка без передачі даних на зовнішні 
сервери, підтримка форматів PDF, DOCX і TXT в одному рішенні, вбудована 
мовна модель для генерації відповідей, підтримка україномовного контенту і 
зрозумілий графічний інтерфейс для нетехнічного користувача. Саме ця 
незаповнена ніша і визначає напрямок розробки. 
Вирішення поставленої задачі вимагає розробки системи, яка: 
–реалізує надійний шар завантаження даних із підтримкою трьох форматів 
документів і стійкістю до пошкоджених файлів; 
–будує семантичний індекс на основі векторних ембедингів із підтримкою 
слов'янських мов, зокрема української [8]; 
–зберігає індекс локально між сесіями роботи без потреби у хмарній 
інфраструктурі [12]; 
–реалізує RAG-конвеєр із локальною мовною моделлю для генерації 
відповідей на запити користувача [13, 14]; 
–надає зручний десктопний інтерфейс із відображенням джерел відповіді і 
прогресу індексації. 
Таким чином, розробка програмної системи семантичного аналізу 
інформації в локальних текстових масивах є актуальною практичною задачею, що 
не має повноцінного аналога серед відкритих рішень з наведеним набором 
характеристик. 
 
19 
ЧДТУ 262263.024 ПЗ 
Висновки до розділу 1 
У першому розділі проведено аналіз предметної галузі семантичного 
аналізу текстових масивів і досліджено основні підходи, що застосовуються у 
сучасних інформаційно-пошукових системах. Розглянуто еволюцію від 
статистичних методів BoW та TF-IDF до нейромережевих ембедингів Word2Vec 
і GloVe, а також сучасних трансформерних архітектур BERT і Sentence-BERT. 
Показано, що переломним моментом стало введення механізму самоуваги у 2017 
році, завдяки якому стало можливим формувати контекстно-залежні векторні 
представлення тексту, якісно відмінні від попередніх статичних підходів. 
Досліджено технологію розбиття документів на фрагменти та показано її 
принципову роль у якості кінцевих результатів RAG-системи. Розглянуто 
алгоритм HNSW як основу ефективного пошуку у векторних базах даних і 
порівняно доступні рішення для зберігання ембедингів: FAISS і ChromaDB. 
Обґрунтовано вибір ChromaDB як оптимального рішення для локальних систем 
завдяки персистентності, підтримці метаданих і простоті розгортання. 
Технологію RAG розглянуто як ефективний спосіб подолання двох 
ключових обмежень великих мовних моделей – галюцинацій і застарілості знань. 
Встановлено, що поєднання локальної моделі llama3.1:8b з 4-бітним 
квантуванням і платформи Ollama дозволяє розгорнути повноцінний RAG-
конвеєр на звичайному споживчому ПК без будь-яких хмарних залежностей. 
Аналіз шести існуючих програмних аналогів – Azure Cognitive Search, 
Elastic Semantic Search, LangChain, LlamaIndex, Obsidian Smart Connections і 
PrivateGPT показав, що жодне з них не задовольняє одночасно всі ключові 
вимоги: повна локальна обробка, підтримка форматів PDF, DOCX і TXT, 
вбудована мовна модель і зрозумілий графічний інтерфейс для нетехнічного 
користувача. Виявлена незаповнена ніша визначила мету і напрямок даної 
кваліфікаційної роботи, а результати порівняльного аналізу слугували основою 
для обґрунтування технологічного стеку системи. 
20 
ЧДТУ 262263.024 ПЗ 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
У цьому розділі виконано повний цикл проектування програмної системи 
семантичного аналізу інформації в локальних текстових масивах. Послідовно 
розглянуто предметну область і виявлено ключові сутності, сформовано і 
проаналізовано вимоги до системи, побудовано логічну та архітектурну моделі, а 
також змодельовано поведінку системи у формі UML-діаграм. 
2.1. Моделювання предметної області 
Перший крок до розробки будь-якої складної системи це зрозуміти, що саме 
вона моделює. Предметна область даної роботи охоплює процес інтелектуальної 
обробки неструктурованих текстових документів: від їхнього завантаження і 
розбиття на фрагменти до векторного представлення і генерації відповідей на 
запити користувача. Побудова моделі предметної області допомогла виявити 
основні сутності системи та зв'язки між ними ще до написання першого рядка 
коду. 
2.1.1. Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметна область системи – це сукупність об'єктів, процесів і відносин, 
пов'язаних з автоматизованим пошуком і аналізом змісту локальних текстових 
документів. Система не просто шукає за ключовими словами, а розуміє зміст 
запиту і документів завдяки векторному представленню тексту. 
Модель предметної області відображена на рис. 2.1. На ній показано 
основні сутності системи та зв'язки між ними: від завантаження документів через 
їхню обробку до формування відповіді користувачеві.  
Центральними сутностями є Документ, Чанк, Ембединг і Запит. Документ 
розбивається на чанки, кожен чанк перетворюється на ембединг і зберігається у 
векторній базі даних. Коли користувач формулює запит, система знаходить 
21 
ЧДТУ 262263.024 ПЗ 
найближчі за змістом ембединги і повертає результати пошуку, на основі яких 
мовна модель генерує відповідь. 
 
 
Рисунок 2.1 – Модель предметної галузі системи семантичного аналізу 
22 
ЧДТУ 262263.024 ПЗ 
Словник предметної області містить такі ключові терміни: 
Документ – файл формату PDF, DOCX або TXT, що є джерелом знань для 
системи. 
Чанк (chunk) – текстовий фрагмент фіксованого розміру, отриманий після 
розбиття документа; одиниця індексації. 
Ембединг (embedding) – числовий вектор у багатовимірному просторі, що 
кодує семантичний зміст тексту. 
Векторна база даних – спеціалізоване сховище ембедингів з підтримкою 
пошуку за смисловою близькістю. 
Запит – природномовне питання або завдання, яке формулює користувач. 
Семантичний пошук – пошук документів за змістом, а не за точним збігом 
слів. 
RAG – архітектурний патерн, що поєднує пошук релевантних фрагментів із 
генерацією відповіді мовною моделлю. 
LLM (Large Language Model) – велика мовна модель, що генерує текст на 
основі наданого контексту. 
Косинусна подібність – міра семантичної близькості двох векторів, 
значення від 0 до 1. 
Індексація – процес перетворення документів на ембединги та збереження 
їх у векторній базі даних. 
2.1.2. Елементи моделювання предметної області 
Для моделювання предметної області та проектування системи в цій роботі 
використовується мова UML (Unified Modeling Language). UML є 
стандартизованою мовою візуального моделювання, яка дозволяє описувати 
структуру, поведінку та взаємодію компонентів програмної системи з різних 
точок зору. Основні графічні символи та єднальні елементи UML-діаграм 
наведено на рис. 2.2 та рис. 2.3. 
 
23 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.2 – Основні графічні символи UML 
24 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.3 – Єднальні елементи UML 
 
При проектуванні програмної системи використовується підмножина 
діаграм UML, що найбільш повно відображає структуру та поведінку 
розроблюваного комплексу: діаграми прецедентів, класів, пакетів, компонентів, 
розгортання, діяльності, послідовності, комунікації та скінченного автомату. 
2.1.3. Робоча область моделювання 
На основі аналізу предметної області виявлено такі основні інформаційні 
потоки в системі, що відображають її робочий процес від надходження 
документів до формування відповіді: 
Схему інформаційних потоків системи відображено на рис. 2.4. 
25 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.4 – Інформаційні потоки програмної системи 
26 
ЧДТУ 262263.024 ПЗ 
1 Завантаження документів – користувач вказує шлях до файлу або папки; 
система зчитує файли форматів PDF, DOCX, TXT. 
2 Попередня обробка тексту – очищення від зайвих символів, 
нормалізація пробілів і переносів рядків. 
3 Чанкінг – розбиття очищеного тексту на перекриваючі фрагменти по 500 
символів із перекриттям 50 символів. 
4 Векторизація – перетворення кожного чанка на ембединг розмірністю 
768 за допомогою моделі sentence-transformers. 
5 Індексація – збереження ембедингів разом з метаданими (ім'я файлу, 
номер чанку) у ChromaDB. 
6 Обробка запиту – векторизація запиту користувача і пошук top-5 
найближчих чанків у ChromaDB. 
7 Генерація відповіді – передача знайдених фрагментів як контексту до 
мовної моделі llama3.1:8b через Ollama. 
8 Виведення результату – стрімінгове відображення відповіді та посилань 
на джерела в інтерфейсі. 
2.2. Формування та аналіз вимог 
Формування вимог є фундаментом будь-якого проектування. Правильно 
зафіксовані вимоги дозволяють уникнути суперечностей між очікуваннями і 
реалізацією, а також слугують критерієм оцінки готовності системи. У цьому 
підрозділі визначено первинні вимоги, деталізовано їх до функціональних і 
нефункціональних, а також представлено діаграму прецедентів. 
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги 
Формування вимог до програмного забезпечення 
Формування вимог є першим і найважливішим етапом проектування 
програмної системи [21]. Правильно зафіксовані вимоги дозволяють уникнути 
суперечностей між очікуваннями замовника і реалізацією розробника, а також 
27 
ЧДТУ 262263.024 ПЗ 
слугують критерієм оцінки готовності системи. Процес формування вимог 
включає виявлення потреб стейкхолдерів, їх аналіз і документування у формі, 
придатній для проектування [35]. 
У контексті даної роботи замовником і кінцевим користувачем є 
нетехнічний спеціаліст, який потребує інструменту для аналізу власної колекції 
документів без необхідності налаштування складних технічних рішень. Вимоги 
сформовано методом цілеорієнтованого аналізу: від загальної мети через задачі до 
конкретних функціональних можливостей системи [21, 35]. 
Первинні і детальні вимоги 
Первинна вимога до системи визначається її цільовим призначенням: 
надати користувачу можливість задавати довільні запити до власної колекції 
документів і отримувати точні, обґрунтовані відповіді – повністю локально, без 
звернень до хмарних сервісів. 
На основі первинної вимоги сформовано такі детальні вимоги розробника: 
1 Система повинна сканувати вказану користувачем директорію і 
знаходити всі файли форматів PDF, DOCX та TXT. 
2 Система повинна надійно парсити знайдені файли: не аварійно 
завершуватись на пошкоджених документах, підтримувати кілька 
кодувань для TXT-файлів. 
3 Система повинна розбивати текст на перекриваючі чанки і 
перетворювати їх на векторні ембединги. 
4 Система повинна зберігати ембединги і метадані локально у векторній 
базі даних між сесіями. 
5 Система повинна приймати запити у вільній текстовій формі і 
виконувати семантичний пошук по індексу. 
6 Система повинна формувати відповідь через локальну мовну модель з 
використанням знайдених фрагментів як контексту. 
7 Система повинна відображати джерела, на основі яких сформована 
відповідь. 
28 
ЧДТУ 262263.024 ПЗ 
8 Система повинна мати зрозумілий графічний інтерфейс для 
нетехнічного користувача. 
9 Система повинна коректно обробляти великі файли – обмежувати обсяг 
тексту з одного файлу для запобігання помилок пам'яті. 
Вимоги замовника і розробника  
Вимоги замовника відображають бізнес-потреби і формулюються у 
термінах кінцевого користувача, без прив'язки до технічної реалізації. Замовник 
вимагає: отримати локальний інструмент для пошуку і аналізу документів, що не 
потребує доступу до Інтернету, зберігає конфіденційність даних і є зрозумілим 
для людини без технічних знань [21]. 
Вимоги розробника деталізують технічні рішення, необхідні для 
задоволення вимог замовника. Вони охоплюють вибір алгоритмів, архітектурні 
рішення, вибір бібліотек і форматів даних. Ключова технічна вимога розробника 
це реалізація RAG-архітектури з локальними компонентами: vectorize-and-retrieve 
конвеєр на базі sentence-transformers і ChromaDB та генерація відповідей через 
Ollama [13, 25]. 
Функціональні та нефункціональні вимоги 
Функціональні вимоги описують конкретні дії і можливості, які система має 
виконувати. Нефункціональні характеризують якісні властивості системи: 
надійність, продуктивність, зручність та безпеку. 
Функціональні вимоги до системи: 
1 Сканування директорії та вибір окремих файлів PDF, DOCX, TXT через 
графічний діалог. 
2 Парсинг документів із підтримкою текстових шарів PDF, параграфів і 
таблиць DOCX, автовизначення кодування TXT. 
3 Чанкінг тексту з налаштованим розміром фрагмента та перекриттям. 
4 Векторизація чанків за допомогою багатомовної моделі sentence-
transformers. 
5 Збереження ембедингів і метаданих у локальній ChromaDB із 
персистентністю між сесіями. 
29 
ЧДТУ 262263.024 ПЗ 
6 Семантичний пошук по індексу за запитом користувача з поверненням 
top-K результатів. 
7 Формування RAG-промпту і генерація відповіді через Ollama 
(llama3.1:8b) у стрімінговому режимі. 
8 Відображення відповіді, джерел і оцінок релевантності у графічному 
інтерфейсі. 
9 Генерація загального резюме проіндексованих документів. 
10 Очищення векторного індексу за запитом користувача. 
Нефункціональні вимоги до системи: 
1 Локальність – уся обробка виконується на комп'ютері користувача без 
передачі даних у мережу Інтернет. 
2 Надійність – система не аварійно завершується на пошкоджених 
файлах; помилки логуються і обробляються. 
3 Масштабованість – підтримка папок з великою кількістю документів 
завдяки обмеженням розміру файлу і тексту. 
4 Продуктивність – час індексації одного документа середнього розміру 
не повинен перевищувати 30 секунд. 
5 Зручність – мінімум три кліки від запуску до отримання першої 
відповіді. 
6 Сумісність – коректна робота на Windows 10/11 з Python 3.10 і вище. 
7 Конфігурованість – ключові параметри (модель, розмір чанку, кількість 
результатів) виносяться у config.py. 
8 Документованість – наявність README з інструкцією з розгортання та 
опису архітектури. 
2.2.2. Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (Use Case Diagram) дає змогу побачити систему очима 
кінцевого користувача – які саме дії він може виконувати і які функції система 
надає у відповідь. Єдиним актором системи є Користувач, оскільки система 
повністю локальна і не передбачає зовнішніх сервісів як учасників. 
30 
ЧДТУ 262263.024 ПЗ 
Діаграму прецедентів зображено на рис. 2.5. Вона охоплює вісім основних 
варіантів використання, пов'язаних відношеннями включення (<<include>>) з 
внутрішніми процесами системи. 
 
 
Рисунок 2.5 – Діаграма прецедентів системи семантичного аналізу 
 
Основні варіанти використання та їхній опис наведено нижче. Обрати папку 
та Обрати файл – дають користувачу змогу вказати джерело документів. Ці 
прецеденти включають відображення системного діалогу і оновлення UI. 
Індексувати документи – запускає повний конвеєр обробки: парсинг, чанкінг, 
векторизацію і збереження у ChromaDB; включає прецеденти Парсинг файлів, 
Векторизація тексту. Ввести запит та Отримати відповідь – ключовий RAG-цикл, 
31 
ЧДТУ 262263.024 ПЗ 
що включає прецедент Семантичний пошук і Генерацію відповіді LLM. 
Переглянути джерела – дає змогу побачити фрагменти, на основі яких 
сформована відповідь. Генерувати резюме – формує узагальнений огляд всіх 
документів. Очистити індекс – видаляє всі збережені ембединги з ChromaDB. 
2.3. Проектування логічної структури програмного комплексу 
Логічна структура системи визначає, з яких класів вона складається, які 
відповідальності несе кожен клас і як класи взаємодіють між собою. Для її опису 
побудовано діаграму класів і діаграму пакетів. 
2.3.1. Діаграми класів 
Діаграма класів відображає статичну структуру системи: класи, їхні 
атрибути, методи та зв'язки між ними. Вона є центральним артефактом об'єктно-
орієнтованого проектування і слугує основою для реалізації [22, 24]. 
Для кращого розуміння загальної архітектури спершу розглянемо спрощену 
діаграму класів без атрибутів і методів (рис. 2.6), яка відображає лише класи та 
зв'язки між ними. Це дозволяє сприймати загальну структуру системи без 
надлишкових деталей [22]. 
 
 
Рисунок 2.6 – Спрощена діаграма класів системи семантичного аналізу 
32 
ЧДТУ 262263.024 ПЗ 
Детальну діаграму класів із повним переліком атрибутів і методів 
зображено на рис. 2.7. Система складається з шести основних класів, кожен з яких 
відповідає за чітко визначений рівень обробки [22]. 
 
 
Рисунок 2.7 – Діаграма класів системи семантичного аналізу 
33 
ЧДТУ 262263.024 ПЗ 
Опис ключових класів: 
SemanticRAGApp – головний клас застосунку. Є точкою входу і 
координатором між усіма компонентами. Містить посилання на FileProcessor, 
EmbeddingService, VectorDatabase та AIController. Відповідає за побудову UI і 
обробку подій користувача. 
FileProcessor – клас шару завантаження даних (Ingestion Layer). Виконує 
сканування директорій, парсинг файлів PDF/DOCX/TXT і чанкінг тексту. Реалізує 
захист від аварійного завершення при пошкоджених файлах і перевищенні ліміту 
розміру. 
ParsedDocument – клас-контейнер результату парсингу одного файлу. 
Зберігає шлях до файлу, сирий текст, список чанків і опис помилки (якщо є). 
Властивість is_valid повертає True лише якщо парсинг пройшов успішно. 
EmbeddingService – клас семантичного ядра. Виконує ліниве завантаження 
моделі sentence-transformers і надає методи embed_texts() та embed_query() для 
векторизації. 
VectorDatabase – клас семантичного ядра. Обгортає ChromaDB. Відповідає 
за індексацію документів, семантичний пошук і управління колекцією. 
AIController – клас аналітичного модуля (Inference Layer). Реалізує повний 
RAG-цикл: пошук релевантних чанків, формування промпту і стрімінгову 
генерацію відповіді через Ollama. 
2.3.2. Діаграми пакетів 
Діаграма пакетів відображає логічну організацію програмного коду: як 
класи і модулі згруповані в пакети і які залежності існують між ними. Це 
допомагає оцінити зв'язність і зв'язку системи на архітектурному рівні. 
Діаграму пакетів зображено на рис. 2.8. Система розбита на три внутрішні 
пакети і один пакет зовнішніх залежностей. 
 
34 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.8 – Діаграма пакетів системи семантичного аналізу 
 
Опис пакетів: 
ui – пакет інтерфейсу користувача. Містить клас SemanticRAGApp (app.py) 
і файл ініціалізації. Залежить від пакету core і зовнішньої бібліотеки customtkinter. 
core – пакет бізнес-логіки. Містить чотири модулі: file_processor.py, 
embedding_service.py, vector_database.py, ai_controller.py. Є серцем системи, всі 
алгоритми обробки зосереджені тут. 
semantic_rag (корінь) – кореневий рівень проекту. Містить точку входу 
main.py, конфігурацію config.py і файл залежностей requirements.txt. 
Зовнішні бібліотеки – сторонні пакети: customtkinter (UI), PyMuPDF і 
python-docx (парсинг), sentence-transformers (ембединги), chromadb (векторне 
сховище), ollama (інтеграція з LLM), langchain (допоміжні утиліти). 
2.4. Архітектурне проектування 
Архітектурне проектування визначає фізичну організацію системи: з яких 
компонентів вона складається, як вони розгортаються на апаратних засобах і 
через які інтерфейси взаємодіють. Для цього побудовано діаграму компонентів і 
діаграму розгортання. 
2.4.1. Діаграма компонентів 
35 
ЧДТУ 262263.024 ПЗ 
Діаграма компонентів відображає фізичну декомпозицію системи на окремі 
частини – компоненти, та зв'язки між ними через надані та потрібні інтерфейси. 
Вона дає розуміння того, як система поділена на незалежні одиниці розгортання. 
Систему розбито на чотири рівні, кожен з яких є окремим компонентом зі 
своїми залежностями (рис. 2.9). 
 
 
Рисунок 2.9 – Діаграма компонентів системи семантичного аналізу 
 
UI Layer містить компонент SemanticRAGApp, реалізований засобами 
CustomTkinter. Цей компонент отримує події від користувача і делегує виконання 
нижчим рівням. Ingestion Layer включає FileProcessor з двома підкомпонентами: 
PyMuPDF для парсингу PDF і python-docx для роботи з DOCX. Semantic Core 
складається з EmbeddingService, VectorDatabase і ChromaDB, що забезпечує 
векторизацію і пошук. Inference Layer містить AIController і OllamaClient, що 
взаємодіє з локальним Ollama-сервером через REST API на порту 11434. 
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
36 
ЧДТУ 262263.024 ПЗ 
Діаграма розгортання моделює фізичне розміщення програмних 
компонентів на апаратних вузлах і способи їхньої взаємодії. Для даної системи усі 
компоненти розгортаються на єдиному вузлі – персональному комп'ютері 
користувача під керуванням Windows 10/11. 
Діаграму розгортання зображено на рис. 2.10. На ній виділено три ключові 
середовища виконання. 
 
 
Рисунок 2.10 – Діаграма розгортання системи семантичного аналізу 
 
Python 3.13 Runtime – це основне середовище виконання, в якому 
розгортаються всі Python-модулі системи: main.py, ui/app.py, core/file_processor.py, 
core/embedding_service.py, core/vector_database.py, core/ai_controller.py і config.py. 
Ollama Server це окремий процес, що слухає на localhost:11434 і обслуговує запити 
до моделі llama3.1:8b у форматі GGUF з 4-бітним квантуванням. Взаємодія 
відбувається через REST API. ChromaDB зберігає ембединги у директорії 
chroma_db/ на локальному диску у вигляді файлів SQLite і бінарних індексних 
структур. Документи користувача (PDF / DOCX / TXT) читаються з довільного 
шляху файлової системи. 
37 
ЧДТУ 262263.024 ПЗ 
2.5. Моделювання поведінки системи 
Поведінкові діаграми описують, як система діє в часі: яка послідовність 
кроків виконується, як об'єкти обмінюються повідомленнями і через які стани 
проходить система в процесі роботи. Нижче наведено чотири типи поведінкових 
діаграм. 
2.5.1. Діаграма діяльності 
Діаграма діяльності моделює потік керування всередині системи: від 
запуску до завершення сеансу роботи. Вона відображає альтернативні гілки, 
паралельні процеси і зони відповідальності різних учасників (swim lanes). На рис. 
2.11 показано діаграму діяльності для двох основних сценаріїв: індексації 
документів і обробки запиту. 
Потік індексації: після вибору джерела система запускає сканування в 
окремому потоці, щоб не блокувати UI. Для кожного знайденого файлу 
виконується парсинг і якщо файл прочитано без помилок, текст розбивається на 
чанки. Далі для всієї колекції чанків виконується пакетна векторизація і 
збереження у ChromaDB. Прогрес відображається у UI через прогрес-бар. 
Потік обробки запиту: введений користувачем текст відразу 
векторизується, після чого виконується пошук top-5 найближчих чанків. Знайдені 
фрагменти разом із запитом формують RAG-промпт, який передається до Ollama. 
Відповідь надходить потоково – кожен токен одразу відображається у вікні UI. 
2.5.2. Діаграма послідовності 
Діаграма послідовності відображає хронологічний порядок повідомлень 
між об'єктами під час виконання конкретного сценарію. Вона дозволяє побачити, 
хто кого викликає і в якому порядку передаються дані.  
На рис. 2.12 наведено діаграму послідовності для повного циклу роботи 
системи: вибір джерела → індексація → запит → отримання відповіді. 
 
38 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.11 – Діаграма діяльності системи семантичного аналізу 
39 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.12 – Діаграма послідовності системи семантичного аналізу 
40 
ЧДТУ 262263.024 ПЗ 
Опис ключових взаємодій: 
1 Користувач викликає on_select_folder(path) або on_select_file(path), 
після чого SemanticRAGApp оновлює мітку шляху в UI.  
2 Користувач викликає on_index(), SemanticRAGApp передає шлях до 
FileProcessor.scan_folder().  
3 FileProcessor виконує parse_file() для кожного документа і повертає 
список ParsedDocument.  
4 SemanticRAGApp передає список документів у VectorDatabase.index_do
cuments().  
5 VectorDatabase звертається до EmbeddingService.embed_texts() для 
отримання ембедингів і зберігає їх у ChromaDB.  
6 Користувач викликає on_ask(question), SemanticRAGApp передає запит 
у AIController.ask_stream().  
7 AIController звертається до VectorDatabase.search() для отримання top-5 
чанків.  
8 AIController формує промпт і викликає ollama.Client.chat() у 
стрімінговому режимі.  
9 Кожен токен відповіді одразу передається назад у UI для відображення. 
2.5.3. Діаграма комунікації 
Діаграма комунікації (кооперації) описує ту саму взаємодію, що й діаграма 
послідовності, але акцентує увагу не на часовому порядку, а на структурних 
зв'язках між об'єктами. Кожне повідомлення нумерується відповідно до порядку 
виконання. 
На рис. 2.13 відображено діаграму комунікації між основними об'єктами 
системи під час типового сеансу роботи. 
На діаграмі виділено вісім об'єктів: Користувач, SemanticRAGApp, 
FileProcessor, EmbeddingService, VectorDatabase, AIController, OllamaClient, 
ChromaDB. Нумеровані повідомлення між ними відповідають послідовності 
викликів від ініціювання запиту до отримання кінцевого результату. Ключовою 
особливістю є те, що VectorDatabase звертається до EmbeddingService двічі: при 
41 
ЧДТУ 262263.024 ПЗ 
індексації (embed_texts) і при пошуку (embed_query), що відображає єдність 
механізму векторизації для обох операцій. 
 
 
Рисунок 2.13 – Діаграма комунікації системи семантичного аналізу 
 
2.5.4. Діаграма скінченного автомату 
Діаграма скінченного автомату (автоматна модель) описує множину станів, 
у яких може перебувати система, і переходи між цими станами під дією подій. 
Вона особливо корисна для розуміння реактивної поведінки UI-застосунків. 
На рис. 2.14 зображено автоматну модель системи. Визначено сім 
стабільних станів системи. 
42 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 2.14 – Діаграма скінченного автомату системи семантичного аналізу 
43 
ЧДТУ 262263.024 ПЗ 
Опис станів і переходів: 
Ініціалізація – початковий стан після запуску; система завантажує 
компоненти і підключається до ChromaDB. Перехід у стан Очікування 
відбувається після успішної ініціалізації. 
Очікування – основний стан спокою; система чекає дій користувача. З 
цього стану можливий перехід у будь-який інший залежно від натиснутої кнопки. 
Вибір джерела – активний діалог вибору папки або файлу. Після 
підтвердження відбувається повернення в стан Очікування з оновленим шляхом. 
Індексація – складений стан з підстанами: Сканування, Парсинг, Чанкінг, 
Векторизація, Збереження. При виникненні помилки відбувається перехід у стан 
Помилка. 
Обробка запиту – складений стан з підстанами: Векторизація запиту, 
Пошук, Формування промпту, Генерація відповіді, Стрімінг. При виникненні 
помилки відбувається перехід у стан Помилка. 
Відображення відповіді – тимчасовий стан після завершення генерації; 
система відображає відповідь і джерела. Після взаємодії відбувається повернення 
в стан Очікування. 
Помилка – стан обробки помилки; повідомлення відображається у вікні 
відповіді. Після ознайомлення відбувається повернення в стан Очікування. 
 
44 
ЧДТУ 262263.024 ПЗ 
Висновки до розділу 2 
У другому розділі виконано повний цикл проектування програмної системи 
семантичного аналізу інформації в локальних текстових масивах. Побудовано 
модель предметної області у вигляді спрощеної діаграми класів, складено словник 
ключових термінів і визначено основні інформаційні потоки системи. 
Сформовано і деталізовано вимоги до системи відповідно до методів 
об'єктно-орієнтованого аналізу: дев'ять функціональних вимог охоплюють 
повний цикл обробки – від завантаження файлів до генерації відповіді; вісім 
нефункціональних вимог забезпечують надійність, локальність і зручність 
використання. На основі вимог побудовано діаграму прецедентів з вісьма 
варіантами використання. 
Спроектовано логічну структуру системи: детальна діаграма класів 
відображає шість основних класів із чіткими відповідальностями, діаграма 
пакетів показує трирівневу організацію коду. Архітектурне проектування 
закріплено діаграмою компонентів і діаграмою розгортання. 
Поведінку системи змодельовано чотирма UML-діаграмами: діаграмою 
діяльності, послідовності, комунікації та скінченного автомату. Широкі діаграми 
розміщено в альбомній орієнтації для забезпечення читабельності. Отримані 
проектні артефакти повністю визначають архітектурні рішення і є достатньою 
основою для переходу до реалізації. 
 
 
 
 
 
 
 
 
 
 
45 
ЧДТУ 262263.024 ПЗ 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
У розділі викладено деталі практичної реалізації програмної системи 
семантичного аналізу інформації в локальних текстових масивах. Розглянуто 
обґрунтування вибору засобів реалізації, описано структурну та логічну схеми 
системи, розробку бази даних, інтерфейс користувача й основні програмні 
компоненти. Окремий підрозділ присвячено результатам тестування на чотирьох 
рівнях. 
3.1. Розробка програмного комплексу 
3.1.1. Обґрунтування вибору засобів реалізації 
Вибір технологічного стеку здійснювався з урахуванням вимог до 
локальності роботи, підтримки україномовного контенту, надійності парсингу 
документів і можливості запуску мовної моделі на споживчому обладнанні без 
доступу до мережі Інтернет. 
Мова програмування 
Основною мовою реалізації обрано Python версії 3.13 [19]. Серед мов 
програмування Python займає лідируючі позиції в галузі машинного навчання та 
обробки природної мови: переважна більшість сучасних NLP-бібліотек – 
HuggingFace Transformers [20], sentence-transformers [21], LangChain [22] та 
ChromaDB [12]  розроблені насамперед для Python і має найбільш повну 
підтримку саме для цієї мови. Крім того, модульна архітектура Python і 
зрозумілий синтаксис суттєво прискорюють розробку та подальшу підтримку 
коду. 
Як альтернативи розглядалися JavaScript/Node.js та Java. Node.js має 
розвинену екосистему для веб-розробки, але бібліотеки для NLP-задач значно 
поступаються Python-аналогам як за функціональністю, так і за якістю 
документації. Java забезпечує кращу продуктивність у корпоративних сценаріях, 
проте інтеграція з сучасними моделями ембедингів і векторними базами даних 
вимагала б значних додаткових зусиль. 
46 
ЧДТУ 262263.024 ПЗ 
Засоби парсингу документів 
Для зчитування PDF-файлів використано бібліотеку PyMuPDF (fitz) [23]. 
Бібліотека відрізняється високою швидкістю витягування тексту, підтримкою 
зашифрованих файлів і стійкістю до пошкоджених документів – ключова вимога 
для надійного шару завантаження даних. Для роботи з файлами формату DOCX 
застосовано бібліотеку python-docx [24], яка надає зручний API для доступу до 
параграфів і таблиць документа без залежності від зовнішніх офісних застосунків. 
Модель векторних ембедингів 
Векторне представлення тексту реалізовано за допомогою бібліотеки 
sentence-transformers і моделі paraphrase-multilingual-mpnet-base-v2 [21]. Дана 
модель навчена на паралельних корпусах понад 50 мов, включаючи українську та 
інші слов'янські мови, і демонструє якісні результати для задач семантичного 
пошуку в цих мовах. Розмірність вихідного вектора становить 768, що забезпечує 
достатню семантичну ємність при розумних обчислювальних витратах. На 
відміну від хмарних рішень (OpenAI Embeddings, Cohere), модель працює 
повністю локально без передачі даних на зовнішні сервери. 
Векторна база даних 
Для зберігання ембедингів обрано ChromaDB – відкриту векторну базу 
даних, орієнтовану на Python-додатки [12]. Ключова перевага ChromaDB у 
даному контексті це персистентний режим роботи: дані зберігаються між сесіями 
у директорії на локальному диску без необхідності розгортання окремого сервісу. 
Додатково ChromaDB підтримує збереження довільних метаданих до кожного 
вектора, що спрощує відображення джерел у відповіді [12]. FAISS від Meta 
демонструє вищу швидкість на колекціях мільярдного масштабу, проте є 
бібліотекою низького рівня без підтримки метаданих і персистентності, що 
ускладнює розробку прикладних систем. 
Локальна мовна модель 
Для генерації відповідей обрано модель llama3.1:8b від компанії Meta, яка 
запускається через інструмент Ollama [25, 30]. У конфігурації з 8 мільярдами 
параметрів і 4-бітним квантуванням модель потребує близько 6-8 ГБ оперативної 
47 
ЧДТУ 262263.024 ПЗ 
пам'яті, що відповідає характеристикам сучасного споживчого ПК. Ollama надає 
уніфікований REST API на порту 11434, що дозволяє інтегрувати модель у 
власний застосунок кількома рядками Python-коду [25]. Підтримка стрімінгового 
режиму генерації дозволяє відображати відповідь у UI по мірі її формування, не 
чекаючи повного завершення. 
Графічний інтерфейс користувача 
Для реалізації десктопного інтерфейсу використано бібліотеку 
CustomTkinter – розширення стандартного Tkinter з підтримкою темної теми та 
сучасного зовнішнього вигляду компонентів [26]. Вибір зумовлений тим, що 
CustomTkinter не потребує встановлення окремого середовища виконання (як-от 
Electron або Qt) і повністю інтегрується в Python-проект без додаткових 
складнощів розгортання [26]. 
Апаратна конфігурація для розробки і тестування: процесор Intel Core i5-
13450HX, оперативна пам'ять 16 ГБ, накопичувач SSD 512 ГБ, операційна система 
Windows 11. 
3.1.2. Опис структурної (функціональної) схеми 
Структуру проекту програмної системи наведено на рис. 3.1. Проект 
організовано у два основних пакети: core, який містить усю бізнес-логіку системи, 
та ui, що відповідає за графічний інтерфейс користувача. На кореневому рівні 
розміщено точку входу main.py, файл конфігурації config.py і файл залежностей 
requirements.txt. Директорія chroma_db створюється автоматично при першій 
індексації і містить локальну векторну базу даних [12]. 
Пакет core містить чотири модулі. file_processor.py реалізує шар 
завантаження даних: сканування директорій, парсинг файлів PDF, DOCX і TXT, 
очищення та чанкінг тексту [23, 24]. embedding_service.py відповідає за 
векторизацію тексту за допомогою моделі sentence-transformers [21]. 
vector_database.py є обгорткою над ChromaDB і забезпечує індексацію чанків та 
семантичний пошук [12]. ai_controller.py реалізує повний RAG-цикл: формування 
промпту і стрімінгову генерацію відповіді через Ollama [13, 25]. 
 
48 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 3.1 – Структура проекту програмної системи 
 
Пакет ui містить єдиний модуль app.py з реалізацією графічного інтерфейсу 
засобами CustomTkinter [26]. Він координує роботу всіх компонентів пакету core, 
обробляє події користувача і відображає результати у відповідних вкладках 
інтерфейсу. 
Функціональну схему взаємодії компонентів системи наведено на рис. 3.2. 
Вона відображає внутрішню архітектуру системи: як компоненти пов'язані між 
собою і через які інтерфейси здійснюється взаємодія між шарами. 
 
 
Рисунок 3.2 – Функціональна схема системи семантичного аналізу 
49 
ЧДТУ 262263.024 ПЗ 
Процес індексації включає такі операції: вибір джерела (папки або окремого 
файлу), сканування і парсинг документів, очищення та чанкінг тексту, пакетну 
векторизацію чанків і збереження ембедингів у ChromaDB разом з метаданими. 
Результатом є заповнений індекс, готовий до пошуку. 
Процес обробки запиту: користувач вводить запит у текстове поле, система 
векторизує його і виконує пошук top-5 найближчих чанків, формує RAG-промпт 
із знайденими фрагментами і передає його до Ollama. Відповідь надходить у 
стрімінговому режимі, де кожен токен одразу відображається у вікні UI. 
3.1.3. Опис логічної схеми системи 
Логічна схема у вигляді блок-схеми описує послідовність операцій, що 
виконуються від моменту запуску програми до отримання кінцевого результату 
(рис. 3.3). На відміну від діаграми діяльності у розділі 2, блок-схема відображає 
конкретні умови і розгалуження, реалізовані у програмному коді. 
Послідовність операцій при запуску системи: 
1 Запуск програми – виконується ініціалізація компонентів: створення 
екземплярів FileProcessor, EmbeddingService, VectorDatabase та 
AIController. VectorDatabase підключається до ChromaDB або створює 
нову колекцію, якщо індекс порожній [12]. Паралельно перевіряється 
доступність Ollama-сервера [25]. 
2 Відображення головного вікна – система відображає поточну 
статистику індексу (кількість чанків) і статус підключення до Ollama 
[26]. Кнопка індексації доступна після вибору джерела. 
3 Вибір джерела – користувач обирає папку або окремий файл через 
системний діалог. Шлях зберігається у внутрішній змінній і 
відображається у лівій панелі UI [26]. 
4 Індексація – після натискання кнопки «Індексувати» запускається 
окремий потік. FileProcessor сканує директорію і парсить кожен файл 
[23, 24]. Для файлів розміром понад 50 МБ або з обсягом тексту понад 
500 000 символів застосовуються обмеження для запобігання помилок 
пам'яті. Після парсингу EmbeddingService пакетно векторизує чанки [8],  
50 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 3.3 – Блок-схема роботи програмної системи 
51 
ЧДТУ 262263.024 ПЗ 
VectorDatabase зберігає ембединги і метадані в ChromaDB [12]. Прогрес 
відображається через прогрес-бар у UI. 
5 Обробка запиту – після введення запиту AIController векторизує його, 
виконує пошук top-5 чанків за косинусною подібністю [10], будує RAG-
промпт і звертається до Ollama у стрімінговому режимі [13, 25]. 
Відповідь і посилання на джерела відображаються у вкладках «Запит» і 
«Джерела». 
6 Генерація резюме – за запитом формується узагальнюючий огляд усіх 
проіндексованих документів через передачу розширеного промпту до 
мовної моделі [13]. 
7 Очищення індексу – після підтвердження користувача колекція 
ChromaDB видаляється і створюється порожня нова [12]. 
3.1.4. Розробка бази даних 
В якості бази даних у системі використовується векторна база даних 
ChromaDB у персистентному режимі [12]. Оскільки ChromaDB є спеціалізованим 
сховищем ембедингів, а не реляційною базою даних, структура її колекції суттєво 
відрізняється від традиційних таблиць. 
Система використовує одну колекцію з назвою semantic_rag_docs з 
метрикою косинусної відстані [10]. Кожен запис у колекції це один текстовий 
чанк, який містить чотири поля: унікальний UUID-ідентифікатор, текст чанку, 
векторний ембединг розмірністю 768 і набір метаданих. 
Метадані кожного запису містять такі поля: source_file – повний шлях до 
вихідного файлу; file_name – ім'я файлу для відображення у UI; file_type – 
розширення файлу (.pdf, .docx, .txt); chunk_index – порядковий номер чанку в 
межах документа. Ці поля дозволяють відображати посилання на джерела і 
перевіряти, чи документ вже присутній в індексі перед повторною індексацією 
[12]. 
Дані зберігаються в директорії chroma_db/ у корені проекту у вигляді файлів 
SQLite і бінарних HNSW-індексних структур [10, 12]. Завдяки цьому індекс 
зберігається між сесіями роботи програми без додаткових дій з боку користувача. 
52 
ЧДТУ 262263.024 ПЗ 
Структуру колекції ChromaDB у вигляді діаграми наведено на рис. 3.4, а 
табличне представлення полів – у таблиці 3.1. 
 
 
Рисунок 3.4 – Діаграма структури колекції ChromaDB 
 
Таблиця 3.1 
Структура запису в колекції ChromaDB 
Поле Тип Опис 
id UUID (str) Унікальний ідентифікатор запису 
document str Текстовий вміст чанку (до 500 символів) 
embedding List[float] (768) Векторне представлення тексту 
source_file str (metadata) Повний шлях до вихідного файлу 
file_name str (metadata) Ім'я файлу 
file_type str (metadata) Розширення: .pdf, .docx, .txt 
chunk_index int (metadata) Порядковий номер чанку в документі 
53 
ЧДТУ 262263.024 ПЗ 
3.1.5. Розробка інтерфейсу користувача 
Графічний інтерфейс реалізовано засобами бібліотеки CustomTkinter у 
вигляді десктопного застосунку з темною темою оформлення [26]. Вікно 
розділено на дві частини: ліву бічну панель з елементами керування та праву 
основну панель для виведення результатів (рис. 3.4). 
 
 
Рисунок 3.5 – Головне вікно програмної системи 
 
Ліва панель містить секцію вибору джерела з двома кнопками: «Обрати 
папку» і «Обрати файл», де остання відкриває стандартний діалог з фільтром за 
підтримуваними форматами (*.pdf, *.docx, *.txt). Нижче розташована кнопка 
«Індексувати», яка блокується на час виконання операції. Секція «База знань» 
відображає поточну кількість чанків в індексі та стан підключення до Ollama [25]. 
Прогрес-бар і текстовий рядок стану у нижній частині інформують про хід 
поточної операції. 
Права панель побудована на основі компонента CTkTabview і містить три 
вкладки. Вкладка «Запит» відображає відповідь системи у стрімінговому режимі 
54 
ЧДТУ 262263.024 ПЗ 
– текст з'являється по мірі генерації [13]. Вкладка «Джерела» показує список 
чанків, які були знайдені за запитом, з назвами файлів і оцінками релевантності у 
відсотках. Вкладка «Резюме» містить кнопку для запуску генерації узагальненого 
огляду документів. 
У нижній частині правої панелі розташоване поле введення запиту з 
підтримкою надсилання клавішею Enter і кнопкою «Пошук». 
На рис. 3.6 показано стан інтерфейсу під час процесу індексації: кнопка 
«Індексувати» заблокована, прогрес-бар відображає поточний прогрес обробки 
файлів, рядок стану показує назву поточного файлу. 
 
 
Рисунок 3.6 – Стан інтерфейсу під час індексації документів 
 
На рис. 3.7 показано діалогове вікно вибору папки з документами, яке 
відкривається при натисканні кнопки «Обрати папку». 
55 
ЧДТУ 262263.024 ПЗ 
 
Рисунок 3.7 – Діалогове вікно вибору папки з документами 
 
На рис. 3.8 показано вкладку «Запит» з прикладом відповіді системи на 
запит користувача. Відповідь містить конкретну інформацію з проіндексованих 
документів [13]. 
 
 
Рисунок 3.8 – Приклад відповіді системи на запит 
56 
ЧДТУ 262263.024 ПЗ 
На рис. 3.9 показано вкладку «Джерела» після отримання відповіді: для 
кожного знайденого фрагмента відображається назва вихідного файлу, оцінка 
релевантності у відсотках і перші 300 символів тексту чанку [12]. 
 
 
Рисунок 3.9 – Відображення джерел відповіді у вкладці «Джерела» 
 
На рис. 3.10 показано вкладку «Резюме» з результатом генерації 
узагальненого огляду всіх проіндексованих документів. 
 
 
Рисунок 3.10 – Вкладка «Резюме» з результатом генерації огляду документів 
57 
ЧДТУ 262263.024 ПЗ 
3.1.6. Опис розробки програмних компонентів 
Нижче описано реалізацію основних програмних компонентів системи 
відповідно до архітектури, визначеної у другому розділі [22, 24]. 
FileProcessor: шар завантаження даних. 
Компонент реалізовано у файлі core/file_processor.py. , який зображено на 
рис. 3.11. Метод scan_folder() рекурсивно обходить задану директорію і знаходить 
файли з розширеннями .pdf, .docx і .txt. Для кожного файлу перевіряється розмір: 
якщо він перевищує 50 МБ, файл пропускається з відповідним записом у лог. 
Парсинг PDF виконується постосторінково з ранньою зупинкою при досягненні 
ліміту 500 000 символів [23]. Для DOCX окремо обробляються параграфи і рядки 
таблиць [24]. TXT-файли читаються з автоматичним перебором кодувань: UTF-8, 
CP1251, Latin-1. Якщо під час парсингу виникла будь-яка помилка, вона 
записується у поле error об'єкта ParsedDocument – решта файлів у папці 
продовжують оброблятися. 
 
 
Рисунок 3.11 – Фрагмент реалізації методу scan_folder() 
58 
ЧДТУ 262263.024 ПЗ 
Метод _split_into_chunks(), зоабражений на рис. 3.12, реалізує розбиття 
тексту на перекриваючі фрагменти. Розмір чанку – 500 символів, а перекриття – 
50 символів. Межа розрізання вибирається по найближчому символу переносу 
рядка або пробілу, що дозволяє не розривати слова. Вбудований захист обмежує 
кількість чанків до 10 000 на один документ. 
 
 
Рисунок 3.12 – Фрагмент реалізації методу search() 
 
EmbeddingService: сервіс векторизації. 
Компонент реалізовано у файлі core/embedding_service.py. Модель sentence-
transformers завантажується ліниво – тільки при першому виклику embed_texts() 
або embed_query(), що прискорює запуск програми [8, 21]. Метод embed_texts() 
виконує пакетну векторизацію з розміром пакету 32 і нормалізацією ембедингів, 
що забезпечує коректну роботу косинусної метрики [10]. Метод embed_query() 
векторизує одиночний рядок запиту аналогічним чином. 
59 
ЧДТУ 262263.024 ПЗ 
VectorDatabase: обгортка над ChromaDB. 
Компонент реалізовано у файлі core/vector_database.py. При ініціалізації 
створюється або підключається персистентна колекція з метрикою косинусної 
відстані [12]. Метод index_documents() перевіряє наявність файлу в індексі перед 
додаванням, і якщо документ вже проіндексовано, він пропускається. Метод 
search() приймає текстовий запит, векторизує його через EmbeddingService і 
виконує запит до колекції з поверненням заданої кількості найближчих 
результатів. Оцінка релевантності обчислюється як 1 – відстань [10]. 
AIController: аналітичний модуль. 
Компонент реалізовано у файлі core/ai_controller.py, зображений на рис. 
3.13. Метод ask_stream() є головним методом RAG-циклу [13]: він викликає 
VectorDatabase.search() для отримання top-5 чанків, формує промпт методом 
_build_prompt() і звертається до Ollama через ollama.Client.chat() у режимі 
stream=True [25]. Кожен токен генерованої відповіді повертається генератором, 
що дозволяє UI відображати текст по мірі надходження. Промпт містить системну 
інструкцію формувати відповідь виключно на основі наданих фрагментів і 
повідомляти, якщо відповіді не знайдено. 
 
 
Рисунок 3.13 – Фрагмент реалізації методу ask_stream() 
60 
ЧДТУ 262263.024 ПЗ 
3.2. Тестування системи 
Тестування проводилось на чотирьох рівнях: модульному, інтеграційному, 
системному і приймальному. Для модульного і інтеграційного тестування 
використовувалась бібліотека pytest [27]. Системне і приймальне тестування 
проводились вручну на реальних документах [28, 29]. 
3.2.1. Модульне тестування 
Модульне тестування перевіряє коректність роботи кожного класу окремо, 
у відриві від решти системи [28]. Тестові файли розміщено у директорії tests/ і 
запускаються командою pytest tests/. 
Для класу FileProcessor перевірено коректний парсинг PDF-файлу з 
кількома сторінками [23], читання DOCX із параграфами і таблицею [24], 
автовизначення кодування TXT, повернення is_valid=False, заповнення поля error 
при передачі неіснуючого файлу або файлу непідтримуваного формату і коректне 
розбиття тексту на чанки з перекриттям. 
Для класу EmbeddingService перевірено повернення вектора розмірністю 
768 для одиночного рядка, обробку порожнього списку без виключень та 
нормалізацію вихідних векторів (норма ≈ 1.0) [8]. 
Для класу VectorDatabase перевірено успішне збереження чанків і їх 
наявність після перевірки через _is_indexed(), коректне повернення SearchResult 
із заповненими полями, очищення колекції методом clear_index() [12]. 
Результати модульного тестування наведено у таблиці 3.2. 
 
Таблиця 3.2 
Результати модульного тестування 
Тестовий сценарій Очікуваний результат Отриманий 
результат 
Парсинг коректного Непорожній raw_text, Відповідає 
PDF is_valid=True очікуваному 
 
61 
ЧДТУ 262263.024 ПЗ 
Продовження таблиці 3.2 
Парсинг пошкодженого error заповнено, Відповідає 
PDF is_valid=False очікуваному 
Парсинг TXT у кодуванні Текст декодовано Відповідає 
CP1251 коректно очікуваному 
Чанкінг рядка 1200 3 чанки по ~500 символів Відповідає 
символів очікуваному 
embed_texts([]) — Порожній список без Відповідає 
порожній список помилок очікуваному 
Норма вектора ембедингу ||v|| ~ 1.0 (нормалізований) Відповідає 
очікуваному 
Збереження і пошук у search() повертає Відповідає 
ChromaDB збережений чанк очікуваному 
clear_index() з наступним total_chunks = 0 Відповідає 
get_stats() очікуваному 
 
3.2.2. Інтеграційне тестування 
Інтеграційне тестування перевіряє коректну взаємодію між компонентами 
системи [28, 29]. Основна увага приділялась двом ланцюжкам: перший – 
FileProcessor, EmbeddingService, VectorDatabase (конвеєр індексації); другий – 
VectorDatabase, AIController, Ollama(конвеєр обробки запиту). 
Конвеєр індексації тестувався на наборі з трьох тестових документів різних 
форматів. Перевіряло.сь, що всі чанки коректно зберігаються в ChromaDB [12], 
метадані відповідають вихідним файлам і повторна індексація того самого файлу 
не дублює записи. 
Конвеєр обробки запиту тестувався після індексації тестового документа з 
відомим змістом. Перевірялось, що search() повертає саме ті чанки, які містять 
відповідь на тестовий запит [10], і що AIController формує промпт із коректними 
посиланнями на джерела [13]. 
62 
ЧДТУ 262263.024 ПЗ 
Результати інтеграційного тестування наведено у таблиці 3.3. 
 
Таблиця 3.3 
Результати інтеграційного тестування 
Інтеграційний сценарій Очікуваний результат Отриманий 
результат 
Парсинг PDF з подальшим Чанки збережено з Відповідає 
збереженням у ChromaDB коректними метаданими очікуваному 
Парсинг DOCX з подальшим Чанки збережено з Відповідає 
збереженням у ChromaDB коректними метаданими очікуваному 
Повторна індексація того ж Дублювання відсутнє Відповідає 
файлу очікуваному 
Пошук за запитом, Релевантні чанки у Відповідає 
повернення top-5 чанків відповіді очікуваному 
Запит до порожнього індексу Повідомлення без Відповідає 
виклику LLM очікуваному 
AIController викликає Генератор повертає Відповідає 
ask_stream через Ollama токени очікуваному 
 
3.2.3. Системне тестування 
Системне тестування проводилось на реальному наборі документів – 12 
файлів різних форматів загальним обсягом близько 2,3 МБ [29]. Перевірялась 
відповідність системи функціональним і нефункціональним вимогам у цілому. 
Функціональність індексації. Система коректно обробила всі 12 документів, 
сформувавши 847 чанків. Два файли з пошкодженими секціями PDF були 
частково оброблені – текст доступних сторінок збережено, помилки зафіксовано 
у лог-файлі. Загальний час індексації склав 4 хвилини 12 секунд. 
Якість семантичного пошуку. Для 10 тестових запитів різної складності 
перевірялась релевантність top-5 результатів. У 9 з 10 випадків правильний 
63 
ЧДТУ 262263.024 ПЗ 
фрагмент присутній серед перших трьох результатів. Один запит з 
вузькоспеціалізованою технічною термінологією дав знижену релевантність, що 
пов'язано з особливостями навчання моделі ембедингів. 
Відповідність нефункціональним вимогам. Локальність підтверджена: 
мережевий трафік відсутній під час роботи (окрім початкового завантаження 
моделі ембедингів з HuggingFace Hub) [20]. Система не аварійно завершувалась 
при обробці пошкоджених файлів. Час відповіді на запит від введення до першого 
токена – в середньому 8-12 секунд. 
 
Таблиця 3.4 
Результати системного тестування 
Перевірка Результат 
Індексація 12 документів без збою Виконано успішно 
Обробка пошкодженого PDF без аварії Виконано успішно 
Релевантність пошуку (9/10 запитів) Виконано успішно 
Відсутність зовнішнього мережевого трафіку Підтверджено 
Час відповіді < 15 с на тестовому ПК Виконано успішно 
Прогрес-бар оновлюється під час індексації Виконано успішно 
 
3.2.4. Приймальне тестування 
Приймальне тестування проводилось після розгортання системи на 
кінцевому ПК відповідно до інструкції з файлу README.md [19]. Метою було 
перевірити, чи система виконує поставлені вимоги в умовах реального 
використання [29]. 
Для тестування було підготовлено набір з 5 документів: 2 PDF-файли 
наукових статей, 2 DOCX-файли звітів і 1 TXT-файл з нотатками. Загальний обсяг 
– близько 800 КБ. Виконувались такі сценарії: 1) вибір папки і повна індексація; 
2) вибір одного файлу і часткова індексація; 3) введення 5 запитів різного рівня 
64 
ЧДТУ 262263.024 ПЗ 
складності; 4) генерація резюме документів; 5) очищення індексу і повторна 
індексація. 
Всі п'ять сценаріїв завершились успішно. Система коректно відображала 
відповіді з посиланнями на конкретні файли і фрагменти [13]. Генерація резюме 
сформувала зв'язний текст на основі змісту всіх документів. Під час тестування 
виявлено одне обмеження: для документів з великою кількістю таблиць якість 
ембедингів дещо нижча, оскільки табличний текст після об'єднання рядків через 
роздільник погано відображається векторною моделлю. Проблема зафіксована як 
можливий напрямок подальшого вдосконалення. 
 
Таблиця 3.5 
Результати приймального тестування 
Сценарій Результат 
Індексація папки з 5 документами Виконано успішно 
Індексація одного файлу Виконано успішно 
5 тестових запитів – відповіді з джерелами Виконано успішно 
Генерація резюме Виконано успішно 
Очищення і повторна індексація Виконано успішно 
 
3.3. Приклади впровадженого програмного комплексу 
Для розгортання системи на новому ПК достатньо виконати кілька 
послідовних кроків [19, 25]. Насамперед необхідно встановити Python 3.11 або 
новішої версії з позначкою «Add to PATH», а також Ollama з офіційного сайту 
ollama.com [25]. 
Після встановлення необхідно завантажити модель: у терміналі виконати 
команду ollama pull llama3.1:8b [30]. Ollama автоматично стартує як фоновий 
сервіс після встановлення на Windows, тому окремий запуск ollama serve зазвичай 
не потрібен. 
65 
ЧДТУ 262263.024 ПЗ 
Далі у директорії проекту встановити залежності командою py -m pip install 
-r requirements.txt [19]. Після завершення встановлення систему запускають 
командою py main.py або подвійним кліком на run.bat. 
Типовий сеанс роботи виглядає так: після запуску у лівій панелі 
відображається статус «Ollama: підключено», – це підтверджує, що мовна модель 
доступна. Користувач натискає «Обрати папку» або «Обрати файл», вказує 
розташування документів і натискає «Індексувати». По завершенні індексації у 
секції «База знань» відображається кількість збережених чанків. Після цього у 
полі запиту внизу вікна можна вводити будь-які питання щодо змісту документів, 
де відповідь з'являється у вкладці «Запит», а вкладка «Джерела» показує 
конкретні фрагменти з назвами файлів і оцінками релевантності, на основі яких 
сформовано відповідь (рис. 3.8 та рис. 3.9). 
 
66 
ЧДТУ 262263.024 ПЗ 
Висновки до розділу 3 
У третьому розділі виконано практичну реалізацію програмної системи 
семантичного аналізу інформації в локальних текстових масивах. Обґрунтовано 
вибір технологічного стеку: Python, PyMuPDF і python-docx, sentence-transformers, 
ChromaDB, llama3.1:8b через Ollama та CustomTkinter. Кожен інструмент обрано 
на основі конкретних вимог до системи і зіставлення з доступними 
альтернативами. 
Описано структурну та логічну схеми системи, розкрито деталі реалізації 
кожного з чотирьох основних компонентів: FileProcessor, EmbeddingService, 
VectorDatabase та AIController. Окремо розглянуто структуру векторної бази 
даних ChromaDB та реалізацію графічного інтерфейсу із демонстрацією всіх 
основних вікон і станів застосунку. 
За результатами чотирьох рівнів тестування підтверджено, що система 
відповідає сформульованим вимогам: коректно обробляє файли трьох форматів, 
виконує семантичний пошук з прийнятним рівнем релевантності (9 з 10 тестових 
запитів), генерує відповіді на запити виключно локально і стійко до помилок при 
обробці пошкоджених документів. Виявлене обмеження щодо якості обробки 
табличного контенту зафіксовано як напрямок подальшого вдосконалення 
системи. 
 
67 
ЧДТУ 262263.024 ПЗ 
ВИСНОВКИ 
Задача ефективного пошуку та аналізу інформації в локальних текстових 
масивах залишається актуальною для широкого кола організацій, де 
конфіденційність даних є критичною вимогою. Існуючі комерційні рішення або 
потребують хмарної інфраструктури, або не надають зручного інтерфейсу для 
нетехнічного користувача, або не підтримують україномовний контент на 
належному рівні. У даній кваліфікаційній роботі вирішено задачу побудови 
повнофункціональної RAG-системи, що усуває всі ці обмеження одночасно. 
У ході виконання кваліфікаційної роботи вирішено такі задачі: 
1 Досліджено еволюцію підходів до семантичного пошуку:  від класичних 
статистичних методів BoW та TF-IDF до трансформерних архітектур 
BERT і Sentence-BERT. Визначено оптимальний технологічний стек: 
sentence-transformers для векторизації, ChromaDB для зберігання 
індексу, Ollama для локального розгортання мовної моделі. 
2 Розроблено архітектуру системи відповідно до принципів інженерії 
програмного забезпечення на основі чотирьох рівнів: шару 
завантаження даних (Ingestion Layer), семантичного ядра (Semantic 
Core), аналітичного модуля (Inference Layer) та рівня інтерфейсу (UI 
Layer). Кожен рівень реалізовано у вигляді окремого Python-модуля з 
чіткими відповідальностями. 
3 Реалізовано надійний шар завантаження даних із підтримкою форматів 
PDF, DOCX і TXT, стійким до пошкоджених файлів і великих 
документів, а також алгоритм чанкінгу з перекриттям по 500 символів. 
Побудовано RAG-конвеєр, що включає векторизацію запиту, пошук top-
5 релевантних фрагментів за алгоритмом HNSW і стрімінгову генерацію 
відповіді через локальну мовну модель. 
4 Розроблено графічний інтерфейс на базі CustomTkinter із трьома 
вкладками: «Запит», «Джерела» та «Резюме», що забезпечує доступність 
системи для нетехнічного користувача. 
68 
ЧДТУ 262263.024 ПЗ 
5 За результатами чотирьох рівнів тестування: модульного, 
інтеграційного, системного та приймального – підтверджено 
відповідність системи усім сформульованим вимогам. На наборі з 12 
реальних документів система забезпечила релевантний результат у 9 з 10 
тестових запитів, час відповіді не перевищив 15 секунд, мережевий 
трафік під час роботи відсутній. 
Практична цінність розробленої системи полягає в тому, що вона може 
використовуватись як інструмент аналізу внутрішньої документації організацій із 
підвищеними вимогами до конфіденційності даних, як базова платформа для 
подальшого розширення додатковими форматами файлів і механізмами 
розмежування доступу, а також як навчальний стенд для демонстрації принципів 
побудови RAG-систем.  
Напрямками подальшого розвитку є підтримка форматів XLSX і PPTX, 
покращена обробка табличного контенту, інтеграція з корпоративними системами 
документообігу та оптимізація стратегії чанкінгу залежно від типу документа. 
 
69 
ЧДТУ 262263.024 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Salton G., McGill M. Introduction to Modern Information Retrieval. New 
York : McGraw-Hill, 1983. 448 p. 
2 Sparck Jones K. A statistical interpretation of term specificity and its 
application in retrieval. Journal of Documentation. 1972. Vol. 28, No. 1. P. 
11-21. 
3 Deerwester S. et al. Indexing by latent semantic analysis. Journal of the 
American Society for Information Science. 1990. Vol. 41, No. 6. P. 391-407. 
4 Mikolov T. et al. Distributed Representations of Words and Phrases and their 
Compositionality. Advances in Neural Information Processing Systems. 
2013. P. 3111-3119. 
5 Pennington J., Socher R., Manning C. GloVe: Global Vectors for Word 
Representation. EMNLP 2014. P. 1532-1543. 
6 Vaswani A. et al. Attention Is All You Need. Advances in Neural Information 
Processing Systems. 2017. Vol. 30. 
7 Devlin J. et al. BERT: Pre-training of Deep Bidirectional Transformers for 
Language Understanding. NAACL-HLT 2019. P. 4171-4186. 
8 Reimers N., Gurevych I. Sentence-BERT: Sentence Embeddings using 
Siamese BERT-Networks. EMNLP 2019. P. 3982-3992. 
9 Gao Y. et al. Retrieval-Augmented Generation for Large Language Models: 
A Survey. arXiv preprint arXiv:2312.10997. 2023. 
10 Malkov Yu. A., Yashunin D. A. Efficient and robust approximate nearest 
neighbor search using Hierarchical Navigable Small World graphs. IEEE 
Transactions on Pattern Analysis and Machine Intelligence. 2020. Vol. 42, 
No. 4. P. 824-836. 
11 Johnson J., Douze M., Jégou H. Billion-scale similarity search with GPUs. 
IEEE Transactions on Big Data. 2021. Vol. 7, No. 3. P. 535-547. 
12 ChromaDB: the AI-native open-source embedding database. –
https://www.trychroma.com. 
70 
ЧДТУ 262263.024 ПЗ 
13 Lewis P. et al. Retrieval-Augmented Generation for Knowledge-Intensive 
NLP Tasks. Advances in Neural Information Processing Systems. 2020. Vol. 
33. P. 9459-9474. 
14 Dubey A. et al. The Llama 3 Herd of Models. arXiv preprint 
arXiv:2407.21783. 2024. 
15 Dettmers T. et al. QLoRA: Efficient Finetuning of Quantized LLMs. 
Advances in Neural Information Processing Systems. 2023. Vol. 36. 
16 Microsoft Azure Cognitive Search documentation. – 
https://learn.microsoft.com/en-us/azure/search. 
17 Elasticsearch documentation. – https://www.elastic.co/docs. 
18 Obsidian Smart Connections plugin. – 
https://github.com/brianpetro/obsidian-smart-connections. 
19 Python Software Foundation. Python 3.13 Documentation. – 
https://docs.python.org/3/. 
20 HuggingFace Transformers Documentation. https://huggingface.co/docs/tra
nsformers. 
21 Sentence Transformers Documentation. – https://www.sbert.net. 
22 LangChain documentation. – https://python.langchain.com. 
23 PyMuPDF Documentation. – https://pymupdf.readthedocs.io. 
24 python-docx Documentation. – https://python-docx.readthedocs.io. 
25 Ollama documentation. – https://ollama.com/docs. 
26 CustomTkinter documentation. – https://customtkinter.tomschimansky.com. 
27 pytest documentation. – https://docs.pytest.org. 
28 Авраменко А. С., Авраменко В. С., Косенюк Г. В. Тестування 
програмного забезпечення : навч. посіб. – Черкаси : ЧНУ імені Богдана 
Хмельницького, 2017. – 284 с. 
29 Myers G. J., Badgett T., Sandler C. The Art of Software Testing. 3rd ed. – 
New Jersey : Wiley, 2011. – 240 p. 
30 Meta AI. Llama 3.1 Model Card. – https://ai.meta.com/blog/meta-llama-3-1. 
71 
ЧДТУ 262263.024 ПЗ 
31 Авраменко В. С., Авраменко А. С. Проектування інформаційних систем 
: навч. посіб. – Черкаси : ЧНУ імені Богдана Хмельницького, 2017. – 434 
с. 
32 Єрмаков І. Є., Хоменко М. Д. Об'єктно-орієнтоване програмування та 
проектування програмних систем : навч. посіб. – Київ : НТУ України 
«КПІ», 2015. – 312 с. 
33 Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language 
Reference Manual. 2nd ed. – Boston : Addison-Wesley, 2004. – 721 p. 
34 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling 
Language. 3rd ed. – Boston : Addison-Wesley, 2003. – 208 p. 
35 Sommerville I. Software Engineering. 10th ed. – Boston : Addison-Wesley, 
2015. – 816 p. 
36 Pressman R. S., Maxim B. R. Software Engineering: A Practitioner's 
Approach. 9th ed. – New York : McGraw-Hill Education, 2019. – 976 p. 
37 LlamaIndex documentation. – https://docs.llamaindex.ai. 
38 Сердюк В. Д. Технології програмування : навч. посіб. – Черкаси : ЧДТУ, 
2016. – 248 с. 
39 Trifonova O., Lutska N. Застосування методів машинного навчання для 
обробки природної мови в українськомовних текстах. Вісник НТУУ 
«КПІ». Серія «Інформатика, управління та обчислювальна техніка». 
2022. № 74. С. 45-52. 
40 Brown S. The C4 Model for Software Architecture. – https://c4model.com. 
 
72 
 
ДОДАТОК А 
 
 
 
 
 
 
 
«Програмна система семантичного аналізу інформації 
в локальних текстових масивах» 
 
Специфікація 
482.ЧДТУ.26.2263.024 
Листів 2 
 
 
 
 
 
 
 
 Розробник  ________________   Терещенко Є. В. 
 
 
 
 
 
 
 
2026 
 
2 
Позначення Найменування Примітка 
 Документація  
482.ЧДТУ. 262263 12 01 Текст програми  
482.ЧДТУ. 262263 34 01 Інструкція користувачеві  
482.ЧДТУ. 262263 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
  74 
 
Додаток Б 
 
 
 
 
 
 
 
«Програмна система семантичного аналізу інформації 
в локальних текстових масивах» 
Лістинг програми 
482.ЧДТУ.262263 12 01 
Листів 18 
 
 
 
 
 
 
         Розробник                   ________________        Є. В. Терещенко 
 
 
 
 
 
 
 
 
 
2026 
 
         482.ЧДТУ. 262263 12 01 2 
ЗМІСТ 
Лістинг Б.1 – config.py ............................................................................................. 3 
Лістинг Б.2 – main.py ............................................................................................... 4 
Лістинг Б.3 – core/file_processor.py ......................................................................... 4 
Лістинг Б.4 – core/embedding_service.py ............................................................... 10 
Лістинг Б.5 – core/vector_database.py .................................................................... 11 
Лістинг Б.6 – core/vector_database.py .................................................................... 15 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
76 
         482.ЧДТУ. 262263 12 01 3 
Лістинг Б.1 – config.py 
import os 
from pathlib import Path 
  
BASE_DIR = Path(__file__).parent 
DB_DIR = BASE_DIR / "chroma_db" 
DB_DIR.mkdir(exist_ok=True) 
  
OLLAMA_MODEL = "llama3.1:8b" 
EMBEDDING_MODEL = "sentence-transformers/paraphrase-multilingual-mpnet-base-v2" 
  
CHUNK_SIZE = 500 
CHUNK_OVERLAP = 50 
  
TOP_K_RESULTS = 5 
  
LLM_TEMPERATURE = 0.1 
LLM_MAX_TOKENS = 2048 
  
OLLAMA_BASE_URL = "http://localhost:11434" 
  
CHROMA_COLLECTION_NAME = "semantic_rag_docs" 
  
SUPPORTED_EXTENSIONS = {".pdf", ".docx", ".txt"} 
  
RAG_PROMPT_TEMPLATE = """Ти — аналітичний асистент. Використовуй ЛИШЕ надані 
фрагменти документів для відповіді. 
Якщо відповідь не знайдена у фрагментах — скажи про це чесно. 
  
=== Знайдені фрагменти документів === 
{context} 
  
=== Запитання користувача === 
{question} 
 === Твоя відповідь ===" \ " " \ " " \ "  
77 
         482.ЧДТУ. 262263 12 01 4 
Лістинг Б.2 – main.py 
import sys 
from ui.app import SemanticRAGApp 
  
def main(): 
    app = SemanticRAGApp() 
    app.run() 
  
if __name__ == "__main__": 
    main() 
 
Лістинг Б.3 – core/file_processor.py 
import os 
import logging 
from pathlib import Path 
from dataclasses import dataclass, field 
from typing import List, Optional 
  
import fitz 
from docx import Document as DocxDocument 
  
from config import SUPPORTED_EXTENSIONS, CHUNK_SIZE, CHUNK_OVERLAP 
  
logger = logging.getLogger(__name__) 
  
MAX_FILE_SIZE_MB = 50 
MAX_FILE_SIZE_BYTES = MAX_FILE_SIZE_MB * 1024 * 1024 
MAX_TEXT_CHARS = 500_000 
  
  
@dataclass 
class ParsedDocument: 
    file_path: str 
    file_name: str 
78 
         482.ЧДТУ. 262263 12 01 5 
    file_type: str 
    raw_text: str 
    chunks: List[str] = field(default_factory=list) 
    error: Optional[str] = None 
  
    @property 
    def is_valid(self) -> bool: 
        return self.error is None and bool(self.raw_text.strip()) 
  
  
class FileProcessor: 
  
    def __init__(self): 
        self._stats = {"processed": 0, "failed": 0, "skipped": 0} 
  
    def scan_folder(self, folder_path: str, callback=None) -> List[ParsedDocument]: 
        folder = Path(folder_path) 
        if not folder.exists(): 
            raise FileNotFoundError(f"Папка не знайдена: {folder_path}") 
  
        all_files = [ 
            f for f in folder.rglob("*") 
            if f.is_file() and f.suffix.lower() in SUPPORTED_EXTENSIONS 
        ] 
  
        documents = [] 
        total = len(all_files) 
  
        for idx, file_path in enumerate(all_files): 
            if callback: 
                callback(idx + 1, total, file_path.name) 
  
            doc = self.parse_file(str(file_path)) 
            if doc.is_valid: 
                try: 
79 
         482.ЧДТУ. 262263 12 01 6 
                    doc.chunks = self._split_into_chunks(doc.raw_text) 
                    self._stats["processed"] += 1 
                except MemoryError: 
                    doc.error = "Файл занадто великий для обробки в памяті" 
                    logger.warning(f"MemoryError при чанкінгу: {file_path.name}") 
                    self._stats["failed"] += 1 
                except Exception as e: 
                    doc.error = str(e) 
                    logger.warning(f"Помилка чанкінгу {file_path.name}: {e}") 
                    self._stats["failed"] += 1 
            else: 
                self._stats["failed"] += 1 
  
            documents.append(doc) 
  
        logger.info( 
            f"Сканування завершено: {self._stats['processed']} оброблено, " 
            f"{self._stats['failed']} помилок" 
        ) 
        return documents 
  
    def parse_file(self, file_path: str) -> ParsedDocument: 
        path = Path(file_path) 
        ext = path.suffix.lower() 
  
        doc = ParsedDocument( 
            file_path=str(path), 
            file_name=path.name, 
            file_type=ext, 
            raw_text="", 
        ) 
  
        if ext not in SUPPORTED_EXTENSIONS: 
            doc.error = f"Непідтримуваний формат: {ext}" 
            self._stats["skipped"] += 1 
80 
         482.ЧДТУ. 262263 12 01 7 
            return doc 
  
        try: 
            file_size = path.stat().st_size 
            if file_size > MAX_FILE_SIZE_BYTES: 
                doc.error = f"Файл занадто великий: {file_size // (1024*1024)} МБ" 
                self._stats["skipped"] += 1 
                return doc 
        except Exception: 
            pass 
  
        try: 
            if ext == ".pdf": 
                doc.raw_text = self._parse_pdf(path) 
            elif ext == ".docx": 
                doc.raw_text = self._parse_docx(path) 
            elif ext == ".txt": 
                doc.raw_text = self._parse_txt(path) 
  
            if len(doc.raw_text) > MAX_TEXT_CHARS: 
                doc.raw_text = doc.raw_text[:MAX_TEXT_CHARS] 
  
        except MemoryError: 
            doc.error = "Недостатньо памяті для обробки файлу" 
        except Exception as e: 
            doc.error = str(e) 
  
        return doc 
  
    def _parse_pdf(self, path: Path) -> str: 
        texts = [] 
        total_chars = 0 
        with fitz.open(str(path)) as pdf: 
            if pdf.is_encrypted: 
                pdf.authenticate("") 
81 
         482.ЧДТУ. 262263 12 01 8 
            for page_num, page in enumerate(pdf): 
                try: 
                    text = page.get_text("text") 
                    if text.strip(): 
                        texts.append(text) 
                        total_chars += len(text) 
                        if total_chars > MAX_TEXT_CHARS: 
                            break 
                except Exception as e: 
                    logger.warning(f"PDF {path.name} стор.{page_num}: {e}") 
        return "\n".join(texts) 
  
    def _parse_docx(self, path: Path) -> str: 
        doc = DocxDocument(str(path)) 
        parts = [] 
        total_chars = 0 
        for para in doc.paragraphs: 
            text = para.text.strip() 
            if text: 
                parts.append(text) 
                total_chars += len(text) 
                if total_chars > MAX_TEXT_CHARS: 
                    break 
        if total_chars < MAX_TEXT_CHARS: 
            for table in doc.tables: 
                for row in table.rows: 
                    row_text = " | ".join( 
                        cell.text.strip() for cell in row.cells if cell.text.strip() 
                    ) 
                    if row_text: 
                        parts.append(row_text) 
                        total_chars += len(row_text) 
                        if total_chars > MAX_TEXT_CHARS: 
                            break 
        return "\n".join(parts) 
82 
         482.ЧДТУ. 262263 12 01 9 
  
    def _parse_txt(self, path: Path) -> str: 
        encodings = ["utf-8", "cp1251", "latin-1"] 
        for enc in encodings: 
            try: 
                return path.read_text(encoding=enc)[:MAX_TEXT_CHARS] 
            except UnicodeDecodeError: 
                continue 
        raise ValueError(f"Не вдалося визначити кодування: {path.name}") 
  
    def _split_into_chunks(self, text: str) -> List[str]: 
        text = self._clean_text(text) 
        if not text: 
            return [] 
        if len(text) > MAX_TEXT_CHARS: 
            text = text[:MAX_TEXT_CHARS] 
        chunks = [] 
        start = 0 
        length = len(text) 
        while start < length: 
            end = min(start + CHUNK_SIZE, length) 
            if end < length: 
                split_at = text.rfind("\n", start, end) 
                if split_at == -1: 
                    split_at = text.rfind(" ", start, end) 
                if split_at != -1: 
                    end = split_at 
            chunk = text[start:end].strip() 
            if chunk: 
                chunks.append(chunk) 
            next_start = end - CHUNK_OVERLAP 
            if next_start <= start: 
                next_start = start + 1 
            start = next_start 
            if len(chunks) > 10000: 
83 
         482.ЧДТУ. 262263 12 01 10 
                break 
        return chunks 
  
    def _clean_text(self, text: str) -> str: 
        import re 
        text = re.sub(r'\r\n', '\n', text) 
        text = re.sub(r'\n{3,}', '\n\n', text) 
        text = re.sub(r'[ \t]+', ' ', text) 
        text = re.sub(r'[^\x20-\x7E\u0400-\u04FF\n]', '', text) 
        return text.strip() 
 
Лістинг Б.4 – core/embedding_service.py 
import logging 
from typing import List 
  
from sentence_transformers import SentenceTransformer 
  
from config import EMBEDDING_MODEL 
  
logger = logging.getLogger(__name__) 
  
  
class EmbeddingService: 
  
    def __init__(self): 
        self._model: SentenceTransformer | None = None 
        logger.info("EmbeddingService ініціалізовано") 
  
    def _load_model(self): 
        if self._model is None: 
            logger.info(f"Завантаження моделі: {EMBEDDING_MODEL}") 
            self._model = SentenceTransformer(EMBEDDING_MODEL) 
            logger.info("Модель ембедингів успішно завантажена") 
  
84 
         482.ЧДТУ. 262263 12 01 11 
    def embed_texts(self, texts: List[str]) -> List[List[float]]: 
        self._load_model() 
        if not texts: 
            return [] 
        logger.info(f"Векторизація {len(texts)} чанків...") 
        embeddings = self._model.encode( 
            texts, 
            batch_size=32, 
            show_progress_bar=False, 
            convert_to_numpy=True, 
            normalize_embeddings=True, 
        ) 
        return embeddings.tolist() 
  
    def embed_query(self, query: str) -> List[float]: 
        self._load_model() 
        embedding = self._model.encode( 
            query, 
            convert_to_numpy=True, 
            normalize_embeddings=True, 
        ) 
        return embedding.tolist() 
  
    @property 
    def model_name(self) -> str: 
        return EMBEDDING_MODEL 
 
Лістинг Б.5 – core/vector_database.py 
import logging 
import uuid 
from typing import List, Dict, Any 
from dataclasses import dataclass 
  
import chromadb 
85 
         482.ЧДТУ. 262263 12 01 12 
from chromadb.config import Settings 
  
from config import DB_DIR, CHROMA_COLLECTION_NAME, TOP_K_RESULTS 
from core.embedding_service import EmbeddingService 
from core.file_processor import ParsedDocument 
  
logger = logging.getLogger(__name__) 
  
  
@dataclass 
class SearchResult: 
    chunk_text: str 
    source_file: str 
    distance: float 
    chunk_index: int 
  
    @property 
    def relevance_score(self) -> float: 
        return max(0.0, 1.0 - self.distance) 
  
  
class VectorDatabase: 
  
    def __init__(self, embedding_service: EmbeddingService): 
        self._embedding_service = embedding_service 
        self._client = chromadb.PersistentClient( 
            path=str(DB_DIR), 
            settings=Settings(anonymized_telemetry=False), 
        ) 
        self._collection = self._client.get_or_create_collection( 
            name=CHROMA_COLLECTION_NAME, 
            metadata={"hnsw:space": "cosine"}, 
        ) 
        logger.info( 
            f"VectorDatabase підключено. " 
86 
         482.ЧДТУ. 262263 12 01 13 
            f"Документів в індексі: {self._collection.count()}" 
        ) 
  
    def index_documents(self, documents: List[ParsedDocument], 
                        callback=None) -> int: 
        total_chunks = 0 
        for doc_idx, doc in enumerate(documents): 
            if not doc.is_valid or not doc.chunks: 
                continue 
            if self._is_indexed(doc.file_path): 
                logger.info(f"Вже в індексі: {doc.file_name}") 
                continue 
            try: 
                embeddings = self._embedding_service.embed_texts(doc.chunks) 
                ids, metadatas, texts = [], [], [] 
                for chunk_idx, (chunk, embedding) in enumerate( 
                    zip(doc.chunks, embeddings) 
                ): 
                    ids.append(str(uuid.uuid4())) 
                    texts.append(chunk) 
                    metadatas.append({ 
                        "source_file": doc.file_path, 
                        "file_name": doc.file_name, 
                        "file_type": doc.file_type, 
                        "chunk_index": chunk_idx, 
                    }) 
                self._collection.add( 
                    ids=ids, 
                    embeddings=embeddings, 
                    documents=texts, 
                    metadatas=metadatas, 
                ) 
                total_chunks += len(doc.chunks) 
                logger.info(f"Проіндексовано: {doc.file_name} ({len(doc.chunks)} чанків)") 
            except Exception as e: 
87 
         482.ЧДТУ. 262263 12 01 14 
                logger.error(f"Помилка індексації {doc.file_name}: {e}") 
            if callback: 
                callback(doc_idx + 1, len(documents)) 
        return total_chunks 
  
    def search(self, query: str, top_k: int = TOP_K_RESULTS) -> List[SearchResult]: 
        if self._collection.count() == 0: 
            return [] 
        query_embedding = self._embedding_service.embed_query(query) 
        results = self._collection.query( 
            query_embeddings=[query_embedding], 
            n_results=min(top_k, self._collection.count()), 
            include=["documents", "metadatas", "distances"], 
        ) 
        search_results = [] 
        if not results["documents"] or not results["documents"][0]: 
            return [] 
        for text, meta, dist in zip( 
            results["documents"][0], 
            results["metadatas"][0], 
            results["distances"][0], 
        ): 
            search_results.append(SearchResult( 
                chunk_text=text, 
                source_file=meta.get("file_name", "невідомо"), 
                distance=dist, 
                chunk_index=meta.get("chunk_index", 0), 
            )) 
        return search_results 
  
    def get_stats(self) -> Dict[str, Any]: 
        return { 
            "total_chunks": self._collection.count(), 
            "collection_name": CHROMA_COLLECTION_NAME, 
            "db_path": str(DB_DIR), 
88 
         482.ЧДТУ. 262263 12 01 15 
        } 
  
    def clear_index(self): 
        self._client.delete_collection(CHROMA_COLLECTION_NAME) 
        self._collection = self._client.get_or_create_collection( 
            name=CHROMA_COLLECTION_NAME, 
            metadata={"hnsw:space": "cosine"}, 
        ) 
        logger.info("Індекс очищено") 
  
    def _is_indexed(self, file_path: str) -> bool: 
        results = self._collection.get( 
            where={"source_file": file_path}, 
            limit=1, 
            include=[], 
        ) 
        return len(results["ids"]) > 0 
 
Лістинг Б.6 – core/vector_database.py 
import logging 
from typing import List, Generator 
  
import ollama 
  
from config import ( 
    OLLAMA_MODEL, OLLAMA_BASE_URL, 
    LLM_TEMPERATURE, LLM_MAX_TOKENS, 
    RAG_PROMPT_TEMPLATE, TOP_K_RESULTS, 
) 
from core.vector_database import VectorDatabase, SearchResult 
  
logger = logging.getLogger(__name__) 
  
  
89 
         482.ЧДТУ. 262263 12 01 16 
class AIController: 
  
    def __init__(self, vector_database: VectorDatabase): 
        self._db = vector_database 
        self._client = ollama.Client(host=OLLAMA_BASE_URL) 
        self._last_sources: List[SearchResult] = [] 
  
    def ask(self, question: str, top_k: int = TOP_K_RESULTS) -> str: 
        self._last_sources = self._db.search(question, top_k=top_k) 
        if not self._last_sources: 
            return "У базі знань ще немає проіндексованих документів." 
        prompt = self._build_prompt(question, self._last_sources) 
        try: 
            response = self._client.chat( 
                model=OLLAMA_MODEL, 
                messages=[{"role": "user", "content": prompt}], 
                options={ 
                    "temperature": LLM_TEMPERATURE, 
                    "num_predict": LLM_MAX_TOKENS, 
                }, 
            ) 
            return response["message"]["content"] 
        except Exception as e: 
            logger.error(f"Помилка Ollama: {e}") 
            return f"Помилка звязку з LLM: {e}" 
  
    def ask_stream(self, question: str, 
                   top_k: int = TOP_K_RESULTS) -> Generator[str, None, None]: 
        self._last_sources = self._db.search(question, top_k=top_k) 
        if not self._last_sources: 
            yield "У базі знань ще немає проіндексованих документів." 
            return 
        prompt = self._build_prompt(question, self._last_sources) 
        try: 
            stream = self._client.chat( 
90 
         482.ЧДТУ. 262263 12 01 17 
                model=OLLAMA_MODEL, 
                messages=[{"role": "user", "content": prompt}], 
                options={ 
                    "temperature": LLM_TEMPERATURE, 
                    "num_predict": LLM_MAX_TOKENS, 
                }, 
                stream=True, 
            ) 
            for chunk in stream: 
                token = chunk["message"]["content"] 
                if token: 
                    yield token 
        except Exception as e: 
            logger.error(f"Помилка стримінгу Ollama: {e}") 
            yield f"\n\nПомилка: {e}" 
  
    def summarize(self) -> str: 
        try: 
            results = self._db._collection.get( 
                limit=15, 
                include=["documents", "metadatas"], 
            ) 
            if not results["documents"]: 
                return "У базі знань ще немає проіндексованих документів." 
            sources = [] 
            for doc, meta in zip(results["documents"], results["metadatas"]): 
                sources.append(SearchResult( 
                    chunk_text=doc, 
                    source_file=meta.get("file_name", "невідомо"), 
                    distance=0.0, 
                    chunk_index=meta.get("chunk_index", 0), 
                )) 
            self._last_sources = sources 
            question = ( 
                "Зроби детальне резюме всіх наданих документів: " 
91 
         482.ЧДТУ. 262263 12 01 18 
                "опиши про що кожен з них, ключові факти та висновки." 
            ) 
            prompt = self._build_prompt(question, sources) 
            response = self._client.chat( 
                model=OLLAMA_MODEL, 
                messages=[{"role": "user", "content": prompt}], 
                options={ 
                    "temperature": LLM_TEMPERATURE, 
                    "num_predict": LLM_MAX_TOKENS, 
                }, 
            ) 
            return response["message"]["content"] 
        except Exception as e: 
            logger.error(f"Помилка генерації резюме: {e}") 
            return f"Помилка: {e}" 
  
    def get_last_sources(self) -> List[SearchResult]: 
        return self._last_sources 
  
    def check_ollama_available(self) -> bool: 
        try: 
            self._client.list() 
            return True 
        except Exception: 
            return False 
  
    def _build_prompt(self, question: str, sources: List[SearchResult]) -> str: 
        context_parts = [] 
        for i, src in enumerate(sources, 1): 
            context_parts.append( 
                f"[Фрагмент {i} з '{src.source_file}' " 
                f"(релевантність: {src.relevance_score:.0%})]:\n{src.chunk_text}" 
            ) 
        context = "\n\n---\n\n".join(context_parts) 
        return RAG_PROMPT_TEMPLATE.format(context=context, question=question) 
92 
 
Додаток В 
 
 
 
 
 
 
 
«Програмна система семантичного аналізу інформації 
в локальних текстових масивах» 
Інструкція користувачеві 
482.ЧДТУ.262263 34 01 
Листів 3 
 
 
 
 
 
 
         Розробник                   ________________        Є. В. Терещенко 
 
 
 
 
 
 
 
 
 
2026 
 
 482.ЧДТУ.262263 34 01 2 
Програмна система семантичного аналізу інформації в локальних текстових 
масивах призначена для інтелектуального пошуку та аналізу змісту документів 
форматів PDF, DOCX і TXT. Система працює повністю локально на комп'ютері 
користувача без підключення до мережі Інтернет. Для початку роботи необхідно 
запустити файл run.bat або виконати команду py main.py у терміналі з директорії 
проекту. Після запуску відкриється головне вікно програми, яке складається з 
лівої панелі керування та правої панелі для виведення результатів. 
У лівій панелі розміщено елементи для вибору джерела документів та 
управління індексом. Для роботи з папкою документів необхідно натиснути 
кнопку «Обрати папку», після чого відкриється стандартний системний діалог 
вибору директорії. Якщо потрібно проаналізувати лише один файл, слід 
скористатися кнопкою «Обрати файл» – діалог автоматично фільтрує файли за 
підтримуваними форматами (*.pdf, *.docx, *.txt). Після вибору джерела обраний 
шлях відображається у відповідному рядку лівої панелі. 
Після вибору джерела документів необхідно виконати їх індексацію, 
натиснувши кнопку «Індексувати». Під час індексації кнопка блокується, а 
прогрес-бар і рядок стану відображають поточний хід обробки – назву файлу що 
обробляється та відсоток завершення. Система автоматично сканує всі 
підтримувані файли у вибраній директорії, витягує з них текст, розбиває на 
фрагменти та зберігає у локальній векторній базі даних. Після завершення 
індексації у секції «База знань» відображається загальна кількість збережених 
фрагментів. Індекс зберігається між сесіями роботи програми, тому повторна 
індексація тих самих документів при наступному запуску не потрібна. 
Для отримання відповіді на запит необхідно ввести питання у текстове поле 
у нижній частині правої панелі та натиснути кнопку «Пошук» або клавішу Enter. 
Система автоматично знаходить найбільш релевантні фрагменти 
проіндексованих документів і формує на їх основі відповідь за допомогою 
локальної мовної моделі. Відповідь відображається у вкладці «Запит» у 
стрімінговому режимі, де текст з'являється по мірі генерації, не очікуючи повного 
завершення обробки. 
  94 
 482.ЧДТУ.262263 34 01 3 
Після отримання відповіді користувач може перейти на вкладку «Джерела» 
щоб переглянути конкретні фрагменти документів, на основі яких було 
сформовано відповідь. Для кожного фрагмента відображається назва вихідного 
файлу, оцінка релевантності у відсотках та початковий текст фрагмента. Це 
дозволяє користувачеві перевірити достовірність отриманої інформації та за 
потреби звернутися до першоджерела. 
Вкладка «Резюме» призначена для отримання узагальненого огляду всіх 
проіндексованих документів. Для генерації резюме необхідно натиснути 
відповідну кнопку у цій вкладці. Система автоматично відбирає фрагменти з 
різних документів та формує стислий узагальнюючий текст, що описує основний 
зміст і ключові теми колекції документів. 
У разі необхідності оновлення бази знань, наприклад, якщо документи були 
змінені або додано нові, тоді слід скористатися кнопкою «Очистити індекс» у 
лівій панелі. Після підтвердження операції всі збережені дані видаляються, і 
користувач може повторно проіндексувати актуальні документи. Статус 
підключення до мовної моделі відображається у секції «Ollama» лівої панелі – 
напис «підключено» свідчить про готовність системи до роботи, а «не запущена» 
вказує на необхідність запустити сервіс Ollama перед початком роботи. 
  95 
ДОДАТОК Г 
«Програмна система семантичного аналізу інформації 
в локальних текстових масивах» 
Графічні матеріали 
482.ЧДТУ.262263 90 01
Листів 10
Розробник ________________  Терещенко Є. В. 
2026 
       482.ЧДТУ.262263 90 01        2 
 
Рисунок Г.1 – Тема роботи 
 
 
Рисунок Г 2 – Вступ 
 
  101 
       482.ЧДТУ.262263 90 01        3 
 
Рисунок Г.3 – Вимоги 
 
 
Рисунок Г.4 – Аналіз існуючих рішень 1 
 
  102 
       482.ЧДТУ.262263 90 01        4 
 
Рисунок Г.5 – Засоби розробки 
 
 
Рисунок Г.6 – Діаграма прецедентів 
 
  103 
       482.ЧДТУ.262263 90 01        5 
 
Рисунок Г.7 – Діаграми класів та пакетів 
 
 
Рисунок Г.8 – Діаграми діяльності та послідовності 
 
  104 
       482.ЧДТУ.262263 90 01        6 
 
Рисунок Г.9 – Діаграми комунікації та скінченного автомату 
 
 
Рисунок Г.10 – Структурна та функціональна схеми 
 
  105 
       482.ЧДТУ.262263 90 01        7 
 
Рисунок Г.11 – Логічна схема 
 
 
Рисунок Г.12 – Структура бази даних 
 
  106 
       482.ЧДТУ.262263 90 01        8 
 
Рисунок Г.13 – Інтерфейс користувача 
 
 
Рисунок Г.14 – Тестування 1 
 
  107 
       482.ЧДТУ.262263 90 01        9 
 
Рисунок Г.15 – Тестування 2 
 
 
Рисунок Г.16 – Приклади впровадження 
 
  108 
       482.ЧДТУ.262263 90 01        10 
 
Рисунок Г.17 – Висновки 
 
 
Рисунок Г.18 – Кінець презентації 
 
  109