모든 결과 뒤에 있는 근거를 다시 찾아보세요.

캠페인, 구성, 실행 구분하기

캠페인은 하나의 질문을 담습니다. 예를 들어 기준 모델과 개선된 버전을 비교하는 것입니다. 구성은 기술적 선택을 기술합니다. 런은 해당 구성을 실행한 하나의 시도로, 시드, 시작, 종료, 상태를 가집니다. 따라서 동일한 두 시도는 두 개의 식별자를 유지합니다. 두 번째가 중단된 첫 시도를 대체하더라도 마찬가지입니다.

동일한 아티팩트를 여러 데이터셋에서 또는 새로운 메트릭으로 평가할 경우 평가 식별자를 추가하세요. 이렇게 하면 새로운 모델과 기존 모델의 새로운 평가를 혼동하지 않습니다. 재개 시도를 이전 시도 및 로드된 체크포인트와 연결하세요.

MLflow 역시 런, 파라미터, 메트릭, 아티팩트를 중심으로 추적을 구성합니다. 이러한 구분은 단순한 파일 폴더에서도 유용합니다. 평소 사용하는 도구로 적용할 수 있으며, 시작하기 위해 특정 추적 플랫폼이 필요하지는 않습니다.

기술 출처: MLflow — 런, 파라미터, 메트릭, 아티팩트

실제로 실행된 매니페스트 작성하기

기본값과 실행 인자를 적용한 후의 최종 파라미터를 보관하세요. 원본 구성 파일은 기본 배치 크기나 실행 시 변경된 옵션을 누락할 수 있습니다. 실제로 사용된 것을 코드 사본 또는 변경 불가능한 리비전과 저장되지 않은 수정 사항의 상태와 함께 기록하세요.

매니페스트는 모델과 토크나이저 버전, 소프트웨어 환경, 실제 사용된 GPU, 정밀도, 데이터, 시드, 메트릭 정의도 연결합니다. 이는 설치 튜토리얼이 아니라 실험을 기술하는 것입니다. 단위를 명시하세요. 초, 바이트, 토큰, 포인트, 또는 측정값에 따라 0에서 1 사이의 비율을 사용합니다.

시작 시 상태는 진행 중이며, 종료 시 확인한 내용에 따라 완료, 실패 또는 중단이 됩니다. 잊고 기록하지 않은 버전을 현재 설치된 버전으로 나중에 채우지 마세요. 알 수 없는 정보는 표시하고 그것에 의존하는 결론을 제한하세요.

폴더 이름을 넘어 데이터 식별하기

donnees/final 같은 경로는 안정적인 버전을 가리키지 않습니다. 파일 또는 예시의 목록, 분할, 변환 절차를 보관하세요. 레이블을 수정하거나 행을 필터링하는 경우 새 버전을 만들고 이전 버전과의 관계를 유지하세요. 예전 점수는 계속 예전 데이터를 가리켜야 합니다.

Hugging Face Datasets는 캐시를 관리하기 위해 데이터셋의 상태와 변환에 지문(fingerprint)을 연결합니다. 이 메커니즘은 유용하지만 데이터의 출처와 전처리도 함께 보관해야 합니다. 특히 해시할 수 없는 변환은 무작위 지문을 초래할 수 있습니다. 캐시 식별자만으로는 출처 기록을 대체할 수 없습니다.

고정된 아티팩트의 경우 크기와 파일 지문을 추가하세요. 복사 전후에 계산한 SHA-256 다이제스트는 바이트가 보관된 참조와 일치하는지 확인할 수 있습니다. 그러나 레이블 품질, 사용 권리, 분할 간 누출 여부는 증명하지 않습니다.

기술 출처: Hugging Face Datasets — 지문과 변환 · Python 3.14 — hashlib를 사용한 파일 지문

메트릭, 예측, 아티팩트 연결하기

하나의 지표 라인은 run, 평가 대상 아티팩트, 평가 데이터셋, 지표 버전과 그 범위를 식별할 수 있어야 합니다. 값이 중간 체크포인트에 관한 것인지, 최종 모델인지, 아니면 하위 그룹인지 명시하세요. 선택한 지점에 어떤 파일이 대응하는지 더 이상 알 수 없다면 곡선 하나로는 충분하지 않습니다.

