[수정중]Hidden Technical Debt in ML:논문 정리

2페이지 까지 완료

개요

머신러닝 시스템을 개발하고 배포하는 것은 쉽지만, 이를 유지하는 것은 어렵습니다.

그 이유는 “기술적 부채” 때문인데, 당신이 그 당시에 쉽고 빠른 코드를 작성하는 선택을 한다면, 그 선택이 나중에 문제를 일으킬 가능성이 매우 높다는 것을 의미합니다.

물론 이러한 기술적 부채가 반드시 나쁜것은 아닙니다.

기술적 부채 또한 재정적인 부채와 비슷하게, 전략적으로 기술적 부채를 가져야 할 필요가 있습니다.(지금 당장 서비스를 제공하기 위해)

그러나 빠르게 기술적 부채를 갚지 않으면, 문제는 점점 악화될 것입니다.

그리고 숨겨진 부채(hidden dept)는 우리의 눈을 피해 조용히 커지고 있기에 조심해야 합니다!

 

ML 시스템은 기존의 기술적부채에 더해서, ML만의 특수한 기술적 부채를 가지고 있습니다.

ML만의 특수한 기술적 부채는 주로 코드레벨 보다는 시스템 레벨의 문제이기 때문에, 감지하기가 어렵습니다.

그리고 데이터가 ML시스템의 행동에 영향을 미치기 떄문에, 기존의 추상화와 모듈설계는 모호해지고, 잘 작동하지 않을 수 있습니다.

또한, 일반적으로 기술적 부채를 상환하기 위해 사용하는 방법들은(코드가 지저분하여 생기는 문제 해결),

ML관련 기술부채를 해결하기가 어렵습니다.

 

이 논문에서는 새로운 머신러닝 알고리즘을 제시하기 보다는 , 기존의 알고리즘을 사용할 때, 결정해야하는 어려운 선택에 초점을 두고 있으며, 특히 우리는 시스템 수준의 상호작용과 인터페이스가 얼마나 급격하게 기술적 부채를 생성할 수 있는지를 집중적으로 다룹니다.

 

입력 신호를 재사용하거나 연결하는 과정에서 우리가 의도치 않게 ML model을 다른 시스템을 연결시킬 수 있습니다.

 

 

많은 사람들이 ML packages를 명확히 이해하지 않고 black boxes처럼 다루기 떄문에, 이 것이 많은 양의 Glue code나 calibration layers를 생성하게 되는 결과를 가져옵니다. (필요없는 코드를 많이 만들고, 후에 변경할때 어려움을 겪게 된다는 이야기)

 

또한 실제 외부 세계의 시스템은 의도되지 않은 방향으로 움직일 수 있기 때문에 신중한 설계가 없이는 ML 시스템의 행동을 분석하는것이 어려울 수 있다.

 

 

 

복잡한 모델은 경계를 무너뜨린다.

 

기존의 소프트웨어 엔지니어링 에서는 캡슐화와 모듈화를 통해 한 코드가 정확히 하나의 일을 수행하도록 하여,

코드를 읽기 쉽고 이해하기 쉽게 하고, 코드를 변경할 때 이 변경이 모든 코드에 영향을 미치지 않게 간단히 변경하는것이 가능했습니다.

 

그러나 ML에서는 이러한 강력한 추상화를 적용하는 것이 어렵습니다.

게다가, ML은 외부 데이터 없이는 로직을 효율적으로 구현하기가 어렵기까지 합니다.

ex) 사진을 보고, 고양이 인지 아닌지 예측하는 로직을 구현하는 것은 매우 어렵다.
우리도 마찬가지로, 고양이 사진을 보고, 이 사진이 고양이인지 아닌지 어떻게 알았어? 라고 물어본다면,
“그냥 보면 알잖아.” 라고 말할 수 밖에 없다(우리가 고양이를 어떻게 인식하는지를 로직화 하기는 사실 아주 어려운 문제이므로)

 

현실세계는 깔끔한 캡슐화에 어울리지 않기 때문에, 경계가 모호합니다.

