you gyoung-yoon

Posted on Feb 12, 2022

모니터링을 통한 머신러닝 모델 정확도 유지

#mlops #monitoring

원문: Maintaining Machine Learning Model Accuracy Through Monitoring
원글: May 20, 2021
번역: Feb 12, 2022

요약 🔗

Doordash에서 머신러닝 모델 모니터링 방법 소개
ML 모델은 데이터 패턴에서 파생되기 때문에 모델 드리프트를 진단하고 방지하기 위해 모니터링 필요
프로덕션에서 모든 예측의 입력 및 출력을 기록하여 ML 모델을 분석할 수 있도록 보관
데이터 흐름: API Request > 자체 예측 서비스(Sibyl) > Log Kafa Topic > Snowflake Data warehouse
첫 릴리스에서는 데이터 웨어하우스 사용, 두번째 릴리스에서는 실시간 처리 파이프라인을 사용해서 모니터링 구축
메트릭 및 데시보드는 Prometheus, Grafana 사용하여 별도의 온보딩 없이 시스템을 편하게 사용 할 수 있도록 함
모든 모델, 모든 피쳐 이름 및 모든 메트릭에 대한 완전한 모니터링을 활성화하여 사용자가 별도로 구성할 필요 없도록 만듬
이 글 작성 당시 시간별, 일별 메트릭을 제공, 앞으로는 Continuous time scale에서 작동하도록 시스템 개선 예정

머신 러닝(ML) 모델은 식당에서 주문한 음식을 준비하는 데 걸리는 시간이나 주문이 소비자에게 도달하는 데 걸리는 시간을 신뢰할 수 있는 추정치로 제공합니다. 그러나 ML 모델은 훈련되고 검증되고 프로덕션에 배포되면 model drift에 의해 즉시 성능이 저하되기 시작합니다. 이러한 모델 성능 저하는 시간 추정치 및 기타 ML 모델 출력의 정확도에 부정적인 영향을 미칩니다.

ML 모델은 데이터 패턴에서 파생되기 때문에 모델 드리프트를 진단하고 방지하기 위해 입력과 출력을 면밀히 모니터링 해야 합니다. 실제 데이터에 대한 성능을 체계적으로 측정하면 모델 드리프트의 범위를 측정할 수 있습니다.

플랫폼 사용자를 위한 최적의 경험을 유지하려면 시스템 수준에서 모델이 제대로 수행되지 않을 때를 감지하기 위한 ML 모델에 대한 observability best practice를 개발해야 했습니다. 우리는 플랫폼 사용자들의 의사 결정을 온전히 보호하기 위해 모든 ML 모델에 적용할 수 있고, 설치 없이 즉시 사용 가능한 모니터링 솔루션으로 model obserbility에 접근했습니다.

Model Obserbility에 투자한 이유 🔗

일반적인 ML 개발 흐름에는 피쳐 추출, 모델 훈련 및 모델 배포가 포함됩니다. 그러나 가장 중요한 단계 중 하나인 모델 모니터링은 모델이 배포된 후에만 시작됩니다. 모델 예측은 종종 우리가 Dasher에게 제공하는 배송 (배송 드라이버에 대한 용어)과 같은 비즈니스 결정에 직접적인 영향을 미치기 때문에 모델 모니터링이 중요 합니다.

모델 예측은 시간이 지남에 따라 예상 분포에서 벗어나는 경향이 있습니다. 이러한 편차는 당사 플랫폼에서 더 많은 고객, 더 많은 제품, 더 많은 주문으로 인해 데이터 패턴이 변경되기 때문에 발생합니다. 예를 들어, 변화는 COVID-19 전염병과 같은 외부 이벤트의 결과일 수 있으며, 이로 인해 고객이 DoorDash와 상호 작용하는 방식이 크게 변화 했습니다.

과거에는 모델이 구식이 되어 잘못된 예측을 하기 시작한 경우를 보았습니다. 이러한 문제는 비즈니스 및 고객 경험에 부정적인 영향을 미치고 엔지니어링 팀이 문제를 조사하고 수정하는 데 많은 노력을 기울여야 했습니다. 당시에는 이러한 종류의 모델 드리프트를 모니터링할 방법이 었었기 때문에 이 문제를 찾는데는 오랜 시간이 걸렸습니다.

