머신러닝 파워드 애플리케이션

https://link.coupang.com/a/bcHhWd

머신러닝 파워드 애플리케이션:아이디어에서부터완성된제품까지강력한머신러닝애플리케이션

 

 

p.43~44

 

모델 

 

한 문장에서 다른 문장으로 매핑하는 모델은 앞서 언급한 생성 모델에 속합니다. 이런 모델은 최근 몇 년간 급격히 발전했습니다. 시퀀스-투-시퀀스(sequence-to-sequence) 모델은 번역 작업을 위해 2014년 개발되어 기계 번역과 사람 번역 사이의 간격을 좁혔습니다. 하지만 이런 모델의 성공은 대부분 문장 수준의 작업에 기반했고, 한 문단보다 긴 텍스트를 처리하는 데 자주 사용되지 않았습니다. 지금까지 한 문단을 다른 언어로 옮길 때, 긴 범위에 걸친 문맥을 감지할 수 없었기 때문입니다. 또한 일반적으로 많은 모델 파라미터를 사용하기 때문에 훈련 속도가 느립니다. 모델이 한 번만 훈련된다면 이슈가 되지 않습니다. 만약 매시간 또는 매일 다시 훈련해야 한다면 훈련 시간이 중요한 요소가 될 수 있습니다.

 

응답 속도

 

시퀀스-투-시퀀스 모델은 종종 자기회귀 모델(autoregressive model)이라 부릅니다. 모델이 앞서 출력한 단어를 다음 출력을 만드는 데 사용한다는 의미입니다. 이로 인해 인접한 단어에서 얻은 정보를 사용할 수 있지만 단순한 모델보다 훈련과 추론을 느리게 만듭니다. 이런 모델은 추론 시에 응답을 하는 데 몇 초가 걸릴 수 있습니다. 반면 간단한 모델은 1초 안에 응답합니다. 충분히 빠르게 실행하도록 모델을 최적화할 수 있지만 추가적인 엔지니어링 작업이 필요합니다.

 

구현의 용이성

 

복잡한 엔드투엔드 모델은 구성 요소가 많기 때문에 훈련 과정이 매우 어렵고 오류가 발생하기 쉽습니다. 따라서 모델의 잠재적인 성능과 파이프라인에 추가될 복잡도 사이의 트레이드오프를 생각해야 합니다. 복잡도가 커지면 파이프라인 구축에 시간이 걸리지만 유지 보수 작업도 늘어나게 됩니다. 만약 다른 팀원이 모델을 반복해서 향상할 거라 예상한다면 간단하고 잘 이해할 수 있는 모델을 고르는 것이 좋습니다.

 

p.47~50

모니카 로가티는 컴퓨터 과학 박사 학위를 받은 후 링크드인에서 경력을 시작했습니다. 링크드인에서 '당신이 알 수도 있는 사람' 알고리즘에 머신러닝을 통합하고 구직자 매칭 시스템의 첫 번째 버전을 만드는 일과 같은 핵심 프로젝트에 참여했습니다. 그다음 조본(Jawbone)의 데이터 부사장으로 근무하며 데이터 팀 전체를 만들고 이끌었습니다. 현재 모니카는 직원이 5명에서 부터 8,000명까지 이르는 수십 개 회사에 자문을 해주고 있습니다. 친절하게도 모니카가 머신러닝 제품을 설계하고 진행하는 팀에게 알려주곤 했던 조언을 공유해주었습니다.

 

Q. 머신러닝 제품의 범위를 어떻게 정하나요?

A. 최선의 도구를 사용하여 문제를 풀어야 한다는 것을 기억하고, 타당성이 있을 때만 머신러닝을 사용해야 합니다. 

 

애플리케이션 사용자가 수행할 일을 예측하여 추천으로 제공하고 싶다고 가정해보죠. 모델링과 제품에 대한 논의를 함께 진행하는 것부터 시작합니다. 무엇보다도 머신러닝이 실패할 때 우아하게 처리하도록 제품을 설계하는 것도 포함해야 합니다.

 

처음부터 예측에 대한 모델의 신뢰도를 고려하여 신뢰도 점수를 기반으로 추천 내용을 다르게 구성할 수 있습니다. 신뢰도가 90% 잉상이면 적극적으로 제안합니다. 50% 이상이면 표시는 하지만 크게 강조하지 않습니다. 신뢰도가 50% 이하라면 표시하지 않습니다.

 

