ML 파이프라인

프로덕션 ML의 목표는 단일 모델을 빌드하고 배포하는 것이 아닙니다. 목표는 시간 경과에 따라 모델을 개발, 테스트, 배포하기 위한 자동화된 파이프라인을 빌드하는 것입니다. 왜냐하면 세상이 변화하면 데이터 트렌드가 변화하여 프로덕션의 모델이 노후화됩니다. 일반적으로 모델은 장기적으로 고품질 예측을 계속 제공하려면 최신 데이터로 재학습해야 합니다. 즉, 오래된 모델을 새 모델로 교체하는 방법이 필요합니다.

파이프라인이 없으면 오래된 모델을 교체할 때 오류가 발생하기 쉽습니다. 예를 들어 모델이 잘못된 예측을 제공하기 시작하면 누군가 수동으로 새 데이터를 수집 및 처리하고, 새 모델을 학습시키고, 품질을 검증한 후에 모델을 배포해야 합니다. ML 파이프라인은 이러한 반복적인 프로세스를 상당수 자동화하여 보다 효율적이고 안정적으로 모델을 관리하고 유지보수합니다.

파이프라인 빌드

ML 파이프라인은 모델을 빌드하고 잘 정의된 태스크로 배포하는 단계를 구성합니다 파이프라인에는 예측 전달 또는 모델 업데이트의 두 가지 기능 중 하나가 있습니다

예측 제공

서빙 파이프라인은 예측을 제공합니다. 모델을 실제 세상에 공개하므로 사용자가 액세스할 수 있습니다 예를 들어 사용자가 내일 날씨, 공항까지 가는 데 몇 분 정도 걸리는지, 맞춤 동영상 목록을 원하는 경우 제공 파이프라인은 사용자의 데이터를 수신 및 처리한 후 예측한 후 이를 사용자에게 전송합니다.

모델 업데이트

모델은 프로덕션으로 전환된 직후부터 비활성 상태가 되는 경향이 있습니다. 본질적으로 오래된 정보를 사용하여 예측을 수행합니다. 이들의 학습 데이터 세트는 하루 전, 경우에 따라서는 한 시간 전 세계의 상태를 포착했습니다. 필연적으로 세상은 변화했습니다. 사용자는 더 많은 동영상을 시청하고 새로운 추천 목록이 필요하고, 비로 인해 교통량이 줄었고, 사용자는 예상 도착 시간을 업데이트해야 합니다. 인기 있는 추세로 인해 소매업체는 특정 상품에 대한 업데이트된 인벤토리 예측을 요청합니다.

일반적으로 팀은 프로덕션 모델이 노후화되기 한참 전에 새 모델을 학습시킵니다. 경우에 따라 팀은 지속적인 학습 및 배포 주기로 매일 새 모델을 학습시키고 배포합니다. 이상적으로는 프로덕션 모델이 비활성화되기 훨씬 전에 새 모델을 학습시키는 것이 좋습니다.

다음 파이프라인이 함께 작동하여 새 모델을 학습시킵니다.

  • 데이터 파이프라인. 데이터 파이프라인은 사용자 데이터를 처리하여 학습 및 테스트 데이터 세트를 만듭니다.
  • 학습 파이프라인. 학습 파이프라인은 데이터 파이프라인의 새 학습 데이터 세트를 사용하여 모델을 학습시킵니다.
  • 검증 파이프라인. 검증 파이프라인은 데이터 파이프라인에서 생성된 테스트 데이터 세트로 학습된 모델을 프로덕션 모델과 비교하여 검증합니다.

그림 4는 각 ML 파이프라인의 입력과 출력을 보여줍니다.

ML 파이프라인

입력과 출력을 보여주는 ML 파이프라인 서빙 파이프라인은 사용자 입력을 받아 예측을 제공합니다. 데이터 파이프라인은 애플리케이션 데이터 로그를 처리하여 학습 및 검증 파이프라인이 새 모델을 학습시키고 검증하는 데 사용하는 학습 및 테스트 데이터 세트를 만듭니다.

그림 4. ML 파이프라인은 모델 개발 및 유지보수를 위한 수많은 프로세스를 자동화합니다 각 파이프라인은 입력과 출력을 보여줍니다.

