자율주행에 머신러닝이 구현될 때 핵심은 모델이 아닌 파이프라인이다

이 기사는 Lei Feng.com에서 복제되었습니다. 재인쇄가 필요한 경우 Lei Feng.com 공식 웹사이트로 이동하여 승인을 신청하세요.

대학 졸업 후 첫 직장을 시작했을 때 저는 머신러닝에 대해 많이 알고 있다고 생각했습니다. 저는 Pinterest와 Khan Academy에서 기계 학습 시스템을 구축하는 인턴십을 두 번 했습니다. 버클리에서의 마지막 해에는 컴퓨터 비전을 위한 딥러닝에 대한 연구를 수행했으며 최초의 인기 딥러닝 라이브러리 중 하나인 Caffe에서 일했습니다. 졸업 후 저는 자율주행차를 전문으로 생산하는 '크루즈'라는 작은 스타트업에 입사했습니다. 현재 저는 Aquarium에서 기업이 딥 러닝 모델을 배포하여 중요한 사회 문제를 해결하도록 돕고 있습니다.

수년에 걸쳐 저는 꽤 멋진 딥 러닝과 컴퓨터 비전 스택을 구축했습니다. 제가 버클리에서 연구를 하던 때보다 지금은 더 많은 사람들이 프로덕션 애플리케이션에서 딥 러닝을 사용하고 있습니다. 그들이 지금 직면하고 있는 많은 문제는 제가 2016년 크루즈에서 직면했던 것과 동일합니다. 저는 여러분과 공유하고 싶은 제작 과정의 딥 러닝에 관해 배운 많은 교훈이 있는데, 여러분이 그것을 어렵게 배울 필요가 없기를 바랍니다.

캡션: 저자 팀이 자동차에 배포된 최초의 머신러닝 모델을 개발했습니다

1 ML 모델을 자율주행차에 배포한 이야기

우선, 크루즈 회사의 역사 이후 자동차에 최초로 배치된 ML 모델입니다. 모델을 개발하면서 워크플로는 제가 연구 기간에 익숙했던 것과 매우 유사하게 느껴졌습니다. 우리는 오픈 소스 데이터를 바탕으로 오픈 소스 모델을 훈련하고 이를 회사의 제품 소프트웨어 스택에 통합하여 자동차에 배포합니다. 몇 주간의 작업 끝에 우리는 최종 PR을 병합하고 자동차에서 모델을 실행했습니다.

"임무 완수!" 다음 불을 끄는 작업으로 넘어가야겠다고 생각했습니다. 나는 거의 몰랐습니다. 실제 작업은 이제 막 시작되었습니다.

모델이 생산에 들어갔고 QA 팀에서 성능 문제를 발견하기 시작했습니다. 하지만 우리는 구축해야 할 다른 모델과 수행해야 할 다른 작업이 있었기 때문에 이러한 문제를 즉시 해결하지는 못했습니다. 3개월 후 문제를 조사했을 때 첫 번째 배포 이후 코드베이스가 변경되었기 때문에 훈련 및 검증 스크립트가 모두 손상되었음을 발견했습니다.

일주일간 수정한 후 지난 몇 달 간의 버그를 살펴보고 모델 생산 실행에서 관찰된 많은 문제가 모델 코드 수정으로는 쉽게 해결될 수 없다는 것을 깨달았습니다. 우리 회사의 차량 데이터는 오픈 소스 데이터에 의존하지 않습니다. 이는 프로세스에 필요한 모든 도구, 운영 및 인프라를 포함하여 라벨링 프로세스를 확립해야 함을 의미합니다.

또 3개월 후에 우리는 자동차에서 무작위로 선택한 데이터를 기반으로 훈련된 새 모델을 실행했습니다. 그런 다음 자체 도구를 사용하여 마크업하세요. 그러나 단순한 문제를 해결하기 시작할 때 어떤 변화가 결과를 가져올 것인지에 대해 더 분별력을 가져야 합니다.

약 90%의 문제는 심층적인 모델 아키텍처 변경이나 초매개변수 조정을 통해서가 아니라 어렵거나 드문 시나리오에 대한 신중한 데이터 큐레이션을 통해 해결됩니다. 예를 들어, 비가 오는 날에는 모델의 성능이 좋지 않다는 사실을 발견하여(샌프란시스코에서는 드물게) 더 많은 비오는 날 데이터에 라벨을 지정하고 새 데이터에 대해 모델을 재교육한 결과 모델의 성능이 향상되었습니다. 마찬가지로 녹색 절두체(주황색 절두체에 비해 흔하지 않음)에서도 모델의 성능이 좋지 않다는 사실을 발견하여 녹색 절두체에 대한 데이터를 수집하고 동일한 과정을 거쳤으며 모델의 성능이 향상되었습니다.

