노트북 프로토타이핑과 실험 추적

둘째 섹션의 마지막 조각은 「사람이 실제로 손을 대는 자리」입니다. 모델은 노트북에서 시작하고, 거기서 돌린 수십 번의 시도 중 무엇이 좋았는지 기억해 두지 않으면 같은 실험을 두 번 하게 됩니다. 시험은 노트북 제품을 고르는 문항과 실험 기록을 묻는 문항을 각각 냅니다.

Agent Platform Workbench

관리형 JupyterLab

Workbench 인스턴스는 JupyterLab이 올라간 가상 머신을 플랫폼이 띄우고 관리해 주는 환경입니다. 머신 타입·GPU·디스크 크기를 내가 직접 고르고, 만든 뒤에도 사양을 바꿀 수 있습니다. 주피터 확장이나 시스템 패키지를 설치해 환경을 손볼 수도 있어, 오래 도는 학습이나 손이 많이 가는 환경에 맞습니다.

유휴 종료

노트북의 가장 흔한 낭비는 열어 두고 잊는 것입니다. 인스턴스가 떠 있는 동안 요금이 나가므로 유휴 종료 시간을 걸어 두면 일정 시간 아무 작업이 없을 때 자동으로 멈춥니다. 디스크는 남으므로 다시 켜면 작업이 그대로 있습니다. 비용 문항에서 「노트북을 쓰되 요금을 줄여라」의 답이 대개 이것입니다.

Colab Enterprise

런타임 템플릿

Colab Enterprise는 Colab 화면에 기업용 통제를 얹은 환경입니다. 사용자가 머신을 고르는 것이 아니라 관리자가 런타임 템플릿에 사양·네트워크·유휴 시간을 미리 정해 두고, 사용자는 그 템플릿으로 런타임을 붙여 씁니다. 인스턴스를 각자 만들고 지우는 일이 없어지므로 사람이 많을수록 유리합니다.

공유

노트북 자체가 관리되는 리소스라 IAM으로 보기·편집 권한을 나눠 링크로 공유합니다. 「분석가 서른 명이 같은 노트북을 열어 보되 각자 VM을 만들지는 않게 하라」는 조건이 이쪽을 가리킵니다.

노트북 보안

서비스 계정

노트북에서 돌아가는 코드는 사용자 계정이 아니라 노트북에 붙은 서비스 계정의 권한으로 BigQuery와 Cloud Storage를 읽습니다. 이 구분이 시험에 나옵니다 — 사용자에게 권한을 줘도 서비스 계정에 없으면 코드가 실패하고, 반대로 서비스 계정에 넓은 권한이 붙어 있으면 그 노트북을 열 수 있는 사람이 그 권한을 그대로 씁니다. 그래서 서비스 계정에는 그 노트북이 실제로 필요한 것만 붙입니다.

네트워크와 경계

데이터를 프로젝트 밖으로 내보내지 않는 조건이면 셋을 함께 씁니다 — 공개 IP 없이 VPC 안에만 두기, 비공개 경로로 서비스에 접근하기, 그리고 VPC Service Controls 경계 안에 넣기. 개인 노트북으로 데이터를 내려받아 작업하는 보기가 늘 오답인 이유가 이 셋입니다. 노트북을 못 쓰게 하는 것이 아니라 노트북을 경계 안으로 들이는 것이 답의 방향입니다.

프로토타입 프레임워크

세 갈래

노트북 안에서는 무엇이든 씁니다. 자주 나오는 셋의 자리가 다릅니다.

• scikit-learn은 정형 데이터에 표준 알고리즘을 빠르게 붙이는 자리입니다. 기준선을 세우는 데 가장 싸고, 이 기준선을 넘지 못하는 딥러닝은 쓸 이유가 없습니다.
• PyTorch는 신경망을 직접 짜는 자리입니다. 이미지·텍스트·멀티모달에서 사실상 기본값이고 미리 학습된 모델 생태계가 넓습니다.
• JAX는 수치 계산과 자동 미분을 컴파일해 가속기에서 돌리는 쪽입니다. TPU에서 크게 돌리거나 연구성 구현을 할 때 고릅니다.

