DEV Community: you gyoung-yoon

[2022-09-12] AWS ML Weekly Updates

you gyoung-yoon — Mon, 12 Sep 2022 13:27:59 +0000

2022-09-12 업데이트 전달 드립니다.
관련 자료에 대해서 댓글로 이야기 해주셔도 좋습니다 !

Amazon SageMaker JumpStart 소개

SageMaker JumpStart는 머신러닝으로 해결 가능한 다양한 문제 유형을 학습된 오픈소스 모델과 함께 제공합니다. 배포전에 사용자의 데이터로 추가 학습하여 튜닝할 수 있습니다. 또한, 인프라 설정 텟픔릿과 SageMaker를 실행 할 수 있는 Jupyter Notebook을 함께 제공합니다.

Amazon SageMaker JumpStart 바로가기

Amazon SageMaker JumpStart Virtual Workshop 소개

SageMaker JumpStart Virtual Workshop이 예정이라서 소개드립니다. 일정은 9월 27일 오후 11시 30분 부터 입니다. JumpStart로 빠르게 ML을 시작하고 싶은 분들에게 추천 드립니다.

SageMaker JumpStart Virtual Workshop 신청 바로가기

Amazon SageMaker Autopilot Virtual Workshop 소개

SageMaker Autopilot Virtual Workshop 소개드립니다. 일정은 8월 23일에 있었고, 현재는 영상이 공개되어 있습니다. Amazon SageMaker Autopilot으로 자동으로 데이터를 학습하고, 자신의 모델을 만들고 싶으신 분들은 워크숍 영상을 보시면 좋을 것 같습니다.

SageMaker Autopilot Virtual Workshop 보러가기

Machine Learning Engineering on AWS 책 소개

AWS Hero인 Joshua Arvin Lat의 2번째 책
"Machine Learning Engineering on AWS: Building, Scaling, and Securing Machine Learning Systems and MLOps Pipelines in Production"이 2022년 11월 9일 공개됩니다.

아래의 내용을 다룬다고 하네요.

Amazon SageMaker, Amazon EKS 등을 사용하여 AWS에서 ML 워크로드를 관리하는 실용적인 지식 습득
컨테이너 및 서버리스 서비스를 사용하여 다양한 ML 엔지니어링 요구 사항을 해결하는 방법
AWS에서 자동화된 MLOps 파이프라인 및 워크플로 설계, 구축 및 보호하는 방법

흥미로운 주제가 많고, 이분의 경험을 빠르게 습득할 수 있을것 같아서 기대가 됩니다.

Machine Learning Engineering on AWS 책 구매 바로가기

Amazon SageMaker에서 GPT등 대형 모델을 서빙 할 수 있는 볼륨과 타임아웃을 구성 지원

EBS 볼륨 크기 및 타임아웃 쿼타를 사용자 설정이 대형 모델(최대 500GB)을 배포할 수 있는 크기까지 확장 되었다고 하네요. 이번 런치로 사용자들은 SageMaker의 완전 관리형 실시간 비동기 예측 서비스에 GPT나 OPT 같은 대형 모델 배포할 수 있을 것 같습니다. 기존에 30GB로 제한 되었던 EBS 볼륨 크기는 이제 500GB까지 설정가능하고, 컨테이너 헬스 체크와 다운로드 타임아웃도 60분까지 설정 가능하게 되었습니다. 최근에 출시된 ml.p4d 및 ml.g5 인스턴스에서 멀티 GPU를 사용하여 메모리에 모델을 로드하여 고성능 추론을 구성할 수도 있습니다 !

Amazon SageMaker 소식 바로가기

기타 관심가는 서비스 업데이트

AWS Glue Crawler history 제공

AWS Glue Crawler history는 데이터 스키마 정보를 추론하는 데 사용되는 크롤러 실행, 스케쥴, 데이터 소스, 태그를 볼 수 있는 편리한 방법을 제공합니다. 크롤러 기록은 데이터베이스 스키마의 변경 사항, Amazon S3 파티션 변경 사항 및 사용된 DPU 시간을 포함하여 각 크롤링에 대한 데이터 변경 사항에 대한 요약을 제공합니다.

저도 아테나를 사용하기 위해서 AWS Glue Crawler를 사용하고 있는데요. 편리한 기능이 추가된 것 같아서 기대되네요.

AWS Glue Crawler history 소식 바로가기

Amazon DynamoDB에서 트랜잭션당 최대 100개의 작업을 지원

Amazon DynamoDB transactions을 용하면 여러 아이템을 변경을 all-or-nothing으로 처리할 수 있습니다. 기존에 25개 작업(action)로 제한되어 있었지만, 이제 100개 작업까지 처리가 가능하다고 하네요.

Amazon DynamoDB 소식 바로가기

Amazon RDS, AWS Lambda, AWS Step Functions, Amazon Managed Prometheus 및 AWS KMS용 AWS Controllers for Kubernetes (ACK) 일반 공개

AWS 서비스를 K8s 컨트롤러를 통해서 관리하는 방법이 있군요. AWS 리소스 관리 방법으로 잘 사용될 수도 있을 것 같아서 흥미로워서 기록해봅니다. 둘러보니 정의는 쿠베로하고 워크로드는 실제 AWS 서비스를 사용하는것 같습니다.

AWS Controllers for Kubernetes (ACK) 소식 바로가기

Amazon Kinesis Data Analytics for Apache Flink 에 신규 컨테이너 메트릭 지원

Amazon Kinesis Data Analytics for Apache Flink에서 3가지 신규 컨테이너 레벨 메트릭을 CloudWatch에서 지원한다고 하네요.

CPU Utilization
Memory Utilization
Disk Utilization of Flink Task Managers

새로운 메트릭은 Task Manager 리소스 사용량에 대한 향상된 가시성을 제공하며 Kinesis Data Analytics에서 실행되는 애플리케이션을 쉽게 확장하는 데 사용 가능하다고 합니다.

참고로, Amazon Kinesis Data Analytics를 사용하면 Apache Flink를 통해 스트리밍 데이터를 실시간으로 쉽게 변환하고 분석할 수 있습니다. Amazon Kinesis Data Analytics는 Apache Flink 애플리케이션 구축 및 관리의 복잡성을 줄여주는데요. Amazon MSK, Amazon Kinesis Data Streams, Amazon Opensearch Service, Amazon DynamoDB 스트림, Amazon Simple Storage Service(Amazon S3) 등과 통합도 가능합니다.

Amazon Kinesis Data Analytics for Apache Flink 소식 바로가기

더 많은 AWS ML Weekly Updates 리스트

[2022-09-05] AWS ML Weekly Updates

you gyoung-yoon — Sun, 11 Sep 2022 15:43:49 +0000

2022-09-05 업데이트 전달 드립니다.
관련 자료에 대해서 댓글로 이야기 해주셔도 좋습니다 !

AWS Developers Podcast를 소개

Amazon Web Services(AWS) 개발자 혹은 AWS에서 제품을 구축하는 개발자들과 대화를 나누는 AWS의 공식 팟케스트가 있어서 소개합니다. 매주 다양한 주제로 팟케스트가 올라오네요. 관심 있으신 분들 접속하여 확인해보세요.

AWS Developers Podcast 바로가기

AWS에서 모던 데이터 스트리밍 아키텍처 구축 백서 소개

AWS에서 모던 데이터 스트리밍 아키텍처 구축(Build Modern Data Streaming Architectures on AWS)방법을 설명한 백서(Whitepaper)가 있어서 소개합니다. 모던 데이터 구조 및 최신 데이터 스트리밍 구조를 소개합니다. 모던 데이터 구조를 활용한 다양한 스트리밍 구조 상황별로 소개하여, 자신에게 필요한 방법을 쉽게 찾을 수 있습니다. 다양한 Amazon Kinesis와 Amazon MSK(Amazon Managed Streaming for Apache Kafka)의 특징과 상황별 고려사항을 비교 소개합니다. 스트리밍 처리에 관심이 많으신 분들에게 강력 추천 드립니다 !

AWS에서 최신 데이터 스트리밍 아키텍처 구축 백서 바로가기

AWS Glue 모범 사례: 성능이 뛰어나고 비용 최적화된 데이터 파이프라인 구축 백서 소개

AWS Glue를 사용하여 비용 최적화된 고성능 데이터 파이프라인을 구축할 때 고려해야 할 몇 가지 고려 사항과 모범 사례를 보여주는 백서(Whitepaper)가 최근 발행(2022/08/26)되어 소개 합니다. AWS Glue를 적극 활용중이신 분들은 참고하시면 좋을 것 같습니다.

AWS Glue 모범 사례 백서 바로가기

Amazon SageMaker Autopilot에서 이제 사용자 지정 데이터 분할 옵션을 제공

기존에 Autopilot은 기본적으로 80:20으롤 데이터셋을 자동으로 분할하여 training과 validation 데이터셋으로 사용했습니다. 이번 업데이트로 분할 비율을 사용자가 지정하거나 각각의 훈련, 검증 데이터셋을 업로드 할 수 있게 되었다고합니다.

