Кожен, хто створив розумний дім, знає розпорядок: одне додаток для тьмяного світла, інше, щоб регулювати термостат, і голосовий помічник, який розуміє лише точне фразування. Ці системи називають себе розумними, але на практиці вони часто жорсткі і розчаровують.
Новий документ Алакеша Каліти, старшого члена IEEE, пропонує інший шлях. Поєднуючи LLM з IoT Networks на краю, пристрої могли реагувати на природні мови командами таким чином, що відчуває себе інтуїтивно зрозумілим та узгодженим. Замість того, щоб керувати кожним пристроєм окремо, користувач може видати одну широку команду і дозволити системі розібратися в деталях.
Запропонована рамка поділяється на кілька структурованих модулів, які обробляють збір даних, обробку, оперативне створення, обробка відповідей та управління приводом
Традиційні системи IoT покладаються на просту командну логіку. Користувач може вимкнути світло або відрегулювати термостат за допомогою одноразового додатка або датчика. Ці системи працюють, але вони вимагають від користувачів, щоб точно прописати, чого вони хочуть, часто через кілька кроків. Підхід Каліти додає інтерфейс природної мови, що працює від LLMS, що дозволяє користувачам видавати більш широкі, гнучкі команди, такі як “Налаштування до кіномани”. Потім система може інтерпретувати цей запит і запустити кілька пристроїв, таких як затемнення вогнів, увімкнення телевізора та регулювання температури.
Модульна, перша рамка
Щоб зробити цю роботу на практиці, дослідник представляє модульну, орієнтовану на край. Замість запуску LLMS на кожному пристрої IoT, який є непрактичним завдяки обмеженим ресурсам, моделі працюють на більш спроможному обчислювальному пристрої, підключеному до шлюзу мережі. Ця установка обробляє дані локально, що зменшує затримку та покращує конфіденційність.
Система поділяється на кілька модулів. Він починається з модуля збору даних IoT, який збирає дані датчиків та команди користувачів за допомогою MQTT, легкого протоколу обміну повідомленнями. Далі формати модуля обробки даних та фільтрують цей вхід. Історичні дані зберігаються окремо і можуть бути використані пізніше для забезпечення контексту прийняття рішень.
Справжнє нововведення випливає з того, як система створює підказки для LLM. Модуль створення оперативного створення поєднує дані датчика в режимі реального часу із збереженою історією, щоб генерувати структурований підказку, використовуючи підхід, що перевищує пошук (RAG) підходу. Цей структурований вхід допомагає LLM забезпечити більш точні відповіді на ситуацію.
Після того, як LLM обробляє підказку, вихід передається модулю обробки відповідей, який розбирає його у стандартний формат. Потім модуль поводження з приводом надсилає відповідні команди на пристрої IoT.
Тестування підходу в розумному будинку
Щоб перевірити цю установку, дослідники побудували прототип розумного будинку, використовуючи Raspberry Pi 5 як крайовий пристрій. Три прилади, світло, телевізор та вентилятор, були підключені за допомогою мікроконтролерів ESP8266. Було протестовано два LLM: Llama 3 (7b) та Gemma 2b. Команди, такі як “Встановити місце для навчання” або “Я хочу спати зараз”, були видані через текстовий інтерфейс. Моделі інтерпретували команди, створили відповіді JSON та відправили правильні дії.
Llama 3 надала відповіді з більшою семантичною точністю, але зайняв значно довше, до 208 секунд. Gemma 2b була набагато швидшою, до 30 секунд, але періодично неправильно зрозуміла команду. Це підкреслює основний компроміс. Більш великі моделі є більш точними, але повільнішими, тоді як менші моделі швидше, але можуть потребувати налаштування для конкретних завдань.
Розширення випадків використання
Автор також досліджує випадки більш широкого використання. У промислових умовах LLMS може посилити прогнозне обслуговування шляхом інтерпретації складних моделей датчиків. У галузі охорони здоров’я вони могли підтримувати моніторинг в режимі реального часу та персоналізовані сповіщення на основі даних про носіння датчиків.
Для ефективності комунікації LLM, що розгортається EDGE, може зменшити використання пропускної здатності, генеруючи компактні, семантичні описи замість надсилання необроблених даних. Це було б особливо актуально в 5G та майбутніх мережах 6G.
Проблеми з безпекою на краю
Безпека – це головне врахування, коли LLMS контролює пристрої IoT. Chas Clawson, Field CTO, безпека в Sumo Logic, заявила Help Net Security, що галузь довго зосереджена на захисті людських ідентичностей, але тепер повинна застосовувати ту саму суворість до нелюдських ідентичностей, які можуть викликати фізичні зміни. Він зазначив, що дослідження вдосконалюють гарантії, щоб зробити шляхи контролю LLM більш безпечними та детермінованими, але “нам все ще потрібен довіра, але перевіряє підхід: завершити кожну дію з моніторингом, перевірками політики та сповіщеннями про збої контролю чи порушення граничних наконечників”.
На практиці Клаусон рекомендує централізувати канали журналу для критичних систем, додавання виявлення для поведінки зовнішньої частини та розширення телеметрії поза журналами пристроїв, щоб включити підказки, результати моделі, відмови валідатора та рішення про привід як події аудиту першого класу. Він також радив перенести “подальше ліворуч”, моніторинг змін до коду програми, моделі та конфігурації RAG та розгортання за допомогою мислення ланцюга постачання програмного забезпечення, щоб запобігти непоміченому впровадженню вразливості.
Документ також застерігає, що виклики залишаються. Конфіденційність викликає занепокоєння, коли конфіденційні дані обробляються LLMS. Місцеве виконання Edge пропонує кращу конфіденційність, ніж хмарні моделі, але також обмежує масштабованість. У критичних умовах, таких як охорона здоров'я або промислова автоматизація, помилки з LLM можуть мати фізичні наслідки. Автор пропонує поєднувати LLM з системами, заснованими на правилах, та розробити орієнтири, що стосуються домену, для підвищення надійності.