Головна / Статті

Агентське прогностичне обслуговування на OpenVINO: один конвеєр, п’ять промислових сценаріїв використання.

Як конвеєр OpenVINO та LangGraph перетворює прогнози на докази та замовлення у різних конвеєрах, сонячних панелях, лініях електропередач, аудіо- та растрових даних на обладнанні Intel.

Видавець: REACTAPP.TOP7 хв читання1501 слів

Джерела: Building an Agentic AI Predictive Maintenance Pipeline with OpenVINO™ and Intel® Metro AI Suite

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

У цьому огляді розглядається проект Google Summer of Code 2026, який взяв за основу концепцію прогнозованого технічного обслуговування Intel Metro AI Suite, розроблену на базі OpenVINO, та розширив її новими сценаріями використання та наборами даних.

Розрив між прогнозом та рішенням

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

Проект був спрямований саме на це. Він поєднав інференс моделі зі структурованим зберіганням, координував агентів ШІ, запитання у природній мові та замовлення, засновані на доказах, усе це в межах одного робочого процесу.

Як складається конвеєр

Обробка починається з моделі OpenVINO, результати роботи якої записуються у файли JSONL та базу даних SQLite. Потім робочий процес LangGraph координує три агента: один відповідає за формування політики, інший — за аналіз, а ще один — за збір доказів. Користувачі можуть ознайомитися з результатами через чат або подати запит, підкріплений відповідними доказами.

Роботу над проектом сформували чотири покращення, спрямовані на зручність використання, пояснюваність, можливості розширення та широту застосування. Це різні виправлення, але всі вони входять до одного цільового процесу.

Чотири внески

Одна форма для кожного типу запитання

Раніше користувач мусив обирати між режимом аналізу, доказів та SQL перед тим, як щось ввести. Це означало необхідність знання того, як розділені внутрішні елементи системи, що є складною вимогою до оператора. Нова версія автоматично розпізнає намір користувача та надсилає запит до відповідного сервера як у командному рядку, так і в веб-інтерфейсі. Тепер ніхто більше не обирає режим.

Питання щодо необроблених даних з датчиків

Налаштовуваний схематизм SQLite було розширено для зберігання необроблених значень датчиків, рівня впевненості для кожної модальності та метаданих про сценарій використання. Це уможливлює постановку таких запитань: які зразки мали вищий рівень впевненості датчиків, ніж рівень впевненості щодо зображень? Умова, сформульована мовою природи, перетворюється на запит до бази даних, який повертає відповідні показники, мітки та джерельні записи. Цей самий контекст також надходить до агентів, відповідальних за політики та аналіз. Важливою є простежуваність, оскільки збережені необроблені значення та метадані пов’язують кожну відповідь із записами, з яких вона походить.

Нові моделі без перебудови

Початкова точка виконання інференції обробляла занадто багато завдань. Її розділили на окремі частини: налаштування, маршрутизація, обробники для кожної моделі, етап виконання, збереження результатів та їх візуалізація. Тепер диспетчер обирає невеликий, спеціалізований обробник, тоді як спільні компоненти відповідають за поведінку, характерну для кожного випадку використання. Додавання нового типу даних тепер означає написання обробника та конфігурації, а решта етапів життєвого циклу використовуються знову.

П’ять промислових випадків використання на одному середовищі виконання

Вхідні дані, цілі прогнозування та докази відрізняються у цих п’яти випадках, але вони використовують однакову інфраструктуру. Покриваються чотири типи вхідних даних: табличні дані, зображення, аудіо з текстом та растрові дані з текстом.

Трубопроводи нафти та газу. Таблиці з даними про експлуатацію та матеріали подаються до моделі OpenVINO MLP, яка одночасно прогнозує два показники: стан трубопроводу та зменшення товщини стінки. До вхідних даних належать геометричні параметри, матеріал, дані про експлуатацію та показники корозії. Кожен оброблений запис дає клас стану та оцінку зменшення товщини, причому обидва показники залишаються пов’язаними з початковими вимірюваннями. Це забезпечує можливість для наступних етапів обробки пояснити результат, використовуючи реальні показники експлуатації, а процес включає аналіз, спрямований на виявлення корозії.