Amazon QuickSight Q에서 질문 작성자는 이제 Q가 답변하지 않은 질문을 식별하거나 답변을 생성하기 위해 사용자 명확성을 요구할 수 있음

QuickSight에서 질문 작성자가 사용자의 활동을 더 잘 분석할 수 있게 되었다고 하네요. 아래의 기능이 더 추가 되었네요.

답변을 위해 사용자에게 명확한 질문 요구가 필요 경우 식별
응답 여부 또는 사용자에게 명확한 질문 요구 여부에 따라 질문 필터링
질문을 제출한 사용자를 기준으로 질문 필터링

개인적으로 Amazon QuickSight를 사용해본 적은 없지만, 자연어로 질문 가능한 BI(Business Intelligence) 서비스인 QuickSight가 어떻게 개선되고 있는지 관심 갖고자 이번주 업데이트에 추가했습니다.

Amazon QuickSight 업데이트 바로가기

기타 관심가는 서비스 업데이트

EC2 인스턴스에 부착된 여러 EBS 볼륨중 일부만 스냅샷 생성하는 기능 추가

EC2 인스턴스에 부착된 여러 EBS 볼륨중 일부를 중단 일관성(crash-consistent)이 유지하며 특정 시점의 스냅샷 생성하는 기능 추가되었다고 하네요. 기존에는 부착된 전체의 스냅샷을 남겼지만, 이제는 안전하게 일부 볼륨만 스냅샷을 남길 수 있게 되었나보네요. 특정 서비스의 데이터만 백업, 캐싱 등이 필요할때 유용하게 사용할 수 있을 것 같습니다.

EBS 업데이트 정보 바로가기

이제 Amazon Managed Service for Prometheus Alert Manager & Ruler logs를 Amazon CloudWatch Logs에서 사용 가능

Amazon Managed Service for Prometheus의 Alert Manager & Ruler logs 를 Amazon CloudWatch Logs에서 확인할 수 있습니다. 이 기능을 사용하여 사용자는 Prometheus alerting과 configuration을 보다 편하게 트러블 슈팅할 수 있을 것 같습니다.

Amazon Managed Prometheus 업데이트 정보 바로가기

더 많은 AWS ML Weekly Updates 리스트

[2022-08-29] AWS ML Weekly Updates

you gyoung-yoon — Sat, 27 Aug 2022 17:38:00 +0000

2022-08-29 업데이트 전달 드립니다.
관련 자료에 대해서 댓글로 이야기 해주셔도 좋습니다 !

SageMaker hands-on Tutorials 소개

Data preparation, Training, Mode deployment, MLOps 등 다양한 머신러닝 lifecycle task에 맞는 SageMaker 튜토리얼이 있네요. SageMaker를 사용하여 ML개발에 관심 있는 분들 여기 튜토리얼을 살펴 보시면 좋을것 같습니다 !

SageMaker hands-on Tutorials 바로가기

AWS에서 머신러닝으로 고객이 관심있는 제품 타겟팅하기 블로그 글 소개

Amazon Personalize, Pinpoint를 사용하여 고객을 개인화 타겟팅 하는 방법이 블로그로 소개 되었네요. 이 모든 과정을 S3, StepFunction, EventBridge로 이벤트를 연결하여 자동화 처리 되도록 하였습니다. 관심 있는 분들은 자세히 한번 보시면 좋겠네요.

블로그 바로가기

Machine Learning with Amazon SageMaker Cookbook 책 소개

AWS Machine Learning Hero인 Joshua Arvin Lat가 저술한 SageMaker Cookbook이 출판 되었네요. Amazon SageMaker로 고수준의 머신러닝 모델을 만드는 과정을 단계 별로 가이드했다고 하네요. SageMaker 관련 책을 찾는 분들은 살펴 보시면 좋을 것 같습니다.

Amazon SageMaker Cookbook 바로가기

기타 관심가는 서비스 업데이트

DynamoDB 새로운 테이블 데이터를 S3에서 대량 가져오기 지원

이번 출시를 통해 데이터를 DynamoDB 새 테이블에 쉽게 마이그레이션 및 로드할 수 있게 되었다고 하네요. 테스트 데이터를 애플리케이션으로 로드하거나, 데이터 복구 등 마이그레이션 작업에 유용하게 사용 할 수 있을 것 같네요. ML분야에서도 DynamoDB를 사용하여 Online Feature Store 구축하기도 하는데요. Online Feature Store에 데이터를 대량으로 마이그레이션 할때 유용하게 사용할 수 있을 것 같습니다.

뉴스 바로가기

Amazon MSK Serverless 블로그 글 소개

Amazon MSK Serverless를 소개하는 블로그 글이 올라왔네요. Amazon MSK Serverless 기존 MSK 다르게 사용량을 설정하지 않고 on-demand로 프로비전 됩니다. 사용량을 예측하기 어렵거나 변화가 큰 경우에 사용하면 유용 하다고 하네요.

블로그 바로가기

AWS Lambda, 이제 Amazon MSK및 자체 관리형 Kafka를 이벤트 소스로 지원

AWS Lambda가 이벤트 소스로 Amazon MSK 및 자체 관리형 Kafka를 지원한다고 합니다. Kafka에 퍼블리싱된 이벤트를 람다로 처리하기 더욱 편리해질 것 같습니다.

뉴스 바로가기

더 많은 AWS ML Weekly Updates 리스트

[2022-08-22] AWS ML Weekly Updates

you gyoung-yoon — Fri, 26 Aug 2022 18:28:00 +0000

2022-08-22 업데이트 전달 드립니다.
관련 자료에 대해서 댓글로 이야기 해주셔도 좋습니다 !

CodeWhisperer에게 코드 추천 받으면서 Python Serverless application 만드는 영상 공유

Amazon CodeWhisperer는 머신러닝 기반의 코드 추천 서비스 인데요. 이번에 Python을 사용해서 AWS Lambda 코드 작성하는 영상이 공개 되었네요. 코드 추천 서비스를 활용하면 반복적으로 작성하는 코드를 빠르게 완성할 수 있을 것으로 기대하는데요. Github에서도 Copilot이라는 유사한 서비스를 제공하는데요. AWS 서비스 관련 코드는 CodeWhisperer가 더 좋은 추천을 해주지 않을까 기대합니다.

영상 링크 바로가기
Amazon CodeWhisperer preview 신청하기

SageMaker 사용하여 Real-Time 머신러닝 모델 서빙 배포하고 엔드포인트 생성하기 튜토리얼

SageMaker를 사용해서 손쉽게 모델을 배포하고 엔드포인트까지 생성하는 좋은 내용의 튜토리얼이 공유 되었네요. 간단하게 모델을 배포하고 엔드포인트까지 만드는 것이 매우 편리해 보이는데요. 추가적으로, 해당 엔드포인트에 모니터링 메트릭을 제공하고, 트래픽 변화에 따라서 Auto Scaling도 설정할 수 있네요. 이런 기능도 직접 구축한다면 인프라 작업도 간단하지 않은데요. 빠르게 모델 서빙을 시작하기 위해서는 위 튜토리얼의 방식도 매력적으로 생각 됩니다.

튜토리얼 바로가기

AI Use Case Explorer 소개

다양한 도메인의 AI 사용 사례를 찾아 볼 수있는 사이트가 있네요. 사용 사례, 산업군, 회사타입, 지역등으로 검색 가능합니다. 현재까지 AI 분야별로 어떻게 사용되고 있는지 궁금하시다면 검색해보시면 좋을 것 같네요. 저도 제가 근무하는 IT서비스 회사 이외에 다른 분야를 검색해보니 흥미로운 사용 사례가 많네요 ! :D

AI Use Case Explorer 바로가기

더 많은 AWS ML Weekly Updates 리스트

[2022-07-09] AWS ML Weekly Updates

you gyoung-yoon — Fri, 26 Aug 2022 16:20:00 +0000

2022-07-09 업데이트 전달 드립니다 !

Machine Learning University 소개

Amazon의 개발자들이 머신러닝 관련 내용을 공부할때 사용하는 코스와 동일한 학습자료(영상, 예제)가 공개 되어있네요. 자연어 처리, 테이블 데이터, 컴퓨터 비전을 3일 동안 진행하는 기본 과정을 시작하도록 설계되었고, 트리 기반 및 앙상블 모델에 대해서는 5일 동안 진행되는 고급 강의 시리즈를 제공합니다 ! 영상은 YouTube에서도 볼 수 있고, 강의 자료는 Github에 업로드 되어 있습니다. 아마존 개발자들 어떤 자료로 공부하는지 궁금하신 분들은 확인해보셔도 좋을 것 같습니다.

바로가기

What is OpenSearch?

Amazon OpenSerch Service에 대한 글이 공개되었네요. 오픈서치는 실시간 애플리케이션 모니터링, 로그 분석, 웹사이트 검색과 같은 분야에서 광범위하게 사용할 수 있는데요 Apache 2.0 라이선스로 100% 오픈 소스 제품 입니다. 기존에 텍스트 검색에 널리 사용되고 있지만, 개인적으로는 오픈서치가 k-nearest neighbors (KNN)에 잘 사용 될수 있을지 관심이 많습니다. OpenSearch 소식 및 설명이 궁금하셨던 분들은 살펴보셔도 좋을 것 같습니다. 바로가기