Q. 머신러닝 프로젝트에서 초점을 맞춰야 할 곳을 어떻게 결정하나요?

A. 성능 병목(impact bottleneck)을 찾아야 합니다. 즉 개선할 경우 가장 큰 가치를 제공할 수 있는 파이프라인의 구성 요소를 의미합니다. 다른 회사와 일할 때 보면 올바른 문제를 다루고 있지 않거나 올바른 개발 단계를 따르고 있지 않은 경우를 종종 봅니다.

 

모델과 관련된 문제가 많습니다. 이를 찾는 가장 좋은 방법은 간단한 모델로 바꾸고 전체 파이프라인을 디버깅하는 것입니다. 모델의 정확도가 문제가 아닌 경우가 많습니다. 성공적인 모델이라도 제품이 실패하는 경우가 많습니다. 

 

Q. 왜 간단한 모델로 시작하는 것을 일반적으로 추천하나요? 

A. 프로젝트 계획은 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 합니다. 가장 좋은 방법은 최악의 성능을 알기 위해 '허수아비 모델'로 싲가하는 것이죠. 초기엔 단순하게 사용자가 이전에 선택한 행동을 제안할 수 있습니다. 

 

이렇게 하면 예측이 얼마나 자주 들어맞을까요? 틀렸을 때 사용자를 얼마나 성가시게 할까요? 모델의 성능이 이 기준보다 크게 높지 않다고 가정해도 이 제품이 여전히 가치가 있을까요?

 

이는 챗봇, 번역, Q&A, 요약 같은 자연어 이해와 자연어 생성에 잘 적용됩니다. 예를 들어 요약의 경우 단순히 해당 글에서 다루는 상위 키워드나 카테고리를 뽑는 것으로도 대부분의 사용자 요구를 충족할 수 있는 경우가 많습니다.

 

Q. 전체 파이프라인을 구축한 후에 성능 병목을 어떻게 찾나요?

A. 먼저 성능 병목이 해결되었다고 상상하세요. 그리고 예상되는 노력을 들일 만큼 가치가 있는지 스스로에게 물어보세요. 저는 프로젝트를 시작하기도 전에 데이터 과학자에게 트윗을 쓰거나 회사에 보도자료를 작성하라고 권장합니다. 이렇게 하면 본인이 노력했기에 멋지다고 생각하거나 결과를 강조하는 실수를 피할 수 있습니다. 

 

결과에 상관없이 프로젝트 결과를 발표할 수 있다면 이상적입니다. 최상의 결과를 얻지 못하더라도 여전히 도움이 되나요? 무언가를 배우거나 어떤 가정을 검증했나요? 배포에 필요한 노력을 낮추도록 인프라를 구축하면 이런 전략에 도움이 됩니다.

 

링크드인에서 몇 줄의 텍스트와 하이퍼링크로 구성된 작은 윈도는 매우 유용한 디자인 요소이며 데이터 사용해 커스터마이징할 수 있었습니다. 디자인이 이미 승인되었기 때문에 직업 추천 같은 프로젝트를 위해 간단히 실험해볼 수 있었습니다. 자원 투자가 적었기에 영향이 크지 않았고 빠르게 반복할 수 있었죠. 오히려 윤리, 공정성, 브랜딩처럼 엔지니어링이 아닌 문제들이 장벽이었습니다.

 

Q. 어떤 모델링 기술을 사용할지 어떻게 결정하나요

A. 먼저 데이터를 직접 살펴봅니다. 링크드인 사용자에게 그룹을 추천하는 모델을 만든다고 가정해보죠. 단순하게 그 회사 이름이 제목에 포함되어 있고, 가장 인기 있는 그룹을 추천할 수 있습니다. 몇 가지 경우를 살펴보니 오라클 회사에 대해 가장 인기있는 그룹 중 하나는 '오라클 최악이네!'였습니다. 오롸클 직원에게 추천하기엔 아주 나쁜 그룹입니다.

 

모델의 입력과 출력을 직접 살펴보는 노력은 언제나 그만한 가치가 있습니다. 샘플 목록을 아래로 스크롤하면서 이상한 것이 없나 살펴보세요. IBM에서 제 부서장은 어떤 일을 하기 전에 항상 한 시간 정도는 수동으로 직접 해봐야 한다는 철칙을 가지고 있었습니다.

 

