산업용 기계 학습: 10가지 설계 원칙

산업용 기계 학습: 10가지 설계 원칙

요즘에는 SpaceX 로켓을 제어하는 ​​소프트웨어부터 스마트폰을 통해 옆방에 있는 주전자와 상호 작용하는 소프트웨어에 이르기까지 놀라운 일을 만들 수 있는 새로운 서비스, 애플리케이션 및 기타 중요한 프로그램이 매일 생성됩니다.

그리고 때때로 모든 초보 프로그래머는 열정적인 스타트업이든 일반 풀 스택 또는 데이터 과학자이든 관계없이 삶을 크게 단순화하는 소프트웨어 프로그래밍 및 제작에 대한 특정 규칙이 있다는 것을 조만간 깨닫게 됩니다.

본 글에서는 10-Factor App 방법론을 기반으로 산업용 머신러닝을 애플리케이션/서비스에 쉽게 통합할 수 있도록 프로그래밍하는 12가지 원칙을 간략하게 설명하겠습니다. Heroku 팀이 제안한. 나의 계획은 많은 개발자와 데이터 과학 전문가에게 도움이 될 수 있는 이 기술에 대한 인식을 높이는 것입니다.

이 기사는 산업용 기계 학습에 관한 일련의 기사에 대한 프롤로그입니다. 여기서는 실제로 모델을 만들어 프로덕션에 출시하고 이를 위한 API를 만드는 방법과 시스템에 ML이 내장된 다양한 분야와 회사의 사례에 대해 자세히 설명하겠습니다.

원칙 1: 하나의 코드 기반

첫 단계의 일부 프로그래머는 게으름 때문에(또는 어떤 이유로든) Git을 잊어버립니다. 단어를 완전히 잊어버리거나, 즉 드라이브에서 서로에게 파일을 던지거나, 텍스트만 던지거나, 비둘기로 보내거나, 작업 흐름을 고려하지 않고 각각을 자신의 브랜치에 커밋한 다음 주인.

이 원칙은 다음과 같이 명시합니다. 하나의 코드베이스와 많은 배포가 있습니다.

Git은 프로덕션과 연구 개발(R&D) 모두에서 사용할 수 있지만 그다지 자주 사용되지는 않습니다.

예를 들어, R&D 단계에서는 다양한 데이터 처리 방법 및 모델을 사용하여 커밋을 남겨두고 가장 좋은 것을 선택하고 추가 작업을 쉽게 계속할 수 있습니다.

둘째, 프로덕션에서 이것은 대체할 수 없는 일입니다. 코드가 어떻게 변경되는지 지속적으로 살펴보고 어떤 모델이 최상의 결과를 생성했는지, 어떤 코드가 결국 작동했는지, 어떤 일이 발생하여 작동이 중지되거나 잘못된 결과가 생성되는지 알아야 합니다. . 이것이 바로 커밋의 목적입니다!

또한 프로젝트 패키지를 생성하여 예를 들어 Gemfury에 배치한 다음 다른 프로젝트에 대한 기능을 가져와서 1000번 다시 작성하지 않고 나중에 더 자세히 설명할 수도 있습니다.

원칙 2: 종속성을 명확하게 선언하고 격리합니다.

각 프로젝트에는 어딘가에 적용하기 위해 외부에서 가져오는 다양한 라이브러리가 있습니다. Python 라이브러리, 다양한 목적을 위한 다른 언어 라이브러리, 시스템 도구 등 귀하의 작업은 다음과 같습니다.

• 종속성을 명확하게 선언합니다. 즉, 프로젝트에 사용되며 설치해야 하는 모든 라이브러리, 도구 및 해당 버전을 포함하는 파일입니다(예를 들어 Python에서는 Pipfile 또는 요구 사항.txt를 사용하여 수행할 수 있습니다. A 잘 이해할 수 있는 링크: realpython.com/pipenv-guide)
• 개발 중에 프로그램에 대한 종속성을 특별히 격리하세요. 예를 들어 Tensorflow와 같이 지속적으로 버전을 변경하고 다시 설치하고 싶지 않으십니까?