Amazon Data Wrangler 및 SageMaker Autopilot을 통한 통합 데이터 준비 및 모델 훈련 블로그 글 소개

Data Wrangler를 사용하여 손쉽게 데이터를 가공하고, SageMaker Autopilot을 사용해서 모델을 자동 훈련시키는 방법에 대한 블로그 글이 공개 되었습니다. 개인적으로 간단하게 데이터 가공을하고, 모델 훈련을 자동으로 진행하는 것이 생성성이 엄청 좋다고 생각하는데요. 두 서비스에 관심있는 분들 블로그 확인해보시면 좋을 것 같습니다 !
바로가기

Weight & Biases를 사용하여 ML 개발자 생산성 향상시키키: Amazon SageMaker의 컴퓨터 비전 예제 블로그 글 소개

Weights & Biases와 AWS가 함께 작성한 블로그 글이네요. 이 글에서는 Weight & Biases(W&B) 와 Amazon SageMaker를 사용하여 자율 주행 차량 객체 인식 모델을 훈련 합니다. 두 솔루션이 ML 개발자의 수작업을 줄이고 모델 개발 프로세스의 투명성을 높이며 팀이 프로젝트에서 협업할 수 있도록 하는 방법을 공유합니다. 관심 있으신 분들 읽어보시면 좋겠습니다 ! 바로가기

더 많은 AWS ML Weekly Updates 리스트

[2022-07-02] AWS ML Weekly Updates

you gyoung-yoon — Tue, 23 Aug 2022 17:30:00 +0000

2022-07-02 업데이트 전달 드립니다 !

커스텀 컨테이너 이미지를 사용하여 RStudio on Amazon SageMaker에 자체 개발 환경 구성하기 블로그 글 소개

Amazon SageMaker의 RStudio는 업계 최초의 클라우드 기반 완전 관리형 RStudio Workbench입니다. 친숙한 RStudio 통합 개발 환경(IDE)을 빠르게 시작하고 작업을 중단하지 않으면서 기본 컴퓨팅 리소스를 조정할 수 있기 때문에 R기반의 머신 러닝 및 대규모 분석 환경을 쉽게 구축할 수 있습니다. SageMaker RStudio는 이미 R 프로그래밍 및 Data Science 툴을 미리 구성된 컨테이너 이미지와 함께 제공합니다. 그러나 종종 IDE 환경을 커스텀 정의해야 합니다. 이제부터 원하는 패키지 및 도구를 사용하여 특정 사용자 커스텀 이미지를 가져와서 클릭 몇 번으로 SageMaker의 모든 RStudio 사용자가 사용할 수 있도록 할 수 있습니다.

바로가기

AWS AI 및 ML 서비스를 사용하여 시각 또는 의사 소통이 불편한 분들의 접근성 개선하기 블로그 글 소개

멋진 글이 올라왔네요. AWS는 ML 관련 경험이 없는 개발자를 위해 미리 훈련된 바로 사용할 수 있는 광범위한 인공 지능(AI) 및 기계 학습(ML) 서비스를 제공합니다. 이번 블로그 글에서는 AWS의 인공지능 및 기계학습 서비스를 사용하여 시각 장애 또는 의사 소통 장애가 있는 사람들이 사용하기 편리한 애플리케이션을 구축하는 방법을 소개합니다. Amazon Transcribe, Amazon Polly, Amazon Translate, Amazon Rekognition 및 Amazon Textract와 같은 서비스를 사용하면 라이브 텍스트 기록, 텍스트 음성 변환, 번역, 객체 감지, 이미지에서 텍스트 추출과 같은 기능을 서비스에 손쉽게 추가할 수 있습니다.

바로가기

더 많은 AWS ML Weekly Updates 리스트

AWS ML Weekly Updates

you gyoung-yoon — Mon, 22 Aug 2022 18:04:00 +0000

안녕하세요. AWS Machine Learning Community Builder 유경윤 입니다.
AWS ML 관련해서 주간 업데이트를 전달 드립니다 !

2022-09-12

Amazon SageMaker JumpStart 소개

Amazon SageMaker JumpStart Virtual Workshop 소개

Amazon SageMaker Autopilot Virtual Workshop 소개

Machine Learning Engineering on AWS 책 소개

Amazon SageMaker에서 GPT등 대형 모델 서빙 할 수 있는 볼륨과 타임아웃을 구성 지원

기타 관심가는 서비스 업데이트 소개

AWS Glue Crawler history 제공

Amazon DynamoDB에서 트랜잭션당 최대 100개의 작업을 지원

Amazon RDS, AWS Lambda, AWS Step Functions, Amazon Managed Prometheus 및 AWS KMS용 AWS Controllers for Kubernetes (ACK) 일반 공개

Amazon Kinesis Data Analytics for Apache Flink 에 신규 컨테이너 메트릭 지원

2022-09-05

AWS Developers Podcast를 소개

AWS에서 최신 데이터 스트리밍 아키텍처 구축 백서 소개

AWS Glue 모범 사례: 성능이 뛰어나고 비용 최적화된 데이터 파이프라인 구축 백서 소개

Amazon SageMaker Autopilot에서 이제 사용자 지정 데이터 분할 옵션을 제공

Amazon QuickSight Q에서 질문 작성자는 이제 Q가 답변하지 않은 질문을 식별하거나 답변을 생성하기 위해 사용자 명확성을 요구할 수 있음

기타 관심가는 서비스 업데이트 소개

EC2 인스턴스에 부착된 여러 EBS 볼륨중 일부만 스냅샷 생성하는 기능 추가

이제 Amazon Managed Service for Prometheus Alert Manager & Ruler logs를 Amazon CloudWatch Logs에서 사용 가능

2022-08-29

SageMaker hands-on Tutorials 소개

AWS에서 머신러닝으로 고객이 관심있는 제품 타겟팅하기 블로그 글 소개

Machine Learning with Amazon SageMaker Cookbook 책 소개

기타 관심가는 서비스 업데이트 소개

DynamoDB 새로운 테이블 데이터를 S3에서 대량 가져오기 지원

Amazon MSK Serverless 블로그 글 소개

AWS Lambda, 이제 Amazon MSK및 자체 관리형 Kafka를 이벤트 소스로 지원

2022-08-22

CodeWhisperer에게 코드 추천 받으면서 Python Serverless application 만들기 영상 소개

SageMaker 사용하여 Real-Time 머신러닝 모델 서빙 배포하고 엔드포인트 만드는 튜토리얼 소개

AI Use Case Explorer 소개

2022-07-09

Machine Learning University 소개

What is OpenSearch?

Amazon Data Wrangler 및 SageMaker Autopilot을 통한 통합 데이터 준비 및 모델 훈련 블로그 글 소개

Weight & Biases를 사용하여 ML 개발자 생산성 향상시키키: Amazon SageMaker의 컴퓨터 비전 예제 블로그 글 소개

2022-07-02

커스텀 컨테이너 이미지를 사용하여 RStudio on Amazon SageMaker에 자체 개발 환경 구성하기 블로그 글 소개

AWS AI 및 ML 서비스를 사용하여 시각 또는 의사 소통이 불편한 분들의 접근성 개선하기 블로그 글 소개

2022-06-25

SageMaker Fridays를 소개

Hugging Face의 모델과 Amazon SageMaker를 사용하여 텍스트 요약 블로그 공개

ML School on Twitch 소개

[2022-06-25] AWS ML Weekly Updates

you gyoung-yoon — Mon, 22 Aug 2022 18:03:00 +0000

2022-06-25 업데이트 전달 드립니다 !

SageMaker Fridays를 소개

4월 ~ 10월 매달 마지막 금요일에 SageMaker 관련 소통 가능한 세션이 열립니다. 데이터 과학자, ML 엔지니어, 비지니스 분석가 분들이 빠르게 SageMaker에 익숙해지고, 어떻게 정확한 예측을 만들어낼 수 있는지 설명한다고 하네요. 이미 지난 세션도 다시보기 가능하네요. 바로가기

주제 목록도 남겨 봅니다 ! 진짜 흥미로운 주제가 많네요. 꼭 한번 봐야겠습니다. ~!!

3월 - Easily build, train, and deploy an ML model
4월 - Low-Code ML
5월 - Train large deep learning models with hundreds of billions of parameters
6월 - Automate ML workflows
7월 - Learn ML for free
8월 - Generate accurate ML predictions without writing code
9월 - Deploy an ML model for best performance, cost, and prediction quality
10월 - Accelerate deep learning model development with cloud custom environments

Hugging Face의 모델과 Amazon SageMaker를 사용하여 텍스트 요약 블로그 공개