학습 작업으로 이관

프로토타입이 되면 노트북 셀을 스크립트로 빼고 학습 작업으로 제출합니다. 노트북에 붙은 GPU로 며칠을 돌리는 대신 작업이 끝나면 자원이 사라지고, 무엇보다 같은 실행을 다시 재현할 수 있게 됩니다.

from google.cloud import aiplatform

aiplatform.init(project="my-proj", location="us-central1", experiment="churn-tuning")

job = aiplatform.CustomJob.from_local_script(
    display_name="churn-dnn",
    script_path="train.py",
    container_uri="us-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-4:latest",
    machine_type="n1-standard-8",
    accelerator_type="NVIDIA_TESLA_T4",
    accelerator_count=1,
)
job.run()

Experiments

실행 기록

Experiments는 한 실험 아래에 여러 실행(run)을 두고, 실행마다 파라미터와 지표를 기록하는 기능입니다. 노트북에서 손으로 표에 적던 것을 플랫폼이 대신 들고 있습니다.

with aiplatform.start_run(run="lr-0003-depth-6") as run:
    run.log_params({"learning_rate": 0.003, "max_depth": 6})
    model = train(learning_rate=0.003, max_depth=6)
    run.log_metrics({"auc_pr": 0.812, "logloss": 0.243})

log_params는 내가 정한 설정값, log_metrics는 그 설정으로 나온 결과입니다. 둘을 바꿔 쓰면 비교가 성립하지 않습니다 — 학습률을 지표로 적어 두면 「학습률이 가장 높은 실행」을 고르게 됩니다.

비교

기록이 쌓이면 실행들을 한 표로 꺼내 정렬하고 비교합니다.

df = aiplatform.get_experiment_df(experiment="churn-tuning")
print(df.sort_values("metric.auc_pr", ascending=False).head())

표로 꺼내 놓고 나서 보는 것이 둘입니다. 하나는 어느 설정이 지표를 올렸는가이고, 다른 하나는 그 차이가 설정 때문인가입니다. 같은 설정을 두 번 돌렸을 때 지표가 크게 흔들리면 그 차이는 설정이 아니라 난수 때문이므로, 시드를 기록해 두지 않은 실행끼리 소수점 셋째 자리를 비교하는 것은 의미가 없습니다. 기록할 파라미터에 시드와 데이터 버전까지 넣어 두는 것이 여기서 값을 합니다.

이것이 Vizier와 다른 점입니다. Vizier는 다음에 무엇을 시도할지 골라 주고, Experiments는 이미 시도한 것을 기록합니다. 둘은 경쟁하지 않고 대개 함께 씁니다.

ML Metadata

계보

ML Metadata는 어떤 데이터가 어떤 실행을 거쳐 어떤 산출물이 됐는지를 그래프로 남기는 저장소입니다. 기록되는 것이 셋입니다 — 데이터셋·모델처럼 만들어진 것인 아티팩트, 그것을 만든 실행, 그리고 그 둘을 묶는 맥락입니다. 파이프라인을 돌리면 이 기록이 저절로 남습니다.

역추적

계보가 있으면 운영에서 문제가 난 모델에서 거꾸로 어떤 데이터와 어떤 코드로 학습됐는지를 따라갈 수 있습니다. 「학습에 쓴 테이블에 잘못된 행이 섞여 있었다」를 알았을 때 그 테이블로 학습된 모델이 무엇무엇인지 찾는 것도 같은 그래프입니다. 거꾸로도 씁니다 — 이 데이터셋이 어느 모델로 갔는가, 이 모델이 어느 엔드포인트에 배포됐는가를 같은 그래프에서 따라갑니다. 규제 대응에서 요구하는 재현성과 감사 추적이 이 자리이고, 노트북에서 손으로 돌린 실행은 아무 기록도 남기지 않는다는 것이 파이프라인으로 옮기는 이유 중 하나입니다.

연습 문제

