Google Developers Korea Blog: November 2019

TensorFlow Lite를 사용해서 몸동작 인식한 중국 국민체조 앱의 케이스를 소개합니다

Friday, November 29, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 송호연(MachineLearning GDE)님이 참여해 주셨습니다>
게스트 게시자: Keith Chan, Vincent Zhang(OliveX Engineering 팀 소속) 팔단금이란? 8가지 순서로 나뉘어진 단련 법을 의미하는 것으로서 중국에서 공식 공인된 운동법으로 현대 스트레칭의 효시로 불립니다.
소개 OliveX는 홍콩에 본사를 두고서 피트니스 관련 소프트웨어에 주력하는 회사로, 2018년 회사 창립 이래로 200만 명 이상의 사용자에게 서비스를 제공하고 있습니다. 사용자 대부분은 노년층이며, Baduanjin 앱은 사용자의 부상 가능성을 최소화하면서도 팔단금(Baduanjin)을 수련하도록 도와줍니다. 이런 목적을 달성하기 위해, 우리는 스마트폰 앱에 최신 인공지능 기술을 활용하여 팔단금 수련 동작을 자동으로 탐지하여 사용자에게 알맞은 피드백을 제공합니다. 목표와 요구사항 팔단금은 8가지 종류의 팔다리 동작과 호흡 조절법으로 이루어진 대중적인 운동입니다. 정신과 육체의 건강을 모두 개선해주는 팔단금 수련을 위해서는 정확한 동작과 호흡 조절이 매우 중요합니다.
몸동작을 취하는 애니메이션 인물

몸동작을 취하는 애니메이션 인물

사용자는 'Smart Baduanjin' 앱을 통해 자신의 동작을 추적하는 AI를 사용하여 수련 동작을 올바로 취하고 있는지 확인할 수 있습니다. 우리는 최신 머신러닝 기술을 활용하여 사용자가 단순히 운동 동영상을 보고 따라서 운동하는 기존의 학습 방식을 사용자가 자신의 몸동작에 관한 피드백을 실시간으로 받으면서 보다 즐겁게 운동할 수 있는 대화식 환경으로 바꾸기를 바랍니다. 또한 이런 기능으로 노년층 유저들이 팔단금을 더 효과적으로 수련하고 부상 위험도 줄이는 데 도움이 될 수 있기를 희망합니다. ‘Smart Baduanjin’ 앱의 스틸 컷

‘Smart Baduanjin’ 앱의 스틸 컷

우리는 목표를 분석하고 우선순위를 정한 후 다음과 같이 전반적인 제품 요구사항을 정의했습니다.

보통 실외에서 팔단금을 수련하면서 쓰는 용도이므로, 제품을 '모바일' 기반으로 만들 필요가 있음

팔단금을 수련할 때, 사용자는 보통 시연 동영상을 따라 동작을 취하면서 화면에 등장하는 코치의 동작을 모방하므로, 동영상을 소리와 함께 재생할 수 있는 제품이어야 함

사용자에게 귀중한 실시간 피드백을 제공하려면 전면 카메라로 사용자의 몸동작을 포착해야 함

특히 몸동작 인식에 관해, 우리는 알고리즘이 다음 작업을 수행하기를 바랍니다.

전체 수련 동작 순서에서 각각의 팔단금 동작 인식

사용자가 취하는 몸동작의 정확성을 기준으로 점수 부여

만족스럽지 못한 동작에 대한 교정 지도 기능 제공

기술 분석 ML 프레임워크 선택 위 요구사항을 바탕으로, 우리는 프로젝트 구현을 위해 적합한 딥 러닝 프레임워크를 선택해야 했습니다. 특히, 우리는 다음과 같은 특징을 가진 프레임워크를 찾고 있었습니다.

휴대기기를 위한 강력한 지원을 제공하고 중급부터 저급 스마트폰에서도 원활히 실행 가능함

친화적 API 디자인과 풍부한 디버깅 도구

성숙한 커뮤니티 지원과 리소스 사용 가능

우리는 종합적인 조사와 평가를 거친 후 TensorFlow Lite가 우리의 요구사항에 부합한다는 점을 깨달았습니다. 그 밖에도, Google은 인체의 다양한 포즈를 탐지하도록 특별히 디자인한 앱인 PoseNet을 오픈소스로 공개하고 TensorFlow.js를 기반으로 하는 데모 코드를 제공했습니다(편집자 주: 우리는 최근에 TensorFlow Lite를 기반으로 하는 PoseNet 샘플을 발표했음). Google은 우리가 오픈소스 코드의 도움을 받아 인체 포즈 인식을 위한 초기 작업을 완료하는 데 도움을 주었을 뿐 아니라, 우리의 동작 인식 알고리즘이 자바스크립트에서 훌륭한 성능을 발휘하므로 휴대기기에서 원활하게 작동할 수 있으리라는 확신도 주었습니다. 알고리즘 몸동작 인식 우리는 개발 초기 단계에서 기존의 몸동작 인식 알고리즘을 조사했습니다. 현재, 주류 알고리즘은 주로 순차적 동영상 프레임 분석을 기반으로 합니다. 이런 알고리즘이 우리의 요구사항을 충족할 수는 있겠지만, 네트워크가 상당히 복잡하고 이런 네트워크에서 추론을 실행하면 많은 계산 리소스가 소비됩니다. 하지만 휴대기기에서 모델을 실행해야 한다는 까다로운 요구사항이 있었으므로, 정확성과 성능 사이에서 절충점을 찾아야 했습니다.
우리가 택한 접근 방식은 PoseNet을 통해 주요 인체 관절을 먼저 포착한 다음, 인체 관절이 움직이는 순서를 기반으로 특정한 동작을 인식하는 것이었습니다. PoseNet은 17개의 인체 관절만 추적하므로, 전체 크기 이미지에 비해 계산량이 대폭 줄었습니다. 아래에서 알고리즘의 워크플로를 보여드리겠습니다. 우리는 먼저 PoseNet을 사용하여 입력 동영상에서 인체 관절 데이터를 추출한 다음, 인체 관절 데이터를 기반으로 동작을 분류했습니다. PoseNet을 사용하여 인체 관절을 포착하는 방법

PoseNet을 사용하여 인체 관절을 포착하는 방법

주요 동작 기술적 접근 방식을 결정한 후에는 앱을 위해 인식할 주요 몸동작을 정의할 필요가 있었습니다. 우리는 이를 위해 몸동작 인식 문제를 전형적인 머신러닝 분류 문제로 변환했습니다. 아래는 주요 팔단금 동작을 정의한 방법의 샘플입니다. 주요 팔단금 동작 차트