이러한 경계의 모호화는 기술적 부채를 급격히 증가시키는 몇가지 결과를 가져옵니다.

 

Entanglement(얽힘)

ML은 여러가지 신호들이 뒤섞이고,얽혀서 들어오기 때문에, 개선하기가 어렵습니다.

예를 들면, feature x1 … xn개의 특성을 사용한다고 할때, x1의 분포를 줄이면, 나머지 n-1개의 분포또한 같이 변경됩니다. 마찬가지로 새로운 특성 x(n + 1)을 추가하면, 나머지 n개의 특성이 같이 변경됩니다.

이러한 문제는 online 이든 batch serving이든 동일하게 적용됩니다.

 

따라서 우리는 the CACE principle: Changing Anything Changes Everything 를 인용합니다.

“하나가 바뀌면 모든것이 바뀐다.”

이러한 원칙은 feature에만 적용되는 것이 아니라, hyperparameter, learning settings, sampling methods, convergence thresholds, data selection와 같은 모든 우리의 변경점에 적용됩니다.

 

한가지 가능한 완화 법칙이 있다면, 모델을 격리시키고 앙상블을 제공하는 것입니다.

이러한 접근 방식은 이미지 분류처럼, 분리된 다중 클래스가 있고, 오직 하나의 클래스에만 이미지가 속할수 있는 상황에서 유용합니다.

 

그렇지 않은 상황에서도, 앙상블은 유용한데, 그 이유는 모델이 서로 상쇄될 수 있는 다양한 종류의 실수를 할 가능성이 있기 때문입니다.

ex) A모델이 b에서 실수를 하더라도, B, C모델이 b를 올바르게 예측한다면 실수가 상쇄됨.(다른 것도 마찬가지)

 

시스템이 강하게 얽힌 조합으로 구성되어 있기 때문에, 당신이 어느 한 파트를 개선하더라도 다른 파트가 그 부분에 강하게 얽혀있어 오히려 전체 성능이 떨어질 수 있습니다.

 

두번째 가능한 방식은, 모델의 예측행동이 변화할 때, 그 변화에 집중하는 것입니다.

고차원 시각화 도구를 사용하여 이러한 변화에 더 잘 집중할 수 있습니다.

→ 데이터를 조각내서 평가하는 방식이, 통째로 평가하는 방식보다 더 변화를 잘 표현하고, 유용하다.

 

Correction Cascades(계단식 보정).

→ 데이터조각의 작은 오류가, 후속 데이터의 오류의 도미노 효과를 일으킴.

ex)원본데이터가 잘못된 경우, 컴퓨터는 잘못된 데이터를 계속 생성한다.

기존에 a를 수행하는 모델 ma가 존재하는데, a와 약간 다른 a’를 추가로 수행해야 하는 모델을 만들어야 할 때가 있다.

이럴 때우리는 ma를 조금 수정하여ma’을 만들어 a’도 같이 수행하고자 하는 유혹을 받을 수 있다.

그러나, 이러한 수정모델 ma’은 새로운 시스템 의존성이 생기기 때문에, 기존의 ma를 분석하는 것 보다 많은 비용이 든다.

만약 ma’를 통해 또 다른 비슷한 task a’’를 추가로 수행하는 모델 ma’’를 만든다면, 계단식으로 더큰 error가 발생할 것이다.

→ 따라서, ma를 조금 수정하여 ma’를 수용하는 것이 아니라,ma 안에 a’을 수행하는 작은 모델을 만들거나, 모델에 feature를 추가하여 ,a와 a’을 더 잘 구별하도록 하는 것이 좋습니다.

 

Undeclared Consumers.
기계 학습 모델이 예측이 이루어지는 시점이나 파일 또는 로그에 저장함으로써 널리 액세스할 수 있는 예측을 종종 수행할 때가 있습니다.(파이프라인에서 앞단의 output이 뒷단의 input이 되는 케이스-변성윤 마스터님의 블로그에서 발췌)

엑세스 제어 없이, consumers가 선언되지 않고 조용히 예측을 사용할 때가 있다.

