SKT AI Fellowship 5기에서 ‘APP 서비스 및 5G 성능 분석을 위한 영상/이미지 분석 기술 개발’ 과제를 수행 중인 12팀 슼나무입니다!

이번 포스트에서는 연구 계획 및 Task를 이번 게시물을 통해 소개해 드리도록 하겠습니다.

1. 연구 과제 소개

1.1 연구 배경

여러분, 새로운 앱을 출시하기 위해서 여러 개발자들이 많으면 몇 천 번, 심지어 그 이상까지도 Testing한다는 사실을 알고 계셨나요?

현재 SKT에서도 , 다양한 언어와 플랫폼으로 제작된 수많은 앱을 Live Service 중입니다.

그리고 사용자에게 더나은 앱 사용경험을 제공하자 기능개발(feature), 결함해결(bugfix) 등 지속적인 업데이트를 하고 있습니다.

맙소사, 매 업데이트마다 수동으로 테스트해야한다니..💀

Testing 자동화가 매우 필요한 상황이지요. 테스팅 자동화를 위해 개발환경(언어와 플랫폼)을 위한 수많은 Testing Tool이 존재합니다.

안정적인 품질로 앱이 배포될 수 있도록 다양한 자동화 Testing Tool 으로 여러 번의 테스팅을 거쳐 진행됩니다.

하지만 앱 서비스가 여러 언어로 개발이 되었다면요? 서로 다른 개발환경에서 개발된 기능을 테스트를 하려면 서로 다른 testing 환경을 구성하고 유지보수해야합니다.

AI를 도입하여 보다 다양한 영역에 자동화된 Testing을 도입하면, 시간을 절약하면서도 자동화에 따른 정밀도 향상을 기대할 수 있습니다.

더 나아가 빠르고 정확한 Testing은 즉각적인 결함 탐지와 해결 방안 모색 등에도 도움을 주므로, 전체적인 개발 Process에서의 효율성까지 개선합니다.

위와 같은 발전을 위해 더 이상 앱의 언어와 플랫폼에 의존하지 않고 많은 개발자들이 보다 편하면서도 정밀하게 Testing하는 환경을 구축하는 것이 목표입니다.

1.2 Detection 모델 관련 연구

1.2.1 Object Detection 이란

앱 특정 화면에서 원하는 요소(element)가 존재하는지 식별하고, 존재한다면 어떤 위치에 놓여있는지 확인하기 위해 Object Detection Model 을 사용할 예정입니다.

우선 Object Detection이 무엇인지와 배경을 설명드리겠습니다.

• 이미지 분류(Classification): 해당 이미지에 존재하는 객체(class)가 무엇인지 판단하는 과정입니다.

• 위치 탐색(Localization): 그 객체가 이미지 상에서 어디에 존재하는지 추론하는 과정입니다.

• 객체 검출(Object Detection): [이미지 분류 + 위치 탐색] 2가지를 종합한 Task입니다.

  이미지 내에서 유의미한 여러 객체를 분류(classification)할 뿐만 아니라, 해당 물체가 존재할 만한 위치까지 추론(localization)하는 종합적 과정을 뜻합니다.

Obejct Detection Model을 만드는 과정, 즉 이미지를 제공하면 Classification과 Localization을 하는 인공지능을 만드는 과정은 매우 다양합니다.

그 중에서 다양한 앱이 빈번하게 업데이트될 때에도 문제 없이 Testing하는 모델을 만들기 위해 Few-shot & Zero-shot Learning으로 학습할 계획입니다.

1.2.2 Few-shot & Zero-shot Learning 이란

Few-shot 과 Zero-shot은 적은 양의 데이터(Few-shot)로, 더 나아가 학습 데이터가 없을 때에도(Zero-shot) 의미 있는 성능의 모델을 만드는 학습(Learning) 패러다임입니다.

앱은 빈번하게 업데이트되며, 그때마다 변경 사항을 테스트해야 합니다.