주요 팔단금 동작 차트

우리는 일반적인 심층신경망을 훈련하여 사용자의 몸동작을 분류했습니다. 하이퍼 매개변수 조정과 훈련 데이터 최적화/확대를 여러 차례 반복한 후에 얻은 최종 모델은 아래 그림과 같이 훌륭한 정확도를 보여 제품 요구사항을 충족할 수 있었습니다. 정확도 및 동작 그래프

정확도 및 동작 그래프

휴대기기에서 해결해야 할 난제 딥 러닝 모델을 완성한 후, 우리가 다음으로 밟은 단계는 iOS 및 Android 휴대기기에 모델을 배포하는 작업이었습니다. 처음에는 TensorFlow Mobile을 사용해보았습니다. 하지만 인식 결과를 실시간으로 얻어야 했는데 TensorFlow Mobile은 이 요구사항에 부합하는 성능을 발휘하지 못했기에 적합한 옵션이 아니었습니다.
우리가 성능 문제를 해결하려고 한창 애쓰던 무렵, Google은 성능 측면에서 TensorFlow Mobile보다 크게 향상된 TensorFlow Lite를 내놓았습니다. 이 두 솔루션을 아래와 같이 비교할 수 있습니다.
TensorFlow Mobile과 TensorFlow Lite를 비교하는 표

TensorFlow Mobile과 TensorFlow Lite를 비교하는 표

또한 아래 표는 모델에 대한 최초 벤치마크 결과를 나타낸 것입니다.

최초 벤치마크 결과

벤치마크 수치를 기준으로, 우리는 512x512 입력 크기를 기반으로 하는 대부분의 Android 기기에서는 실시간으로 몸동작을 인식할 수 없다는 결론을 내렸습니다. 이 문제를 해결하기 위해 머신러닝 모델을 프로파일링한 결과, PoseNet에 병목 현상이 발생해 계산 시간의 95%를 소비했다는 사실을 밝혀냈습니다. 그래서 우리는 PoseNet 입력 크기와 하이퍼 매개변수를 조정하고, 동작 인식 알고리즘을 다시 훈련하여 발생한 정확성 손실을 줄어든 입력 크기로 보상했습니다. 마침내, 우리는 Android에서 MobileNet을 위해 입력 크기로는 337x337 RGB, 너비 승수로는 0.5를 선택했습니다.
우리의 대상 사용자는 대부분 중장년층이므로, 주요 사용자가 대체로 저사양 기기를 보유한 경향이 있습니다. PoseNet 매개변수를 조정하여 성능을 개선했지만, 여전히 썩 만족스럽지는 않았습니다. 따라서 우리는 어느 스마트폰에나 있는 가속기인 GPU에 의지했습니다. Google에서 마침 그 무렵에 TensorFlow Lite GPU 대리자(시험용)를 내놓았는데, 우리는 그 덕분에 많은 엔지니어링 리소스를 절약했습니다.
모바일 GPU 덕분에 모델 실행이 현저히 가속화되었습니다. 사용자들 사이에서 인기 있는 여러 기기에서 벤치마크를 실시한 결과가 아래 표에 나와 있으며, GPU 대리자를 사용한 경우와 그렇지 않은 경우를 비교할 수 있습니다. 사용자들 사이에서 인기 있는 여러 기기에서 실시한 벤치마크 결과(GPU 대리자를 사용한 경우와 그렇지 않은 경우).

사용자들 사이에서 인기 있는 여러 기기에서 실시한 벤치마크 결과(GPU 대리자를 사용한 경우와 그렇지 않은 경우).

노년층 사용자의 팔단금 동작 움직임은 비교적 느리므로, TensorFlow Lite GPU 대리자(시험용)를 통합한 후 대부분의 기기에서 우리 제품이 원활하게 작동할 수 있었습니다.
애니메이션으로 구현한 팔단금 동작

애니메이션으로 구현한 팔단금 동작

결론 우리는 iOS와 Android에서 모두 Smart Baduanjin 제품을 성공리에 완성해 테스트에 참여한 사용자들로부터 호평을 받았습니다. 우리는 ML 기술과 TensorFlow를 활용하여 팔단금 초보자가 시연 동영상을 따라 동작을 익힐 수 있도록 하기 위한 '가이드 모델'을 제공했습니다. 우리는 숙련된 팔단금 수련자가 실력을 더욱 키울 수 있도록 점수와 같은 소중한 피드백을 제공했습니다. 현재, ‘Smart Baduanjin’은 App Store와 Google Play에서 모두 무료로 제공됩니다. 한편, OliveX는 다른 피트니스 운동에 인체 포즈 추정을 적용할 방법을 적극적으로 연구하고 있습니다. 우리는 수련자 몸동작의 정확성이 매우 중요하다는 점에서 다른 많은 운동 수련 역시 팔단금과 마찬가지라는 점을 깨달았습니다. 올바른 몸동작은 신체 부상을 방지할 뿐 아니라, 운동의 효율성을 높이는 데도 도움이 됩니다. 따라서 우리는 팔단금 프로젝트에서 얻은 지식과 기술을 다른 영역에도 이전하고 싶습니다.

프로덕션 환경에서 실제로 사용되는 머신러닝, TensorFlow Extended(TFX)에 대해 소개합니다

Thursday, November 21, 2019

.post-body span { white-space: normal !important; } 게시자: Robert Crowe, Konstantinos (Gus) Katsiapis, Kevin Haas(TFX 팀을 대표해 게시함)