이러한 유형의 문제를 빠르게 식별하고 해결할 수 있는 프로세스를 구축해야 합니다.

이 모델의 1.0 버전을 조립하는 데 몇 주가 걸렸고, 새롭고 개선된 버전의 모델을 출시하는 데 6개월이 더 걸렸습니다. 여러 측면(더 나은 라벨링 인프라, 클라우드 데이터 처리, 교육 인프라, 배포 모니터링)에 대해 점점 더 많은 작업을 수행함에 따라 대략 매달에서 매주 모델을 재교육하고 재배포하고 있습니다.

처음부터 더 많은 모델 파이프라인을 구축하고 이를 개선하기 위해 노력하면서 몇 가지 공통된 주제가 보이기 시작합니다. 우리가 배운 내용을 새로운 파이프라인에 적용하면 더 적은 노력으로 더 나은 모델을 더 빠르게 실행하는 것이 더 쉬워졌습니다.

2 반복 학습을 유지하세요

캡션: 다양한 자율 주행 딥 러닝 팀은 모델 파이프라인의 반복 주기가 매우 유사합니다. 위에서 아래로: Waymo, Cruise, Tesla.

저는 머신러닝이 주로 모델에 관한 것이라고 생각했어요. 실제로 산업 생산에서 기계 학습은 대부분 파이프라인입니다. 성공을 예측하는 가장 좋은 변수 중 하나는 모델 파이프라인에서 효율적으로 반복하는 능력입니다. 이는 단지 빠르게 반복한다는 의미가 아니라 스마트하게 반복한다는 의미이며, 두 번째 부분이 중요합니다. 그렇지 않으면 파이프라인에서 잘못된 모델이 매우 빠르게 생성됩니다.

대부분의 전통적인 소프트웨어는 제품 요구사항을 알 수 없고 적응을 통해 발견해야 하기 때문에 빠른 반복과 민첩한 전달 프로세스를 강조합니다. 따라서 초기 단계에서 불안정한 가정으로 세부적인 계획을 세우는 것보다 신속하게 MVP를 전달하고 진행하는 것이 좋습니다. 반복합니다.

기존 소프트웨어 요구 사항이 복잡한 것처럼 기계 학습 시스템이 처리해야 하는 데이터 입력 영역은 정말 방대합니다. 일반적인 소프트웨어 개발과 달리 기계 학습 모델의 품질은 코드 구현과 코드가 의존하는 데이터에 따라 달라집니다. 데이터에 대한 이러한 의존은 기계 학습 모델이 데이터 세트 구성/관리를 통해 입력 도메인을 "탐색"할 수 있음을 의미하므로 코드를 수정하지 않고도 작업 요구 사항을 이해하고 시간이 지남에 따라 이에 적응할 수 있습니다.

이 기능을 활용하려면 머신러닝에서 데이터와 코드의 반복을 강조하는 지속적인 학습 개념이 필요합니다. 기계 학습 팀은 다음을 수행해야 합니다.

• 데이터 또는 모델 성능의 문제 발견
• 문제 발생 이유 진단
• 문제를 해결하기 위해 데이터 또는 모델 코드 변경
• 재학습 후 모델이 더 좋아지는지 확인
• 새 모델 배포 모델 및 반복

팀은 최소한 매달 이 주기를 거치도록 노력해야 합니다. 괜찮다면 매주 하셔도 됩니다.

대기업은 하루 이내에 모델 배포 주기를 완료할 수 있지만, 인프라를 신속하고 자동으로 구축하는 것은 대부분의 팀에게 매우 어렵습니다. 모델이 이보다 덜 자주 업데이트되면 코드 손상(코드 베이스 변경으로 인해 모델 파이프라인이 중단됨) 또는 데이터 도메인 이동(프로덕션 모델이 시간 경과에 따른 데이터 변경을 일반화할 수 없음)으로 이어질 수 있습니다.

대기업은 모델 배포 주기를 하루 만에 완료할 수 있지만, 대부분의 팀이 신속하고 자동으로 인프라를 구축하는 것은 매우 어렵습니다. 이보다 덜 빈번하게 모델을 업데이트하면 코드가 손상되거나(코드 베이스의 변경으로 인해 모델 파이프라인이 손상됨) 데이터 도메인 이동(프로덕션의 모델이 시간 경과에 따른 데이터 변경을 일반화할 수 없음)이 발생할 수 있습니다.