그러므로 Small Data만으로 추가 / 변경 사항을 기존 모델에 빠르게 학습시켜 변경에 대응할 수 있도록

Few-shot & Zero-shot Learning을 기반으로 Object Detection Model을 설계할 예정입니다.

Dataset 구조는 다음과 같습니다.

• Training Set : 모델은 Training Set으로 구분하는 방법(classification)만을 배우게 됩니다.

  학습된 여러 이미지로 “이 두 이미지의 대상은 같지 않아”, 혹은 “이 두 이미지의 대상은 동일한 것이야”라는 사실만을 파악하는 능력을 가지게 되는 것이지요.

• Support Set : 모델을 통해 실제로 구분해야 하는 객체들의 집합입니다. Support Set이 제공되지 않는 방식이 Zero-shot입니다.

• Query Sample : 새로운 클래스에 대한 평가 데이터입니다. 즉, 분류하고자 하는 이미지입니다.

출처: lectures on few-shot learning, Shusen Wang

구체적인 학습 과정은 다음과 같습니다.

Learning(training set 이용) → Adaptation 학습 (Support Set 이용)→ Test-set 평가(Query Sample 이용)

정리하자면 Training set을 통해 서로 다른 것을 다르다고 인식하는 능력을 키운 모델이

Image Query Sample이 무엇인지 구분하라는 요청을 받았을 때 Sample이 Support Set 중 무엇인지 구분하여 알려주는 모델을 만드는 학습 과정입니다.

1.2.3 Few-shot & Zero-shot Object Detection / Counting Model 이란

Few-shot & Zero-shot Object Detection Model은 Few-shot & Zero-shot Learning 방식으로 학습하여 Classification과 Localization을 수행할 수 있는 모델입니다.

그 중에서도 Object Counting Model은 검출하려는 객체가 단 한 개만 주어지는,

특이 Case에 사용되는 모델로 단순하게 background와 클래스를 구분하여 목표 객체가 사진에 몇 번 등장하는지 등을 확인하는 방식입니다.

출처 : Dual-Awareness Attention for Few-Shot Object Detection, IEEE 2021

1.3 연구 목표

Object Counting은 Object Detection보다 변화량이 적은 객체 판단에서 강점을 갖습니다.

그리고 대부분의 앱 Testing과정에서는 Query Sample에 터치하거나 확인해야 할 Target 객체가 하나며, 앱 구동 영상은 real world와 다르게 static합니다.

따라서 종합적으로 고려한 결과 Few-shot & Zero-shot Learning 방식으로 학습한, Object Counting Model을 구현할 예정입니다.

Challenge 01: 학습 데이터(Referecnce)의 부족

Few-shot & Zero-shot Object Counting Task에서는 모델이 이전에 한 번도 본 적 없는,

Novel Class에 대한 몇장의 사진만(Support Set)을 가지고 추론 단계에서 바로 Novel Class의 존재와 위치에 대한 예측을 해야합니다.

Zero-shot의 경우에는 support set 없이 Novel Class에 대한 예측을 진행합니다.

Few-shot & Zero-shot Object Counting 한계

• 학습 데이터의 절대량 부족으로, 학습을 통해 Target Class를 일반화하는 과정에서 오류가 발생할 수 있습니다.

• Base Class로만 학습된 모델로 Novel Class를 예측할 경우, 각 객체의 Feature 이전에 어려움이 됩니다.

Challenge 02: Scale Variation

모델은 다양한 크기의 객체에 대한 정보가 없기 때문에 찾으려는 객체의 Scale을 결정짓기가 쉽지 않고,

따라서 추론하려는 객체의 크기에 다양한 후보군이 존재하게 되어(Scale Variation) 오브젝트 Classification 정확도에도 큰 악영향을 미치게 됩니다.

예를 들어, 아래와 같이 Support Set에서 제공한 Image와 Scale이 크게 차이나는 Query Sample이 들어오면 객체를 Query Sample에서 추론하기가 어려워집니다.

해결 & 완화 전략 - App의 특성을 고려하여