Hugging Face에서 제공하는 모델과 Amazon SageMaker를 사용하여 텍스트 요약
하기 블로그 포스트 공개 되었네요. 아주 자세하게 설명되어 있네요. 이 주제에 관심이 있으셨던 분들은 읽어보시면 좋을 것 같습니다. 바로가기

ML School on Twitch 소개

ML School on Twitch 프로그램은 데이터 과학이나 머신러링 관련 배경지식이 없는 분들에게 실용적이 AI 기술을 소개하는 프로그램이라고 하네요. 트위치에서 영어로 대화하는 형식이고, 강의당 1시간 정도로 구성되어 있네요. 관심있으신 분들 살펴 보시길 바랍니다 ! 바로가기

더 많은 AWS ML Weekly Updates 리스트

실시간(Real-time) 머신 러닝: challenges and solutions

you gyoung-yoon — Sat, 12 Feb 2022 12:47:54 +0000

원문: Real-time machine learning: challenges and solutions
원글: January 2, 2022 9:00 AM
번역: January 23, 2022

요약 🔗

Online Prediction 향하는 단계 설명
- 1단계 Batch prediction: 예측 결과를 저장하고 서빙
- 2단계 Batch features + Online Prediction: item의 임베딩을 미리 생성하고, 이벤트가 발생하면 해당 이벤트의 임베딩을 조회하고 모델 입력으로 사용하여 실시간 예측 실행(=Session Based 예측)
- 3단계 Complex streaming + batch features를 사용한 Online prediction: 미리 계산된 Batch feature(ex, 과거 이 식당의 평균 준비 시간 )와 실시간으로 변하는 스트리밍 데이터(ex, 이 순간 얼마나 많은 다른 주문이 있는지)를 활용하여 온라인 예측 실행
Bandits을 사용하면 AB Test보다 더 효율적으로 온라인 모델을 평가 할 수 있음
Continual Learning으로 향하는 단계 설명
- 1단계 Manual, Stateless Retraining: 수동으로 모델을 처음부터 다시 학습
- 2단계 Automated Retraining: 고정된 일정(개발자 직감으로 설정) + 자동 + 모델을 처음부터 다시 학습
- 3단계 Automated, Stateful Training: 고정된 일정(개발자 직감으로 설정) + 자동 + 신규 데이터만 모델을 이어서 학습
- 4단계 Continual Learning: 모델 성능이 저하 되거나, 데이터 분포 변화가 확인되면 자동으로 신규 데이터만 모델을 이어서 학습 (모델 학습 트리거 메커니즘 개선)
Log and wait (Feature Reuse) 서빙 입력에 사용한 데이터를 저장해서 훈련에서 다시 사용하는 방식
Stream processing 와 Batch processing의 효율성 비교
- 스트림 처리의 강점은 stateful, continuous 및 unbounded data processing에 있음. 적절하게 사용하면 Stateless Batch 처리에 비해 비용이 적게 드는 경우가 있음
- 단, 스트림 처리는 대규모 bounded data 처리에 최적화되어 있지 않으며 대용량 historical 데이터 처리(예: backfill)에서는 성능이 현저히 떨어짐

[ 트위터 토론 , LinkedIn ]

1년 전 저는 머신 러닝이 실시간으로 진행 되는 방식에 대한 게시물을 작성했습니다. 이 게시물은 많은 데이터 과학자들의 고충을 포착했을 것입니다. 게시물 이후에 많은 회사들이 저에게 연락하여 고충을 공유하고 파이프라인을 실시간으로 이전하는 방법에 대해 논의했기 때문입니다. 이러한 대화를 통해 저는 실시간 머신 러닝 기반 회사를 시작하게 되었습니다. 여러분과 공유하고 싶은 흥미진진한 소식이 있습니다. 하지만 그건 다른 시간을 위한 이야기입니다 :-)
작년에 저는 다양한 산업 분야의 ~30개 회사와 실시간 머신 러닝의 문제점에 대해 이야기했습니다. 또한, 저는 해결책을 찾기 위해 꽤 많은 사람들과 협력했습니다. 이 게시물은 (1) 온라인 예측 및 (2) 지속적인 학습을 위한 솔루션을 설명하며 각 레벨에 필요한 단계별 사용 사례, 고려 사항 및 기술을 제공합니다.

경험에 따라 일부 단계는 기본적으로 보일 수 있습니다. 건너뛰어도 괜찮습니다 !

또한, 보다 정확한 관점을 위해 귀사의 ML 워크플로에 대해 자세히 알고 싶습니다. 다음은 5분 설문조사 링크 입니다. 결과는 집계후 요약되어 커뮤니티와 공유됩니다. 감사합니다!

Online Prediction을 향하여 🔗

Continual learning이 주류로 채택되기까지는 아직 몇 년이 남았다고 생각하지만 온라인 추론으로 전환하기 위해 기업에서 상당한 투자를 하고 있습니다. 이 글에서 우리는 배치 피쳐를 사용하는 심플한 온라인 시스템을 위해서 어떤 것들이 필요한지 논의할 것 입니다. (e.g. 웹사이트나 모바일 앱에서 유저 활동 내역을 기반한 유저 예측 제공). 그런 다음 복잡한 스트리밍 + Batch 피쳐 모두를 활용하는 보다 성숙한 온라인 예측 시스템으로 이동하는 방법에 대해 계속 논의할 것입니다.

1단계. Batch prediction 🔗

이 단계에서 모든 예측은 Batch 처리로 미리 계산되어 특정 간격(예: 4시간마다 또는 매일)마다 생성됩니다. Batch 예측의 일반적인 사용 사례는 collaborative filtering, content-based 추천입니다. Batch 예측을 사용하는 회사의 예시로는 DoorDash의 레스토랑 추천, Reddit의 서브레딧 추천, 2021년경 Netflix의 추천 시스템 등이 있습니다. 이 게시물을 기준으로 Netflix는 예측을 온라인으로 옮기고 있습니다.

Batch 예측에는 이전 게시물에 설명된 대로 많은 제한 사항이 있습니다. 여기에서 한 가지 예를 빠르게 살펴보고자 합니다. 방문자의 절반이 신규 사용자이거나 로그인하지 않는 e-커머스 사이트라고 생각해보세요. 이러한 방문자들은 신규 방문자이기 때문에 미리 계산된 개인화 추천 결과가 없습니다. 다음 추천 Batch가 생성될 때 이 신규 방문자는 관련 항목을 찾지 못했기 때문에 구매하지 않고 이미 떠났을 수 있습니다.

일반적인 Batch 예측 워크플로

Batch 예측은 온라인 예측의 전제 조건이 아닙니다. Batch 예측은 대부분 레거시 시스템의 산물입니다.

지난 10년 동안 빅 데이터 처리는 MapReduce 및 Spark와 같은 Batch 시스템에 의해 지배되었으며, 이를 통해 대량의 데이터를 매우 효율적으로 주기적으로 처리할 수 있습니다. 기업에서 기계 학습을 시작할 때 기존 Batch 시스템을 활용하여 예측을 수행했습니다.

💡 지금 새로운 ML 시스템을 구축하고 있다면 온라인 예측으로 바로 시작할 수 있습니다.

2단계. Batch features 사용한 Online Prediction 🔗

이 단계의 회사는 요청이 도착하기 전에 예측을 생성하는 대신 요청이 도착한 후에 예측을 생성합니다. 그들은 앱에서 실시간으로 사용자의 활동을 수집합니다. 그러나 이러한 이벤트는 세션 임베딩을 생성하기 위해 미리 계산된 임베딩을 조회하는 데만 사용됩니다. 스트리밍 데이터에서 실시간으로 계산되는 피쳐는 없습니다.

이전 단계의 동일한 e-커머스 웹사이트 예시를 생각하십시오. 새로운 방문자가 웹사이트를 방문하면 모두에게 일반적인 항목을 제안하는 대신 사용자의 활동을 기반으로 항목을 표시한다면 어떻겠습니까? 예를 들어, 키보드와 컴퓨터 모니터를 본 적이 있다면 재택근무 환경 셋팅을 보고 있을 가능성이 높으므로, 알고리즘은 HDMI 케이블이나 모니터 받침대와 같은 관련된 항목을 추천해야 합니다.

그렇게 하려면 이 방문자의 활동이 발생하는 대로 수집하고 처리해야 합니다. 이 방문자가 항목 1, 항목 10 및 항목 20을 본 경우 데이터 웨어하우스에서 항목 1, 10 및 20에 대한 임베딩을 가져옵니다. 이 임베딩들은 결합(예: 평균)되어 이 방문자의 현재 세션 임베딩이 됩니다.

이 세션 임베딩과 가장 관련성이 높은 아이템을 찾고 싶습니다. 단순하게(Naively) 사이트에 있는 모든 항목의 순위(ranking)를 지정하고 방문자에게 가장 높은 점수를 받은 항목을 표시하는 모델을 만들 수 있습니다. 그러나 사이트에 수백만 개의 항목이 있을 수 있고, 모든 항목의 점수를 매기는 데 너무 오래 걸릴 수 있습니다. 나는 방문자가 추천을 보기 위해 영원히 기다리지 않기를 바랍니다. 대부분의 회사는 item-item collaborative filtering 및 k-nearest neighbors과 같은 다른 알고리즘을 사용하여 점수를 매길 소수의 후보(candidate) 항목(예: 1000개)을 생성합니다. 이러한 후보 항목 생성 프로세스를 "candidate generation" 또는 "retrieval"이라고 합니다. 관심 있는 독자는 Eugene Yan의 session-based recommendations 와 Google’s free crash course를 확인하십시오.