이러한 경험이 우리를 자사의 ML 플랫폼위에 솔루션을 구축하게 만들었습니다. 우리는 이 모델 드리프트 문제를 보다 일반적으로 해결하고 앞으로 우리 플랫폼의 모든 ML 사용 사례에 대해 이와 같은 문제를 방지할 수 있게 되었습니다. 궁극적으로 우리의 목표는 DoorDash 프로덕션에서 사용하는 모든 다양한 ML 모델을 안전하게 보호할 수 있는 솔루션을 만드는 것 이었습니다.

ML 플랫폼 개요 🔗

DoorDash의 ML 플랫폼 에는 아래 그림 1에 설명된 대로 모든 예측을 기록하는 ML 서비스인 Sibyl이 있습니다.

그림 1 : 프로덕션에서 모든 예측을 기록하기 때문에 ML 모델의 입력 및 출력을 분석하는 데 필요한 데이터가 있습니다.

데이터 과학자들이 모델의 성능을 조사하려고 할 때마다 예측 로그가 유용할 것입니다. 예측 로그는 예측 결과, 예측 ID, 피쳐 값 및 해당 예측에 사용된 객체 식별자를 포함하여 모델에서 수행한 모든 예측으로 구성됩니다. 예측 로그와 모델 아티팩트를 결합하여 데이터 과학자는 모델의 예측을 완전히 재현할 수 있어야 합니다.

우리는 이러한 예측 로그를 데이터 과학자가 쉽게 액세스할 수 있는 데이터 웨어하우스에 저장합니다. 이 저장 방법론은 깊이 있는 분석을 쉽게 만들어 주었지만 모델이 드리프트하는 이유에 대한 큰 그림을 이해하는 데 도움이 되지 않았습니다. 보다 구체적인 ML 모델 모니터링 솔루션이 필요했습니다.

ML 모델 모니터링 접근 방식 선택 🔗

ML 모델을 모니터링하는 방법에 대한 문제에 접근할 때 MLOps에 대한 시스템 사고 접근 방식 (머신 러닝을 운용하는 접근 방식)을 사용했습니다. 피쳐(ML 모델 입력)와 예측(ML 모델 출력)을 두 가지 주요 구성 요소로 고려했습니다. 솔루션 설계를 시작하기 위해 기존 오픈 소스 접근 방식을 조사하고 데이터 과학자를 인터뷰하여 모델 모니터링을 위해 어떤 종류의 정보를 보고 싶어하는지에 대해 인터뷰했습니다. 우리가 수집한 정보는 통계적 모니터링이 피쳐와 예측 모두에 적용될 수 있음을 분명히 했습니다.

기존 오픈 소스 프로젝트와 업계 모범 사례를 조사했을 때 단위 테스트 접근 방식과 모니터링 접근 방식이라는 두 가지 뚜렷한 접근 방식이 나타났습니다. 두 접근 방식의 차이점은 소프트웨어 작성 측면에서 설명할 수 있습니다. 우리는 소프트웨어의 기능과 견고성을 테스트하기 위해 단위 테스트를 작성할 수 있으며 생산 성능을 관찰하기 위해 모니터링 시스템을 구현할 수 있습니다. 이러한 접근 방식은 상호 보완적이며 오픈 소스 분야의 데이터 모니터링 및 모델 모니터링 문제는 결국 이러한 버킷 중 하나의 솔루션으로 귀결됩니다.

접근하다	기대	적용	Training과 Production의 동등성
단위 테스트	Pass/fail status	Opt-in	훈련 데이터가 프로덕션 데이터와 일치한다고 가정하고 진행
모니터링	Trends distribution	Out-of-the-box (설치 x)	훈련 데이터가 프로덕션 데이터와 일치한다고 가정하지 않음

