Faster, more accurate, and without unnecessary thousands in the budget — how LLM helps the ministry check estimates

Система неупереджена: допоможе уникнути помилок, сформулювати ідею чіткіше — але й не дозволить «випадково» закласти зайві десятки тисяч у бюджет. Замість суб’єктивного ручного розгляду — автоматична перевірка, підказки в режимі реального часу, обґрунтовані зауваження для посадовців.

Розробники пояснили, як вона працює насправді.

На конференції «ЯК ЦЕ ЗРОБЛЕНО. AI edition»  був представлений досвід впровадження AI-модуля для аналізу заяв.  Йдеться про систему, що аналізує заявки на проєкти міжнародних молодіжних обмінів від Міністерства молоді та спорту — перший кейс впровадження генеративного ШІ в державний сервіс на базі платформи Diia.Engine.

Кейс презентував Олександр Акуленко, Head of AI в MK-Consulting, радник CEO Prozorro.Sale, керівник групи розробки першої української платформи для ML-інженерів у De Novo.

Щоб система справді працювала, команді довелося вручну розбити заявки на блоки, сформувати серію запитів до LLM і обійти технічні обмеження моделі — зокрема коротке контекстне вікно та відсутність підтримки інструкцій "із коробки". Врешті ШІ не просто аналізує текст, а й видає релевантні та контекстно точні, по-людськи зрозумілі зауваження.

Яку проблему вирішували?

Міністерство щороку проводить конкурси проєктів міжнародних молодіжних обмінів з Польщею та Литвою. Це програма для неприбуткових організацій, що працюють з молоддю. Заявники часто помиляються при заповненні форм. Співробітники міністерства вручну перевіряють заявки, що створює навантаження та ризик суб’єктивної оцінки. Метою було спростити процес подання заявок та їх оцінку.

Ключові вимоги до AI-моделі

• Автоматичні рекомендації і підказки під час заповнення заявок.
• Генерація обґрунтованих зауважень для співробітників.
• Зменшення впливу людського фактора та ризику помилок при оцінці заявок.
• Підвищення якості заявок.

Рішення побудоване як зовнішній інтеграційний компонент до системи

Обмінів, яка створена на базі Diia.Engine. Весь процес побудований навколо платформи Dify, яка відповідає за обробку запитів, інтеграцію з LLM та повернення результатів.

Приклади обробки заяв

Простий кейс: короткий опис проєкту

У базовому сценарії заявник подає короткий опис проєкту українською мовою і обирає пріоритет з випадаючого списку. Розробники налаштували перевірку відповідності опису проєкту зазначеному пріоритету з урахуванням заздалегідь визначених логічних правил.

У цьому випадку ШІ-модель автоматично підтвердила коректність відповіді заявника — мета проєкту відповідала обраному пріоритету. Зауважень не було, покращення не вимагалося.

Складний кейс: аналіз кошторису

Команда MK-Consulting також реалізувала автоматизовану перевірку складних заяв із великим обсягом інформації, зокрема — кошторисів.

У прикладі одна із заяв містила витрати на екскурсії по Львову для 36 учасників на суму 36 000 грн. ШІ-модель, налаштована командою, визначила, що ці витрати не мають безпосереднього зв’язку з цілями обміну.

У результаті заявнику було надано рекомендацію або вилучити цей рядок із кошторису, або обґрунтувати його значущість у контексті заявленого проєкту.

Типові помилки заявників

Під час перших конкурсів команда MK-Consulting зафіксувала типові слабкі місця в заявках:

• Розпливчасті формулювання мети.
• Відсутність кількісних показників.
• Недостатня деталізація кошторису.

Система, реалізована командою, автоматично виявляє подібні помилки та надає релевантні рекомендації щодо покращення.

Вибір технологічного рішення

Вибрали ШІ-модель Gemma 2 для реалізації рішення. Рішення побудоване як зовнішній інтеграційний компонент до основної системи обміну, що функціонує на базі Diia.Engine для обробки запитів.

Оркестрація та інфраструктура

Для загальної оркестрації роботи ШІ-моделі використовується платформа для оркестрації додатків і моделей, яка є центральним вузлом системи, що керує всіма даними та їх обробкою. Ця платформа розгорнута в Kubernetes за допомогою Helm, приймає на вхід дані від системи обміну та запускає визначені робочі процеси (workflows) в Dify. Ці процеси можуть включати кроки валідації, обробки даних, виклики до LLM та інші операції. Це дозволяє використовувати комбінацію класичної розробки та роботи з генеративним ШІ або іншими моделями залежно від потреб бізнесу.