세션 기반 추천을 위한 예시 파이프라인

item 임베딩은 랭킹 모델과 별도로 또는 함께 학습할 수 있습니다. 개별적인 경우 시스템은 임베딩 학습용, 검색용, 랭킹용등 3개 이상의 모델로 구성됩니다.

여기에서 온라인 예측 2단계를 설명하기 위해 추천 시스템을 예로 들었지만, 광고 CTR, 모든 검색 작업을 포함한 다른 작업에도 적용될 수 있습니다.

세션 기반 예측의 목표는 전환(conversion, 예: 최초 방문자를 신규 사용자로 전환) 클릭률 및 리텐션을 높이는 것 입니다.

Netflix, YouTube, Roblox, Coveo 등을 포함하여 이미 온라인 추론을 수행 중이거나 2022년 로드맵에 온라인 추론을 포함한 회사가 늘어나고 있습니다. Online Inference를 적용한 모든 회사에서 나에게 기존 메트릭보다 좋아졌다고, 나에게 행복하게 말했습니다. 나는 앞으로 2년 동안 대부분의 추천 시스템이 session-based가 될 것으로 예상합니다. 모든 클릭, 뷰, 거래는 (거의) 실시간으로 신선(fresh)하고 관련성 있는 추천을 생성하는 데 사용될 수 있습니다.

요구 사항

이 단계에서는 다음을 수행해야 합니다.

Batch 예측에서 Session-based 예측으로 모델을 업데이트

새 모델을 추가해야 할 수도 있음을 의미합니다. 담당 팀: 데이터 과학/ML.
Session 데이터를 Prediction 서비스에 적용

일반적으로 다음 두 가지 요소로 구성된 스트리밍 인프라를 사용하여 이 작업을 수행할 수 있습니다.
- 스트리밍 전송 (예: Kafka/AWS Kinesis/GCP Dataflow), 스트리밍 데이터(사용자 활동 정보)를 전송(transfort). 대부분의 회사는 관리형 실시간 전송 서비스를 사용합니다. 자체적으로 Kafka를 서비스 하는 것은 매우 어렵습니다.
- 스트리밍 계산(computation) 엔진 (예: Flink SQL, KSQL, Spark Streaming), 스트리밍 데이터 처리(Processing). In-session adaption 경우 스트리밍 계산 엔진은 사용자의 활동을 세션으로 나누고, 각 세션 내에서 정보를 추적하는 역할을 합니다(State keeping; 상태 유지). 앞서 언급된 세 가지 스트리밍 계산 엔진 중 Flink SQL과 KSQL은 업계에서 더 인정받고 있으며 데이터 과학자에게 멋진 SQL 추상화를 제공합니다.

많은 사람들은 예측을 Batch으로 처리하는 것이 예측을 하나씩 처리하는 것보다 효율적이기 때문에 Online 예측이 Batch 예측보다 비용 및 성능 면에서 비효율 적이라고 생각합니다. 이것은 이 글의 부록에서 논의 된 것처럼 반드시 사실은 아닙니다.

온라인 예측을 사용하면 사이트를 방문하지 않는 사용자에 대한 예측을 생성할 필요가 없습니다. 사용자의 2%만 매일 로그인하는 앱을 생각해 보세요. 실제 예를 들어, 2020년에 Grubhub의 사용자는 3,100만 명 이었고 일일 주문 은 622,000 건 이었습니다 .

매일 모든 사용자에 대한 예측을 생성하면 예측의 98%는 계산 낭비가 됩니다.

회사에서 이미 로깅을 위해 스트리밍을 사용하는 경우 이 변경 사항이 너무 급격하게 진행하지 않아야 합니다. 이는 스트리밍 인프라에 더 많은 워크로드를 부과할 수 있으며, 더 효율적이고 확장 가능하도록 인프라를 업그레이드해야 할 수도 있습니다.

담당 팀: 데이터/ML 플랫폼.

**참고 사항 : 내가 이야기한 소수의 사람들은 예측을 위해 스트리밍 인프라를 활용하는 시스템을 지칭하기 위해 "streaming prediction"라고 부르며, 그렇지 않은 시스템을 지칭하기 위해 "online prediction"이라고 합니다. 이 게시물에서 "온라인 예측"은 "스트리밍 예측"을 포함합니다.

Challenges

이 단계의 과제는 다음과 같습니다.

Inference latency

: Batch 예측을 사용하면 추론 지연에 대해 걱정할 필요가 없습니다. 그러나 온라인 예측에서는 Inference latency가 중요합니다.
스트리밍 인프라 셋팅

: 많은 엔지니어들은 스트리밍에 대한 도구가 성숙하고 있음에도 불구하고 스트리밍에서 SQL과 같은 Join을 수행하는 것을 여전히 두려워 합니다.
고품질 임베딩 생성, 특히 다양한 항목의 유형을 다루는 경우

3단계. Complex streaming + batch features를 사용한 Online prediction 🔗

Batch 피쳐는 Batch 처리를 통해 과거 데이터에서 추출된 피쳐입니다. 정적(Static) 피쳐 또는 기록(historical) 피쳐이라고도 합니다.
Streaming 피쳐는 스트리밍 데이터에서 추출한 피쳐로, 종종 스트림 처리(processing)을 사용합니다. 동적(Dynamic) 피쳐 또는 온라인 피쳐 라고도 합니다.

2단계에 있는 회사는 스트림 처리가 거의 필요하지 않지만, 3단계의 회사는 훨씬 더 많은 스트리밍 피쳐을 사용합니다. 예를 들어, Doordash에서는 사용자 주문한 후, 배달 시간을 예측(estimate)하기 위해 다음 피쳐가 필요할 것 입니다.

Batch features: 과거 이 식당의 평균 준비 시간
Streaming features: 이 순간, 얼마나 많은 다른 주문이 있는지, 얼마나 많은 배달 사람이 사용 가능한지

2단계에서 논의한 session-based 추천의 경우, 3단계에서는 item 임베딩만 사용하여 세션 임베딩을 생성하는 대신, 사용자가 지난 24시간 동안 사이트에서 보낸 활동 시간, 항목 구매 횟수와 같은 스트림 피쳐를 사용할 수 있습니다.

스트리밍 피쳐 및 Batch 피쳐을 통한 온라인 예측

Stripe, Uber, Faire 같은 회사들의 사기 감지, 신용 점수 예측, 운전 및 배달 시간 추정, 추천 시스템 등이 3단계의 대표적인 사용 예시 입니다.

각 예측에 대한 스트림 피쳐의 수는 수천은 아니더라도 수백이 될 수 있습니다. 스트림 피쳐 추출 로직에는 서로 다른 차원(dimensions)을 따라 join 및 aggregation이 포함된 복잡한 쿼리가 필요할 수 있습니다. 이러한 피쳐을 추출 하려면 효율적인 스트림 처리 엔진이 필요합니다.

요구 사항

ML 워크플로를 이 단계로 이동하려면 다음 요소가 필요합니다.

모든 스트리밍 피쳐을 허용 가능한 지연 시간(acceptable latency)안에 계산할 수 있는 효율적인 스트림 처리 엔진을 갖춘 성숙한 스트리밍 인프라. 다음 요청이 도착하기 전에, 스트리밍에서 요청을 받아와 예측을 충분히 빠르게 처리할 수 있어야 합니다.
피쳐 저장소(feature store) 구체화된(materialized) 피쳐 관리를 통해 훈련 및 예측 동안 스트리밍 피쳐 일관성 보장해야 합니다. 참고: 현재 피쳐 저장소는 구체화된 스트리밍 피쳐을 관리하지만 피쳐 계산이나 피쳐에 대한 소스 코드는 관리하지 않습니다 .
모델 저장소. 스트림 피쳐를 만든 후에는 유효성 검사를 해야 합니다. 새 피쳐가 실제로 모델의 성능에 도움이 되도록 하려면 새 피쳐를 모델에 추가하여 새 모델을 효율적으로 생성해야 합니다. 이상적으로는 모델 저장소가 새로운 스트리밍 피쳐로 생성된 모델을 관리하고 평가하는 데 도움이 되어야 하지만 모델을 평가하는 모델 저장소는 아직 존재하지 않습니다. 이 중 일부 역할을 피쳐 저장소에 잠재적으로 위임할 수 있습니다.
더 나은 개발 환경을 선호합니다. 데이터 과학자는 현재 스트리밍 피쳐가 생성되고 있음에도 과거(historical) 데이터를 사용하여 일하고 있다면, 새로운 스트리밍 피쳐을 제안하고 검증하기가 어렵습니다. 데이터 과학자들이 새로운 스트림 피쳐를 사용하여 빠르게 실험하고 검증할 수 있도록 데이터 스트림에 대한 직접 액세스 권한을 부여할 수 있다면 어떨까요? 데이터 과학자가 과거 데이터에만 액세스하는 대신 노트북에 바로 들어오는 데이터 스트림에도 액세스할 수 있다면 어떨까요?