사람들은 머신러닝에 대해 생각할 때, 보통은 지금 만들 수 있는 훌륭한 모델에 대해서만 생각합니다. 결국, 대다수 연구 논문에서 초점을 맞춰 설명하는 내용이기도 합니다. 하지만 그런 멋진 모델을 실제 사용 환경에서 사용할 수 있도록 하고 싶다면 모니터링, 신뢰성, 유효성 검사 등, 프로덕션 솔루션에 필요한 모든 사항에 대해 생각해봐야 합니다. 그게 바로 Google에서 TensorFlow Extended(TFX)를 만들어 우리의 머신러닝(ML) 파이프라인을 위한 프로덕션 수준의 지원을 제공하는 이유입니다. 우리는 모든 곳의 개발자가 프로덕션 수준 TFX 파이프라인을 통해 모델을 만들고 배포할 수 있도록 오픈소스 커뮤니티와 함께 TFX를 공유하고 있습니다.
Google은 TFX가 필요했기 때문에 TFX를 만든 것이며, 그 전에는 우리의 요구를 충족시켜 줄 만한 것이 없었습니다. Google, 좀 더 일반적으로 Alphabet은 대부분의 자사 제품에 ML을 광범위하게 사용합니다. 사실, Google이 만든 최초의 ML 파이프라인 프레임워크는 TFX가 아니었습니다. TFX는 이전부터 이루어진 여러 차례의 시도를 통해 진화한 결과물로, 지금은 Google의 대다수 ML 프로덕션 솔루션을 위한 기본 프레임워크가 되어 있습니다. TFX는 Google 이외에 Twitter, Airbnb, PayPal을 비롯한 우리 파트너들에게도 깊은 영향을 미쳤습니다. 단순히 ML만의 문제가 아닌 TFX 애플리케이션에 ML을 결합할 계획을 세우기 시작할 때, 일반적으로 ML에 대해 생각할 수 있는 모든 사항을 고려할 것입니다. 지도 학습을 수행할 경우에는 라벨을 지정한 데이터를 가져오고 데이터셋에 가능한 입력 데이터를 위한 공간이 충분히 확보되어 있는지 확인하는 등의 작업이 여기에 포함됩니다. 또한 피쳐셋에 포함되는 예측 정보는 최대화하면서도 피쳐셋의 차원은 최소화하고 싶을 것입니다. 공정성에 대해 생각해보고 애플리케이션이 불공정하게 편향되지 않도록 해야 합니다. 드물게 발생할 뿐이지만 중요한 상황이 벌어지는 조건에 대해 예측할 수 있는 헬스케어와 같은 애플리케이션에서는 특히 드물게 발생하는 조건도 고려해야 합니다. 마지막으로, 이런 애플리케이션은 시간이 흐르면서 새로운 데이터가 유입되고 조건이 바뀜에 따라 진화하는, 살아 있는 솔루션이 될 것이라는 점을 염두에 두고 데이터의 수명 주기 관리를 계획해야 합니다. 하지만 그 모든 점 외에도, 소프트웨어 애플리케이션을 프로덕션 환경에 적용한다는 점을 잊어선 안 됩니다. 즉, 안전과 보안뿐 아니라 확장성, 일관성, 모듈성, 테스트 가능성을 비롯하여, 어떤 프로덕션 소프트웨어 애플리케이션이라도 가지고 있는 모든 요구사항이 그대로 적용된다는 뜻입니다. 이제는 모델을 단순히 훈련하는 차원을 훌쩍 넘어섰습니다! 이런 문제는 그 자체로 모든 프로덕션 소프트웨어 배포 시에 맞이하게 되는 해결 과제이며, ML을 수행한다는 이유만으로 잊어도 되는 문제가 아닙니다. 어떻게 이 모든 요구를 충족시키고 새롭고 놀라운 모델을 프로덕션 환경에 적용해야 할까요? 그 해답은 바로 TFX입니다. TFX를 사용하면 프로덕션 소프트웨어 배포와 모범 사례에 대한 요구사항 중 다수를 포함하는 프로덕션 ML 파이프라인을 만들 수 있습니다. 이는 데이터를 내부 데이터화하는 단계부터 시작해 데이터 유효성 검사, 특징 추출, 훈련, 평가, 서빙의 순서로 흘러갑니다. TensorFlow 자체 외에, Google은 ML 파이프라인의 각 주요 단계를 위한 라이브러리인 TensorFlow Data Validation, TensorFlow Transform, TensorFlow Model Analysis도 만들었습니다. 또한 서버 팜(TensorFlow Serving), 네이티브 모바일 애플리케이션(TensorFlow Lite), 자바스크립트 애플리케이션(TensorFlow JS)을 비롯한 다양한 배포 대상을 위한 프레임워크도 만들었습니다. TFX는 라이브러리를 활용하는 일련의 파이프라인 구성 요소를 구현하고, 개발자가 자체적인 구성 요소를 만들 수도 있도록 허용합니다. 이 모든 것을 함께 연계하기 위해, Google은 파이프라인 저장, 구성 및 오케스트레이션과 같은 작업을 위한 몇 가지 수평적 계층을 만들었습니다. 이런 계층은 파이프라인과 파이프라인에서 실행하는 애플리케이션을 관리하고 최적화하는 데 실로 중요합니다. 프로덕션 환경의 ML은 많은 도전적 과제를 안겨주는데, Google은 그에 대한 모든 해법을 가지고 있는 것처럼 행세하지 않습니다. TFX는 ML 커뮤니티에서 계속 발전하고 진화하는 분야이며, 이러한 발전에 대한 기여를 적극적으로 환영합니다. 프로덕션 환경에서 머신러닝이 안고 있는 난제에 대한 개요를 훌륭하게 설명한 이 논문을 참조하시기 바랍니다. '파이프라인'과 '구성 요소'란 무엇일까요? TFX 파이프라인은 각각 다른 작업을 수행하는 구성 요소의 시퀀스로 생성됩니다. 구성 요소는 'DAG', 즉 Directed Acyclic Graph로 구성됩니다. 하지만 정확히는 어떻게 구성되어 있을까요?

TFX 구성 요소로는 driver, executor, publisher라는 세 가지 주요 부분이 있습니다. 이들 중 드라이버와 publisher의 두 부분은 주로 변경할 수도 있지만 아마도 절대 그럴 필요가 없을 상용구 코드입니다. 개발자가 실제로 자신의 코드를 삽입하고 사용자 설정을 하는 부분은 바로 executor입니다.
driver는 실제 환경의 상태를 검사하여 어떤 작업을 수행해야 할지 결정함으로써 작업 실행을 오케스트레이션하고 executor에게 메타데이터를 피드합니다. publisher는 executor의 결과를 받아 메타데이터 저장소를 업데이트합니다. 하지만 executor는 실제로는 각 구성 요소에 대한 작업이 수행되는 곳입니다.
그래서 첫째, 구성 요소에 대한 구성이 필요하고 TFX에서는 Python을 사용하여 그런 구성이 수행됩니다. 다음으로, 구성 요소에 대한 입력과 결과를 보낼 장소가 필요합니다. 바로 메타데이터 저장소가 그 역할을 합니다. 메타데이터 저장소에 관해 좀 더 자세히 설명하겠지만, 지금은 대부분의 구성 요소에 대해서는 입력 메타데이터가 메타데이터 저장소에서 오고 결과 메타데이터가 메타데이터 저장소에 다시 기록된다는 점만 알아두시기 바랍니다.