일반적으로 파이프라인이 프로덕션에서 새 모델을 유지하는 방법은 다음과 같습니다.

  1. 먼저 모델이 프로덕션으로 전환되고 서빙 파이프라인이 예측 제공을 시작합니다.

  2. 데이터 파이프라인이 즉시 데이터 수집을 시작하여 새 학습 및 테스트 데이터 세트를 생성합니다.

  3. 일정 또는 트리거에 따라 학습 및 검증 파이프라인은 데이터 파이프라인에서 생성된 데이터 세트를 사용하여 새 모델을 학습시키고 검증합니다.

  4. 유효성 검사 파이프라인에서 새 모델이 프로덕션 모델보다 나쁘지 않음을 확인하면 새 모델이 배포됩니다.

  5. 이 프로세스가 계속 반복됩니다.

모델 비활성 및 학습 빈도

거의 모든 모델이 비활성 상태입니다. 일부 모델은 다른 모델보다 더 빨리 비활성 상태가 됩니다. 예를 들어 의류를 추천하는 모델은 일반적으로 소비자 선호도가 자주 바꾸기로 악명이 높기 때문에 빠르게 노후화됩니다. 반면에 꽃을 식별하는 모델은 노후화되지 않을 수도 있습니다. 꽃의 식별 특성은 안정적으로 유지됩니다.

대부분의 모델은 프로덕션으로 전환되는 즉시 노후화되기 시작합니다. 데이터의 특성을 반영하는 학습 빈도를 설정하는 것이 좋습니다. 데이터가 동적인 경우 자주 학습합니다. 덜 동적이라면 이렇게 자주 학습시킬 필요가 없습니다.

비활성 상태가 되기 전에 모델을 학습시킵니다. 초기 학습은 데이터 또는 학습 파이프라인이 실패하거나 모델 품질이 낮은 경우와 같이 잠재적인 문제를 해결하기 위한 버퍼를 제공합니다.

매일 새 모델을 학습시키고 배포하는 것이 좋습니다. 매일 빌드 및 출시 프로세스가 있는 일반 소프트웨어 프로젝트와 마찬가지로 학습 및 검증용 ML 파이프라인은 종종 매일 실행될 때 가장 잘 작동합니다.

서빙 파이프라인

제공 파이프라인은 온라인 또는 오프라인이라는 두 가지 방법 중 하나로 예측을 생성하고 제공합니다.

  • 온라인 예측. 온라인 예측은 일반적으로 온라인 서버에 요청을 전송하고 예측을 반환하는 방식으로 실시간으로 이루어집니다. 예를 들어 사용자가 예측을 원하는 경우 사용자의 데이터가 모델로 전송되고 모델이 예측을 반환합니다. 예를 들어 Gmail은 온라인 예측을 사용하여 실시간으로 수신 메시지를 분류합니다.

  • 오프라인 예측. 오프라인 예측은 미리 계산되고 캐시됩니다. 예측을 제공하기 위해 앱은 데이터베이스에서 캐시된 예측을 찾아 반환합니다. 예를 들어 정기 결제 기반 서비스는 정기 결제 사용자의 이탈률을 예측할 수 있습니다. 이 모델은 모든 구독자의 이탈 가능성을 예측하고 이를 캐시합니다. 앱에서 앱 제거가 예상되는 사용자에게 인센티브를 제공하기 위해 예측이 필요한 경우 미리 계산된 예측을 조회할 뿐입니다.

그림 5는 온라인 및 오프라인 예측이 생성되고 전달되는 방식을 보여줍니다.

온라인 및 오프라인 예측

예측을 실시간으로 전달할 수도 있고 일괄 처리 및 캐시 처리된 조회를 위해 캐시할 수도 있습니다.

그림 5. 온라인 예측은 실시간으로 예측을 제공합니다. 오프라인 예측은 캐시되고 서빙 시에 조회됩니다.

예측 후처리

일반적으로 예상 검색어는 전달되기 전에 후처리됩니다. 예를 들어 악의적이거나 편향된 콘텐츠를 삭제하기 위해 예측이 후처리될 수 있습니다. 분류 결과는 모델의 원시 출력을 표시하는 대신 트위들링을 사용하여 결과를 재정렬할 수 있습니다. 예를 들어 더 공신력 있는 콘텐츠를 높이거나, 결과의 다양성을 높이거나, 클릭베이트와 같은 특정 결과의 순위를 낮추거나, 법적인 이유로 결과를 삭제할 수 있습니다.