그러나 올바르게 수행되면 팀은 개선된 모델을 프로덕션에 배포하는 좋은 리듬을 얻을 수 있습니다.

3 피드백 루프 구축

모델 불확실성을 보정하는 것은 모델이 실패할 수 있다고 생각되는 부분에 플래그를 지정할 수 있는 감미로운 연구 영역입니다.

모델을 효과적으로 반복하는 핵심 부분은 가장 영향력 있는 문제를 해결하는 데 집중하는 것입니다. 모델을 개선하려면 모델의 문제점을 파악하고 제품/비즈니스 우선순위에 따라 문제를 분류할 수 있어야 합니다. 피드백 루프를 구축하는 방법은 여러 가지가 있지만, 피드백 루프를 구축하는 방법은 오류를 찾고 분류하는 것부터 시작됩니다.

도메인별 피드백 루프를 활용하세요.

이것은 모델에 대한 피드백을 얻는 매우 강력하고 효과적인 방법이 될 수 있습니다. 예를 들어, 예측 작업은 실제 발생에 대한 기록 데이터를 학습하여 레이블이 지정된 데이터를 "무료"로 얻을 수 있으므로 대량의 새로운 데이터를 지속적으로 공급하고 공정하게 자동으로 새로운 상황에 적응할 수 있습니다.

사람들이 모델의 출력을 검토하고 오류가 발생하면 플래그를 지정할 수 있는 워크플로를 설정하세요.

이 접근 방식은 많은 모델 추론을 통해 오류를 쉽게 잡을 수 있는 경우에 특히 유용합니다. 이런 일이 발생하는 가장 일반적인 방법은 고객이 모델 출력에서 ​​오류를 발견하고 기계 학습 팀에 불만을 제기하는 경우입니다. 이 채널을 통해 고객 피드백을 개발 주기에 직접 통합할 수 있으므로 이를 과소평가할 수 없습니다! 팀에서는 고객이 놓쳤을 수 있는 모델 출력을 사람이 다시 확인하도록 할 수 있습니다. 작업자가 컨베이어 벨트에서 패키지를 분류하는 로봇을 지켜보다가 오류가 발생하면 버튼을 클릭한다고 상상해 보세요.

사람들이 모델의 출력을 검토하고 오류가 발생하면 플래그를 지정할 수 있는 워크플로를 설정하세요. 이는 수많은 모델 추론의 오류가 사람의 검토를 통해 쉽게 발견될 때 특히 적합합니다. 가장 일반적인 방법은 고객이 모델 출력에서 ​​오류를 발견하고 ML 팀에 불만을 제기하는 것입니다. 이 채널을 사용하면 고객 피드백을 개발 주기에 직접 통합할 수 있으므로 팀은 고객이 놓쳤을 수 있는 모델 출력을 사람이 자세히 조사하도록 할 수 있습니다. 작업자가 컨베이어 벨트에서 패키지를 분류하는 것을 지켜보는 것을 생각해 보세요. 오류가 발생할 때마다 버튼을 클릭하세요.

사람이 확인할 수 없을 정도로 모델이 너무 자주 실행되는 경우 자동 검토를 설정하는 것이 좋습니다.

이 기능은 모델 출력에 대한 "온전성 검사"를 작성하기 쉬울 때 특히 유용합니다. 예를 들어 LiDAR 물체 감지기와 2D 이미지 물체 감지기가 일치하지 않거나 프레임 간 감지기가 시간 추적 시스템과 일치하지 않을 때마다 플래그를 지정합니다. 작동하면 오류 조건이 발생하는 위치를 알려주는 유용한 피드백을 많이 제공합니다. 작동하지 않으면 검사 시스템에 버그가 노출되거나 시스템이 잘못되는 경우를 모두 놓치게 되는데, 이는 매우 낮은 위험과 높은 보상입니다.

가장 일반적인(그러나 어려운) 솔루션은 실행되는 데이터에 대한 모델 불확실성을 분석하는 것입니다.

간단한 예는 생산에서 신뢰도가 낮은 출력을 생성하는 모델의 예를 살펴보는 것입니다. 이는 모델이 실제로 불확실하지만 100% 정확하지는 않은 부분을 보여줄 수 있습니다. 때로는 모델이 확실히 틀릴 수도 있습니다. 좋은 추론에 사용할 수 있는 정보가 부족하여 모델이 불확실한 경우도 있습니다(예: 사람이 이해하기 어려운 잡음이 많은 입력 데이터). 이러한 문제를 해결하는 모델이 있지만 이는 활발한 연구 영역입니다.

