Collecting,Labeling,Validating Data
Garbage in, Garbage out.
Introduction to ML Engineering in Production
ML pipeline은 거의 directed acyclic graph(DAG) 로 이루어진다.
Orchestrator는 DAG로 정의된 ML pipeline 안에 있는 여러 components들을 스케쥴링하며 pipeline automation을 추진한다. 이러한 작업을 하기 위해서는 Argo, Airflow, Celery, kubeflow 등의 tool을 사용할 수 있다.
TFX(Tensorflow extension)은 Open-source end-to-end ML platform이다.
TFX의 하위에 있는 여러 라이브러리들의 components를 이용해 DAG를 구성하고 그것들 간의 dependency를 설정하면 이것이 곧 ML pipeline이 된다.
- ExampleGen을 이용하여 data를 ingest한다.
- StatisticGen을 이용하여 data의 통계를 만든다.
- Example Validator를 이용하여 data안의 problem 을 찾는다.
- SchemaGen을 이용하여 data부터 feature vector에 걸쳐 schema를 생성한다.
- Transform을 이용하여 feature engineering을한다.
- Tuner와 Trainer로 Model을 Train하고 Hyperparameter를 튜닝한다.
- Evaluator 를 이용하여 Model에 대한 심층적인 분석을 한다.
- Infra Validator를 이용하여 Infrasturucture 위에서 실제로 Model이 예측을 하고 사용될 수 있는지 판단한다.
- Puser를 이용하여 model을 Production한다.
Collecting Data
Data를 모을때는 Bias가 생기지 않게 조심해야한다. Data는 Web crawling, open source, synthetic, live data등 많은곳으로 부터 모아질 수 있기 때문에 항상 Data가 어디서부터 오는지 생각하며 Bias에 신경써야한다.
Bias를 줄이기 위해서는 정확한 labeling이 필요하다. labeling은 Automation(loggin or weak supervision) 하게 될 수도 있고 Humans(aka "Raters")에 의해서 시행될 수 있다.
Rater는 다양한 그룹의 사람들로 구성될 수 있다. Labeling의 난이도가 높은 전문적인 분야는 그에 맞는 Rater를 구성해야 할 것이다. ML Service의 user로부터 받은 일종의 feedback label은 System이 더 잘 작동하게 도와줄 수 있을것이다.
또한 Privacy와 Security에 신경써야한다. User는 자신의 Data가 수집되는것을 인지하고, 제어할 수 있어야 한다. 또한 수집된 데이터는 PII(Protect personally identifiable information)를 통해 보호되어야 한다.
PII를 위한 방법에는 unique한 값을 summary 값으로 교체하는 Aggregation, 일부 data를 삭제해서 덜 구체화시키는 Redaction 등의 방법이 있다.
위의 네가지는 ML system이 실패할 수 있는 요인이다.
Representational harm은 시스템이 특정 그룹에 대한 부정적인 고정관념을 증폭시키거나 반영하는 것이다.
Opportunity denial은 시스템이 부정적인 결정을 예측하여 지속적인 악영향을 미칠 수 있는 경우다.
Disproportionate product failure은 특정 사용자 그룹에 대해 결과가 더 자주 발생하도록 모델의 효율성이 왜곡되는 경우다.
Harm by disadvantage은 시스템이 다른 인구학적 특성과 그 주변의 사용자 행동 사이에 불리한 연관성을 추론하는 것이다.
Key points
- Ensure rater pool diversity
- Investigate rater context and incentives
- Evaluate rater tools
- Mange cost
-
Determine freshness requirements
Labeling Data
Model을 Deploy하고 시간이 지나면 자연스럽게 Performace decay가 일어난다.
Data/Concept Drift가 일어나기 때문이다.
이러한 문제는 초기에 발견하여 적절한 조치를 취해주는것이 바람직하다. 특히 Data의 ground truth가 바뀌는 경우에는 새로운 Training data를 labeling 하는것이 불가피할 것이다.
Data의 ground truth가 바뀌는 주기에 따라 Easy,Hard,ReallyHard한 case로 나누어 살펴보자.
Easy Problems
Ground truth가 천천히(월,년) 바뀌는 경우이다.
보통 이 경우에는 모델의 성능 향상, 소프트웨어나 시스템의 변화로 인해 Model의 retraining이 일어난다.
Labeling은 public domain에서 얻은 자료나, 이때까지 조직에서 써왔던 data를 써도 되고, crowd-based data를 써도 될것이다.
Harder Problems
Ground truth가 일주일 정도로 빨리 바뀌는 경우이다.
이 경우에는 모델의 성능저하가 일어나서 Model을 retraining시키는 일이 생긴다. 물론 성능향상, 더 나은 Data의 확보, 시스템의 변화 등으로 인해서도 일어날 수 있다.
Labeling은 user로 부터 direct feedback을 받아 이용할 수 있으면 매우 좋다. crowd-based data를 써도 된다.
Really Hard Problems
Ground truth가 매우 빨리 일, 시간, 분단위로 바뀔 수 있는 분야이다. (증권 정보 등)
Labeling은 User로 부터의 direct feedback, 그리고 Weak supervision을 이용하면 좋다.
바뀌는 ground truth과 scarce label을 가지고 있는 Data를 labeling하여 Model을 retraining시키면 성능 향상에 많은 도움이 될것이다.
Process Feedback and Human Labeling
Data에 Label을 생성하는 가장 일반적이고 효과있는 방법인 Process Feedback(Direct labeling)과 Human labeling에 대해서 알아본다.
Process feedback의 간단한 예로는 CTR(clicking-through rates)가 있다. 만약 User가 추천해준 항목을 눌렀다면 Positive가 될 것이고, 아니라면 Negative가 될것이다.
process feedback은 model을 retrain할 때 필요한 새로운 data를 계속해서 만들어내는 방법이다.
Process feedback의 장점으로는
- Training dataset continous creation
- Labels evolve quickly
- Captures strong label signals
등이 있다. 실제 User의 action을 monitoring한 결과로부터 새로운 data를 만드는것은 매우 의미있는 data다.
단점으로는
- Hindered by inherent nature of the problem
- Failure to capture ground truth
- Largely bespoke design
등이 있다. Process feedback은 적용할 수 잇는 domain이 매우 한정적이라는 단점이 있다.
Process feedback 을 적용하기 위해서는 Log analysis tool을 사용하는것이 도움이 될 수 있다.
Human labeling은 사람이 직접 Data를 보고 labeling하는것을 말한다. 예를들어 X-ray 사진을 보고 질병 부위를 labeling하는 경우가 있다.
Human labeling에서는 labeling하는 사람들을 "raters" 라고 부른다.
Unlabeled data를 모으고, rater들을 모집한뒤 guide line을 제시하고 labeled data를 얻는 순서로 진행된다.
장점으로는
- More labels
- Pure supervised learning
이라는 점이다. 원하는 Data의 label을 원하는 supervised learning에 적합하게 생성할 수 있다.
단점으로는
- Quality consistency
- Slow
- Expensive
- Small dataset curation
이 있다. 특히 전문 분야일수록 많은 dataset가 사람이 정확하고 일관성 있게 labeling하기에 힘이 들 수 있다. 그리고 인력을 사용하기 때문에 시간이 다소 오래걸리고, 또 비용이 비싸다. 이러한 단점은 적은 dataset라는 결과로 이어질 수 있다.
Validating Data
Drift
시간이 지남에 따라 Data에 변화가 있는 경우다.
Skew
별개의 static version data 사이의 차이점을 skew라고 말한다. (ex Training set and Serving set)
Schema skew : ex) int != float
Feature skew : Training set와 Serving set에서 feature value의 차이.
Distribution skew : Training set와 Serving set의 input distribution이 다른경우. 예를 들어 계절의 변화나 트렌드의 변화 등으로 인해 발생할 수 있음 (Data Drift..?)
Detecting data issues
-
Detecting schema skew
- Training and Serving data do not conform to the same schema
-
Detecting distribution skew
- Dataset shift -> covariate or concept shift
- Requires continuous evaluation
Skew detection workflow
Skew detection을 위해서는 지속적으로 Monitoring하고 Data를 비교하는 작업이 필요하다.
Training data와 Serving data의 statistics를 계산하고 그 둘을 비교한다. 중대한 변화가 감지되면 경보를 trigger 하고 이에 따른 적절한 조치를 취할 수 있다.
연관글
Papers
Konstantinos, Katsiapis, Karmarkar, A., Altay, A., Zaks, A., Polyzotis, N., … Li, Z. (2020). Towards ML Engineering: A brief history of TensorFlow Extended (TFX). http://arxiv.org/abs/2010.02013
Paleyes, A., Urma, R.-G., & Lawrence, N. D. (2020). Challenges in deploying machine learning: A survey of case studies. http://arxiv.org/abs/2011.09926
ML code fraction:
Sculley, D., Holt, G., Golovin, D., Davydov, E., & Phillips, T. (n.d.). Hidden technical debt in machine learning systems. Retrieved April 28, 2021, from Nips.cc https://papers.nips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf