실험

실험은 프로젝트의 실행 가능성을 높이는 데 도움이 됩니다. 테스트 가능하고 재현 가능한 가설입니다. 실험을 실행할 때의 목표는 다양한 모델 아키텍처와 기능을 평가하여 지속적으로 개선하는 것입니다. 실험할 때는 다음을 실행하는 것이 좋습니다.

• 기준 성능을 결정합니다. 먼저 기준 측정항목을 설정합니다. 기준은 실험을 비교하는 측정 기준 역할을 합니다.

  경우에 따라 현재의 비 ML 솔루션이 첫 번째 기준점 측정항목을 제공할 수 있습니다. 현재 솔루션이 없는 경우 간단한 아키텍처와 몇 가지 기능으로 ML 모델을 만들고 측정항목을 기준으로 사용합니다.

• 작은 사항을 하나씩 변경합니다. 한 번에 하나의 작은 사항만 변경합니다(예: 초매개변수, 아키텍처, 기능). 변경사항으로 인해 모델이 개선되면 해당 모델의 측정항목이 향후 실험을 비교하는 새로운 기준이 됩니다.

  다음은 하나의 작은 변경사항을 적용하는 실험의 예입니다.

  • X 기능을 포함합니다.
  • 첫 번째 히든 레이어에서 0.5 드롭아웃을 사용합니다.
  • Y 기능의 로그 변환을 취합니다.
  • 학습률을 0.001로 변경합니다.

• 실험 진행 상황을 기록합니다. 실험을 많이 해야 할 가능성이 큽니다. 대조군에 비해 예측 품질이 좋지 않거나 중립적인 실험도 추적하는 데 유용합니다. 어떤 접근 방식이 효과가 없는지 알려줍니다. 진행률은 일반적으로 비선형이므로 기준 품질을 높이기 위한 진행 상황 외에도 효과가 없는 것으로 확인된 모든 방법을 강조 표시하여 문제를 해결하기 위해 노력하고 있음을 보여주는 것이 중요합니다.

실제 데이터 세트에서 각 전체 학습은 몇 시간 또는 며칠이 걸릴 수 있으므로 여러 개의 독립 실험을 동시에 실행하여 공간을 빠르게 탐색하는 것이 좋습니다. 반복을 거듭할수록 프로덕션에 필요한 품질 수준에 점점 더 가까워질 수 있습니다.

실험 결과의 노이즈

실험 결과에 모델이나 데이터 변경사항으로 인한 것이 아닌 노이즈가 발생할 수 있으므로, 내가 적용한 변경사항이 실제로 모델을 개선했는지 판단하기가 어려울 수 있습니다. 다음은 실험 결과에 노이즈를 일으킬 수 있는 요소의 예입니다.

• 데이터 셔플: 데이터가 모델에 표시되는 순서는 모델의 성능에 영향을 줄 수 있습니다.

• 변수 초기화: 모델의 변수가 초기화되는 방식도 성능에 영향을 줄 수 있습니다.

• 비동기 병렬 처리: 모델이 비동기 병렬 처리를 사용하여 학습되는 경우 모델의 여러 부분이 업데이트되는 순서도 성능에 영향을 미칠 수 있습니다.

• 소규모 평가 세트: 평가 세트가 너무 작으면 모델의 전반적인 성능을 대표하지 못하여 모델 품질에 불균등한 변동이 발생할 수 있습니다.

실험을 여러 번 실행하면 실험 결과를 확인하는 데 도움이 됩니다.

실험 관행을 조정합니다.

팀은 정의된 관행과 아티팩트를 바탕으로 '실험'이 정확히 무엇인지 명확하게 이해해야 합니다. 다음 사항을 요약한 문서를 준비해야 합니다.

• 아티팩트 실험의 아티팩트란 무엇인가요? 대부분의 경우 실험은 일반적으로 실험 간의 변화와 모델 품질에 미치는 영향을 나타내는 메타데이터 (예: 특성 및 하이퍼파라미터)를 로깅하여 재현할 수 있는 테스트된 가설입니다.

• 코딩 방법 모든 사용자가 자체 실험 환경을 사용하나요? 모든 사용자의 작업을 공유 라이브러리로 통합하는 것이 얼마나 가능하거나 쉬울까요?

• 재현성 및 추적. 재현성의 표준은 무엇인가요? 예를 들어 팀에서 동일한 데이터 파이프라인과 버전 관리 관행을 사용해야 하나요? 아니면 플롯만 표시해도 되나요? 실험 데이터는 SQL 쿼리로 저장되나요, 아니면 모델 스냅샷으로 저장되나요? 각 실험의 로그는 어디에 문서화되나요? 문서, 스프레드시트, 실험 관리용 CMS 중 어디에 문서화되나요?