마지막으로 훈련 세트에 대한 모델의 피드백을 사용할 수 있습니다.

예를 들어 모델과 해당 훈련/검증 데이터세트(예: 고손실 예시) 간의 불일치를 확인하는 것은 신뢰도가 높은 실패 또는 라벨링 오류를 나타냅니다. 신경망 임베딩 분석은 훈련/검증 데이터 세트의 실패 모드 패턴을 이해하는 방법을 제공할 수 있으며 훈련 데이터 세트와 프로덕션 데이터 세트의 원시 데이터 분포 차이를 발견할 수 있습니다.

캡션: 대부분의 사람들의 시간은 일반적인 재교육 주기에서 쉽게 빠져 나옵니다. 이로 인해 기계 시간 효율성이 떨어지더라도 수작업으로 인한 고통이 많이 줄어듭니다.

반복 속도를 높이는 주요 내용은 반복 주기를 완료하는 데 필요한 작업량을 줄이는 것입니다. 하지만 일을 더 쉽게 만드는 방법은 항상 있기 때문에 개선하고 싶은 부분의 우선순위를 정해야 합니다. 나는 노력을 시계 시간과 인간 시간이라는 두 가지 방식으로 생각하는 것을 좋아합니다.

클럭 시간은 데이터 ETL, 모델 훈련, 추론 실행, 지표 계산 등과 같은 특정 컴퓨팅 작업을 실행하는 데 필요한 시간을 나타냅니다. 휴먼 타임(Human time)은 수동으로 결과를 확인하거나, 명령을 실행하거나, 파이프라인 중간에 스크립트를 트리거하는 등 파이프라인을 실행하기 위해 사람이 적극적으로 개입해야 하는 시간을 의미합니다.

예를 들어, 단계 간에 파일을 수동으로 이동하여 여러 스크립트를 순차적으로 수동으로 실행해야 하는데 이는 매우 일반적이지만 낭비입니다. 간단한 계산: 기계 학습 엔지니어의 비용이 시간당 90달러이고 수동으로 스크립트를 실행하는 데 일주일에 2시간을 낭비한다면 연간 1인당 최대 9,360달러가 추가됩니다!

여러 스크립트와 사람의 인터럽트를 완전히 자동화된 하나의 스크립트로 결합하면 모델 파이프라인 루프를 더 빠르고 쉽게 실행할 수 있어 막대한 비용을 절약하고 기계 학습 엔지니어를 덜 이상하게 만들 수 있습니다.

반면, 시계 시간은 일반적으로 "합리적"이어야 합니다(예: 밤새도록 수행 가능). 유일한 예외는 기계 학습 엔지니어가 광범위한 실험을 수행하는 경우 또는 비용/확장 제약이 극심한 경우입니다. 이는 클럭 시간이 일반적으로 데이터 크기 및 모델 복잡성에 비례하기 때문입니다. 로컬 처리에서 분산 클라우드 처리로 전환하면 클럭 시간이 크게 단축됩니다. 그 후, 클라우드의 수평적 확장은 문제의 규모가 커질 때까지 대부분의 팀에서 대부분의 문제를 해결하는 경향이 있습니다.

안타깝게도 일부 작업은 완전히 자동화할 수 없습니다. 거의 모든 프로덕션 기계 학습 애플리케이션은 지도 학습 작업이며, 대부분은 모델이 수행해야 하는 작업을 알려주기 위해 어느 정도 인간 상호 작용에 의존합니다. 일부 영역에서는 인간과 컴퓨터의 상호 작용이 무료입니다(예: 소셜 미디어 추천 사용 사례 또는 직접적인 사용자 피드백이 많은 기타 애플리케이션). 훈련된 방사선 전문의가 훈련 데이터에 대해 CT 스캔에 "레이블을 지정"하는 경우와 같이 사람의 시간이 더 제한되거나 비용이 많이 드는 경우도 있습니다.

어쨌든 모델 개선에 필요한 노동 시간과 기타 비용을 최소화하는 것이 중요합니다. 초기 팀은 데이터 세트를 관리하기 위해 기계 학습 엔지니어에게 의존할 수 있지만, 기계 학습 지식이 없는 운영 사용자나 도메인 전문가가 데이터 관리 작업을 수행하도록 하는 것이 더 경제적입니다(또는 방사선 전문의의 경우 필요한 경우). 이 시점에서는 좋은 소프트웨어 도구를 사용하여 데이터 세트의 라벨링, 검사, 개선 및 버전 관리를 위한 운영 프로세스를 확립하는 것이 중요해졌습니다.