단위 테스트 접근 방식 에서 데이터 과학자는 데이터를 분석하고 유효성 검사(예: "배달 시간이 1시간을 넘지 않을 것으로 예상합니다")를 결정하고 이러한 유효성 검사를 기록하여 선택합니다. 그런 다음 이러한 유효성 검사는 모든 새 데이터에 대해 실행됩니다. 앞의 예시에서 유효성 검사는 입력된 모든 배달 시간이 1시간 미만인지 확인합니다. 그러나 신제품의 도입은 이러한 가정을 변경할 수 있으므로 데이터 과학자는 입력이 변경되었다는 경고를 받게 됩니다.

모니터링 접근 방식 에서는 DevOps 모범 사례를 사용 하여 Prometheus 와 같은 표준 DevOps 도구를 통해 메트릭을 생성 하고 Grafana 와 같은 도구를 통해 차트를 사용하여 모니터링 합니다. Prometheus의 Alertmanager 는 메트릭이 특정 임계값을 초과할 때 경고를 보내도록 설정할 수 있습니다.

기대 설정, 채택 요구 사항 및 훈련 데이터와 프로덕션 데이터 간의 패리티 가정을 기반으로 두 접근 방식을 비교하겠습니다.

기대치 설정 🔗

기대치를 설정하는 측면에서 단위 테스트 접근 방식의 장점은 이러한 검증이 모델의 예상 입력 및 출력에 대한 데이터 과학자의 기대를 구체화할 것이라는 점입니다. 단점은 이러한 검증이 부울(Boolean)이라는 것입니다. 즉, 통과하거나 실패하므로 데이터 과학자가 근본적인 문제를 진단하는 데 도움이 되지 않습니다.

예를 들어, 이 단위 테스트 접근 방식은 데이터가 점진적인 변화에서 갑작스러운 변화로 전환되는 경우 세부 정보를 제공하지 않습니다. 특정 메트릭을 초과할 때만 경고를 보냅니다. 모니터링 방식의 경우는 그 반대입니다. 판단할 사전 설정 기대치는 없지만 분석하는 동안 데이터의 추세를 볼 수 있습니다.

채택 요건 (Requirements of adoption) 🔗

채택 측면에서 단위 테스트 접근 방식의 장점은 데이터 과학자가 모델의 입력 및 출력에 대한 유효성 검사를 유연하게 선택할 수 있다는 것입니다. 단점은 단위 테스트가 옵트인(opt-in)이며 이를 채택하기 위해 데이터 과학자의 명시적인 노력이 필요하다는 것입니다. 모니터링 방식에서 시스템은 이러한 메트릭을 자동으로 생성할 수 있지만 유효성 검사를 선택하는 데 있어 유연성이 떨어집니다.

Training과 Production 간의 동등성 가정 🔗

훈련과 프로덕션 사이의 동등성 측면에서. 프로덕션에서 단위 테스트 접근 방식은 훈련 데이터가 프로덕션 값과 일치할 것으로 기대합니다. 이 가정의 단점은 내부 설문조사에서 데이터 과학자들이 훈련 데이터와 프로덕션 데이터 간의 동등성을 가정하지 않는다는 것입니다. 그들은 프로덕션 데이터가 모델이 프로덕션에 배포된 첫날의 훈련 데이터와 다를 것으로 예상합니다.

훈련 및 프로덕션 데이터의 차이를 허용한다는 것은 단위 테스트 접근 방식이 출시일에 경고를 생성할 수 있음을 의미합니다. 훈련 데이터와 프로덕션 데이터 간의 완벽한 패리티는 실제로 어렵기 때문에 이러한 경고는 거짓일 수 있습니다. 모니터링 접근 방식에는 사전 설정된 기대치가 없으며 데이터는 지속적으로 분석할 수 있을 뿐만 아니라 즉시 사용할 수 있습니다.

Best 접근 방식 선택 🔗

이러한 절충점을 감안할 때 우리는 팀에게 이 두 가지 접근 방식 중 선호하는 사항을 묻기로 결정했습니다. 우리는 설문지를 준비하고 데이터 과학자들과 인터뷰하여 그들이 찾고 있는 기능이 무엇인지에 대해 인터뷰했으며, 필수로 있으면 좋은 것을 나열하여 순위를 매기도록 요청했습니다. 설문 조사 응답을 받은 후 결과를 보고, 플랫폼 솔루션을 선호하며 훈련 데이터가 프로덕션 데이터와 일치하지 않을 것이라고 가정하는 것이 분명해졌습니다.

