hidden technical debt in machine learning systems 논문 공부

나온지 오래됐지만 많은 분들이 추천하는 논문을 읽어보았다.(사실상 논문리뷰를 읽은 셈)

---

software engineering과 마찬가지로 라이브 시스템에 ML을 적용하면서 개발과 배포에 걸리는 시간은 상대적으로 빠르고 저렴하지만, 이를 유지보수하는 것은 어렵고 비용이 많이 든다.

• 🤔라이브 시스템에 ML 적용 : (ex) 실시간으로 데이터를 분석하고 예측을 하여 의사소통에 도움을 주는 것

프로토타입 제작 등으로 ML 시스템을 개발하고 배포하는 초기 비용은 낮을 수 있지만, 장기적으로는 유지보수와 관리에 더 많은 노력과 비용이 필요하다.

• 🤔WHY? 데이터는 변화하기 때문에, 변화하는 데이터를 재학습시키거나 모델의 성능이 나오지 않으면 모니터링하면서 학습해야하기 때문

특히나 ML system에서 전통적인 코드를 유지보수하는 문제에 특정 ML 이슈가 발생하는데, 이런 기술 부채들은 code level보다 system level에 존재하기 때문에 감지하기 어렵다.

• 🤔code level : 미사용 코드, 잘못 사용한 변수 수정 등
• 🤔system level : 데이터 관리, 모델 업데이트 및 배포 등

전통적인 software engineering 방식에서 캡슐화와 모듈 디자인을 사용한 강한 추상화 경계를 통해 유지보수가 가능한 코드를 만들고 독립화시킬 수 있지만, ML system에서는 외부 데이터로 인해 이런 추상화 경계를 적용하기 어렵고, 이로 인해 기술 부채가 생기게 되는 것이다.

 

Entanglement(얽힘)

ML system에서 입력값들이 복잡하게 얽혀 있기 때문에, 이를 독립적으로 분리하기는 어렵다. 즉, 하나라도 변경된다면 모든 것이 바뀌게 되는 것이다(CACE)

• 🤔CACE : Change Anything Changes Everything

이에 대한 해결책으로 앙상블 및 예측에 대한 변화를 감지하는 것이 있다.

모델이 독립적으로 분리되어 있기 때문에, 즉, 각 모델은 서로 영향을 주지 않기 때문에 CACE를 피할 수 있다. 또한, 이런 결과를 앙상블하면서 더 강력한 예측을 만들어낼 수 있다.

 

Correction cascade(지속적 보정)

특정 문제 A에 대한 모델 Ma가 존재하고 A와 비슷한 문제 A'가 존재할 때, 기존 모델 Ma를 보정하여 Ma'를 만들지 마라.

이러한 경우 Ma에 대한 의존성으로 인해 향후 모델을 개선하거나 유지보수하는데 어려움을 겪을 수 있다.

 

Undeclared Consumers(미신고 고객)

모델 예측값에 대해 접근이 쉬운 경우, 개발자가 모르는 상황에서 다른 팀이 접근하여 데이터를 활용할 수 있다.

이런 경우를 software engineering에서 Visibility Debt(가시성 부재)라고 한다.

=> 비용이 증가되고, 모델이 개선된 경우 적용하기 어려워진다. 또한 Hidden Feedback loop를 만들어 낼 수 있음

• 🤔 ex ? 날씨 앱에서 강수량 데이터를 알려주는 어플이 있을 때, 다른 팀이 본 팀에게 알리지 않고 이 어플의 강수량 값을 활용해 물을 얼마나 줘야 하는지 알려주는 농작물 스마트팜 어플을 개발했다고 생각해보자. 이때, 어플을 개선하면서 강수량 데이터가 사라지거나 값이 변경된다면, 농작물 스마트팜 어플은 즉시 적용하기 어려워진다.
  라고 이해하였다..

Data Dependencies Costs(데이터 의존성 비용)

코드 의존성의 경우 컴파일러나 링커를 통해 눈으로 확인하기 쉽지만, 데이터 의존성의 경우 의존성을 파악할 수 있는 도구가 없다면, 해결하기 어려운 데이터 의존성이 쌓일 수 있다.

1. unstable data dependencies

다른 시스템의 출력 값을 입력 값으로 쓰는 경우가 많은데, 시간에 따라 값이 변화하면서 Unstable data가 될 수 있다. 출력값이 암묵적으로 변화하는데, 이 출력값을 입력값으로 가져오는 과정에서 입력 값의 변화를 감지하긴 어렵다.

해결 방안 : 데이터에 대한 versioned copy를 만들어 데이터 의존성을 해결한다.

2. underutilized data dependecies

underutilized data dependecies는 이득이 거의 없는 입력값을 의미하는데, 위에서 언급했듯이 이런 입력값은 불필요하게 변화에 취약하게 만든다.