5 ML 엔지니어가 건강해지도록 격려하세요

예: ML 엔지니어가 무게를 들 때 모델 학습의 무게도 증가합니다

새로운 도메인이나 새로운 사용자 그룹을 지원하기 위한 충분한 도구를 구축하는 데는 많은 시간과 노력이 필요할 수 있지만, 잘 수행된다면 그만한 가치가 있는 결과를 얻을 수 있습니다. Cruise의 엔지니어 중 한 명은 특히 똑똑했습니다(일부는 게으르다고도 합니다).

이 엔지니어는 운영 피드백과 메타데이터 쿼리를 결합하여 모델 성능이 좋지 않은 라벨링을 위한 데이터를 추출하는 반복 루프를 구축했습니다. 그런 다음 해외 운영 팀이 데이터에 라벨을 지정하고 이를 새 버전의 교육 데이터 세트에 추가합니다. 그 후 엔지니어는 컴퓨터에서 스크립트를 실행하고 일련의 클라우드 작업을 시작하여 새로 추가된 데이터에 대한 간단한 모델을 자동으로 재교육하고 검증할 수 있는 인프라를 설정했습니다.

매주 재훈련 스크립트를 실행합니다. 그런 다음 모델이 스스로 훈련하고 검증하는 동안 체육관에 도착했습니다. 몇 시간 동안 운동을 하고 저녁 식사를 한 후 그들은 결과를 확인하기 위해 다시 돌아왔습니다. 공교롭게도 새롭고 개선된 데이터는 모델 개선으로 이어질 것이며, 모든 것이 타당하다는 것을 재빠르게 재확인한 후 새 모델을 생산에 투입하면 자동차의 주행성이 향상될 것입니다. 그런 다음 인프라를 개선하고, 새로운 모델 아키텍처를 실험하고, 새로운 모델 파이프라인을 구축하는 데 일주일을 보냈습니다. 이 엔지니어는 분기 말에 승진했을 뿐만 아니라 몸매도 매우 좋았습니다.

6 결론

요약하자면: 연구 및 프로토타이핑 단계에서는 모델을 구축하고 게시하는 데 중점을 둡니다. 그러나 시스템이 프로덕션으로 전환됨에 따라 최소한의 노력으로 개선된 모델을 정기적으로 출시할 수 있는 시스템을 구축하는 것이 핵심 작업입니다. 더 잘할수록 더 많은 모델을 만들 수 있습니다!

이를 위해서는 다음 사항에 집중해야 합니다.

• 모델 파이프라인을 정기적으로 실행하고 이전보다 더 나은 배송 모델을 만드는 데 집중하세요. 매주 또는 그 이하로 새롭고 개선된 모델을 생산해 보세요!
• 모델 출력부터 개발 프로세스까지 좋은 피드백 루프를 구축하세요. 모델의 성능이 좋지 않은 예를 찾아 훈련 데이터세트에 더 많은 예를 추가하세요.
• 파이프라인에서 특히 어려운 작업을 자동화하고 팀 구성원이 자신의 전문 분야에 집중할 수 있도록 팀 구조를 구축하세요. Tesla의 Andrej Karpathy는 이상적인 최종 상태를 "Operation Holiday"라고 부릅니다. 저는 기계 학습 엔지니어가 체육관에 가서 기계 학습 파이프라인이 무거운 작업을 수행하도록 하는 워크플로를 설정하는 것을 제안합니다!

마지막으로 강조할 점은 내 경험상 모델 성능에 관한 대부분의 문제는 데이터로 해결할 수 있지만 일부 문제는 모델 코드를 수정해야만 해결할 수 있다는 점입니다.

이러한 변경 사항은 현재 모델 아키텍처에 매우 특정한 경향이 있습니다. 예를 들어 몇 년 동안 이미지 개체 감지기에 대해 작업한 후 특정 방향 비율에 대한 최적의 사전 상자 할당과 기능 매핑 해상도 개선에 대해 걱정하는 데 너무 많은 시간을 보냈습니다. 작은 물체.

그러나 Transformers가 다양한 딥 러닝 작업을 위한 포괄적인 모델 아키텍처 유형이 될 것이라는 가능성을 보여주면서 이러한 기술 중 더 많은 기술이 덜 관련성이 줄어들고 기계 학습 개발의 초점이 데이터 세트 개선 쪽으로 더욱 옮겨갈 것이라고 생각합니다.

위 내용은 자율주행에 머신러닝이 구현될 때 핵심은 모델이 아닌 파이프라인이다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!