데이터 과학자의 사용 사례를 고려하여 모니터링 접근 방식을 채택하기로 결정했습니다. 모니터링을 구현하려면 관련 Metric 생성, 그래프가 포함된 대시보드 생성, 이러한 메트릭에 대한 Alert 활성화의 세 단계가 필요했습니다.

모니터링 접근 방식은 다음과 같은 이점을 제공합니다.

기존 도구 활용: Observability 팀에서 제공하는 도구를 재사용하면 Metric을 표시하고 Alert 설정이 가능하고 확장성 있고 유연한 플랫폼을 설계할 수 있습니다.
온보딩 필요 없음: 데이터 과학자는 훈련 파이프라인에 모니터링을 추가하기 위해 개별적으로 코드를 작성할 필요가 없으며, 모니터링 솔루션의 확장성과 안정성에 대해서도 생각할 필요가 없습니다.
오픈 소스 표준: Prometheus 및 Grafana와 같은 표준 오픈 소스 관찰 도구를 사용하면 데이터 과학자와 엔지니어는 자체 개발한 시스템을 따로 배울 필요가 없습니다.
손쉬운 시각화: Grafana와 같은 그래프 도구는 분할 및 기록 데이터를 대화식으로 볼 수 있는 기능을 제공합니다. 이것은 이벤트 간의 상관 관계를 찾을 때 매우 유용한 도구입니다.
셀프 서비스: 데이터 과학자는 플랫폼 팀의 도움 없이 이 도구를 사용할 수 있으므로 앞으로 모델 드리프트를 보다 확장성 있게 감지할 수 있습니다.

DevOps 시스템으로 ML 모델 모니터링 구축 🔗

모니터링 방식을 선택한 후 우리는 DoorDash의 기존 시스템을 활용하기 위해 사용할 기술 스택을 결정해야 했습니다. 위의 그림 1과 같이 Apache Kafka topic 단계에서 또는 최종 데이터 웨어하우스 단계에서 데이터를 모니터링할 수 있습니다. 우리는 SQL 쿼리를 활용할 수 있기 때문에 첫 번째 릴리스에는 데이터 웨어하우스 단계를 사용하기로 결정했습니다. 두 번째 릴리스에서는 실시간 처리 시스템 위에 구축하여 실시간 모니터링의 이점을 얻을 수 있었습니다.

예측 로그는 지속적으로 데이터 웨어하우스에 업로드됩니다. 데이터 스키마는 다음과 같습니다.

sent_at : timestamp
- 예측이 이루어진 시간입니다.
- 모니터링에서 aggregation에 이 타임스탬프를 사용합니다. 동일한 모델이 동일한 피쳐에 대해 수행한 여러 예측을 구별하는 것도 중요합니다.
prediction_id : string
- 예측이 수행된 객체에 대한 사용자 제공 식별자입니다. 일치하는 배송 ID, 사용자 ID, 판매자 ID 등이 될 수 있습니다.
predictor_name : string
- 예측자 이름이 목적입니다(예: ETA 예측) .
- 예측자 이름을 기본 모델 ID 또는 섀도우 모델 ID 에 매핑하여 구성할 수 있습니다.
- 그림자 모델은 추가 예측이 이루어지고 기록됩니다.
- 섀도우 모델은 동작을 모니터링하는 데 사용되며 동작이 예상과 일치하면 기본 모델 ID로 승격될 수 있습니다.
model_id : string
- 예측을 수행하도록 훈련된 ML 모델의 버전 이름입니다. ML 모델링은 반복적인 프로세스이므로 시간이 지남에 따라 모델 버전을 추적해야 합니다.
features : key-value pairs
- 각 피쳐 이름에 상응하는 피쳐 값이 수반됩니다.
prediction_result : numerical
- 호출자 서비스에서 사용할 ML 모델의 출력입니다.
default_values_used : set of feature names
- 실제 피쳐 값을 사용할 수 없는 경우 모델에 구성된 f디폴트 피쳐 값으로 fallback하고, 이 set에 피쳐 이름을 추가하여 동일하게 기록합니다.

