Hidden Technical Debt in Machine Learning Systems
https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
ML은 복잡하고 강력한 예측 능력을 제공할 수 있으나, 이는 많은 기술 부채를 지고 있다.
앞으로 실제 마주하게 되는 ML-시스템에서의 여러가지 위험에 대해 알아보자.
1. Introduction
모든 기술적 부채들이 나쁜 것은 아니나, 모든 기술적 부채들은 리팩토링, 의존성 감소, 테스팅 추가, 문서화 추가 등의 방식들로 결국엔 갚아져야만 한다.
목표는 새로운 기능의 추가가 아닌, 유지보수 가용성 증가, 에러 감소이다.
ML-시스템은 더욱 특수한 방식으로 기술부채를 질 수 있는데 이는 기존의 전통적 코드에 문제들과 함께 ML특수의 문제가 추가되어서이다. 또한 ML-시스템은 “glue code”의 사용, 현실 세계의 변화, 숨겨진 시스템상의 피드백-루프 등의 이유로 조용이 좀먹을 수 있다. 이를 막기 위해서는 모니터링에 더해 시스템의 면밀한 디자이닝을 필요로 한다.
2. Complex Models Erode Boundaries
전통적인 소프트웨어 개발에서 엄격한 추상화를 통해 모듈화가 가능했지만, ML-시스템은 외부의 데이터에 대한 의존성으로 인해 쉽지 않다.
Entanglement. ML-시스템은 데이터와 복잡하게 얽혀있는데, 이는 CASE 원칙이라 소개 할 수 있다: Chainging Anything Changes Everything. CASE는 입력신호에만 적용 되는 것이 아닌, 하이퍼-파라미터, 학습-세팅, 샘플링 방식, 수렴임계값, 데이터 설정, 그리고 모든 미세한 설정들에 적용되는 법칙이다.
이를 해결하기 위한 첫 번째 방안으로는 모델들을 분리 시키는 것이다.
두 번째로는 시각화 도구를 사용해 변화를 미리 감지해 내는 것이다.
Correction Cascades. A의 문제 해결을 위해 Ma 모델을 사용하였다가, A’문제 해결을 위해 Ma모델을 Ma’ 모델을 확장해 사용하면, Ma’ 모델이 Ma 모델에 의존성을 가지게 되고, 이는 문제가 발생 했을 때 문제 해결 비용을 증가 시킨다.
이를 해결하기 위해서는 각각의 문제들에 대해 모델들을 따로 개발하거나, Ma모델을 직접 적으로 수정해 피쳐들을 추가하는 것이다.
3. Data Dependencies Cost More than Code Dependencies
코드의 의존성과는 다르게, 데이터에 대한 의존성은 정적으로 분석해내기 훨씬 까다롭다.
Unstable Data Dependencies
데이터 수집 장비의 잘못된 세팅 등의 이유로 데이터에 문제가 있을 수도 있다.
또한 데이터의 정확도가 향상되는 변화에도 모델에 예상치 못한 영향을 끼칠 수 있는데, 이는 데이터 버져닝으로 해결 가능하다.
그러나 데이터 버저닝에도 데이터 변질, 시간이 지남에 따라 동일한 데이터에 대한 여러 버젼 관리를 해야 하는 비용 등의 문제는 있다.
Underutilized Data Dependencies.
불필요한 데이터나, 피쳐 등에 대한 의존성으로 인한 문제.
Legacy Features : 초기에 추가된 F 피쳐가 다른 추후에 다른 피쳐로 대체됐으나 감지되지 않음
Bundled Features : 쓸모없거나 가치가 적은 피쳐가 그룹피쳐로 함께 포함되는 경우
e-Features : 복잡도 증가는 높은데 비해 모델의 성능 증가는 미미한 향상을 선택하는 경우
Correlated Features : 두개의 피쳐가 서로 상관관계가 클때 이중 더 중요한 피쳐를 선택하는 것은 쉽지 않고 때때로 덜 중요한 피쳐를 선택하기도 한다. 이는 추후 상관관계 변동에 더울 취약하게 만든다.
주기적으로 철저한 leave-one-feature-out evaluation을 실행해 불필요한 피쳐들을 탐색해 낼 수 있다.
Static Analysis of Data Dependencies. 전통적인 코드는 컴파일러와 빌드-시스템, 정적 분석 방법들로 의존성 그래프를 그릴 수 있었다. 그런데 데이터에 대한 정적 분석 툴은 거의 없다시피 한데, 이는 에러 체킹, 지속적 업데이트 등을 위해 필수적이다.
4. Feedback Loops
ML-시스템의 특징은 시간이 지남에 따라 모델 자체의 영향력이 모델 스스로에 반영된다는 것이다.
Direct Feedback Loops.(직접적인 피드백 루프) 일정량 만큼의 난수화, 주어진 모델을 데이터의 일정 부분에대해 격리 시키는 방식으로 해결 가능하다.
Hidden Feedback Loops.(숨겨진 피드백 루프) 는 시스템들이 보이지 않는 방식으로 상호간에 영향을 끼치는 것으로, 발견하고 해결하기 훨씬 까다롭다.
5. ML-System Anti-Patterns
잘못된 시스템 디자인으로 인한 기술부채 생성.
Glue Code. 재활용이 불가능한 코드들을 계속해서 ML-코드에 덧붙혀 문제가 된다.
이를 해결하기 위해서는 black-box 처럼 자주사용 하는 api 들을 감싸는 것이다.
Pipeline Jungles. 주로 데이터 준비에 자주 발생하는 문제인데, 누더기코드, 조인 정글 등의 문제이다.
파이프라인 정글은 thinking holistic about data collection을 통해서만 해결 가능한데, 이는 사실상 파이프라인을 리디자인하고 새로 만드는 것이다.
이는 특이하게도 연구자와 엔지니어의 역할이 지나치게 분리되어 있어서 발행하는 경우가 많은데, 이는 연구자와 엔지니어가 협업을 하거나 같은 사람이 됨으로써 문제를 줄일 수 있다.
Dead Experimental Codepaths. 지나치게 많은 코드 분기들을 중첩해서 사용해, 코드의 흐름추적이 불가능해 지는 문제이다.
Abstraction Dept. ML-시스템에서 추상화의 부족으로 인해 확장이 힘들어지고 재사용성이 줄어드는 문제이다.
Common Smells.
Plain-old-data type smell
Multiple-Language Smell
Prototype Smell
6. Configuration Debt
연구자나 엔지니어들이 설정값 들에 대해 중요치 않게 생각하는 경우가 많은데, 때로는 설정값을 위한 코드들이 프로덕션 코드들보다 많아지기도 하는데, 설정값을위한 코드들은 모두 잠재적 위험이다.
해결하기 위해서는 -
설정값의 작은 변화를 감지하기 쉬워야한다.
매뉴얼리 진행되는 실수나, 누락, 지나침이 잃어나기 쉽지 않아야한다.
시각적으로 설정값들의 비교가 쉬워야한다.
피쳐의 개수나 데이터 의존성 등의 설정값들이 자동적으로 분석될 수 있어야 한다.
사용하지 않거나 불필요한 설정값들을 발견해 낼 수 있어야 한다.
설정값 코드들은 전체적으로 리뷰되어야 하고 레포지토리에 반영 되어야한다.
7. Dealing with Changes in the External World
ML-시스템은 세상과 직접적으로 영향력을 행사하는데, 세상은 항상 변한다.
이러한 점들이 지속적인 유지-보수 비용을 필요로 하게한다.
Fixed Threshold in Dynamic Systems. 참 or 거짓, 라벨들의 결정을 위한 임계치 값 설정은 때때로 수동으로 이루어 지는데, 이는 모델을 취약하고 업데이트가 느려지게 만든다.
이를 해결하기 위해 임계치 설정을 validation-data 를 사용해 학습시키는 방법이다.
Monitoring and Testing. 현실 세계에 적용 되어야 하는 모델을 사전에 테스트 하기는 쉽지 않음으로, 모니터링 시스템을 구축해 빠르게 대응 할 수 있도록한다.
이때 모니터링 해야 하는 타겟들로는 -
Prediction Bias. 예측한 결과들의 올바른 분배를 보이는지.
Action Limits. 시스템이 한계치에 도달했을 때 알림이 설정되게 해서, 시스템 확인을 할 수 있게 해야 한다.
Up-Stream Producers. 시스템에 들어오는 데이터 스트림도 모니터링 되고 테스트, 확인 되어야 한다.
8. Other Areas of ML-related Debt
Data Testing Dept. 데이터들도 모니터링 되고 데이터 분배 등이 확인 되어야 한다.
Reproducibility Debt. 과학자로서 실험의 재실현과 유사한 결과를 도출해 내는 것은 중요한데, 실제로 많은 난수화 알고리즘 때문에 이는 쉽지 않다.
Process Management Dept. 수많은 설정값들과 자원들을 수작업으로 관리하는 것은 업데이트, 모델 유지보수 등에 문제가 있다. 이를 해결하기 위해서는 수작업으로 진행되는 프로세스들을 최대한 피하는 것이다.
Cutural Dept. 팀의 문화를 연구자와 엔지니어들이 최대한 까가이서 협력하게끔 하는 것이 피쳐들 관리, 복잡도를 낮게유지하는것, 안정성, 모니터링, 재활용성 등에 유리하다.
9. Conclusions: Measuring Debt and Paying it Off
How easily can an entirely new algorithmic approch be tested at full scale?
What is teh transitive closure of all data dependencies?
How precisely can the impact of a new change to the system be measured?
Does improving one model or signal degrade others?
How quickly can new members of the team be brought up to speed?
