Коли дані розкидані по десятках сервісів — класичні підходи не працюють. Розкажемо, як ми побудували агреговану read-модель для 30M+ документів, витримали 1500 write RPS і чому Elasticsearch став ключовим компонентом каталогу.

У своїй доповіді Ірина розповість про те, як змінюється мислення, коли переходиш від “покращити існуюче” до “створити з нічого”. Які ролі насправді критичні, де команда підсилює, а де - гальмує. Та які помилки в командній взаємодії коштують найдорожче на старті

Впровадження ШІ у державний сервіс на 23+ млн користувачів — це шлях постійних продуктових відкриттів та викликів. У цій доповіді я поділюся реальним досвідом того, як екосистема «Дія» переходить від класичної Цифрової держави (де юзер сам шукає потрібні послуги) до Агентної (де ШІ проактивно виконує намір користувача). Про що поговоримо: - Product Discovery та зміна парадигми: Перехід від Digital State до Agentic State. Чому звичні інтерфейси досягли своєї межі, та як ми валідували потребу в проактивних AI-рішеннях. - AI у Підтримці як перший великий крок: Як ми автоматизували 90% звернень без втрати якості (CSAT). М'який AI UX: чому люди не вміють користуватися промптами і як ми допомагаємо їм гібридними інтерфейсами. - Кейс Upskill та трансформація команди: Ми не звільнили жодного оператора. Як ми створили внутрішні AI-тули для команди, а вчорашні оператори стали AI-тренерами. - Deep Dive у Дія.AI на Порталі: Запуск першої у світі агентивної послуги на державному рівні. Як працює наша RAG-архітектура, як ми захищаємо персональні дані (PII) від потрапляння в LLM та відбиваємо спроби джейлбрейків.

Більшість компаній починають AI-трансформацію з технології, а не з бізнес-задачі, і отримують вічні пілоти замість результатів. Поділюся принципами, які сформувались через побудову та реалізацію 20+ AI-стратегій і 50+ рішень для компаній від рітейлу до фарми в США, Європі та Україні. Які помилки коштують найдорожче, що насправді визначає ROI, і чому одні проєкти масштабуються, а інші назавжди залишаються на слайдах. Для кого буде корисно: • CEO, власники бізнесу та керівники, які впроваджують або планують AI. • Технічні лідери та ML-інженери, які будують AI-рішення і хочуть, щоб робота давала бізнес-результат.

Опис доповіді: - Передумови впровадження. Чому ми вирішили додати асистента до звичного пошуку. - Ринкові тренди. Як розвивається Agentic Commerce і чому це важливо зараз. - Реалізація. Як ми технічно будували та впроваджували AI-агента в структуру Prom. - МВП та результати експерименту. Що показали перші тести та як користувачі взаємодіяли з асистентом. - Ключові інсайти та висновки. Головні думки, які ми винесли під час розробки та запуску. - Що робимо далі. Плани щодо розвитку AI-інструментів на маркетплейсі.

Що відбувається, коли велика мовна модель стає точкою входу до державних сервісів, які працюють під реальним навантаженням і в умовах інформаційної війни? У такій архітектурі будь-який запит може бути не лише некоректним, а й навмисно маніпулятивним — і стандартні AI-safety рішення виявляються значно менш надійними, ніж у лабораторних бенчмарках. У цій доповіді я розповім, як ми будували власний guardrail-модуль для Дія.AI після того, як зіткнулися з обмеженнями готових фільтрів і високою вартістю підходу LLM-as-a-Judge. Замість перевірки кожного запиту великою моделлю ми спроєктували каскадну архітектуру безпеки: швидкі ML-класифікатори відсікають більшість трафіку, а LLM підключається лише там, де справді потрібен глибокий аналіз контексту. Це доповідь не про ідеальні моделі, а про компроміси, обмеження і практичні рішення, які доводиться приймати, коли AI-система працює не в ноутбуці, а в національному сервісі.

Ця презентація призначена для інженерів, архітекторів та технічних лідерів, які хочуть не просто користуватись великими мовними моделями, але й розуміти, як вони працюють, як працювати через API, які є проблеми при створенні RAG-систем і як їх розв'язувати.

Під час виступу ми розберемо чому простого RAG уже недостатньо для організації з різними джерелами даних і як еволюціонують сучасні AI-системи: від класичного RAG до Deep Search, гібридного пошуку та Knowledge Graph як шару корпоративної пам’яті. Подивимось як поєднати неструктуровані документи, табличні дані, бази даних, внутрішні wiki, чати й бізнес-сутності в єдину систему, де AI знаходить релевантні джерела, будує маршрут пошуку, пояснює зв’язки між фактами та видає більш точні й перевірювані відповіді.

З розвитком AI інструментів IT галузь досягла тієї точки, коли зробити новий проєкт часто стає дешевше і простіше, ніж підтримувати існуючий. Проте для багатьох великих довготривалих проєктів переписування з нуля не найкращий варіант, особливо якщо навчитися їх підтримувати та розвивати за допомогою Agentic інструментів. Досвід роботи з подібними проєктами у всіх ключових аспектах роботи з людьми, інструментами, технологіями і процесами розглянемо на прикладі реальних кейсів.

Більшість інженерів рано чи пізно стикаються з необхідністю проводити load testing: перевірити масштабування сервісу, протестувати нову базу даних або зробити performance benchmark для нової технології. І тут виникає питання — який інструмент обрати? Існуючі рішення добре працюють для HTTP-навантаження, але часто мають обмеження, коли потрібно тестувати інші протоколи, моделювати складні workload-патерни (open vs closed systems, skewed distributions, hot partitions) або запускати distributed load testing у кластері. У цій доповіді я розповім про NBomber — Load Testing Framework, який я створив для вирішення цих задач. Ми поговоримо про: - чому виникла ідея створити новий інструмент попри існування Gatling, Locust та k6; - використання .NET та мови F# для побудови latency-sensitive систем; - архітектуру NBomber; - як працює NBomber Cluster; - кілька практичних кейсів: database benchmarks, anomaly detection, Kubernetes integration, benchmark comparison та аналіз performance trends.