이렇게 하면 향후 팀에 합류할 개발자가 프로젝트에 사용되는 라이브러리와 해당 버전에 빠르게 익숙해질 수 있으며, 특정 프로젝트에 설치된 버전과 라이브러리 자체를 관리할 수도 있습니다. 이는 라이브러리나 해당 버전의 비호환성을 방지하는 데 도움이 됩니다.

또한 애플리케이션은 특정 OS에 설치될 수 있는 시스템 도구에 의존해서는 안 됩니다. 이러한 도구는 종속성 매니페스트에서도 선언되어야 합니다. 이는 도구 버전(및 가용성)이 특정 OS의 시스템 도구와 일치하지 않는 상황을 피하기 위해 필요합니다.

따라서 컬이 거의 모든 컴퓨터에서 사용될 수 있더라도 다른 플랫폼으로 마이그레이션할 때 컬이 존재하지 않거나 원래 필요했던 버전이 아닐 수 있으므로 종속성으로 선언해야 합니다.

예를 들어, 요구사항.txt는 다음과 같습니다.

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

원칙 3: 구성

많은 개발자들이 실수로 AWS의 암호 및 기타 키를 사용하여 GitHub에 코드를 공개 리포지토리에 업로드하고 다음날 깨어나서 6000달러 또는 심지어 50000달러의 빚을 졌다는 이야기를 들었습니다.

물론 이러한 경우는 극단적이지만 매우 중요합니다. 자격 증명이나 구성에 필요한 기타 데이터를 코드 내부에 저장하면 실수를 하는 것이며, 그 이유는 설명할 필요가 없다고 생각합니다.

이에 대한 대안은 환경 변수에 구성을 저장하는 것입니다. 환경 변수에 대해 자세히 읽을 수 있습니다. 여기에.

일반적으로 환경 변수에 저장되는 데이터의 예:

• 도메인 이름
• API URL/URI
• 공개 키와 개인 키
• 연락처(메일, 전화 등)

이렇게 하면 구성 변수가 변경될 때 코드를 지속적으로 변경할 필요가 없습니다. 이렇게 하면 시간, 노력, 비용을 절약하는 데 도움이 됩니다.

예를 들어 Kaggle API를 사용하여 테스트를 수행하는 경우(예: 소프트웨어를 다운로드하고 이를 통해 모델을 실행하여 실행 시 모델이 제대로 작동하는지 테스트), KAGGLE_USERNAME 및 KAGGLE_KEY와 같은 Kaggle의 개인 키를 사용해야 합니다. 환경변수에 저장됩니다.

원칙 4: 제XNUMX자 서비스

여기서의 아이디어는 코드 측면에서 로컬 리소스와 타사 리소스 간에 차이가 없는 방식으로 프로그램을 만드는 것입니다. 예를 들어 로컬 MySQL과 타사 MySQL을 모두 연결할 수 있습니다. Google Maps나 Twitter API와 같은 다양한 API도 마찬가지입니다.

타사 서비스를 비활성화하거나 다른 서비스를 연결하려면 위 단락에서 설명한 환경 변수 구성의 키만 변경하면 됩니다.

따라서 예를 들어 매번 코드 내부에 데이터 세트가 있는 파일의 경로를 지정하는 대신 pathlib 라이브러리를 사용하고 config.py에서 데이터 세트의 경로를 선언하는 것이 더 좋습니다. 예를 들어 CircleCI), 프로그램은 새 서비스의 새 파일 시스템 구조를 고려하여 데이터 세트의 경로를 찾을 수 있었습니다.

원칙 5. 빌드, 릴리스, 런타임

데이터 과학 분야의 많은 사람들은 소프트웨어 작성 기술을 향상시키는 것이 유용하다고 생각합니다. 프로그램이 가능한 한 거의 충돌하지 않고 가능한 한 오랫동안 오류 없이 작동하도록 하려면 새 버전을 출시하는 과정을 3단계로 나누어야 합니다.

