[정보💡] 스마트싱스 루틴 생성 어시스턴트의 작동원리 - 스마트홈의 생성형 AI

[스싱마스터(stmaster)]

https://gall.dcinside.com/mgallery/board/view/?id=smartthings&no=9731

스마트싱스 루틴 생성 어시스턴트의 개념

루틴 생성 어시스턴트의 개념에 대해 살펴봤음. 이제 한 발 더 들어가서, 루틴 생성 어시스턴트가 어떻게 사람의 말을 루틴으로 바꿔내는지 그 내부 과정을 알아보려고 함.

스마트싱스의 루틴 생성 어시스턴트의 전체적인 루틴 생성 파이프라인이 모두 밝혀진 것은 아니지만

루틴생성 어시스턴트 안에서 스마트싱스의 자료가 어떻게 받아지고, 바뀌는 지는 알 수 있기 때문임

글 시작에 앞서 루틴 생성 어시스턴트의 파이프라인을 간단하게 요약하자면 다음과 같음

1단계) 먼저 스마트싱스에 등록된 유저의 계정 속 정보를 파악한다 (기기 목록, 위치 정보, 시간대, 날씨 등) 

2단계) 스마트싱스 안에 유저의 계정 속 정보랑 자연어로 만들어진 명령 가운데 조건에 맞는 것을 생성형 AI가 고른다. 

3단계) 골라진 조건을 '언제실행할까요'와 '무엇을할까요'로 치환해서 루틴 생성을 마침

그래서 스마트싱스 루틴생성 어시스턴트에는 deviceMap이 있음.

deviceMap을 간단히 말하자면 어떤 기기를, 어떤 기능으로, 어떤 조건에서 쓸 수 있는지 완벽히 정의하는 설계도가 바로 deviceMap임. 

왜 디바이스맵이 필요하냐면 사람은 에어컨,불 이렇게 간단하게 말하지만, 스마트싱스 안에는 그렇게 단순하게 기록되어 있지 않기 때문이고, 내 계정에 등록된 기기가 여러개일 수도 있고, 어느 방을 기준으로 해야할지도 모호하기 때문.

deviceMap은 사용자의 계정 속 기기들의 메타데이터인 카테고리와 기능인 capabilities로 정리해둔 일종의 사전의 형태를 가지고 있음

따라서 생성형 AI가 에어컨이라는 단어를 만나면, deviceMap으로 불리는 사전을 뒤져서 실제 루틴에서 호출 가능한 에어컨을 찾고, 이 명령이 어떤것과 연관이 있는지 알아보는 일을 함.

사전의 특징은 키와 값으로 이루어져있다는 거임. 데이터가 저장될 때 키와 값이라는 2가지의 정보를 반드시 저장함

1. 사전안에 들어가는 단어가 어떤 성격을 가지고 있는지

2. 사전안에 들어가는 단어가 무엇인지

간단한 디바이스 맵으로 확인해보려고함

