Artifacts에 대하여
그리스의 암포라와 같은 아티팩트는 프로세스의 결과물인 생산된 오브젝트입니다. ML에서 가장 중요한 아티팩트는 datasets (데이터셋)과 models (모델)입니다. 그리고 코로나도 전 전설의 십자가처럼, 이러한 중요한 아티팩트들은 박물관에 보관되어야 합니다. 즉, 여러분과 여러분의 팀, 그리고 더 넓은 ML 커뮤니티가 이를 통해 배울 수 있도록 카탈로그화되고 정리되어야 합니다. 결국 트레이닝을 기록하지 않는 사람들은 이를 반복할 운명에 처하게 됩니다. W&B의 Artifacts API를 사용하면Artifact를 W&B Run의 출력으로 로그하거나, 아래 다이어그램처럼 Artifact를 Run의 입력으로 사용할 수 있습니다. 이 예시에서 트레이닝 run은 데이터셋을 입력받아 모델을 생성합니다.

Artifact와 Run은 함께 유향 그래프(비순환 유향 그래프 DAG)를 형성합니다. 여기서 노드는 Artifact와 Run을 나타내며, 화살표는 Run을 소비하거나 생산하는 Artifact에 연결합니다.
Artifacts를 사용하여 모델 및 데이터셋 트래킹하기
설치 및 임포트
Artifacts는 버전0.9.2부터 Python 라이브러리의 일부로 포함되었습니다.
대부분의 ML Python 스택과 마찬가지로 pip를 통해 설치할 수 있습니다.
데이터셋 로그하기
먼저, 몇 가지 Artifacts를 정의해 보겠습니다. 이 예제는 PyTorch의 “Basic MNIST Example”을 기반으로 하지만, TensorFlow나 다른 프레임워크, 또는 순수 Python에서도 동일하게 수행할 수 있습니다. 먼저Dataset부터 시작합니다:
- 파라미터 선택을 위한
train(트레이닝) 세트 - 하이퍼파라미터 튜닝을 위한
validation(검증) 세트 - 최종 모델 평가를 위한
test(테스트) 세트
load)하는 코드와 데이터를 로드하고 로그(load_and_log)하는 코드가 분리되어 있습니다.
이것은 좋은 관행입니다.
이 데이터셋들을 Artifact로 로그하려면 다음 단계가 필요합니다:
wandb.init()으로Run생성 (L4)- 데이터셋을 위한
Artifact생성 (L10) - 관련
file저장 및 로그 (L20, L23)
wandb.init()
Artifact를 생성할 Run을 만들 때, 해당 run이 속할 project를 명시해야 합니다.
워크플로우에 따라 프로젝트는 car-that-drives-itself처럼 클 수도 있고 iterative-architecture-experiment-117처럼 작을 수도 있습니다.
Best practice: 가능하다면실행하는 다양한 종류의 작업을 트래킹하기 위해Artifact를 공유하는 모든Run을 단일 프로젝트 내에 유지하세요. 이렇게 하면 관리가 단순해지지만, 걱정하지 마세요.Artifact는 프로젝트 간 이동이 가능합니다.
Run을 생성할 때 job_type을 제공하는 것이 유용합니다. 이렇게 하면 Artifacts 그래프를 깔끔하게 유지할 수 있습니다.
Best practice:job_type은 파이프라인의 단일 단계를 설명하는 명칭이어야 합니다. 여기서는 데이터를 로드(load)하는 작업과 전처리(preprocess)하는 작업을 구분했습니다.
wandb.Artifact
무엇인가를 Artifact로 로그하려면 먼저 Artifact 오브젝트를 만들어야 합니다.
모든 Artifact는 name을 가집니다. 이는 첫 번째 인수로 설정됩니다.
Best practice: name은 설명적이어야 하지만 기억하기 쉽고 타이핑하기 좋아야 합니다. 하이픈으로 구분되고 코드의 변수명과 일치하는 이름을 사용하는 것을 권장합니다.
또한 type을 가집니다. Run의 job_type과 마찬가지로, 이는 Run과 Artifact의 그래프를 정리하는 데 사용됩니다.
Best practice:사전(dictionary) 형태로type은 단순해야 합니다.mnist-data-YYYYMMDD보다는dataset이나model과 같은 명칭을 사용하세요.
description과 metadata를 추가할 수도 있습니다. metadata는 JSON으로 직렬화 가능해야 합니다.
Best practice: metadata는 가능한 한 자세하게 작성하는 것이 좋습니다.
artifact.new_file 및 run.log_artifact
Artifact 오브젝트를 만든 후에는 파일을 추가해야 합니다.
맞습니다. 단일 파일이 아니라 여러 files (파일들)을 추가할 수 있습니다. Artifact는 파일과 서브 디렉토리를 포함하는 디렉토리와 같은 구조를 가집니다.
Best practice: 의미가 있는 경우 Artifact의 내용을 여러 파일로 나누어 저장하세요. 이는 나중에 규모를 확장할 때 도움이 됩니다.
new_file 메소드를 사용하여 파일을 작성함과 동시에 Artifact에 첨부합니다. 아래에서는 이 두 단계를 분리하는 add_file 메소드도 사용해 볼 것입니다.
모든 파일을 추가했다면 wandb.ai에 log_artifact를 호출해야 합니다.
출력 결과에 Run 페이지를 포함한 몇 가지 URL이 나타나는 것을 볼 수 있습니다. 거기에서 로그된 모든 Artifact를 포함하여 Run의 결과를 확인할 수 있습니다.
아래에서 Run 페이지의 다른 구성 요소들을 더 잘 활용하는 예시를 살펴보겠습니다.
로그된 데이터셋 Artifact 사용하기
W&B의Artifact는 박물관의 유물과 달리 보관만 하는 것이 아니라 사용 되도록 설계되었습니다.
그 과정이 어떤지 살펴보겠습니다.
아래 셀은 원시 데이터셋을 입력받아 정규화 및 형태가 조정된 preprocess (전처리) 데이터셋을 생성하는 파이프라인 단계를 정의합니다.
이번에도 핵심 코드인 preprocess와 wandb 인터페이스 코드를 분리했음에 유의하세요.
preprocess 단계에 wandb.Artifact 로깅을 적용하는 코드를 작성합니다.
아래 예제는 새로운 단계인 Artifact 사용(use)과 이전 단계와 동일한 로그(log)를 모두 수행합니다. Artifact는 Run의 입력이자 출력이 될 수 있습니다.
이전 작업과는 다른 종류의 작업임을 명확히 하기 위해 새로운 job_type인 preprocess-data를 사용합니다.
steps가 metadata로서 preprocessed_data와 함께 저장된다는 것입니다.
실험의 재현성을 확보하려 한다면, 가능한 많은 메타데이터를 캡처하는 것이 좋습니다.
또한 데이터셋이 “대형 아티팩트”임에도 불구하고 download 단계는 1초도 걸리지 않습니다.
자세한 내용은 아래 마크다운 셀을 펼쳐 확인하세요.
run.use_artifact()
이 단계는 간단합니다. 사용자는 Artifact의 name과 추가 정보만 알면 됩니다.
그 “추가 정보”는 사용하려는 특정 버전의 Artifact 에일리어스(alias)입니다.
기본적으로 가장 최근에 업로드된 버전은 latest로 태그됩니다. 그렇지 않으면 v0/v1 등으로 이전 버전을 선택하거나 best 또는 jit-script와 같이 직접 에일리어스를 제공할 수 있습니다. Docker Hub 태그와 마찬가지로 에일리어스는 이름과 :로 구분되므로, 우리가 원하는 Artifact는 mnist-raw:latest입니다.
Best practice: 에일리어스는 짧고 명확하게 유지하세요. 특정 속성을 만족하는Artifact를 원할 때latest나best와 같은 커스텀alias를 사용하세요.
artifact.download
이제 download 호출에 대해 걱정하실 수도 있습니다. 사본을 다시 다운로드하면 메모리 부담이 두 배가 되지 않을까요?
걱정하지 마세요. 실제로 무언가를 다운로드하기 전에 로컬에 올바른 버전이 있는지 확인합니다. 이는 토렌트나 git을 이용한 버전 관리의 기반이 되는 기술인 해싱(hashing)을 사용합니다.
Artifacts가 생성되고 로그됨에 따라 작업 디렉토리의 artifacts 폴더에는 각 Artifact에 대한 서브 디렉토리가 채워지기 시작합니다. !tree artifacts로 그 내용을 확인해 보세요.
Artifacts 페이지
이제Artifact를 로그하고 사용해 보았으니 Run 페이지의 Artifacts 탭을 확인해 보겠습니다.
wandb 출력의 Run 페이지 URL로 이동하여 왼쪽 사이드바에서 “Artifacts” 탭을 선택합니다(세 개의 하키 퍽이 쌓여 있는 모양의 데이터베이스 아이콘입니다).
Input Artifacts 테이블이나 Output Artifacts 테이블에서 행을 클릭한 다음, 탭(Overview, Metadata)을 탐색하여 해당 Artifact에 대해 로그된 모든 내용을 확인하세요.
특히 Graph View를 추천합니다. 기본적으로 Artifact의 type과 Run의 job_type을 두 종류의 노드로 보여주며, 소비와 생산 관계를 화살표로 나타냅니다.
모델 로그하기
이것으로 Artifacts API가 어떻게 작동하는지 충분히 살펴보았지만,Artifact가 ML 워크플로우를 어떻게 개선할 수 있는지 확인하기 위해 이 예제의 파이프라인 끝까지 따라가 보겠습니다.
여기 첫 번째 셀은 PyTorch로 DNN model을 구축합니다. 아주 간단한 ConvNet입니다.
먼저 모델을 트레이닝하지 않고 초기화만 하겠습니다. 그렇게 하면 다른 모든 요소를 일정하게 유지하면서 트레이닝을 반복할 수 있습니다.
run.config 오브젝트를 사용합니다.
해당 config 오브젝트의 사전(dict) 버전은 매우 유용한 metadata 조각이므로 반드시 포함시키세요.
artifact.add_file()
데이터셋 로깅 예시처럼 new_file로 파일을 작성함과 동시에 Artifact에 추가하는 대신, 한 단계에서 파일을 작성하고(여기서는 torch.save) 다른 단계에서 Artifact에 추가(add)할 수도 있습니다.
Best practice: 중복을 방지하기 위해 가능하면 new_file을 사용하세요.
로그된 모델 Artifact 사용하기
dataset에 use_artifact를 호출했던 것처럼, initialized_model에 대해 호출하여 다른 Run에서 사용할 수 있습니다.
이번에는 model을 트레이닝(train)해 보겠습니다.
더 자세한 내용은 W&B와 PyTorch 연동 Colab을 확인하세요.
Artifact 생성 Run을 실행합니다.
첫 번째 run이 model 트레이닝(train)을 마치면, 두 번째 run은 test_dataset에 대한 성능을 평가(evaluate)하여 trained-model Artifact를 소비합니다.
또한 네트워크가 가장 혼동하는(즉, categorical_crossentropy가 가장 높은) 32개의 예시를 추출할 것입니다.
이는 데이터셋과 모델의 문제를 진단하는 좋은 방법입니다.
Artifact 기능을 추가하지 않으므로 별도로 설명하지 않겠습니다. 단지 Artifact를 사용(use), 다운로드(download), 로그(log)하는 과정일 뿐입니다.