데이터를 들여다보면 유용한 경험을 얻고, 모델에 대해 생각하고, 제품을 재구성하는 데 도움이 됩니다. 데이터셋에 있는 샘플을 빈도 기준으로 순서를 매긴다면 샘플의 80% 정도를 순식간에 구별해서 레이블을 부여할 수도 있습니다.

 

예를 들어 조본에서는 고객들이 기록한 식단을 분석할 수 있었습니다. 직접 상위 100개에 레이블을 부여하니 기록의 80%를 처리했고, 텍스트 인코딩과 언어의 다양성과 같이 앞으로 처리해야 할 핵심 문제에 대해 강한 확신을 가지게 되었습니다.

 

최후의 보루는 결과를 내기 위해 많은 인력을 투여하는 것입니다. 이렇게 하면 친구에게 고릴라 태그를 붙이는 것 같은 모델의 차별적인 행동이나 자동으로 생성된 추억 앨범에 고통스러운 과거 경험ㅇ르 너허는 것처럼 공감하기 어려운 동작을 찾아낼 수 있습니다.

 

p.51

프로젝트의 성공 지표와 모델의 성공 지표가 불일치해 많은 머신러닝 프로젝트가 시작부터 실패하는 거서을 보았습니다. 많은 프로젝트가 좋은 모델을 만들고도 실패하는 이유는 모델의 복잡도 때문이 아니라 제품에 도움이 되지 않는 ㅁ도ㅔㄹ이었기 때문입니다.

 

p.51-52

머신러닝을 시작할 때 첫 번째로 만드는 모델은 제품의 요구사항에 맞는 가장 간단한 모델이어야 합니다. 왜냐하면 머신러닝에서는 결과를 만들고 평가하는 것이 모델의 성능을 향상하는 가장 빠른 방법이기 때문입니다. 

 

p.53

제품이나 기능에 대해 뚜렷한 목표를 가지고 시작하는 것이 중요하다고 이야기했습니다. 목표가 명확하다면 측정 대상을 정의하여 목표가 달성되었는지 판단해야 합니다. 이 지표는 모델의 성능 지표와는 다르며, 오직 제품의 성공을 반영해야 합니다. 제품의 성능 지표는 어떤 기능으로 유입된 사용자 수와 같이 간단하거나 추천 상품의 클릭률(CTR)처럼 복합적인 의미일 수 있습니다.

 

제품의 성능 지표가 제품이나 기능의 목표를 표현하기 때문에 궁극적으로 유일하고도 중요한 지표입니다. 다른 모든 성능 지표는 제품의 성능을 향상하기 위해 사용합니다. 하지만 제품의 성능 지표가 하나일 필요는 없습니다. 대부분의 프로젝트가 제품 성능 하나를 향상시키는 데 촛점을 맞춥니다. 하지만 종종 특정 지점 아래로 내려가면 안 되는 가드레일 메트릭(Guardrail Metric)과 같은 여러 다른 측정 지표로도 제품이 받는 영향을 측정합니다. 예를 들어 한 머신러닝 프로젝트의 목표를 CTR같은 측정 지표를 증가시키는 것이지만 평균 사용자 체류 시간과 같이 다른 지표를 유지시키는 것도 목표로 삼을 수 있습니다.

 

머신러닝 에디터의 경우 추천의 유용성을 측정합니다. 예를 들어 추천을 선택한 횟수의 비율을 사용한다면 이 측정값을 계산하기 위해 머신러닝 에디터의 인터페이스는 사용자가 제안을 수락했는지 감지해야 합니다. 입력창 위에 추천 내용을 띄워서 클릭할 수 있도록 만드는 것도 한 방법입니다. 

 

제품마다 가능성 있는 머신러닝 방법은 많습니다. 이런 머신러닝 방법의 효과를 측정하려면 모델의 성능을 확인할 필요가 있습니다.

 

p.53~54

제품을 만들었지만 아직 배포 전이라면 사용 횟수 기반의 지표를 측정할 수 있습니다. 그럼에도 성능이 향상되었는지 평가하기 위해 오프라인 메트릭(Offline Metric) 또는 모델 메트릭(Model Metric)이라 부르는 별도의 성능 지표를 정의하는 것이 중요합니다. 좋은 오프라인 메트릭은 사용자에게 모델을 노출하지 않고 평가할 수 있어야 하고, 제품의 목표와 측정 지표가 가능한 한 연관되어야 합니다. 

 