데이터가 파이프라인을 통해 이동함에 따라, 구성 요소는 이전의 구성 요소에서 생성된 메타데이터를 읽고, 파이프라인의 하부에 있는 구성 요소에서 사용하게 될 메타데이터를 작성합니다. 파이프라인의 시작 및 끝에서처럼 몇 가지 예외는 있지만, 대다수의 부분에서는 데이터가 위와 같은 방식으로 TFX 파이프라인을 통해 흐릅니다.
TFX 파이프라인 오케스트레이션 이 모든 구성 요소를 구성하고 이런 파이프라인을 관리하려면 오케스트레이션이 필요합니다. 그런데 오케스트레이션이란 정확히 무엇이고 오케스트레이션이 어떤 도움이 되는 걸까요? ML 파이프라인을 만들고 그 파이프라인을 구성하는 구성 요소의 시퀀스를 정의하고 그 실행을 관리하려면 오케스트레이터가 필요합니다. 오케스트레이터는 작업을 트리거하고 구성 요소를 모니터링하는 데 사용할 수 있는 관리 인터페이스를 제공합니다. 파이프라인의 다음 단계를 시작하기만 하면 될 경우에는 작업을 인식하는 아키텍처로 충분합니다. 이전의 구성 요소가 작업을 마치자마자 다음 구성 요소를 곧바로 시작할 수 있습니다. 하지만 작업과 데이터를 인식하는 아키텍처는 훨씬 더 강력하며, 수많은 실행이 이루어지는 동안 모든 구성 요소로부터의 모든 아티팩트를 저장하므로 실제로 어떤 프로덕션 시스템에 대해서도 거의 필수적인 요건이라 할 수 있습니다. 바로 그 메타데이터를 확보하면 훨씬 더 강력한 파이프라인이 생성되고, 만약 메타데이터를 확보하지 못했더라면 매우 어려웠을 많은 일들이 가능해지므로, TFX는 작업과 데이터를 인식하는 파이프라인 아키텍처를 구현합니다. 개방적이고 확장 가능한 TFX를 구현하는 방법 중 하나는 오케스트레이션을 사용하는 것입니다. Google은 별도의 구성 없이 바로 사용 가능한 Apache Airflow와 Kubeflow를 위한 지원을 제공하지만, 필요하다면 다른 오케스트레이터를 사용하기 위한 코드를 작성할 수 있습니다. 마음에 드는 워크플로 엔진이 이미 있다면, TFX와 함께 그 엔진을 사용하도록 실행기를 빌드할 수 있습니다.
왜 메타데이터를 저장해야 할까요? TFX는 ML 파이프라인을 위한 메타데이터를 정의하고 저장하고 쿼리하기 위한 오픈소스 라이브러리인 ML-Metadata(MLMD)를 사용하여 메타데이터 저장소를 구현합니다. MLMD는 관계형 백엔드에 메타데이터를 저장합니다. 현재 구현에서는 별도의 구성 없이 SQLite 및 MySQL을 바로 사용할 수 있도록 지원하지만, 기본적으로 어떤 SQL 호환 데이터베이스에 대해서든 ML-Metadata를 확장하는 코드를 작성할 수 있습니다. 그렇지만 메타데이터 저장소에 정확히 무엇을 저장하는 것일까요? 첫째, 개발자가 훈련한 모델에 관한 정보, 개발자가 모델을 훈련할 때 사용한 데이터, 그리고 평가 결과를 저장합니다. 우리는 이런 유형의 메타데이터를 '아티팩트'라고 지칭하는데, 아티팩트에는 속성이 있습니다. 데이터 자체는 데이터베이스 외부에 저장되지만, 데이터의 속성과 위치는 메타데이터 저장소에 보관됩니다. 다음으로, 우리는 각 구성 요소가 실행될 때마다 해당 실행 기록을 보관합니다. ML 파이프라인은 긴 수명에 걸쳐 새로운 데이터가 들어오거나 조건이 변경됨에 따라 수시로 실행되므로, 해당 기록을 보관하는 것이 디버깅, 재현 및 감사에 중요하게 됩니다. 마지막으로, 우리는 데이터 객체가 파이프라인을 따라 흐를 때 데이터 객체의 계보 또는 출처도 포함합니다. 따라서 파이프라인을 통해 전후로 추적하여 데이터와 코드의 변경에 따른 구성 요소의 출처와 실행 결과를 파악할 수 있습니다. 이는 파이프라인의 최적화나 디버그가 필요할 때 실로 중요하며, 이것이 없다면 최적화나 디버그에 상당한 어려움이 있을 것입니다.
메타데이터로 작동되는 기능 이제 메타데이터 저장소에 무엇이 저장되는지 알게 되었으므로, 이 저장소에서 얻는 기능상 이점에 대해 살펴봅시다. 첫째, 모든 데이터 아티팩트의 계보와 출처를 알고 있으면 파이프라인에서 앞쪽과 뒤쪽으로 추적할 수 있습니다. 예를 들어 모델을 훈련할 때 어떤 데이터를 사용했는지, 새로운 특징 추출이 평가 측정항목에 어떤 영향을 미쳤는지 등을 파악할 수 있습니다. 일부 사용 사례에서는 데이터의 출처와 결과를 추적하는 이 기능이 규정이나 법률에 정해진 필수 요건인 경우도 있습니다. 이 기능은 현재의 모델이나 현재의 결과를 위한 것만은 아니라는 점을 기억하세요. 시간이 흐르면서 새로운 데이터를 가져와 모델을 다시 훈련할 때 데이터와 결과가 어떻게 바뀔지 파악하는 데도 관심 있으실 것입니다. 종종 어제나 지난주에 실행한 모델 실행 결과와 비교해 결과가 개선되거나 악화된 이유를 알고 싶을 것입니다. 프로덕션 솔루션은 일회용이 아니라 필요한 만큼 오랫동안 사용되므로, 몇 개월이나 몇 년의 수명을 가질 수 있습니다. 또한 필요할 때만 구성 요소를 다시 실행하고 웜 부팅을 사용하여 훈련을 계속함으로써 파이프라인을 훨씬 더 효율적으로 만들 수도 있습니다. 개발자는 실행에 몇 시간이나 며칠이 걸릴 수 있는 큰 데이터세트를 종종 다루게 된다는 점을 유념하세요. 이미 하루 동안 모델을 훈련했는데 좀 더 훈련하고 싶은 경우 처음부터 다시 시작하는 대신 직전에 훈련을 끝낸 부분부터 시작할 수 있습니다. 메타데이터에 모델에 관한 정보를 저장해두었다면 훨씬 더 쉽습니다. 또한 입력 또는 코드가 바뀌었을 때 파이프라인의 다른 구성 요소만 다시 실행하여 이들을 훨씬 더 효율적으로 만들 수도 있습니다. 구성 요소를 다시 실행하는 대신, 캐시에서 이전 결과를 그냥 끌어올 수 있습니다. 예를 들어 파이프라인을 새로 실행할 때 훈련자의 매개변수만 변경되는 경우에는 파이프라인이 어휘와 같은 데이터 전처리 아티팩트를 재사용할 수 있으며, 데이터 볼륨이 크면 데이터 전처리 비용이 비싸다는 점을 고려하면 이를 통해 많은 시간을 절약할 수 있습니다. TFX와 MLMD를 사용할 때 별도의 구성 없이 이런 재사용이 가능한데, 더 간단한 '파이프라인 실행' 인터페이스가 표시되며 실행할 구성 요소를 수동으로 선택하는 문제를 걱정할 필요가 없습니다. 이 점 역시 처리 시간을 단축하는 데 도움이 됩니다. 구성 요소의 입력 데이터와 결과를 메타데이터에 저장했다면 훨씬 더 쉬울 것입니다.
구성 요소? 어떤 종류의 구성 요소일까요? 이제 오케스트레이터가 있으므로, TFX에 기본으로 제공되는 구성 요소에 대해 얘기해봅시다. 하지만 먼저 Apache Beam에 대해 얘기해봅시다. Apache Beam에 대해 먼저 설명한 후 기본 구성 요소에 대해 설명하겠습니다. 대량의 데이터, 특히 ML 작업 부하와 같은 계산 집약적 데이터의 분산 처리 문제를 다루려면 Apache Spark, Apache Flink 또는 Google Cloud Dataflow와 같은 분산 처리 파이프라인 프레임워크가 필요합니다. TFX 구성 요소는 대부분 여러 실행 엔진에서 실행 가능한 통합 프로그래밍 모델인 Apache Beam 상에서 실행됩니다. Beam 덕분에 개발자가 이미 가지고 있는 분산 처리 프레임워크를 사용하거나, 우리가 선택한 분산 처리 프레임워크를 강제로 사용하지 않고 개발자가 원하는 프레임워크를 선택할 수 있습니다. 현재, Beam Python은 Flink, Spark 및 Dataflow 실행기에 실행할 수 있지만, 새로운 실행기가 추가되고 있습니다. 또한 직접 실행기도 포함하고 있는데, 이 실행기를 사용하면 노트북과 같은 로컬 시스템에서 개발 중인 TFX 파이프라인을 실행할 수 있습니다. 기본 구성 요소