예측을 입력 식별자, 상태 및 평가에 필요한 정보와 함께 보존하세요. 기대 참조는 별도의 버전 관리 파일에 둘 수 있습니다. 구조화된 출력의 경우 원시 결과, 파싱된 결과, 판정을 구분하세요. 파싱을 수정한다고 해서 최초 출력을 덮어써서는 안 됩니다.

MLflow는 지표를 모델과 데이터에 연결할 수 있게 해줍니다. 파일을 사용할 때도 동일한 원칙을 명시적 식별자로 적용하세요. 아티팩트 목록을 읽기 쉽게 유지하세요. 가중치 또는 어댑터, 생성 파라미터, 출력, 평가 보고서, 결정 메모가 여기에 해당합니다. 스크린샷이 이런 파일을 대체한다고 가정하지 마세요.

기술 출처: MLflow — 지표, 모델, 데이터셋 연결

예시: 여섯 개의 run과 결측을 감추는 중복 하나

두 구성과 세 시드로 이루어진 분류 예시를 살펴봅시다. 이는 여섯 개의 예정된 run을 만들어냅니다. 각 run은 동일한 300개의 평가 식별자를 예측해야 하므로, 완전한 폴더에는 6 × 300 = 1,800개의 고유한 (run_id, input_id) 쌍이 있어야 합니다. 이 계산은 기대 목록을 설명할 뿐, 실제로 수행된 실험이 아닙니다.

어떤 파일에 300개의 행이 있지만 doc-042 식별자가 두 번 나타나고 doc-117이 없다고 가정해 봅시다. 전체 행 수는 맞는 것처럼 보이지만 고유 식별자는 299개뿐입니다. 이 run은 이상이 설명되고 수정될 때까지 커버리지 검사에서 실패합니다.

각 run이 이후 전체 코퍼스와 긴 텍스트 하위 그룹에서 평가된다면, 주어진 지표 하나에 대해 열두 개의 지표 라인을 얻게 됩니다. 이는 여전히 여섯 개의 run이며, 열두 개의 독립적인 학습이 아닙니다. 이 구분을 유지하려면 평가 키에 범위가 포함되어야 합니다.

읽기 쉬운 결정으로 폴더를 마무리하기

run을 완료로 선언하기 전에 파일의 존재와 열림 여부, 식별자 일치, 재계산 가능한 지표, 각 오류의 상태를 점검하세요. 기술적으로 완료된 시도라도 품질이 불충분하여 거부된 상태로 남을 수 있습니다. 이 두 상태를 분리해 두세요.

결정 메모에는 질문, 비교한 변형, 사전에 공표한 기준, 채택한 결과, 제외 이유를 모읍니다. "마지막 모델" 대신 run_id와 아티팩트 경로를 인용하세요. 한계도 덧붙이세요. 반복 횟수가 적음, 하위 그룹이 불충분함, 버전을 찾을 수 없음, 또는 비교가 불가능해짐 등이 여기에 해당합니다.

이후의 수정은 흔적을 남겨야 합니다. 새 평가, 새 보고서, 변경 이유가 그것입니다. 이전 결론은 식별된 이력 버전으로 보존하되, 현재의 결정으로 나타나지 않게 하세요. 마지막으로 내보낸 사본이 대상 폴더에서 열리는지 확인하세요.

불필요한 수집과 재현 약속 피하기

모든 환경 변수나 터미널 기록이 아니라 증명에 필요한 필드만 수집하세요. 구성이나 URL에 토큰이 포함될 수 있으므로, 비밀이 없는 공유 가능한 버전을 준비하고 비공개로 유지해야 할 데이터는 허용된 위치에 보관하세요. 기술적인 시험 식별자에 사람 이름을 포함할 필요는 없습니다.

완전한 폴더는 실험을 다시 수행하고 이해할 가능성을 높여줍니다. 하지만 플랫폼이나 버전 간의 수치적 동일성을 보장하지는 않습니다. PyTorch는 이러한 재현성 한계를 문서화하고 있습니다. 프로토콜 되찾기, 아티팩트 다시 불러오기, 수치를 정확히 재현하기를 구분하세요.

IteraGPU 노트북은 목표, 파라미터, 결정을 유용한 참조와 함께 보관할 수 있습니다. 하지만 run을 실행하거나 파일 또는 텔레메트리를 자동으로 수집하지는 않습니다. 이를 여러분의 사고 과정을 위한 색인으로 사용하고, 아티팩트 폴더는 여러분의 자체 백업에 보관하세요.

기술 출처: PyTorch 2.14 — 환경 간 재현성 한계

실용적인 질문