모델링 방식이 다르면 모델 측정 지표가 다릅니다. 모델링 방법을 바꾸면 제품의 목표를 달성하는 데 충분한 모델 성능을 쉽게 얻을 수도 있습니다. 

 

예를 들어 사용자가 온라인 쇼핑몰에서 검색어를 입력할 때 추천 단어를 제시한다고 가정해보죠. 사용자가 추천한 단어를 얼마나 클릭했는지 나타내는 클릭률을 계산해 이 기능의 성공을 측정합니다. 

 

추천 상품을 생성하기 위해 사용자가 입력하는 단어를 추측하는 모델을 만들어 사용자 입력에 따라 예측된 문장을 제시합니다. 얼마나 많이 다음 단어를 올바르게 예측했는지 단어 수준의 정확도를 계산하여 모델의 성능을 측정합니다. 이런 모델은 제품의 CTR을 높이기 위해 아주 높은 정확도를 달성해야 합니다. 왜냐하면 한 단어만 잘못 예측해도 쓸모없는 추천을 만들기 때문입니다. 그림 [2-1]의 왼쪽 부분에 이 방법이 나타나 있습니다.

 

또 다른 방법은 사용자의 입력을 상품 카테고리로 분류하고 가장 가능성 있는 세 개의 카테고리를 추천하는 훈련을 하는 것입니다. 단어의 정확도보다 카테고리에 대한 정확도를 사용해 모델의 성능을 측정합니다. 카테고리의 개수는 어휘 사전에 있는 단어의 개수보다 훨씬 작기 때문에 최적화하기 훨씬 쉽습니다. 또한 클릭을 유도하기 위해서는 모델이 하나의 카테고리만 정확하게 예측하면 됩니다. 이 모델을 사용하면 제품의 CTR을 증가시키기가 훨씬 쉽습니다. [그림 2-1]의 오른쪽에서 이 방법의 동작 방식을 볼 수 있습니다.

p.55-56

다음은 모델링 작업을 쉽게 만들기 위해 애플리케이션을 수정하는 세 가지 사례입니다.

 

- 신뢰도가 기준 이하인 경우 모델의 출력 결과를 생락할 수 있도록 인터페이스 바꾸기 : 예를 들어 사용자가 입력한 문장을 자동으로 완성하는 모델을 만들 때 일부 문장에서만 잘 동작할 수 있습니다. 이런 경우 모델의 신뢰도 점수가 90%일 때만 사용자에게 추천을 보여주도록 구현할 수 있습니다.

 

- 최상의 모델 예측뿐만 아니라 다른 예측이나 경험적인 규칙으로 만든 결과를 제시하기 : 예를 들면 대부분의 웹사이트는 모델이 출력한 추천을 하나 이상 보여줍니다. 같은 모델을 사용하더라도 하나가 아니라 다섯 개의 후보 항목을 추천하면 사용자에게 도움이 될 가능성이 더 높습니다. 

 

- 모델이 실험적인 경우 피드백을 받을 수 있도록 사용자와 소통하기 : 사용자의 모국어를 감지하여 자동으로 번역을 수행하는 웹사이트는 종종 번역이 정확하고 유용한지 알기 위해 사용자에게 피드백을 받을 수 있는 버튼을 제공합니다.

 

주어진 문제에 적합한 모델링 방법이더라도 제품 성능에 잘 맞는 모델 측정 지표를 추가로 만들면 이따금 도움이 됩니다.

 

간단한 웹사이트 스케치로부터 HTML을 생성하는 모델을 만드는 데이터 과학자와 일한 적이 있습니다(그가 쓴 [Automated front-end development using deep learning (딥러닝을 사용한 자동 프런트엔드 개발)]을 참고하세요). 이 모델은 크로스 엔트로피 손실을 사용해 예측된 HTML 토큰과 올바른 토큰을 비교합니다. 하지만 이 제품의 목표는 토큰의 순서와 상관없이 생성된 HTML로 입력 스케치에 있는 것과 비슷한 웹사이트를 만드는 것입니다.

 