토론: bandits 과 contextual bandits에 대한 온라인 예측 🔗

온라인 예측을 사용하면 모델이 보다 정확한 예측을 할 수 있을 뿐만 아니라 온라인 모델 평가 및 예측 생성을 위한 탐색 전략을 위한 bandits를 사용할 수 있습니다. 이는 A/B 테스팅보다 더 흥미롭고 강력합니다.

이러한 익숙하지 않은 bandit 알고리즘은 도박에서 시작되었습니다. 카지노에는 지불금이 다른 여러 슬롯 머신이 있습니다. 슬롯 머신은 one-armed bandit으로도 알려져 있으므로 여기서 이름을 따왔습니다. 어떤 슬롯 머신이 가장 높은 지불금을 제공하는지 모릅니다. 당신은 지불금을 최대화려면 어떤 슬롯 머신이 가장 좋은지 알아보기 위해 시간이 지남에 따라 실험할 수 있습니다.

Multi-armed bandits는 exploitation(과거에 가장 많은 비용을 지불한 슬롯 머신 선택)과 exploration(더 많은 비용을 지불할 수 있는 다른 슬롯 머신 탐색) 사이의 균형을 맞출 수 있는 알고리즘입니다.

모델 평가를 위한 Bandits 🔗

현재 업계의 온라인 모델 평가 기준은 A/B 테스팅입니다. A/B 테스트는 예측을 위해 트래픽을 각 모델에 무작위로 라우팅하고, 어떤 모델이 더 잘 작동하는지 측정합니다.

A/B 테스트는 stateless 입니다. 현재 성능에 대해 알 필요 없이 각 모델에 트래픽을 라우팅 합니다. Batch 예측으로도 A/B 테스팅을 할 수 있습니다.

평가할 모델이 여러 개인 경우 각 모델은 지불금(payout, 예: 예측 정확도)이 얼마인지 모르는 상태의 슬롯 머신으로 간주할 수 있습니다. Bandits를 사용하면 사용자에게 표시되는 잘못된 예측을 최소화하면서 최상의 모델을 결정하기 위해 어떻게 트래픽을 각 모델로 라우팅 해야할지 결정할 수 있습니다.

Bandits는 stateful입니다. 요청을 모델로 라우팅하기 전에 모든 모델의 현재 성능을 계산해야 합니다.

Bandits은 학계에서 잘 연구되었으며 A/B 테스트보다 데이터 효율성이 훨씬 높은 것으로 나타났습니다. 많은 경우에 Bandits은 최적의 방법이기도 합니다.

Bandits은 어떤 모델이 가장 좋은지 결정하는 데 필요한 데이터가 적으며, 동시에 트래픽을 더 나은 모델로 더 빠르게 라우팅하므로 기회 비용이 줄어듭니다.

구글의 Greg Rafferty의 이 실험에서 A/B 테스트는 630,000개의 필요한 샘플을 통해 95%의 신뢰 구간을 얻을 수 있었습니다 . 그러나 간단한 Bandits 알고리즘 (톰슨 샘플링)은 특정 모델이 다른 모델보다 5% 더 나은 것을 결정하는데 12,000개 이하의 샘플이 필요했습니다.

LinkedIn, Netflix, Facebook, Dropbox 및 Stitch Fix의 Bandits에 대한 토론을 참조하세요. 보다 이론적인 관점은 강화 학습 책 (Sutton & Barton, 2020)의 2장을 참조하십시오.

요구 사항

모델 평가를 위해 bandits를 수행하려면 시스템에서 다음 세 가지 요구 사항이 필요합니다.

온라인 예측
짧은 피드백 루프를 선호합니다. 모델의 현재 성능을 계산하려면 모델의 예측이 좋은지 아닌지에 대한 피드백을 받아야 합니다. 피드백은 예측을 위한 레이블을 추출하는 데 사용됩니다.

짧은 피드백 루프가 있는 작업의 예는 추천 시스템과 같이 사용자의 피드백에서 레이블을 결정할 수 있는 작업입니다. 사용자가 추천을 클릭하면 좋은 추천 예측입니다. 피드백 루프가 짧으면 각 모델의 성능을 빠르게 업데이트할 수 있습니다. 루프가 길어도 여전히 Bandits을 할 수 있지만 사용자에게 추천을 한후 모델의 성능을 업데이트하는 데 시간이 더 오래 걸립니다.
피드백을 수집하고, 각 모델의 성능을 계산 및 추적하고, 현재 성능을 기반으로 다른 모델로 예측 요청을 라우팅하는 메커니즘입니다.

이러한 요구 사항 때문에 밴딧은 A/B 테스트보다 구현하기가 훨씬 더 어렵습니다. 따라서 산업에서는 일부 대형 기술 회사 이외에 널리 사용 되지는 않습니다.

탐색 전략(Exploration Strategy)으로서의 Contextual(상황별) Bandits 🔗

모델 평가를 위한 Bandit의 경우 각 모델의 지불금(payout, 예: 예측 정확도)을 결정하지만, Contextual Bandits은 각 액션의 지불금을 결정합니다. 추천의 경우 액션은 사용자에게 보여줄 항목이고 지불금은 사용자가 클릭할 가능성입니다.

면책 조항 : 일부 사람들은 모델 평가를 위해 bandits를 "contextual bandits"라고 부르기도 합니다. 이것은 대화를 혼란스럽게 만들 수 있으므로 이 글에서의 Contextual *Bandits은 예측의 지불금을 결정하기 위한 탐색 전략을 말합니다.*

이를 설명하기 위해 10,000개 항목에 대한 추천 시스템을 고려하십시오. 매번 사용자에게 10개의 항목을 추천할 수 있습니다. 10개의 표시된 항목은 사용자의 피드백을 받습니다(클릭 여부). 그러나 다른 9,990개 항목에 대한 피드백은 받지 못했습니다.

사용자에게 클릭할 가능성이 가장 높은 항목만 계속 표시한다면, 인기 있는 항목만 표시하고 덜 인기 있는 항목에 대해서는 피드백을 받지 못하는 피드백 루프에 빠질 것 입니다.

Contextual Bandits은 상황별(context) 정보를 활용하여 사용자에게 그들이 좋아할 항목을 노출하는 것(exploitation)과 아직 많이 알지 못하는 항목을 표시하는 것(exploration) 사이의 균형을 유지하면서 차선책 액션의 비용을 최소화합니다.

Contextual bandits은 잘 연구되었으며 모델의 성능을 크게 향상시키는 것으로 나타났습니다(Twitter, Google 보고서 참조). 그러나, 탐색(exploration) 전략은 ML 모델의 아키텍처(예: decision tree인지 neural network인지 여부)에 따라 달라지므로 use-case 전반에 걸쳐 일반화할 수 없기 때문에 contextual bandits은 Model bandits보다 구현하기가 훨씬 더 어렵습니다.

Continual Learning(지속적인 학습)을 향하여 🔗

지속적인 학습을 들을 때 사람들은 5분마다 매우 자주 모델을 업데이트하는 것을 상상합니다. 많은 사람들은 다음과 같은 이유로 대부분의 회사에서는 모델 업데이트를 자주 할 필요없다고 주장합니다.

그들은 retraining 스케쥴링이 필요를 이해할 수 있는 트래픽이 없습니다.
그들의 모델은 그렇게 빨리 성능 저하(decay)되지 않습니다.

나는 그들에게 동의합니다. 그러나 Continual Learning은 재훈련 빈도가 아니라 모델이 재훈련되는 방식(manner)에 관한 것 입니다.

대부분의 회사에서는 stateless retraining을 수행 합니다. 모델은 매번 처음부터 훈련됩니다. 지속적인 학습은 stateful training을 ****허용하는 것을 의미 합니다. 모델은 새 데이터에 대해서만 훈련을 이어서 합니다 (fine-tuning).

한번 stateful training을 수행하도록 인프라가 설정되면 교육 빈도는 간단히 수정하면 됩니다. 한 시간에 한 번, 하루에 한 번 모델을 업데이트하거나 시스템이 분포 이동을 감지할 때마다 모델을 업데이트할 수 있습니다.

모델 업데이트에는 두 가지 유형이 있습니다.

Model iteration

: 기존 모델 아키텍처에 새로운 피쳐을 추가하거나 모델 아키텍처를 변경합니다.
Data iteration

: 동일한 모델 아키텍처 및 피쳐이지만 새로운 데이터를 훈련 해야합니다.