TFX는 처음 설치할 때 완벽히 구비된 기본 구성 요소 집합을 포함하는데, 각 구성 요소는 프로덕션 ML 파이프라인의 각기 다른 부분에 맞춰 설계되었습니다. 예를 들어 Transform 구성 요소는 Apache Beam을 사용하여 어휘를 생성하거나 기본 구성 요소 분석(PCA)을 실행하는 등, 특징 추출 변환을 수행합니다. 이와 같은 변환은 Dataflow를 사용하여 Flink나 Spark 클러스터 또는 Google Cloud에서 실행할 수 있습니다. Apache Beam의 이식성 덕분에, 코드를 변경하지 않고 이들 사이에서 이전할 수 있습니다. Trainer 구성 요소는 TensorFlow만 사용합니다. 놀라운 모델을 만들어 훈련할 생각만 하던 때를 기억하시나요? 그게 바로 여기서 사용할 코드입니다. 현재, TFX는 tf.estimators만 지원합니다. 호환성에 관한 다른 정보는 여기에 나열되어 있습니다. 어떤 구성 요소는 무척 단순합니다. 예를 들어 Pusher 구성 요소는 Python만 있으면 주어진 작업을 수행할 수 있습니다. 이 모든 것을 한데 모아서 오케스트레이터로 관리하면 TFX 파이프라인을 가지게 되는 것입니다. 한쪽에서는 데이터를 내부 데이터화하고 다른 쪽에서는 SavedModel을 배포 대상 중 하나 이상으로 푸시합니다. 여기에는 TensorFlow Hub, TensorFlow JS를 사용하는 자바스크립트 환경, TensorFlow Lite를 사용하는 네이티브 모바일 애플리케이션, TensorFlow Serving을 사용하는 서버 팜, 또는 위 모든 것이 포함됩니다. 이제 이들 각 구성 요소를 좀 더 자세히 살펴봅시다. 데이터 읽어오기 먼저 ExampleGen을 사용하여 입력 데이터를 내부 데이터화합니다. ExampleGen은 Beam에서 실행되는 구성 요소 중 하나입니다. 이 구성 요소는 지원되는 다양한 소스와 유형에서 데이터를 읽어와 훈련과 평가로 분할하고 tf.examples 형식으로 지정합니다. ExampleGen을 위한 구성은 매우 간단한데, 단 두 줄의 Python 코드에 불과합니다. 다음으로, StatisticsGen은 Beam을 사용하여 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 각 특징에 대해 설명적인 통계 수치를 계산합니다. 이를 위해 StatisticsGen은 Jupyter 노트북에서 실행할 수 있는 시각화 도구를 위한 지원을 포함하는 TensorFlow Data Validation(TFDV) 라이브러리를 활용합니다. 이를 통해 데이터를 탐색하여 이해하고, 있을지 모를 문제를 찾을 수 있습니다. 이는 전형적인 데이터 랭글링 작업으로, 우리 모두가 모델을 훈련하기 위해 데이터를 준비할 때 수행하는 것과 같은 일입니다. 그 다음 구성 요소인 SchemaGen 역시 TensorFlow Data Validation 라이브러리를 사용합니다. 이 구성 요소는 StatisticsGen에 의해 생성된 통계 정보를 살펴보고 특징 값의 데이터 형식, 값의 범위, 카테고리를 포함하여, 특징의 기본 속성에 대한 추론을 시도합니다. 필요에 따라 스키마를 검사하고 오케스트레이션해야 합니다(예: 표시될 것으로 기대하는 새 카테고리 추가). 그 다음 구성 요소인 ExampleValidator는 StatisticsGen과 스키마(SchemaGen의 출력이거나 사용자 큐레이션의 결과일 수 있음)에서 통계 정보를 받으며 문제가 있는지 찾아봅니다. 이 구성 요소는 누락된 값 또는 스키마와 일치하지 않는 값, 훈련/서비스 제공 간의 편중, 데이터 드리프트를 포함한 다양한 이상 클래스를 찾으며, 찾은 내용에 대한 보고서를 생성합니다. 항상 새 데이터를 받게 되므로 문제가 발생할 때 이를 알아차려야 합니다. 특징 추출 Transform은 더 복잡한 구성 요소 중 하나로, 더 많은 구성뿐 아니라 추가 코드도 필요합니다. Transform은 Beam을 사용하여 특징 추출을 수행하는데, 특징에 변환을 적용해 모델의 성능을 향상합니다. 예를 들어 Transform은 어휘를 생성하거나 값을 분류하거나 입력에 대해 PCA를 실행할 수 있습니다. 개발자가 작성하는 코드는 모델과 데이터세트를 위해 어떤 특징 추출을 수행해야 하느냐에 따라 결정됩니다. Transform은 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 두 가지 다른 종류의 결과를 생성합니다. 모든 예제에 대해 동일한 숫자인 특징의 중앙값 또는 표준편차 계산과 같은 작업의 경우, Transform은 상수를 출력합니다. 예제마다 다른 값을 정규화하는 것과 같은 작업의 경우, Transform은 TensorFlow Op를 출력합니다. 그런 다음, Transform은 이러한 상수 및 연산자를 이용해 TensorFlow 그래프를 출력합니다. 그래프는 밀폐되어 있으므로, 그와 같은 변환을 적용하는 데 필요한 모든 정보를 담고 있고 모델을 위한 입력 단계를 형성하게 됩니다. 즉, 훈련과 서비스 제공 사이에 동일한 변환이 일관되게 적용되어 훈련/서비스 제공의 편중을 없애준다는 뜻입니다. 대신에 훈련 환경에서 서비스 제공 환경 또는 애플리케이션으로 모델을 이동하고 두 장소에서 모두 같은 특징 추출을 적용하려는 경우 변환이 똑같기를 바라겠지만 때로는 똑같지 않다는 사실을 발견하게 됩니다. 우리는 그런 상황을 훈련/서비스 제공의 편중이라 부르는데, Transform은 개발자가 모델을 실행하는 어디서든 정확하게 같은 코드를 사용하여 이런 편중을 제거합니다. 모델 훈련 이제는 최종적으로 모델을 훈련할 준비를 마쳤으며, 모델 훈련은 전체 프로세스에서 사람들이 머신러닝을 생각할 때 흔히 떠올리게 되는 부분입니다. Trainer는 Transform에서 변환 그래프와 데이터를 가져오고 SchemaGen에서 스키마를 가져온 후, 작성한 모델링 코드를 사용하여 모델을 훈련합니다. 이것이 일반적인 모델 훈련이지만, 훈련이 완료되면 Trainer는 두 가지 다른 SavedModel을 저장합니다. 하나는 프로덕션 환경에 배포되는 SavedModel이고, 다른 하나는 모델의 성능 분석에 사용할 EvalSavedModel입니다. 단계 수나 웜 부팅의 사용 여부와 같은 Trainer를 위한 구성을 예상하실 것입니다. Trainer를 위해 만드는 코드가 모델링 코드이므로, 필요한 만큼 단순하거나 복잡하게 만들 수 있습니다. 훈련 프로세스를 모니터링하고 분석하려면 일반적인 방법과 똑같이 TensorBoard를 사용할 수 있습니다. 이 경우에는 현재 모델 훈련의 실행을 보거나 여러 차례의 모델 훈련 실행에서 얻은 결과를 비교할 수 있습니다. 이는 위에서 설명한 ML-Metadata 저장소이기에 가능한 일일 뿐입니다. TFX를 사용하면 이런 종류의 비교 작업을 상당히 수월하게 수행할 수 있다는 점을 자주 확인할 수 있습니다. 충분히 좋은가요? 모델 훈련을 마쳤는데, 결과가 어때 보입니까? Evaluator 구성 요소는 Trainer가 생성한 EvalSavedModel과 원본 입력 데이터를 받아 Beam과 TensorFlow Model Analysis 라이브러리를 사용하여 심층 분석을 수행합니다. 이는 전체 데이터세트에서 최상위 레벨 결과만 살펴보는 것이 아니라, 데이터세트의 개별 조각 수준에서 그보다 더 깊은 곳을 들여다보는 것입니다. 이는 모델의 각 사용자의 사용 환경이 개별 데이터 요소에 따라 결정되므로 중요한 사항입니다. 모델이 전체 데이터세트에서 잘 돌아갈 수도 있겠지만, 모델이 사용자가 제공하는 데이터 요소에서 제대로 작동하지 않을 경우 사용자 환경 역시 열악해집니다. 이 점에 대해서는 다음 게시물에서 자세히 다루겠습니다. 이제 모델의 성능도 살펴보았는데, 그대로 프로덕션 단계로 진행해야 할까요? 이미 프로덕션 환경에 있는 모델보다 나은가요, 아니면 못한가요? 단순히 새 모델이라는 이유로 성능이 나쁜 모델을 프로덕션 단계로 푸시하고 싶지는 않을 것입니다. 그래서 ModelValidator 구성 요소가 Beam을 사용해 앞서 설명한 비교 작업을 수행하는데, 개발자가 정의한 기준에 따라 새 모델을 프로덕션 단계로 푸시할지 여부를 결정합니다. ModelValidator가 새 모델이 프로덕션 단계로 넘어갈 준비가 되었다고 판단할 경우에는 Pusher가 모델을 배포 대상으로 실제로 푸시하는 작업을 수행합니다. 그와 같은 대상은 모바일 애플리케이션을 개발 중인 경우에는 TensorFlow Lite가 될 수 있고, 자바스크립트 환경에 배포 중인 경우에는 TensorFlow JS가 될 수 있으며, 서버 팜에 배포 중인 경우에는 TensorFlow Serving이 될 수 있습니다. 또는 위의 모두가 될 수도 있습니다. 이젠 어디로 가야 할까요? TFX 및 ML 파이프라인의 일반적인 기본 개요를 제공하고 주요 개념을 소개하는 것이 이 게시물의 목표였습니다. 이어지는 게시물에서는 필요에 따라 TFX를 확장할 수 있는 방법에 대한 논의를 비롯해, TFX에 대해 더 깊이 알아보도록 하겠습니다. TFX는 오픈소스이므로, Google에서는 소프트웨어 및 ML 커뮤니티에서 TFX의 개선에 도움을 받길 기다리고 있습니다. TFX 개발자 가이드도 참고해보세요. 관련 주제 TensorFlow Extended: 머신러닝 파이프라인과 모델의 이해(Google I/O’19) TFX: TensorFlow 기반 프로덕션 스케일의 머신러닝 플랫폼(KDD 2017) YouTube에 소개된 TFX