크로스 엔트로피 손실은 토큰의 정렬(alignment) 상태를 고려하지 않습니다. 모델이 맨 처음 하나의 토큰을 제외하고 올바른 HTML 시퀀스를 생성했다면 타깃과 비교했을 때 모든 토큰이 하나씩 밀려 있게 됩니다. 이런 출력은 거의 이상적인 결과이지만 손실값은 매우 높습니다. 모델의 유용성을 평가할 때 최적화 지표 이상을 고려해야 한다는 의미입니다. 이 예에서는 BLEU 점수를 사용하면 생성된 HTML과 이상적인 출력 사이의 유사도를 더 잘 측정할 수 있습니다.

 

마지막으로 제품은 모델 성능에 대한 합리적인 가정을 전제로 설계되어야 합니다. 완벽해야지 유용한 모델에 제품이 의존할 경우, 부정확하거나 심지어 위험한 결과를 만들 가능성이 높습니다.

 

예를 들어 약 사진을 보고 환자에게 약의 종류와 복용량을 알려주는 모델을 만든다고 가정해보죠. 사용 가능한 수준에서 모델이 만들 수 있는 최악의 정확도는 무엇일까요? 만약 이 정확도에 대한 요구사항이 현재의 방법으로는 달성하기 어렵다면, 예측 오류로 인해 사용자가 위험에 처하지 않고 이 서비스를 사용할 수 있도록 재설계할 수 있나요?

 

머신러닝 에디터는 글에 대한 추천을 제공합니다. 대부분의 머신러닝 모델에는 적합한 입력과 그렇지 않은 입력이 있습니다. 제품 관점에서 보았을 때 도움을 줄 수 없다면 (그리고 문제가 되지 않는다면) 입력보다 나쁜 출력을 만드는 기회를 줄이는 것이 좋습니다. 모델의 성능 지표에 어떻게 이를 표현할 수 있을까요?

 

찬성 개수를 바탕으로 질문이 좋은지 아닌지 예측하는 분류 모델을 만든다고 가정해보죠. 분류기의 정밀도(precision)는 좋다고 예측한 질문 중에 정말로 좋은 질문의 비율로 정의됩니다. 반면 재현율은 데이터셋에 있는 좋은 질문 전체에서 모델이 좋은 질문으로 예측한 비율입니다.

 

항상 관련 있는 추천을 제공하려면 모델의 정밀도를 우선시해야 합니다. 정밀도가 높은 모델이 질문을 좋은 것으로 분류할 때 (그리고 추천을 만들 때) 실제로 이 질문이 좋을 가능성이 높기 때문입니다. 정밀도가 높다는 의미는 올바른 추천을 만들 가능성이 높다는 의미입니다.

 

p.58

최신성(freshness)에 대한 요구사항이 모든 문제에 동일한 것은 아닙니다. 고대 언어에 대한 번역 서비스는 다루는 데이터가 비교적 일정하게 유지된다고 예상할 수 있지만, 검색엔진을 구축하려면 사용자의 검색 패턴이 변화하는 속도에 맞춰 검색엔진이 진화할 수 있어야 합니다.

 

비즈니스 문제에 따라서 모델을 최신으로 유지하는 것이 얼마나 어려울지 고려해야 합니다. 얼마나 자주 모델을 다시 훈련해야 하고 훈련할 때마다 드는 비용은 얼마일까요?

 

머신러닝 에디터의 경우 '잘 쓰인 문장'의 정의가 변화하는 주기는 비교적 길 것이라 생각할 수 있습니다. 아마도 일 년 정도일 겁니다. 하지만 최신성에 대한 요구 사항은 특정 도메인을 대상으로 할 경우 바뀔 수 있습니다. 예를 들어 수학에 대한 올바른 질문 방법은 음악 트렌드에 대한 질문 방법보다 훨씬 더 느리게 바뀔 것입니다. 매년 모델을 다시 훈련해야 한다고 예상한다면 훈련에 필요한 새로운 데이터를 매년 모아야 할 것입니다.

 

기준 모델과 단순한 모델은 입력과 타깃이 쌍을 이루지 않은 데이터에서 학습할 수 있어 데이터 수집 과정이 간단합니다 (작년의 새로운 질문만 찾으면 됩니다). 복잡한 모델은 입력과 타깃 쌍이 필요합니다. 즉 동일한 문장이 '좋고', '나쁜' 방식으로 쓰인 샘플을 찾아야 한다는 의미입니다. 최신성 요구사항을 만족시키려면 입력 타깃 쌍을 구하는 것보다 훨씬 어렵습니다. 업데이트된 데이터셋을 준비하는 데 시간이 훨씬 많이 필요하기 때문입니다.

 