현재 stateful training은 Data iteration을 의미합니다. 모델 아키텍처를 변경하거나 새 피쳐을 추가하는 경우에는 새 모델을 처음부터 교육해야 합니다. 모델 아키텍쳐가 변경되도 Continual Learning을 할 수 있는 흥미로운 연구도 있습니다. knowledge transfer (구글, 2015) 및 model surgery (OpenAI 2019) : "모델의 어떤 부분이 변경되지 않고 어떤 부분을 다시 초기화해야 하는지 결정하기 위해 선택한 후에 한 Network에서 다른 Network로 훈련된 가중치를 이전(transfer)합니다.” 몇몇의 거대한 연구실에서 이를 실험했습니다만, 저는 업계의 명확한 결과를 알지는 못합니다.

Manual retraining으로 시작하는 첫 번째 단계는 재훈련 프로세스를 자동화하는 것 입니다. 그런 다음 stateless retraining에서 stateful training으로 이동합니다. 마지막으로 continual learning에 대해 논의할 것입니다.

1단계. Manual, Stateless Retraining 🔗

처음에 ML팀은 사기 탐지, 추천, 배송 추정 등 가능한 한 많은 비즈니스 문제를 해결하기 위해 ML 모델을 개발하는 데 중점을 둡니다. 팀이 새 모델 개발에 집중하고 있기 때문에 기존 모델 업데이트는 뒷전입니다. 다음 경우에만 기존 모델을 업데이트합니다.

모델의 성능이 득보다 실이 많을 정도로 저하되었습니다.
팀에서 모델을 업데이트할 시간이 있습니다.

일부 모델은 6개월에 한 번씩 업데이트 됩니다. 일부는 분기별로 업데이트됩니다. 일부는 1년 동안 야생에 있었고 전혀 업데이트되지 않았습니다.

모델 업데이트 프로세스는 수동이며 임시입니다. 일반적으로 데이터 플랫폼 팀의 누군가가 데이터 웨어하우스에 새 데이터를 쿼리합니다. 다른 누군가가 이 새 데이터를 정리하고, 그 데이터에서 피쳐을 추출하고, 이전 데이터와 새 데이터 모두 사용하여 처음부터 해당 모델을 다시 학습시킨 다음, 업데이트된 모델을 바이너리 형식으로 내보냅니다. 그런 다음 다른 사람이 해당 바이너리 형식의 업데이트된 모델을 배포합니다. 종종 피쳐/모델/처리 코드는 모델 재학습 중에 수정 되지만 변경 사항이 프로덕션에서 복제(replicated)되지 않아 추적하기 어려운 버그가 발생합니다.

이 과정이 당신에게 고통스럽게 들린다면, 당신은 혼자가 아닙니다. 기술 산업 외부의 대다수 회사(예: ML을 도입한 지 3년 미만이고 ML 플랫폼 팀이 없는 회사)가 이 단계에 있습니다.

2단계. Automated Retraining 🔗

임시 방식으로 수동으로 모델을 재훈련하는 대신 재훈련 프로세스를 자동으로 실행하는 스크립트가 있습니다. 이것은 일반적으로 Spark와 같은 Batch 프로세스에서 수행됩니다.

어느 정도 성숙한 ML 인프라를 갖춘 대부분의 회사가 이 단계에 있습니다. 일부 정교한 회사는 최적의 재훈련 빈도를 결정하기 위해 실험을 실행합니다. 그러나 대부분의 회사에서 재교육 빈도는 직감에 따라 설정됩니다(예: "하루에 한 번 정도가 적당할 것 같습니다." 또는 "매일 밤 유휴 컴퓨팅이 있을 때 재훈련 프로세스를 시작합시다.").

파이프라인의 서로 다른 모델에는 각각의 재훈련 스케쥴이 필요할 수 있습니다.

위의 session-based 추천의 경우 임베딩 모델이 랭킹 모델과 별개인 경우 임베딩 모델은 랭킹 모델보다 훨씬 적은 빈도로 재학습해야 할 수도 있습니다. 예를 들어, 임베딩을 일주일에 한 번 재교육하고, 하루에 한 번 랭킹 모델을 재교육할 수 있습니다. 임베딩을 학습해야 하는 새로운 항목이 매일 많다면 이야기가 달라집니다.

모델 간에 종속성이 있으면 상황이 훨씬 더 복잡해집니다. 예를 들어, 임베딩이 변경되면 랭킹 모델이 임베딩에 따라 달라지므로 랭킹 모델도 업데이트해야 합니다.

요구 사항

회사에 프로덕션 환경에 ML 모델이 있는 경우 자동화된 재훈련에 필요한 대부분의 인프라가 이미 회사에 있을 수 있습니다. 아직 없는 경우 필요한 유일한 새 조각은 모델을 재현하는 데 필요한 모든 코드/아티팩트를 자동으로 버전화하고 저장하는 모델 저장소 입니다.

가장 간단한 모델 저장소는 아마도 구조화된 방식으로 직렬화된 모델 Blob을 저장하는 S3 버킷일 것입니다. 좀 더 성숙한 모델 스토어를 원하신다면 제가 자주 듣는 솔루션은 SageMaker(관리형 서비스)와 MLFlow(오픈 소스)입니다. SageMaker는 사용하기 더 어렵고 모델의 코드와 아티팩트를 저장하지 않습니다. MLFlow는 오픈 소스이며 더 많은 피쳐가 있지만 본인의 ML플랫폼에 특이사항(quirks)이 많은 경우 작동하기 어려울 수 있습니다.

워크플로를 자동화하는 스크립트를 작성하고 데이터를 자동으로 샘플링하고, 피쳐를 추출하고, 재훈련을 위해 레이블을 처리도록 인프라를 구성해야 합니다. 이 프로세스에서 소요되는 시간은 여러 요인에 따라 다르지만 다음은 두 가지 주요 요인입니다.

스케줄러. Airflow, Argo와 같은 CRON 스케줄러가 이미 있는 경우 스크립트를 함께 연결하는 것이 그렇게 어렵지 않을 것입니다.
데이터 액세스 및 가용성. 필요한 모든 데이터가 이미 데이터 웨어하우스에 수집되어 있습니까? 여러 조직의 데이터를 결합해야 합니까? 처음부터 많은 테이블을 만들어야 합니까? Stitch Fix의 ML/데이터 플랫폼 관리자인 Stefan Krawczyk은 대부분의 사람들이 이곳에서 많은 시간을 보내고 있을 수도 있다고 생각한다고 말했습니다.

Bonus: Log and wait (feature reuse) 🔗

새 데이터에 대해 모델을 재학습할 때 새 데이터가 이미 예측 서비스를 거쳤을 가능성이 있습니다. 즉, 예측을 위해 특성이 이미 한 번 추출되었음을 의미합니다. 일부 회사는 이러한 추출된 피쳐을 모델 업데이트에 재사용하여 계산을 절약하고 예측과 훈련 간의 일관성을 허용합니다. 이 접근 방식을 log and wait 라고 합니다. 이는 프로덕션 환경과 개발 환경 간의 불일치로 인해 발생하는 버그인 training-serving 편향(Skew)을 줄이기 위한 고전적인 접근 방식입니다.

이것은 아직 대중적인 접근 방식은 아니지만 점점 더 대중화되고 있습니다. 곧 표준이 되리라 기대합니다. Faire는 log and wait 접근 방식의 장단점을 논의 하는 훌륭한 블로그 게시물을 보유하고 있습니다.

3단계. Automated, Stateful Training 🔗

Stateful training은 모델을 처음부터 다시 훈련하는 대신 새 데이터로만 모델을 이어서 훈련할 때 사용한다는 점을 기억하십시오. Stateful retraining을 사용하면 더 적은 데이터로 모델을 업데이트할 수 있습니다. 한 달에 한 번 모델을 업데이트하는 경우 지난 3개월 동안의 데이터에 대해 처음부터 모델을 다시 학습시켜야 할 수 있습니다. 그러나 매일 모델을 업데이트하는 경우 마지막 날의 데이터에 대해서만 모델을 fine-tune 하면 됩니다.

Grubhub는 stateless daily retraining에서 stateful daily retraining으로 전환한 후 훈련 비용을 45배 절감 했습니다 (2021년).

Stateless vs. Stateful 훈련

Incremental learning의 또 다른 좋은 속성은 각 데이터 샘플을 최대 두 번(예측 중에 한 번, 모델 훈련 중에 한 번)만 볼 필요가 있다는 것입니다. 데이터 프라이버시가 걱정된다면 데이터 샘플을 사용한 후 폐기할 수 있습니다.

요구 사항

이 단계에서 가장 필요한 것은 더 좋은 모델 스토어입니다.

Model lineage

: 모델의 버전을 지정하는 것뿐만 아니라 계보(lineage)를 추적하기를 원합니다. 어떤 모델에서 fine-tune 되었는지 확인.
Streaming features reproducibility

: 과거의 스트리밍 피쳐을 추출하기 위해 시간 여행(time-travel)을 할 수 있고 어떤 일이 발생하여 디버그해야 하는 경우 과거의 어느 시점에서든 모델에 대한 훈련 데이터를 다시 생성할 수 있기를 원합니다.

