[기술 회고] 다중 모델 파이프라인과 규칙 기반 후속 추론

다중 모델 파이프라인과 규칙 기반 후속 추론

이 글은 현장실습에서 Segmentation·분류 모델과 규칙 기반 엔진을 묶어, 이미지 입력부터 결과 리포트까지 이어지는 파이프라인을 만든 과정을 정리한 기술 회고다. 탐지 대상의 구체적 의미나 도메인 고유 규칙은 공개하지 않고, 시스템 구성과 기술 선택만 남긴다.

프로젝트와 동작 원리

단일 Segmentation 모델만으로 끝내기보다, 역할을 나눈 여러 모델의 출력을 모은 뒤 규칙으로 해석하는 구조를 택했다. 이미지가 들어오면 영역 분할·관련 속성 인식 등을 수행하고, 그 결과를 지식/규칙 테이블과 매칭해 후속 결론을 점수화하는 방식이었다.

원리는 “딥러닝이 전부 판단한다”가 아니라, 딥러닝이 관측 가능한 특징을 뽑고, 도메인 규칙은 별도 엔진에서 다루는 쪽에 가깝다. 규칙 쪽 세부 내용과 점수표는 기밀에 해당할 수 있어 여기에는 적지 않는다. 대신 엔진이 fact를 받아 cause/score 형태로 순위를 매기는 구조였다는 정도만 남긴다.

서빙은 FastAPI로 구성했다. 이미지와 모델들을 로드해 분석한 뒤, 시각화 결과와 JSON 리포트를 반환하는 API 서버였다.

무엇이 문제였나

모델이 여러 개가 되면 학습 코드뿐 아니라 실행 순서, 입출력 스키마, 실패 시 동작이 필요하다. 한쪽 모델만 좋아져도 파이프 전체가 깨지면 데모·검증이 안 된다. 시계열 예측 쪽은 실측 시계열 데이터가 부족해, 학습·검증 설계 자체가 어려웠다. 그래서 가상 시계열·시뮬레이션 데이터 생성 스크립트로 파이프를 먼저 검증하는 우회도 필요했다.

저해상도·미세 영역은 인식이 어렵고, 외부 환경 정보가 없으면 후속 추론의 근거가 이미지 특징에만 의존하게 된다. 이런 한계는 문서에도 남겨 두었고, 파이프라인 완성도와 성능 상한을 구분해서 보는 편이 맞았다.

실제로 어떻게 구성·개선했나

역할이 다른 모델들

영역 유형을 보는 Segmentation/인식 모델, 구조·위치 관련 정보를 보는 모델, 세부 속성을 보는 멀티라벨 분류 모델, 재질 등 부가 속성을 보는 모델처럼 역할을 나눠 학습·테스트 스크립트를 분리했다. 이름은 내부 편의상 Model A/B/C/D처럼 구분해 두었고, 각각 train/test 진입점이 달랐다.

규칙 기반 추론 엔진

모델이 뽑은 fact를 입력으로 받아, 사전 정의된 규칙 테이블과 대조해 점수를 누적하고 상위 결론을 고르는 엔진을 구현했다. 필수 조건 일치에 기본 점수를 주고, 세부 속성 키워드가 추가로 맞으면 가점하는 식의 가중 합산이었다. 딥러닝 출력의 해석 레이어를 코드로 명시한 셈이다.

통합 실행 스크립트

여러 모델과 엔진을 한 번에 돌려 결과 이미지를 저장하는 통합 파이프라인 스크립트를 만들었다. 개별 test_*.py로 모델을 검증한 뒤, run_final_* 계열로 묶는 흐름이었다. 중간에 마스크 변환, 속성 라벨, 시각화가 끼어 있어서, 파일 단위 유틸이 많았다.

시계열·진행 예측 보조

실측 시계열이 부족한 구간에서는 진행 규칙을 가정한 시뮬레이션 데이터 생성, LSTM 기반 진행 예측 학습/테스트 코드를 준비했다. 정량 검증이 어려운 한계는 명확히 있었고, “파이프가 도는지”와 “현업 성능을 보장하는지”를 분리해서 봤다.

API로 묶기

최종적으로는 FastAPI 서버에서 이미지 입력 → 다중 모델 추론 → 엔진 → 시각화/JSON 응답으로 이어지게 했다. 노트북 실험과 데모 가능 상태의 차이가 여기에 있었다.

정리

파이프라인 회고의 핵심은 특정 도메인 결론이 아니라, Segmentation·속성 모델·규칙 엔진·FastAPI를 한 줄로 잇는 시스템 구성을 만들었다는 점이다. 데이터가 부족한 시계열 구간은 시뮬레이션으로 우회했고, 한계(저해상도, 외부정보 부재, 규칙 검증의 어려움)도 같이 적어 두었다. 모델 정확도 개선과 별개로, “결과를 서비스/리포트 형태로 내보내는 경로”를 연 경험이 남았다.

관련해 라벨링 도구와 Segmentation 실험 과정은 별도 회고로 분리해 두었다.