Amazon SageMaker ML 모델에 대한 테스트 접근 방식

플라톤에 의해 재발행

팔로워 : 0

이 게시물은 Intuit Machine Learning Platform의 소프트웨어 엔지니어링 관리자인 Tobias Wenzel과 공동으로 작성했습니다.

예를 들어 자율 주행을 사용하거나 Alexa와 상호 작용할 때 우리 모두는 고품질의 안정적인 기계 학습(ML) 모델의 중요성을 인식하고 있습니다. ML 모델은 비즈니스 애플리케이션, 의료, 금융 기관, amazon.com, TurboTax 등에서 사용되는 덜 분명한 방식으로도 중요한 역할을 합니다.

ML 지원 애플리케이션이 많은 비즈니스의 핵심이 됨에 따라 모델은 소프트웨어 애플리케이션과 동일한 활력과 원칙을 따라야 합니다. MLOps의 중요한 측면은 테스트, 버전 관리, 지속적 전달 및 모니터링과 같은 확립된 DevOps 관행을 사용하여 프로덕션에서 이전에 개발된 ML 모델의 새 버전을 제공하는 것입니다.

몇 가지가 있습니다 처방 적 MLOps에 대한 지침과 이 게시물에서는 따를 수 있는 프로세스와 테스트에 사용할 도구에 대한 개요를 제공합니다. 이는 인튜이트 그리고 AWS. 우리는 이 게시물에 설명된 권장 사항을 실제로 그리고 대규모로 구현하기 위해 함께 작업했습니다. 인튜이트의 목표는 AI 기반 전문가 플랫폼 초기 모델 개발 속도를 높이고 새 버전을 테스트하는 전략에 크게 의존합니다.

요구조건 니즈

다음은 새 모델 버전을 배포할 때 고려해야 할 주요 영역입니다.

모델 정확도 성능 – 하는 것이 중요합니다. 추적하다 정확도, 정밀도 및 재현율과 같은 모델 평가 메트릭의 요소를 제거하고 객관적인 메트릭이 모델의 새 버전으로 상대적으로 동일하게 유지되거나 개선되도록 합니다. 대부분의 경우 최종 사용자의 경험이 향상되지 않으면 새 버전의 모델을 배포하는 것이 의미가 없습니다.
데이터 품질 테스트 – 시뮬레이션 또는 특정 시점 복사 여부에 관계없이 비프로덕션 환경의 데이터는 볼륨 또는 배포 측면에서 모델이 완전히 배포될 때 수신할 데이터를 나타내야 합니다. 그렇지 않은 경우 테스트 프로세스가 대표성이 없으며 프로덕션 환경에서 모델이 다르게 작동할 수 있습니다.
기능 중요도 및 패리티 – 새로운 기능이 도입될 수 있지만 최신 버전의 모델에서 기능 중요도는 이전 모델과 상대적으로 비교되어야 합니다. 이는 모델이 편향되지 않도록 하기 위한 것입니다.
비즈니스 프로세스 테스트 – 새 버전의 모델이 허용 가능한 매개변수 내에서 필요한 비즈니스 목표를 달성할 수 있는 것이 중요합니다. 예를 들어 비즈니스 메트릭 중 하나는 모든 서비스의 종단 간 대기 시간이 100밀리초를 넘지 않아야 하거나 특정 모델을 호스팅하고 재교육하는 비용이 연간 $10,000를 초과할 수 없다는 것일 수 있습니다.
비용 – 테스트에 대한 간단한 접근 방식은 전체 프로덕션 환경을 테스트 환경으로 복제하는 것입니다. 이것은 소프트웨어 개발의 일반적인 관행입니다. 그러나 ML 모델의 경우 이러한 접근 방식은 데이터 크기에 따라 올바른 ROI를 산출하지 못할 수 있으며 해결하려는 비즈니스 문제 측면에서 모델에 영향을 미칠 수 있습니다.
보안 – 테스트 환경에는 실제 고객 데이터 대신 샘플 데이터가 있어야 하는 경우가 많으며 결과적으로 데이터 처리 및 규정 준수 규칙이 덜 엄격할 수 있습니다. 비용과 마찬가지로 단순히 프로덕션 환경을 테스트 환경에 복제하면 보안 및 규정 준수 위험이 발생할 수 있습니다.
기능 저장소 확장성 – 조직이 비용이나 보안상의 이유로 별도의 테스트 기능 저장소를 만들지 않기로 결정한 경우 프로덕션 기능 저장소에서 모델 테스트를 수행해야 하며, 이는 테스트 기간 동안 트래픽이 두 배로 늘어나 확장성 문제를 일으킬 수 있습니다.
온라인 모델 성능 – 온라인 평가는 오프라인 평가와 다르며, 인지된 만족도가 아닌 실시간으로 사용자 만족도를 측정하기 때문에 추천 모델과 같은 경우 중요할 수 있습니다. 계절성 또는 기타 사용자 행동으로 인해 비프로덕션에서 실제 트래픽 패턴을 시뮬레이션하기 어렵기 때문에 온라인 모델 성능은 프로덕션에서만 수행할 수 있습니다.
운영 성능 – 모델이 커지고 다양한 하드웨어에서 분산 방식으로 배포됨에 따라 대기 시간, 오류율 등과 같은 원하는 운영 성능에 대해 모델을 테스트하는 것이 중요합니다.