애플리케이션의 인기가 높으면 데이터 수집 요구사항을 줄일 수 있습니다. 머신러닝 에디터의 질문 추천 서비스가 입소문을 타면 사용자가 출력의 품질을 평가하는 버튼을 추가합니다. 그다음 사용자의 원래 입력과 모델 예측 그리고 이와 관련된 사용자 평가를 모아 훈련 세트로 사용합니다.

 

하지만 애플리케이션이 유용해야 인기가 높아집니다. 이를 위해선 사용자의 요청에 제때제때 응답해야 합니다. 따라서 모델의 예측 속도가 중요한 요소로 고려되어야 합니다.

 

p.63

예를 들어 뉴스 기사의 조회 수를 예측하는 모델을 찾는다고 가정해보죠. 하지만 뉴스 기사와 연관된 조회 수로 구성된 데이터셋을 찾기는 어렵습니다. 대신 공개된 위키백과 트래픽 통계 데이터셋을 사용하여 예측 모델을 훈련할 수 있습니다. 이 모델의 성능이 만족스럽다면 뉴스 기사 조회 데이터셋이 주어질 경우, 모델이 잘 동작하리라고 믿을 만합니다. 비슷한 데이터셋을 찾으면 접근 방식을 검증하는 데 도움이 되고 데이터 수집에 자원을 합리적으로 투자할 수 있습니다.

 

이 방법은 독점적인 데이터를 다룰 때도 유용합니다. 종종 예측 작업에 필요한 데이터셋을 얻기가 쉽지 않으며 어떤 경우에는 필요한 데이터를 수집하려면 허락이 필요할 때도 있습니다. 이런 경우 비슷한 데이터셋에서 잘 동작하는 모델을 구축하여 결정권자를 설득해 새로운 데이터 수집 파이프라인을 구축하거나 기존의 파이프라인을 사용할 권한을 얻는 것이 가장 좋은 방법입니다.

 

p.64-65

기존 코드를 찾아보면 두 가지 고수준의 목적을 달성할 수 있습니다. 비슷한 모델링 작업을 수행할 때 다른 사람이 직면했던 문제점을 파악하고 주어진 데이터셋에서 잠재적으로 발생할 수 있는 이슈를 알 수 있습니다. 따라서 제품의 목표와 동일한 문제를 해결하는 파이프라인과 앞서 선택한 데이터셋을 다루는 코드를 검색해보는 것이 좋습니다. 예제 코드를 찾았다면 먼저 직접 그 결과를 재현해보세요.

 

많은 데이터 과학자는 온라인에서 찾은 머신러닝 코드를 활용하여 원래 작성자가 주장한 것과 비슷한 수준의 정확도로 모델을 훈련할 수 있습니다. 매번 새롱누 방식이 잘 준비된 문서와 제대로 동작하는 코드를 제공하지는 않기 때문에 머신러닝 결과를 재현하기 어려운 경우가 많으며 항상 검증해봐야 합니다.

 

데이터 검색과 마찬가지로 비슷한 코드를 찾는 좋은 방법은 당면한 문제를 입력과 출력 종류로 표현하고, 그 다음 비슷한 종류의 문제를 다루는 코드를 찾는 것입니다.

 

예를 들어 [pix2code : Generating Code from a Graphical User Interface Screenshot] 논문의 저자인 토니 벨트라멜리는 웹사이트 스크린샷에서 HTML 코드를 생성할 때 이미지를 시퀀스로 변환하는 데 어려움을 겪었습니다. 이 문제를 해결하기 위해 이미지에서 시퀀스를 생성할 수 있고 훨씬 성숙된 분야인 이미지 캡셔닝의 기존 구조와 모범 사례를 활용했습니다. 이로 인해 완전히 새로운 작업에서 훌륭한 결과를 만들었고 유사한 애플리케이션이 쌓아온 수년 간의 성과를 활용할 수 있었습니다.

 

p.65

비슷한 작업을 해결하는 기존 모델을 찾고 원본 데이터셋을 훈련할 수 있다면 우리의 문제에 이를 적용하는 것만 남았습니다. 이를 위해 다음 단계를 따르는 것이 좋습니다.

 

