안녕하세요 자율주행 인지개발팀 조재훈 책임연구원입니다. 이전 포스팅에 (https://developers.hyundaimotorgroup.com/blog/411) 이어서 오늘은 Knowledge distillation를 활용하여 3d object detection 객체 검출 네트워크를 경량화한 방법론 및 실험 결과를 공유드리도록 하겠습니다.제안방법overall framework제안 방식은 2-Step Knowledge Distillation 으로 진행이 되며, end-to-end 방식으로 학습을 수행합니다.각 step별 방법론은 다음과 같습니다.Step 1. Backbone Feature Distillation교사와 학생 백본 네트워크로부터 추출한 2차원 Spatial Feature map을 Width, Height 각 축으로 Projection시켜서 1 x Width, 1 x Height형태로 만들고 softmax을 취하여 2가지 분포로 만듭니다. 이때 교사와 학생의 각각 2가지 분포를 분포의 차이를 나타내는 손실 함수인 Kullback Leibler Divergence를 활용하여 교사의 분포를 닮도록 모방 학습 시킵니다.Teacher의 backbone에서 Spatial Feature map을 추출함추출한 Feature map을 x축으로 y축으로 value를 모두 더해서 1 x height, 1 x width 벡터 형태로 만듦Student Backbone에서 2. 를 수행하여 동일한 형태로 1 x height , 1 x width의 벡터 형태로 만듦모든 값의 합을 1로 만드는 softmax 함수를 활용하여 분포로 만들고, Kullback-Leibler 손실 함수를 통해서 height, width의 2개의 분포를 닮도록 함Step 2. Center Feature DistillationNetwork의 Head에는 객체의 중심 위치, 깊이, 바운딩 박스 등 다양한 결과를 추론합니다. 이때, 각 클래스에 객체의 중심을 나타내는 Heat map 결과를 Backbone Feature Distillation과 같은 형태로 Width, Height 축으로 projection 시켜 2가지 분포를 얻고 Kullback-Leibler Divergence 손실 함수를 통해서 교사 네트워크의 분포를 유사하게 추론할 수 있도록 모방 학습을 수행합니다.Teacher의 각 Class 별 CenterPoint를 나타내는 Heatmap을 추출함추출한 Heatmap을 x축으로 y축으로 value를 모두 더해서 1 x height, 1 x width 벡터 형태로 만듦Student Head에서 Heatmap을 추출하고 2. 를 수행하여 동일한 형태로 1 x height , 1 x width의 벡터 형태로 만듦아래의 그림은 head distillation을 시각화한 그림입니다.Center feature distillation실험결과2021 CVPR에 게재된 Delving into Localization Errors for Monocular 3D Object Detection (monodle)논문을 baseline으로 선정하였으며, Experimental Setting은 다음과 같습니다.Teacher Backbone: DLA34Student Backbone: ResNet50Train, Validation Dataset: KITTI정량평가정량결과위의 table은 실험수행 결과에 대한 정량 평가를 보여줍니다. Backbone distillation을 통해 backbone 부분에서 파라미터가 줄어드는 것을 확인할 수 있었습니다. 연산량 및 latency 에서도 효과적으로 경량화 되는 것을 확인할 수 있었습니다.다만 위의 실험결과에서 한가지 의문이 들 수 있습니다. Backbone 측면에서 DLA34와 ResNet50이 크게 차이가 나지 않아 보이는데 어떻게 latency 측면에서 차이가 28%의 효과를 볼 수 있었을까요? 질문에 대한 답은 이전에 작성한 포스팅에서 정답을 유추해 볼 수 있습니다 (https://developers.hyundaimotorgroup.com/blog/291). 참고 부탁드려요.정량결과위의 실험 결과는 실험에 대한 정량평가를 보여줍니다. Teacher network는 기존 논문의 결과이며, 우측의 table은 student에 대한 결과 입니다. 네트워크가 경량화 됨에 따라 2~9% 정도의 성능 저하를 가져옵니다. 하지만, self-distillation 기법 혹은 teacher network와 student network를 함께 학습함으로써 유용한 정보들을 효과적으로 학습할 수 있는 distillation 기법들을 활용하면 성능 저하에 대한 issue를 완화할 수 있으며, 저희 그룹에서는 self-distillation을 통해 teacher network를 뛰어넘는 성능을 얻을 수 있었습니다. self-distillation에 대해서는 추후 포스팅을 통해 전달드리도록 하겠습니다.정성평가정성결과위의 결과는 head distillation의 장점을 보여주는데요, 제안 방식을 통해 다중 박스로 오인식 하는 문제를 해결할 수 있었습니다.정성평가Head 부분의 feature map을 시각화 한 결과 입니다. 기존 baseline 모델에서 car class에 해당하는 heatmap feature map을 시각화 하였을 때, 하나의 차량에서 하나의 하나의 점이 (최댓값) 관찰되어야 하지만 다중으로 activation 되는 것을 확인할 수 있었습니다. 이는 다중 box를 생성하게 되어 정확도와 인식 측면에서 큰 손실을 가져옵니다.  반면, 제안 방식은 center point를 효과적으로 잡아내는 것을 feature map과 정량/정성 결과를 통해 확인할 수 있었습니다. 이로써 제안 방식의 head distillation이 효과적임을 정성적으로 확인할 수 있었습니다.마무리오늘은 3d object detection 알고리즘에 새롭게 개발한 Knowledge distillation 기법을 적용해본 경험에 대해 공유해 보았습니다. 궁금하시거나 말씀해주실 사항 있으시면 언제든 의견주세요!

아자르는 전세계 230개 이상의 국가에서 Social Discovery 서비스를 제공하고 있습니다. 사용자들은 관계를 형성하기 위해 사진, 동영상, 음성 등 자신의 미디어를 서비스에 등록할 수 있습니다. 이러한 미디어 전송 행위는 전세계에 위치한 사용자들로부터 수행되며 이를 안정적으로 제공하기 위해 Media Management System을 개발하게 되었습니다. 본 게시물을 통해 해당 사례에 대해 소개하고자 합니다. 배경 아자르 서비스의 기존 미디어 업로드 방식은 Client가 직접 AWS S3 저장소에 직접 업로드를 수행하는 방식으로 이루어져 있었습니다. 따라서, 직접 Client 단말기에서 최종 저장소로 업로드를 수행하기 때문에 현황 파악이 어려운 문제가 있었습니다. 나아가, 각 나라 및 지역의 ISP (Internet Service Provider)에서 네트워크 이슈가 발생할 경우, 해당 지역 인근에 위치한 사용자들은 업로드가 불가능한 상황이 발생합니다. 업로드 요청은 Client에서 AWS S3로 직접 전달되기에, 네트워크에 문제가 생긴 것인지 인지하는 것 조차도 어렵습니다. 인지할 수 없는 문제는 풀 수 없는 문제와 같습니다. 따라서, 각 Client에서 최종 저장소에 직접 파일 업로드를 수행하지 않고 서버를 통해 업로드를 수행하도록 개선하게 되었습니다. 목표 전세계에 위치한 사용자에게 Media Management System 제공 주요 기능 * Media Upload 기능 * Media Delete 기능 * Media Download 기능 * Media History 관리 기능 부가 기능 * Media History CDC 기능 * JWT 인증 기능 * JsonPath를 이용한 유연한 Property 추출 기능 * ISP Network Issue 대응 기능 방식 Edge Server와 Backbone Network를 활용하여 트래픽 전송을 가속화 합니다. 이를 통해 전세계 각 지역에 위치한 사용자는 Media Management System과의 데이터 전송을 고속으로 수행 할 수 있습니다. 구현 많은 사용자들이 동시에 대용량 업로드 요청을 수행하더라도 빠르고 안정적으로 처리할 수 있어야 합니다. 따라서, 전송할 Media의 전체 Byte를 Heap Memory에 모두 Load 하지 않고 작은 Chunk 단위로 쪼개 비동기 스트리밍 방식으로 업로드를 수행하도록 구현하였습니다. Server Application은 Spring Framework를 기반으로 하며 비동기 스트리밍 업로드를 위해 Webflux, Kotlin Coroutine를 활용합니다. Media Storage는 AWS S3를 사용하며, Media History Storage는 Distributed Database인 ScyllaDB를 사용합니다. SERVLET UPLOAD (MEMORY) - 1.6GB VIDEO UPLOAD Servlet Upload에서 File에 Flush하지 않고 Memory에 Load하여 사용하는 방식입니다. 비효율적인 File I/O는 발생

SKT AI Fellowship 과제로 진행하고 있는 Smart Factory 서비스를 위한 진동/압력/온도 센서의 Anomaly Detection 개발에 대한 연구 과제를 소개 하고자 합니다. 10월말까지 진행하는 저희 연구 과제에 많은 관심 부탁드립니다.① 연구 과제 소개■ 연구 배경 및 목적Smart Factory(Data기반 지능형 공장) 의 핵심 Task는 예지 정비(Predictive Maintenance) 솔루션/서비스입니다.여기서 예지 정비 란 이상치를 탐지하여 설비의 고장 (Failure) 이전에 정비를 하는 것입니다.공장 내에서 설비의 고장으로 인해 설비가 멈추게 되면 Machine downtime이 발생 하고,이는 기업에게 막대한 손해로 이어지기 때문에 이를 방지하는 것이 업계에서 중요한 issue 입니다.따라서 많은 기업들이 공장 내 설비 Data를 기반으로 통계 분석, AI 분석을 통해 예지 정비 를 시행하고 있으며,이러한 분석을 이상치 탐지(Anomaly Detection) 라고 합니다.스마트 공장 솔루션 SKT Grandview 서비스따라서, 본 연구는 SKT GrandView 서비스에 탑재할 수 있는 이상 치 탐지 모델의 개발 을 주목적으로 합니다.■ 연구 내용- 그렇다면 SKT GrandView 서비스에 개발된 모델을 탑재하려면 어떤 과정을 거쳐야 할까요?우선, 데이터는 진동 센서를 통해 측정 된 공신력 있는 데이터 셋 이어야 합니다.이에 많은 논문들이 사용하고 있는 NASA & CWRU Bearing Dataset 을 통해서 우선적으로 검증 을 진행하고 있습니다.- 진동 센서로 측정 된 데이터(Raw data)를 모델의 Input data로 활용 할 수 있을까요?Raw data(웨이브 형태의 데이터)를 그대로 사용하면 주파수 형태로의 분석이 어렵고, False alarm의 발생 가능성이 높습니다.따라서 Raw data를 Wavelet과 같은 주파수 변환 방법 을 통해서 Input 데이 터의 품질을 향상을 하는 것이 중요합니다.- NASA , CRWU Bearing Dataset은 시뮬레이션 환경 하에 측정 된 데이터 아닌가요?위의 데이터는 실제 수집 환경에 서 발생할 수 있는 noise & NaN 을 고려하지 않습니다 .따라서 실제 수집 환경에서 발생할 수 있는 noise & NaN을 임의로 추가 하고,이를 포락선 분석(envelope analysis), Imputation 방법 을 통해 이상 상황과 구분 할 것입니다.- 개발한 모델을 추가적인 데이터 셋으로 추가 검증한다고 들었습니다.저희는 SKT Grandview에 모델을 탑재할 것이기 때문에 성능 검증을 위한 추가적인 Dataset을 고려할 것입니다.Noise와 NaN이 포함되어 있는 산업 현장의 실제 센서 데이터를 통해 최종 점검 을 진행할 예정입니다.- 그렇다면 이상 탐지 모델은 어떤 것을 사용하시나요?저희가 모델링 부분에서 최우선적으로 고려한 것은 비지도 학습 모 델 이었습니다.실제 환경에서 수집된 데이터는 당연하게도 Label이 존재하지 않기

TOAST UI Grid는 현재 새로운 메이저 업데이트인 버전 4를 릴리스하기 위해 열심히 준비중이다. 버전 4는 Backbone과 jQuery를 사용해서 작성했던 기존의 코드를 모두 버리고 처음부터 새로 작성하는 대대적인 개편 작업이다. 이번 업데이트를 통해 불필요한 의존성을 줄이면서, 훨씬 더 가볍고 빠른 그리드가 되기를 기대하고 있다. 버전 4는 Backbone과 jQuery 대신, 직접 작성한 반응형 상태 관리자와 Preact를 기반으로 만들어졌다. 버전 4의 첫 번째 알파 배포를 기념하며, 이 글에서는 Backbone과 같은 이벤트 기반의 상태 관리 방식과 Vue, MobX와 같은 반응형 방식이 어떻게 다른지, 왜 반응형 상태 관리자를 직접 만들었는지, 그리고 반응형 시스템을 구현하기 위해 어떤 점들을 고려해야 하는지 등을 실제 소스 코드를 보며 자세히 설명하고자 한다. 반응형(reactivity) 시스템이란? 반응형이라는 단어는 많은 곳에서 범용적으로 사용되기 때문에, 먼저 용어를 명확하게 정의할 필요가 있을 것 같다. 이 글에서 말하는 반응형 시스템이란 Vue나 MobX에서 사용되는 방식을 말하며, 객체의 상태 변경을 자동으로 감지해서 그 객체를 사용하는 다른 객체의 상태를 변경해주거나, 관련된 뷰(View)를 자동으로 갱신해주는 시스템을 말한다. 즉, 기존의 이벤트 기반 방식에서 모든 상태 변경에 대해 이벤트를 발생시키고, 변경을 감지하기 위해서 해당 이벤트에 대한 리스너를 등록하던 일을 자동으로 해 주는 것이다. 사실 이런 방식은 Backbone 이후에 나온 대부분의 프레임워크에서 지원하는 방식이며, AngularJS가 처음 주목받을 때에는 데이터 바인딩이란 용어가 더 흔하게 사용되었다. 하지만 최근 Vue에서 반응형 (reactivity)라는 단어를 공식적으로 사용하면서 이제 Vue를 대표하는 특징적인 용어가 되었으며, 그로 인해 Vue에서 사용하는 특정 구현 방식과 연관되어 사용되는 경우도 많다. Vue에서는 반응형을 구현하기 위해 getter/setter를 사용해서 프록시를 걸어주는 방식을 사용하며, 현재 개발중인 Vue 3에서는 ES2015의 Proxy를 직접 사용해서 구현될 예정이다. MobX는 Vue의 반응형 시스템과 거의 유사한 방식을 사용하며, 버전 4 이전까지는 getter/setter를, 버전 5부터는 Proxy를 사용해서 구현되어 있기 때문에 브라우저 지원 범위에 따라 적당한 버전을 선택해서 사용할 수 있다. 다만 MobX는 상태 관리만을 위한 라이브러리이므로, UI를 표현하기 위해서는 리액트와 같은 별도의 프레임워크를 같이 사용해야만 한다. 이벤트 방식 vs 반응형 방식 이제 간단한 예제를 살펴보면서 반응형 방식이 기존 이벤트 기반 방식에 비해 어떤 장점을 갖는지를 살펴보겠다. 이벤트 방식은 Backbone의 Model을, 반응형 방식은 MobX의 observable을 사용할 예정이며, 개념을 설명할 용도이므로 API에 익숙하지 않더라도 소스 코드를 읽는데 전혀 문제가 없을 것이다. 게임 플레이어 A