AI 서비스 기획 02 - 데이터 수집과 평가 (Data Collection + Evaluation)
안녕하세요, Daisy 입니다 ☺️
구글의 AI 서비스 R&D 조직 PAIR에서 제작한 “People + AI Guidebook”의 6단계의 가이드라인 중 Chapter 2에 대해 다뤄보도록 하겠습니다.
Chapter 2. Data Collection + Evaluation
Intro
Chapter 2에서는 다음 주제를 바탕으로 이야기합니다.
- 사용자의 니즈를 충족하기 위한 Training dataset
- 기존 Training dataset 사용과 dataset 자체 구축 결정
- 데이터 품질을 높이는 방법
- Label 생성 시 오류 (errors)와 편향 (bias)을 방지하기 위한 라벨러와의 협력 방법
예측을 위한 AI 기반 Product는 데이터의 패턴과 상관 관계를 인식하도록 모델을 학습시켜야 합니다. 여기에서 활용되는 데이터를 Training data라고 하며, 이는 이미지, 비디오, 텍스트, 오디오 등이 될 수도 있고 기존 데이터 소스를 사용하거나 명시적으로 새 데이터를 수집하여 모델을 학습시킬 수도 있습니다. 이처럼 소싱하거나 수집하는 Training dataset과 해당 데이터의 Labeling 방법은 모델의 결과와 UX의 품질을 결정하는데 큰 영향을 끼치므로, 다음과 같이 AI를 Product에 적용하기 전 6가지를 고려해야 합니다.
초기 단계의 양질의 데이터 수집 계획: 데이터 품질보다 모델 개발에 더 많은 시간과 리소스가 투자되는 경우가 대부분으로, AI 모델링 중 잘못된 데이터의 영향을 피하려면 초반 데이터 수집 단계부터 철저히 계획해야 함사용자의 니즈와 데이터 요구사항 연결: 사용자의 니즈와 연결하여 모델 학습에 필요한 데이터 유형을 결정하고 예측력, 관련성, 공정성, 개인 정보 보호 및 보안을 고려해야 함데이터 소싱 및 평가: Label이 지정된 데이터를 사용하거나 직접 데이터를 수집하는 등 프로젝트에 적합한지 확인하기 위해 데이터와 수집 방법을 평가하는 것이 중요함Dataset 구축 및 문서화: Dataset의 준비 및 수집, 처리 과정에서 내린 결정과 내용을 문서화해야 함라벨러 및 라벨링을 위한 설계: 지도 학습 (Supervised learning)의 경우 모델에서 유용한 결과를 얻으려면 정확한 데이터 Label을 갖는 것이 중요하므로 초반의 Label 지정 지침 및 UI 흐름을 신중하게 설계해야 함모델의 Tuning: 모델의 결과와 Product의 목표 및 사용자 니즈와 일치하는지 확인하고, 그렇지 않은 경우 데이터의 잠재적인 문제를 분석하여 해결해야 함
1. 초기 단계의 양질의 데이터 수집 계획
데이터는 AI에 매우 중요하지만 데이터 품질보다 모델 개발에 더 많은 시간과 리소스가 투자되는 경우가 대부분으로 개발 파이프라인 전체에 걸쳐 상당한 다운스트림 효과를 발생시킬 수 있는데 이를 ’Data cascades’라고 합니다. 다음은 Data cascades의 예시입니다.
서비스 기획: 식물의 사진을 업로드하면 식물 유형에 대해 예측하고 먹어도 안전한지 판단하는 앱 개발개발 과정: 이미지 분류 모델을 훈련하기 위한 Dataset 준비 → 이미 Label이 있고 모델을 학습하는 데 사용하기 쉬운 Dataset으로 이는 대부분 북미 원산의 식물 이미지로 이루어져 있음개발 결과: Plant Pal 앱을 출시 후 많은 사용자가 남미에서 식물 검출 오류를 보고하고 있음을 알게 됨
Data cascades : 노이즈가 없는 Dataset에서 학습된 모델이 노이즈가 많은 실제 환경에 배포되었을 때 제대로 작동하지 않는 상황으로, 이로 인해 한 모델의 출력 오류가 시스템의 다운스트림에 있는 후속 모델로 전파되어 더 많은 오류가 발생하는 Cascade 효과가 발생할 수 있음
이는 Training data와 실제 사용자 데이터 간의 불일치 효과가 지연된 Data cascades의 예로써, 만약 AI 모델을 개발할 때 남미 원산의 식물 이미지를 포함하거나 북미에서만 앱을 출시함으로써 문제를 피할 수 있었을 것입니다. 이처럼 일부 Data cascades는 진단이 어려울 수 있으며, 사용자가 말하기 전까지 그 영향을 알 수 없습니다. 따라서, 처음부터 데이터를 철저히 분석하여 완전히 이해하면 문제를 조기에 발견하는 데 도움이 될 수 있습니다. 고품질 데이터는 다음과 같이 정의할 수 있습니다.
- 실제 현상 또는 개체를 정확하게 표현하는 데이터
- 철저한 규칙을 기반으로 데이터를 수집하고 관리되는 데이터
- Reproducible (사실이나 결과를 다시 재현 가능한) 데이터
- 장기간에 걸쳐 유지 보수가 가능한 데이터
- 관련 애플리케이션에서 재사용이 가능한 데이터
- 근거가 충분하며 설명력이 있는 데이터
데이터 문제가 Data cascades에 어떻게 복합되는지를 보여주는 예
데이터의 불완전한 이해 → 현실과 맞지 않는 데이터 → 부실한 데이터 문서화 → 데이터 작업 저평가
Product 팀과 데이터 파트너의 역할 대부분은 AI를 개발할 때 데이터 파이프라인에 관여하므로, 그들의 우선 순위, 워크플로우와 과제를 이해하면 고품질 데이터를 위한 솔루션을 찾을 수 있습니다.
2. 사용자의 니즈와 데이터 요구사항의 연결
AI 모델을 학습하는 데 사용할 수 있는 Dataset에는 하나 이상의 Features (기능)과 가능한 Label들이 포함되어 있습니다.
Feature의 범위, Label의 품질, Training dataset은 모두 AI 모델의 품질에 영향을 미치는 요인입니다. 위 표에는 특정 달리기가 어느 정도 즐거운지 예측하기 위해 모델 훈련 시 사용 가능한 데이터입니다. Feature 및 Label이 해당 모델의 품질에 미치는 영향은 다음과 같습니다.
Example
만약 모델을 학습할 때 활용하는 데이터가
엘리트 러너들에게서만 수집한 데이터라면, 더 넓은 사용자 기반을 예측하기 위한 모델을 만들 때 유용하지 않을 것입니다. 반면, 엘리트 러너들을 위한 모델을 만드는 데 유용할 것입니다.Features
만약 Dataset에서
고도 상승 (Elevation) Feature이 제외된다면, 모델은 3.0마일 오르막 주행과 3.0마일 내리막 주행과 같이 매우 다른 Feature임에도 동일하게 평가할 것입니다.Label
- 재미있는 달리기로 예측할 가능성이 가장 높은 Feature을 식별하기 위해
러너의 주관적 경험을 보여주는 Label이 추가되면 더 효과적으로 예측할 수 있을 것입니다. - 모델을 훈련하는 데 필요한 Example, Features 및 Label을 결정할 때, 아래 예시와 같이
개념적인 수준에서 필요한 데이터를 정의해야 합니다. 예를 들어 “바쁜 일정에 맞춰 앱이 실행되면 좋겠다”라는 사용자 니즈 해결을 목표로 하는 Product에 대해 필요한 데이터를 정의해야 하는 것이죠.
- 재미있는 달리기로 예측할 가능성이 가장 높은 Feature을 식별하기 위해
- 2-1. Dataset 규격 설계
새 기능이나 Product에 대한 작업을 시작하기 전에 제품 사양서 (제품 요구사항)를 작성하는 것과 마찬가지로 데이터 요구사항을 지정하는 문서 (Dataset 설계 문서)를 작성하는 것을 고려하고, 사용자 니즈에서 정의한 문제를 기반으로 필요한 Dataset을 정의해야 합니다.
예를 들어, ‘Plant Pal’ 앱을 개발하고 있다고 가정하면, 이미지 분류 모델을 구축하고 학습해야 합니다. 이 작업에 필요한 데이터의 종류, 필요한 데이터의 형식 (이미지 형식, 속성, “만져도 안전함” 및 “먹어도 안전함” Label), 잠재적인 데이터 소스를 지정할 수 있습니다.
- 2-2. 데이터 가져오기
데이터 요구사항 정의 후 진행해야 할 다음 단계는 데이터의 수집으로, 먼저 재사용할 수 있는 기존 Dataset이 있는지 확인하는 것이 좋습니다.
- 프로젝트 니즈를 충족하는 기존 Dataset에 액세스할 수 있는지?
- 사용 가능한 Dataset이 있는지 탐색
- 다른 조직과 협력, Dataset의 구매, 클라이언트 데이터를 사용하여 기존 Dataset을 얻을 수 있는지?
만약 기존 Dataset을 가져오기로 결정한 경우 다음 정보를 체크해야 합니다.
- 해당 데이터가 사용자 및 Product에 적합한지?
- 데이터의 수집 방법
- 데이터의 변경사항
- 추가 데이터 소스 보강 여부
- 데이터 구축 시 Trade-offs 및 전제조건이 있는지?
- Dataset에 대한 데이터 규정 준수 표준 및 라이선스 정보는 무엇인지?
- Dataset에 데이터 카드와 같은 문서가 있는지?
반면, 기존 Dataset 외에 사내 데이터 수집 툴 또는 클라우드 소싱 플랫폼을 사용하여 새 Dataset을 생성해야 할 수도 있습니다.
- 2-3. 필요한 데이터와 보유한 데이터의 식별
프로젝트에 실제로 필요한 데이터 양과 데이터 유형은 무엇인지 파악해야 합니다. 또한, 상황에 따라 “많은 양의 데이터”가 데이터 요구사항을 해결하는 최선의 솔루션이 아닐 수 있습니다. 필요한 데이터를 결정할 때 다음 질문과 함께 현재 데이터를 평가하고, 각 변수에 대해 다음을 수행합니다.
- 다음과 같이 다른 방법으로 취급이 필요한 데이터가 있는지?
- 개인 식별 정보 (PII : Personally identifiable information)
- 보호된 특성
- PII 또는 보호 특성을 추론하는 데 사용할 수 있는 변수
- 주어진 데이터를 통해 사용자에게 어떤 이점을 제공하는지?
- 데이터를 안전하게 저장하고 사용할 수 있는지?
- 데이터의 보관기간은?
- 실제로 Labeling해야하는 데이터의 양은?
- 데이터가 사용자를 대표하는지?
- 사용 사례에 대한 대표성 정의 방법 혹은 대표 데이터의 수집방법은?
PII : 이름, 이메일 주소, 주민등록번호, 운전면허 번호, 여권 번호 및 기타 정부에서 발급한 ID와 같은 고유한 식별 번호, 지문 및 망막 스캔과 같은 생체 인식 데이터, 은행 계좌 번호 및 신용카드 번호를 포함한 금융 정보, 의료 기록 등과 같이 특정한 개인과 연결되어 개인의 신원을 밝히는 데 사용할 수 있는 모든 정보
- 2-4. Under fitting (과소적합)과 Over fitting (과적합)의 균형
하나의 컨텍스트에서 작동하도록 Product를 구축하려면 해당 컨텍스트를 안정적으로 반영하는 Dataset을 사용해야 합니다. 예를 들어, 사용자가 검색 엔진에 입력하는 단어를 Training data로 사용하는 것은 도움이 되지 않습니다. 왜냐하면 실제로 말하는 방식과 똑같이 검색을 입력하지 않기 때문이죠.
이처럼 Training data가 컨텍스트에 맞지 않으면 과적합하거나 과소적합할 위험이 증가합니다. Over fitting (과적합)은 모형이 Training data에 과하게 fit된 것을 의미합니다. 만약 모형에서 Training data를 과적합시킨 경우 Training data에 대해서는 우수한 예측 결과를 보여 줄 수 있지만 Test data나 새 데이터가 주어진 환경에서 모델의 예측 성능은 크게 저하될 것입니다.
또한 모델은 Under fitting (과소적합)으로 인해 잘못 예측 할 수도 있습니다. 여기서 모델은 Training dataset 기능 간의 관계의 복잡성을 제대로 학습하지 못하여 Training data 또는 Test, 새 데이터 환경에서 또한 좋은 예측을 할 수 없습니다.
이러한 모델 학습의 미묘한 차이를 이해해 과적합 및 과소적합을 방지할 수 있도록 도와주는 많은 리소스들이 존재합니다만, 먼저 학습에 필요한 Example, Features 및 Label과 같이 개념적인 요소에 대해 Product 팀의 모든 사람들과 토론하고, 사용자 니즈에 따라 가장 중요한 기능이 무엇인지 이야기하는 것이 중요합니다.
- 2-5. 공정성의 약속
모델 개발 단계에서 인간의 편견이 모델에 반영될 수 있습니다. 데이터는 실제 인간으로부터 수집되어 개인의 경험과 편견을 반영되므로, 이러한 패턴들이 암묵적으로 식별되고 증폭될 수 있습니다.
가이드북은 공정성과 관련된 몇 가지 조언을 하지만 완전한 리소스는 아니며, 현재에도 AI의 공정성 문제를 해결하고 불공정 편향을 최소화하는 것은 활발한 연구 영역입니다. 다음은 AI 모델이 사용자에게 장애를 야기하는 예시입니다.
재현적 피해: 특정 그룹에 대한 부정적인 고정관념을 증폭시키거나 반영시키는 경우기회 거부: 기회, 자원 및 전반적인 삶의 질에 대한 개인의 접근에 실제 결과와 지속적인 영향을 미치는 예측 및 결정을 내리는 경우불균형 오류: 제품이 작동하지 않거나 특정 사용자 그룹에 대해 더 자주 왜곡된 출력을 제공하는 경우불이익에 의한 피해: 시스템이 특정 인구통계학적 특성과 사용자 행동 또는 관심 사이에 불리한 연관성을 추론하는 경우
공정성에 대한 표준 정의는 없으며 상황에 따라 다를 수 있지만, 다음과 같이 Dataset에서 문제가 있는 편견을 완화하기 위한 방법들이 존재합니다.
- 2-5-1. 다양한 사용자 그룹에 적용되는 데이터 사용
Training data는 사용자들의 다양성과 문화적 배경을 반영해야 합니다. Facets 및 WIT와 같은 도구를 사용하여 Dataset을 살펴보고 편견을 더 잘 이해할 수 있습니다. 이 경우 모델을 적절하게 교육하기 위해, 실제 세계에서는 동일한 비율로 존재하지 않을 수 있는 서로 다른 사용자 그룹의 동일한 비율에서 데이터를 수집해야 할 수 있습니다. 예를 들어, 음성 인식 소프트웨어가 미국의 모든 사용자에게 동일하게 작동하도록 하려면 Training dataset이 소수인 경우에도 영어 원어민이 아닌 사용자의 데이터의 50%를 포함해야 할 것입니다.
- 2-5-2. 데이터 수집 및 평가 과정의 편중 고려
완벽한 중립 데이터는 존재하지 않습니다. 간단한 이미지에서도 사용된 장비와 조명이 결과를 형성합니다. 게다가 인간은 데이터 수집과 평가에 관여하고 있기 때문에 그 결과물에는 편견이 포함됩니다. 예를 들어, 사용자에게 새로운 건강 및 피트니스 목표를 권장하는 권장 시스템을 만들고 있다고 가정합니다. 피트니스 레벨이 폭넓은 사용자가 안전하게 달성할 수 있는 목표를 설정하는 것이 목적이라면, Training dataset에는 젊고 건강한 사용자 뿐만이 아니라 보다 다양한 사용자의 유형 데이터가 포함시키는 것이 중요합니다.
- 2-5-3. 개인정보 보호 및 보안 관리
사용자의 개인정보와 보안을 보호하는 것이 중요합니다. 위의 실행 관련 예시에서도 이 모델을 Train하는 데 필요한 생리학적 및 인구학적 데이터는 매우 민감합니다. 개인정보 보호 및 보안을 관리하기 위한 권장사항은 다음과 같습니다.
- PII 및 보호 특성에 대한 데이터 검토
- 해당 지역 및 제품 사용자 지역에서 데이터를 수집하거나 사용하기 전 법률 전문가와 상의
- 기본적인 데이터 정책이 개인의 정보를 보호하기에 충분하다고 생각하지 말 것
- 개인정보 보호를 위한 인프라, 교육 및 안내 프로그램 설정
- 경쟁사가 데이터를 입수할 가능성이 있는 상황 대비
- 개인 정보가 AI 예측의 일부로 노출될 수 있는 경우 개인정보 보호를 위한 추가 조치를 취할 것
예 : 주소 ⇒ 사용자의 이름을 사용하는 데 동의한 경우에도 익명화
다음과 같은 경우 개인 정보 보호 및 보안 전문가와 함께 논의하는 것이 좋습니다.
- 2-5-4. 데이터 사용에 대한 사용자 동의에는 어떤 제한이 있을까?
데이터를 수집 시 많은 국가의 법적 요구 사항은 사용자가 시스템에서 사용할 수 있는 데이터와 데이터를 사용할 수 있는 방법에 대해 가능한 많은 제어 권한을 부여하는 것입니다. 예를 들어 사용자에게 자신의 계정을 선택하고 해제하거나 삭제할 수 있는 기능을 제공하는지, 시스템이 이를 수용하도록 구축되었는지 확인해야 합니다.
- 2-5-5. 실수로 사용자 데이터를 공개할 위험이 있다면 결과는 어떻게 될까?
예를 들어, 개인의 건강 데이터는 비공개이고 안전할 수 있지만 AI 비서가 홈 스마트 스피커를 통해 사용자에게 약을 복용하라고 상기시키면 방에 있을 수 있는 다른 사람들에게 개인 의료 데이터가 부분적으로 공개될 수 있습니다.
다음은 런닝 앱에서 자신의 이름을 사용하는 데 동의한 경우 사용자 이름을 익명화하여 공개하지 않은 경우와 공개한 경우입니다.
- 사용자 이름 익명화 = Runner
개인 정보가 AI 추천 또는 예측의 일부로 노출될 수 있는 경우 개인 정보를 보호하기 위한 추가 조치를 취해야 함 (예 : 사용자가 사는 곳 ⇒ 커뮤니티에서 자신의 이름을 사용하는 데 동의한 경우에도 익명화)
- 사용자 이름 공개시 문제점
기본 데이터 정책이 개인 정보를 보호하기에 충분하다고 판단하지 말아야 함. 위와 같이 같은 지점에서 달리기를 시작하는 경우 사용자의 본명을 공개되어 해당 사용자의 거주지가 유추될 수 있음
Product에 필요한 데이터를 높은 수준으로 이해한 후, 특정 사용자 니즈와 데이터 요구사항을 연결합니다. 이 단계의 진행과정을 최대한 구체적으로 작성해야하며, 이는 팀이 앞으로 리소스를 사용하기로 결정하는 UX에 직접적인 영향을 미치기 때문입니다.
3. 데이터 소싱 및 평가
- 3-1. 기존 Dataset 사용
처음부터 Dataset를 구축하지 못할 수 있지만, 대신 Google Cloud AutoML, Google AI Dataset, Kaggle, AI Hub 등 공공 데이터 플랫폼과 같은 소스의 기존 데이터를 사용 할 수 있습니다. 지도 학습 (Supervised learning)을 고려하는 경우 데이터의 Label이 지정 돼 있거나 직접 추가해야 할 것입니다. 이 때, Dataset에 대한 사용 조건을 확인하고 사용 사례에 적합한지 검토하는 것이 좋습니다.
기존 Dataset을 사용하기 전에 Facets와 같은 도구를 사용하여 Dataset을 자세히 살펴보고 해당 Dataset에 내재 돼 있을 수 있는 차이나 편견에 대해 이해해야 합니다. 실제 데이터는 정제 돼 있지 않기 때문에, 데이터를 정리하는 데 상당한 시간이 소요되며 이 과정에서 결측값, 철자 오류 및 잘못된 형식 지정과 같은 문제가 있을 수 있습니다.
- 3-2. 독자적인 Dataset 구축
독자적인 Dataset 구축할 때, Product가 제공하려는 기능 및 서비스와 관련된 도메인 전문가를 관찰하는 것부터 시작하는 것이 좋습니다. 예를 들어 회계사가 재무 데이터를 분석하거나 식물학자가 식물을 분류하는 것을 관찰하는 것처럼, 그들이 생각하는 대로 인터뷰하거나 문제에 대한 비ML 솔루션을 통해 작업할 수 있다면 그들이 결정을 내릴 때 또는 조치를 취하기 전 어떤 데이터를 보는지 통찰력을 얻을 수 있습니다. 따라서, 도메인 전문가와의 일회성 파트너십 보다는 프로젝트 전체 라이프 사이클에 걸쳐 긴밀하고 지속적인 협업 및 관계를 유지하는 것이 좋습니다. 더불어 관련있는 Dataset을 조사하여 해당 Dataset을 사용할 수 있는지 평가하고, 모델이 학습하기에 충분한 정보를 갖기 위해 여러 소스의 데이터를 결합해야 할 수도 있습니다.
Dataset에 대한 잠재적 소스를 수집한 후에는 다음과 함께 데이터 분석 및 파악에 집중해야 합니다.
- 데이터 소스 식별
- 데이터 소스를 새로 고치는 빈도 확인
- Feature의 가능한 값, 단위 및 데이터 유형을 검사
- 특이치를 식별하고 실제 특이치인지 또는 데이터의 오류로 인한 특이치인지 파악
Dataset의 출처와 수집 방법을 이해하면 잠재적인 문제를 발견하는 데 도움이 됩니다. 새 Dataset을 구축해야 하는 경우 데이터 수집팀을 구성해야 할 수 있으며, 이 때 데이터 수집 계획을 문서화하여 품질 문제를 방지하고 편중 여부를 검토하는 것이 좋습니다.
- 질문하는 방식이 답변에 영향을 미치는지?
- 필요한 Label 옵션을 모두 제공했는지?
- 불균형한 클래스일 것 같다면, 더 희귀한 클래스의 오버샘플링을 고려해야 함
오버샘플링 (Oversampling) : 데이터 분석 및 ML에서 Dataset의 클래스 불균형을 해결하는 데 사용되는 기술로써, 모델이 소수 클래스를 올바르게 예측하고 다수 클래스에 대한 편향된 예측을 방지하는 방법을 학습할 수 있도록 하기 위해 수행됩니다. 클래스 불균형은 데이터의 한 클래스가 다른 클래스보다 훨씬 더 많이 표현될 때 발생되며, 오버샘플링을 통해 소수 클래스의 크기가 다수 클래스와 더 비슷해질 때까지 데이터를 복제하거나 합성하여 소수 클래스의 크기를 인위적으로 늘립니다. 오버샘플링은 모델의 성능을 개선하는 데 유용할 수 있으며, 특히 희귀 질환을 정확하게 식별하는 것이 중요한 의학적 진단과 같이 소수 클래스가 중요한 경우 유용할 수 있습니다. 그러나 오버샘플링으로 인해 노이즈와 과적합이 발생할 수도 있으므로 사용된 오버샘플링 기술의 결과를 신중하게 평가하는 것이 중요합니다.
- 3-3. 사용자로부터 실시간 데이터 수집
모델을 학습하고 Product가 실제로 사용되면 모델을 지속적으로 개선하기 위해 Product의 데이터를 수집할 수 있습니다. 데이터 수집 방법은 데이터의 품질에 직접적인 영향을 미칩니다. 앱 내 사용자 활동 배경에 암묵적으로 데이터를 수집하거나 사용자에게 직접 요청할 때 명시적으로 데이터를 수집할 수 있으며, 각각의 설계 상 고려사항은 서로 다를 것입니다.
- 3-4. Training dataset의 Noize 반영
입력 데이터가 실제 데이터와 최대한 유사해야 모델 오류가 발생하지 않습니다. 예를 들어 감정 분류를 위해 올바르게 포맷되고 오타가 없는 리뷰 Dataset을 사용하는 대신, 실제 Dataset에는 Noize가 많이 존재하므로 Training dataset에 또한 'Noize'가 포함되어야 합니다.
- 3-5. 포맷 검토
이처럼 실제 데이터는 Noize가 많습니다. “0” 값은 실제 측정된 “0”일 수도 있고 누락에 대한 측정 지표(Null)일 수도 있습니다. “country” 기능에는 “US”, “USA”, “United States” 등 다양한 형식의 엔트리가 포함될 수 있습니다. 사람은 데이터를 보는 것만으로도 의미를 파악할 수 있지만 AI 모델은 일관된 형식의 데이터에서 더 잘 학습합니다.
- 3-6. 다른 모델의 복합 오류 방지
예를 들어 A모델의 출력 값을 B 모델의 학습을 위한 입력 값으로 사용하는 경우 위험한 데이터 소스라는 점을 기억해야 합니다. 이와 관련된 오류는 시스템의 전체 오류로 연결되며 원본 Training data에서 멀어질수록 오류 원인을 판단하기에 더 어려워질 것이기 때문입니다.
- 3-7. 개인 식별 정보 보호
어떤 데이터를 사용하든 개인 식별 정보가 포함될 수 있습니다. 데이터 익명화는 다음과 같이 집계 (Aggregation)와 교정 (Redaction) 방법이 동반될 수 있습니다. 집계 (Aggregation)는 고유 값을 요약 값으로 바꾸는 프로세스입니다. 예를 들어 사용자의 분당 최대 심박수를 일 분당 평균 심박수 또는 범주별 높음/중간/낮음과 같이 Label의 단일 값으로 바꿀 수 있습니다. 교정 (Redaction)은 일부 데이터를 제거하여 익명화하는 방법으로 단일 사용자를 식별하는 데 사용할 수 있는 Features의 수를 줄이는 것을 목표로 합니다. 하지만 모든 상황에서 데이터를 완전히 익명화할 수는 없으므로 전문가에게 자문을 구하는 것이 좋습니다.
- 3-8. 데이터 유지보수 계획
Dataset을 구축하고 싶다면 Dataset을 유지할 수 있는지, 그리고 예기치 않은 위험을 감당할 수 있는지 고려해야 합니다. Dataset이 더 이상 사용되지 않을 때까지 다음 작업에 집중하여 Dataset 품질을 유지해야 합니다.
예방적 유지보수: 다양한 액세스 수준과 안정적인 식별자를 제공하는 저장소에 Dataset을 저장합니다. 단, 개인 및 연구실 웹 사이트에서 호스팅된 Dataset의 경우 어려울 수 있습니다.적응형 유지보수: 보존할 Dataset의 속성을 결정하고 업데이트합니다. Dataset은 지속적으로 요구사항을 충족하고 측정하는 현상의 현실을 나타내야 합니다.수정 유지 보수: Data cascade로 인해 문제가 발생할 수 있습니다. 예상치 못한 문제에 대비하여 플랜 B를 준비하고 Dataset의 모든 변경사항에 대해 상세히 로그를 기록합니다.
4. Dataset 구축 및 문서화
- 4-1. Dataset을 Train / Test Data로 분할
모델에 활용될 데이터는 Train / Test Data으로 분할합니다. 모델은 Training data에서 학습 후 Test data로 평가되며, 모델이 얼마나 잘 동작하는지 알 수 있습니다. 분할은 Dataset의 예제 수 및 데이터 분포와 같은 요인에 따라 달라집니다. Datasets의 가장 보편적인 분할 비율은 Train 60%, Test 40% 정도 입니다.
- 4-2. 데이터 분석 및 준비
모든 모델 교육 파이프라인에서 중요한 단계는 정제되지 않고 일관성 없는 데이터를 전처리하는 것으로 다음과 같습니다.
- 구조 추출
- 결측치 (Null) 처리
- 중복 제거
- 잘못된 데이터의 처리
- 특정 범위에 포함되도록 수정
- 외부 데이터 소스의 기존 값에 매핑하도록 조정
데이터 전처리 및 분석에는 반복 작업이 필요합니다. 데이터를 분석 및 시각화하면 Dataset의 문제를 식별하는 데 도움이 될 수 있으며, 추가적인 전처리가 필요할 수 있습니다.
- 4-3. 데이터 문서화
Dataset 문서화는 코드 문서화와 마찬가지로 중요합니다. Dataset의 소스, Dataset에 적용된 작업 및 변환 목록, 시간 경과에 따른 기록 및 권장 용도를 기록하면 다음 작업을 수행할 때 도움이 됩니다.
- Dataset 공유 시
- Dataset를 사용 및 게시여부 확인 시
- 타 Dataset과 비교 시
- AI 모델의 학습 데이터로 활용 시
- 데이터로 학습한 AI 모델의 동작 해석 시
- Dataset 유지보수 시
AI 기반 Product는 모델 학습과 Test에 필요한 데이터를 입수하는 것이 중요하므로 아래 질문을 체크하는 것이 좋습니다.
Q. 새로운 Dataset 구축 시, 데이터를 어떻게 수집할 계획인지?
Q. 기존 Dataset 활용 시, 만약 사용자 모집단을 위해 변경 또는 추가해야 하는 경우 어떻게 해야하는지?
5. 라벨러 및 라벨링을 위한 설계
지도 학습 (Supervised learning)의 경우 Label은 중요한 요소입니다. Label은 자동 프로세스를 통해 또는 라벨러에 의해 추가할 수 있습니다. ‘라벨러’는 다양한 컨텍스트, 스킬셋 및 전문화 수준을 포괄하는 총칭으로 다음과 같을 수 있습니다.
사용자: 사진 태그 부착 등의 조작을 통해 파생 Label 제공제너럴리스트: 크라우드 소싱 툴을 통해 다양한 데이터에 Label 추가전문 지식인: 전문 도구를 사용하여 의료 이미지 등의 Label 부착
라벨러에 대한 훈련과 라벨링을 책임 있게 완료할 수 있는 능력을 테스트하는 것은 데이터의 품질을 보증하는 데 중요합니다.
- 5-1. 라벨러 풀의 다양성 확보
사람들의 관점과 잠재적인 편견, 다양성과 균형을 맞추는 방법, 그리고 그들의 관점이 Label의 품질에 어떤 영향을 미칠 수 있는지 생각해보아야 합니다. 경우에 따라서는 라벨러가 무의식적인 편향을 인식할 수 있도록 교육을 제공하는 것이 편향을 줄이는 데 효과적이었습니다. 다음은 라벨러 풀을 평가하는 질문입니다.
1) 주석자가 최종 사용자와 유사한지?
→ 예를 들어 미국 주석에게 인도 요리의 이미지에 Label을 붙이도록 요청하고 있는지?
2) 라벨러와 사용자 간에 문화적 차이가 있는지?
→ 예를 들어 날짜 형식 규칙 (DD/MM/YYY 대 MM/DD/YYY)과 측정 척도 (미터 대 영국식)
3) 라벨러들은 무엇을 해야 하는지 알고 있는지?
→ 이들은 도메인 전문가인지, 아니면 교육이 필요한지?
→ 데이터 품질에 대한 가이드라인이 있으며 주석자의 모국어로 제공 돼 있는지?
→ 라벨러는 데이터가 무엇에 사용될지 알고 있는지?
- 5-2. 라벨러 상황 및 인센티브 조사
라벨러의 경험과 작업 수행 방법 및 방안의 근거를 검토해야 합니다. 지루함, 반복, 인센티브에 대한 설계 불량 등의 문제로 인해 작업을 잘못 완료할 위험이 항상 존재하며, 품질보다 볼륨에 초점을 맞춘 인센티브는 Dataset의 편중을 야기할 수 있습니다.
- 5-3. Labeling을 위한 설계 도구
Label 부착 도구는 Product 내 프롬프트에서 특수 소프트웨어까지 다양합니다. Product 내 Label을 요청할 때는 사용자가 올바른 정보를 쉽게 제공할 수 있도록 UI를 설계해야 합니다. 전문 라벨러를 위한 도구를 만들 때 평가자는 다음의 권장사항을 제공하는 것이 좋습니다.
바로 가기를 사용하여 키 흐름 최적화: 라벨러가 빠르고 효율적으로 작업하는 데 도움이 됨Label의 손쉬운 액세스: 사용 가능한 Label의 전체를 라벨러가 확인하고 사용할 수 있어야 하며, Label의 적용이 UI에서 빠르고 쉬워야 함라벨러 지원: 라벨러가 다른 의견을 구하고 오류를 수정할 수 있도록 유연한 워크플로우 지원자동 감지 및 표시 오류: 확인 및 플래그를 사용하여 실수로 인한 오류 방지타사 도구 기능 및 제한사항 검토: 라벨러가 온보딩되는 방법과 교육을 개선할 수 있는지 알아보고 플랫폼에서 프로세스를 파일럿하여 라벨러가 피드백을 제공하고 모호한 데이터에 플래그를 지정할 수 있는 방법이 있는지 확인합격 기준 설명: 작업 거부를 유발할 수 있는 오류를 명확하게 설명라벨러가 인스턴스를 '확실하지 않음'으로 표시하거나 건너뛸 수 있도록 허용: 라벨링을 반드시 지정하도록 강요하지 말 것가치 불일치: Label 해석 방법의 불일치를 발견하면 데이터와 Label을 재검토해야 함
라벨러의 작업에 대한 지침을 내릴 때 라벨러는 도메인과 작업에 익숙하지 않을 수 있으므로 다음 권장사항을 고려해야 합니다.
작업에 대한 예시 제공: 원활한 이해를 위해 작업에 대한 예시를 함께 기술단계별 작업 지침 제공: 필요한 모든 도구를 명시적으로 기술관리 가능한 그룹으로 분할: 단계 또는 규칙에 글머리 기호를 사용해 기술작업 지침에 대한 상세한 기술: 작업을 정확하게 수행하기 위해 세부사항을 상세히 기술
작업 및 지침 설계를 위해 라벨러와 함께 연구를 수행하도록 미리 계획해야 합니다. 작업을 시작하기 전 소규모 라벨러와 함께 작업을 파일럿하여 피드백과 예제 결과를 수집하면서 라벨러가 혼동 지점을 식별할 수도 있습니다.
다음은 라벨러 워크플로우를 위한 고려사항 입니다.
작업자 환경과 데이터 공동 작업자의 언어 고려: 데이터 공동 작업자를 위한 작업을 설계하여 데이터의 대표성을 개선하는 데 도움을 줄 수 있음라벨러의 시간 할당: 라벨러가 작업을 완료할 수 있는 충분한 시간을 주고 필요한 경우 추가 시간을 요청할 수 있도록 함모바일 라벨링을 위한 계획: 워크플로우를 조정하려면 텍스트에 대한 의존도를 최소화하고 다른 형식 (예 : 이미지 및 오디오)을 활용하고 직관적인 아이콘을 만들거나 현지 언어 지원을 제공
라벨러로부터 데이터 수집 후에는 라벨러 간 신뢰도를 분석하기 위해 통계 테스트를 수행해야 합니다. 신뢰성 부족은 지침이 잘못 설계된 것일 수도 있습니다. 다음은 지침으로 인해 라벨러가 겪을 수 있는 상황에 대한 예시입니다.
- 지침은 구체적이고 단순하게 작성해야 함
“running shoe”는 축구화 같은 다른 운동화를 선택하는 것을 쉽게 배제할 수 있음
- 여러 가지로 해석가능한 지침은 사용하지 말아야 함
예를 들어, “athletic shoe”에 대한 누군가의 주관적인 정의는 댄스 슈즈를 포함할 수도 있고 포함하지 않을 수도 있음
라벨러를 위한 도구를 설계하기 전 최종 사용자에 대해 생각하는 것과 같은 방식으로 라벨러의 니즈를 조사해야 하며, 이는 그들의 동기와 능력이 우리가 구축하는 모든 것에 직접적인 영향을 미치기 때문입니다.
Q. 라벨러는 어떤 작업자들인지?
Q. 라벨러의 맥락과 인센티브는 무엇인지?
Q. 라벨러는 어떤 도구를 사용하고 있는지?
6. 모델의 Tuning
모델 학습이 끝나면 결과 값을 평가하여 정의한 성공 지표에 따라 사용자 니즈를 충족 여부를 평가하고, 그렇지 않으면 모델을 재조정해야 합니다. Tuning은 학습 과정에서 하이퍼 파라미터나 모델 등을 조정하거나 Training data를 트러블 슈팅하는 것을 의미합니다. 모형을 평가하는 방법은 다음과 같습니다.
- What-If 도구 및 LIT(Language Interpreterability Tool)와 같은 도구를 사용하여 모델을 검사하고 사각지대 식별
- 지속적인 Test
- 개발 초기 단계에서 대상 고객의 다양한 사용자들과 함께 심도 있는 질적 피드백을 받아 Training dataset 또는 모델 튜닝과 관련된 “위험 요소” 파악
- 사용자 피드백을 위한 적절하고 사려 깊은 메커니즘을 구축했는지 확인
- UX 모니터링을 위해 맞춤형 대시보드 및 데이터 시각화 구축의 고려
- Chpater 1에서 다룬 예상하지 못한 2차 효과 확인
- 모델 변경은 고객 만족도 또는 사용자가 모델의 권장 사항을 수용하는 빈도 등 주관적인 UX의 명확한 지표와 연계
표준 지표 (예 : 정확도)를 개선하는 것 외에도 예상대로 작동하지 않는 시스템을 처리하는 방법에 대한 전략이 필요합니다. 변경 전후에 모델을 테스트해보고, 특히 Training data의 문제를 해결해야 할 수도 있으므로 다음을 고려합니다.
데이터 품질이 낮거나 충분하지 않은지: 더 나은 데이터를 더 수집할 수 있는지?의도하지 않은 결과: 설계 변경의 기회
- 출력 오류 및 오류 패턴
- 모델 성능의 변화로 이어질 수 있는 데이터의 변화 (데이터 드리프트)
- 시스템 자체의 오류, 해당 컨텍스트 또는 사용자가 원하는 것
- 어떻게 다음 Iteration에서 이러한 결과를 피할 수 있는지?
- 다음에 어떤 다른 문제가 발생할 수 있으며 어떻게 완화할 수 있는지?
- 사용자가 이해하기 특히 어려운 프로젝트 부분, 올바르게 설명되지 않은 항목에 대해
사용자는 오류로 볼 수 있음
- 누락 또는 선의의 거짓말 스캔
- 상황에 대한 설명 제공 예: “좋아하는 노래뿐만 아니라 모든 노래를 사용하여 추천 생성”
문제를 식별한 후에는 이를 특정 데이터 Feature 및 Label 또는 모델 파라미터에 다시 매핑해야 합니다. 이것은 쉽지 않거나 간단하지 않을 수 있으며, 문제 해결을 위해 Training data의 분포 재조정, Labeling 수정, 보다 더 관련성 높은 데이터 수집과 같은 방법이 동원될 수 있습니다. 다음은 Tuning 과정에 대한 예시입니다.
기능 출시: 런닝 앱에서 소모 칼로리를 계산하여 목표 칼로리를 소모할 수 있도록 권장하는 새 기능 출시베타 테스트 결과
- 권장사항을 받은 사용자가 다른 사용자보다 그만둘 가능성이 훨씬 더 높은 것으로 관찰
- 권장사항을 따르고 완료한 사용자는 같은 주에는 앱의 두 번째 실행을 위해 돌아올 가능성이 적었음
- Product Manager는 이 기능이 실패했다고 가정함. 그 이유는 사용자 인터뷰 및 데이터를 자세히 살펴본 결과 알고리즘이 예상 칼로리 소모량을 계산할 때 외부 온도 및 사용자 체중과 같은 중요한 데이터 가중치를 적용하지 않았기 때문
모델의 Tuning: 일부 사용자 조사 후, 일부 사용자가 칼로리 계산을 신뢰하지 않아 앱의 권장사항을 수락하는 포인트를 보지 못했기 때문에 종료하고 있음이 분명해졌으므로, 엔지니어링 팀은 알고리즘을 재조정하여 성공적으로 기능을 출시함
Tuning은 사용자의 피드백과 예기치 않은 상황으로 인해 발생하는 문제에 대응하여 모델을 조정하는 지속적인 프로세스이며, 개발 초기 단계에서 특히 중요합니다.
Q. 모델의 조기 테스트 계획은 무엇인지?
Q. 초기 베타 사용자가 모델을 제대로 테스트할 수 있을 정도로 충분히 다양한지?
Q. Tuning의 성공 여부를 판단하기 위해 어떤 지표를 사용할 것인지?
7. Conclusion
지금까지 두 번째 가이드라인을 정리해보았습니다. 데이터는 모든 AI 모델의 기반으로 관련 컨텍스트에서 데이터를 소싱하여 문제가 있는 편향을 체크함으로써 사용자의 니즈에 효과적으로 대응할 수 있을 것입니다. Chpter 2를 6가지로 재요약하면 다음과 같습니다.
초기 단계의 양질의 데이터 수집 계획: 데이터를 수집하고 준비할 때 미리 철저한 계획을 세워두면 전체 사이클에서 잘못된 데이터 선택의 영향을 방지할 수 있음사용자의 니즈와 데이터 요구사항 연결: 데이터의 Feature, Label 및 Example을 신중하게 고려해야 하며, 사용자의 니즈, 사용자 작업 및 예측을 필요한 Dataset을 체계적으로 분석해야 함. 잠재적인 Dataset을 식별하거나 데이터 수집 계획을 수립할 때 데이터를 검사하고 잠재적인 편향을 식별하며 데이터 수집 방법을 설계해야 함데이터 소싱 및 평가: 기존 Dataset을 사용하거나, 새 Training dataset을 구축하는 경우 모두 관련성, 공정성, 개인 정보 보호 및 보안을 고려해야 함Dataset 구축 및 문서화: Dataset의 준비 및 수집, 처리 과정에서 내린 결정과 내용을 문서화해야 함라벨러 및 라벨링을 위한 설계: Label이 올바르게 지정된 데이터는 효과적인 지도 학습 (Supervised learning)의 중요한 요소로, 라벨러가 사용하는 툴을 신중하게 검토하면 라벨의 정확성을 향상하는 데 도움됨모델의 Tuning: 모델의 파라미터를 조정할 뿐만 아니라 데이터를 검사하는 작업이 포함하여 모델을 엄격하게 테스트하고 Tuuning해야 함. 대부분의 경우 데이터의 문제로 추적될 수 있음
다음은 Chapter 3 “Mental Models”를 정리해보겠습니다.
Next series Mental Models
해당 글이 도움이 되셨다면 소중한 격려와 응원 부탁드립니다 ☺️