사용자 연구(user research)의 일환으로 데이터 과학자들은 낮은 피쳐 범위의 선행 지표이기 때문에 예측에서 기본값을 사용하는 비율에 대해 걱정된다고 말했습니다. 예측 서비스인 Sibyl은 특정 값을 사용할 수 없을 때마다 모델 구성 파일에 지정된 기본값을 사용합니다. 예를 들어 특정 식당의 평균 식사 준비 시간을 모를 경우 기본 식사 준비 시간을 사용합니다.

Sibyl은 예측을 하면서 실시간으로 기본값을 입력합니다. 그러나 모니터링 시 기본 집계 값을 알지 못합니다. 얼마나 자주 기본값을 사용했는지 알아보기 위해 Sibyl에 기본값이 사용될 때마다 기록하는 기능을 추가했습니다.

이 스키마를 avg, stddev, min, max 및 approx_percentile(예: P5, P25, P50, P75, P95)과 같은 SQL 집계 함수를 사용하여 SQL 쿼리 템플릿을 생성했습니다.

모니터링 작업은 monitoring cadence와 각 모델 및 예측기(Predictor)에서 추출하려는 메트릭 유형을 정의하는 YAML 구성 파일을 사용하여 생성할 수 있습니다.

시간별 및 일별 Duration, 예측자 이름 및 모델 ID를 이 SQL 쿼리 템플릿에 연결하고 최종 SQL을 생성하여 데이터 웨어하우스를 쿼리하고 집계된 값을 수신하면 이 정보를 Prometheus 메트릭 으로 내보냅니다.

Prometheus 메트릭을 사용할 수 있게 되면 데이터 과학자와 ML 엔지니어가 플랫폼을 최대한 활용할 수 있습니다. 예를 들어, 아래 그림 2와 같이 특정 예측 변수 이름, 모델 ID 및 피쳐 이름에 대한 그래프가 포함 된 Grafana 대시보드 를 사용하여 피쳐 값 통계의 추세를 볼 수 있습니다 .

그림 2: Grafana 대시보드의 대규모의 view collection을 통해 ML 기능 및 예측의 변경 사항에 대한 심층 조사를 수행할 수 있습니다.

PromQL 을 사용하여 쿼리를 생성하고 임계값을 추가하고 팀별 Slack 채널 또는 팀별 PagerDuty 에 경고를 연결할 수 있는 내부 Terraform 리포지토리 를 알림 에 활용할 수 있었습니다 . 우리 Observability 팀은 이미 이 인프라를 사용중이었고, 데이터 과학자와 엔지니어에게도 새로운 도구가 아니었기 때문에 모델 모니터링을 원활하고 쉽게 채택할 수 있었습니다.

유연성 및 적용 범위 개선 🔗

이 첫 번째 릴리스에서는 모델 드리프트를 감지하기 위한 모니터링, 그래프 작성 및 경고 워크플로가 완벽하게 작동했습니다. 데이터 과학자들과의 긴밀한 컨설팅과 조정 덕분에 물류, 사기, 공급 및 수요, ETA 팀을 포함한 많은 팀을 첫 번째 릴리스에 온보딩할 수 있었습니다.

사용 및 피드백을 기반으로 몇 가지 개선 사항을 적용했습니다.

첫 번째 릴리스에서는 데이터 과학자가 특정 피쳐 이름에 대해 원하는 특정 메트릭을 구성할 수 있도록 하여 데이터 과학자를 위한 모니터링 유연성을 높였습니다. 이 추가에는 새 모델 및 새 피쳐 이름에 대한 온보딩 단계가 필요하다는 단점이 있었습니다. 두 번째 릴리스에서는 모든 모델, 모든 피쳐 이름 및 모든 메트릭에 대한 완전한 모니터링을 활성화하여 온보딩 단계를 제거했습니다. 이 두 번째 릴리스에서 즉시 사용 가능한 경험에 대한 우리의 비전을 달성했습니다.