Під капотом використовується PostgreSQL для зберігання даних: конфігурацій, історії запусків, даних додатків тощо. Взаємодія з SGLang забезпечує роботу з LLM, який використовується для інференсу. SGLang виступає як проміжний шар між Dify та ШІ-моделлю, надаючи інтерфейс для роботи з LLM, обробки запитів, реалізує батчинг, обробку кількох запитів та керує пам'яттю GPU.

Вибір моделі Gemma 2

Для обробки тексту обрано ШІ-модель Gemma 2, оскільки на момент початку роботи з системою третя версія ще не була доступна. Gemma 2 з 27 мільярдами параметрів показувала оптимальні результати при обробці української мови та могла бути розгорнута в ресурсах замовника. Для роботи ШІ-моделі необхідно мінімум один GPU H100 або A100. Замовник орендував ресурси в українського провайдера хмарних сервісів для штучного інтелекту та машинного навчання.

Оптимізація роботи моделі

Спочатку планувалося використовувати комбінацію кількох ШІ-моделей, оскільки Gemma добре працює з українською мовою, але має обмежене контекстне вікно. Ідея полягала в тому, щоб великий вивід передавати іншій ШІ-моделі, яка повноцінно працює з контекстом, але не може нормально видати результат українською. У кінці планувалося самарізувати все за допомогою Gemma, щоб заявник і замовник отримали адекватний результат.

Проте в процесі вдалося оптимізувати роботу: розбити заявку на окремі компактні блоки, які аналізуються ізольовано, зменшити обсяг нерелевантної інформації, яку заповнює заявник, щоб вона не впливала на роботу ШІ-моделі. У результаті вдалося отримати потрібний результат лише з використанням Gemma без застосування додаткових ШІ-моделей, що зекономило ресурси для замовника.

Технічні виклики та рішення

Під час використання SGLang для інференсу виникли певні обмеження: токенізатор для Gemma формально не підтримував роботу з системними інструкціями ШІ-моделі. Це обмежувало налаштування, зокрема неможливість задати роль, стилістику відповідей тощо, що суттєво впливало на якість відповідей. Команді довелося перезібрати SGLang вручну, оновити конфігурацію, що дозволило використовувати системні промпти, які підтримувалися.

Налаштування системи

Для налаштування системи використовувалася комбінація кількох джерел даних:

• Законодавство, яке регулює обміни, хоча воно було досить верхньорівневим і не давало відповіді на всі питання.
• Інструкції та особистий досвід посадових осіб, які займаються перевіркою заяв.
• Історичні дані: попередні заяви та результати їх розгляду, щоб врахувати це під час налаштування ШІ-моделі.

З досвіду Акуленка, фаза бізнес-аналізу для подібних проектів іноді не менш, а може й більш важлива, ніж у випадку з класичною розробкою. Більшість ШІ-моделей не спеціалізовані, вони не розуміють, що відбувається в голові експерта, який оцінює заяву. Тому потрібно детально зрозуміти, як думає експерт, на що він спирається під час оцінки заяви, щоб потім цю логіку, наскільки можливо, відтворити за допомогою ШІ. На першій фазі потрібні значні інвестиції в бізнес-аналіз, що часто не розуміють замовники, які вважають, що ШІ самостійно вирішить усі завдання без надання необхідної інформації.

Процес обробки заяв

Процес працює наступним чином:

1. Отримання через API JSON з повною інформацією про заяву в Dify.
2. Визначення країни, до якої відноситься заява, оскільки логіка відрізняється для Польщі та Литви.
3. Парсинг JSON, розбиття на окремі логічні блоки, відкидання нерелевантної інформації.
4. Для кожного поля, яке потрібно врахувати, відправляється окремий запит до Gemma або серія запитів, залежно від блоку інформації, з урахуванням попереднього контексту та необхідних правил перевірки.
5. Збір відповідей, форматування за допомогою мовної моделі, формування окремої відповіді для заявника та окремої для посадової особи, оскільки відповіді трохи відрізняються.

Контекстне вікно Gemma обмежено 8192 токенами, а на обробку однієї заяви йде орієнтовно 100 000 токенів. Тому необхідна комбінація кроків, щоб не блокувати себе обмеженнями контекстного вікна та якісно обробити заяву.

Гнучкість системи

Система не прив'язана до специфіки роботи конкретної ШІ-моделі. У разі появи моделі, яка краще працює з українською, працює швидше або споживає менше ресурсів, можна без принципових змін у системі переключитися на нову ШІ-модель.

Інтерфейс для посадових осіб і заявників

Команда також розробила інтерфейс адміністратора, який дозволяє:

• Переглядати покрокове виконання обробки заявки.
• Аналізувати обсяг використаних токенів.
• Оцінювати загальний час виконання.

Результати аналізу заявник отримує через той самий інтерфейс, де подає заявки. Вони включають оцінку логічної узгодженості, рекомендації та можливість запуску часткового аналізу на проміжних етапах.