동영상 이해를 위해 최적의 네트워크 아키텍처를 자동으로 검색하기

Wednesday, November 20, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 강재욱(Machine Learning GDE)님이 참여해 주셨습니다>
게시자: Michael S. Ryoo(연구원), AJ Piergiovanni(학생 연구자) - Google Robotics 부문
동영상의 이해는 까다로운 문제입니다. 동영상에는 시공간 데이터가 포함되므로 외관 및 모션 정보를 모두 추상화하려면 특징 표현이 필요합니다. 이는 웹 동영상 분류 또는 스포츠 활동 인식과 같이, 동영상의 시맨틱 콘텐츠를 자동으로 이해하는 데 필수적일 뿐 아니라, 로봇 인식 및 학습에도 매우 중요합니다. 인간과 마찬가지로, 로봇에 장착된 카메라에서 전송되는 입력 신호가 세상의 모습을 담은 정적 스냅샷인 경우는 거의 없고 연속적인 동영상 형식을 띱니다.
오늘날의 딥 러닝 모델이 가지는 능력은 이들 모델의 신경 아키텍처에 크게 좌우됩니다. 동영상용 컨벌루션 신경망(CNN)은 보통 Inception 및 ResNet과 같이 알려진 2D 아키텍처를 3D로 수동으로 확장하거나 외관 및 모션 정보를 모두 함께 융합하는 두 스트림으로 구성된 CNN 아키텍처를 신중하게 디자인하는 방법으로 빌드됩니다. 하지만 동영상에 포함된 시공간 정보를 최선으로 활용하는 최적의 동영상 아키텍처 디자인은 아직도 풀리지 않은 문제로 남아 있습니다. 적당한 아키텍처를 발견하기 위한 신경 아키텍처의 검색(예: Zoph 외, Real 외)은 이미지에 대해서는 폭넓게 이루어졌지만, 동영상에 대해 머신에 최적화된 신경 아키텍처는 아직 개발되지 않았습니다. 동영상 CNN은 일반적으로 계산 및 메모리 집약적이므로, 동영상 CNN의 고유한 속성을 포착하는 동시에 이들을 효율적으로 검색하기 위한 접근 방식을 고안하기 어려웠습니다.
우리는 이런 난제에 대응하기 위한 동영상 이해를 위해 최적의 네트워크 아키텍처를 자동으로 검색하는 기술에 대한 연구를 수행했습니다. 우리는 학습 계층과 이런 계층의 모듈 구성(EvaNet), 다중 스트림 연결 학습(AssembleNet), 계산상 효율적이고 콤팩트한 네트워크의 빌드(TinyVideoNet)라는 세 가지 다른 신경 아키텍처의 진화 알고리즘을 보여 드립니다. 우리가 개발한 동영상 아키텍처는 공개된 여러 가지 데이터세트를 기반으로 수작업으로 만든 기존 모델을 상당한 격차로 능가하는데, 네트워크 런타임의 경우 10~100배 정도 개선된 것으로 나타납니다.
EvaNet: 최초의 진화된 동영상 아키텍처 우리가 ICCV 2019의 'Evolving Space-Time Neural Architectures for Videos(동영상용으로 진화하는 시공간 신경 아키텍처)'에서 소개하는 EvaNet은 동영상 아키텍처를 위한 신경 아키텍처 검색 설계를 최초로 시도합니다. EvaNet은 시공간 컨벌루션 계층의 유형뿐 아니라 이런 계층의 순차적 구성이나 병렬 구성을 찾는 데 초점을 맞춘 모듈 레벨 아키텍처 검색입니다. 돌연변이 연산자를 포함한 진화 알고리즘이 검색에 사용되어 아키텍처 모집단을 반복적으로 업데이트합니다. 이를 통해 검색 공간을 병렬 방식으로 더욱 효율적으로 탐색할 수 있는데, 이 검색 공간은 동영상 아키텍처 검색에서 다양한 시공간 계층과 이들 계층의 조합을 고려하기 위해 필요합니다. EvaNet은 (네트워크 내의 다양한 위치에 있는) 여러 모듈을 진화시켜 다양한 아키텍처를 생성합니다.
우리의 실험 결과에 따르면, 유형이 다른 모듈을 진화시켜서 얻는 이러한 동영상 CNN 아키텍처의 이점이 확인됩니다. 이 접근 방식에서 여러 개의 병렬 계층으로 구성된 중요한 모듈이 수동으로 디자인한 모듈에 비해 빠르고 더 우수한 성능을 나타내므로 가장 효과적이라는 점을 종종 발견합니다. 또 다른 흥미로운 면은 비슷하게 좋은 성능을 발휘하지만 추가적인 계산 없이도 진화의 결과로서 다양한 아키텍처를 여럿 얻는다는 점입니다. 이런 아키텍처로 앙상블을 형성하면 성능이 더욱 향상됩니다. 이런 아키텍처의 병렬 특성 덕분에, 모델의 앙상블이 (2+1)D ResNet과 같은 다른 표준 동영상 네트워크보다 계산상 더 효율적이기까지 합니다. 우리는 해당 코드를 오픈소스로 공개했습니다.

