실험은 프로젝트의 실행 가능성을 높여 줍니다. 검증 및 재현 가능한 가설입니다. 실험을 실행할 때 목표는 다양한 모델 아키텍처와 기능을 평가하여 지속적으로 점진적으로 개선하는 것입니다. 실험할 때는 다음과 같이 하는 것이 좋습니다.
기준 성능을 확인합니다. 먼저 기준 측정항목을 설정합니다. 기준은 실험의 비교 기준 역할을 합니다.
경우에 따라 현재의 비 ML 솔루션이 첫 번째 기준 측정항목을 제공할 수 있습니다. 현재 솔루션이 없는 경우 간단한 아키텍처와 몇 가지 특성으로 ML 모델을 만들고 측정항목을 기준으로 사용합니다.
작은 변경사항 하나만 적용합니다. 예를 들어 초매개변수, 아키텍처, 특성 등을 한 번에 조금만 변경합니다 이러한 변경으로 모델이 개선되면 해당 모델의 측정항목이 향후 실험을 비교할 새로운 기준이 됩니다.
다음은 작은 변화 하나를 만드는 실험의 예입니다.
- X 기능을 포함합니다.
- 첫 번째 히든 레이어에 0.5 드롭아웃을 사용합니다.
- 특성 Y의 로그 변환을 사용합니다.
- 학습률을 0.001로 변경합니다.
실험 진행 상황을 기록합니다. 아마도 많은 실험을 해야 할 것입니다. 기준과 비교했을 때 예측 품질이 낮거나 중립적인 실험도 추적에 유용합니다. 어떤 접근 방식이 효과가 없는지 신호를 보냅니다. 진행 상황은 일반적으로 비선형이므로, 기준 품질을 향상하기 위한 진행 상황 외에 효과가 없는 것으로 확인된 모든 방법을 강조하여 문제를 해결하고 있음을 보여주는 것이 중요합니다.
실제 데이터 세트에 대한 전체 학습에는 몇 시간 (또는 며칠)이 걸릴 수 있으므로 해당 공간을 빠르게 탐색하려면 여러 개의 독립적인 실험을 동시에 실행하는 것이 좋습니다. 반복을 거듭할수록 프로덕션에 필요한 품질 수준에 가까워질 것입니다.
실험 결과의 노이즈
실험 결과에서 모델 또는 데이터 변경으로 인한 것이 아닌 노이즈가 발생할 수 있으므로, 변경사항으로 인해 실제로 모델이 개선되었는지 판단하기 어려울 수 있습니다. 다음은 실험 결과에서 노이즈를 생성할 수 있는 요인의 예입니다.
데이터 셔플링: 모델에 데이터가 표시되는 순서는 모델의 성능에 영향을 줄 수 있습니다.
변수 초기화: 모델의 변수가 초기화되는 방식이 성능에 영향을 줄 수 있습니다.
비동기 동시 로드: 비동기식 동시 로드를 사용하여 모델을 학습시키면 모델의 여러 부분이 업데이트되는 순서도 성능에 영향을 줄 수 있습니다.
작은 평가 세트: 평가 세트가 너무 작으면 모델의 전체 성능을 제대로 나타내지 못하여 모델 품질에 불균일한 편차가 발생할 수 있습니다.
실험을 여러 번 실행하면 실험 결과를 확인하는 데 도움이 됩니다.
실험 관행에 대해 합의하기
팀은 일련의 정의된 관행과 아티팩트를 통해 '실험'이 정확히 무엇인지 명확하게 이해해야 합니다. 다음 사항을 설명하는 문서가 필요합니다.
아티팩트. 실험의 아티팩트는 무엇인가요? 대부분의 경우 실험은 일반적으로 실험 간 변경사항과 모델 품질에 미치는 영향을 나타내는 메타데이터 (예: 특성 및 초매개변수)를 로깅하여 재현할 수 있는 테스트된 가설입니다.
코딩 관행. 모든 사용자가 자신만의 실험 환경을 사용하나요? 모든 사람의 작업을 공유 라이브러리에 얼마나 쉽게 통합할 수 있나요?
재현성 및 추적. 재현성의 기준은 무엇인가요? 예를 들어 팀이 동일한 데이터 파이프라인 및 버전 관리 방법을 사용해야 할까요, 아니면 그래프만 표시해도 괜찮을까요? 실험 데이터는 어떻게 SQL 쿼리로 저장되나요, 아니면 모델 스냅샷으로 저장되나요? 각 실험의 로그는 실험 관리를 위한 문서, 스프레드시트, CMS 중 어디에 문서화되나요?
잘못된 예측
실제 모델은 완벽할 수 없습니다. 시스템은 잘못된 예측을 어떻게 처리하나요? 이에 대처하는 방법에 대해 일찍 생각하십시오.
권장사항 전략은 사용자가 잘못된 예측에 올바르게 라벨을 지정하도록 권장합니다. 예를 들어 메일 앱은 사용자가 스팸 폴더로 이동하는 메일을 로깅하거나 그 반대의 경우도 기록하여 잘못 분류된 이메일을 캡처합니다. 사용자로부터 정답 라벨을 캡처하여 데이터 수집 및 모델 재학습을 위한 자동화된 피드백 루프를 설계할 수 있습니다.
UI 삽입 설문조사는 사용자 의견을 수집하지만 데이터는 일반적으로 정성적이며 재학습 데이터에 통합할 수 없습니다.
엔드 투 엔드 솔루션 구현
팀에서 모델을 실험하는 동안 최종 파이프라인의 일부를 구축하는 것이 좋습니다 (할 수 있는 리소스가 있는 경우).
데이터 수집 및 모델 재학습과 같은 파이프라인의 여러 부분을 설정하면 최종 모델을 프로덕션으로 더 쉽게 이전할 수 있습니다. 예를 들어 데이터를 수집하고 예측을 제공하기 위한 엔드 투 엔드 파이프라인을 확보하면 팀이 모델을 제품에 통합하고 초기 단계의 사용자 테스트를 수행하는 데 도움이 될 수 있습니다.
중단된 프로젝트 문제 해결
프로젝트 진행이 중단되는 경우가 있을 수 있습니다. 유망한 실험을 진행했지만 몇 주 동안 모델을 개선하는 데 성공하지 못한 팀이 있을 수 있습니다. 어떻게 해야 하나요? 가능한 접근 방식은 다음과 같습니다.
전략. 문제를 재구성해야 할 수도 있습니다. 실험 단계에서 시간을 보낸 후에는 문제와 데이터, 가능한 솔루션을 더 잘 이해할 수 있습니다. 도메인에 대한 깊이 있는 지식을 바탕으로 문제를 더 정확하게 프레이밍할 수 있습니다
예를 들어 처음에 선형 회귀를 사용하여 숫자 값을 예측하려고 했을 수 있습니다. 하지만 선형 회귀 모델을 학습시키기에 충분한 데이터가 아닙니다. 어쩌면 추가 분석을 통해 예가 특정 값보다 크거나 낮은지 여부를 예측하여 문제를 해결할 수 있음을 알 수도 있습니다. 이를 통해 문제를 이진 분류로 재구성할 수 있습니다.
진행 속도가 예상보다 느리더라도 포기하지 마세요. 시간 경과에 따른 점진적인 개선이 문제를 해결하는 유일한 방법일 수 있습니다. 앞서 언급했듯이 매주 동일한 양의 진행 상황이 발생하지는 않습니다. 프로덕션에 즉시 사용 가능한 모델 버전을 얻는 데 상당한 시간이 필요한 경우가 많습니다. 모델 개선은 불규칙하고 예측할 수 없습니다. 진행이 느리면 개선이 급증하거나 그 반대로 발전할 수 있습니다.
기술. 잘못된 예측을 진단하고 분석하는 데 시간을 할애합니다. 경우에 따라 몇 가지 잘못된 예측을 격리하고 이러한 인스턴스에서 모델의 동작을 진단하여 문제를 찾을 수 있습니다. 예를 들어 아키텍처나 데이터에 관한 문제를 발견할 수 있습니다. 다른 경우에는 더 많은 데이터를 얻는 것이 도움이 될 수 있습니다. 올바른 방향으로 나아가고 있음을 나타내는 더 명확한 신호를 얻거나 더 많은 노이즈를 생성하여 접근 방식에 다른 문제가 있음을 나타낼 수 있습니다.
사람이 라벨을 지정한 데이터 세트가 필요한 문제를 해결하는 경우 모델 평가를 위해 라벨이 지정된 데이터 세트를 가져오기가 어려울 수 있습니다. 리소스를 찾아 평가에 필요한 데이터 세트를 가져옵니다.
해결 방법이 없을 수도 있습니다. 접근 방식에 타임 박스를 넣고, 기간 내에 진전이 없는 경우 중지합니다. 하지만 문제가 되는 구문이 있다면 해결 방법이 필요할 가능성이 높습니다