첫 번째 릴리스에서는 시간별 및 일별 집계 수준에서 통계를 계산했습니다. 점심과 저녁 시간에 피크를 보이기 때문에 시간당이 일별 보다 훨씬 더 가치가 있는 것으로 나타났습니다. 따라서 평균보다 분포에 더 많은 가치가 있습니다. 두 번째 릴리스에서는 실시간 그래프 및 Alert를 위한 real-time processing 파이프라인 을 사용하여 모니터링을 재구축하는 시간별 집계에만 집중했습니다 .

출력 모니터링에 대한 또 다른 개선 사항은 Opt-in 평가 메트릭의 도입으로 이루어졌습니다. 예측의 기술적인 통계적 속성을 이해하는 것이 중요하지만 더 유용한 메트릭은 예측된 값이 실제 값에 얼마나 가까운지를 알려줍니다. ”우리의 ML 모델이 실제로 실제 애플리케이션에서 복잡한 문제를 잘 모델링하고 있습니까?” 예를 들어, 배송 ETA를 예측할 때 ****배송이 완료된 시점과 배송된 시점의 차이로 실제 배송 시간을 유추할 수 있습니다.

ML 작업은 수행하는 예측 유형에 따라 분류할 수 있습니다. 이러한 각 작업에는 다음과 같은 특수한 평가 메트릭 세트가 필요합니다.

Regression (mean squared error, root mean square error)
Classification (accuracy, precision, area under curve)
Ranking (mean reciprocal rank, normalized discounted cumulative gain)
Text processing (BLEU score)

어떤 평가 메트릭을 사용할지 또는 모니터링 시스템을 위해 이를 개선하는 방법을 결정하는 데 몇 가지 문제가 있습니다. 준비 시간(prep time) 모델링 과 같은 일부 응용 프로그램에서는 데이터가 검열 됩니다. 사기성 주문 예측과 같은 애플리케이션에서는 지불 프로세와 은행에서 주문을 조사해야 하기 때문에 실제 가치를 몇 주 동안 알 수 없을 수도 있습니다.

이 두 경우의 공통점 중 하나는 예측값과 실제값을 별도로 저장해야 한다는 것입니다. 실제 값은 종종 주어진 예측 ID에 대한 데이터베이스 테이블에서 명시적으로 또는 암시적으로 사용할 수 있습니다. 예측 ID와 데이터베이스 row를 실제 값으로 연결하는 JOIN 쿼리를 작성하여 나란히 두고, 일반적으로 사용 가능한 평가 메트릭 중 하나를 사용할 수 있습니다. 일부 계산은 평균 절대 오차와 같은 기본 연산을 사용하여 수행할 수 있지만 더 복잡한 메트릭의 경우 분산 방식으로 Apache Spark 작업을 사용하여 데이터를 로드하고 평가할 수 있습니다.

그림 3: 모니터링 시스템을 통해 평균 절대 오차(mean absolute error)와 같은 중요한 성능 지표의 편차를 관찰할 수 있습니다.

요약하자면, 우리는 내부 예측 서비스에서 내보낸 예측 로그를 활용하고, 집계를 만들고, 설명 통계(descriptive statistics) 및 평가 메트릭을 Prometheus 로 내보냈고, Grafana 차트에서 해당 메트릭을 보고, 내부 Terraform 리포지토리를 사용하여 Alert를 활성화했습니다.

미래 작업 🔗

앞으로 우리는 DoorDash의 "매일 더 나은 1%" 가치를 두 배로 늘려 모니터링 시스템을 점진적으로 개선하고자 합니다. 우리 앞에 놓인 흥미로운 작업에는 모니터링 시스템의 범위를 더 많은 응용 프로그램으로 확장하고 데이터 과학자와 DoorDash에 대한 유용성, 안정성 및 전반적인 가치를 개선하는 것이 포함됩니다.

일부 real-time applications은 이점을 얻을 뿐만 아니라 시간당 보다 더 자주 이슈에 응답해야 합니다. Continuous time scale에서 작동하도록 시스템의 데이터, 그래프 및 알람 측면을 변경할 것입니다.

정성적 메트릭의 힘을 확장하기 위해 데이터 과학자는 훈련시 모델의 성능을 프로덕션에서의 모델 성능과 비교할 때도 있습니다. 모범 사례로 ML 실무자는 일반적으로 훈련 중에 평가 세트를 설정합니다. 이 동일한 평가 세트를 사용하여 모델이 예상대로 예측하는지 확인할 수 있습니다. 불일치를 만드는 일반적인 실수는 특정 피쳐 누락 또는 잘못된 전처리 입니다.