대부분의 ML 팀은 모델 테스트에 대해 다각적인 접근 방식을 사용합니다. 다음 섹션에서는 다양한 테스트 단계에서 이러한 문제를 해결하는 방법을 제공합니다.

오프라인 모델 테스트

이 테스트 단계의 목표는 정확도 관점에서 기존 모델의 새 버전을 검증하는 것입니다. 실시간 예측을 제공하는 프로덕션 시스템의 예측에 영향을 미치지 않도록 오프라인 방식으로 수행해야 합니다. 새 모델이 적용 가능한 평가 메트릭에 대해 더 나은 성능을 발휘하도록 함으로써 이 테스트는 과제 1(모델 정확도 성능)을 해결합니다. 또한 이 테스트는 올바른 데이터 세트를 사용하여 문제 2와 3(테스트 데이터 품질, 기능 중요도 및 패리티)을 해결할 수 있으며 문제 5(비용)를 해결하는 추가 이점도 있습니다.

이 단계는 준비 환경에서 수행됩니다.

오프라인 백 테스트에서 재생하는 데 사용할 수 있는 프로덕션 트래픽을 캡처해야 합니다. 합성 데이터 대신 과거 프로덕션 트래픽을 사용하는 것이 좋습니다. 그만큼 Amazon SageMaker 모델 모니터 캡처 데이터 기능 에 호스팅된 모델에 대한 프로덕션 트래픽을 캡처할 수 있습니다. 아마존 세이지 메이커. 이를 통해 모델 개발자는 피크 영업일 또는 기타 중요한 이벤트의 데이터로 모델을 테스트할 수 있습니다. 캡처된 데이터는 다음을 사용하여 배치 방식으로 새 모델 버전에 대해 재생됩니다. Sagemaker 일괄 변환. 즉, 배치 변환 실행은 단 몇 시간 만에 몇 주 또는 몇 달에 걸쳐 수집된 데이터로 테스트할 수 있습니다. 이렇게 하면 두 개 이상의 실시간 모델 버전을 나란히 실행하고 각 엔드포인트에 중복 예측 요청을 보내는 것과 비교하여 모델 평가 프로세스의 속도를 크게 높일 수 있습니다. 더 나은 성능의 버전을 더 빨리 찾는 것 외에도 이 접근 방식은 더 짧은 시간 동안 컴퓨팅 리소스를 사용하여 전체 비용을 줄입니다.

테스트에 대한 이러한 접근 방식의 문제는 기능 집합이 모델 버전 간에 변경된다는 것입니다. 이 시나리오에서는 모든 기능을 한 번에 쿼리하고 데이터 캡처를 통해 기록할 수 있도록 두 버전에 대한 기능의 상위 집합으로 기능 집합을 만드는 것이 좋습니다. 그러면 각 예측 호출은 현재 버전의 모델에 필요한 기능에서만 작동할 수 있습니다.