다양한 EvaNet 아키텍처의 예. 색칠된 (크거나 작은) 각 상자는 상자의 색으로 유형을 표시하는 계층을 나타내는데, 3D 변환(파란색), (2+1)D 변환(주황색), iTGM(녹색), 최대 풀링(회색), 평균(자주색), 1x1 변환(분홍색)입니다. 계층은 종종 그룹화되어 모듈(큰 상자)을 형성합니다. 각 상자 내부의 숫자는 필터 크기를 표시합니다.

AssembleNet: 더 강하고 나은 (다중 스트림) 모델 빌드 'AssembleNet: Searching for Multi-Stream Neural Connectivity in Video Architectures(AssembleNet: 동영상 아키텍처에서 다중 스트림 신경 연결 검색)'에서는 다양한 입력 형식(예: RGB 및 광학 흐름)과 시간 해상도를 가진 다양한 하위 네트워크 융합의 새로운 방법을 살펴봅니다. AssembleNet은 대상 작업에 맞춰 최적화되는 동안 다양한 입력 형식에 걸친 특징 표현 중에서 '연결성'을 학습하기 위한 일반적인 접근 방식을 제공하는 학습 가능 아키텍처로 구성된 '패밀리'입니다. 다양한 형식의 다중 스트림 CNN을 상위 레벨 네트워크 연결을 탐색하기 위한 효율적인 진화 알고리즘과 결합된 방향성 그래프로 표현할 수 있게 하는 일반적인 방법을 소개합니다. 동영상에서 외관 및 모션의 시각적 실마리에 대해 더 나은 특징 표현을 학습하는 것이 이 방법의 목적입니다. 늦은 융합이나 고정된 중간 융합을 사용하는 이전의 수동 디자인된 두 스트림이 있는 모델과는 달리, AssembleNet은 과도하게 연결된 다중 스트림, 다중 해상도 아키텍처로 구성된 모집단을 진화시키는 동시에 연결 가중치 학습으로 돌연변이들을 안내합니다. 우리는 처음으로 다양한 중간 연결을 포함해 네 스트림이 있는 아키텍처를 살펴보고 있는데, RGB 및 광학 흐름마다 두 개의 스트림이 있으며 각각 시간 해상도가 다릅니다.
아래 그림은 50~150라운드에 걸쳐 임의의 초기 다중 스트림 아키텍처의 풀을 진화시켜서 찾아낸 AssembleNet 아키텍처의 예를 보여줍니다. 우리는 매우 인기 있는 두 동영상 인식 데이터세트 Charades와 Moments-in-Time(MiT)에서 AssembleNet을 테스트했습니다. MiT에서는 처음에 34% 이상의 성능을 보였습니다. Charades에서의 성능은 58.6% mAP(mean Average Precision)에서 훨씬 더 인상적인 결과가 나왔는데, 이전의 테스트에서 최고로 알려진 결과였던 42.5와 45.2에 비하면 크게 향상된 수치입니다.

