[AI Product Serving] 프로젝트 설계 과정과 관련 용어 정리

AI를 활용한 서비스의 개발 과정에서 문제를 잘 정의하고, 해결하려는 해당 문제를 구체화하는 것은 가장 우선시되는 중요한 업무다. 이것이 잘 진행되었다는 전제 하에, 이후 프로젝트 설계 단계와 관련 용어들에 대해서 정리해본다.

 

1) 머신러닝 문제 타당성 확인

기계학습 모델을 서비스에 포함시키는 것이 가치있는 선택이기 위해서는 여러가지 조건이 붙는다. 바꾸어 말하면, 모든 상황에 기계학습 모델 혹은 AI가 활용된 솔루션이 문제를 해결하는 좋은 방법은 아니다. 따라서 아래의 사항들을 확인하고 따져본 후 기계학습의 적용 여부를 결정하는 것이 좋다.

 

[① 데이터 존재 유무]

머신러닝은 데이터로부터 특정 패턴을 학습하는 것이므로, 데이터 없이는 불가능하다. 현실적으로 목적에 꼭 맞는 양과 label을 가진 데이터를 구하는 것은 쉽지 않은데, 적어도 데이터 수집 및 전처리, augmentation, 라벨링 등을 통해서라도 데이터를 확보할 수 있는지가 중요하다. 최근에는 이러한 데이터 확보의 어려움을 해결하기 위해 필요한 데이터를 현실의 데이터와 유사하게 생성하거나 label 없이도 모델이 학습할 수 있도록 하는 비지도학습 등이 활발히 연구, 시도되고 있다.

 

[② 패턴의 존재 여부 & 복잡성]

복권 번호의 예측처럼 매 시행이 독립적이고 랜덤하여 아무런 패턴이 없을 것으로 기대되는 문제의 해결에는 머신러닝이 적합할리 없다. 데이터를 확보했다면 적절한 탐색과 분석을 통해 최소한의 패턴을 발견한 뒤 프로젝트를 진행한다. 또한 패턴이 존재한다해도 rule-based 모델로 해결할 수 없는 적당한 복잡성이 존재해야 머신러닝을 적용하는 것이 가치가 있다.

 

[③ 사람이 반복적으로 해야하는 일인가?]

일회성 업무 혹은 문제 해결에는 머신러닝 모델이 적합하지 않을 수 있다. 얼굴 인식을 통한 체온 체크 시스템처럼, 인간이 반복적으로 행해야 하는 노동의 부담을 줄여줄 수 있는 경우 머신러닝이 더 큰 가치를 지닐 수 있다. 또한 인간이 특정 행위를 반복할 수 있다는 것은, 해당 업무 혹은 문제를 해결하는데 있어 특정 패턴이 존재하여 그것을 기계학습이 대체할 수 있는 가능성이 있음을 의미하기도 한다.

 

[④ 목적 함수의 설정]

기계학습이 실제 가능하기 위해서는 (이를 최소화하는 것이) 문제를 해결하는 것과 같은 목적을 달성하는 것이라 정의할 수 있는 목적함수를 특정할 수 있어야한다. 대표적으로 MSE, Accuracy 등이 활용된다. 데이터의 특성과 양에 따라, 데이터의 종류에 따라, 해결하고자하는 문제에 따라 적절하게 정의해야한다.

 

반대로 아래의 경우들에 해당된다면, 머신러닝을 문제 해결에 사용하는 것을 지양해야한다.

- 비윤리적인 문제: 이루다의 성희롱, 페이스북의 극단적 성향의 게시물 추천 알고리즘 등이 대표적인 예다.

- rule-based 모델 등의 더 간단한 문제해결 방법이 있는 경우

- 양질의 데이터를 충분히 얻기 어려운 경우

- 한번의 예측 오류가 치명적인 결과를 초래하는 경우: 의료 진단 서비스처럼 민감한 문제에 대해서는 전적으로 AI에 의존하는 것이 아니라 보조적인 도구로 활용하기도 한다.

- 시스템이 내리는 모든 결정이 설명 가능해야 할 경우: 설명 가능한 AI를 사용하는 것으로 해결하기도 한다.

- 비용 효율적이지 않은 경우

 

2) 목표 설정과 지표 결정

