AI‐Learning ‐ 세부기능 - nhnacademy-aiot3-4iren/4iren-wiki GitHub Wiki

AI Learning — 세부기능

repo: 4iren-machine-learning (실제 운영 코드는 develop 브랜치에 있으며, main에는 초기 실험용 노트북만 남아 있습니다)

머신러닝 파이프라인

0. 현재 구현 현황 (develop 브랜치 기준, 2026-08-31 PR #8 병합)

0.1 실행 방식

  • 별도의 상시 API 서버가 아니라, self-hosted GitHub Actions로 매일 03:17(KST) 실행되는 야간 배치 Job입니다 (.github/workflows/nightly-feedback-update.yml). workflow_dispatch로 수동 실행도 가능합니다.
  • Python 3.12 패키지 fouriren_ml로 구현되어 있으며, 웹 프레임워크(FastAPI/Flask 등)는 사용하지 않습니다.

0.2 데이터 소스

  • 사용자 피드백: notification-service의 내부 API GET /api/notification/internal/feedback-exports에서 커서 기반(X-Last-Feedback-Log-Id)으로 신규 피드백만 조회합니다.
  • 센서 시계열: core-api의 Room Sensor Series(10분 간격)를 조회합니다.
  • 두 소스 모두 일시 장애·불완전 시계열 시에는 새 릴리스를 만들지 않고 안전하게 종료합니다.

0.3 갱신 범위 (전체 재학습이 아님)

  • 신규 피드백을 기존 feedback_history.csv와 병합·중복 제거한 뒤, 최근 5일치 데이터로 temperature/humidity residual adapter와 강의실별 선호도 프로필(preference profile)만 증분 갱신합니다.
  • 나머지 ONNX 모델(온습도 base 회귀, 분류기, Behavior 7종)은 재학습 없이 이전 버전을 그대로 상속합니다.
  • 신규 피드백이 없으면 NO_NEW_FEEDBACK으로 종료하고 새 버전을 만들지 않습니다(MinIO 호출도 하지 않음).

0.4 모델 구성 — ONNX 10개가 운영 모델의 SSOT

구분 개수 역할
분류기(Classifier) 1 센서 지시문 라벨링 (CO2_RISING_FAST, CO2_HIGH_STABLE, CO2_RECOVERING, TEMP_RISING_FAST, TEMP_FALLING_FAST, DRY_AIR, HUMIDITY_HIGH, NO_ACTION) → 행동 후보(action_candidates)로 매핑
회귀(Regression) 2 온도·습도 Spline Ridge base 예측 + 최근 5일 residual adapter로 보정
Behavior 7 냉난방(HVAC) on/off 이벤트, 환기 이벤트, 일별 사용 패턴 등 학습

.joblib 등 sklearn 객체 파일은 저장하지 않고, 검증(ONNX↔sklearn parity)까지 마친 ONNX만 영속화합니다.

0.5 검증 및 배포 절차

  1. staging 디렉터리에 새 Bundle 생성 → 체크섬 검증 → 별도 프로세스로 ONNX 세션 생성·smoke test
  2. Serving Bundle(21개 파일)과 Training State가 각각 검증을 통과해야만 active pointer가 새 버전으로 승격 (os.replace로 원자적 공개)
  3. 검증된 Bundle만 MinIO에 versions/{modelVersion}/, training-state/{modelVersion}/ 두 prefix로 게시. 두 prefix 업로드는 원자적이지 않아 실패 시 자동 롤백하지 않고 전체 실패로 종료됩니다.

0.6 하류 연동

  • recommendation-api의 MinioModelBundleDownloader가 이 Job이 게시한 모델 Bundle을 서버 기동 시 내려받아 BehaviorRecommendationService(ONNX Runtime, Java)로 추론합니다.
  • 추론 결과(mlRecommendation)는 recommendation-api의 웰컴 브리핑 생성 프롬프트에 근거자료로 투입됩니다.

0.7 학습 대상 공간의 제약 (중요)

모델은 강의실마다 별도 모델을 두지 않는다. 공통 모델 하나 위에 공간별 보정값을 얹는 구조다.

  • 분류기는 location을 입력 피처로 사용하는 단일 모델이다.
  • 공간별 개인화는 온·습도 잔차 보정(residual adapter)과 선호 환경 프로필로만 이루어진다.
  • 대상 공간 목록이 constants.py에 상수로 정의되어 있으며(ROOM_ID_BY_LOCATION), 이 목록에 없는 공간의 데이터는 피처 생성 단계에서 제외된다. 즉 새 강의실을 추가하려면 코드 수정이 필요하며, 자동으로 학습 대상이 되지 않는다.

0.8 아래 "설계 배경" 문서와의 주요 차이

  • 실행 주기: 설계상 "5분마다 실시간 추론" → 실제는 1일 1회 야간 배치
  • 피처 집계 윈도우: 설계상 15분 → 실제 분류기 피처는 10분(co2_avg_10m 등, constants.py)
  • 출력에 confidence/confidenceLevel 필드 없음 (InferenceService.predict는 sensorLabels/actionCandidates/locationPreference만 반환)
  • 라벨셋 일부 명칭 차이: TEMP_LOW_FALLING → TEMP_FALLING_FAST, WARM_DRY_AIR → DRY_AIR
  • 재실·밀집도 추정, 원인 분석 API(MCP Tool) 등은 미구현
  • 설계에 있던 "새 공간 자동 적응(플러그앤플레이)"은 미구현 — 0.7 참조

설계 배경 (초기 요구사항 정의)

아래는 프로젝트 초기에 작성된 요구사항 명세입니다. 실제 구현과 세부 수치·용어가 다를 수 있으므로, 현재 동작 기준은 위 "0. 현재 구현 현황"을 따릅니다.

실내 센서 기반 환경 상태 판단 모델 기능 요구사항

1. 기능 개요

실내 센서 기반 환경 상태 판단 모델은 강의실 및 실내 공간에서 수집되는 CO₂, 온도, 습도, 활동 감지, 출입문 센서 데이터를 분석하여 현재 공간의 환경 상태를 분류하는 기능이다.

모델은 에어컨, 환기장치 등의 기기를 직접 제어하지 않는다. 모델은 현재 실내 환경 상태를 나타내는 지령과 신뢰도를 반환하며, 이후 LLM 및 제어 정책 계층이 외부 날씨, 미세먼지, 기기 상태, 공간별 선호 통계 등을 추가로 고려하여 최종 제어 여부를 결정한다.

2. 기능 목적

본 기능의 목적은 다음과 같다.

  1. 실내 CO₂, 온도, 습도 상태를 주기적으로 분석한다.
  2. 단순 현재값뿐 아니라 단기 변화량과 일정 시간 동안의 추세를 함께 분석한다.
  3. 현재 공간에서 환기, 냉방, 난방, 습도 관리가 필요한 상태인지 분류한다.
  4. 모델의 판단 결과와 예측 신뢰도를 후속 LLM 판단 단계에 전달한다.
  5. 모델과 제어 로직을 분리하여 안전하고 설명 가능한 환경 제어 구조를 제공한다.

3. 데이터 수집 및 실행 주기

3.1 원본 데이터 주기

실내 센서 데이터는 5분 단위로 수집한다.

각 데이터에는 최소한 다음 정보가 포함되어야 한다.

  • 측정 시각
  • 센서 장치 식별자
  • 공간 식별자 또는 공간명
  • 측정 항목
  • 측정값

3.2 모델 실행 주기

모델 추론은 5분마다 수행한다.

모델은 매 실행 시점마다 현재 시점까지 수집된 실내 센서 데이터를 기반으로 공간별 환경 상태를 판단한다.

3.3 분석 구간

순간적인 센서 노이즈를 줄이기 위해 현재 센서값 하나만 사용하지 않고 최근 15분 데이터를 집계하여 사용한다.

예시는 다음과 같다.

  • 09시 05분 판단: 08시 50분부터 09시 05분까지의 데이터 사용
  • 09시 10분 판단: 08시 55분부터 09시 10분까지의 데이터 사용
  • 09시 15분 판단: 09시 00분부터 09시 15분까지의 데이터 사용

즉, 분석 구간은 최근 15분이며 실행 간격은 5분이다.

4. 사용 센서 데이터

4.1 모델 학습 및 추론에 사용하는 데이터

모델은 다음 실내 센서 데이터를 사용한다.

  • CO₂ 농도
  • 실내 온도
  • 실내 습도
  • 활동 감지값
  • 출입문 이벤트
  • 측정 시간
  • 요일
  • 공간 정보

4.2 모델에서 제외하는 데이터

다음 데이터는 신뢰성 및 설치 환경 영향을 고려하여 모델 학습에서 제외한다.

  • 조도
  • 적외선 광량
  • 적외선 및 가시광 복합값
  • TVOC
  • 외부 날씨
  • 외부 미세먼지

외부 날씨와 미세먼지는 모델에 직접 입력하지 않고 LLM 판단 단계에서 현재 실내 환경 상태와 함께 사용한다.

4.3 활동 및 출입문 데이터의 해석

활동 감지와 출입문 데이터는 재실 여부를 확정하는 값으로 사용하지 않는다.

활동이 감지된 경우 공간 사용 가능성을 높이는 보조 증거로 사용할 수 있으나, 활동이 감지되지 않았다고 해서 공간이 비어 있다고 판단하지 않는다.

출입문 이벤트도 사람의 입실 또는 퇴실 방향을 확정할 수 없으므로 공간 전환이 발생했다는 보조 정보로만 사용한다.

5. 공간별 데이터 통합

동일 공간에 같은 종류의 센서가 여러 개 설치된 경우, 센서 데이터를 공간 단위로 통합한다.

예를 들어 하나의 강의실에 CO₂ 센서가 여러 개 설치되어 있다면 각 센서값을 이용하여 공간 대표값을 생성한다.

기본적으로 다음 값을 생성할 수 있다.

  • 공간 내 CO₂ 평균
  • 공간 내 CO₂ 최대값
  • 공간 내 CO₂ 최소값
  • 공간 내 CO₂ 표준편차
  • 정상 수신된 CO₂ 센서 개수

온도와 습도도 공간별 평균값을 기본 대표값으로 사용한다.

센서별 값 차이가 큰 경우 단순 평균만으로 국소적인 고농도 상태가 가려질 수 있으므로, CO₂ 최대값과 센서 간 편차를 보조 정보로 사용할 수 있다.

6. 모델 입력 피처

6.1 기본 피처

모델은 다음 기본 피처를 입력으로 사용한다.

  • location
  • co2_avg_15m
  • temperature_avg_15m
  • humidity_avg_15m
  • activity_sum_15m
  • door_open_count_15m
  • hour
  • weekday

6.2 단기 변화 피처

5분 전의 최근 15분 평균과 현재 최근 15분 평균을 비교하여 단기 변화량을 생성한다.

  • co2_delta_5m
  • temperature_delta_5m
  • humidity_delta_5m

예를 들어 co2_delta_5m은 다음 의미를 가진다.

현재 시점의 최근 15분 CO₂ 평균에서 5분 전 시점의 최근 15분 CO₂ 평균을 뺀 값

연속된 분석 구간은 일부 시간이 겹치므로, 해당 변화량은 순간 센서값 차이가 아니라 최근 15분 평균 상태가 5분 동안 어떻게 변했는지를 의미한다.

6.3 중기 변화 피처

5분 단위의 순간 변화만으로 상태를 판단하면 센서 노이즈에 민감할 수 있으므로 최근 30분 변화량을 함께 사용한다.

  • co2_change_30m
  • temperature_change_30m
  • humidity_change_30m

co2_change_30m은 현재 최근 15분 평균과 30분 전 최근 15분 평균의 차이를 나타낸다.

5분 단위 데이터에서는 30분 전 값을 참조하기 위해 동일 공간의 6개 이전 행을 사용한다.

6.4 누적 상태 피처

일시적인 변동과 장시간 지속된 상태를 구분하기 위해 다음 누적 피처를 사용한다.

  • co2_rolling_max_1h

해당 피처는 최근 1시간 동안 계산된 CO₂ 대표값 중 최대값을 의미한다.

6.5 추가 검토 피처

센서 데이터 품질 및 공간 내 편차를 분석하기 위해 다음 피처를 추가할 수 있다.

  • co2_room_max_15m
  • co2_room_min_15m
  • co2_room_std_15m
  • co2_sensor_count_15m
  • co2_sensor_rising_count
  • sensor_event_sum_15m

이 피처들은 초기 모델 성능과 데이터 품질 분석 결과에 따라 최종 사용 여부를 결정한다.

7. 모델 출력 상태

모델은 현재 공간 상태를 다음 지령 중 하나로 분류한다.

7.1 NO_ACTION

현재 센서 상태가 별도의 환경 조치가 필요한 조건에 해당하지 않는 상태이다.

7.2 CO2_RISING_FAST

현재 CO₂ 농도가 높거나 주의 구간에 있으며, 단기 및 중기적으로 빠르게 상승하고 있는 상태이다.

인원 증가, 환기 부족 등의 가능성이 있으나 모델은 원인을 확정하지 않고 CO₂ 상승 상태만 반환한다.

7.3 CO2_HIGH_STABLE

CO₂ 농도가 높은 상태로 일정 시간 유지되고 있으며 변화량은 상대적으로 크지 않은 상태이다.

단기적으로 급상승하지 않더라도 고농도 상태가 지속되고 있음을 의미한다.

7.4 CO2_RECOVERING

CO₂ 농도가 일정 시간 동안 감소하고 있어 실내 공기질이 회복되는 상태이다.

단일 5분 변화만으로 판단하지 않고 30분 변화량을 함께 고려하여 일시적 노이즈와 실제 회복 상태를 구분한다.

7.5 TEMP_RISING

현재 온도가 기준 이상이면서 단기 또는 중기적으로 상승하고 있는 상태이다.

모델은 냉방 실행 명령을 직접 반환하지 않고 온도 상승 상태만 반환한다.

7.6 TEMP_LOW_FALLING

현재 온도가 낮은 구간에 있으며 추가로 하락하고 있는 상태이다.

모델은 난방 실행 명령이 아니라 저온 하락 상태를 반환한다.

7.7 HUMIDITY_HIGH

현재 실내 습도가 설정된 고습 기준 이상인 상태이다.

7.8 WARM_DRY_AIR

실내 온도가 비교적 따뜻한 상태에서 습도가 낮거나 지속적으로 감소하는 상태이다.

단순히 습도가 낮다는 이유만으로 해당 상태를 반환하지 않는다. 저온 환경의 낮은 습도와 난방 등에 의해 발생할 수 있는 따뜻하고 건조한 환경을 구분하기 위해 온도, 습도 및 변화량을 함께 고려한다.

8. 라벨 판정 원칙

8.1 절대값과 변화량 결합

환경 상태는 현재 센서값 하나만으로 판정하지 않는다.

예를 들어 CO₂가 동일하게 900ppm이라도 다음 두 상태는 다르게 판단해야 한다.

  • 700 → 800 → 900ppm: 상승 상태
  • 1,100 → 1,000 → 900ppm: 회복 상태

따라서 현재값, 5분 변화량, 30분 변화량을 함께 사용한다.

8.2 라벨 우선순위

하나의 시점에서 여러 조건이 동시에 성립할 수 있으므로 라벨 판정 우선순위를 정의해야 한다.

예를 들어 고습 상태와 CO₂ 급상승 상태가 동시에 발생할 수 있다.

초기 모델에서는 안전성과 긴급도를 고려하여 다음 순서를 적용한다.

  1. CO₂ 급상승
  2. CO₂ 고농도 지속
  3. CO₂ 회복
  4. 저온 하락
  5. 고온 상승
  6. 고습
  7. 따뜻하고 건조한 상태
  8. 별도 조치 없음

라벨 우선순위는 EDA 및 운영 검증 결과에 따라 조정할 수 있다.

8.3 라벨 임계값

5분 데이터의 변화량은 기존 15분 데이터보다 작을 가능성이 높으므로 기존 변화량 기준을 그대로 사용하지 않는다.

CO₂, 온도, 습도 변화량 임계값은 다음 절차로 결정한다.

  1. 5분 변화량 분포 분석
  2. 30분 변화량 분포 분석
  3. 상위·하위 분위수 확인
  4. 각 후보 임계값별 라벨 발생 건수 확인
  5. 실제 센서 시계열과 대조
  6. 클래스 불균형 여부 확인
  7. 최종 임계값 확정

절대 CO₂, 온도, 습도 기준과 변화량 기준은 별도로 관리한다.

9. 모델 학습 요구사항

9.1 모델 종류

초기 모델은 RandomForestClassifier를 사용한다.

RandomForest를 사용하는 이유는 다음과 같다.

  • 비선형 임계값 조합을 표현할 수 있음
  • 범주형·수치형 전처리 파이프라인과 결합 가능
  • 예측 확률을 제공할 수 있음
  • 모델 설명 및 feature 중요도 확인이 가능함
  • ONNX 변환 및 Java 환경 배포가 가능함

9.2 전처리 파이프라인

모델 파이프라인에는 다음 전처리를 포함한다.

  • 공간명 범주형 인코딩
  • 수치형 결측값 대체
  • 입력 컬럼 순서 고정
  • 알 수 없는 신규 공간값 처리

범주형 공간값은 OneHotEncoder를 사용하며, 학습 당시 존재하지 않았던 공간이 입력되어도 추론 과정이 실패하지 않도록 설정한다.

수치형 결측값은 학습 데이터의 중앙값으로 대체한다. 중앙값 계산은 전체 데이터가 아니라 학습 구간에서만 수행하여 미래 데이터 누수를 방지한다.

9.3 학습·검증 데이터 분리

센서 데이터는 시계열 데이터이므로 무작위 분할을 사용하지 않는다.

데이터를 시간순으로 정렬한 후 과거 구간을 학습 데이터로 사용하고 이후 구간을 테스트 데이터로 사용한다.

최근 15분 rolling window를 5분 간격으로 생성하면 인접 행 간 데이터가 중복되므로 학습과 테스트 경계에는 일정한 purge 구간을 둘 수 있다.

예시는 다음과 같다.

  • 학습 구간 종료
  • 30분 이상의 제외 구간
  • 테스트 구간 시작

9.4 평가 지표

모델은 다음 지표를 평가한다.

  • Accuracy
  • 클래스별 Precision
  • 클래스별 Recall
  • 클래스별 F1-score
  • Confusion Matrix
  • 클래스별 support
  • 예측 신뢰도
  • 실제 라벨과 예측 라벨의 혼동 조합

전체 정확도만으로 성능을 판단하지 않고, 희소 클래스의 표본 수와 클래스별 재현율을 함께 확인한다.

9.5 규칙 복제 특성

초기 학습 라벨은 센서값 기반 규칙으로 생성되므로 높은 정확도가 나올 수 있다.

해당 성능은 실제 사용자 판단을 예측한 결과라기보다 정의된 환경 상태 규칙을 모델이 근사한 결과로 해석해야 한다.

모델의 초기 목적은 다음과 같다.

  • 센서 규칙을 배포 가능한 모델로 변환
  • 임계값 주변에서 확률 기반 판단 제공
  • 복합 센서 조건을 하나의 분류 결과로 통합
  • 향후 실제 운영 데이터 기반 개선 가능성 확보

10. 예측 신뢰도

모델은 분류 라벨과 함께 예측 확률을 반환한다.

출력 예시는 다음과 같다.

{ "location": "실습실", "predictedLabel": "CO2_RISING_FAST", "confidence": 0.94, "confidenceLevel": "HIGH" }

신뢰도 등급은 다음과 같이 정의할 수 있다.

  • 0.80 이상: HIGH
  • 0.60 이상 0.80 미만: MEDIUM
  • 0.60 미만: LOW

신뢰도가 낮은 경우 LLM 또는 제어 정책은 즉시 강한 제어를 수행하지 않고 추가 센서 데이터 또는 다음 추론 결과를 확인할 수 있다.

11. 실시간 추론 입력 검증

모델 실행 전 다음 사항을 검증해야 한다.

  • 필수 피처 존재 여부
  • 입력 데이터 타입
  • CO₂ 유효 범위
  • 온도 유효 범위
  • 습도 유효 범위
  • 현재 시간 및 요일 값
  • 최근 데이터 수신 여부
  • 5분 간격 연속성
  • 최근 15분 집계에 필요한 최소 표본 수
  • 30분 변화량 계산 가능 여부
  • 최근 1시간 누적값 계산 가능 여부

필수 데이터가 부족하거나 센서값이 유효 범위를 벗어난 경우 모델 결과를 생성하지 않고 데이터 부족 또는 센서 오류 상태를 반환한다.

출력 예시는 다음과 같다.

{ "location": "실습실", "status": "INSUFFICIENT_SENSOR_DATA", "missingFeatures": [ "co2_change_30m" ] }

12. 연속 추론 안정화

모델은 5분마다 실행되므로 동일한 상태가 연속으로 반환될 수 있다.

예시는 다음과 같다.

  • 09시 00분: TEMP_RISING
  • 09시 05분: TEMP_RISING
  • 09시 10분: TEMP_RISING

동일한 결과가 반복되더라도 매번 기기 제어 명령을 새로 수행해서는 안 된다.

후속 제어 정책에서는 다음을 고려한다.

  • 동일 지령 연속 발생 횟수
  • 직전 지령과 현재 지령 비교
  • 직전 제어 후 경과 시간
  • 최소 기기 유지시간
  • 제어 명령 cooldown
  • 반대 방향 제어 전환 제한

해당 안정화 로직은 모델 내부가 아니라 LLM 및 기기 제어 정책 계층에서 처리한다.

13. 모델 배포 형식

학습 완료 모델은 ONNX 형식으로 변환한다.

ONNX 모델에는 다음 항목을 포함한다.

  • 범주형 인코더
  • 수치형 결측값 처리
  • RandomForest 분류기

다음 작업은 ONNX 모델 외부에서 처리한다.

  • 원본 센서 데이터 조회
  • 센서 이상값 정제
  • 공간별 센서 통합
  • 최근 15분 집계
  • 5분 변화량 계산
  • 30분 변화량 계산
  • 최근 1시간 rolling 계산
  • 입력값 검증
  • LLM 호출
  • 최종 기기 제어

ONNX 모델 파일은 MinIO에 저장하고 추론 서비스가 필요한 모델을 내려받아 ONNX Runtime으로 실행한다.

14. 모델 아티팩트 관리

모델 배포 시 다음 파일을 함께 관리한다.

model.onnx metadata.json metrics.json

metadata.json에는 다음 내용을 포함한다.

  • 모델명
  • 모델 버전
  • 모델 생성 시각
  • 원본 데이터 주기
  • 분석 window
  • 추론 stride
  • 입력 피처 목록
  • 피처 자료형
  • 클래스 목록 및 순서
  • 라벨 정의 버전
  • 피처 스키마 버전

예시는 다음과 같다. { "modelName": "indoor-environment-directive-classifier", "modelVersion": "1.0.0", "sourceIntervalMinutes": 5, "windowMinutes": 15, "strideMinutes": 5, "featureSchemaVersion": "2.0", "labelDefinitionVersion": "3.0", "classLabels": [ "NO_ACTION", "CO2_RISING_FAST", "CO2_HIGH_STABLE", "CO2_RECOVERING", "TEMP_RISING", "TEMP_LOW_FALLING", "HUMIDITY_HIGH", "WARM_DRY_AIR" ] }

15. 모델 재학습 및 버전 관리

모델은 다음 조건에서 재학습할 수 있다.

  • 신규 실내 센서 데이터가 충분히 누적된 경우
  • 입력 피처 구성이 변경된 경우
  • 라벨 임계값이 변경된 경우
  • 센서 설치 위치나 센서 구성이 변경된 경우
  • 기존 모델 성능 저하가 확인된 경우
  • 5분 데이터 기반 라벨 분포가 크게 변화한 경우

기존 모델 파일을 덮어쓰지 않고 버전별로 저장한다.

예시는 다음과 같다.

indoor-directive/ ├─ v1.0.0/ │ ├─ model.onnx │ ├─ metadata.json │ └─ metrics.json └─ v1.1.0/ ├─ model.onnx ├─ metadata.json └─ metrics.json

새 모델은 기존 검증 데이터에 대한 성능과 ONNX 변환 결과를 확인한 후 활성화한다.

새 모델 로드 또는 검증에 실패하면 기존 모델을 계속 사용해야 한다.

16. 공간별 피드백과 모델의 관계

사용자의 온도·습도 만족도 피드백은 현재 환경 상태 분류 모델의 라벨과 목적이 다르다.

환경 상태 모델은 객관적인 실내 상태를 분류한다.

사용자 피드백은 특정 강의실 및 특정 이용 시간대에서 이용자들이 해당 환경을 얼마나 쾌적하게 느꼈는지를 나타낸다.

따라서 초기 구조에서는 사용자 피드백을 공통 환경 상태 모델에 직접 반영하지 않는다.

피드백은 다음 단위로 집계한다.

  • 공간
  • 이용 시간대
  • 피드백 항목
  • 당시 온도 또는 습도 구간

예시는 다음과 같다.

공간: A 강의실 시간대: 오후 온도 구간: 24.0~24.5℃ 평균 만족도: -1.2 표본 수: 35

해당 통계는 환경 상태 모델 결과와 함께 LLM에 전달한다.

향후 강의실별 피드백 데이터가 충분히 누적되면 환경 상태 모델과 별도로 강의실별 쾌적도 예측 모델을 구성할 수 있다.

환경 상태 분류 모델과 강의실별 쾌적도 모델은 역할을 분리한다.

17. 최종 처리 흐름

전체 처리 흐름은 다음과 같다.

5분 단위 실내 센서 데이터 수집 → 센서값 정제 및 유효성 검사 → 동일 공간의 센서값 통합 → 최근 15분 환경 피처 생성 → 5분 및 30분 변화 피처 생성 → ONNX 환경 상태 모델 추론 → 환경 지령 및 신뢰도 반환 → 공간별·시간대별 선호 통계 조회 → 날씨·미세먼지·기기 상태 조회 → LLM 최종 판단 → 안전 규칙 검증 → 기기 제어 또는 상태 유지

18. 모델 기능 범위

모델이 수행하는 기능

  • 실내 센서 데이터 기반 환경 상태 분류
  • 단기 및 중기 센서 변화 분석
  • 공간별 환경 상태 판단
  • 환경 지령 반환
  • 예측 확률 및 신뢰도 반환

모델이 수행하지 않는 기능

  • 에어컨 또는 환기장치 직접 제어
  • 외부 날씨 판단
  • 외부 미세먼지 판단
  • 사용자 재실 여부 확정
  • 출입 방향 판정
  • 사용자별 선호 판단
  • 공간별 쾌적도 통계 계산
  • 최종 기기 명령 생성
  • 안전 정책 우회

19. 기대 결과

본 모델을 통해 실내 센서값을 단순 조회하는 수준을 넘어 현재 공간에서 발생하는 CO₂ 상승, 고농도 지속, 공기질 회복, 온도 상승, 저온 하락, 고습 및 건조 상태를 주기적으로 분류할 수 있다.

또한 환경 상태 모델과 외부 상황 판단 및 기기 제어 기능을 분리하여 모델의 판단 근거를 명확히 유지하고, 향후 실제 강의실 피드백과 운영 데이터를 기반으로 모델 및 공간별 쾌적도 기능을 독립적으로 개선할 수 있다.