By 아론 솔린저 & 윌 쿤즈

우리 프로젝트를 위한 MLOps 스택을 설계할 때 우리는 실험 지시에 따라 진화할 수 있는 고도의 사용자 정의와 유연성을 허용하는 솔루션이 필요했습니다. 우리는 많은 기능을 포함하는 대형 플랫폼을 고려했지만 일부 핵심 영역에서 제한적임을 발견했습니다. 궁극적으로 우리는 레이블 지정, 데이터 버전 관리 및 지속적인 통합을 위해 별도의 특수 도구를 구현하는 접근 방식을 결정했습니다. 이 문서에서는 이 사용자 지정 MLOps 접근 방식을 구축한 경험을 문서화합니다.

님이 촬영 한 사진 댄 찾기 | 댄 그린위스 on Unsplash

NBDEV

(에서 가져온 https://github.com/fastai/nbdev)

개발에 Jupyter를 사용하는 고전적인 문제는 프로토타입에서 프로덕션으로 이동하는 데 필요한 복사/붙여넣기 코드를 노트북에서 파이썬 모듈로 옮기는 것이었습니다. NBDEV는 노트북과 모듈 간의 전환을 자동화하므로 Jupyter 노트북이 프로덕션 파이프라인의 공식 부분이 될 수 있습니다. NBDEV를 통해 개발자는 노트북이 생성해야 하는 모듈, 모듈에 푸시할 노트북 셀 및 테스트할 노트북 셀을 명시할 수 있습니다. NBDEV의 핵심 기능은 노트북 내에서 테스트하는 접근 방식이며 NBDEV 템플릿은 CI/CD 프레임워크에서 테스트를 구현하기 위한 기본 Github 작업도 제공합니다. 결과 Python 모듈은 개발자가 편집할 필요가 없으며 내장된 Python 가져오기 기능을 사용하여 다른 노트북이나 대규모 프로젝트에 쉽게 통합할 수 있습니다.

Iterative.ai: DVC/CML

(에서 가져온 https://iterative.ai/)

기계 학습 파이프라인에 사용되는 파일은 git과 같은 기존 버전 제어 솔루션에 액세스할 수 없거나 비용이 많이 드는 바이너리/압축 파일의 대규모 아카이브인 경우가 많습니다. DVC는 DVC가 변경 사항을 추적할 수 있도록 하는 파일 내용의 해시로 대규모 데이터 세트를 표시하여 데이터 버전 관리를 해결합니다. git과 유사하게 작동합니다(예: dvc add, dvc push). 당신이 달릴 때 dvc add 데이터 세트에서 .gitignore 에 의해 변경 사항을 추적했습니다. dvc. CML은 Github Actions 워크플로의 모델 아티팩트를 Github Issues, Pull Requests 등으로 첨부된 주석에 게시하는 기능을 제공하는 프로젝트입니다. 이는 교육 데이터 변경 및 결과에 대한 Pull Request 계정의 공백을 채우기 시작하는 데 도움이 되기 때문에 중요합니다. 모델 정확도 및 효율성.

Github 작업

(에서 가져온 https://github.com/features/actions)

우리는 자동화된 테스트 파이프라인에서 모델 구축을 포함하여 자동화된 코드 테스트를 원합니다. Github Actions는 코드 푸시, 커밋, 풀 요청 등에 대한 테스트를 자동화하는 CircleCI, Travis, Jenkins와 경쟁하고 있습니다. 이미 Github를 사용하여 저장소를 호스팅하고 있기 때문에 Actions를 사용하여 다른 타사 앱을 사용하지 않습니다. 이 프로젝트에서는 Github 자체 호스팅 러너를 사용하여 온프레미스 GPU 클러스터에서 작업을 실행해야 합니다.

라벨 스튜디오

(에서 가져온 https://labelstud.io/)

Label Studio 사용 방법에 대해 자세히 알아보았습니다. 여기에서 지금 확인해 보세요.. Label Studio는 데이터에 레이블을 지정하는 솔루션입니다. 잘 작동하며 다양한 환경에서 유연하게 실행할 수 있습니다.

왜 함께 사용합니까?

 
 
설정은 모델을 더 빠르게 배포하도록 설계되었습니다. 즉, 더 많은 데이터 과학자가 조화롭게 병렬로 작업하고 리포지토리의 투명성을 확보하며 새로운 사람의 온보딩 시간을 단축할 수 있습니다. 목표는 데이터 과학자가 프로젝트에서 수행해야 하는 활동 유형을 표준화하고 명확한 지침을 제공하는 것입니다.

다음은 이 시스템 설계로 간소화하려는 작업 목록입니다.

1. Label Studio에서 수집을 자동화하고 이를 모델 교육 및 평가 활동에 수집하기 위한 단일 지점을 제공합니다.
2. 데이터 파이프라인 코드에 대한 자동화된 테스트, 즉 프로세스에서 사용하는 컨테이너의 단위 테스트 및 재배포입니다.
3. 모델 코드에 대한 자동화된 테스트, 즉 프로세스에서 사용하는 컨테이너의 단위 테스트 및 재배포입니다.
4. 모델 재교육 및 평가 기준을 포함하도록 자동화된 테스트를 활성화합니다. 모델 코드가 변경되면 새 코드로 모델을 학습시키고 기존 모델과 비교합니다.
5. 학습 데이터가 변경되면 모델 재학습을 트리거합니다.

다음은 각 작업에 대한 파이프라인에 대한 설명입니다.

기존 CI/CD 파이프라인

 
 
이 파이프라인은 구문, 단위, 회귀 및 통합 테스트의 평가를 포함하는 각 풀 요청에 대한 자동화된 테스트 피드백을 구현합니다. 이 프로세스의 결과는 기능적으로 테스트된 도커 이미지를 개인 저장소에 제공합니다. 이 프로세스는 최신 최고의 코드가 다운스트림 작업을 위해 저장소에서 사용할 수 있는 완전히 테스트된 이미지에 있을 가능성을 최대화합니다. 새 기능의 컨텍스트에서 개발자 수명 주기가 작동하는 방식은 다음과 같습니다.

여기에서는 코드를 편집하는 동안 워크플로가 어떻게 작동하는지 보여줍니다. NBDEV를 사용하면 노트북에서 직접 테스트를 작성하는 것을 포함하여 Jupyter 노트북에서 직접 작업할 수 있습니다. NBDEV를 사용하려면 노트북의 모든 셀이 예외 없이 실행되어야 합니다(셀이 실행되지 않도록 플래그가 지정되지 않은 경우). (저자 이미지)

데이터 파이프 라인

 
 
현재 Label Studio에는 저장된 레이블 데이터의 변경 시 업데이트를 가능하게 하는 이벤트 후크가 없습니다. 그래서 우리는 cron 트리거된 접근 방식으로 매시간 데이터 세트를 업데이트합니다. 또한 레이블 스튜디오 훈련 데이터 세트는 충분히 작지만 훈련 파이프라인의 일부로 업데이트를 수행할 수도 있습니다. Github Actions 인터페이스를 사용하여 요청 시 데이터 파이프라인 새로 고침을 트리거할 수 있는 기능이 있습니다.

데이터 파이프라인은 Label Studio에서 제공하고 모든 버전의 데이터 세트와 관련 입력을 AWS S3에 저장된 DVC 캐시에 유지합니다. (저자 이미지)

모델 파이프라인

 
 
모델링 파이프라인은 모델 교육을 리포지토리의 CI/CD 파이프라인에 통합합니다. 이를 통해 각 pull 요청은 코드베이스에 구성된 구문, 단위, 통합 및 회귀 테스트를 평가할 수 있지만 새로운 결과 모델 평가를 포함하는 피드백을 제공할 수도 있습니다.

이 경우 워크플로는 구성 파일(model_params.yaml)에 지정된 모델 학습 실험을 실행하고 모델 아티팩트(best-model.pth)를 업데이트합니다(Image by Author).

벤치마크 평가 파이프라인

 
 
벤치마킹 파이프라인은 "공식 제출" 프로세스를 형성하여 모든 모델링 활동이 프로젝트의 메트릭에 대해 측정되도록 합니다.

best-model.pth에서 새로 훈련된 모델은 벤치마크 데이터 세트에 대해 평가되고 결과는 최신 커밋 해시로 태그가 지정되고 AWS S3에 유지됩니다. (저자 이미지)

워크 플로우

 
 
다음은 DVC에서 사용하는 DAG 정의 파일입니다. 워크플로 단계와 해당 입력을 캡처하고 사용자와 시스템 전반에 걸쳐 재현성을 허용합니다.

stages: labelstudio_export_trad: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/traditional_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/traditional_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_trad: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_traditional.yaml --proj_root "." deps: - data/raw_labels/traditional.json params: - pipelines/create_traditional.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir train_model_trad: cmd: python pipelines/3_train_model.py --config_fp pipelines/model_params.yaml --proj_root "." deps: - data/traditional_labeling params: - pipelines/model_params.yaml: - dataloader.bs - dataloader.size - dataloader.train_fp - dataloader.valid_fp - learner.backbone - learner.data_dir - learner.in_checkpoint - learner.metrics - learner.n_out - learner.wandb_project_name - train.cycles labelstudio_export_bench: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/benchmark_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/benchmark_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_bench: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_benchmark.yaml --proj_root "." deps: - data/raw_labels/benchmark.json params: - pipelines/create_benchmark.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir eval_model_trad: cmd: python pipelines/4_eval_model.py --config_fp pipelines/bench_eval.yaml --proj_root "." deps: - data/models/best-model.pth params: - pipelines/bench_eval.yaml: - eval.bench_fp - eval.label_config - eval.metrics_fp - eval.model_conf - eval.overlay_dir

조사 결과

1. Github 작업 워크플로 cron 방아쇠는 매우 신뢰할 수 없습니다. 타이밍을 보장하지 않습니다.
2. DVC는 푸시 시 트리거되는 Github 작업 워크플로 내에서 명확한 방식으로 작동하지 않습니다. 소스 제어되는 추적기를 변경하고 커밋되면 다른 Github 작업을 생성합니다.
3. 모델을 실행하는 메커니즘으로서의 Github Actions 오케스트레이션에는 GPU를 사용하는 자체 호스팅 러너가 필요합니다. 이는 클라우드 또는 온프레미스의 GPU 인스턴스에 연결하는 것을 의미하며, 이는 액세스 제어 문제를 나타냅니다. 예를 들어 자체 호스팅 러너 구성을 리포지토리에서 제거하지 않고 정확한 리포지토리를 공개할 수 없습니다. 그렇지 않으면 임의의 사람들이 프로젝트에 코드를 푸시하여 교육 서버에서 워크로드를 실행할 수 있습니다.
4. NBDEV 기본 제공 워크플로가 잘못된 위치에서 코드를 테스트하고 있습니다. 컴파일된 패키지 대신 노트북을 테스트하고 있습니다. 한편으로 "시험을 노트북에 바로 쓸 수 있다"고 말할 수 있다는 것은 좋은 일입니다. 반면에 노트북을 직접 테스트하면 노트북이 실행되더라도 NBDEV에서 만든 코드 패키지가 실패할 가능성이 있습니다. 우리에게 필요한 것은 NBDEV 컴파일 패키지를 직접 테스트하는 기능입니다.
5. NBDEV는 NBDEV가 일방통행이라는 점에서 "전통적인" Python 개발과 상호 운용되지 않습니다. 이것은 단순히 프로젝트를 대화형 Jupyter 노트북 스타일로 개발할 수 있도록 합니다. Python 모듈을 직접 개발하는 것은 불가능합니다. 어느 시점에서든 프로젝트가 "전통적인" Python 개발 테스트로 변환되기를 원한다면 다른 방법으로 수행해야 합니다.
6. 처음에는 Weights & Biases를 실험 추적 대시보드로 사용했지만 Github Action에 배포하는 데 문제가 있었습니다. 우리가 말할 수 있는 것은 구현을 위한 사용자 경험이 wandb Action Workflow에서 첫 번째 딸꾹질을 쳤습니다. 가중치 및 편향을 제거하면 문제가 즉시 해결되었습니다. 그것 앞에, wandb MLOps에서 최고의 사용자 경험으로 두드러졌습니다.

결론

 
 
궁극적으로 Github Actions, Iterative.ai 도구(DVC 및 CML) 및 NBDEV로 코드를 관리하기 위한 이러한 도구의 구현을 완료하는 데 일주일이 걸렸습니다. 이것은 우리에게 다음과 같은 기능을 제공합니다:

1. 코드에 대한 기록 시스템으로 Jupyter 노트북에서 작업합니다. 우리는 Jupyter를 좋아합니다. 주요 사용 사례는 Jupyter 서버를 호스팅하고 데스크톱으로 전달하여 SSH로 연결할 수 있는 모든 하드웨어에서 직접 작업할 수 있도록 하는 것입니다. 분명히 하자면, 우리는 NBDev를 사용하지 않더라도 이 작업을 수행할 것입니다. 그 이유는 대안이 Vim이나 우리가 그다지 좋아하지 않는 도구를 사용하는 것이기 때문입니다. VS Code 또는 Pycharm을 사용하여 원격 서버에 연결하려는 이전 실험은 실패했습니다. 그래서 주피터입니다.
2. 코드를 테스트하고 코드가 생성하는 모델을 테스트합니다. 이제 CI/CD 파이프라인의 일부로 저장소 변경으로 인한 모델이 모델을 더 좋게 만들거나 나쁘게 만들거나 그대로 유지하는지 여부를 평가할 수 있습니다. 이것은 병합되기 전에 pull 요청에서 모두 사용할 수 있습니다. main.
3. 훈련 실행을 위한 오케스트레이터로 Github Actions 서버를 사용하면 여러 데이터 과학자가 보다 명확한 방식으로 동시에 작업할 수 있습니다. 앞으로 우리는 협업 데이터 과학 프로세스를 조정하기 위한 이 설정의 한계를 보게 될 것입니다.

 
아론 솔린저 이전에는 금융, 예측 유지 관리 및 스포츠의 문제를 해결하는 데이터 과학자 및 소프트웨어 엔지니어로 일했습니다. 그는 현재 다중 카메라 컴퓨터 비전 애플리케이션을 작업하는 Hoplabs에서 기계 학습 시스템 컨설턴트로 일하고 있습니다.

윌 쿤즈 백 엔드 소프트웨어 개발자로서 할 수 있는 태도와 끈기 있는 결단력을 가지고 도전에 임하고 있습니다. 파악하기 어려운 버그를 추적하거나 새로운 기술에 빠르게 적응하는 것은 중요하지 않습니다. 해결책이 있다면 윌은 그것을 찾고 싶어합니다.

실물. 허가를 받아 다시 게시했습니다.

관련 :

• MLOps 모범 사례
• MLOps는 엔지니어링 분야입니다 : 초보자를위한 개요
• MLOps 및 기계 학습 로드맵