프로젝트의 목표는 일반적인 큰 목적인 Goal과 Goal을 달성하기 위한 세부 단계의 구체적인 목적인 Objectives로 나눌 수 있다. 이때 Goal과 Objectives는 데이터를 확인해가며 설정하며 Objectives에 알맞은 목적함수를 지정하되, 상황에 따라 데이터를 레이블링하거나 레이블 없이 목표를 달성할 수 있는 방법을 고민해야한다.

 

Ex) Goal: 극단적인 견해와 잘못된 정보의 확산을 최소화하며 사용자의 참여를 극대화

Objectives:

- NSFW(Not Safe for Work) 컨텐츠 필터링

- 잘못된 정보 필터링

- 품질에 따른 게시물 랭킹 선정

- 참여에 따른 게시물 랭킹 선정

 

다만 때로는 달성하고자 하는 Objectives들이 여러 개 존재하는 동시에 상충할 수 있다. 예를들어 위 예시처럼 게시물 추천을 품질과 참여에 따라 진행할 때, 게시물이 매우 매력적이어서 참여가 많지만 해당 게시물의 품질이 떨어지는 경우가 존재할 수 있다. 이런 경우 아래의 두 방법 중 하나를 택할 수 있다.

 

[방법 1. 단일 모델 생성]

Objectives에 각각 상응하는 목적함수에 대해 loss를 결합한 하나의 loss를 최소화하기 위해 모델을 학습

EX) loss = 𝛼*quality_loss + 𝛽*engagement_loss

 

[방법 2. n개의 모델의 병렬적 연결]

Objectives에 각각 상응하는 목적함수에 대해 loss를 최소화하는 모델을 생성하여, 그 output을 결합해 새로운 지표를 생성하는 방법.

EX) Rank: 𝛼*quality_model(post) + 𝛽*engagement_model(post)

 

방법 1의 경우 𝛼, 𝛽의 값을 조정하고 싶을 때마다 모델을 재학습 해야하는 문제가 발생하기 때문에, Objectives를 분리한 방법 2를 활용하는 것이 좋다. 또한 방법 2를 활용할 때는 각 Objectives의 특성에 따라 유지보수 일정을 다르게 적용할 수 있다는 장점이 있다.

 

3) 제약 조건(Constraint & Risk)

본격적으로 프로젝트를 진행하기 앞서 일정, 예산, 관련된 사람, 레거시 환경(기존에 운영하고 있던 인프라), 윤리적 이슈 등 다양한 항목에 대한 제약과 리스크의 범위를 정해야한다. 특히나 클라우드나 DB를 활용하는 경우 개인정보 보호법 등 프라이버시와 관련된 제약들을 잘 살펴야하며, 모델의 성능과 관련해서도 아래의 키워드들에 대한 확인 혹은 확립이 필요하다.

 

[① Baseline]

학습한 모델을 무엇과 비교할 것인지 그 기준이 되는 모델 혹은 사람의 성능을 말한다. 기존에 활용되던 모델을 활용하는 경우도 있고, 간단히 rule-based 혹은 회귀로 직접 만들 수도 있다. 베이스라인 모델보다 성능을 얼마나 향상시킬 것인지가 프로젝트의 목표 중 하나가 되기도 한다. 이때 베이스라인 모델은 최대한 간단한 것으로 택하는 것이 좋으며, 관련된 이전의 관련 연구를 확인하기 위해 SOTA(State of the Art) 논문을 참고하는 것도 방법이 될 수 있다.

 

[② Performance Trade-off]

모델이 필요로 하는 시간 복잡도와 성능이 서로 trade-off 관계에 놓이는 경우가 많은데, 이때 어떤 것에 더 중점을 둘 것인지 결정한다. Yolo v5처럼 여러 버전의 모델을 만드는 것이 일반적인 것 같다.

 

[③ 해석 가능 여부]

결과에 대한 해석이 필요한지, 필요하다면 누구에게(사용자, 운영자 등) 필요한지, 어떤 방식으로 제공할지 등을 결정한다.

 

[④ Confidence Measurement]

위음성(False Negative) 등의 오탐이 있어도 괜찮은지, 만약 용인한다면 어느 정도까지 용인할 수 있는지 등을 결정한다.

 

위를 토대로 모델을 학습할 준비 및 그 제약 조건에 대한 정립을 마친 후에는 아래의 플랫폼 등을 활용해 프로토타입을 만들고, 피드백을 통해 수정 보완해나가는 것이 좋다.