그림 6은 서빙 파이프라인 및 예측 제공과 관련된 일반적인 작업을 보여줍니다.

후처리 예측

서빙 파이프라인은 일반적으로 예측 후처리입니다.

그림 6. 예측 제공과 관련된 일반적인 작업을 보여주는 서빙 파이프라인

특성 추출 단계는 일반적으로 별도의 독립된 프로세스가 아니라 모델 내에서 빌드됩니다. 서빙 파이프라인의 데이터 처리 코드는 데이터 파이프라인이 학습 및 테스트 데이터 세트를 만드는 데 사용하는 데이터 처리 코드와 거의 동일한 경우가 많습니다.

애셋 및 메타데이터 스토리지

서빙 파이프라인은 모델 예측과 가능한 경우 정답을 로깅하는 저장소를 통합해야 합니다.

모델 예측을 로깅하면 모델의 품질을 모니터링할 수 있습니다. 예측을 집계하여 모델의 일반적인 품질을 모니터링하고 품질이 저하되기 시작하는지 확인할 수 있습니다. 일반적으로 프로덕션 모델의 예측은 학습 데이터 세트의 라벨과 동일한 평균을 가져야 합니다. 자세한 내용은 예측 편향을 참조하세요.

정답 캡처

경우에 따라 정답은 훨씬 나중에 사용할 수 있게 됩니다. 예를 들어 날씨 앱이 미래의 6주 후 날씨를 예측하면 6주 동안 정답 (실제 날씨)을 사용할 수 없습니다.

가능한 경우 앱에 의견 메커니즘을 추가하여 사용자가 정답을 보고하도록 합니다. Gmail은 사용자가 받은편지함에서 스팸 폴더로 메일을 이동할 때 사용자 의견을 암시적으로 캡처합니다. 하지만 이 방법은 사용자가 메일을 올바르게 분류하는 경우에만 작동합니다. 사용자가 스팸임을 알고 있으며 스팸 메일을 열지 않아 받은편지함에 스팸을 보관할 경우 학습 데이터가 부정확해집니다. 메일의 특정 부분이 '스팸'으로 분류되면 '스팸 아님'으로 표시됩니다. 즉, 항상 정답을 캡처하고 기록하는 방법을 찾으려고 노력하되, 피드백 메커니즘에 있을 수 있는 단점에 유의해야 합니다.

그림 7에서는 사용자에게 제공되고 저장소에 로깅되는 예측을 보여줍니다.

예측 로깅

서빙 파이프라인은 모델 비활성을 모니터링하기 위해 예측을 로깅해야 합니다.

그림 7. 예측을 로깅하여 모델 품질을 모니터링합니다.

데이터 파이프라인

데이터 파이프라인은 애플리케이션 데이터에서 학습 및 테스트 데이터 세트를 생성합니다. 그러면 학습 및 검증 파이프라인이 데이터 세트를 사용하여 새 모델을 학습시키고 검증합니다.

데이터 파이프라인은 원래 모델 학습에 사용된 특성과 라벨이 동일하지만 더 새로운 정보가 있는 학습 및 테스트 데이터 세트를 만듭니다. 예를 들어 지도 앱은 수백만 사용자의 지점 간 최근 이동 시간을 바탕으로 날씨와 같은 기타 관련 데이터와 함께 학습 및 테스트 데이터 세트를 생성합니다.

동영상 추천 앱은 사용자가 추천 목록에서 클릭한 동영상 (클릭하지 않은 동영상 포함)과 시청 기록과 같은 기타 관련 데이터가 포함된 학습 및 테스트 데이터 세트를 생성합니다.

그림 8은 애플리케이션 데이터를 사용하여 학습 및 테스트 데이터 세트를 생성하는 데이터 파이프라인을 보여줍니다.

데이터 파이프라인

데이터 파이프라인은 학습 및 테스트 데이터 세트를 생성합니다.

그림 8. 데이터 파이프라인은 애플리케이션 데이터를 처리하여 학습 및 검증 파이프라인용 데이터 세트를 만듭니다.

데이터 수집 및 처리