1. 분석가 서른 명이 같은 노트북을 열어 보되 각자 VM을 만들고 관리하지는 않게 하려 합니다. 알맞은 것은?
   ① Workbench 인스턴스를 서른 개 만든다
   ② Colab Enterprise에서 런타임 템플릿을 정하고 노트북을 IAM으로 공유한다
   ③ 각자 개인 노트북에 데이터를 내려받는다
   ④ Dataproc 클러스터를 띄운다

   ②. 사양은 템플릿이 정하고 접근은 IAM이 나눕니다. ③은 데이터가 경계를 벗어나고, ①은 관리 부담이 서른 배가 됩니다.
2. 노트북 코드가 BigQuery 테이블을 읽지 못합니다. 사용자 계정에는 조회 권한이 있습니다. 먼저 볼 것은?
   ① 노트북에 붙은 서비스 계정의 권한
   ② 노트북의 머신 타입
   ③ 주피터 확장 버전
   ④ 유휴 종료 시간

   ①. 노트북 안의 코드는 서비스 계정 권한으로 돕니다. 사용자 권한과 별개입니다.
3. 다음 코드에서 잘못된 것은?

   run.log_params({"auc_pr": 0.812})
   run.log_metrics({"learning_rate": 0.003})

   ① 실행 이름이 없다
   ② 파라미터와 지표가 서로 바뀌었다
   ③ log_params는 딕셔너리를 받지 않는다
   ④ 아무 문제 없다

   ②. 학습률은 내가 정한 설정값이라 파라미터이고, AUC는 결과라 지표입니다. 바꿔 적으면 「지표가 가장 높은 실행」을 골랐을 때 학습률이 제일 큰 실행이 나옵니다.
4. 노트북에서 GPU를 붙여 사흘짜리 학습을 돌리고 있습니다. 비용과 재현성을 함께 개선하는 방법은?
   ① 노트북 머신 타입을 키운다
   ② 스크립트로 빼서 커스텀 학습 작업으로 제출한다
   ③ 유휴 종료 시간을 늘린다
   ④ 셀을 나눠 실행한다

   ②. 작업이 끝나면 자원이 사라지고 같은 실행을 다시 재현할 수 있습니다. ③은 반대로 요금이 더 나갑니다.
5. Vizier와 Experiments의 관계로 옳은 것은?
   ① 같은 일을 하는 두 제품이라 하나만 쓴다
   ② Vizier는 다음 시도를 고르고 Experiments는 시도한 것을 기록한다
   ③ Experiments가 하이퍼파라미터를 탐색한다
   ④ Vizier가 모델 계보를 남긴다

   ②. 역할이 다르고 함께 씁니다. ④의 계보는 ML Metadata의 일입니다.
6. 운영 중인 모델이 잘못된 예측을 내고, 학습에 쓴 테이블에 오류 행이 있었다는 것이 밝혀졌습니다. 그 테이블로 학습된 모델을 모두 찾으려면?
   ① Model Registry의 별칭을 본다
   ② ML Metadata의 계보를 따라간다
   ③ Experiments의 지표를 정렬한다
   ④ Model Monitoring 알림을 본다

   ②. 아티팩트와 실행의 그래프를 거슬러 올라가는 것이 계보의 용도입니다. ①은 버전을 가리킬 뿐 원천 데이터를 모릅니다.
7. 정형 데이터에 기준선 모델을 가장 싸게 세우려 합니다. 노트북에서 고를 프레임워크는?
   ① scikit-learn
   ② JAX
   ③ PyTorch로 직접 설계한 심층 신경망
   ④ 사전학습된 멀티모달 모델

   ①. 기준선은 싸고 빨라야 하고, 그 기준선을 못 넘는 복잡한 모델은 쓸 이유가 없습니다.
8. 노트북 요금이 예상보다 크게 나왔고 확인해 보니 인스턴스가 밤새 떠 있었습니다. 알맞은 조치는?
   ① 유휴 종료 시간을 설정한다
   ② GPU를 더 붙인다
   ③ 디스크를 키운다
   ④ 리전을 바꾼다

   ①. 일정 시간 작업이 없으면 자동으로 멈추고 디스크는 남아 작업이 보존됩니다.