1. 무대 조립. 개별 리소스가 포함된 베어 코드를 필요한 모든 코드와 데이터가 포함된 소위 패키지로 변환합니다. 이 패키지를 어셈블리라고 합니다.
2. 무대 석방하다 — 여기서 구성을 어셈블리에 연결합니다. 그렇지 않으면 프로그램을 릴리스할 수 없습니다. 이제 완전히 출시 준비가 완료된 릴리스입니다.
3. 다음은 무대 성취. 여기서는 릴리스에서 필요한 프로세스를 실행하여 애플리케이션을 릴리스합니다.

모델 또는 전체 파이프라인의 새 버전을 출시하기 위한 이러한 시스템을 사용하면 관리자와 개발자 간의 역할을 분리할 수 있고, 버전을 추적할 수 있으며, 원치 않는 프로그램 중지를 방지할 수 있습니다.

릴리스 작업의 경우 .yml 파일에서 직접 실행하기 위한 프로세스를 작성할 수 있는 다양한 서비스가 생성되었습니다. 예를 들어 CircleCI에서는 프로세스 자체를 지원하는 config.yml입니다. Wheely는 프로젝트용 패키지를 만드는 데 능숙합니다.

다양한 버전의 기계 학습 모델로 패키지를 생성한 다음 이를 패키징하고 필요한 패키지와 해당 버전을 참조하여 거기에서 작성한 기능을 사용할 수 있습니다. 이는 모델에 대한 API를 생성하는 데 도움이 되며, 패키지는 예를 들어 Gemfury에서 호스팅될 수 있습니다.

원칙 6. 모델을 하나 이상의 프로세스로 실행

또한 프로세스에는 공유 데이터가 있어서는 안 됩니다. 즉, 프로세스는 별도로 존재해야 하며, 모든 종류의 데이터는 필요에 따라 MySQL 등의 타사 서비스에 별도로 존재해야 합니다.

즉, 프로세스 파일 시스템 내부에 데이터를 저장하는 것은 확실히 가치가 없습니다. 그렇지 않으면 다음 번 구성 릴리스/변경 또는 프로그램이 실행되는 시스템 전송 중에 이 데이터가 지워질 수 있습니다.

그러나 예외가 있습니다. 기계 학습 프로젝트의 경우 추가 라이브러리가 없거나 버전이 변경되지 않은 경우 새 버전을 시작할 때마다 다시 설치하지 않도록 라이브러리 캐시를 저장할 수 있습니다. 이렇게 하면 업계에서 모델을 출시하는 데 걸리는 시간이 단축됩니다.

모델을 여러 프로세스로 실행하려면 필요한 프로세스와 해당 순서를 지정하는 .yml 파일을 생성하면 됩니다.

원칙 7: 재활용성

모델 애플리케이션에서 실행되는 프로세스는 시작 및 중지가 쉬워야 합니다. 따라서 이를 통해 코드 변경 사항, 구성 변경 사항을 신속하게 배포하고, 빠르고 유연하게 확장하고, 작업 버전의 중단 가능성을 방지할 수 있습니다.

즉, 모델을 사용한 프로세스는 다음과 같아야 합니다.

• 시작 시간을 최소화합니다. 이상적으로는 시작 시간(시작 명령이 실행된 순간부터 프로세스가 작동되는 순간까지)이 몇 초를 넘지 않아야 합니다. 위에서 설명한 라이브러리 캐싱은 시작 시간을 줄이는 기술 중 하나입니다.
• 올바르게 종료하십시오. 즉, 서비스 포트에서 수신 대기가 실제로 일시 중지되고 이 포트에 제출된 새 요청이 처리되지 않습니다. 여기에서는 DevOps 엔지니어와 원활한 의사소통을 설정하거나 그것이 어떻게 작동하는지 직접 이해해야 합니다(물론 후자가 바람직하지만 모든 프로젝트에서 의사소통은 항상 유지되어야 합니다!)

원칙 8: 지속적인 배포/통합