1. 비슷한 오픈 소스 모델을 찾습니다. 훈련된 데이터셋도 함께 찾아 직접 훈련 결과를 재현해보는 게 이상적입니다.

2. 결과를 재현하고 나면 주어진 문제에 가장 가까운 데이터셋을 찾습니다. 그리고 이 데이터셋으로 앞에서 찾은 모델을 훈련합니다.

3. 데이터셋과 훈련 코드를 통합했다면 사전에 정의한 측정 지표를 사용하여 모델의 성능을 판단하고 반복을 시작합니다.

 

p.67

기억해야 할 중요한 한 가지가 있습니다. 초기 모델과 데이터셋을 구축하는 목적은 향후 더 나은 제품을 위해 필요한 모델링과 데이터 수집 작업에 도움이 될 정보를 만드는 것입니다.

 

간단한 모델로 시작해서 스택 오버플로 질문의 품질을 향상시키는 트렌드를 추출하면 빠르게 성능을 측정하고 반복할 수 있습니다.

 

반대로 처음부터 완벽한 모델을 만드는 방법은 막상 실전에서 잘 동작하지 않습니다. 머신러닝은 반복적인 과정입니다. 모델이 어떻게 실패하는지 확인하는 것이 가장 성능을 빠르게 높이는 방법입니다. 모델이 빨리 실패할수록 더 많이 향상시킬 수 있습니다.

 

p.68

반복하여 강조하지만 머신러닝에서 맞닥뜨리는 많은 어려움은 소프트웨어 분야의 가장 큰 도전 과제 중 하나와 비슷합니다. 아직 필요하지 않은 것을 만들려는 충동을 억제하는 일입니다. 많은 머신러닝 프로젝트는 초기 데이터 수집과 모델 구축 계획에 의존하면서도 이 계획을 주기적으로 평가하고 수정하지 않기 때문에 실패합니다. 머신러닝의 확률적 특징 때문에 현재 데이터셋과 모델이 얼마나 오래 유효할지 예측하기가 매우 어렵습니다.

 

이런 이유로 요구 사항에 맞는 가장 간단한 모델로 시작하는 것이 필수입니다. 그 다음 이 모델을 포함한 엔드투엔드 프로토타입을 구축하고 최적화 측면이 아니라 제품의 목표에 맞는 성능을 평가해야 합니다.

 

p.75

다른 소프트웨어 엔지니어링처럼 머신러닝에서도 가능한 최소 기능 제품(MVP)부터 차근차근 구현해야 합니다.

 

p.82

Flesh 가독성 점수

 

https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests#Flesch_reading_ease

Flesch–Kincaid readability tests - Wikipedia

 

p.91

머신러닝 제품을 만드는 가장 빠른 방법은 모델 구축과 평가를 재빠르게 반복하는 것입니다. 데이터셋 자체가 모델 성공의 핵심 요소입니다. 따라서 모델링과 마찬가지로 데이터 수집, 준비, 레이블링이 반복적인 과정이어야 합니다. 

 

p.93

초기 데이터셋을 어떻게 탐색할까요? 물론 첫 번째 단계는 데이터셋을 모으는 것입니다. 이 과정에서 기술자들이 완벽한 데이터셋을 찾으려 하기 때문에 막히는 것을 자주 봅니다. 기억하세요. 예비 결과를 만들 수 있는 간단한 데이터셋을 구하는 것이 목표입니다. 머신러닝의 다른 부분과 마찬가지로 간단하게 시작해서 발전시켜야 합니다.

 

p.97

얼마나 많은 데이터가 있나요? 대규모 데이터셋이 있다면 데이터 중 일부를 선택해 분석을 시작해야 합니다. 반면 데이터셋이 너무 작거나 일부 클래스의 샘플이 부족하다면 훈련된 모델도 데이터처럼 편향될 위험이 있습니다. 이런 편향을 피하는 가장 좋은 방법은 수집이나 증식을 통해 데이터의 다양성을 높이는 것입니다. 데이터의 양을 측정하는 방법은 데이터셋에 따라 다르지만 아래 표에 시작하기 좋은 몇 가지 질문이 있습니다.

 

p.99