"deviceMap": { "airPurifierSwitch1": { "deviceCategories": [ "AirPurifier" ], "capabilities": [ "switch", "airQualitySensor" ] }, "lightSwitch1": { "deviceCategories": [ "Light", "Switch" ], "capabilities": [ "switch" ] }, "airConditionerSwitch1": { "deviceCategories": [ "AirConditioner" ], "capabilities": [ "switch" ] },

이것은 스마트싱스 루틴 생성 어시스턴트가 가지고 있는 airPurifierSwitch1, lightSwitch1, airConditionerSwitch1의 디바이스 맵임

사용자가 공기청정기에 대한 루틴을 원하면, 스마트싱스 디바이스 카테고리에서 AirPurifier 카테고리인 디바이스 리스트를 뽑아오는거임

그리고 디바이스 리스트 안에서도 온오프 스위치랑 공기질 관련 capability를 뽑아올 수 있게됨.

여기서 키는 deviceCategories, capabilities이고 값은 대괄호 안에 들어간 문자들임. (대괄호는 1개 이상의 값이 들어갈 수 있다는 뜻)

이렇게 deviceMap은 구조체의 성격을 가지고 있음. 그리고 deviceMap 자체도 각 기기들을 값으로 가지고 있는 키임

"tempSensor1": { "deviceCategories": [ "AirQualityDetector", "TempSensor", "MultiFunctionalSensor", "Button", "GenericSensor", "TempHumiditySensor" ], "capabilities": [ "temperatureMeasurement" ] },

"blindWindowShade1": { "deviceCategories": [ "Blind" ], "capabilities": [ "windowShade", "switch" ] },

디바이스 맵은 여러 값을 복잡하게 가질 수도 있으면서도, 꼭 필요한 기능만 가져오게끔 해서 생성형 AI가 더 확실하게 우선순위를 판단하기 위한 일을 하기도 함

사용자가 온도센서 관련 루틴을 만들고싶을때 deviceMap에서는 공기질 감지, 온도 감지, 다목적 센서, 버튼, 제네릭 센서, 온습도 센서와 같은 광범위한 카테고리의 디바이스를 호출할 수 있음. 그런데 그 중에서도 temperatureMeasurement 라는 capability를 뽑아올 수 있음. 

여기까지 deviceMap을 알아봤는데, 이제 deviceMap을 활용하는 templeteMap을 소개하려고함

templeteMap은 루틴 생성 어시스턴트를 처음 켰을때 위쪽에 뜨는 다여섯개의 추천 루틴을 말함

이것이 왜 중요하냐면 생성형 AI에게 전달하는 프롬프트가 자연어가 아닌 형태로 바로 쏘아지기 때문임.

쉽게 말해서 templeteMap을 알면 사용자가 자연어로 말한 명령이 어떤 형태가 되어 최종적으로 생성형 AI에게 보내지는 지 알 수 있게 된다는 것임.
 

"templateMap": { "KO": { "routineSuggestions": [ { "template": "오전 9시에 \"굿모닝~ 좋은아침\" 인사해줘", "types": [ "GENERAL" ], "priority": 999 },

이게 매우 간단한 템플릿 맵의 모습임

오전 9시에 \"굿모닝~ 좋은아침\" 인사해줘 라는 템플릿이 있음

이 것의 타입은 General이고, 우선순위는 999임. 이것이 매우 낮은 우선순위를 가지고 있다는 것을 알 수 있음..

{ "template": "밤에 실내 온도가 20도 이하로 떨어지면 {fanSwitch1.deviceName} 꺼줘", "types": [ "DEVICE" ], "suggestionCondition": { "deviceInfoList": [ { "deviceMapKey": "tempSensor1", "onlyOneDevice": true, "restrictedOneRoom": true }, { "deviceMapKey": "fanSwitch1", "onlyOneDevice": true, "restrictedOneRoom": true } ], "roomPriority": [ "복도", "거실", "안방", "서재" ] }, "priority": 1 },

그리고 이게 최고로 높은 우선순위를 가진 복잡한 템플릿맵임

키와 값이 확많아졌지?

여기서 우리는 타입에 집중해야함. types에 담겨질 수 있는 모든 타입의 리스트는 다음과 같음

DEVICE: 스마트싱스에 붙어있는 기기 

MEMBER: 스마트싱스 멤버 위치인 가족/사용자의 위치나 상태 

GEOLOCATION: 날씨, 해뜰/해질 시각, modes의 외출 여부 

DUST: 날씨의 미세먼지 상태

SECURITY: 스마트싱스 홈 모니터링의 상태

이 값중에 공개되지 않은 것들이 많고, 스마트싱스 안에서 내부적으로 처리되는 것들이 대부분임

그래서 DEVICE만 확인할 수 있음.

DEVICE 타입의 특징은 deviceMap을 호출한다는 것에 있음. 그러니까 types가 DEVICE 일 때만 deviceMap이 쓰임.

그 다음은 priority에 집중해보면

숫자가 작을 수록 우선순위가 높은 복잡한 루틴이고, 숫자가 클 수록 우선순위가 낮은 단순한 루틴이라는 것을 알 수 있음

위에 올린 templeteMap을 보면, priority가 제일 높은 순위인 1인 템플릿은 기기 연동, 위치 기반 등 여러 타입이 쓰인 것들이고 

priority가 999인 매우 후순위의 템플릿은 딱히 스마트싱스에 기기가 없어도 만들 수 있는 일반적인 시간/날씨 기반 알림 기반의 루틴이라는 것을 알 수 있음.

자 그러면 types가 DEVICE일때 파이프라인을 살펴보면 다음과 같음. 참고로 생성형AI가 구조체를 읽는 순서가 있기는 하지만 일처리를 딱히 순서대로 하는건 아님

- deviceMap을 열고 각 key가 어떤 카테고리와 capabilities인지 파악함. 

- 스마트싱스의 계정에 등록된 기기 목록에서 필터링을 시작함 

- onlyOneDevice로 기기가 하나만 있는지 확인함.

- restrictedOneRoom으로 기기가 모두 같은 방에 있는지 여부를 찾아봄. 여기서 같은 유형의 기기가 여러 방에 있을 때 우선 매핑할 방 순서도 정함.

- roomPriority로 같은 유형의 기기가 여러 방에 있을 때 우선 매핑할 방 순서를 정함.

정리하자면 사람이 자연어로 루틴 생성 어시스턴트에게 부탁한 자연어가 여러 단계의 형 변환 과정을 거쳐 스마트싱스가 바로 이해하고 실행할 수 있는 구조화된 루틴으로 바뀌게 됨. 이 과정의 중간에서 여러 Map이 만들어지고 스마트싱스 APi의 capability과 매칭됨. 그런 다음 SmartThings Rule API의 Json 자동화 포맷에 맞춰 만들어짐. 

이 과정에서 주목할것은 루틴생성어시스턴트가 개인화에 집중했다는 거임. 단순히 생성형 AI가 파운데이션 모델로부터 학습한 이미 알고있는 코드만 뽑아주는게 아니라, 스마트싱스 계정에 등록된 내 집의 여러 환경을 고려해서 우선순위를 나누고 내 집에서 돌아갈 가능성이 높은 검사를 거치기때문에 유용한 루틴을 뽑아낼 수 있도록 파이프라인의 설꼐가 되어있는 거임. 

[스싱붕이 1(211.107)]

일단 선개추

[스싱붕이 2(58.121)]

교수님 진도가 너무 빨라요