당신이 AI(ML)팀과 대화가 안되는 3가지 이유

당신이 AI(ML)팀과 대화가 안되는 3가지 이유
Photo by Jason Goodman / Unsplash

ChatGPT의 등장 이후, 학계에서나 들렸던 다양한 인공지능의 언어들이 사회 곳곳에서 들리기 시작한다. 굳이 인공지능과 관련없던 일을 하는 사람들도 지금은 인공지능을 삶의 곳곳에서 자연스럽게 쓰고 있다. 불과 몇년 사이에 벌어진 일이다.

자연스럽게 많은 회사에서 AI를 비즈니스 전면에 도입하는 모습도 심심치 않게 볼 수 있다. 하지만  아직은 비용측면보다는 (AI를 활요하는) 기술기업임을 과시하고 싶은 효과를 목적으로 도입하는 경우가 많다. 실제 실무에서 보면 AI를 막상 도입해놓고선 프로젝트가 기존 대비 나은 성과를 보여주지 못하거나 실패로 돌아가는 경우도 부지기수이다. 왜 그럴까? 세가지로 정리해보면 다음과 같다.

첫 번째, 문제에 대해서 제대로 대화하지 않는다. 실무진은 문제에 대한 세부사항을 충분히 설명하지 않고 최종적인 변화만을 주로 언급한다. 특히 최근 GPT 등장 이후에는 AI가 모든 문제를 해결해줄 것이라는 문제의 현황과 활용 용도, 해결 목표와 범위에 대해 굉장히 인간의 관점에서 가이드하는 경우가 많다. 그들이 궁금한 것은 "해결능여부"와 "해결까지 걸리는 시간" 것일뿐 어떠한 부분도 AI팀을 고려하지 않는 경우가 많다.

하지만 데이터과학자에게 중요한 것은 정확한 목표이다. 무엇을 왜, 언제까지 어떠한 형태로 구현해주길 바라는지 제시해주지 않는다면 데이터과학자는 정말 이상한 결과물을 들고 올 수 있다. 심지어 AI가 필요하지 않는 경우도 다반사이다. 기술과 비즈니스 사이에서 다리를 이어줄 수 있는 주요지식이 부재한 경우 이 문제는 개발 이상으로 오랜시간을 잡아먹을 때가 많다.

두 번째, AI를 만능이라고 생각하고 문제의 모든 부분을 AI팀에게 넘긴다. AI팀은 과학자라는 단어가 의미하는 것처럼 학구적인 형태로 접근하기도 하고, 실무의 관점에서도 접근하기도 한다. 이는 오버 엔지니어링을 낳기도 하고, 또는 너무나도 다양한 지엽적 접근으로 일정을 지연시키기도 한다. 심지어 재현이 되지 않는 경우도 많다. Feature에 대한 부분도 그렇다. 도메인 지식이 풍분한 사업이나 서비스의 의견은 의외로 중요할 수 있다. 따라서 문제의 MVP 형태나 변경사항에 대한 적절한 유연성 있는 요구사항은 비스니스와 프로덕트가 함께 가져야 가야 한다고 생각한다. 문제에 대한 과소적합도, 과대적합도 아닌 적절한 중간을 찾기 위해서는 문제를 함께 풀어나가야 한다.

마지막으로, 배포 및 운영방식에 대한 충분한 대화가 필요하다. 충분한 데이터 분석결과를 바탕으로 예측주기를 어떻게 가져가는 것이 좋을지 그리고 모델의 결과를 그대로 쓰지 않는 경우 후처리를 어떻게 하면 좋을지, 장애의 경우 역시 어떻게 하면 좋을지 등을 고려하는데 있어서 역시 충분한 대화가 필요하다. 예를 들어 예측 데이터에 대한 실시간 성이 필요하다보면 REST API를 구축해야할 것이다. 그리고 모델을 매일 훈련하고 추론해야 한다면 모델의 성능을 측정할 수 있는 MLFlow등의 모니터링 툴과 모델을 관리하기 위한 모델 레지스트리가 필요할 것이다. 뿐만 아니라 배포 형태를 카나리아나 블루/그린등으로 가져갈지도 논의가 필요하다. 실시간이 버겁지만 그래도 준실시간이 필요하다면 레디스(Redis) 등을 이용한 캐시활용도 필요할 수도 있을 것이다. 이와 같은 부분은 운영이 모두 기술적 용어를 이해할 필요는 없다. 하지만 운영시나리오를 충분히 공유함으로써 AI팀이 다양한 상황에 대응할 수 있도록 도울 필요는 있다.

정리하면 결국 함께 문제를 푸는 존재로서 문제에서 고려해야할 다양한 부분을 함께 논의하고 공유하는 것은 너무나도 중요하다. 이 때 사업의 관점, 서비스의 관점을 넘어 보다 매순간 매초 자동으로 운용되는 AI 프로덕트의 관점의 대해서 함께 논의할 때 보다 견고하고 지속가능한 AI프로덕트를 운용하여 문제를 해결할 수 있음을 잊지 말아야 한다.

Read more

ML 코드 작성시 유의사항

ML 코드 작성시 유의사항

유의사항 * 코드의 작성방식: 다른사람이 코드를 읽고 이해할 수 있는가? * 코드의 성능: 의도치 않은 부작용이 발생하는가? * 코드의 복잡성: 유스케이스에 비해 설계가 과도하고 부족한가 * 개선의 용이성: ML코드가 지속적으로 리팩토링 되는가? 코드 작성방식에 따른 개발자(+데이터과학자)의 유형 분류 출처 * 머신러닝 엔지니어링 인 액션

ELPD는 모델이 새로운 데이터를 얼마나 잘 예측하는지를 보여주는 지표입니다.

ELPD는 모델이 새로운 데이터를 얼마나 잘 예측하는지를 보여주는 지표입니다.

기본 개념 * ELPD(Expected Log Predictive Density)는 모델이 새로운 데이터를 얼마나 잘 예측하는지를 나타내는 지표로, 주어진 데이터 포인트에 대해 모델이 예측한 확률의 로그 값(로그확률)을 합산한 것입니다. $$\text{ELPD} = \sum_{i=1}^{n} \log p(y_i \mid \text{data})$$ * $n$: 데이터 포인트의 수 * $y_i$ : 실제 관측된

잭나이프 샘플링은 표본의 변동성 추정 방법중 하나입니다.

잭나이프 샘플링은 표본의 변동성 추정 방법중 하나입니다.

잭나이프 샘플링이란? * 잭나이프 샘플링은 표본 데이터에서 하나의 관측치를 제거한 여러 하위 샘플을 만들어, 이들 샘플에 대해 통계량을 계산한 후 그 결과를 바탕으로 전체 표본의 변동성을 추정하는 방법입니다. 잭 * 나이프는 주로 표본의 분산을 추정하거나 통계량의 편향을 줄이기 위해 사용됩니다. 예시 * 주어진 표본이 [x1, x2, x3, x4]라면, 잭나이프 샘플링은 다음과 같은

정확한 단위로 대화를 하는 것이 중요합니다.

정확한 단위로 대화를 하는 것이 중요합니다.

자전거를 타고 약속장소로 이동하는 중이었습니다. 근처 과일 가게에 이런 문구가 적혀있었습니다. "한 상자에 X,000원" 과일을 직접 사먹지는 않는 편이기 때문에 가격은 모르지만 꽤 매력적인 가격대였습니다. 그래서 잠시 "살까?" 망설였습니다. 하지만 이내 자전거를 타고 다시 가던 길을 갔습니다. 한 상자 안에 몇개가 들어가 있을지를 몰랐기 때문입니다.