• 요약
• 동기
  • 목표
• 문맥
• 디자인 및 구현 세부 사항
  • 데이터 레이어 변경 사항
  • 마일스톤 1: Ml::Candidates 패키지를 ml_model 유형으로 마이그레이션
    • 반복 1: 새로운 후보는 ml_model 패키지 유형을 사용합니다
    • 반복 2: 기존 후보들을 ml_model로 마이그레이션
  • 마일스톤 2: Ml::Model을 Ml::Candidates의 상위 항목으로 사용
  • 마일스톤 3: Ml::Experiment를 Ml::Model로 교체
    • 단계 1: Ml::Model에 표시 이름 추가
    • 단계 2: 새 실험 생성 차단, 모델만 생성
    • 단계 3: 새 실험 생성 차단, 모델만 생성
  • 마일스톤 4: 정리
• 기존 분리 유지
• 데이터 마이그레이션 없이 모델 실험 폐기

모델 실험을 모델 레지스트리로 Merge

요약

모델 실험과 모델 레지스트리를 두 가지 다른 기능으로 유지하는 것은 UX와 코드 유지보수에 불필요한 부하를 추가할 것이며, 우리는 모델 실험을 모델 레지스트리로 통합하기를 목표로 하고 있습니다. 이는 데이터 레이어의 일부 변경을 필요로 하며, 선택한 전략에 따라 데이터 유실을 가져올 수도 있습니다.

동기

모든 기능을 모델 레지스트리에서 제공하면서 모델 실험을 제거함으로써 사용성을 희생하지 않고 사용자 여정을 단일 기능으로 통합합니다.

목표

• 모델 실험의 모든 기능을 모델 레지스트리로 통합
• 모델 실험 폐기 (https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/)

문맥

머신러닝 모델 실험은 16.2에서 출시된 기능으로, 사용자가 모델 후보 및 관련 메타데이터를 GitLab에 저장할 수 있게 합니다. 모델 실험의 두 가지 주요 엔티티는 후보, 훈련 코드, 매개변수 및 데이터의 조합, 그리고 실험, 비교 가능한 후보들의 모음입니다. 모델 실험은 사용자가 정의한 메트릭에 따라 실험 내 후보들의 진화를 추적하고, 이러한 후보들과 관련된 메타데이터를 관리하는 데 사용됩니다. 모델 실험의 주요 기능 중 하나는 MLflow 클라이언트와의 호환성 레이어인데, 기존의 MLflow 사용자가 코드베이스를 변경하지 않고 GitLab을 새로운 솔루션으로 사용할 수 있게 합니다.

모델 실험에 대한 자세한 내용

모델 레지스트리는 모델 실험의 후속 필요성을 해결하기 위해 16.8에서 출시된 기능으로, 모델 및 버전을 관리하고 배포합니다. 현재 형태에서는 사용자가 모델의 메타데이터를 관리할 수 있는 패키지 레지스트리입니다. 버전 모음뿐만 아니라 사용자는 해당 모델 내에서 후보를 생성할 수도 있습니다. 사용법 측면에서 모델 후보는 모델 버전으로 승격될 수 있습니다.

디자인 및 구현 세부 사항

데이터 레이어 변경 사항

이 블루프린트는 다음과 같은 아키텍처 변경을 제안합니다.

• Ml::Candidates를 Ml::Experiment 대신 Ml::Model에 속하게 합니다.
• 모든 Ml::Candidates를 일반적인 대신 ml_model 패키지 유형을 사용하도록 합니다.
• MLflow 클라이언트 API를 사용하여 실험을 생성할 때, Ml::Experiment 대신에 Ml::Model이 생성됩니다.
• Ml::Experiments 및 Ml::ExperimentMetadata 삭제

데이터 토폴로지 변경:

이전
변경
이후

마일스톤 1: Ml::Candidates 패키지를 ml_model 유형으로 마이그레이션

목표:

• [ ] Ml::Candidates에 연결된 모든 패키지가 ml_model 유형임

기존 후보들은 일반 패키지 유형을 사용하여 아티팩트를 저장하고 있지만, 모델 레지스트리는 새로운 ml_model 유형과 해당 엔드포인트를 사용합니다. 이러한 엔드포인트들은 패키지 생성에 대해 더 많은 도메인 제어를 제공하고 후보 아티팩트를 저장하는 논리를 단순화해야 합니다. 기존 후보들은 일반 패키지를 유지하거나 새로운 ml_model 패키지 유형으로 마이그레이션할 방법을 찾아야 합니다.