추가 보너스로 통합하여 Amazon SageMaker 명확화 오프라인 모델 테스트에서 새 버전의 모델에서 편향을 확인하고 기능 속성을 이전 버전의 모델과 비교할 수도 있습니다. 파이프라인을 사용하면 교육 후 품질 검사 단계를 수행하여 모델 메트릭 및 기능 중요도를 분석할 수 있도록 전체 워크플로를 오케스트레이션할 수 있습니다. 이러한 측정항목은 SageMaker 모델 레지스트리 다음 교육 실행에서 비교할 수 있습니다.

통합 및 성능 테스트

기능 및 런타임 성능 관점에서 종단 간 비즈니스 프로세스를 검증하려면 통합 테스트가 필요합니다. 이 프로세스 내에서 기능 저장소의 기능 가져오기 및 계산, ML 애플리케이션 실행을 포함하여 전체 파이프라인을 테스트해야 합니다. 이는 다양한 시나리오와 요청을 처리하고 가능한 모든 코드 실행에 대해 높은 범위를 달성하기 위해 다양한 페이로드로 수행되어야 합니다. 이는 4번과 9번 문제(비즈니스 프로세스 테스트 및 운영 성능)를 해결하여 모델의 새 버전에서 비즈니스 프로세스가 중단되지 않도록 합니다.

이 테스트는 준비 환경에서 수행해야 합니다.

통합 테스트와 성능 테스트는 모두 MLOps 파이프라인을 사용하여 개별 팀에서 구현해야 합니다. 통합 테스트의 경우 기능적으로 동일한 사전 프로덕션 환경을 유지 관리하고 몇 가지 다른 페이로드로 테스트하는 시도되고 테스트된 방법을 권장합니다. 테스트 워크플로는 다음과 같이 자동화할 수 있습니다. 이 워크샵. 성능 테스트를 위해 다음을 사용할 수 있습니다. Amazon SageMaker 추론 추천자, 어떤 인스턴스 유형과 사용할 인스턴스 수를 결정할 수 있는 좋은 출발점을 제공합니다. 이를 위해서는 오픈 소스 프로젝트와 같은 부하 생성기 도구를 사용해야 합니다. perfsizesmaker 와 완성하다 인튜이트가 개발한 Perfsizesagemaker를 사용하면 다양한 페이로드, 응답 시간 및 초당 최대 트랜잭션 요구 사항으로 모델 엔드포인트 구성을 자동으로 테스트할 수 있습니다. 다른 모델 버전을 비교하는 자세한 테스트 결과를 생성합니다. Perfsize는 초당 최대 트랜잭션과 예상 응답 시간만 고려하여 다양한 구성을 시도하는 동반 도구입니다.

A / B 테스트

전자 상거래 애플리케이션과 같이 모델의 즉각적인 출력에 대한 사용자 반응이 필요한 많은 경우 오프라인 모델 기능 평가로는 충분하지 않습니다. 이러한 시나리오에서는 모델 업데이트를 결정하기 전에 프로덕션에서 모델을 A/B 테스트해야 합니다. A/B 테스트는 실제 고객에게 영향을 미칠 수 있기 때문에 위험도 있습니다. 이 테스트 방법은 가벼운 엔지니어링 온전성 검사인 최종 ML 성능 검증 역할을 합니다. 이 방법은 또한 과제 8과 9(온라인 모델 성능 및 운영 우수성)를 해결합니다.

A/B 테스트는 프로덕션 환경에서 수행해야 합니다.

SageMaker를 사용하면 다음을 실행하여 ML 모델에 대한 A/B 테스트를 쉽게 수행할 수 있습니다. 여러 생산 변형 끝점에서. 트래픽을 증분 방식으로 새 버전으로 라우팅하여 잘못 작동하는 모델이 프로덕션에 미칠 수 있는 위험을 줄일 수 있습니다. A/B 테스트 결과가 좋으면 트래픽이 새 버전으로 라우팅되어 결국 트래픽의 100%를 차지하게 됩니다. 배포 가드레일을 사용하여 모델 A에서 B로 전환하는 것이 좋습니다. 아마존 개인화 모델을 예로 들면 다음을 참조하십시오. A / B 테스트를 사용하여 Amazon Personalize에서 생성 한 권장 사항의 효율성 측정.

온라인 모델 테스트

