큐:
로컬 머신에서 머신 러닝 (ML) 교육을 실행 한 다음 서버에서 정기적으로 실행하는 이유는 무엇입니까?
ㅏ:머신 러닝 프로젝트와 교육 및 테스트 단계를 구성하는 방법에 대한 질문은 ML "라이프 사이클"을 통해 프로그램을 교육 환경에서 프로덕션 환경으로 가져 오는 방법과 관련이 있습니다.
ML 훈련을 로컬 머신에 놓고 서버 기반 시스템으로 실행을 이동시키는 위의 모델을 사용하는 가장 간단한 이유 중 하나는 의무 분리의 이점입니다. 일반적으로 훈련 세트를 분리하여 훈련 시작 및 중지 위치와 테스트 시작 위치를 명확하게 파악할 수 있습니다. 이 KDNuggets 기사는이 원칙에 대해 대략적인 방식으로 다루면서 로컬 머신에서 학습 세트를 분리해야하는 다른 이유도 살펴 봅니다. 이 모델의 또 다른 기본 가치 제안은 매우 다른 아키텍처의 교육 및 테스트 세트를 통해 공동 기차 / 테스트 할당에 대해 혼동하지 않을 것입니다!
또 다른 흥미로운 이점은 사이버 보안과 관련이 있습니다. 전문가들은 로컬 머신에 초기 열차 프로세스가 있다면 인터넷에 연결할 필요가 없다고 지적합니다! 이는 기본 방식으로 보안을 확장하여 프로세스가 프로덕션 환경에 도달 할 때까지 프로세스를 "인큐베이팅"한 다음 서버 모델에 적절한 보안을 구축해야합니다.
또한, 이러한 "절연 된"모델 중 일부는 개념 드리프트 및 숨겨진 컨텍스트와 같은 문제를 해결하는 데 도움이 될 수 있습니다. "비정 지성"의 원칙은 개발자에게 데이터가 시간이 지남에 따라 "고정되지 않음"(측정 대상에 따라 다름)을 경고합니다. 테스트 단계를 기차 단계와 일치 시키려면 많은 적응성이 필요합니다. 또는 경우에 따라 열차와 테스트 프로세스가 혼재되어 혼동을 일으킬 수 있습니다.
서버에 테스트 단계를 처음으로 배포하면 데이터 적응성 문제를 해결하는 다양한 "블랙 박스"모델을 사용할 수 있습니다. 경우에 따라 변경 주문을 여러 플랫폼에 적용하는 중복 프로세스가 필요하지 않습니다.
또한 서버 환경은 엔지니어가 ML 생산에 가장 적합한 데이터 전송 및 코드 모델에 액세스하려는 실시간 또는 동적 프로세스를 제공합니다. 예를 들어 AWS Lambda는 프로덕션 기능 (또는 Lambda와 S3 객체 스토리지의 조합)을 처리하고 연결이 불가능한 (서버없이) 불가능한 기능을 처리하는 매력적인 옵션 일 수 있습니다.
이는 개발자가 테스트 및 프로덕션에서 학습 ML 단계를 분할하는 방법을 고려할 때 생각할 수있는 일부 문제입니다.