기술 통계(Descriptive Statistics) 및 경고 임계값은 잘못된 구성 및 갑작스러운 변경을 포착하는 강력한 도구이지만 보다 다양한 회귀를 감지하려면 보다 포괄적인 접근 방식이 필요합니다. 예를 들어, 메트릭은 사용자 행동 및 장기적인 영향으로 변화로 인해 급격한 변화가 아니라 시간이 지남에 따라 점진적인 변화를 경험할 수 있습니다. 우리가 활용할 수 있는 일반적인 연구 영역은 시계열 데이터를 예측하고 시간이 지남에 따라 발생하는 이상치(outlier)를 감지할 수 있는 이상 감지(anomaly detection)입니다.

제품 엔지니어와 데이터 과학자는 자주 ML 모델 개발을 반복하고, 모델의 변경 사항이 제품에 미치는 영향을 이해해야 합니다. 자주 새로운 실험은 새로운 ML 모델에 일대일로 매핑됩니다. 따라서, 모델 분석 프로세스를 간소화하기 위해 ML 모델 모니터링을 당사의 실험 분석 플랫폼인 Curie 와 통합을 고려할 수 있습니다.

종종 ML 모델은 해석하기 어렵거나 예상하지 못한 결과를 생성하여 조사(investigations)를 지연시킬 수 있습니다. 이는 뉴럴 네트워크와 같은 복잡한 모델에서 특별히 일반적인 문제입니다. 이러한 문제를 완화하기 위해 우리 플랫폼은 특정 예측이 이루어진 이유에 대한 정보도 보여줄 수 있습니다. 결과에 가장 크게 영향을 준 입력은 무엇인지? 특성 값을 약간 변경하면 출력이 어떻게 변경 되는지.

결론 🔗

우리는 ML 모델 개발의 공통 프로세스를 식별하여 시스템화하고 ML 플랫폼에 통합했습니다. 데이터 과학자가 시스템 설계보다 모델 개발에 집중할 수 있도록 하는 목표를 달성했습니다.

모델 성능 메트릭 모니터링을 위해 DevOps 접근 방식을 사용한 것은 사용하기 편리하고, 유연했으며 DoorDash의 데이터 과학자 및 기계 학습 엔지니어에게 빠르게 전달하여 모두에게 효과적 이었습니다. 고객은 차트의 추세를 보고, 시간 범위를 확대 및 축소하고, 다양한 기간의 추세를 비교할 수 있습니다. 또한 고객은 이러한 측정항목을 기반으로 사용자 지정 자체 서비스 알림을 생성할 수 있습니다. 우리의 이 시스템의 사용자가 DoorDash의 사용자, 판매자, Dasher 에게 더 훌륭한 사용 경험을 줄 수 있는 ML 모델 개발에 더 집중할 수 있도록 복잡한 부분을 추상화했습니다.

모델 모니터링 시스템은 데이터 크기, 모델 수, 사용 사례 수 및 사용자(데이터 과학자) 수 측면에서 확장 가능합니다. 우리는 플랫폼을 활용하여 즉시 모니터링할 수 있습니다.

이 설계 및 솔루션은 비즈니스 메트릭에 영향을 미치는 내부적인 ML 모델에게 이점을 보여주었습니다. 우리는 이 접근 방식이 데이터 드리프트, 모델 드리프트와 같은 문제를 방지하려는 다른 데이터 기반 팀에게도 실행 가능하고 확장 가능한 솔루션이라고 생각합니다.

감사의 말 🔗

저자는 Kunal Shah, Dhaval Shah, Hien Luu, Param Reddy, Xiaochang Miao, Abhi Ramachandran, Jianzhe Luo, Bob Nugman, Dawn Lu 및 Jared Bauman에게 기여와 조언에 감사드립니다.

Top comments (1)

you gyoung-yoon • Feb 12 '22

이 글에 대한 논의 환영합니다 ~!

DEV Community