데이터 파이프라인에서 데이터를 수집하고 처리하는 작업은 아마도 솔루션이 실행 가능하다고 판단한 실험 단계와 다를 수 있습니다.

  • 데이터 수집. 실험 중에 데이터를 수집하려면 일반적으로 저장된 데이터에 액세스해야 합니다 데이터 파이프라인의 경우 데이터를 수집하려면 스트리밍 로그 데이터에 액세스하기 위한 탐색 및 승인이 필요할 수 있습니다.

    의료 이미지와 같이 사람이 라벨을 지정한 데이터가 필요한 경우 데이터를 수집하고 업데이트하는 프로세스도 필요합니다. 사람이 라벨을 지정한 데이터가 필요한 경우 CrowdCompute 페이지를 참조하세요.

  • 데이터 처리. 실험 중에 적절한 특성은 실험 데이터 세트의 스크래핑, 조인, 샘플링에서 비롯되었습니다 데이터 파이프라인의 경우 동일한 특성을 생성하는 데 완전히 다른 프로세스가 필요할 수 있습니다. 단, 특성과 라벨에 동일한 수학적 연산을 적용하여 실험 단계의 데이터 변환을 복제해야 합니다.

애셋 및 메타데이터 스토리지

학습 및 테스트 데이터 세트의 저장, 버전 관리, 관리 프로세스가 필요합니다. 버전 제어 저장소는 다음과 같은 이점을 제공합니다.

  • 재현성. 모델 학습 환경을 다시 만들고 표준화하고 여러 모델 간의 예측 품질을 비교합니다

  • 규정 준수. 감사 가능성과 투명성을 위한 규정 준수 요구사항을 준수합니다.

  • 보관. 데이터 보관 기간에 대한 데이터 보관 값을 설정합니다.

  • 액세스 관리. 세분화된 권한을 통해 데이터에 액세스할 수 있는 사용자를 관리합니다.

  • 데이터 무결성. 시간 경과에 따른 데이터 세트의 변경사항을 추적하고 이해하여 데이터 또는 모델의 문제를 더 쉽게 진단할 수 있습니다.

  • 검색 가능성. 다른 사용자가 데이터 세트와 특성을 쉽게 찾을 수 있게 하세요. 그러면 다른 팀에서 자신의 용도에 유용한지 판단할 수 있습니다.

데이터 문서화

좋은 문서는 다른 사용자가 데이터 유형, 소스, 크기, 기타 필수 메타데이터와 같은 데이터에 관한 주요 정보를 이해하는 데 도움이 됩니다. 대부분의 경우 데이터를 디자인 문서나 g3doc에 문서화하는 것으로 충분합니다. 데이터를 공유하거나 게시할 계획이라면 데이터 카드를 사용하여 정보를 구조화하세요. 데이터 카드를 사용하면 다른 사용자가 데이터 세트를 쉽게 찾고 이해할 수 있습니다

학습 및 검증 파이프라인

학습 및 검증 파이프라인은 비활성 상태가 되기 전에 프로덕션 모델을 대체할 새 모델을 생성합니다. 새로운 모델을 지속적으로 학습시키고 검증하면 항상 최상의 모델이 프로덕션에 배포됩니다

학습 파이프라인은 학습 데이터 세트에서 새 모델을 생성하고 검증 파이프라인은 테스트 데이터 세트를 사용하여 새 모델과 프로덕션 모델의 품질을 비교합니다.

그림 9는 학습 데이터 세트를 사용하여 새 모델을 학습시키는 학습 파이프라인을 보여줍니다.

학습 파이프라인

학습 파이프라인은 새 데이터를 기반으로 새 모델을 학습시킵니다.

그림 9. 학습 파이프라인은 최신 학습 데이터 세트를 사용하여 새 모델을 학습시킵니다.

모델이 학습되면 검증 파이프라인은 테스트 데이터 세트를 사용하여 프로덕션 모델의 품질을 학습된 모델과 비교합니다.

일반적으로 학습된 모델이 프로덕션 모델보다 유의미하지 않으면 학습된 모델이 프로덕션으로 전환됩니다. 학습된 모델이 더 좋지 않은 경우 모니터링 인프라에서 알림을 만들어야 합니다 예측 품질이 낮은 학습된 모델은 데이터 또는 검증 파이프라인에 잠재적인 문제가 있음을 나타낼 수 있습니다. 이 접근 방식은 최신 데이터로 학습된 최상의 모델이 항상 프로덕션에 있도록 하는 데 효과적입니다.