내가 아는 한, 이 두 가지 피쳐을 모두 갖춘 모델 스토어는 없습니다. 스트리밍 피쳐 재현성(reproducibility)을 피쳐 스토어에 위임할 수 있지만 솔루션을 사내에서 구축해야 할 수 있습니다.

4단계. Continual Learning 🔗

내가 노력하고 있고 많은 회사들이 궁극적으로 채택하기를 바라는 것은 Continual Learning 입니다.

고정된 일정에 따라 모델을 업데이트하는 대신 데이터 분포가 변경되고 모델의 성능이 떨어질 때마다 모델을 지속적으로 업데이트 하십시오.

성배는 지속적인 학습과 에지 배포를 결합할 때입니다. 새 장치와 함께 기본 모델을 배송할 수 있고 해당 장치(Ex, phone, watch, drone, etc)의 모델이 계속해서 환경에 맞게 업데이트되고 조정될 것이라고 상상해 보십시오. 중앙 집중식 서버 비용이 없으며 장치와 클라우드 간에 데이터를 주고받을 필요가 없습니다!

요구 사항

3단계에서 4단계로의 전환이 가파릅니다. 다음이 요소들이 필요할 것 입니다.

모델 업데이트를 트리거하는 메커니즘 입니다. 이 트리거는 time-based(예: 5분마다), performance-based(예: 모델 성능이 급락할 때마다) 또는 drift-based(예: 데이터 분포가 이동할 때마다)일 수 있습니다.

오늘날 대부분의 모니터링 솔루션은 피쳐 분석에 중점을 두고 있습니다. 즉, 피쳐의 요약 통계(예: 평균, 분산, 최소값, 최대값)를 분석하고 이러한 통계에서 중요한 변경이 발생하면 알려줍니다. 그러나 모델에는 수천 개 까지는 아니더라도 수백 개의 피쳐가 있을 수 있습니다. 대부분의 피쳐 통계 변경 사항은 무해합니다. 문제는 이러한 변경 사항을 감지하는 방법이 아니라 실제로 주의가 필요한 변경 사항을 아는 방법입니다.
모델을 지속적으로 평가하는 더 나은 방법. 모델을 업데이트하는 함수를 작성하는 것은 3단계에서 하는 것과 크게 다르지 않습니다. 어려운 부분은 업데이트된 모델이 제대로 작동하는지 확인하는 것입니다. 변화하는 환경에 적응하도록 모델을 업데이트하고 있기 때문에 고정 테스트 세트로는 더 이상 충분하지 않습니다. 백테스트, 점진적 평가(progressive evaluation), 섀도 배포를 포함한 프로덕션 테스트인 A/B 테스트, 카나리아 분석 및 bandits을을 고려할 수 있습니다.
기존 예측 서비스를 중단하지 않고 모델을 업데이트하고 평가하기 위해 인스턴스를 자동으로 스핀업하는 오케스트레이터.

결론 🔗

실시간 머신 러닝은 주로 인프라 문제입니다. 이를 해결하려면 DS/ML 팀과 플랫폼 팀이 협력해야 합니다.

Online Prediction과 Continual Learning 모두 성숙한 스트리밍 인프라가 필요합니다. 지속적 학습의 훈련 부분은 Batch로 수행할 수 있지만 온라인 평가 부분은 스트리밍이 필요합니다. 많은 엔지니어들은 스트리밍이 어렵고 비용이 많이 든다고 걱정합니다. 3년 전만 해도 사실이었지만 스트리밍 기술은 그 이후로 눈에 띄게 발전했습니다. Spark Streaming, Snowflake Streaming, Materialize, Decodable, Vectorize 등을 포함하여 기업이 스트리밍으로 쉽게 이동할 수 있도록 하는 솔루션을 점점 더 많은 회사에서 제공하고 있습니다.

업계에서 실시간 ML의 채택과 과제를 더 잘 이해하기 위해 저희 팀과 저는 설문 조사를 진행하고 있습니다. 귀하의 생각을 공유해 주시면 감사하겠습니다. 소요 시간은 약 5분입니다. 결과는 집계되고 요약되어 커뮤니티와 공유됩니다. 감사합니다!

저와 제 팀이 온라인 예측, 온라인 모델 평가 및 자동화된 Stateful training을 어떻게 도울 수 있는지 논의하려면 연락하십시오.

감사의 말 🔗

이 게시물은 워크플로에 대한 내 질문에 매우 인내심 있는 많은 엔지니어 목록의 도움 없이는 불가능했을 것입니다.

또한 Stefan Krawczyk , Zhenzhong Xu , Max Halford , Goku Mohandas , Alex Egg , Jacopo Tagliabue , Luke Metz 의 사려 깊은 의견으로 이 게시물을 개선한 데 에도 감사드립니다 .

Ammar Asmro, Alex Gidiotis, Aditya Soni, Shaosu Liu, Deepanshu Setia, Bonson Sebastian Mampilli, Sean Sheng 및 Daniel Tan에게 설문에 대한 피드백을 주셔서 감사합니다!

부록 🔗

Stream processing 와 Batch processing의 효율성 비교 🔗

전반적인 비용 효율성, 컴퓨팅 성능 효율성, 인재 효율성이라는 세 가지 차원에서 효율성을 비교할 것입니다. 이 사려 깊은 분석에 대해 Zhenzhong Xu에게 감사드립니다!

비용 효율성

불행히도 Stream processing 과 Batch processing 사이에 보편적인 비용 효율성 공식은 없습니다. latency requirement, data size, late arrival tolerance, failure tolerance, statefulness 등과 같은 많은 변수에 따라 달라집니다. 스트림 처리의 강점은 stateful, continuous 및 unbounded data processing에 있습니다. 적절하게 사용하면 Stateless Batch 처리에 비해 비용이 적게 드는 경우가 많습니다. 예를 들어, 30일 평가판 사용 기간 동안 사용자 참여를 스코어링하기 위해 슬라이딩 윈도우를 계산해야 하는 경우 Batch 처리는 매번 Batch에서 30일 분량의 데이터를 다시 계산해야 하는 반면 Stateful streaming workload는 모든 중복 처리를 피할 수 있기 때문에 컴퓨팅 비용이 적게 듭니다. 반면에 매우 큰 데이터셋을 일회성으로 처리하는 경우 Batch가 여전히 최고의 선택이 될 것 입니다.
성능 효율성

스트림 처리는 오늘날 매우 정교한(sophisticated) 기술입니다. Apache Flink와 같은 프레임워크는 확장성이 뛰어나고 완전히 분산된 것으로 입증되었습니다. 스트림 처리는 speed와 unbounded data에 최적화되어 있습니다. 성능은 운영자당 처리량으로 측정되며 가용성 SLA는 종종 특정 지연 허용 범위 내에서 처리되는 이벤트의 백분율로 정의됩니다. 그러나 스트림 처리는 대규모 bounded data 처리에 최적화되어 있지 않으며 대용량 historical 데이터 처리(예: backfill)에서는 성능이 현저히 떨어집니다. 즉, 스트리밍과 Batch의 장점을 모두 활용하는 응집력(cohesive) 있고 통합된 아키텍처를 찾는 것은 현재 활발한 개발 영역입니다. 여기서 기억해야할 점은 Stream 처리와 Batch 처리에는 모두 장단점이 있다는 점 입니다. 궁극적으로 데이터 처리 사용자들은 현재의 스트리밍/배치 구분에 대해 걱정할 필요가 없을 것입니다. 추상화가 불가피하게 증가함에 따라 이 격차는 몇 년 안에 좁혀질 것입니다.
인재(Talent) 효율성

오늘날에도 스트리밍은 사내에서 관리하기 어렵다는 것이 일반적인 합의입니다. 기술적 깊이와 운영 모두에 정통한 매우 강력한 인프라 엔지니어 팀이 필요합니다. 그러나 데이터 처리가 점점 더 일반화 되면서 많은 기업이 자체 구축보다 구매를 고려하기 시작할 것입니다. 여기에서 비유하자면, 전기를 더 높은 가치로 만들기 위해서 원자력 과학자가 필요하지는 않습니다. (오 만약, 당신이 원자력 발전 회사를 운영하고 있지 않다면요 :) - 그 경우, 당신은 가능한 최고의 사람들을 얻을 준비가 되어 있어야 합니다!)

Feature stores는 무엇을 합니까? 🔗

이 분석에 대해 Stefan Krawczyk에게 감사드립니다.

Tecton 및 FEAST와 같은 피쳐 저장소는 일부 스트리밍 피쳐 계산을 수행하지만 조인이 필요하지 않은 데이터에서만 작동하므로 전체 feature computation flow를 오케스트레이션하지는 않을 것입니다.

Sagemaker의 피쳐 저장소는 구체화된 데이터만 저장하며 실제 계산을 수행할 파이프라인에 연결해야 합니다. 그런 다음 사람들은 시스템의 구체화된 피쳐을 참조(reference)하고 사용 합니다, 이는 계산하는 실제 코드가 아닙니다.

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

you gyoung-yoon — Sat, 12 Feb 2022 07:56:05 +0000

원문: 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에게 기여와 조언에 감사드립니다.