앱 화면과 Real-world 이미지들 간에는 큰 차이점이 있습니다. 앞서 말씀드린 것처럼 Real-world 이미지는 객체의 Scale과 포즈, 상황, 배경 등이 무한한 경우의 수로 이루어집니다.

반면 앱 화면은 객체들이 보다 정적이고, Scale의 범위 역시 한정되어 있으며, 상황 및 배경이 제한적이라는 조건을 가지고 있습니다.

이러한 조건들이 모두 앱 환경에서의 Few-shot & Zero-shot Object Counting의 구현 가능성을 높이는데, 저희는 특히 객체의 Scale의 범위가 한정되어 있다는 조건에 집중하였습니다.

Few shot object Counting을 진행함에 있어, 원하는 Scale의 범위가 아닌 부분들은 Masking 할 수 있기 때문입니다.

Task의 큰 문제였던 Scale 후보 군의 다양성(scale variation)를 이렇게 Scale-Aware한 방법으로 완화할 수 있다고 판단하였습니다.

이를 구현하기 위해, Target Image와 함께 scale에 관한 정보도 받아, 판단 과정에서 masking을 하도록 설계할 예정입니다.

자세한 내용은 바로 이어지는 Pipeline 설계 계획을 참고해주세요!

2. 연구 수행 계획

2.1 모델 생성 관련 연구

연구 01. OpenCV의 객체 탐지 기술을 활용하여 Testing의 가능성 판단

• Model 생성 이전에 OpenCV의 Target Detection 을 활용하여 객체 탐지를 기반으로 한 테스팅이 가능한지 확인하며 파이프라인을 확정하겠습니다.

• 해당 과정에서 발생한 문제를 해결하고 최적화하며 Few-shot & Zero-Shot Object Counting Model의 기능과 성능 방향을 결정하겠습니다.

연구 02. Few-shot & Zero-Shot Object Counting Model 기초 설계

출처: Baseline Model (based on Class-agnostic Few-shot Object Counting, WACV 2021)

• 모델의 output layer 중 객체의 출현 빈도를 탐지하는 Counting 모듈을 제외하고, 확률 분포만을 이용하여 모델을 이용하는 방식으로 Task를 잡았습니다.

• 또한 ResBlock을 Vit Block으로 교체하거나, CoAtNet을 이용해 모델 구조를 수정하는 등으로 Model Capacity를 키우는 방식,

  혹은 여러가지 기법을 연구하여 저희만의 Novel한 모델 구조 및 방법도 실험을 통해 찾을 예정입니다.

[Resnet에서 최초로 소개된 Residual Block 구조]

연구 03. 최적의 Hyper-Parameter 및 최적의 모델 구조 결정

• 다양한 실험을 통해 Learning Process를 줄인다는 Few-shot & Zero-shot의 이점을 극대화 하는 방향, 또한 정확도를 향상하는 방향을 고민하겠습니다.

• Testing에 최적화된 고속 & 고성능 모델을 설계 및 구축하여, 2.1.2 과정에서 사용했던 Baseline 모델을 독자적 모델로 교체하는 것을 최종 목표로 삼았습니다.

2.2 Pipeline 설계

WatchMAN+는 SKT&SK ICT App 서비스를 테스팅하고 모니터링에 사용하고 있는 자동화 Testing Tool입니다.

이번 프로젝트 목표는 WatchMAN+에서 Mobile OS, App 개발플랫폼에 독립적으로 testing 할 수 있도록 연구개발한 Model을 API로 제공하여 단말영상 기반으로 testing 자동화 프로세스 효율화에 기여하는 것입니다.

WatchMAN+을 고려하여 모델에 필요한 정보를 주고 받는 Pipeline을 고려하였습니다.

• Input은 앱의 작동 영상을 나타내는 Video Stream , 그리고 터치해야 할 버튼 정보 등을 나타내는 Target Image 입니다.

  Video Stream이 Support Set, Target Image가 Query Sample의 역할을 수행합니다. Target Image에는 Image file뿐만 아니라 Target이 되는 Class의 Scale 정보도 포함됩니다.