writing.stackexchange.com은 30,000개 정도의 포스트를 담고 있는 비교적 작은 데이터셋이지만 이 작업은 1분 이상 걸립니다. 따라서 같은 작업을 반복하지 않도록 처리한 데이터를 다시 파일로 저장하는 것이 ㅈ호습니다. 코드의 마지막 부분처럼 판다스의 to_csv 함수를 사용하면 간단히 저장할 수 있습니다.

 

이런 습관은 모델 훈련에 필요한 모든 전처리 작업에 권장됩니다. 모델 최적화 과정 전에 수행해야 할 전처리 코드는 실험 속도를 크게 떨어뜨릴 수 있습니다. 가능한 항상 데이터를 미리 전처리하여 디스크에 저장하세요.

 

p.107

대부분의 데이터셋은 특성, 레이블 또는 둘을 조합하여 클러스터로 나눌 수 있습니다. 각 클러스터를 조사하고 클러스터 간의 유사도와 차이를 살펴보면 데이터셋에 내재된 구조를 식별하는 데 큰 도움이 됩니다.

 

여기에서 고려해야 할 점은 다음과 같습니다.

 

- 데이터셋에 얼마나 많은 클러스터가 있나요?

- 클러스터마다 다르게 보이나요? 어떤 기준을 사용하나요?

- 다른 클러스터보다 더 조밀한 클러스터가 있나요? 그렇다면 모델이 조밀하지 않은 지역에서 잘 동작하지 않을 수 있습니다. 특성이나 데이터를 추가하면 이 문제를 해결하는 데 도움이 됩니다.

- 모든 클러스터가 모델링하기 어려운 데이터를 나타내나요? 일부 클러스터가 복잡한 데이터를 표현하는 것처럼 보인다면 기록해두었다가 모델의 성능을 평가할 때 다시 이 문제를 살펴보겠습니다.

 

앞에서 언급한 것처럼 군집 알고리즘은 벡터에서 수행되기 때문에 일련의 문장을 군집 알고리즘에 그대로 전달할 수 없습니다. 군집 알고리즘에 사요하도록 데이터를 준비하기 위해서는 먼저 이 데이터를 벡터화해야 합니다.

 

p.111~112

 

벡터화와 데이터 누수

 

일반적으로 동일한 기술을 사용해 데이터를 벡터화하여 시각화하고 모델에 주입합니다. 하지만 중요한 차이가 있습니다. 모델에 데이터를 주입하기 위해 벡터화할 때는 훈련 세트를 벡터로 변환하기 위해 사용한 매개변수를 저장해야 합니다. 그 다음 검증 세트와 테스트를 변환할 때, 같은 매개변수를 사용해야 합니다. 

 

예를 들어 데이터를 정규화할 때 훈련 세트만 사용해 평균, 표준편차 같은 요약 평균을 게산해야 합니다(동일한 값으로 검증 세트를 정규화합니다). 제품 환경에서 추론을 수행할 때도 마찬가지입니다.

 

어떤 범주를 원-핫 인코딩할지 결정하거나 정규화를 수행하기 위해 검증과 훈련 데이터를 모두 사용하면 데이터 누수(data leakage)가 발생합니다. 훈련 세트 밖의 정보를 사용해 훈련 특성을 만들기 때문입니다. 이렇게 하면 모델 성능이 인공적으로 부풀려지고 실제 제품 환경에서는 잘 동작하지 못합니다.

 

 

p.124

알고리즘이 되어보기를 해본 적이 없다면 결과의 품질을 판단하기 어려울 것입니다. 반면 시간을 들여 직접 데이터를 레이블링해보면 모델링 작업을 쉽게 만드는 트렌드를 찾는 경우가 많습니다.

 

경험 규칙에 관한 절에서 이런 조언을 먼저 접했기 때문에 놀랍지는 않습니다. 모델링 방식을 고르는 것은 규칙을 만드는 것만큼 많은 가정이 전제가 되며 이런 가정은 데이터 기반이어야 합니다.

 

데이터셋이 레이블을 가지더라도 데이터에 레이블을 달아봐야 합니다. 이를 통해 레이블이 올바른 정보를 표현하고 있는지, 레이블이 정확한지 검증할 수 있습니다. 이 경우에는 유사 레이블인 질문의 점수를 품질을 측정하는 정도로 사용합니다. 직접 몇 개의 샘플을 레이블링해보면 이 레이블이 적절한지에 대한 가정을 검증할 수 있습니다.

 

 

 

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."