2024년 2월 현재, gitab.com 데이터베이스에는 약 38,000개의 후보가 있으며, 그 중 약 4,000개의 패키지가 마이그레이션되어야 합니다. Self-Managed형 인스턴스에 대한 많은 데이터가 없지만, 마이그레이션은 그들에게도 작동해야 합니다.

반복 1: 새로운 후보는 ml_model 패키지 유형을 사용합니다

이미 모델 버전의 일부인 후보들에게는 이미 이 작업이 진행 중입니다. 다른 후보들에 대해서는 모델 레지스트리 피처 플래그가 활성화된 것을 확인하면 ml_model_packages.rb에 새로운 엔드포인트를 추가하여 후보를 지원할 수 있습니다.

반복 2: 기존 후보들을 ml_model로 마이그레이션

후보에 연결된 모든 미리 정의된 패키지를 ml_model 패키지 유형으로 마이그레이션하는 것을 추가합니다. 이러한 패키지들은 새로운 ml_model 패키지 유형이 아니라 기존 이름 및 버전을 지원해야 합니다.

마일스톤 2: Ml::Model을 Ml::Candidates의 상위 항목으로 사용

목표:

• [ ] Ml::Candidate의 experiment_id 열을 제거하고 model_id 열을 추가
• [ ] 모델 상세 페이지에 후보 비교 테이블 추가

Ml::Model은 이제 동일한 이름을 가진 Ml::Experiment를 가지고 있는 기본 Ml::Experiment으로 구성되며, 이는 모델에 할당된 Ml::Candidates를 보유합니다. 이 중간 과정을 제거합니다.

현재 모델 실험이 지원하지만 모델 레지스트리가 아직 지원하지 않는 유일한 기능은 메트릭에 따라 후보를 비교하고 정렬할 수 있는 테이블 뷰입니다. 모델 레지스트리는 정보가 거의 없는 디렉터리만 표시합니다.

마일스톤 3: Ml::Experiment를 Ml::Model로 교체

목표:

• [ ] MLflow 클라이언트 호환성 엔드포인트 (experiments/create)가 실험 대신 모델을 생성
• [ ] 각 실험에 대해 새 모델이 생성
• [ ] 모든 후보는 모델 내에서 생성
• [ ] Ml::Candidate의 상위 항목이 모델에서 실험으로 변경

실험은 단순히 후보들을 그룹화하기 위한 추상적인 것입니다. 하지만 후보들이 모델에 할당되면 모델이 이미 실험의 역할을 수행하며 이는 불필요합니다. 최악의 경우 사용자는 이를 홍보하지 않고 후보를 수집하기 위해 임시 모델을 생성할 수 있습니다. 이것은 정확히 실험과 동일합니다. 실험 테이블을 삭제하면 코드베이스가 단순화됩니다.

단계 1: Ml::Model에 표시 이름 추가

모델 이름은 실험 성명을 따르고 싶지만 표시 이름의 슬러그 버전을 추가해야 합니다.

단계 2: 새 실험 생성 차단, 모델만 생성

모델 실험 MLflow 엔드포인트를 실험 대신 모델로 생성하도록 수정합니다.

단계 3: 새 실험 생성 차단, 모델만 생성

각 실험을 위해 새 모델이 생성되고, 기존 후보들이 해당 모델과 연관됩니다. 새 후보들은 항상 모델과 연관됩니다. 실험 My Experiment은 디스플레이 네임이 My Experiment이고 이름이 my_experiment인 모델을 가집니다.

이 단계에서 모든 후보들이 새로 생성된 모델또는 실험이 기본 실험인 모델에 연관되어 있습니다. model_id라는 새 열이 Ml::Candidate에 추가되어야 합니다.

마일스톤 4: 정리

목표:

• [ ] Ml::Experiments 및 Ml::ExperimentsMetadata 테이블 삭제
• [ ] ExperimentsController (및 관련 헬퍼) 삭제
• [ ] ml/experiment_tracking 하위 분류의 프론트엔드 코드 삭제

대체

기존 분리 유지

장점:

• 단기간에 필요한 작업 없음

단점:

• 부분적으로 동일한 기능을 하는 두 가지 다른 기능을 유지하는 데 부담
• 두 가지 다른 기능을 처리하기 위한 코드 복잡도 증가
• 사용자 여정이 더 복잡해짐

데이터 마이그레이션 없이 모델 실험 폐기

모델 실험 폐기

장점:

• 수행할 작업이 상당히 줄어들며, 간단히 테이블을 삭제할 수 있음

단점:

• 실험적인 기능을 테스트하는 초기 채택자의 신뢰 손실

추가

기존 위상도 다이어그램