• [ex]
  • Legacy Feature
    가장 흔하게 발생하는 경우이다. Feature A가 모델 개발 단계에서 포함되었다가 시간이 지나면서 새로운 Feature에 의해 필요 없어진 경우이다.
  • Bundled Feature
    마감 일정에 쫓겨서 모든 feature 그룹을 추가하는데, 여기서 효과가 적거나 가치가 없는 feature가 추가된 경우
  • ϵ-feature
    이득은 적은데, 복잡도가 매우 큰 feature
  • correlated feature
    두 feature가 강한 상관관계를 보이지만, 한 가지 feature만이 직접적인 원인이 되는 경우

위 예시들은, 정기적인 평가(코드 리뷰) 등을 통해 불필요한 feature를 제거해줘야 한다.

 

Feedback Loops

피드백 루프(Feedback Loops)는 어떤 시스템이나 프로세스에서 출력이 입력에 영향을 주고, 그 영향이 다시 출력으로 돌아가는 과정이다. 이는 라이브 머신러닝 시스템의 주요 특징 중 하나로, 머신러닝 모델이 시간이 지남에 따라 업데이트되면서 스스로의 행동에 영향을 미치게 되는 것이다.

• 🤔피드백 루프 예시
  온도 조절 시스템에서 현재 온도와 원하는 온도를 생각해보자. 현재 온도를 확인하고 원하는 온도를 선택하는데, 이로 인해 현재 온도가 변경되는 것이다. 이걸 모델로 보면, 자신의 예측 결과값이 자신의 입력에 영향을 미치는 것이다.. 라고 이해하였다

피드백 루프에서도 세부적으로 2가지가 존재하는데 1.Direct Feedback Loops , 2. Hidden Feedback Loops 이다. 

1. Direct Feedback Loops

ML 모델이 학습 데이터를 선택할 때 자체적으로 그 선택에 영향을 주는 상황을 나타낸다. 모델의 선택이 결과에 영향을 미치고, 그 결과가 다시 모델의 선택에 영향을 미치는 것이다.

위 경우에서는 밴딧 알고리즘을 사용하는 것이 유용하지만, 실제 문제에 적용하기엔 어렵고 크다. 그렇기에 데이터를 격리시키거나 데이터 일부를 무작위로 선택하는 방법을 통해 피드백 루프에 빠지는 것을 통제한다.

• 🤔밴딧 알고리즘 : 다양한 선택 중 최상의 선택

2. Hidden Feedback Loops

이 경우가 더 어려운 문제이다. 이는 두 시스템이 직접적이 아닌 간접적으로 영향을 미치는 경우이다.

논문에서 든 예시가 이해가 잘 가는데, 두 회사의 주식 시장 예측 모델이다.

예를 들어 한 회사가 모델 개선을 통해 성능을 높였고, 이로 인해 다른 회사의 입찰 구매에 영향을 주는 경우이다.

이런 숨은 피드백 루프는 완전히 독립된 시스템이라고 생각해도 발생할 수 있다는 것에 유의해야 한다.

 

ML-System Anti-Patterns

ML system에서 코드는 매우 작은 부분을 차지한다. ML system에서 요구되는 인프라는 매우 복잡하고, 많은 ML system에서 높은 부채의 디자인 패턴이 포함되기 때문에 유의해야 한다.

아래는 높은 부채의 디자인 패턴 경우이다.

 

1. Glue Code

ML 리서처들은 종종 일반적인 솔루션을 사용하려고 한다. 여기서 일반적인 솔루션이란, 데이터 처리나 모델에 관련된 작업을 할 수 있는 패키지나 라이브러리이다. 패키지나 라이브러리에 맞게 데이터나 결과를 변환하기 위한 지원 코드를 작성하는데, 이것이 Glue Code이다. 이것은 특정 패키지에 종속될 수 있기 때문에 일반 패키지를 공통 인터페이스(API)로 래핑하는 것이다.

결국 ML system을 설계할 때, 특정 패키지에 의존하지 않도록 설계하라는 것!

 

2. Pipeline Jungle

Glue Code  특정 케이스로 데이터를 전처리할 때 종종 발생한다. 새로운 입력값 및 새로운 데이터 소스를 추가하면서 점차 발생하게 된다. 여기에 주의를 기울이지 않으면, 중간 파일 생성/join/샘플링 등으로 정글이 생성된다.

데이터 파이프라인을 관리하고 에러 감지 및 복구하는 작업은 비용이 많이 든다. 또한 파이프라인 테스트할 때도 end-to-end 테스트가 필요할 때가 많은데, 이런 모든 것으로 인해 기술부채가 쌓이게 된다.

해결 방안 : 데이터 처리를 단순화하고 표준화된 방법으로 진행하자. + 파이프라인 정글이 됐다면, 파이프라인을 백지상태에서 출발해 재설계해라! 실제로 많이 사용하는 효과적인 방식이라고 한다.

 