Сонячні панелі. Детектор у стилі YOLO на базі OpenVINO шукає дефекти на одноканальних зображеннях електролюмінесценції сонячних елементів та зберігає рамки, що їх огороджують, як докази. На одному з зразків черваона рамка позначає справжню тріщину у вигляді зірки, яку має знайти детектор. Оцінка, проведена на всіх 19 150 тестових зображеннях, дала значення F1 у 0.8277. Прогнозована рамка зберігається разом із її класом та рівнем впевненості, щоб користувач міг бачити, де саме виявлено дефект.

Передача енергії. Налаштована модель YOLOv8s-cls сортує зображення ліній електропередач на три категорії схем. Вона працює як із синтетичними, так і з реальними зображеннями, що дозволяє перевірити, чи здатен один класифікатор обробляти як візуалізовані схеми, так і фотографії з польових перевірок. На 348 зображенняах, залишених для тестування, вона правильно ідентифікувала 334 з них, що дає точність у 0.9598. Обидві групи зображень проходять однакову попередню обробку та інференцію.

Технічне обслуговування середовища роботи. У цьому випадку аудіокліп поєднується з субтитрами. Їх обробляють окремо, класифікують за допомогою двох гілок моделі OpenVINO MLP, а потім поєднують шляхом пізньої фузії. Зразок, присвячений обертовим машинам, супроводжувався субтитрами про вібрацію електринструменту під час роботи. Відеокадр надає контекст для людського читача, але вхідними даними для моделі є аудіо з кліпу та текст. Гілки залишаються окремо доступними для перевірки до тих пір, доки їхні оцінки не будуть об’єднані.

Очищення води. 15-канальний растер Sentinel-2 поєднується з текстовим описом навколишнього середовища, наприклад описом округу в Арізоні з даними про евапотранспірацію, опади, глибину ґрунтових вод та глибину поверхневих вод. Статистичні характеристики растера та ознаки TF-IDF з тексту проходять через окремі відгалуження OpenVINO перед фінальним об’єднанням, що зберігає рівень впевненості кожного відгалуження. Генерується попередній перегляд у форматі JPEG, щоб люди могли побачити зразок, але сама модель використовує оригінальний багатоканальний масив NumPy. Попередній перегляд також можна додати до заявки, щоб надати видимі докази багатомодального прогнозу.

Робота на апаратному забезпеченні Intel

Кожна модель була реалізована у форматі OpenVINO IR, причому єдиний налаштовуваний точка входу обробляє зображення, табличні вектори датчиків, аудіохарактеристики та парні багатомодальні дані. Код було перевірено на GPU Intel, а процес інференсу через цю систему також підтверджено на NPU Intel, включаючи генерацію результатів у форматах JSONL та SQLite.

Тестування — це більше, ніж лише точність

Перевірка охоплювала не лише точність моделей. Кожен робочий процес було протестовано від завантаження моделі та структурованого форматування результатів через агенти, інтерфейси, докази, замовлення та виконання на обладнанні Intel. Перевірки стосувалися як меж між компонентами, так і результатів окремих моделей.

Що демонструють демонстрації

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

Другий підхід — це єдиний чат. Користувачі переглядають узагальнення аналізу, досліджують докази та фільтрують результати, а також запитують інформацію зі структурованих даних про технічне обслуговування. Після дослідження вони можуть створити заявку на обслуговування для подальшої роботи. Це демонструє весь процес від аналізу результатів до подання заявки.

Уроки з проектування

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

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

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

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

Те, що спочатку було конвеєрною системою, створеною для одного конкретного випадку використання, стало більш модульним, багатомодальним та орієнтованим на користувача. OpenVINO забезпечує спільний шар інференсу, а структуроване зберігання разом із координованими агентами перетворюють результати моделі на інформацію, яку людина може переглянути та використати. Той самий процес — від промислових даних через інференс та докази до аналізу на природній мові та створення заявок — тепер використовується у кількох сферах технічного обслуговування.

  • Практичні нотатки: GLM-5.3-Flash: 320B Open-Source Native Multimodal Agentic Model — Детальний огляд Практичних нотаток: GLM-5.3-Flash: 320B Open-Source Native Multimodal Agentic Model, включаючи контракти, перевірки та шаблони коду для команд, які використовують цю модель.