Trane скоротив діагностику HVAC у 60 разів

Чому одного дашборда не досить

У Trane Cloud стікаються дані з мільйонів HVAC-систем — датацентрів, лікарень, заводів, комерційної нерухомості. Проблема була не в браку даних, а в тому, що різним ролям потрібні різні зрізи одних і тих самих даних. Польовий технік шукає тиск хладагенту, код несправності й покрокову діагностику. Керівник з роботи з клієнтами дивиться на показники безвідмовної роботи, економію коштів і тренди по портфелю об'єктів. Власник будівлі хоче просту оцінку ефективності. Старий інтерфейс був один на всіх — і кожна роль продиралася через меню, розраховане на когось іншого.

Тому команда відмовилась від одного універсального агента-«мозку» і побудувала п'ять вузьких: кожен зі своїм системним промптом і вузькою зоною відповідальності. Коли треба додати новий інструмент чи оновити один сценарій, змінюється тільки один агент, а не вся система.

П'ять агентів і що кожен насправді робить

Розподіл побудований навколо типів запитів, а не відділів компанії:

• Resources Assistant — довідкова інформація: Хто мій контакт, який посібник застосувати, яку документацію надіслати клієнту?
• Knowledge Assistant — технічні пояснення про роботу обладнання й параметри системи, включно з питаннями на кшталт того, чи атестована інфраструктура Trane Cloud за стандартом SOC 2
• Analytics Insights Assistant — робота з живою телеметрією: шукає можливості підвищити ефективність, позначає обладнання для перевірки, простежує першопричину несправності
• Expert Advisor — підбір рішення під сценарій клієнта і допомога зібрати демонстрацію продукту
• Navigation Assistant — видає точні посилання: форму ескалації в техпідтримку, сторінку замовлення запчастин

Архітектура відкрита для розширення: нові агенти чи інструменти — наприклад, системи управління заявками або CRM — підключаються через той самий шлюз без окремої інтеграційної роботи під кожну систему.

Контроль доступу і захист від зловживань

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

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

Як перевіряли рішення, перш ніж довіритись йому

Прототип показали керівництву за 3–4 тижні, але зовнішнім клієнтам агент дістався не одразу. Спочатку його впровадили серед внутрішніх польових техніків-бета-тестерів — саме вони ставлять найвимогливіші діагностичні запити, тож їхній фідбек виявив прогалини в точності й зручності в реальних умовах. Лише після доопрацювання рішення відкрили зовнішнім клієнтам.

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

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