3. Dead Experimental Codepaths

Glue Code나 Pipline Jungle의 일반적인 결과이다. 일부 프로젝트에서 새로운 기능을 실험하기 위해 실험용 코드를 추가하고는 한다. 새로운 아이디어를 빠르게 실험하여 유용할 수 있지만, 시간이 지나며 누적된다면 예상치 못한 문제를 일으킬 수 있다.

해결방안 : 정기적인 코드 검토를 통해 안 쓰는 부분을 삭제하자

 

4. Common smells

software engineering에서 흔히 발생하는 일반적인 문제를 smell이라고 표현하는데, ML system에서 발생하는 smell은 아래와 같다.

• Plain-Old-Data Type Smell
  데이터를 다룰 때 흔히 발생하는 문제를 가르킨다. 사용되는 데이터 타입의 정보를 명확하게 알아야 하고(ex.몇 로그 승수인지), 데이터가 어떻게 생산되고 소비되는지 파악해야 한다.
• Multiple-Language Smell
  특정 부분에 편리한 언어를 사용하려고 하는 것은 편리할 수 있지만, 다양한 언어를 사용하다보면 테스트 비용이 증가한다.
• Prototype Smell
  새로운 아이디어를 테스트하기 위해, 작은 규모의 프로토타입을 구성하는 것은 유용할 수 있다. 그러나 자주 이런 환경에 의존하는 것은 full-scale system이 변화에 대응이 어려워질 수 있다.

 

Configuaration Debt

대규모의 시스템은 대규모의 구성 옵션을 가지고 있다. 종종 리서처나 엔지니어는 이런 옵션 설정을 뒤로 미루곤 하는데, 옵션 설정 실수는 시간 및 프로세스 낭비로 이어질 수 있기 때문에, 좋은 구성 시스템을 갖춰야 한다.

아래는 좋은 구성 시스템을 갖추기 위한 원칙이다.

• 작은 변경으로 구성이 바뀌도록 변경이 쉬워야 한다
• 수동으로 오류를 범하거나 누락하는 것이 어렵도록 만들어야 한다.
• 두 모델의 구성 차이가 잘 보이게 만들어야 한다
• 구성에 대한 기본 사실을 자동으로 확인하고 검증하기 쉬워야 한다.
• 사용되지 않거나 중복된 셋팅을 감지하기 쉬워야 한다
• Comfiguaration은 전체 코드를 검토하고 repo로 이동되야 한다

 

Dealing with Changes in the external world

ML system은 외부 환경과 상호작용 할 수 있는데, 외부 환경은 안정적이지 않다. 그렇기 때문에 변화에 대한 지속적인 유지보수가 필요한데 이는 큰 비용을 발생시킨다.

• Fixed Thresholds in Dynamic Systems(동적 시스템에서의 고정 임계값)
  ML의 고전적인 접근 방식은 특정 메트릭(ex. precision or recall) 등에 대해 좋은 균형을 얻기 위해 가능한 임계값을 설정하는 것이다. 그런데 이런 방법은 모델이 새 데이터로 업데이트되면 무효화될 수 있다. 그래서 많은 임계값을 수동으로 업데이트해야 하는데, 이는 많은 시간이 소요된다. 이러한 문제에 대한 완화 전략으로 검증 데이터셋을 통해 임계값을 찾는 것이다.
  주어진 모델에 대해 결정 임계값을 설정해야 할 때가 있다. (ex. true/false 예측, 이메일 스팸인지 아닌지 여부, 광고 표시 여부)
• Monitoring and Testing
  각 요소 별 Unit testing나 전체 end-to-end 테스트는 가치가 있지만, 변화하는 환경에서 제대로 작동한다는 증거를 제공하기에는 충분하지 않다. 그렇기에 실시간 모니터링이 중요하다. 
  • Prediction Bias (예측 편향) : 의도대로 되고 있는가 변화 감지
  • Action Limits(작업 제한) : 동작에 대한 limit 설정. 예시로 입찰 시스템에서 입찰금을 무한으로 설정하지 못하도록 limit 제한
  • Up-Stream Producers(상류 생성자) : ML 모델의 요구 사항에 만도록 철처히 모니터링 되야 함
  실시간에 대응하자!

 

Other Areas of ML-related Debt

• Data Testing Debt
  ML 시스템에서 데이터는 매우 중요한 역할을 한다. 따라서 데이터 품질 체크가 중요하기 때문에 데이터의 변화를 모니터링하자

• Reproducibility Debt
  동일한 조건으로 실험했을 때, 재현이 되야 한다.

• Process Management Debt
  우선 순위에 따라 리소스를 할당하는 등 여러 모델을 관리할 때 프로세스를 관리해라

• Cultural Debt
  ML 연구와 엔지니어링의 협력이 중요하다.

---

참고

https://inahjeon.dev/technical-dept-in-ml-systms/