• Model은 Few-shot & Zero-shot Object Counting Model입니다. Support Set에 Query Sample이 존재하는지,

  존재한다면 Class가 무엇인지(Classification)와 어디에 놓여있는지(Localization)를 판단하는 역할입니다.

• Model은 Classification과 모델 추론 좌표 결과를 WatchMAN+에 Return합니다.

  WathMAN+는 Return value를 사용해 해당 위치에 터치 명령을 내리거나, Interaction이 정확히 반영되었는지 검증하는 등의 작업을 수행합니다.

2.3 연구 일정

🔥 🚴🏻 중간 결과물 목표: WatchMAN+와 API로 정확히 통신할 수 있는 Agent Server & ifland 기준 원활한 Testing이 가능한 Model 완성

🔥 🚴🏻‍♀️ 최종 결과물 목표: Server Resource를 최소화하는, 상용화 가능한 최적화 모델로 개선 & 앱 테스팅에 최적화된, 독자적 모델 구조 설계 Task 최적화

레이블링을 최대한 지양하나, Model Test를 위한 최소한의 레이블링이 필요하기도 하고, 처음 모델 형성 당시에 진행될 Few-shot Training에도 어느정도는 labeled data가 필요하여,

데이터셋 준비(unlabeled dataset 구축 포함) 및 업그레이드 기간을 상당히 오래 잡았습니다. 대신 구축과 테스트를 병행하며 데이터를 바로 반영하는 구조로 계획하였습니다.

과제 요약

🔥  WatchMAN+ 내에서 Assets 들의 실시간 Few-shot & Zero-shot Object Couning

• 연구 배경 : 앱의 언어와 플랫폼 등 환경에 따라 자동화 Testing이 불가능한 상황이 있음.

• 연구 목표 : WatchMAN+ 에서 유니티 기반 앱의 요소와 객체에 대한 Few-shot Object Counting Model을 이용해 좌표 자동 추출 및 테스팅 자동화.

• 핵심 도전 과제 : 학습 데이터 부족에서 기인한 Few-shot & Zero-shot의 문제를 완화하여, 속도와 정확도를 모두 요구하는 Testing 환경 최적화 모델 구현.

3. SKT AI Fellowship 팀 소개

(1) 슼나무 팀 소개

저희 슼나무 팀은 성균관대학교 학부생 차승일, 정현철, 박민서로 구성된 팀입니다.

훌륭하신 멘토님들과 잘 협업하여 SKT의 Testing Automation 프로세스 업그레이드에 기여할 수 있도록 노력하고 또 노력하겠습니다.

호용환 , 권정일, 이연주 멘토님에게 부끄럽지 않은 펠로우가 되기 위해 좋은 결과물을 꼭 내겠습니다! 잘 지켜봐 주세요!

(2) Ground Rule

• 펠로우 정기 회의는 매주 일요일 오후 8시에 열릴 예정 입니다.

• 매주 종합 보고서를 통해 멘토들께 진행사항을 보고드리고 피드백을 받을 예정 입니다.

• 온라인 회의는 수시로, 오프라인 회의는 메이저 이슈가 있을 때 진행할 예정 입니다.

• 중간 발표 전까지는 뛰어난 성능의 모델을 WatchMAN+에 이식하는 것이 목표입니다.

(3) 팀 채널

저희의 메인 logging 수단은 github organization wiki입니다.

https://github.com/skt-fellowship-team12/SKT_AI_fellowship_team12/wiki

• 상세한 실험 통계, wiki에 기록하기 힘든 방대한 자료들은 저희 노션에 기록할 예정입니다.

  https://www.notion.so/eb69a54ad1864e1aaa3d5c8fb0675d1f

• 디스코드에는 어느정도 완성도가 있거나, 공유하고 싶은 것들을 공유할 예정이고, 멘토분들과 소통 또한 디스코드로 활발히 진행할 예정입니다!