이 시나리오에서 모델의 새 버전은 이미 프로덕션에서 라이브 트래픽을 제공하는 버전과 크게 다르므로 오프라인 테스트 접근 방식은 더 이상 새 모델 버전의 효율성을 결정하는 데 적합하지 않습니다. 가장 눈에 띄는 이유는 예측을 생성하는 데 필요한 기능이 변경되어 이전에 기록된 트랜잭션이 모델을 테스트하는 데 사용할 수 없기 때문입니다. 이 시나리오에서는 섀도 배포를 사용하는 것이 좋습니다. 섀도우 배포는 섀도우(또는 도전자) 생산과 함께 모델(또는 챔피언) 현재 예측을 제공하는 모델입니다. 이를 통해 프로덕션 트래픽에서 섀도우 모델의 성능을 평가할 수 있습니다. 그림자 모델의 예측은 요청하는 애플리케이션에 제공되지 않습니다. 오프라인 평가를 위해 기록됩니다. 테스트를 위한 섀도우 접근 방식을 통해 4, 5, 6, 7번 문제(비즈니스 프로세스 테스트, 비용, 보안 및 기능 저장소 확장성)를 해결합니다.

온라인 모델 테스트는 스테이징 또는 프로덕션 환경에서 수행해야 합니다.

새 모델 버전을 테스트하는 이 방법은 다른 모든 방법을 사용할 수 없는 경우 최후의 수단으로 사용해야 합니다. 여러 모델에 대한 이중화 호출은 프로덕션의 모든 다운스트림 서비스에 추가 로드를 생성하여 성능 병목 현상과 프로덕션 비용 증가로 이어질 수 있으므로 최후의 수단으로 권장합니다. 이것이 갖는 가장 명백한 영향은 기능 제공 계층에 있습니다. 물리적 데이터의 공통 풀에서 기능을 공유하는 사용 사례의 경우 프로덕션으로 전환하기 전에 리소스 경합이 없는지 확인하기 위해 동일한 데이터 테이블에 동시에 액세스하는 여러 사용 사례를 시뮬레이션할 수 있어야 합니다. 가능하면 기능 저장소에 대한 중복 쿼리를 피하고 두 모델 버전에 필요한 기능을 두 번째 추론에 재사용해야 합니다. 기능 저장소 기반 아마존 DynamoDB, Intuit이 구축한 것처럼 구현할 수 있습니다. Amazon DynamoDB 가속기(DAX)를 사용하여 데이터베이스에 대한 I/O가 두 배로 늘어나는 것을 방지하고 캐시합니다. 이러한 캐싱 옵션과 기타 캐싱 옵션은 문제 7(기능 저장소 확장성)을 완화할 수 있습니다.

챌린지 5(비용)와 7을 해결하기 위해 섀도 배포를 사용하여 들어오는 트래픽을 샘플링할 것을 제안합니다. 이를 통해 모델 소유자는 생산 시스템에 미치는 영향을 최소화할 수 있는 또 다른 제어 계층을 제공합니다.

섀도 배포는 모델 모니터 챌린저 버전의 개선 사항을 관찰하기 위해 일반 프로덕션 배포와 동일한 오퍼링을 제공합니다.

결론

이 게시물은 모델 테스트와 관련된 다양한 문제를 해결하기 위한 포괄적인 프로세스 및 도구 세트를 만들기 위한 빌딩 블록을 보여줍니다. 모든 조직이 고유하지만 이는 시작하는 데 도움이 되고 고유한 테스트 전략을 구현할 때 고려 사항을 좁힐 수 있습니다.

저자 소개

토비아스 벤젤 캘리포니아 마운틴뷰에 있는 Intuit Machine Learning Platform의 소프트웨어 엔지니어링 관리자입니다. 그는 2016년에 플랫폼이 시작된 이후로 플랫폼에서 일해 왔으며 처음부터 플랫폼을 설계하고 구축하는 데 도움을 주었습니다. 그는 직장에서 플랫폼의 운영 우수성에 중점을 두었고 Intuit의 계절적 비즈니스를 통해 이를 성공적으로 가져왔습니다. 또한 최신 기술로 플랫폼을 지속적으로 확장하는 데 열정을 쏟고 있습니다.