ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9709| Title: | Інтелектуалізована підсистема імпорту навчальних здобутків студентів з документів до Інформаційно-аналітичної системи університету |
| Authors: | Підгорний, Микола Володимирович Гахова, Валерія Володимирівна |
| Keywords: | ІНФОРМАЦІЙНА СИСТЕМА;МІКРОСЕРВІС;ІМПОРТ ДАНИХ;НАВЧАЛЬНІ ЗДОБУТКИ;CHROMADB;SENTENCE TRANSFORMERS;GLINER2. |
| Issue Date: | 11-Jun-2026 |
| Abstract: | Актуальність теми. Актуальність роботи зумовлена необхідністю зменшити обсяг ручного введення, скоротити кількість помилок під час перенесення навчальних даних та підвищити швидкість обробки документів різної структури. Особливого значення набувають мікросервісні архітектури, у межах яких інтелектуалізовані сервіси здатні автоматично виконувати розпізнавання тексту, витяг сутностей та очищення даних. Слід зазначити, що автоматизація семантичного зіставлення назв дисциплін значно оптимізує процеси перезарахування результатів неформальної освіти, що створює потребу у розробці зручної та функціональної підсистеми для університетського середовища. Мета роботи. Метою кваліфікаційної роботи бакалавра є розробка програмної підсистеми, здатної обробляти зображення документів, виділяти з них структуровану інформацію та передавати її в інформаційно-аналітичну систему університету у придатному для подальшої обробки форматі. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9709 |
| Appears in Collections: | 124 Системний аналіз (Штучний інтелект) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Гахова Валерія_СА-2202_2025-2026.pdf Restricted Access | 1.61 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ
ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Інтелектуалізована інформаційна підсистема імпорту навчальних
здобутків студентів з документів до Інформаційно-аналітичної системи
університету»
Виконав: студент 4 курсу, групи СА-2202
спеціальності 124 − «Системний аналіз»
(шифр і назва спеціальності)
Освітня програма «Штучний інтелект»
(назва освітньої програми)
____________________Валерія ГАХОВА
Керівник __________ Микола ПІДГОРНИЙ
(прізвище та ініціали)
Рецензент __________
(прізвище та ініціали)
Черкаси 2026 року
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 124 – Системний аналіз
Освітня програма Штучний інтелект
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2026 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Гаховій Валерії Володимирівні
(прізвище, ім‘я, по батькові)
1. Тема роботи Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків
студентів з документів до Інформаційно-аналітичної системи університету
Керівник роботи Підгорний М.В., к.т.н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «12» березня 2026 р. №56/03-03 .
2. Строк подання студентом роботи « » 2026 року
3. Вихідні дані до роботи:
Відомості про структуру університетської інформаційно-аналітичної системи.
Звіт з виробничої практики. Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз предметної області та постановка задачі.
4.2. Проєктування архітектури та методів обробки.
4.3. Програмна реалізація підсистеми.
4.4. Тестування та введення в експлуатацію.
4.5. Оцінка використаних засобів та напрями розвитку.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482.ЧДТУ. 62299-01.
5.2. Додаток Б. Опис програми.
5.3. Додаток В. Інструкція програмісту.
2
5.4. Додаток Г. Інструкція користувачеві.
5.5. Додаток Д. Програма і методика випробувань.
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ
посада консультанта завдання видав завдання прийняв
7. Дата видачі завдання 2026 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ з/п Назва етапів кваліфікаційної роботи бакалавра виконання Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
12.01.2026
бакалавра.
2 Аналіз літературних джерел, об’єкту та предмету
дослідження. до 09.02.2026
3 Написання теоретичного розділу кваліфікаційної
роботи бакалавра. до 24.03.2026
4 Написання аналітичного розділу кваліфікаційної
роботи бакалавра. до 05.04.2026
5 Написання практичних розділів й висновків до
кваліфікаційної роботи бакалавра. до 16.05.2026
6 Передзахист кваліфікаційної роботи бакалавра
на засіданні кафедри КНСА. до 19.05.2026
7 Подання роботи завідувачу кафедри КНСА. до 20.06. 2026
8 Захист кваліфікаційної роботи бакалавра. 11.06.2026
Студент _____________________________ Валерія ГАХОВА
(підпис)
Керівник роботи ____________________________ Микола ПІДГОРНИЙ
(підпис)
3
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 75 с., 13 рис., 7 таблиць, 13
використаних джерел, 5 додатків.
Актуальність теми. Актуальність роботи зумовлена необхідністю зменшити
обсяг ручного введення, скоротити кількість помилок під час перенесення навчальних
даних та підвищити швидкість обробки документів різної структури. Особливого
значення набувають мікросервісні архітектури, у межах яких інтелектуалізовані
сервіси здатні автоматично виконувати розпізнавання тексту, витяг сутностей та
очищення даних. Слід зазначити, що автоматизація семантичного зіставлення назв
дисциплін значно оптимізує процеси перезарахування результатів неформальної
освіти, що створює потребу у розробці зручної та функціональної підсистеми для
університетського середовища.
Мета роботи. Метою кваліфікаційної роботи бакалавра є розробка програмної
підсистеми, здатної обробляти зображення документів, виділяти з них структуровану
інформацію та передавати її в інформаційно-аналітичну систему університету у
придатному для подальшої обробки форматі.
Завдання кваліфікаційної роботи бакалавра:
– проаналізувати предметну область та існуючі підходи до розпізнавання
академічних документів;
– спроектувати мікросервісну архітектуру та взаємодію Python-сервісу з
університетською системою (Java/Spring Boot backend і Angular frontend);
– реалізувати процес розпізнавання тексту за допомогою PaddleOCR та виділення
сутностей за допомогою GLiNER2;
– розробити модуль очищення даних для нормалізації дат і перевірки коректності
ПІБ;
– імплементувати семантичне зіставлення назв дисциплін із використанням
ChromaDB і Sentence Transformers;
– реалізувати API-ендпоїнти (/api/process-image та /api/match) і протестувати
підсистему на коректність обробки типових і граничних сценаріїв.
4
Об’єкт дослідження: методи, алгоритми та програмні засоби OCR, NER,
семантичного зіставлення і постобробки даних, які забезпечують інтелектуалізоване
розпізнавання та передавання інформації.
Предмет дослідження: Інтелектуалізована інформаційна підсистема імпорту
навчальних здобутків студентів з документів до Інформаційно-аналітичної системи
університету.
Методи дослідження. У роботі використано системний аналіз та аналіз і синтез
програмних рішень для проєктування архітектури системи. Застосовано методи
комп’ютерного зору (OCR) та обробки природної мови (NER) для екстракції
неструктурованих даних. Використано векторний пошук для реалізації алгоритмів
семантичного зіставлення. Також застосовано порівняльний аналіз і тестування
програмного забезпечення для перевірки коректності роботи підсистеми та оцінки її
ефективності.
Ключові слова: ІНФОРМАЦІЙНА СИСТЕМА, OCR, NER, МІКРОСЕРВІС,
ІМПОРТ ДАНИХ, НАВЧАЛЬНІ ЗДОБУТКИ, CHROMADB, SENTENCE
TRANSFORMERS, GLINER2.
ABSTRACT
The bachelor’s qualification thesis consists of: 75 pages, 13 figures, 7 tables, 13
sources used, 5 appendices.
Relevance of the topic. The relevance of the work is due to the need to reduce the
volume of manual data entry, decrease the number of errors during the transfer of academic
data, and increase the processing speed of documents with various structures. Microservice
architectures, within which intelligent services can automatically perform text recognition,
entity extraction, and data cleaning, are of particular importance. It should be noted that the
automation of semantic matching of discipline names significantly optimizes the processes
of credit transfer for non-formal education results, which creates a demand for the
development of a convenient and functional subsystem for the university environment.
5
Purpose and tasks of the project. The purpose of the bachelor's qualification work
is to develop a software subsystem capable of accepting document images, extracting
structured information from them, and transferring it to the university's information and
analytical system in a format suitable for further processing.
To achieve this goal, the following tasks were formulated:
– analyze the subject area and existing approaches to the recognition of academic
documents;
– design a microservice architecture and the interaction of the Python service with the
university system (Java/Spring Boot backend and Angular frontend);
– implement the text recognition process using PaddleOCR and entity extraction using
GLiNER2;
– develop a data cleaning module for date normalization and verification of the
correctness of the student's full name;
– implement semantic matching of discipline names using ChromaDB and Sentence
Transformers;
– implement API endpoints (/api/process-image and /api/match) and test the subsystem
for the correctness of processing typical and boundary scenarios.
Object of study: the processes of automated import of student academic
achievements from documents into the university information system.
Subject of the study: methods, algorithms, and software tools for OCR, NER,
semantic matching, and data post-processing that provide intelligent recognition and
information transfer.
Research Methods. System analysis and the analysis and synthesis of software
solutions were used in the work to design the system architecture. Computer vision (OCR)
and natural language processing (NER) methods were applied for the extraction of
unstructured data. Vector search was used to implement semantic matching algorithms.
Comparative analysis and software testing were also applied to verify the correctness of the
subsystem's operation and evaluate its effectiveness.
6
Keywords: INFORMATION SYSTEM, OCR, NER, MICROSERVICE, DATA
IMPORT, ACADEMIC ACHIEVEMENTS, CHROMADB, SENTENCE
TRANSFORMERS, GLINER2.
7
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 10
ВСТУП 11
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ 14
1.1 Характеристика підсистеми імпорту навчальних здобутків 14
1.2 Аналіз існуючих підходів і рішень 15
1.3 Вимоги до функціонування та якості 19
Висновки до розділу 1 20
2 ПРОЄКТУВАННЯ АРХІТЕКТУРИ ТА МЕТОДІВ ОБРОБКИ 21
2.1 Архітектура мікросервісного рішення 21
2.2 Модель даних і сценарії обробки 22
2.3 Методи OCR, NER та семантичного зіставлення 24
2.4 Питання безпеки, надійності та продуктивності 27
Висновки до розділу 2 29
3 ПРОГРАМНА РЕАЛІЗАЦІЯ ІНТЕЛЕКТУАЛІЗОВАНОЇ ІНФОРМАЦІЙНОЇ
ПІДСИСТЕМИ ІМПОРТУ НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ 31
3.1 Структура проєкту і технологічний стек 31
3.2 Реалізація обробки зображень сертифікатів 32
3.3 Реалізація зіставлення назв дисциплін 33
3.4 Додаткові модулі очищення і інтеграції 35
3.5 Інтеграція з основною інформаційною системою 36
Висновки до розділу 3 36
4 ТЕСТУВАННЯ ТА ВВЕДЕННЯ В ЕКСПЛУАТАЦІЮ 38
4.1 Підхід до тестування 38
4.2 Функціональні перевірки 38
4.3 Перевірка обробки помилок і нетипових ситуацій 40
8
4.4 Розгортання та супровід 41
Висновки до розділу 4 41
5 ОЦІНКА ВИКОРИСТАНИХ ЗАСОБІВ ТА НАПРЯМИ РОЗВИТКУ 43
5.1 Flask, OpenCV, PaddleOCR та GLiNER2 43
5.2 ChromaDB, SentenceTransformers і LangChain 44
5.3 Інтеграція з Java і Angular 44
5.4 Перспективи удосконалення 48
Висновки до розділу 5 50
ВИСНОВКИ 52
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 53
ДОДАТОК А 55
ДОДАТОК Б 57
ДОДАТОК В 66
ДОДАТОК Г 69
ДОДАТОК Д 73
9
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І
ТЕРМІНІВ
API — Application Programming Interface, інтерфейс програмування застосунків.
Angular — Фреймворк для побудови односторінкових вебзастосунків.
ChromaDB — Векторна база даних для зберігання ембеддингів і семантичного
пошуку.
GLiNER2 — Мультимовна модель розпізнавання іменованих сутностей.
HTTP — HyperText Transfer Protocol, протокол передавання гіпертексту.
JSON — JavaScript Object Notation, текстовий формат обміну даними.
JWT — JSON Web Token, формат токена для автентифікації.
LLM — Велика мовна модель; у роботі цей термін використовується як загальне
позначення моделей NLP.
NER — Named Entity Recognition, розпізнавання іменованих сутностей.
OCR — Optical Character Recognition, оптичне розпізнавання символів.
REST — Representational State Transfer, архітектурний стиль для веб-сервісів.
SPA — Single Page Application, односторінковий вебзастосунок.
SQL — Structured Query Language, мова запитів до реляційних баз даних.
XML — Extensible Markup Language, мова розмітки даних.
МПД — Модуль постобробки даних, що виконує очищення та нормалізацію
результатів.
ПІБ — Прізвище, ім’я, по батькові.
ПЗ — Програмне забезпечення.
СУБД — Система управління базами даних.
ІАС — Інформаційно-аналітична система.
10
ВСТУП
Сучасний університетський облік навчальних досягнень характеризується
великою кількістю документів, різноманітністю їхніх форматів і необхідністю
швидко переносити відомості до централізованих інформаційних систем. У практиці
навчального закладу дані про успішність студентів можуть надходити з академічних
довідок, сертифікатів, додатків до дипломів, довідок про проходження освітніх
модулів, листів-підтверджень і внутрішніх розпорядчих документів. Усі ці джерела
мають різну структуру, різний рівень якості зображення та часто містять як
друкований, так і змішаний текст, що ускладнює ручне введення та стандартизовану
обробку [13].
Актуальність теми. Актуальність роботи зумовлена необхідністю зменшити
обсяг ручного введення, скоротити кількість помилок під час перенесення навчальних
даних та підвищити швидкість обробки документів різної структури. Особливого
значення набувають мікросервісні архітектури, у межах яких інтелектуалізовані
сервіси здатні автоматично виконувати розпізнавання тексту, витяг сутностей та
очищення даних. Слід зазначити, що автоматизація семантичного зіставлення назв
дисциплін значно оптимізує процеси перезарахування результатів неформальної
освіти, що створює потребу у розробці зручної та функціональної підсистеми для
університетського середовища.
Додаткову складність створюють відмінності в написанні назв дисциплін та
освітніх компонентів. У документах одна й та сама дисципліна може бути подана
українською або англійською мовою, з різними скороченнями, у різних відмінках або
з незначними відхиленнями в орфографії. Традиційний точний пошук у таких умовах
є недостатнім, тому в роботі доцільно застосовувати методи семантичного
зіставлення, які дають змогу знаходити близькі за змістом формулювання та
пов’язувати їх із наявним каталогом дисциплін.
Предметна область роботи належить до класу складних інформаційних задач,
оскільки обробка документа передбачає послідовне виконання кількох різнорідних
операцій: приймання файлу, перевірку його цілісності, оптичне розпізнавання тексту,
11
виділення іменованих сутностей, постобробку даних, зіставлення з довідниками та
інтеграцію з основною базою даних університету. У такій постановці помилка на
будь-якому етапі може призвести до неправильного перенесення даних, тому
ключовим є побудова надійного ланцюга обробки, що забезпечує як високу точність,
так і контроль якості результату.
Розроблювана Інтелектуалізована інформаційна підсистема імпорту
навчальних здобутків студентів є частиною ширшого багатосервісного рішення
Deanoffice, у межах якого Java/Spring Boot backend виконує роль основної прикладної
платформи, Angular frontend забезпечує взаємодію користувача з системою, а Python-
сервіс реалізує інтелектуальну обробку документів [4]. Така архітектура дає змогу
ізолювати ресурсоємні моделі OCR та NER в окремому сервісі, спростити
масштабування та забезпечити незалежний розвиток інтелектуальної складової без
ускладнення основної бізнес-логіки.
Мета роботи. Метою кваліфікаційної роботи бакалавра є розробка програмної
підсистеми, здатної обробляти зображення документів, виділяти з них структуровану
інформацію та передавати її в інформаційно-аналітичну систему університету у
придатному для подальшої обробки форматі.
Завдання кваліфікаційної роботи бакалавра:
– проаналізувати предметну область та існуючі підходи до розпізнавання
академічних документів;
– спроектувати мікросервісну архітектуру та взаємодію Python-сервісу з
університетською системою (Java/Spring Boot backend і Angular frontend);
– реалізувати процес розпізнавання тексту за допомогою PaddleOCR та виділення
сутностей за допомогою GLiNER2;
– розробити модуль очищення даних для нормалізації дат і перевірки коректності
ПІБ;
– імплементувати семантичне зіставлення назв дисциплін із використанням
ChromaDB і Sentence Transformers;
– реалізувати API-ендпоїнти (/api/process-image та /api/match) і протестувати
підсистему на коректність обробки типових і граничних сценаріїв.
12
Об’єкт дослідження: методи, алгоритми та програмні засоби OCR, NER,
семантичного зіставлення і постобробки даних, які забезпечують інтелектуалізоване
розпізнавання та передавання інформації.
Предмет дослідження: Інтелектуалізована інформаційна підсистема імпорту
навчальних здобутків студентів з документів до Інформаційно-аналітичної системи
університету.
Методи дослідження. У роботі використано системний аналіз та аналіз і синтез
програмних рішень для проєктування архітектури системи. Застосовано методи
комп’ютерного зору (OCR) та обробки природної мови (NER) для екстракції
неструктурованих даних. Використано векторний пошук для реалізації алгоритмів
семантичного зіставлення. Також застосовано порівняльний аналіз і тестування
програмного забезпечення для перевірки коректності роботи підсистеми та оцінки її
ефективності.
13
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ
1.1 Характеристика процесу імпорту навчальних здобутків
Імпорт навчальних здобутків студентів до інформаційно-аналітичної системи
університету є не просто операцією перенесення даних із одного носія на інший. Це
багатоетапний процес, у якому документ спочатку має бути розпізнаний, потім
інтерпретований, нормалізований, зіставлений з довідниками й лише після цього
записаний до цільової системи. У реальній роботі університетських підрозділів у цей
процес включаються різні типи документів: скановані сертифікати, довідки про
завершення курсу, витяги з результатами, додатки до дипломів, роздруківки з
електронних платформ і навіть фотографії, зроблені з екрана або на мобільний
пристрій.
Кожен із перелічених типів джерел має свої особливості. Частина документів
містить таблиці, рамки, декоративні елементи або водяні знаки; інші мають
нерівномірну якість зображення, перекоси, розмиття або стиснення. Під час ручного
введення оператор змушений самостійно шукати потрібні поля, визначати, чи є назва
дисципліни коректною, перевіряти дати, а також зіставляти дані зі студентською
карткою. Саме тому автоматизований імпорт повинен не лише розпізнати текст, а й
бути здатним до контекстного аналізу результату.
У межах університетської системи імпорт навчальних здобутків виконує кілька
функцій одночасно. По-перше, він забезпечує формування актуальної картки
студента. По-друге, він створює базу для аналітики щодо результатів навчання,
академічної мобільності й участі студентів у зовнішніх освітніх заходах. По-третє, він
підтримує документообіг, оскільки дані, витягнуті з документів, можуть бути
використані для формування довідок, наказів, зведених відомостей і звітів. Таким
чином, якість Інтелектуалізованої інформаційної підсистеми імпорту навчальних
здобутків студентів безпосередньо впливає на якість управління освітнім процесом.
Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків
студентів, розглянута в роботі, орієнтована на опрацювання зображень документів і
передачу результатів у вигляді структурованого JSON-представлення. У ньому для
14
кожного документа можуть бути визначені назва установи, ПІБ студента, назви
дисциплін або освітніх компонентів, дати початку і завершення навчання, дата видачі
документа та інші суттєві ознаки. Саме структурованість вихідних даних є критично
важливою, оскільки вона дозволяє основній інформаційній системі виконувати
подальшу валідацію, зіставлення та запис без додаткового ручного втручання.
1.2 Аналіз існуючих підходів і рішень
Аналізуючи сучасний стан ринку систем інтелектуальної обробки документів
(Intelligent Document Processing — IDP), можна відзначити, що існуючі комерційні
рішення переважно орієнтовані на фінансовий сектор, логістику або юридичну сферу,
де документообіг є високого стандарту. Спеціалізовані продукти для освітньої галузі,
які б враховували специфіку обробки академічних сертифікатів, дипломів та довідок
про неформальну освіту, на українському ринку практично відсутні.
Під час аналізу підходів до автоматизованого перенесення даних з документів
можна виділити три базові групи рішень: ручне введення, системи на базі жорстких
шаблонів (Enterprise OCR) та системи на базі штучного інтелекту (хмарні або локальні
ML-моделі).
Перша група рішень базується на повністю ручному введенні даних
співробітниками деканатів. Цей метод не вимагає фінансових витрат на розгортання
програмної інфраструктури та характеризується високою гнучкістю, оскільки
оператор здатна інтерпретувати будь-які нестандартні ситуації. Однак такий підхід
погано масштабується і є способом з найбільшими затратами часу, що призводить до
затримок у формуванні рейтингів та академічних довідок під час сесійного контролю.
Значний вплив людського фактору створює ризик механічних помилок при
перенесенні оцінок та назв дисциплін, що не відповідає вимогам до швидкої обробки
великих масивів документів.
Друга група рішень спирається на шаблонне розпізнавання (Template-based
OCR). Одним із найбільш технологічно досконалих рішень у цій сфері є платформа
ABBYY FlexiCapture. Це потужне програмне забезпечення класу Enterprise, яке
15
дозволяє створювати складні сценарії розпізнавання та верифікації даних [1]. Вигляд
головної сторінки цього сервісу подано на рисунку 1.1.
Рисунок 1.1 – Веб-сайт сервісу ABBYY FlexiCapture [1]
Головною перевагою даного підходу є висока точність розпізнавання
кириличних текстів. Шаблонні системи виявляються зручними в тих випадках, коли
всі документи надходять з одного джерела і мають стабільне розташування полів.
Проте для університету така ситуація не є характерною, оскільки сертифікати
надходять від різних освітніх платформ (Coursera, Udemy, Prometheus), внутрішніх
підрозділів та зовнішніх організацій. Впровадження такої системи стикається з
суттєвими перешкодами: високою вартістю ліцензування для бюджетних установ та
необхідністю вручну налаштовувати зони розпізнавання для кожного нового макета.
Навіть незначна зміна дизайну сертифіката порушує весь процес екстракції.
Третя група рішень використовує машинне навчання, сучасні алгоритми OCR
та обробки природної мови (NLP) для аналізу документів довільної форми. На ринку
цей підхід представлений потужними хмарними сервісами, лідером серед яких є
Google Document AI. На відміну від шаблонних рішень, хмарні моделі здатні
адаптуватися до неструктурованих документів, автоматично виявляючи ключові
сутності незалежно від їх розташування на сторінці. Це забезпечує швидке
розгортання без власної інфраструктури [2]. Однак для українського освітнього
16
простору критичним недоліком є питання конфіденційності: передача персональних
даних студентів на закордонні сервери створює ризики порушення законодавства.
Крім того, транзакційна модель оплати (pay-as-you-go) ускладнює прогнозування
бюджету.
З огляду на це, оптимальним шляхом є розробка власної архітектури на базі
відкритих ML-моделей. Сучасні відкриті OCR-системи значно покращили якість
розпізнавання, однак для імпорту даних одного тексту недостатньо. Розпізнаний
текст необхідно інтерпретувати: визначити, де назва установи, де дата, а де —
освітній компонент. У розроблюваній Інтелектуалізованій інформаційній підсистемі
імпорту навчальних здобутків студентів закладено гібридну комбінацію: OCR
(PaddleOCR) створює текстову основу, а NER (на базі архітектури Transformer, як-от
GLiNER2) визначає значущі сутності, після чого модуль постобробки приводить їх
до єдиного формату.
Окремим викликом є зіставлення назв дисциплін. У різних документах одна й
та сама дисципліна може подаватися скорочено, з помилками або в різних мовних
варіантах. Тому замість точного пошуку доцільно використовувати семантичне
зіставлення за допомогою ембеддингів (Sentence Transformers) та векторної бази
даних (ChromaDB). Це дозволяє порівнювати змістові ознаки текстів, забезпечуючи
автоматичний пошук найближчої відповідності. Результати порівняння основних
підходів наведено у таблиці 1.1.
Таблиця 1.1 – Порівняння підходів до імпорту навчальних здобутків
Підхід Переваги Недоліки Висновок
Ручне Простота, Висока Доцільне лише для
введення гнучкість, не трудомісткість, дуже малих обсягів
потребує помилки документів
складної оператора, низька
інфраструктури швидкість
17
Продовження таблиці 1.1
Підхід Переваги Недоліки Висновок
Шаблонний Швидка обробка Чутливість до Підходить для
OCR документів змін макета, закритих і стабільних
(Enterprise) єдиного висока вартість форм документів
формату, висока ліцензій
точність
Хмарні AI Висока Ризики для Обмежене
сервіси адаптивність, конфіденційності використання через
(Document відсутність даних, вимоги до захисту
AI) власної непередбачувані персональних даних
інфраструктури витрати
Локальний Підтримує Складніша Найбільш придатне
ML (OCR + нестандартні архітектура рішення для
NER + макети, нечітке розробки, потреба інтелектуалізованого
Векторний зіставлення у власних імпорту в ЗВО
пошук) сутностей, обчислювальних
безпека даних ресурсах
Підсумовуючи проведений аналіз, можна стверджувати, що жодне з
розглянутих готових комерційних рішень не задовольняє повною мірою потреби
університету. Вони є або занадто дорогими та жорсткими, або несуть ризики безпеки
даних, тоді як ручна праця є абсолютно неефективною. Це повністю обґрунтовує
доцільність розробки власної Інтелектуалізованої інформаційної підсистеми імпорту
18
навчальних здобутків студентів на базі відкритих технологій машинного навчання.
Таке рішення дозволяє поєднати адаптивність сучасних нейромереж із безпекою
локальної обробки даних та безшовною інтеграцією з існуючою Інформаційно-
аналітичною системою університету.
1.3 Вимоги до функціонування та якості
Функціональні вимоги до Інтелектуалізованої інформаційної підсистеми
імпорту навчальних здобутків студентів випливають із її місця в загальній архітектурі
університетської інформаційно-аналітичної системи. Система повинна приймати
документ у вигляді зображення, перевіряти формат та розмір файлу, виконувати
оптичне розпізнавання тексту, виділяти значущі сутності, нормалізувати результати,
а далі повертати структурований набір даних. Окремо необхідно забезпечити
механізм семантичного зіставлення назв дисциплін із наявним каталогом, щоб
оператор або інша частина системи могли вибрати коректний запис без ручного
пошуку.
Нефункціональні вимоги є не менш важливими. По-перше, система має бути
стійкою до помилкових або нестандартних вхідних даних, оскільки у практиці
документообігу завжди трапляються пошкоджені файли, неякісні фотографії або
скан-копії з низьким контрастом. По-друге, необхідна достатня продуктивність, щоб
обробка одного документа не створювала затримок для черги користувачів. По-третє,
слід передбачити безпечну взаємодію з основним backend, зокрема перевірку розміру
файлу, валідацію вхідних байтів і обмеження доступу до внутрішніх сервісів.
До вимог якості також належить локалізація. Оскільки система застосовується
в українському університеті, моделі та алгоритми повинні коректно працювати з
українською мовою, а також за потреби підтримувати англійські фрагменти. Це
стосується не лише OCR, а й обробки дат, назв навчальних компонентів і назв
установ. Тому в роботі був застосований набір інструментів, орієнтованих на
багатомовне середовище та на реалії українського освітнього документообігу.
Окремою вимогою є відтворюваність і супровідність рішення. Програмна
система повинна мати чітко визначену структуру файлів, модульну будову, зрозумілі
19
точки інтеграції та конфігураційні параметри, що дозволяє замінювати або
вдосконалювати окремі компоненти без повного перепроєктування. Саме тому у
роботі було обрано мікросервісну схему, де окремий Python-сервіс зосереджений на
інтелектуальній обробці документів, а основна бізнес-логіка реалізується у Java
backend.
Висновки до розділу 1
Проведений аналіз показав, що проблема імпорту навчальних здобутків
студентів має комплексний характер і не може бути якісно вирішена лише засобами
ручного введення або простого шаблонного розпізнавання. Для університетського
середовища характерні документи різної структури, різного рівня якості та з
неоднаковими мовними формами подання інформації, тому потрібен гнучкий
інтелектуалізований підхід.
Доцільним є поєднання OCR, розпізнавання іменованих сутностей,
постобробки даних та семантичного зіставлення назв дисциплін. Така комбінація
дозволяє перетворити неструктурований документ у структурований набір даних,
придатний для внесення до інформаційно-аналітичної системи університету. Отже, у
наступному розділі доцільно перейти до проєктування архітектури та вибору методів,
що забезпечують реалізацію цих функцій.
20
2 ПРОЄКТУВАННЯ АРХІТЕКТУРИ ТА МЕТОДІВ ОБРОБКИ
2.1 Архітектура мікросервісного рішення
У межах кваліфікаційної роботи бакалавра розроблювана Інтелектуалізована
інформаційна підсистема імпорту навчальних здобутків студентів розглядається як
окремий інтелектуальний шар у складі багатосервісної університетської платформи.
Вихідною точкою архітектури є розмежування зон відповідальності: Angular frontend
відповідає за взаємодію з користувачем, Java/Spring Boot backend забезпечує бізнес-
логіку, авторизацію та зв’язок із базою даних, а Python-сервіс виконує ресурсоємні
операції комп’ютерного зору й обробки природної мови. Таке розділення підвищує
гнучкість системи і дає змогу масштабувати окремі компоненти незалежно один від
одного.
Архітектура обрана мікросервісною не випадково. OCR-моделі, моделі NER та
векторні індекси для семантичного пошуку мають великі розміри, потребують
окремого середовища виконання і мають відмінні вимоги до ресурсів. Якщо б вони
були вбудовані безпосередньо в основний backend, це ускладнило б розгортання,
підвищило б навантаження на JVM і погіршило б супровідність. Виділення
інтелектуальної обробки в окремий сервіс дозволяє зберегти чисту бізнес-логіку
основного додатка та швидко оновлювати моделі без втручання в ядро системи.
Комунікація між сервісами реалізована через HTTP-запити у стилі REST, що
більш детально описана в таблиці 2.1.
Таблиця 2.1 – Опис доступних URL-адрес
Ендпоїнт Метод Призначення Основні перевірки
Тип файлу, розмір,
/api/process- Розпізнавання тексту
POST ідентифікатори формату
image з документа
файлу, доступність OCR
Семантичне
Наявність масивів, коректність
/api/match POST зіставлення назв
форматів, доступ до індексу
курсів
21
У випадку імпорту документів Java backend приймає зображення від frontend,
перевіряє права доступу користувача, а потім пересилає файл до Python-сервісу. Після
цього сервіс повертає структуровану відповідь, яку backend додатково зіставляє зі
студентською базою, наприклад за допомогою нечіткого порівняння ПІБ та назв
установ. Така схема забезпечує послідовну обробку даних і не перевантажує
користувацький інтерфейс складною логікою.
Другий сценарій взаємодії стосується зіставлення назв дисциплін. Тут Python-
сервіс не працює із зображенням, а приймає масив назв ідентифікованих або
невизначених курсів та повертає відповідність до довідника. Цей сценарій корисний
у тих випадках, коли назви освітніх компонентів відрізняються від записів у
локальній базі, але за змістом належать до одного й того ж курсу. Завдяки цьому
Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків студентів
здатна підтримувати як імпорт, так і подальшу нормалізацію навчальних записів.
2.2 Модель даних і сценарії обробки
Базова модель даних Інтелектуалізованої інформаційної підсистеми імпорту
навчальних здобутків студентів побудована навколо набору сутностей, які
найчастіше зустрічаються в академічних документах. До них належать назва
навчального закладу, ПІБ студента, назва дисципліни або освітньої програми, дата
видачі документа, дати початку та завершення навчання, а також службові поля для
відстеження стану обробки. Для кожної сутності важливо не лише виділити текст, а й
привести його до однакового формату, оскільки саме від цього залежить подальше
автоматичне зіставлення з базою даних.
Сценарій обробки документа починається з моменту, коли користувач
завантажує файл через вебінтерфейс або коли backend передає його до ML-сервісу.
Спочатку система виконує валідацію файлу за розміром і типом, перевіряючи
ідентифікатори формату файлів JPEG та PNG. Потім зображення декодується
OpenCV, після чого запускається OCR-двигун PaddleOCR. Отриманий текстовий шар
22
є відправною точкою для наступного етапу — виділення сутностей за допомогою
GLiNER2.
Після розпізнавання система отримує текстові фрагменти, що можуть містити
шум, зайві переноси рядків, повтори або неправильні символи. Саме тому потрібен
окремий модуль очищення. У ньому виконуються нормалізація пробілів, перевірка
коректності україномовних імен, стандартизація дат та усунення дублікатів. Такий
підхід дає змогу не передавати до основної системи сирі результати розпізнавання, а
одразу формувати дані, які можна зберігати або зіставляти без додаткових ручних
перевірок.
Для курсового зіставлення використовується окрема модель потоку. Довідник
дисциплін спочатку зчитується з основного backend, після чого записи
векторизуються й розміщуються в ChromaDB. Далі кожна невизначена назва
перетворюється на ембеддинг, і система виконує пошук найбільш схожих документів
за косинусною подібністю. Отримане зіставлення повертається у зворотному вигляді:
від відомого ідентифікатора до списку назв, які були з ним пов’язані. Така схема
полегшує подальший імпорт і групування даних. У таблиці 2.2 подані основні
сутності та поля вихідних даних.
Таблиця 2.2 – Основні сутності та поля вихідних даних
Сутність Поле Призначення
file_name, file_type, Контроль джерела та
Документ
file_size первинна валідація
Назва закладу, що видав
Установа educational_institution
документ
Студент student_name ПІБ власника документа
Навчальний Назва дисципліни або
course_name
компонент програми
date, study_started, Життєвий цикл навчального
Дати
study_finished здобутку
Службові дані confidence, status, metadata Контроль якості та інтеграції
23
2.3 Методи OCR, NER та семантичного зіставлення
Оптичне розпізнавання символів виконує роль первинного перетворювача
зображення у текст. У роботі для цього використано PaddleOCR, оскільки цей
інструмент демонструє стійкість до реальних сканів, підтримує українську мову і
дозволяє отримувати не лише текст, а й оцінку впевненості для кожного фрагмента.
У практичному сенсі це важливо, бо система не повинна однаково довіряти як чіткому
друкованому рядку, так і фрагменту, який був розпізнаний на межі шуму [3].
Після OCR у справу вступає розпізнавання іменованих сутностей. GLiNER2
було обрано тому, що модель здатна працювати з мульти-мовним текстом і не вимагає
жорстко заданої схеми вхідних шаблонів [7]. Для задачі імпорту навчальних
здобутків це означає, що система може виділяти назву установи, ПІБ студента, назву
дисципліни та дату навіть у випадку, коли порядок цих елементів змінюється. Таким
чином, модель працює не як простий парсер, а як інструмент семантичного
витягування змістовних фрагментів.
Семантичне зіставлення назв дисциплін потребує окремого підходу, оскільки
документальні формулювання можуть суттєво відрізнятися від каталожних записів.
Для цього у Інтелектуалізованій інформаційній підсистемі імпорту навчальних
здобутків студентів застосовано Sentence Transformers, які перетворюють текст у
векторне подання, та ChromaDB, яка зберігає ці вектори і виконує пошук найближчих
сусідів[6]. Коли назва дисципліни з документа перетворюється на ембеддинг, система
шукає найбільш близький запис у довіднику та повертає результат за принципом
найвищої подібності. З погляду математичної постановки маємо послідовність
перетворень: документ D проходить через OCR-функцію O, далі через функцію
виділення сутностей N, а після цього через функцію семантичного зіставлення S.
Тобто результат можна описати як S(N(O(D))). Така композиція показує, що кожний
етап використовує вихід попереднього і формує нову, більш структуровану
репрезентацію даних. Нижче на рисунках 2.1, 2.2 та 2.3 наведено узагальнені
алгоритми роботи її основних модулів. Вони відображають логіку без прив’язки до
конкретного синтаксису реалізації і придатні для опису функціональних вимог.
24
Рисунок 2.1 – Алгоритм обробки зображення сертифіката
25
Рисунок 2.2 – Алгоритм семантичного зіставлення назв дисциплін
Рисунок 2.3 – Алгоритм очищення даних після OCR
26
2.4 Питання безпеки, надійності та продуктивності
Безпека Інтелектуалізованої інформаційної підсистеми імпорту навчальних
здобутків студентів починається з перевірки вхідних файлів. Якщо система приймає
завантаження з інтерфейсу без додаткової перевірки, то зростає ризик підміни MIME-
типів, передавання шкідливих файлів або перевантаження сервісу надмірно великими
вкладеннями. Тому в проєкті було встановлено контроль розміру файлу на рівні 10
МБ, а також перевірку ідентифікатору формату файлів JPEG і PNG. Це суттєво
зменшує площу атаки та гарантує, що до OCR надходитимуть лише допустимі
зображення.
Надійність сервісу забезпечується ще й тим, що інтелектуальні моделі
ізольовані в окремому контейнері виконання. Таке рішення знижує ризики для
основного backend і дозволяє при потребі перезапускати або оновлювати моделі без
зупинки всієї системи. Додатково використано механізми локального кешування
даних для модуля зіставлення назв курсів. Це зменшує кількість запитів до основного
Java backend і підвищує стійкість роботи у випадку короткочасної недоступності
зовнішнього джерела.
Продуктивність у проєкті підтримується кількома способами. По-перше, OCR і
NER завантажуються як сінглтони, щоб уникнути повторної ініціалізації важких
моделей. По-друге, у коді передбачено роздільні блокування для OCR і NER, що
дозволяє керувати доступом до моделей у багатопотоковому середовищі. По-третє,
для семантичного пошуку використовується локальна векторна база, що прискорює
пошук без звернення до віддалених сервісів при кожному запиті.
Ще один аспект надійності пов’язаний із коректною реакцією на помилки.
Сервіс не повинен повертати користувачу внутрішні трасування або технічні деталі
бібліотек, оскільки це ускладнює діагностику, але може розкривати зайву інформацію
про внутрішню інфраструктуру. Тому для помилок валідації використовуються
зрозумілі повідомлення, а для внутрішніх збоїв — узагальнені відповіді. Такий підхід
робить систему безпечнішою і зручнішою для експлуатації.
27
У таблиці 2.3 наведено розширений каталог типових помилок, з якими може
зіштовхнутися сервіс під час роботи. Кожен запис містить короткий опис ситуації та
спосіб реакції системи.
Таблиця 2.3 – Каталог типових помилок
№ Код Ситуація Реакція Примітка
Повернути
Відсутній Контроль на
повідомлення
файл або рівні
1 400 про
порожній приймання
обов’язковість
запит запиту
параметра file
Відхилити
Непідтримува файл і
2 400 ний формат пояснити JPEG / PNG
файлу допустимі
формати
Повернути
Помилка OCR Не розкривати
узагальнену
3 500 або збій технічні деталі
внутрішню
моделі клієнту
помилку
Неповний
текстовий Передати Потрібна
4 200/partial результат частково ручна
після заповнені дані верифікація
розпізнавання
Також подано приклади конфігураційних параметрів, які використовуються
Інтелектуалізованою інформаційною підсистемою імпорту навчальних здобутків
студентів. Їх наявність дозволяє відокремити код від середовища виконання та
швидко адаптувати систему до нового розгортання. Вони подані у вигляді довідкової
таблиці 2.4, щоб їх було зручно використовувати під час розгортання.
28
Таблиця 2.4 – Опис параметрів налаштування
Параметр Значення Призначення
Токен доступу до Java Bearer-автентифікація
AUTH_TOKEN
backend внутрішніх запитів
Контроль кількості
SCORE Поріг релевантності
кандидатів у пошуку
Базовий URL для
REMOTE_REPO_URL Адреса джерела курсів
отримання довідника
workers Кількість worker-процесів Gunicorn configuration
bind Адреса прив’язки сервера Gunicorn configuration
Захист від надмірного
file size limit 10 МБ
навантаження
Скорочення поверхні
supported types JPEG, PNG
атаки
Підтримка української
OCR language uk
мови
Орієнтація на високу
NER threshold 0.1
повноту
Відсікання слабких
OCR confidence 0.6
результатів
Конфігурація сервера Gunicorn, а також розширений каталог типових помилок
із механізмами реакції системи наведені у додатку В.
Висновки до розділу 2
На етапі проєктування було встановлено, що найдоцільнішою є мікросервісна
архітектура з виділенням інтелектуальної обробки в окремий Python-сервіс. Такий
підхід дає змогу поєднати надійну бізнес-логіку університетської системи з гнучкою
обробкою документів, а також спрощує супровід і оновлення моделей.
29
Визначені моделі даних, сценарії обробки та вимоги до безпеки створили
основу для наступного етапу — програмної реалізації. У подальшому розділі
доцільно розглянути структуру проєкту, реалізацію API-ендпоїнтів, засоби очищення
даних і механізми інтеграції з основним backend.
30
3 ПРОГРАМНА РЕАЛІЗАЦІЯ ІНТЕЛЕКТУАЛІЗОВАНОЇ ІНФОРМАЦІЙНОЇ
ПІДСИСТЕМИ ІМПОРТУ НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ
3.1 Структура проєкту і технологічний стек
Практична реалізація Інтелектуалізованої інформаційної підсистеми імпорту
навчальних здобутків студентів виконана на мові Python 3.11+ із використанням
фреймворку Flask 3.0 як легкого HTTP-ядра для побудови API. Такий вибір
пояснюється тим, що саме Python має зрілу екосистему для OCR, обробки тексту,
ембеддингів і роботи з векторними базами, а Flask дає змогу зосередитися на бізнес-
логіці без надлишкової складності. Для продуктивного запуску в режимі сервера
використано Gunicorn із кількома робочими процесами.
Структура проєкту побудована модульно: окремий файл відповідає за точку
входу в API, окремі каталоги містять сервіси для розпізнавання документів та
зіставлення курсів, а допоміжні утиліти займаються комунікацією з Java backend.
Такий підхід спрощує розуміння коду, дає змогу локалізувати помилки та полегшує
подальше розширення функціональності. Крім того, у проєкті використовуються
типи Python відповідно до PEP 484, що покращує читабельність і дає змогу краще
контролювати структуру даних. Організація модулів підсистеми відображає чітке
розділення зон відповідальності між точкою входу, бізнес-логікою та утилітами.
Детальна деревоподібна структура каталогів та файлів розробленого мікросервісу
deanoffice_python_services з описом функціонального призначення кожного елемента
наведена у Додатку А.
До складу технологічного стеку входять OpenCV для декодування зображень,
PaddleOCR для оптичного розпізнавання, GLiNER2 для виділення сутностей,
dateparser для нормалізації дат[5], ChromaDB для векторного пошуку, Sentence
Transformers для побудови ембеддингів, requests для HTTP-запитів і python-dotenv для
керування конфігурацією через файл середовища. Усі ці засоби взаємно доповнюють
один одного, створюючи повноцінний конвеєр інтелектуальної обробки документів.
Окремо слід відзначити роль історичного каталогу `cert-rec`, який у межах
проєкту демонструє попередні експериментальні дослідження на основі LayoutLMv3.
31
Хоча цей напрям не є активним виробничим компонентом, він важливий як етап
еволюції рішень, оскільки показує перехід від вузькоспеціалізованого розуміння
документівLayoutLM до більш гнучкого і практичного поєднання OCR, NER та
семантичного пошуку. Схему архітектури, що відображає поділ на frontend, backend
та ML-сервіс, подано на рисунку 3.1.
Рисунок 3.1 – Загальна архітектура Інтелектуалізованої інформаційної підсистеми
імпорту навчальних здобутків студентів
3.2 Реалізація обробки зображень сертифікатів
Сервіс обробки зображень реалізує ендпоїнт POST /api/process-image, який
приймає файл у форматі multipart/form-data. Після отримання запиту виконується
перевірка наявності файлу, контроль його розміру і перевірка ідентифікаторів
формату файлу для JPEG та PNG. Лише після успішної валідації байти передаються
до OpenCV для декодування, що запобігає спробам обробки некоректних або
небезпечних вхідних даних [9].
Для забезпечення універсальності розроблених рішень логіка обробки даних
була формалізована у вигляді абстрактних процедур. Специфікація REST-
інтерфейсів, приклади структур запитів, а також розгорнутий псевдокод конвеєра
обробки сертифікатів та семантичного зіставлення назв дисциплін детально
розглянуті у Додатку Б.
На етапі OCR сервіс використовує модель PaddleOCR з українською мовною
конфігурацією. У результаті розпізнавання отримується набір фрагментів тексту з
оцінками впевненості. Фрагменти, чий показник нижчий за встановлений поріг,
відкидаються, а решта об’єднуються в один текстовий блок. Такий підхід допомагає
32
зменшити кількість випадкових шумових символів і підвищує якість наступного
етапу NLP-аналізу [3].
Для виділення сутностей застосовується GLiNER2, який аналізує текст і
повертає набір об’єктів із мітками educational_institution, course_name, student_name,
date, study_started і study_finished. Цей перелік спеціально підібрано так, щоб
покривати найважливіші поля типового академічного документа. Навіть якщо
документ подано в нетиповому макеті, модель здатна знайти ці сутності за їхнім
смисловим значенням, а не за жорстким шаблоном.
Після завершення NER результат проходить стадію очищення. Тут
вирівнюються пробіли, переводяться у стандартизований вигляд дати, перевіряється
частка українських символів у ПІБ, а також видаляються дублікати. У підсумку
формується JSON-структура, яку легко інтегрувати з Java backend і зберігати в
подальших транзакціях. Така реалізація дає змогу відокремити технічний шум від
змістовних даних. Схему, що відображає послідовність OCR, NER та очищення
даних, подано на рисунку 3.2.
Рисунок 3.2 – Потік обробки документа від завантаження до структурованого
результату
3.3 Реалізація зіставлення назв дисциплін
Другий ключовий сценарій Інтелектуалізованої інформаційної підсистеми
імпорту навчальних здобутків студентів реалізовано в ендпоїнті POST /api/match.
Його призначення полягає у семантичному зіставленні назв дисциплін, отриманих з
документів або з проміжних джерел, із каталогом відомих курсів у основному
33
backend. Такий механізм потрібен тоді, коли назви подані з відхиленнями,
скороченнями або у варіативних мовних формах, а точне текстове порівняння не
забезпечує потрібної якості.
Для цього використано Sentence Transformers, які перетворюють назву
дисципліни у щільне векторне подання. Векторний простір має властивість групувати
семантично близькі фрази ближче одна до одної, що відкриває можливість знаходити
найбільш подібні назви не лише за буквальним збігом, а й за змістом [10]. Саме ця
властивість є визначальною для задачі нормалізації освітніх компонентів.
Збереження і пошук векторів виконується через ChromaDB [6]. Після старту
сервісу або після оновлення кешу з Java backend завантажуються актуальні назви
дисциплін, які перетворюються на документи LangChain і записуються до локального
сховища. Далі для кожної невизначеної назви обчислюється її ембеддинг і
здійснюється пошук найближчих сусідів. Вихідними даними стає словник, де кожен
ідентифікатор курсу отримує список назв, що були до нього прив’язані.
Важливо, що реалізація не покладається на один жорсткий поріг схожості.
Значення порога можна регулювати через конфігураційний параметр, а це означає,
що система може бути налаштована залежно від того, чи потрібно їй працювати більш
консервативно, чи навпаки — ширше охоплювати варіанти написання назв. Така
гнучкість особливо цінна у навчальному середовищі, де назви дисциплін часто
еволюціонують разом із навчальними планами. Схему, що пояснює роль ембеддингів
і векторного сховища ChromaDB, подано на рисунку 3.3.
Рисунок 3.3 – Схема семантичного зіставлення назв курсів
34
3.4 Додаткові модулі очищення та інтеграції
Після основного етапу розпізнавання в системі працює модуль очищення даних.
Його завдання полягає не в новому розпізнаванні, а в приведенні вже отриманих
фрагментів до канонічного виду. У межах цього модуля виконується нормалізація
множинних пробілів, видалення зайвих символів переносу, перевірка дат через
dateparser і обробка випадків, коли дата записана в тексті не в класичному форматі.
Таке постопрацювання суттєво знижує навантаження на основний backend.
Модуль інтеграції з Java backend реалізовано через окремий клієнт HTTP-
запитів. Він читає адресу віддаленого сервера з конфігурації, додає bearer-токен
авторизації і отримує актуальні дані про дисципліни з ендпоїнта довідника. Завдяки
цьому Python-сервіс не містить дубльованої бізнес-логіки та не зберігає ручних
списків курсів, що полегшує супровід і зменшує ризик розсинхронізації даних.
Корисним компонентом стала також розробка демонстраційних скриптів. Вони
дають змогу окремо перевіряти лише логіку розпізнавання або лише логіку очищення
без повного запуску веб-сервісу. Такий підхід зручний для налагодження і
тестування, оскільки дає змогу швидко повторювати одні й ті самі сценарії на
прикладних тестових зображеннях. У межах навчального проєкту це особливо
важливо, оскільки дозволяє покроково перевірити поведінку кожного модуля.
Загалом програмна реалізація базується на принципі розділення
відповідальностей. Окремі класи відповідають за OCR, за NER, за очищення, за
доступ до векторної бази, за побудову запитів і за зворотну інтеграцію з основною
системою. Така модульність робить код не лише зрозумілим, а й стійким до змін:
будь-який блок можна доопрацювати без порушення всієї схеми взаємодії.
Перехід від етапу розробки до промислового використання потребує чіткого
дотримання регламенту синхронізації даних та моніторингу працездатності сервісу.
Покрокові інструкції щодо розгортання, щоденного технічного супроводу, оновлення
залежностей та резервного копіювання локальних векторних індексів містяться у
додатку Г.
35
3.5 Інтеграція з основною інформаційною системою
Інтеграційний сценарій побудований так, щоб користувач сприймав систему як
єдиний сервіс, хоча фактично обробка виконується декількома незалежними
компонентами. Angular frontend передає файл або дані курсу до Java backend, backend
перевіряє авторизацію, а потім звертається до Python-сервісу. Отриманий результат
знову повертається в backend, де може бути зв’язаний із локальними записами
студентів, спеціальностей або навчальних планів.
Така схема дає змогу не лише автоматизувати імпорт, а й зберігати контроль
над остаточним прийняттям рішення. У випадку неоднозначного результату система
може повернути кілька кандидатів або поради для оператора. Це важливо, оскільки
повністю автономне прийняття рішення не завжди є прийнятним у процесах, де
помилка може вплинути на офіційний облік студента. Тому Інтелектуалізована
інформаційна підсистема імпорту навчальних здобутків студентів поєднує
автоматизацію з можливістю людського контролю.
З технічного погляду інтеграція реалізована через стандартизовані JSON-
відповіді. Це спрощує подальший розвиток системи, оскільки зовнішні компоненти
не залежать від внутрішньої структури класів Python-сервісу. Якщо потрібно буде
додати нові поля, наприклад рівень сертифікації, модуль курсу або зовнішню
ідентифікацію документа, це можна зробити через розширення схеми відповіді без
повної переробки сервісу.
Висновки до розділу 3
У програмній частині роботи реалізовано два основні сценарії: розпізнавання й
структуризацію даних з документів та семантичне зіставлення назв дисциплін.
Обидва сценарії спираються на модульну архітектуру, що відокремлює обробку
зображень, обробку тексту, постобробку та інтеграцію з основним backend.
Практична реалізація підтвердила доцільність використання Flask, PaddleOCR,
GLiNER2, ChromaDB і Sentence Transformers для задачі інтелектуалізованого імпорту
навчальних здобутків. Наступний розділ присвячено тестуванню розробленої
36
Інтелектуалізованої інформаційної підсистеми імпорту навчальних здобутків
студентів та оцінці її поведінки в типових і нетипових сценаріях.
37
4 ТЕСТУВАННЯ ТА ВВЕДЕННЯ В ЕКСПЛУАТАЦІЮ
4.1 Підхід до тестування
Тестування розробленої Інтелектуалізованої інформаційної підсистеми імпорту
навчальних здобутків студентів було орієнтоване не лише на перевірку того, чи
запускається програма без помилок, а насамперед на підтвердження коректності її
поведінки в реальних умовах експлуатації. Оскільки система працює з
неструктурованими документами, важливо оцінити її здатність реагувати на якість
зображення, на відмінності у форматі даних і на наявність шуму в OCR-результаті.
Тому перевірка включала як функціональні, так і негативні сценарії.
Основою тестування стали приклади документів різного типу, зокрема тестові
зображення сертифікатів і фрагменти довідкових наборів для зіставлення курсів. При
цьому увага приділялася коректності потоків даних: чи вдається отримати відповідь
після завантаження файлу, чи правильно нормалізуються дати, чи зберігається
структурованість JSON і чи повертає система коректну відповідь на запит до
векторної бази. Такий підхід дозволяє оцінювати не окремі функції, а весь ланцюг
обробки.
Окрім технічної перевірки, важливою була логічна верифікація результатів. Для
цього аналізувалися значення, які повертає OCR, а також список сутностей, виділених
GLiNER2. Якщо в документі були очевидні реквізити, система мала їх знайти без
ручного втручання. Якщо ж документ містив неякісний фрагмент або сумнівну назву
курсу, очікувалася або знижена впевненість, або кілька кандидатів на зіставлення.
Отже, тестування враховувало не лише факт успіху, а й адекватність результату.
4.2 Функціональні перевірки
Функціональні перевірки охоплювали основні точки входу системи. У першому
наборі сценаріїв перевірялося завантаження файлів із допустимими форматами JPEG
і PNG, наявність потрібного поля `file`, а також реакція на перевищення
встановленого обмеження за розміром. У другому наборі перевірялося отримання
38
результату після OCR і NER: чи сформовано структуровані списки полів, чи коректно
очищені значення та чи зберігається цілісність набору сутностей.
Окремий набір сценаріїв стосувався дат. Система мала коректно розпізнавати
як стандартні формати, так і дати, що з’являються всередині текстового речення.
Після нормалізації дата повинна була бути представлена в ISO-подібному форматі
YYYY-MM-DD, оскільки саме такий формат зручний для подальшої роботи з базами
даних, фільтрації і аналітики.
Для зіставлення назв дисциплін перевірялася здатність системи пов’язувати
подібні, але не ідентичні формулювання. Так, назви зі скороченнями, мовними
варіантами або легкими орфографічними відхиленнями мали влучати до правильного
курсу. Ця перевірка була особливо важливою, оскільки саме тут виявляється користь
семантичного пошуку порівняно з точним рядковим порівнянням. Результати
функціонального тестування підтвердили, що окремі модулі взаємодіють послідовно
та узгоджено. Система не лише повертає відповідь, а й зберігає логіку перетворення
сировинних даних у структурований результат. Саме це є головною ознакою того, що
Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків студентів
придатна для інтеграції в реальний університетський процес. Більш детальний опис
подано в таблиці 4.1.
Таблиця 4.1 – Приклади тестових сценаріїв
Сценарій Вхідні дані Очікуваний результат
Завантаження Файл прийнято, розпізнавання
JPEG/PNG до 10 МБ
зображення виконано
Не image або файл з
Пошкоджений файл Повертається помилка валідації
некоректними байтами
Невірний формат PDF або інший тип Файл відхилено
Текстова дата всередині Дата нормалізується або
Дивні дати
речення позначається як null
Варіативна назва Скорочення або
Повертається найближчий курс
дисципліни переклад
39
4.3 Перевірка обробки помилок і нетипових ситуацій
Окрему увагу приділено негативним сценаріям, оскільки саме вони найчастіше
виникають під час експлуатації. До таких сценаріїв належать відсутність файлу в
запиті, спроби передати файл непридатного типу, надмірно великі вкладення,
порожні або майже порожні зображення, а також ситуації, коли OCR повертає надто
мало тексту для надійного виділення сутностей. У всіх цих випадках система повинна
поводитися передбачувано і не падати з внутрішньою помилкою без пояснення.
Нетиповою ситуацією для NER є документ, у якому назва установи або ім’я
студента написані дуже нечітко. У такому разі модуль очищення повинен
відфільтрувати значення, що не відповідають очікуваному мовному складу, а система
не повинна зберігати випадковий шум як коректне ім’я. Подібна логіка є особливо
важливою для україномовного середовища, де якісне розпізнавання ПІБ суттєво
залежить від правильної мови моделі та від чистоти вхідного зображення.
У модулі зіставлення курсів нетиповими вважаються не лише відсутні
значення, а й дуже загальні назви, наприклад короткі фрази або однослівні записи, які
мають слабке семантичне навантаження. У таких випадках доречно або не повертати
жодного зіставлення, або зменшувати рівень довіри до кандидата. Завдяки цьому
Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків студентів
не створює ілюзію точності там, де даних недостатньо.
Тестування негативних сценаріїв показало, що система має реагувати не тільки
на успіх, а й на межові умови. Саме така поведінка дозволяє використовувати її в
умовах реального документообігу, де вхідні дані ніколи не бувають ідеальними. Для
практики це означає, що користувач отримує зрозумілу відповідь навіть тоді, коли
документ виявився нетиповим або неповним.
Для підтвердження надійності підсистеми в умовах реального документообігу
було проведено комплексну валідацію її функціональних компонентів. Повна
матриця тестування, яка включає оцінку поведінки сервісу під час обробки
некоректних форматів, файлів надмірного розміру або часткових текстових
результатів, наведена у додатку Д.
40
4.4 Розгортання та супровід
Розгортання сервісу передбачає два базові режими роботи: режим розробки і
виробничий режим. У режимі розробки Flask запускається локально з вбудованим
сервером, що зручно для налагодження окремих частин коду, а в режимі експлуатації
використовується Gunicorn із кількома worker-процесами. Така конфігурація краще
відповідає вимогам стабільної роботи і дає змогу зменшити ризик простою у випадку
навантаження або помилок одного з процесів.
Супровід Інтелектуалізованої інформаційної підсистеми імпорту навчальних
здобутків студентів зводиться до підтримання актуальності моделей, довідників і
параметрів середовища. Зокрема, при зміні каталогу курсів Python-сервіс має оновити
локальний векторний індекс, а при зміні структури документів — адаптувати логіку
постобробки або мітки сутностей. Саме тому в проєкті передбачено чіткий поділ на
окремі модулі, які можна оновлювати незалежно, не перезаписуючи весь код.
Практичне введення в експлуатацію також пов’язане з організаційними
аспектами. Оскільки система інтегрується в університетський процес, необхідно
передбачити права доступу, логування операцій та можливість відслідковувати, який
саме документ і коли був оброблений. Хоча в межах бакалаврської роботи не всі ці
механізми реалізовані повністю, архітектура Інтелектуалізованої інформаційної
підсистеми імпорту навчальних здобутків студентів вже закладає основу для такого
розширення.
Висновки до розділу 4
Тестування підтвердило працездатність основних сценаріїв Інтелектуалізованої
інформаційної підсистеми імпорту навчальних здобутків студентів та її здатність
адекватно реагувати на типові й нетипові вхідні дані. Особливо важливо, що система
не просто повертає текст, а намагається привести його до структурованого та
придатного для подальшого використання стану.
Розгортання в режимі сервісу та наявність механізмів перевірки помилок
свідчать про готовність проєкту до практичного використання в межах
41
університетського програмного середовища. У наступному розділі розглянуто оцінку
використаних інструментів і перспективи розвитку Інтелектуалізованої
інформаційної підсистеми імпорту навчальних здобутків студентів.
42
5 ОЦІНКА ВИКОРИСТАНИХ ЗАСОБІВ ТА НАПРЯМИ РОЗВИТКУ
5.1 Flask, OpenCV, PaddleOCR та GLiNER2
Flask у межах проєкту виконує роль мінімалістичного, але достатньо гнучкого
каркаса для реалізації API. Його перевага полягає в тому, що розробник може
зосередитися на логіці обробки, а не на складній конфігурації фреймворку [11].
Для невеликого, але інтелектуально насиченого сервісу це є раціональним
вибором, оскільки основні ресурси краще спрямувати на OCR, NER і постобробку, а
не на надлишкову інфраструктуру вебвузла.
OpenCV забезпечує надійне декодування зображення та базові маніпуляції з
ним, що є необхідним під час роботи із завантаженими файлами. Хоча у проєкті не
акцент зроблено на складній комп’ютерній графіці, саме OpenCV дає змогу
безпосередньо працювати з байтами, швидко перетворювати їх на матрицю
зображення і передавати до OCR-двигуна.
Такий підхід відповідає вимогам продуктивності та сумісності з реальними
файлами різного походження [9].
PaddleOCR обрано як практичне й досить стійке рішення для
українськомовного тексту. Воно важливе тим, що працює не тільки з окремими
символами, а й зі словесними блоками, що полегшує подальше виділення реквізитів
[3].
У задачі академічних документів це особливо корисно, бо реквізити можуть
бути розміщені не в єдиному стовпчику, а в багатоколонковому або табличному
макеті.
GLiNER2 підсилює OCR, перетворюючи «сирий» текст на смислово розмічені
сутності. Його значення в проєкті полягає в тому, що він дозволяє перейти від
простого пошуку слів до розуміння ролі кожного фрагмента в документі [7].
Такий рівень інтерпретації і робить Інтелектуалізовану інформаційну
підсистему імпорту навчальних здобутків студентів справді інтелектуалізованою,
оскільки результатом стає не просто текст, а структуровані поля з чітким
призначенням.
43
5.2 ChromaDB, Sentence Transformers і LangChain
Для задачі семантичного зіставлення найбільш придатним виявилося
поєднання Sentence Transformers і ChromaDB. Перший компонент відповідає за
побудову числових представлень тексту, а другий — за їх зберігання та ефективний
пошук. У результаті система може швидко знаходити схожі назви дисциплін навіть у
разі різних мовних форм, часткових скорочень або близьких за змістом формулювань.
Для університетського довідника це значно краще, ніж жорстке порівняння рядків.
LangChain у проєкті використовується як допоміжний шар для роботи з
документами та їхнім розбиттям на елементи, придатні для індексації. Таке рішення
надає додаткову структурованість під час підготовки даних до векторного пошуку.
Хоча сама задача не є типовим сценарієм генеративного ШІ, інфраструктурні
інструменти LangChain у цьому випадку корисні як стандартний спосіб керування
документами, метаданими та конвеєрами перетворення[8].
Однією з переваг векторного підходу є його пристосовність до змін каталогу.
Якщо перелік курсів змінюється, достатньо оновити джерело даних і повторно
проіндексувати колекцію. У традиційній жорстко закодованій схемі довелося б
переписувати правила або вручну доповнювати словники. Завдяки ChromaDB і
ембеддингам рішення лишається відносно незалежним від конкретних назв і краще
масштабується на нові освітні програми.
Потенційним недоліком такого підходу є потреба контролювати поріг схожості
та якість корпусу. Якщо дані в каталозі неактуальні або надто неоднорідні, векторний
пошук може повертати неідеальні кандидати. Саме тому в проєкті реалізовано
конфігураційність параметра порога та окремий етап оновлення даних, що дозволяє
керувати якістю результату без зміни структури коду[6].
5.3 Інтеграція з Java і Angular
Інтеграція Python-сервісу з Java backend і Angular frontend є одним із
найважливіших практичних результатів роботи. Саме через цю інтеграцію
інтелектуальна обробка документів перестає бути ізольованим демонстраційним
44
фрагментом і стає частиною університетського бізнес-процесу. Користувач взаємодіє
лише з вебінтерфейсом, однак на рівні системи запускається ланцюг, у якому кожен
компонент виконує свою чітко визначену роль.
Java backend у цій схемі виступає як точка контролю доступу та координатор
даних. Він може перевірити токени, прийняти файл, передати його до ML-сервісу,
отримати результат і зіставити його з локальною базою. Angular frontend забезпечує
зрозумілий користувацький досвід, дозволяючи завантажувати документ,
переглядати результати та, за потреби, коригувати їх вручну. У цій тришаровій схемі
Інтелектуалізована інформаційна підсистема імпорту навчальних здобутків студентів
є лише одним із шарів, але її якість істотно впливає на зручність усієї платформи.
Особливо цінним є те, що така інтеграція не руйнує межі між відповідальністю
за інтерфейс, бізнес-правила та машинне навчання. Це дає змогу розробляти кожен
шар окремо, підбирати для нього оптимальні інструменти і при цьому зберігати
цілісність системи. Подібний підхід відповідає сучасним практикам побудови
корпоративних інформаційних систем, де інтелектуальні компоненти часто
реалізуються в окремих сервісах.
З організаційної точки зору така схема добре узгоджується й з освітнім
середовищем, оскільки університет може поступово розширювати функціональність
системи: спочатку імпорт окремих документів, далі — інтеграція з електронними
журналами, потім — підтримка нових типів довідок, а в перспективі й автоматичний
аналіз академічних траєкторій студентів.
Робота з сервісом для розпізнавання додатків до дипломів наразі вже є повністю
інтегрованою в систему. Вигляд інтерфейсу та взаємодії з ним поданий на рисунках
5.1, 5.2, 5.3 та 5.4.
45
Рисунок 5.1 – Вибір студента, для якого відбудеться зарахування академрізниці
Рисунок 5.2 – Модальне вікно для завантаження скан-копії додатку до диплому
Рисунок 5.3 – Вікно очікування
46
Рисунок 5.4 – Вигляд модального вікна після розпізнавання предметів
Натискаючи «Порівняти» запит надсилається до сервісу знаходження
схожих назв предметів. Вигляд вебінтерфейсу подано на рисунку 5.5.
Рисунок 5.5 – Вікно для перезарахування та визначення академрізниці
В той час, як розпізнавання сертифікатів, наразі можна отримати лише за
прямим запитом на основний бекенд проєкту. Вигляд JSON відповіді подано на
рисунку 5.6.
47
Рисунок 5.6 – Результат виконання роботи сервісом розпізнавання
сертифікатів в форматі JSON
5.4 Перспективи удосконалення
Перспективи подальшого розвитку розробленої Інтелектуалізованої
інформаційної підсистеми імпорту навчальних здобутків студентів є
багатовекторними та охоплюють як технологічне вдосконалення алгоритмів, так і
розширення функціональних можливостей для кінцевих користувачів. Оскільки
цифровізація освітнього середовища є динамічним процесом, архітектура системи
48
була спроєктована з урахуванням можливості майбутнього масштабування та
інтеграції нових модулів.
По-перше, одним із пріоритетних напрямків розвитку є розширення спектра
форматів документів, що підтримуються. У наступних ітераціях розробки доцільно
додати підтримку багатосторінкових PDF-файлів, які є стандартом для великих
академічних довідок та додатків до дипломів європейського зразка (Diploma
Supplement). Це потребуватиме впровадження методів інтелектуальної сегментації
документів та обробки складних табличних структур, де дані можуть переходити з
однієї сторінки на іншу. Використання сучасних підходів до аналізу макета (Layout
Analysis) дозволить системі не просто зчитувати текст, а розуміти ієрархію та логічні
зв’язки між елементами в межах багатосторінкового документа, що значно підвищить
практичну цінність рішення для обробки великих масивів архівних даних.
Другою важливою перспективою є якісне вдосконалення моделей
розпізнавання та екстракції знань. Хоча поточне поєднання універсальних моделей
OCR та NER демонструє високу точність, подальший розвиток передбачає перехід до
доменно-спеціалізованих моделей (Domain-specific models). Навчання нейромереж на
специфічному корпусі внутрішніх академічних документів українських ЗВО
дозволить врахувати особливості термінології, офіційного стилю та специфічних
шрифтів, що використовуються у державних бланках. Адаптація моделей до
візуальних маркерів (пеаток, підписів, QR-кодів для верифікації) дозволить
автоматизувати не лише зчитування, а й первинну перевірку справжності документа,
що мінімізує потребу у ручному втручанні працівників деканату.
Третьою стратегічною перспективою є впровадження механізмів активного
навчання (Active Learning) та створення контуру зворотного зв’язку. У майбутньому
планується реалізація архітектури «Human-in-the-loop», де кожне виправлення,
зроблене оператором у вебінтерфейсі, автоматично зберігатиметься як новий
навчальний приклад. Накопичення такого верифікованого датасету дозволить
періодично проводити донавчання моделей (fine-tuning) без необхідності повної
переробки кодової бази. Це особливо важливо в умовах постійних змін у стандартах
49
оформлення сертифікатів та появи нових освітніх платформ, оскільки система зможе
самостійно адаптуватися до нових візуальних стилів на основі дій користувача.
Важливим кроком стане також розвиток аналітичного модуля та панелі
адміністрування. Для технічного персоналу та керівництва університету планується
розробка інтерактивного дашборду, який відображатиме метрики ефективності
автоматизації: кількість успішно оброблених документів у реальному часі, середній
час розпізнавання одного файлу, статистику за типами знайдених сутностей та рівень
впевненості моделей для різних джерел (наприклад, порівняння точності
розпізнавання сертифікатів Coursera та Udemy). Така прозорість дозволить приймати
обґрунтовані рішення щодо подальшої модернізації апаратних ресурсів або потреби
в оновленні програмних алгоритмів.
Нарешті, ключовим етапом еволюції системи для підвищення зручності роботи
адміністративного персоналу планується інтеграція сервісу в окремий мобільний
застосунок. Це дозволить працівникам деканату відійти від прив’язки до
стаціонарного робочого місця та потреби у використанні планшетних сканерів. За
допомогою мобільного додатка фахівець зможе за лічені секунди зробити якісне фото
сертифіката безпосередньо під час прийому студента, після чого вбудовані алгоритми
(або хмарний API розробленого сервісу) миттєво проаналізують зображення, виділять
ключові дані та запропонують зберегти їх у загальній системі. Такий мобільний
інструмент з підтримкою технологій Edge Computing або оптимізованої передачі
даних на сервер зробить процес імпорту здобутків максимально оперативним та
безпаперовим, формуючи сучасне цифрове середовище університету.
Висновки до розділу 5
Вибраний програмний інструментарій виявився функціонально узгодженим і
повністю придатним для вирішення поставлених задач інтелектуалізованої обробки
даних. Flask, PaddleOCR, GLiNER2, ChromaDB, Sentence Transformers і LangChain
утворили технологічний набір, який дозволяє поєднати документний аналіз,
семантичний пошук і сервісну інтеграцію.
50
Одержане рішення має практичний потенціал для застосування в
університетській інформаційно-аналітичній системі та створює базу для подальшого
розширення. У заключному розділі підбито підсумки роботи та сформульовано
основні результати, досягнуті в процесі виконання кваліфікаційної роботи бакалавра.
51
ВИСНОВКИ
У кваліфікаційній роботі бакалавра розроблено Інтелектуалізовану
інформаційну підсистему імпорту навчальних здобутків студентів з документів до
інформаційно-аналітичної системи університету. Досягнуто головну мету роботи —
створено програмне рішення, яке здатне приймати зображення документів,
виконувати OCR-розпізнавання, виділяти сутності, очищати результати та повертати
структуровані дані, придатні для подальшого використання в університетській
системі.
У процесі виконання роботи було проаналізовано предметну область,
визначено основні проблеми ручного імпорту даних, обґрунтовано вибір
мікросервісної архітектури та підібрано інструменти, які найкраще відповідають
вимогам задачі. Практична реалізація показала доцільність поєднання PaddleOCR,
GLiNER2, ChromaDB і Sentence Transformers у єдиному конвеєрі інтелектуальної
обробки.
Отримані результати мають практичну цінність для університетського
середовища, оскільки створюють основу для скорочення ручної праці, зменшення
кількості помилок і прискорення перенесення навчальних здобутків до
централізованої бази даних. У подальшому розроблене рішення може бути розширене
підтримкою PDF-документів, нових типів реквізитів, активного навчання та глибшої
аналітики обробки документів.
52
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. AI document automation software | ABBYY flexicapture. ABBYY. URL:
https://www.abbyy.com/flexicapture/ (дата звернення: 06.02.2026).
2. Document AI | google cloud. Google Cloud. URL:
https://cloud.google.com/document-ai (дата звернення: 06.02.2026).
3. Home - PaddleOCR Documentation. Redirecting. URL:
https://www.paddleocr.ai/main/en/index.html (дата звернення:
06.02.2026).
4. Chdtu-fitis. GitHub. URL: https://github.com/chdtu-fitis (дата звернення:
09.05.2026).
5. Dateparser – python parser for human readable dates – DateParser 1.4.0
documentation. URL: https://dateparser.readthedocs.io/en/latest/ (дата звернення:
09.05.2026).
6. Getting started - chroma docs. Introduction - Chroma Docs. URL:
https://docs.trychroma.com/docs/overview/getting-started (дата звернення:
09.05.2026).
7. GitHub - urchade/gliner: generalist and lightweight model for named entity
recognition (extract any entity types from texts). GitHub. URL:
https://github.com/urchade/GLiNER (дата звернення: 09.05.2026).
8. Home - Docs by LangChain. URL: https://docs.langchain.com (дата звернення:
09.05.2026).
9. OpenCV: introduction. OpenCV documentation index. URL:
https://docs.opencv.org/3.4/d1/dfb/intro.html (дата звернення: 09.05.2026).
10. SentenceTransformers Documentation – Sentence Transformers documentation.
URL: https://sbert.net (дата звернення: 09.05.2026).
11. Welcome to flask – flask documentation (3.1.x). URL:
https://flask.palletsprojects.com/en/stable/ (дата звернення: 09.05.2026).
12. Методичні рекомендації для підготовки кваліфікаційної роботи бакалавра
здобувачів освітнього ступеня «бакалавр» зі спеціальності 122 (F3) –
53
«Комп’ютерні науки» усіх форм навчання [Електронний ресурс] / [упоряд.
Триус Ю.В., Оксамитна Л.П., Підгорний М.В.]; М-во освіти і науки України,
Черкас. держ. технол. ун-т. Черкаси: ЧДТУ, 2026. 53 с..
13. В. В. Гахова, М. В. Підгорний. Інтелектуалізована підсистема імпорту
навчальних здобутків студентів з документів до інформаційно-аналітичної
системи університету : Збірник тез доповідей студентської науково-практичної
конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; Міністерство
освіти і науки України, Черкаський державний технологічний ун-т. Черкаси :
ЧДТУ, 2026. С. 25.
54
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2026 р.
ІНТЕЛЕКТУАЛІЗОВАНА ІНФОРМАЦІЙНА ПІДСИСТЕМА ІМПОРТУ
НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ З ДОКУМЕНТІВ ДО
ІНФОРМАЦІЙНО-АНАЛІТИЧНОЇ СИСТЕМИ УНІВЕРСИТЕТУ
Специфікація
482.ЧДТУ. 62299-01
Листів 2
Розробник ____________________ Валерія ГАХОВА
Керівник ____________________ Микола ПІДГОРНИЙ
Черкаси – 2026
55
482.ЧДТУ. 62299-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 62299-01 13 01 опис програми
482.ЧДТУ. 62299-01 33 01 інструкція програмісту
482.ЧДТУ. 62299-01 34 01 інструкція користувачеві
482.ЧДТУ. 62299-01 51 01 програма і методика
випробувань
56
ДОДАТОК Б
ІНТЕЛЕКТУАЛІЗОВАНА ІНФОРМАЦІЙНА ПІДСИСТЕМА ІМПОРТУ
НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ З ДОКУМЕНТІВ ДО
ІНФОРМАЦІЙНО-АНАЛІТИЧНОЇ СИСТЕМИ УНІВЕРСИТЕТУ
Опис програми
482.ЧДТУ. 62299-01 13 01
Листів 9
Розробник ____________________ Валерія ГАХОВА
Керівник ____________________ Микола ПІДГОРНИЙ
Черкаси – 2026
57
У додатку наведено детальну структуру проєкту Deanoffice Python Services та
коротке пояснення призначення кожного основного елемента. Такий перелік
полегшує супровід коду і демонструє, як саме розділено відповідальність між точкою
входу, сервісами, допоміжними модулями та тестовими файлами.
deanoffice_python_services/
├── api.py # Flask application entry point (route registration)
├── gunicorn_config.py # Gunicorn production configuration
├── requirements.txt # Python dependency specification
├── .env # Environment variables (AUTH_TOKEN, SCORE,
REMOTE_REPO_URL)
├── chroma/ # Persistent ChromaDB vector store (auto-created)
├── services/
│ ├── certificate_extraction/
│ │ ├── __init__.py
│ │ ├── api.py # Flask route handler for /api/process-image
│ │ ├── image_service.py # PaddleOCR + GLiNER2 integration (singleton)
│ │ └── data_cleaning_service.py # Post-processing: date normalization,
Ukrainian name validation
│ └── course_matcher/
│ ├── __init__.py
│ ├── api.py # Flask route handler for /api/match
│ ├── service.py # Remote data cache manager (TTL-based refresh)
│ ├── db_manager.py # ChromaDB vector store operations
│ └── prepare_data.py # LangChain Document chunking from remote
data
├── utils/
│ ├── __init__.py
│ └── api_client.py # HTTP client for fetching data from Java backend
58
├── demo_image_processing.py # Standalone demo script for image
processing pipeline
├── demo_data_cleaning.py # Standalone demo script for data cleaning
service
├── 2026-04-04_11-52.png # Test certificate image (Ukrainian)
├── 2026-04-05_13-33.png # Test certificate image
├── 2026-04-05_13-36.png # Test certificate image
└── SERVICE_SUMMARY.md # Detailed service summary
У такій побудові видно, що сервіс орієнтований на два головні сценарії:
обробку зображень сертифікатів і семантичне зіставлення назв дисциплін. Всі
допоміжні файли підтримують саме ці сценарії, тому структура залишається
компактною та легкою для читання.
Також у додатку подано узагальнений опис основних HTTP-ендпоїнтів
Інтелектуалізованої інформаційної підсистеми імпорту навчальних здобутків
студентів. Така форма зручна для інженерного використання, оскільки дозволяє
швидко зрозуміти, які дані очікує сервіс, які перевірки він виконує та що саме
повертає.
Параметри запиту для /api/process-image: multipart/form-data, поле file, прийняті
формати JPEG та PNG, обмеження за розміром 10 МБ. Після успішної перевірки файл
декодується і передається до OCR-моделі.
Параметри запиту для /api/match: JSON-об’єкт із масивом sourceCourseNamesIds та
масивом courseNamesUndefined. Після обробки відповідь повертається у вигляді
словника, де ключі — це ідентифікатори курсів, а значення — списки відповідних
назв.
Нижче подано приклади відповідей у скороченому вигляді.
POST /api/process-image
Request:
multipart/form-data
59
file=<binary image>
Response:
{
"response": {
"structured_data": {
"educational_institution": ["..."],
"course_name": ["..."],
"student_name": ["..."],
"date": ["YYYY-MM-DD"]
}
},
"status": "success"
}
POST /api/match
Request:
{
"sourceCourseNamesIds": ["id1", "id2", "id3"],
"courseNamesUndefined": ["Advanced Programming", "Алгоритми"]
}
Response:
{
"response": {
"id1": ["Advanced Programming"],
"id2": ["Алгоритми"]
},
"status": "success"
60
}
У додатку наведено розгорнутий псевдокод основного конвеєра обробки
сертифікатів. Псевдокод подає логіку без прив’язки до конкретних бібліотек і
допомагає читачеві швидко побачити взаємозв’язок між етапами.
procedure ProcessCertificate(file):
if file is missing:
return error("file is required")
if file size > 10 MB:
return error("file is too large")
header = read first bytes(file)
if header is not JPEG and header is not PNG:
return error("unsupported file type")
image = decode with OpenCV(file)
if image is null:
return error("cannot decode image")
rawText = run PaddleOCR on image
if rawText is empty:
return warning("no text detected")
filteredText = keep only blocks with confidence >= 0.6
mergedText = join filteredText with line separators
entities = run GLiNER2 on mergedText using labels:
educational_institution
course_name
61
student_name
date
study_started
study_finished
cleanedEntities = empty structure
for each entity in entities:
normalizedValue = clean whitespace(entity.text)
if entity label is date:
normalizedValue = normalize date(entity.text)
if entity label is student_name:
if ukrainian character ratio is below threshold:
continue
add normalizedValue to cleanedEntities under entity label
remove duplicates from cleanedEntities
return JSON with cleanedEntities and status success
Коментар до псевдокоду: особливу увагу слід звернути на відсічення шумових
даних і перевірку частки українських символів у ПІБ. Саме ці етапи найбільше
впливають на якість структурованого результату.
Далі подано детальніший варіант із внутрішніми кроками постобробки.
procedure CleanEntities(entities):
result = empty map
for each label in entities:
values = entities[label]
normalizedList = empty list
for each value in values:
62
value = replace multiple spaces with one space
value = trim spaces
if value is empty:
continue
if label is date or label is study_started or label is study_finished:
value = parse date in Ukrainian and English
if value cannot be parsed:
continue
if label is student_name:
if ukrainianCharacterShare(value) < 0.70:
continue
normalizedList.append(value)
result[label] = unique(normalizedList)
return result
Цей додаток також демонструє логіку зіставлення невизначених назв дисциплін
із каталогом відомих курсів. У центрі механізму перебуває векторний пошук, а не
точне рядкове порівняння.
procedure MatchCourseNames(sourceCourseNamesIds, courseNamesUndefined):
refresh local vector store if needed
knownCourses = fetch from Java backend
if knownCourses is empty:
63
return error("cannot load course catalog")
store knownCourses in ChromaDB with metadata ids
matches = empty map from course id to list of undefined names
for each undefinedName in courseNamesUndefined:
queryEmbedding = encode undefinedName using Sentence Transformers
neighbors = search ChromaDB for nearest items to queryEmbedding
restricted by sourceCourseNamesIds
for each neighbor in neighbors:
if similarity score is above threshold:
append undefinedName to matches[neighbor.id]
return matches with status success
Алгоритм не потребує, щоб назва була ідентичною запису в базі. Достатньо,
щоб тексти були семантично близькими, а це істотно розширює можливості імпорту
в умовах варіативних назв.
procedure RefreshCourseStoreIfNeeded():
if cache is fresh:
return
clear existing ChromaDB collection
response = GET /course-names from backend
if response failed:
keep previous cache if exists
return
64
documents = transform response into LangChain documents
embeddings = encode documents
store embeddings in ChromaDB
update last_refresh timestamp
65
ДОДАТОК В
ІНТЕЛЕКТУАЛІЗОВАНА ІНФОРМАЦІЙНА ПІДСИСТЕМА ІМПОРТУ
НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ З ДОКУМЕНТІВ ДО
ІНФОРМАЦІЙНО-АНАЛІТИЧНОЇ СИСТЕМИ УНІВЕРСИТЕТУ
Інструкція програмісту
482.ЧДТУ. 62299-01 33 01
Листів 3
Розробник ____________________ Валерія ГАХОВА
Керівник ____________________ Микола ПІДГОРНИЙ
Черкаси – 2026
66
У цьому додатку подано приклади конфігураційних параметрів, які
використовуються Інтелектуалізованою інформаційною підсистемою імпорту
навчальних здобутків студентів. Їх наявність дозволяє відокремити код від
середовища виконання та швидко адаптувати систему до нового розгортання.
# .env
AUTH_TOKEN=<secret token>
SCORE=-10
REMOTE_REPO_URL=http://localhost:8080
# gunicorn_config.py
bind = "0.0.0.0:5000"
workers = 4
Нижче наведено приклад структурованої відповіді після успішної обробки
документа.
{
"response": {
"structured_data": {
"educational_institution": ["Київський національний університет"],
"course_name": ["Комп'ютерні науки"],
"student_name": ["Олександр Кравченко"],
"date": ["2025-05-07"],
"study_started": ["2024-09-01"],
"study_finished": null
}
},
"status": "success"
}
Приклад відповіді для зіставлення назв курсів показує, як один ідентифікатор
може отримати одразу кілька варіантів написання, якщо вони семантично
відповідають одному каталожному запису.
67
{
"response": {
"course_12": ["Advanced Programming", "Програмування", "Поглиблене
програмування"]
},
"status": "success"
}
У цьому додатку систематизовано ключові параметри, що впливають на запуск
і поведінку Інтелектуалізованої інформаційної підсистеми імпорту навчальних
здобутків студентів.
Оскільки документні дані не завжди є ідеальними, частковий результат може
бути більш корисним, ніж повне відхилення запиту. Саме тому в проєкті важливе
місце займає логіка постобробки та валідації.
68
ДОДАТОК Г
ІНТЕЛЕКТУАЛІЗОВАНА ІНФОРМАЦІЙНА ПІДСИСТЕМА ІМПОРТУ
НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ З ДОКУМЕНТІВ ДО
ІНФОРМАЦІЙНО-АНАЛІТИЧНОЇ СИСТЕМИ УНІВЕРСИТЕТУ
Інструкція користувачеві
482.ЧДТУ. 62299-01 34 01
Листів 4
Розробник ____________________ Валерія ГАХОВА
Керівник ____________________ Микола ПІДГОРНИЙ
Черкаси – 2026
69
У цьому додатку зібрано короткі інструкції, які можуть знадобитися під час
введення системи в експлуатацію та в процесі щоденного супроводу:
– переконатися, що Python-пакети встановлені згідно з requirements.txt;
– перевірити наявність файлу .env і коректність конфігураційних змінних;
– переконатися, що Java backend доступний за адресою REMOTE_REPO_URL;
– перевірити, що каталог chroma доступний для запису;
– запустити сервіс у режимі розробки командою python api.py;
– для промислового запуску використовувати gunicorn -c gunicorn_config.py
api:app;
– перед запуском оновити довідник курсів у backend;
– перевірити доступ до тестових зображень і коректність їхнього формату;
– після оновлення моделей провести повторне тестування;
– фіксувати помилки в окремому журналі супроводу;
– окремо перевіряти сценарії без файла, з великого розміру та з некоректним
JSON;
– контролювати, щоб результати OCR не потрапляли до користувача без
постобробки;
– після зміни довідника курсів очищати або переіндексувати локальну векторну
базу;
– використовувати лише узгоджені версії моделей і бібліотек;
– зберігати резервні копії конфігураційних файлів перед оновленням;
– перевіряти журнали помилок після кожного тестового запуску;
– окремо контролювати час виконання найтяжчих запитів;
– підтримувати доступ до сервісу лише через довірене середовище;
– перевіряти коректність авторизаційних токенів;
– для демонстрації використати окремий набір тестових документів.
Ця пам’ятка може слугувати основою для майбутньої інструкції користувача
або адміністратора системи.
70
Також цей додаток містить розширені пояснення щодо подальшого супроводу
та еволюції рішення. Матеріал може використовуватися як орієнтир для переходу від
навчального проєкту до виробничого середовища:
– підтримувати окремий набір еталонних документів для регресійного
тестування;
– оновлювати залежності тільки після перевірки сумісності з OCR та векторним
пошуком;
– вести окремий журнал змін для моделей, що використовуються в сервісі;
– зберігати опис версій документних шаблонів, які найчастіше трапляються в
системі;
– контролювати, щоб результати пошуку по каталогу курсів залишалися
актуальними після змін у навчальному плані;
– регулярно перевіряти, чи не накопичуються застарілі файли в каталозі
векторного сховища;
– підтримувати чітке розділення між тестовим і продуктивним середовищами;
– перевіряти працездатність сервісу після оновлення Python, бібліотек і
контейнерних образів;
– для складних випадків передбачати ручний режим підтвердження результатів
оператором;
– формувати статистику помилок за типами, щоб бачити, де саме виникають
втрати якості;
– використовувати спільний словник службових позначень для всіх компонентів
системи;
– окремо тестувати повільні сценарії, коли OCR обробляє поганий або розмитий
скан;
– поступово накопичувати приклади помилкових або виправлених результатів
для подальшого навчання;
– перед запуском у продакшн переконатися в коректності маршрутизації запитів,
таймаутів;
71
– використовувати структуроване логування для спрощення діагностики
інцидентів;
– після зміни каталогу курсів синхронізувати дані між backend і локальним
сховищем;
– забезпечити резервне копіювання конфігурацій та індексів;
– періодично виконувати smoke-test на основних ендпоїнтах;
– заздалегідь визначити процедуру відновлення сервісу після аварійного
завершення процесу;
– надати адміністратору коротку інструкцію з перезапуску сервісу і перевірки
статусу.
72
ДОДАТОК Д
ІНТЕЛЕКТУАЛІЗОВАНА ІНФОРМАЦІЙНА ПІДСИСТЕМА ІМПОРТУ
НАВЧАЛЬНИХ ЗДОБУТКІВ СТУДЕНТІВ З ДОКУМЕНТІВ ДО
ІНФОРМАЦІЙНО-АНАЛІТИЧНОЇ СИСТЕМИ УНІВЕРСИТЕТУ
Програма і методика випробувань
482.ЧДТУ. 62299-01 51 01
Листів 3
Розробник ____________________ Валерія ГАХОВА
Керівник ____________________ Микола ПІДГОРНИЙ
Черкаси – 2026
73
Матриця тестування в таблиці Д.1 демонструє, що в проєкті були перевірені не
лише штатні сценарії, а й помилки вхідних даних, умови відмови та варіанти з
нетиповими документами. Це важливо для системи, яка працює з реальним
документообігом.
Таблиця Д.1 – Матриця тестування
№ Сценарій Результат Коментар
JPEG-файл
Запит оброблено
1 коректного Успіх
без помилок
розміру
PNG-файл
OCR виконано
2 коректного Успіх
коректно
розміру
Спрацювало
3 Файл понад 10 МБ Відхилено
обмеження розміру
Некоректні
Захист від підміни
4 ідентифікатори Відхилено
типу файлу
формату файлу
Порожнє Частковий Потрібна ручна
5
зображення результат перевірка
Здійснено
Довільна назва
6 Успіх семантичне
дисципліни
зіставлення
Неправильний Повернено
7 Відхилено
формат JSON помилку валідації
Текст із малою
кількістю Значення не
8 Фільтрація
українських прийнято як ПІБ
символів
74
За підсумком тестування можна зробити висновок, що Інтелектуалізована
інформаційна підсистема імпорту навчальних здобутків студентів стійко реагує на
основні типи відмов і забезпечує коректну обробку типових вхідних даних. Особливо
корисним є поєднання позитивних і негативних сценаріїв, оскільки воно показує не
лише працездатність, а й межі застосовності рішення.
75