많은 회사에서는 애플리케이션 개발 팀과 배포 팀을 분리하여 최종 사용자가 애플리케이션을 사용할 수 있도록 합니다. 이로 인해 소프트웨어 개발 및 개선 진행 속도가 크게 느려질 수 있습니다. 이는 또한 대략적으로 말하면 개발과 통합이 결합된 DevOps 문화를 망칩니다.

따라서 이 원칙은 개발 환경이 프로덕션 환경과 최대한 유사해야 함을 나타냅니다.

이렇게 하면 다음이 허용됩니다.

1. 출시 시간을 수십 배 단축
2. 코드 비호환으로 인한 오류 수를 줄입니다.
3. 개발자와 애플리케이션을 배포하는 사람들이 이제 하나의 팀이 되므로 직원의 업무량도 줄어듭니다.

이를 작업할 수 있는 도구로는 CircleCI, Travis CI, GitLab CI 등이 있습니다.

신속하게 모델을 추가하고, 업데이트하고, 즉시 실행할 수 있으며, 오류가 발생한 경우 매우 빠르게 작업 버전으로 돌아가 최종 사용자가 눈치채지 못하도록 할 수 있습니다. 이는 좋은 테스트를 거친 경우 특히 쉽고 빠르게 수행할 수 있습니다.

차이를 최소화하세요!!!

원칙 9. 로그

로그(또는 "로그")는 일반적으로 애플리케이션(이벤트 스트림) 내에서 발생하는 텍스트 형식으로 기록되는 이벤트입니다. 간단한 예: "2020-02-02 - 시스템 수준 - 프로세스 이름." 이는 프로그램이 실행될 때 개발자가 문자 그대로 무슨 일이 일어나고 있는지 볼 수 있도록 설계되었습니다. 그는 프로세스의 진행 상황을 보고 그것이 개발자 자신의 의도대로 되었는지 이해합니다.

이 원칙은 로그를 파일 시스템 내부에 저장해서는 안 된다는 것을 명시하고 있습니다. 예를 들어 시스템의 표준 출력에서 ​​이를 수행하는 것과 같이 로그를 화면에 "출력"해야 합니다. 그리고 이러한 방식으로 개발 중에 터미널의 흐름을 모니터링하는 것이 가능해집니다.

이는 로그를 전혀 저장할 필요가 없다는 뜻인가요? 당연히 아니지. 귀하의 애플리케이션은 이 작업을 수행해서는 안 됩니다. 타사 서비스에 맡겨두십시오. 애플리케이션은 실시간 보기를 위해 특정 파일이나 터미널에만 로그를 전달하거나 Hadoop과 같은 범용 데이터 스토리지 시스템에만 전달할 수 있습니다. 애플리케이션 자체는 로그를 저장하거나 로그와 상호작용해서는 안 됩니다.

원칙 10. 테스트!

산업용 기계 학습의 경우 이 단계는 모델이 올바르게 작동하고 원하는 것을 생성한다는 것을 이해해야 하기 때문에 매우 중요합니다.

테스트는 pytest를 사용하여 생성할 수 있으며 회귀/분류 작업이 있는 경우 작은 데이터 세트를 사용하여 테스트할 수 있습니다.

딥러닝 모델이 지속적으로 다른 결과를 생성하지 않도록 동일한 시드를 설정하는 것을 잊지 마세요.

이것은 10가지 원칙에 대한 간략한 설명이었고, 물론 그것이 어떻게 작동하는지 시험해 보지 않고는 사용하기 어렵습니다. 따라서 이 기사는 제가 만드는 방법을 공개할 일련의 흥미로운 기사에 대한 프롤로그일 뿐입니다. 산업용 기계 학습 모델, 이를 시스템에 통합하는 방법, 이러한 원칙이 우리 모두의 삶을 어떻게 더 쉽게 만들 수 있는지 알아보세요.

또한 원하시면 누구나 댓글에 남길 수 있는 멋진 원칙을 활용해 보겠습니다.

출처 : habr.com