고전적인 소프트웨어 엔지니어링에서는 이러한 문제를 “가시성 부채” 라고 한다.

이러한 가시성 부채는 아주 위험한데, 이러한 문제가 모델과 아주 밀접하게 연결되어 있으며, 더 나아가 이러한 선언되지 않은 소비자는 hidden feedback loop를 생성할 수 있습니다.

또한 비용없이 이러한 선언되지 않은 소비자를 찾아내는 것이 아주 어렵습니다.

 

ex)예를 들어, 클릭율(CTR) 시스템이 광고 시스템 중 글꼴 크기와 연결되어 있는 경우 숨은 피드백 루프를 따라 클릭율을 높이는 기계학습 시스템은 글꼴 크기를 커지게 합니다. 하지만 우리가 원하는 것은 글꼴 크기를 커지게 하는 것이 아닌, 광고의 전환이 목표입니다.

-변성윤 마스터님의 블로그에서 예시 발췌-

 

Data Dependencies Cost More than Code Dependencies

데이터 의존성이 코드 의존성보다 더 비용이 크다.

 

[13]항목에서, 프로그램이 다른 프로그램이나 라이브러리에 의존하는 경우 종속성 부채(
dependency debt)로 인해 코드 복잡성과 기술적 부채가 어떻게 발생할 수 있는지 논의하고 있습니다.

data dependecies가 유사하게 작용하지만, 이것이 찾아내기가 훨씬 어렵습니다.

 

Code dependencies는 컴파일러와 링커를 이용해서 쉽게 식별 할 수 있지만,

data dependencies는 의도없이 너무나 쉽게 생성될 뿐만 아니라, data depedencies는 이러한 툴(컴파일러나 링커)이 없기 때문에, 식별하기가 매우 어렵습니다.

데이터 종속성: 두개의 데이터가 종속적인 관계를 가지는것? 두 데이터의 순서를 바꾸었을때, 결과가 바뀌면 데이터 종속성이 있는것이다.

Unstable Data Dependencies.

다른 시스템의 signal을 모델의 입력으로 사용하는 것이 편리하지만, 이러한 신호중 일부는 불안정하고, 시간이 지나면 변화할 수 있습니다.

이러한 변화는 암묵적으로 일어날 수 있는데, 입력신호가 시간이 지나면서 업데이트 될수 있는 다른 기계학습 모델로 부터 오느 경우 혹은 데이터 종속적인 테이블에서 입력신호가 오는 경우( TF/IDF scores or semantic mapping과 같은) 입니다.

반대로 명시적으로 이루어 질수도 있는데, 이러한 경우는 입력신호의 소유권과 입력신호를 받는 모델의 소유권이 다를 경우, 이러한 변화가 언제든 일어날 수 있습니다.

ex)입력신호를 만드는 팀과, 모델을 만드는 팀이 분리되어 있는 경우 signal이 변화할 수 있다.

이러한 경우, 입력신호가 아무리 '개선'되었다 할지라도, 모델에 악영향을 미칠 수 있습니다. 그리고 이러한 영향은 찾기 힘들뿐만 아니라, 고치기도 힘듭니다.

예를들어, 이전에 입력신호가 잘못 보정되었을 경우를 생각해 보십시오, 지금까지 모델은 잘못된 보정신호를 소비하고 있었으며, 이러한 신호를 보정하는 업데이트가 발생할 경우, 모델에 큰 영향을 미칠 것입니다.

 

이러한 불안정한 데이터 의존성에 대한 하나의 완화 전략은 '주어진 신호에 대해 버전화된 복사본을 만드는 것입니다.'

예를 들면, 시간이 지나면서 변경되는 주제 클러스터(topic cluster)에 대한 단어의 의미 매핑(semantic mapping)보다는, 고정적인 버전을 만들고, 다음 업데이트를 완전히 검토하기 전까지 사용하는 것이 더 합리적일 것입니다.

그러나 이러한 Versioning carries는 "잠재적 정체"와 "시간이 지남에 따라 동일한 신호의 여러 버전을 유지하는 비용"과 같은 추가비용이 발생합니다.