대표적인 AssembleNet 모델은 Moments-in-Time 데이터세트를 사용하여 진화했습니다. 노드는 시공간 컨벌루션 계층으로 구성된 블록에 상응하는데, 각 에지는 연결성을 지정합니다. 어두운 에지는 더 강력한 연결을 의미합니다. AssembleNet은 대상 작업을 위해 최적화된 학습 가능 다중 스트림 아키텍처의 패밀리입니다.

Charades(왼쪽) 데이터세트와 Moments-in-Time(오른쪽) 데이터세트에 대해 AssembleNet과 수작업으로 디자인한 최신 모델을 비교한 그림. AssembleNet-50 또는 AssembleNet-101은 두 스트림이 있는 ResNet-50 또는 ResNet-101과 같은 수의 매개변수가 있습니다.

작은 동영상 네트워크: 가장 빠른 동영상 이해 네트워크 동영상 CNN 모델이 로봇에서 필요한 것과 같이 실제 환경에서 작동하는 기기에 유용하게 쓰이려면, 효율적인 실시간계산이 필요합니다. 하지만 동영상 인식 작업에서 최신 결과를 얻으려면 깊고 큰 네트워크가 필요한데, 종종 수십에서 수백 개의 컨벌루션 계층이 있으며 이런 계층에 많은 입력 프레임이적용됩니다. 결과적으로, 이런 네트워크는매우 느린 런타임 문제를 야기하며, 최신형 GPU에서는 1초의 동영상 스니펫당 500ms 이상, GPU에서는 2,000ms 이상이 필요하게 됩니다. 우리는 작은 동영상 네트워크에서 계산 비용의 일부만으로 비슷한 성능을 제공하는 네트워크를 자동으로 디자인함으로써 이 문제를 해결합니다. 우리의 작은 동영상 네트워크(TinyVideoNets)는 비슷한 정확도를 달성하고 최대 1초의 동영상에 대해 CPU에서는 37~100ms, GPU에서는 10ms 내에 실시간이나 더 나은 속도로 효율적으로 작동하여 사람이 디자인한 다른 최신 모델보다 수백 배 더 빠른 속도를 실현합니다.
아키텍처 진화 중에 모델 런타임을 명시적으로 고려하고, 계산을 줄이기 위해서 공간 또는 시간 해상도와 채널 크기를 검색 공간으로 탐색하는 알고리즘을 강제 적용하여 이런 성능 이득을 얻습니다. 아래 그림은 TinyVideoNet가 찾아낸 간단하지만 매우 효과적인 두 아키텍처를 보여줍니다. 흥미롭게도, 학습된 모델 아키텍처는 전형적인 동영상 아키텍처보다 컨벌루션 계층 수가 적습니다. 작은 동영상 네트워크는 2D 풀링, 게이팅 계층, squeeze-and-excitation(SE) 계층과 같은 가벼운 요소를 선호합니다. 게다가, TinyVideoNet은 매개변수와 런타임을 공동으로 최적화하여 미래의 네트워크 탐색에서 사용할 수 있는 효율적인 네트워크를 제공할 수 있습니다.

TinyVideoNet(TVN) 아키텍처는 계산 시간을 원하는 제한 범위 내로 유지하면서도 인식 성능을 극대화하도록 진화했습니다. 예를 들어 TVN-1(상단)은 CPU에서는 37ms, GPU에서는 10ms에서 작동합니다. TVN-2(하단)는 CPU에서는 65ms, GPU에서는 13ms에서 작동합니다.

이전 모델과 비교한 TinyVideoNet 모델의 CPU 런타임(왼쪽) 및 (2 + 1)D ResNet 모델과 비교한 TinyVideoNets의 런타임 대 모델 정확도(오른쪽). TinyVideoNet은 이 시간-정확도 공간에서 다른 모델은 존재하지 않는 부분, 즉 극히 빠르면서도 여전히 정확한 공간을 차지합니다.

결론 우리가 아는 한, 이 연구는 동영상 이해를 위한 신경 아키텍처 검색에 관한 최초의 작업입니다. 우리의새로운 진화 알고리즘으로 생성하는 동영상 아키텍처는 공개 데이터세트를 기반으로 사람이 직접 디자인한 CNN 아키텍처 중 가장 잘 알려진 아키텍처를 상당한 격차로 능가합니다. 또한 아키텍처 진화와 함께 계산상 효율적인 동영상 모델인 TinyVideoNet을 학습하는 것이 가능하다는 점도 보여줍니다. 이번 연구는 동영상 이해를 위한 새로운 방향을 제시하고 머신으로 진화된 CNN의 장래성을 잘 보여줍니다.