잘못된 예측

완벽한 실제 모델은 없습니다. 시스템은 잘못된 예측을 어떻게 처리하나요? 문제를 해결하는 방법을 미리 생각해 보세요.

권장사항 전략은 사용자가 잘못된 예측에 올바른 라벨을 지정하도록 유도합니다. 예를 들어 메일 앱은 사용자가 스팸 폴더로 이동한 이메일과 그 반대의 경우를 기록하여 잘못 분류된 이메일을 캡처합니다. 사용자로부터 정답 라벨을 캡처하여 데이터 수집 및 모델 재학습을 위한 자동화된 피드백 루프를 설계할 수 있습니다.

UI에 삽입된 설문조사는 사용자 의견을 수집하지만, 데이터는 일반적으로 정성적이며 재학습 데이터에 통합할 수 없습니다.

엔드 투 엔드 솔루션 구현

팀에서 모델을 실험하는 동안 최종 파이프라인의 일부를 빌드하는 것이 좋습니다 (리소스가 있는 경우).

데이터 수집 및 모델 재학습과 같은 파이프라인의 여러 부분을 설정하면 최종 모델을 프로덕션으로 더 쉽게 이동할 수 있습니다. 예를 들어 데이터를 처리하고 예측을 제공하는 엔드 투 엔드 파이프라인을 가져오면 팀에서 모델을 제품에 통합하고 초기 사용자 테스트를 시작하는 데 도움이 될 수 있습니다.

중단된 프로젝트 문제 해결

프로젝트 진행이 중단되는 시나리오가 있을 수 있습니다. 팀에서 유망한 실험을 진행하고 있지만 몇 주 동안 모델을 개선하지 못하고 있을 수 있습니다. 어떻게 해야 할까요? 다음은 가능한 접근 방식입니다.

• 전략. 문제를 재구성해야 할 수도 있습니다. 실험 단계에서 시간을 보낸 후에는 문제, 데이터, 가능한 해결책을 더 잘 이해하게 됩니다. 도메인에 대한 지식을 더 깊이 있으면 문제를 더 정확하게 파악할 수 있습니다.

  예를 들어 처음에는 선형 회귀를 사용하여 숫자 값을 예측하려고 했습니다. 안타깝게도 데이터가 실행 가능한 선형 회귀 모델을 학습하기에 충분하지 않았습니다. 추가 분석 결과, 예시가 특정 값보다 높거나 낮은지 예측하여 문제를 해결할 수 있다는 것을 알 수 있습니다. 이렇게 하면 문제를 이진 분류 문제로 재구성할 수 있습니다.

  진행 속도가 예상보다 느리더라도 포기하지 마세요. 시간이 지남에 따라 점진적으로 개선하는 것이 문제를 해결하는 유일한 방법일 수 있습니다. 앞서 언급했듯이 매주 동일한 양의 진행이 이루어지리라고 기대하지 마세요. 프로덕션 버전의 모델을 얻는 데 상당한 시간이 걸리는 경우가 많습니다. 모델 개선은 불규칙하고 예측할 수 없습니다. 진전이 느린 기간이 지나면 개선이 급증하거나 그 반대가 될 수 있습니다.

• 기술. 잘못된 예측을 진단하고 분석하는 데 시간을 할애합니다. 경우에 따라 잘못된 예측을 몇 개 분리하고 이러한 인스턴스에서 모델의 동작을 진단하여 문제를 찾을 수 있습니다. 예를 들어 아키텍처 또는 데이터에 문제가 있을 수 있습니다. 다른 경우에는 더 많은 데이터를 가져오는 것이 도움이 될 수 있습니다. 올바른 방향으로 가고 있음을 나타내는 더 명확한 신호를 얻을 수도 있고, 접근 방식에 다른 문제가 있음을 나타내는 더 많은 노이즈가 발생할 수도 있습니다.

  사람이 라벨을 지정한 데이터 세트가 필요한 문제를 해결하는 경우 모델 평가를 위한 라벨이 지정된 데이터 세트를 얻기가 어려울 수 있습니다. 평가에 필요한 데이터 세트를 가져오는 리소스를 찾습니다.

해결 방법이 없을 수도 있습니다. 접근 방식에 타임박스를 적용하고 기간 내에 진전이 없으면 중단합니다. 그러나 강력한 문제 진술이 있다면 해결책이 필요할 가능성이 높습니다.

이해도 확인