애셋 및 메타데이터 스토리지

모델 및 모델의 메타데이터를 버전이 지정된 저장소에 저장하여 모델 배포를 구성하고 추적해야 합니다. 모델 저장소에는 다음과 같은 이점이 있습니다.

  • 추적 및 평가. 프로덕션 환경에서 모델을 추적하고 평가 및 예측 품질 측정항목을 이해합니다

  • 모델 출시 프로세스. 모델을 간편하게 검토, 승인, 출시, 롤백할 수 있습니다

  • 재현성 및 디버깅. 여러 배포에서 모델의 데이터 세트와 종속 항목을 추적하여 모델 결과를 재현하고 문제를 더 효과적으로 디버그합니다.

  • 검색 가능성. 다른 사용자가 모델을 쉽게 찾을 수 있게 하세요. 그러면 다른 팀에서 모델 (또는 모델의 일부)을 해당 용도로 사용할 수 있는지 여부를 결정할 수 있습니다.

그림 10은 모델 저장소에 저장된 검증된 모델을 보여줍니다.

모델 스토리지

버전이 지정된 저장소에 모델 저장

그림 10. 검증된 모델은 추적 및 검색 가능성을 위해 모델 저장소에 저장됩니다.

모델 카드를 사용하여 모델의 목적, 아키텍처, 하드웨어 요구사항, 평가 측정항목 등 모델에 대한 주요 정보를 문서화하고 공유할 수 있습니다.

파이프라인 빌드의 과제

파이프라인을 빌드할 때 다음과 같은 문제가 발생할 수 있습니다.

  • 필요한 데이터에 액세스하기 데이터 액세스에 필요한 이유를 제시해야 할 수 있습니다. 예를 들어 데이터가 사용되는 방법을 설명하고 PII 문제를 해결하는 방법을 명확히 해야 할 수 있습니다. 모델이 특정 종류의 데이터에 액세스하여 더 나은 예측을 수행하는 방법을 보여주는 개념 증명을 표시할 수 있도록 준비하세요.

  • 적합한 기능 얻기. 경우에 따라 실험 단계에서 사용되는 기능을 실시간 데이터에서 사용할 수 없습니다. 따라서 실험할 때는 프로덕션에서 동일한 기능을 사용할 수 있는지 확인하세요.

  • 데이터 수집 및 표현 방식 이해하기 데이터가 수집되는 방식과 수집하는 사람, 데이터 수집 방식을 파악하는 데 다른 문제와 함께 시간과 노력이 필요할 수 있습니다. 데이터를 철저히 이해하는 것이 중요합니다. 프로덕션이 될 수 있는 모델을 학습시키는 데 확신이 없는 데이터를 사용하지 마세요.

  • 노력, 비용, 모델 품질 간의 균형 이해 새로운 특성을 데이터 파이프라인에 통합하려면 많은 노력이 필요할 수 있습니다. 그러나 추가 특성으로 인해 모델의 품질이 약간 향상될 수 있습니다. 그렇지 않은 경우에는 새 기능을 쉽게 추가할 수도 있습니다. 그러나 이 특성을 가져오고 저장하는 데 사용되는 리소스는 엄청나게 비쌀 수 있습니다.

  • 컴퓨팅 가져오기. 재학습에 TPU가 필요한 경우 필요한 할당량을 얻기 어려울 수 있습니다. TPU 관리도 복잡합니다. 예를 들어 모델 또는 데이터의 일부를 여러 TPU 칩으로 분할하여 TPU용으로 특별히 설계해야 할 수 있습니다.

  • 적합한 핵심 데이터 세트 찾기. 데이터가 자주 변경되는 경우 일관되고 정확한 라벨로 우수한 데이터 세트를 얻기가 어려울 수 있습니다.

실험 중에 이러한 유형의 문제를 포착하면 시간이 절약됩니다. 예를 들어 최고의 특성과 모델을 개발하여 프로덕션에 적용할 수 없다는 사실을 알게 되는 것은 바람직하지 않습니다. 따라서 솔루션이 프로덕션 환경의 제약조건 내에서 작동하는지 가능한 한 빨리 확인합니다. 파이프라인 단계에서 해결할 수 없는 문제가 발견되었으므로 실험 단계로 돌아가지 않고 솔루션이 작동하는지 확인하는 데 시간을 할애하는 것이 좋습니다.