<머신러닝 시스템 설계>의 'ch.11 머신러닝의 인간적 측면'의 내용을 요약 및 정리한 내용입니다.
https://product.kyobobook.co.kr/detail/S000201212403
머신러닝 시스템 설계 | 칩 후옌 - 교보문고
머신러닝 시스템 설계 | 프로덕션 환경에서 머신러닝을 다룰 때무수히 생겨나는 물음표를 해결해줄 MLOps 지침서머신러닝 시스템 개발은 선형이 아닌 순환 프로세스다. 모델을 개발해 배포하고
product.kyobobook.co.kr
ML 시스템은 기술뿐 아니라 비즈니스 의사 결정자, 사용자, 시스템 개발자를 포함합니다.
이번에는 사용자와 시스템 개발자가 ML 시스템과 상호 작용하는 방법을 알아봅니다.
1. ML 모델의 확률론적 특성으로 인해 사용자 경험이 어떻게 변경되고 영향받는지 논의합니다.
2. 하나의 ML 시스템의 여러 개발자가 효과적으로 협업하도록 하는 조직 구조를 알아봅니다.
3. ML 시스템이 사회 전체에 어떤 영향을 미치는지 논의합니다.
1. 사용자 경험
ML 시스템은 전통적인 소프트웨어와는 아래의 세 가지 이유로 차이가 발생합니다.
1. ML 시스템은 결정론적이 아니라 확률론적입니다.
- 일반적으로 전통적인 소프트웨어 시스템의 경우 동일한 소프트웨어에서 동일한 입력 데이터로 각기 다른 시간에 두 번 실행하면 동일한 결과를 얻을 것이라 기대합니다. 하지만 ML 시스템의 경우 같은 입력 데이터로 각기 다른 시간에 두 번 실행하면 다른 결과를 얻을 수 있습니다.
2. 확률론적 특성 때문에 ML 시스템의 예측은 대부분 맞지만, 보통 ML 시스템이 어던 입력에 대해 맞을지 모릅니다.
3. ML 시스템의 규모가 커지는 경우에는 예측을 생성하는 데 예상외로 오래 걸립니다.
이러한 차이점은 ML 시스템이 사용자 경험에 기존과 다른 방식으로 영향을 미침을 의미합니다. 특히 사용자가 전통적인 소프트웨어에 익숙하다면 더욱 그렇습니다. 또한 ML은 도입된 기간이 상대적으로 짧기에 ML 시스템이 사용자 경험에 어떤 영향을 미치는지 아직 충분히 연구되지 않았습니다.
이번에는 ML 시스템이 좋은 사용자 경험에 제기하는 세 가지 난제와 그 해결 방안을 논의합니다.
1.1 사용자 경험 일관성 보장하기
사용자는 앱이나 웹사이트를 사용할 때 일정 수준의 일관성을 기대합니다. 그러나 ML 예측은 확률론적이며 일관적이지 않습니다. 즉, 예측 컨텍스트에 따라 오늘 어떤 사용자에 대해 생성된 예측이 다음 날 같은 사용자에 대해 생성되는 예측과 다릅니다. 이러한 ML을 활용해 사용자 경험을 개선하려는 작업에서는 일관적이지 않은 ML 예측은 방해가 됩니다.
이러한 예로는 2020년에 부킹닷컴에서 발표한 사례 연구가 있습니다. 부킹닷컴에는 숙박 시설을 예약할 때 '조식 포함', '반려동물 동반 가능', '금연 객실' 등 원하는 조건을 지정하는 필터가 200여 개 있습니다. 필터가 너무 많아서 원하는 필터를 찾기까지 시간이 걸리죠. 부킹닷컴의 Applied ML 팀은 ML을 사용해 사용자가 특정 브라우징 세션에서 사용한 필터를 기반으로 원하는 필터를 자동으로 제안하고자 했습니다.
팀에서 직면한 난제는 ML 모델이 매번 다른 필터를 제안하면 사용자가 혼란스러워한다는 점이였습니다. 특히 이전에 적용했던 필터를 찾을 수 없다면 사용자는 더 혼란스러울 것입니다.
이러한 문제를 해결하기 위해 팀에서는 시스템이 동일한 필터 추천 사항을 반환해야 하는 조건과 시스템이 신규 추천 사항을 반환하는 조건을 지정하는 규칙을 만들었습니다. 이를 일관성-정확도 트레이드오프라고 부릅니다. 시스템에서 가장 정확하다고 간주하는 추천 사항이 사용자에게 일관성을 제공하는 추천 사항이 아닐 수도 있기 때문입니다.
1.2 '대부분 맞는' 예측에 맞서기
다음으로 모델 예측에서 일관성이 떨어지고 다양성이 높아지는 사례를 알아보겠습니다.
2018년부터 대형 언어 모델 GPT와 그 후속 모델인 GPT-2, GPT-3 이 전세계를 휩쓸고 있습니다. 이렇나 대규모 언어 모델의 장점은 작업별 훈련 데이터가 거의 혹은 전혀 필요하기 않은 상태에서 광범위한 작업에 대한 예측을 생성한다는 점입니다.
위의 사이트는 웹페이지의 요구 사항을 모델 입력으로 사용해 해당 웹 페이지를 생성하는 데 필요한 리액트 코드를 출력합니다.
이러한 모델의 단점은 예측이 항상 옳지는 않으며 예측을 개선하기 위해 작업별 데이터를 미세 조정하는 비용이 높다는 점입니다. 대부분 맞는 예측은 결과를 쉽게 수정할 수 있는 사용자에게 유용합니다. 다만 대부분 맞는 예측은 사용자가 응답을 수정하는 방법을 모르거나 수정할 수 없다면 그다지 유용하지 않게 됩니다.
생성된 코드가 올바르게 작동하지 않으면 지정된 요구 사항을 충족하는 웹 페이지로 랜더링되지 않게 됩니다. 해당하는 경우, 리액트 엔지니어라면 해당 코드를 빠르게 수정할 수 있지만 애플리케이션 사용자는 보통 리액트를 모르기에 문제가 됩니다. 이에 더해서, 해당 애플리케이션은 리액트를 모르는 사용자가 이용할 가능성이 높습니다.
이를 해결하기 위한 방법은 동일한 입력에 대한 여러 예측 결과를 사용자에게 표시해 적어도 하나 이상이 정답일 가능성을 높이는 것입니다. 이 예측 결과들은 비전문가 사용자도 평가할 수 있는 방식으로 랜더링돼야 하는 주의점이 존재 합니다.
앞선 경우라면, 사용자가 입력한 일련의 요구 사항이 주어질 때 모델은 리액트 코드 스니펫을 여러 개 생성합니다. 코드 스니펫은 시각적 웹 페이지로 렌더링되기에, 엔지니어가 아닌 사용자라도 자신에게 가장 적합한 것을 평가할 수 있습니다.
이러한 방법은 일반적으로 사용되고 있으며 이러한 방법은 인간이 개입해 최상의 예측을 선택하거나 혹은 기계가 생성한 예측을 개선하기에 '휴먼 인 더 루프' AI라고 부르기도 합니다.
1.3 원만한 실패
일반적으로 빠른 모델이라 하더라도 특정 쿼리에는 시간이 많이 걸립니다. 이는 특히 언어 모델이나 시계열 모델과 같이 순차적 데이터를 처리하는 모델에서 발생합니다.
이렇게 모델이 응답하기까지 너무 오래 걸리는 쿼리는 어떻게 해야 할까요?
해결책 중 하나는 백업 시스템을 사용하는 것입니다. 주 시스템에 비해 최적은 아니지만 빠른 예측이 가능하게 합니다. 이러한 시스템은 휴리스틱이나 단순 모델일 수 있으며, 미리 계산된 예측을 캐싱할 수도 있습니다.
즉, '주 모델이 예측을 생성하는 데 X밀리초보다 오래 걸리면 대신 백업 모델을 사용하세요.'와 같은 규칙을 지정합니다.
일부 회사는 이 간단한 규칙을 사용하는 대신 또 다른 모델을 사용해, 주 모델이 주어진 쿼리에 대한 예측을 생성하는 데 걸리는 시간을 예측하고 해당 예측을 주 모델 혹은 백업 모델에 적절히 라우팅하기도 합니다. 물론 추가된 모델로 인해 ML 시스템의 추론 레이턴시가 증가하게 됩니다.
여기에는 속도-정확도 트레이드오프가 존재합니다. 어떤 모델은 다른 모델보다 성능이 낮지만 추론을 훨씬 더 빨리 수행합니다. 이처럼 최적은 아니지만 빠른 모델은 사용자에게 조금은 성능이 떨어지는 예측을 제공하지만 레이턴시가 중요한 상황에서는 선호됩니다. 많은 기업에서는 두 모델 중 하나를 선택합니다. 하지만 백업 시스템을 사용하면 추론 속도가 빠른 모델과 정확도가 높은 모델을 모두 사용할 수 있습니다.
2. 팀구조
ML 프로젝트에는 데이터 과학자와 ML 엔지니어뿐 아니라 데브옵스 엔지니어나 플랫폼 엔지니어처럼 다른 유형의 엔지니어와 주제 전문가 (SME) 같은 비개발자 이해관계자도 포함됩니다. 다양한 이해관계자가 있을 때 최적의 ML 팀 구조는 무엇일가요?
두 가지 측면으로 살펴봅니다. 첫 번째는 크로스-펑셔널 팀의 협업이며, 두 번째는 논란이 되고 있는 엔드-투-엔드 데이터 과학자의 역할입니다.
2.1 크로스-펑셔널 팀 협업
ML 시스템을 설계할 때 종종 SME(의사, 변호사, 은행가, 농부, 스타일리스트 등)를 간과하지만, 많은 시스템이 해당 주제에 대한 전문 지식 없이는 작동하지 않습니다. SME는 ML 시스템의 사용자이면서 개발자이기도 합니다.
사람들은 대부분 주제 전문 지식을 데이터 레이블링 단계에서 필요하다고 생각합니다. 그렇기에 SME를 초기의 레이블링 단계에서만 포함시킵니다. 하지만 ML 모델 훈련 프로세스가 프로덕션에서도 이어서 진행되며 레이블링과 재레이블링 프로세스는 전체 프로젝트 수명 주기에 걸쳐서 진행되게 됩니다. 이는 SME가 초기뿐 아니라 나머지 수명 주기에도 큰 도움이 된다는 것을 의미합니다. 그럼에도 불구하고 아직까지는 한 프로젝트에서 서로 다른 인력이 협업할 때는 많은 어려움이 존재하는 것이 사실입니다.
하지만 앞으로는 SME가 프로젝트 계획 단계 초기에 참여하도록 하고, 엔지니어들에게 권한 부여를 요청하지 않고도 프로젝트에 기여할 수 있도록 해야 합니다. 이미 많은 기업에서 코드를 작성하지 않고도 변경 가능한 노코드 및 로우 코드 플랫폼을 구축해 SME가 ML 시스템 개발에 더 많이 참여하도록 돕고 있습니다.
2.2 엔드-투-엔드 데이터 과학자
ML 프로덕션은 ML 문제일 뿐 아니라 인프라의 문제이기도 합니다. MLOps를 수행하려면 ML 전문 지식뿐 아니라 배포, 컨테이너화, 작업 오케스트레이션 및 워크플로 관리와 관련된 운영 전문 지식이 필요합니다.
기업에서는 이러한 전문성을 ML 프로젝트에 적용하기 위해 아래의 두 접근법 중 하나를 선택합니다.
첫째는 모든 운영 측면을 관리하는 팀을 별도로 두는 것이고 둘째는 팀에 데이터 과학자를 포함시켜 전체 프로세스를 담당하게 하는 것입니다.
각 접근법이 어떤 식으로 작동하는지 알아보겠습니다.
접근법 1 : 별도의 팀을 구성해 프로덕션 관리하기
데이터 과학 및 ML 팀은 개발 환경에서 모델을 개발합니다. 그리고 별도의 팀이 프로덕션 환경에 모델을 배포합니다.
이 접근법을 사용하면 인력을 고용하기가 보다 용이합니다. 여러 기술을 갖춘 사람보다는 한 가지 기술을 갖춘 사람을 찾는 편이 더 쉽고, 관련자 개개인이 한 가지에만 집중하면되니 삶의 질이 향상되는 장점이 있습니다.
다만 이 접근법에는 아래와 같은 단점들도 존재합니다.
1. 커뮤니케이션 및 조정 오버헤드
- 한 팀이 다른 팀에 방해가 될 수 있습니다. 프레더렉 P. 브룩스는 "프로그래머 한 명이 한 달에 할 일을 두 명이서는 두 달에 할 수 있습니다."라고 말했습니다.
2. 디버깅 난제
- 무언가 실패했을 때 어느 팀의 코드가 원인인지 알 수 없습니다. 심지어 회사 코드 때문이 아닐 수도 있습니다. 무엇이 잘못됐는지 파악하려면 여러 팀의 협력이 필요합니다.
3. 책임 미루기
- 문제가 무엇인지 파악한 후에도 각 팀은 이를 수정하는 책임이 다른 팀에 있다고 생각할 수 있습니다.
4. 좁은 맥락
- 어느 누구도 전체 프로세스를 개선하는 가시성을 갖고 있지 않습니다.
- 예를 들어, 플랫폼 팀은 인프라 개선 방법에 대한 아이디어가 있지만 데이터 과학자의 요청이 있을 때만 대응합니다. 하지만 데이터 과학자는 인프라를 다루지 않아도 되니 인프라를 선제적으로 변경할 이유가 별로 없습니다.
접근법 2 : 데이터 과학자가 전체 프로세스를 담당하도록 하기
이 접근법을 사용할 때 데이터 과학 팀은 모델의 프로덕션 적용 또한 고려해야 합니다. 데이터 과학자는 프로세스에 관한 모든 것을 알고 있는 유니콘이 되어 데이터 과학보다는 상용 코드를 더 작성하게 될 수도 있습니다. 하지만 데이터 과학자가 인프라를 비롯한 모든 것을 아는 것은 매우 어렵습니다. 인프라에 필요한 기술은 데이터 과학과는 매우 다릅니다. 이론상 두 가지 기술을 모두 배울 수는 있지만 한 가지 시간을 할애할수록 다른 하나에 할애하는 시간은 줄어드는 결과가 초래됩니다.
그럼에도 데이터 과학자가 전체 프로세스를 담당하려면 좋은 도구가 필요합니다. 즉, 좋은 인프라가 필요합니다. 데이터 과학자가 인프라에 대한 걱정 없이 프로세스를 엔드-투-엔드로 감당할 수 있도록 하는 추상화가 있다면 어떨까요?
예를 들어, 도구에 '여기 데이터를 저장하는 곳이 있고(S3) 여기에 코드를 실행하는 단계가 있어(피처화, 모델링). 여기에서 코드를 실행해야 해 (EC2 인스턴스, AWS 배치, AWS 람다와 같은 서비리스 서비스). 각 단계에서 코드를 실행하는 데 필요한 것들이 여기 있어(종속성)'라고 말하고 이 도구가 모든 인프라를 관리한다면 어떨까요?
스티치 픽스와 넷플릭스에 따르면 풀스택 데이터 과학자의 성공은 어떤 도구를 갖췄는지에 달려 있습니다. 즉, "컨테이너화, 분산 처리, 자동 장애 조치 및 기타 고급 과학 개념의 복잡성으로부터 데이터 과학자를 추상화" 하는 도구가 필요합니다.
넷플릭스 모델에서 전문가들, 즉 처음에 프로젝트 일부를 담당했던 사람들은 먼저 아래의 그림과 같이 자신이 담당하는 부분을 자동화하는 도구를 만듭니다. 데이터 과학자는 이러한 도구를 활용해 프로젝트를 엔드-투-엔드로 담당합니다.
이번에는 ML 시스템이 사용자 경험에 어떤 영향을 미치며 조직 구조가 ML 프로젝트 생산성이 어떤 영향을 미치는지 알아봤습니다. 다음으로는 ML 시스템이 사회에 어떤 영향을 미치는지, ML 시스템 개발자가 실보다 득이 많은 시스템을 개발하려면 무엇을 해야 하는지 알아봅니다.
3. 책임 있는 AI
책임 있는 AI란 사용자에게 권한을 부여하고, 신뢰를 낳고, 사회에 공정하고 긍정적인 영향을 보장하기 위해 좋은 의도와 충분한 인식으로 AI 시스템을 설계, 개발, 배포하는 관행을 말합니다. 이는 공정성, 개인 정보 보호, 투명성, 책임과 같은 영역으로 구성됩니다.
이러한 용어들은 이제는 정책 입안자와 실무자 모두 진지하게 고려해야하는 사항이 되었습니다. ML은 우리 삶 거의 모든 측면에 활용되고 있기에 ML 시스템을 공정하고 윤리적으로 만들지 못하면 치명적인 결과를 얻을 수 있습니다.
그렇기에 ML 시스템 개발자는 시스템이 사용자와 사회 전반에 어떤 영향을 미칠지 고려해야 하며, 더 나아가 시스템에 윤리, 안전 및 포괄성을 구체적으로 구현해 모든 이해관계자가 사용자에 대한 책임을 인식하도록 도울 책임이 있습니다.
이번에는 ML 시스템을 책임 있게 만들기 위해 충분한 노력으 기울이지 않을 때 발생하는 문제를 간략히 소개합니다.
먼저, 상당히 유감스럽지만 많이 알려져 있는 ML 실패 사례 두 가지를 살펴봅니다. 그리고 데이터 과학자와 ML 엔지니어가 ML 시스템을 책임 있게 만드는 데 가장 유용한 도구와 자침을 선택할 수있는 예비 프레임워크를 소개합니다.
3.1 무책임한 AI : 사례 연구
이번에 살펴볼 AI 시스템 실패 사례들은 시스템 사용자뿐 아니라 시스템을 개발한 조직에도 심각한 피해를 초래했습니다. 조직이 잘못한 부분이 무엇이며 실무자가 이러한 실패 지점을 예측하기 위해 무엇을 할 수 있었는지 짚어보겠습니다. 이러한 사례 연구는 책임 있는 AI를 위한 엔지니어링 프레임워크를 살펴볼 때 배경이 될 것입니다.
3.1.1 사례 연구 1: 자동 채점기의 편향
2020년 여름, 영국은 코로나 19로 인해 대학 배치를 결정하는 중요한 시험임 A-레벨을 취소했습니다. 영국의 교육 및 시험 규제 기관인 오프퀼(Ofqual)은 시험을 치르지 않고 학생들에게 최종 A-레벨 성적을 할당하는 시스템의 사용을 승인했습니다. 에이다 러브레이스 기관의 존스와 사팍은 "오프퀄은 교사 평가에 근거에 학생에게 점수를 부여하는 방식을 거부했습니다. 학교 간 평가가 불공정하고, 세대 간에 비교가 불가하며, 성적 인플레이션으로 인해 결과가 평가 절하되기 때문입니다. 오프퀄은 특정 통계 모델, 즉 '알고리즘'을 사용해 이전 성적 데이터와 교사 평가가 결합해 성적을 할당하는 편이 더 공정하다고 추측했습니다."라고 이야기했습니다.
하지만 이 알고리즘에 따른 결과는 부당하고 신뢰할 수 없는 것으로 밝혀졌습니다. 학생 수백명이 이에 항의하면서 알고리즘을 없애야 한다는 대중의 외침이 빠르게 확산됐습니다.
얼핏 보면 알고리즘의 열악한 성능인 듯 보입니다. 오프퀄은 2019년 데이터로 테스트한 모델이 A-레벨 응시자들에 대해 60%의 평균 정확도를 보였다고 밝혔습니다. 즉, 모델이 배정한 성적 중 40%는 학생들의 실제 성적과 다를 것으로 예상했다는 뜻이죠.
모델 정확도가 낮아 보이지만 오프퀄은 알고리즘 정확도가 인간 채점자와 정확도와 대체로 비슷하다고 옹호했습니다.
인간 채점관의 점수도 선임 채점관이 작성한 점수와 비교했더니 약 60%만 일치했던 것 입니다. 하지만 이러한 인간 채점관과 알고리즘의 낮은 정확도는 단일 시점에서 학생을 평가할 때 근본적인 불확실성이 있음을 보여줌으로써 대중의 불만을 더욱 부추겼습니다.
대략적인 정확도만으로는 모델 성능을 평가하기에 충분하지 않습니다. 더구나 모델 성능이 많은 학생의 미래에 영향을 미친다면 더욱 그렇습니다. 해당 알고리즘을 살펴보면 자동 채점 시스템을 설계하고 개발하는 과정에서 최소한 세 가지 실패가 있음을 파악할 수 있습니다.
1. 올바른 목표를 설정하기 못함
2. 잠재 편향을 발견하기 위한 세분화된 평가를 수행하지 못함
3. 모델을 투명하게 만들지 못함
자세히 하나씩 알아보겠습니다. 물론 이 세가지를 해결하더라도 대중은 여전히 자동 채점 시스템에 불만을 가질 수도 있음을 명심해야 합니다.
실패 1: 잘못된 목표 설정
학생에게 점수를 매기는 자동 채점 시스템을 개발할 때 시스템 목표를 '채점 정확도' 라고 생각했을 겁니다. 하지만 오프퀄이 최적화하는 것으로 보이는 목표는 학교 간의 '기준 유치' 였습니다. 즉, 모델이 예측한 성적을 각 학교의 과거 성적 분포에 맞추는 것입니다.
예를 들어, A 학교의 과거 입시 실적이 B 학교를 능가했다면 오프퀄은 평균적으로 A학교 학생들에게 B 학교 학생들보다 더 높은 점수를 주는 알고리즘을 원했습니다. 오프퀄은 학생 간의 공정성보다 학교 간의 공정성을 우선시했습니다. 즉, 개인의 성적을 올바르게 매기는 모델보다 학교 수준의 결과를 올바르게 매기는 모델을 선호했단 의미입니다.
이 목표에 따라 모델은 과거 입시 실적이 저조한 학교에서 성적이 우수한 집단은 불균형적으로 강등했습니다. 과거에 학생들이 전체 D를 받은 적이 있는 수업의 학생들은 B와 C로 강등됐습니다.
오프퀄은 자원이 많은 학교가 자원이 적은 학교를 능가하는 경향이 있다는 사실을 고려하지 못했습니다. 알고리즘 자동 채점기는 학생의 현재 성적보다 학교의 과거 입시 실적을 우선시함으로써, 소외 계층이 많이 재학하는 자원 부족 학교의 학생들에게 불이익을 줬습니다.
실패 2: 편향을 발견하는 세분화된 모델 평가 부족
과거 입시 실적이 저조한 학교의 학생들에 대한 편향은 이 모델에서 발견된 많은 편향 중 하나일 뿐입니다.
자동 채점 시스템은 교사의 평가를 입력으로 고려했지만 전체 인구통계학적 그룹에서 교사의 평가 불일치를 해결하지는 못했습니다. 오프퀄은 이 시스템이 "2010년 평등법에 따른 일부 보호 대상 그룹에 대한 복합적인 불이익의 영향을 고려하지 않았습니다. 교사의 낮은 기대치와 일부 학교에 만연한 인종 차별로 인해 이중, 삼중으로 불이익을 받는 거죠."라고 이야기했습니다.
모델이 각 학교의 과거 입시 실적을 고려했으므로 오프퀄은 모델에 소규모 학교에 대한 데이터가 충분하지 않았다는 점을 인정했습니다. 소규모 학교의 경우 알고리즘으로 최종 등급을 매기는 대신 교사가 평가한 등급만 사용했습니다. 실제로 이는 인원이 적은 경향이 있는 사립 학교의 학생들에게 더 나은 등급을 주는 결과를 만들었습니다.
오프퀄의 모델이 다양한 규모의 학교와 다양한 배경을 가진 학생들에 대한 모델 정확도를 평가하는 등의 예측한 성적을 공개하고 다양한 데이터 샘플로 세분화된 평가를 수행했다면 이러한 편향을 발견할 수 있었을 것 입니다.
실패 3: 투명성 부족
투명성은 시스템에 대한 신뢰를 구축하는 첫 번째 단계입니다. 하지만 오프퀄은 알고리즘 자동 채점기의 중요한 측면을 너무 늦게 공개했습니다.
시스템 목적이 학교 간의 공정성을 유지하는 것임을 성적이 발표되는 날까지 대중에게 알리지 않았습니다. 따라서 대중은 모델이 개발되는 동안 이 목표에 대한 우려를 표할 수 없었습니다.
게다가 오프퀄은 교사가 모델 예측에 영향을 미치게끔 평가를 수정하는 것을 방지하기 위한 목적으로, 교사들이 학생 평가 및 석차를 제출한 뒤에도 자동 채점기가 그것을 어떻게 사용할지 교사들에게 알리지 않았습니다.
오프퀄은 모두가 결과를 동시에 확인할수 있도록, 결과를 공개하는 날까지 정확한 모델을 공개하지 않기로 결정했습니다.
물론 이러한 고려 사항은 좋은 의도에서 나온 것입니다. 다만 오프퀄이 모델 개발을 공개하지 않기로 결정했으므로 시스템은 독립적인 외부 조사를 충분히 받지 못했습니다. 대중의 신뢰를 바탕으로 운영되는 시스템은 대중이 신뢰하는 독립적인 전문가가 검토할 수 있어야 합니다. 왕립통계학회(RSS)는 이 자동 채점기 개발에 관해 조사하면서 오프퀄이 모델을 평가하기 위해 모은 '기술 자문 그룹'의 구성에 우려를 표했습니다. RSS는 "통계적 엄밀함을 보장할 더 강력한 절차적 근거가 없고 오프퀄이 검토하고 있는 문제가 더 투명하지 않은 한 오프퀄의 통계 모델의 정당성이 의심스럽다고 지적했습니다.
이 사례 연구는 많은 사람의 삶에 직접적인 영향을 미치는 모델을 구축할 때 투명성이 얼마나 중요한지 보여줍니다. 모델의 중요한 측면을 적시에 공개하지 않으면 어떤 결과를 얻게 되는지 알 수 있죠. 그리고 최적화할 목표를 올바르게 선택하능 일의 중요성 또한 보여줍니다. 잘못된 목표를 설정하면 올바른 목표에 대해서는 성능이 저조한 모델을 선택하게 될 뿐 아니라 편견을 영속화 할 수 있습니다.
이 사례 연구는 알고리즘으로 무엇을 자동화해야 하며 무엇을 자동화하지 말아야 하는지 사이의 모호한 경계를 보여주는 전형적인 예시입니다. 영국 정부에는 A-레벨 성적을 알고리즘으로 자동화해도 괜찮다고 생각하는 사람이 있을 겁니다. 반대로, 치명적인 결과를 얻을 가능성이 있어 애초에 자동화하지 말았어야 했다는 주장도 있죠. 경계가 명확해질 때까지는 AI 알고리즘을 오용하는 사례가 더 많아질 겁니다. 경계가 명확해지도록 하려면 시간과 자원을 더 많이 투자해야 하며 AI 개발자, 대중 및 당국의 진지한 숙고가 필요합니다.
3.1.2 사례 연구 2: 익명화된 데이터의 위험성
이 사례 연구는 알고리즘이 명백한 원인이 아니기에 더 흥미롭습니다. 오히려 민감한 데이터가 유출되도록 하는 요인은 데이터 인터페이스와 데이터 수집의 설계 방식입니다. ML 시스템 개발은 데이터 품질에 크게 의존하므로 사용자 데이터를 수집하는 일이 중요합니다. 연구 커뮤니티는 새로운 기술을 개발하기 위해 고품질 데이터셋에 엑세스해야 하며, 실무자와 기업은 새로운 유스케이스를 발견하고 새로운 AI기반 제품을 개발하기 위해 데이터에 액세스해야 합니다.
데이터셋을 수집하고 공유함으로써 데이터셋의 일부인 사용자의 개인 정보와 보안이 침해되기도 합니다. 사용자 보호를 위해 개인 식별 정보(PII)를 익명화해야 한다는 주장이 제기되기도 했습니다. 하지만 익명화는 개인 정보를 보호하고 데이터 오용을 막는 데 충분하지 않습니다.
2018년 온라인 피트니스 트래커 스트라바는 전 세계 사용자가 달리기, 조깅, 수영 등 운동을 한 경로를 기록한 히트맵을 게시했습니다. 히트맵은 2015년부터 2017년 9월까지 기록된 활동 10억 건에서 집계됐으며 총 거리는 270억 킬로미터였습니다. 스트라바는 사용한 데이터가 익명화됐으며 "사용자가 비공개나 개인 정보 보호 영역으로 지정한 활동을 제외했습니다."라고 말했습니다.
그런데 군인들도 스트라바를 사용했고, 데이터를 익명화했음에도 사람들이 스트라바의 공개 데이터로 해외 미국 기지의 활동을 드러내는 패턴을 알아챌 수 있었습니다. 아프가니스탄 전방 작전 기지, 시리아 내 튀르케예 군 순찰대, 시리아의 러시아 작전 지역 내 경비 순찰 가능성이 있는 것 등이 있었습니다. 어떤 분석가들은 이 데이터가 개별 스트라바 사용자의 이름과 심박수를 드러낸다고까지 말했습니다.
그렇다면 익명화는 어디서부터 잘못됐을까요?
첫째, 스트라바의 개인 정보 설정은 기본적으로 옵트아웃이었습니다. 사용자가 데이터 수집을 원하지 않으면 수동으로 선택을 해제해야 했죠. 사용자들은 이러한 개인 정보 설정 기본값이 명확하지 않을 때가 있으며 예상과 다를 수 있다고 지적했습니다. 일부 개인 정보 설정은 모바일 앱이 아닌 스트라바 웹사이트에서만 변경할 수 있었습니다. 이 사례는 사용자에게 개인 정보 설정에 관해 잘 알려주는 일이 중요함을 보여줍니다. 더 좋은 방법은 옵트아웃이 아니라 데이터 옵트인, 즉 기본적으로 데이터를 수집하지 않는 설정을 기본값으로 하는 것입니다.
하지만 사용자가 수동으로 개인 정보 설정을 변경하는 것은 문제를 피상적으로만 해결하는 방법입니다. 근본적인 문제는 오늘날 우리가 사용하는 기기들이 지속적으로 데이터를 수집하고 보고한다는 점입니다. 수집한 데이터를 어딘가로 저장해야 하는데 중간에서 누군가가 가로채어 오용할 수 있습니다.
스트라바가 보유한 데이터는 아마존, 페이스북, 구글처럼 훨씬 더 널리 사용되는 애플리케이션에 비해 규모가 작습니다. 그렇기에 스트라바의 실수는 군사 기지의 활동을 노출하는 데 그쳤지만 개인 정보 보호 실패는 개인뿐 아니라 사회 전반에 이보다 훨씬 더 큰 위험을 초래할 수 있습니다.
데이터 수집 및 공유는 AI 같은 데이터 기반 기술 개발에 필수지만 잠재적인 위험 또한 존재합니다. 이러한 사례 연구는 데이터를 수집하고 공유함에 따라, 데이터를 익명화하고 선의로 공개한 경우에도 잠재 위험이 있음을 보여줍니다. 사용자 데이터를 수집하는 애플리케이션 개발자는 사용자가 적절한 개인 정보 설정을 선택하는 기술적 노하우와 개인정보 인식을 가지지 않았을 수도 있음을 이해해야 합니다. 수집하는 데이터가 적어지는 한이 있어도 올바를 설정을 기본값으로 설정하기 위해 적극 노력해야 합니다.
3.2 책임 있는 AI의 프레임워크
해당 내용들은 ML 실무자로서 모델 동작을 감시하고 프로젝트 요구 사항을 충족하는 데 도움이 되는 지침을 설정하기 위한 기반이 됩니다. 다만 이 프레임워크가 모든 유스 케이스에 적합하지는 않습니다.
3.2.1 모델 편향의 출처 찾아내기
편향은 프로젝트 수명 주기 내 어느 단계에서든 발생합니다. 그렇기에 이러한 편향 모두를 해결하는 것은 어려우나 가능한 편향이 어디서 발생하는지 찾아내는 것은 중요합니다. 아래는 데이터 소스의 예이며 해당 목록 외에도 다양한 소스가 존재합니다.
훈련데이터
- 모델 개발에 사용한 데이터가 모델이 실제로 처리할 데이터를 대표하나요?
- 그렇지 않다면 모델은 훈련 데이터에 표시되는 데이터가 적은 사용자 그룹에 대해 편향적이 될 수 있습니다.
레이블링
- 인간 어노테이터가 데이터를 레이블링한다면 레이블 품질을 어떻게 측정할까요?
- 어노테이터가 레이블링할 때 주관적인 경험이 아닌 표준 지침을 따르도록 하려면 어떻게 해야 할까요?
- 어노테이터가 주관적인 경험에 의존할수록 인간의 편향이 개입할 여지가 커집니다.
피처 엔지니어링
- 모델이 민감한 정보가 포함된 피처를 사용하나요?
- 모델이 일부 집단의 사람들에게 이질적인 영향을 끼치나요?
- 논문 'Certifying and removing disparate impact'에 따르면 이질적인 영향은 선택 프로세스가 중립적인 것처럼 보인다 할지라도 서로 다른 그룹 간에 매우 다른 결과가 발생한 경우라면 발생한 경우입니다.
- 모델의 결정이 민족, 성별, 종교 등 법적으로 보호되는 계층과 상관관계가 있는 정보에 의존할 때, 심지어 이 정보가 모델을 직접 훈련하는 데 사용되지 않더라도 발생합니다. 예를 들어, 채용 과정에서 우편 번호나 고등학교 졸업장처럼 인종과 상관관계가 있는 변수를 활용하면 인종별로 이질적인 영향을 미치게 됩니다.
- 잠재하는 이질적인 영향을 완화할 방법으로는 펠드만 등이 제안한 기법이나 AIF360에서 구현한 DisparateImpactRemover 함수가 있습니다. H20에서 구현한 Infogram 메서드를 사용해 변수에 숨은 편향을 식별할 수도 있습니다.
모델의 목표
- 모든 사용자에게 공평하게 적용될 수 있는 목표로 모델을 최적화하고 있나요?
- 예를 들어, 모델 성능을 우선시해서 대다수 사용자 그룹에 대해 모델을 왜곡하고 있지는 않나요?
평가
- 다양한 사용자 그룹에 대한 모델의 성능을 이해하기 위해 적절하고 세분화된 평가를 수행하고 있나요?
- 공정하고 적절한 평가는 공정하고 적절한 평가 데이터가 존재하는지에 달려 있습니다.
3.2.2 데이터 기반 접근법의 한계 이해하기
ML은 데이터를 기반으로 문제를 해결하기 위한 접근법입니다. 하지만 데이터로는 충분하지 않습니다. 데이터는 실제 사람들에 관한 것이며 고려해야 할 사회경제적, 문화적 측면이 있습니다. 따라서 데이터에 과도하게 의존함으로써 생기는 맹점을 더 잘 이해해야 합니다. 구축하는 ML 시스템에 영향받을 사람들의 실제 경험을 녹여낼 수 있도록 현업의 도메인 전문가와 논의해 도메인 지식(규율, 기능 등)을 파악해야 합니다.
예를 들어, 공정한 자동 채점 시스템을 구축하려면 반드시 도메일 전문가와 협력해 학생들의 인구통계학적 분포와 사회경제적 요인이 과거 성적 데이터에 어떻게 반영되는지 이해해야 합니다.
3.2.3 서로 다른 요구 사항 간의 트레이드오프 이해하기
ML 시스템을 구축할 때 시스템이 특정 속성을 갖추길 원할 겁니다. 예컨대 낮은 추론 레이턴시를 원한다면 가지치기 같은 모델 압축 기술로 달성할 수 있습니다. 높은 예측 정확도를 원한다면 더 많은 데이터를 추가함으로써 달성할 수 있습니다. 모델이 공정하고 투명하기를 원한다면, 공개 조사를 위해 모델과 해당 모델을 개발하는 데 사용한 데이터에 엑세스 가능하도록 해야할 수도 있습니다.
종종 ML 문헌은 한 속성에 대한 최적화가 나머지 속성을 정적으로 유지한다는 비현실적인 가정을 하기도 합니다. 사람들은 특정 모델의 정확도나 레이턴시가 그대로 유지된다는 가정하에 모델의 공정성을 개선하기 위한 기술을 논의합니다. 하지만 실제로는 한 속성을 개선하면 다른 속성이 저하될 가능성 역시 존재합니다. 다음은 트레이드오프의 두 가지 예입니다.
개인 정보 보호와 정확도 간의 트레이드오프
차등 개인 정보 보호는 데이터셋 내 개인에 대한 정보는 숨기면서 그룹들의 패턴을 설명함으로써 데이터셋에 대한 정보를 공개적으로 공유하는 시스템입니다. 이러한 개념은 데이터베이스에서 임의의 단일 대체의 효과가 충분히 작다면, 쿼리 결과로 개인에 대해 많은 것을 추론할 수 없다는 점에서 개인 정보를 보호하게 됩니다.
차등 개인 정보 보호는 ML 모델의 훈련 데이터에 흔히 사용되는 기술입니다. 이에 트레이드오프는 자동 개인 정보 보호가 제공하는 개인 정보 보호 수준이 높을수록 모델 정확도가 낮아진다는 점입니다. 다만 정확도 감소는 모든 샘플에서 동일하지는 않습니다. 2019년 논문 'Differential Privacy Has Disparate Impact on Model Accuracy'에서는 "차등 개인 정보 보호 모델의 정확도는 과소 대표된 클래스와 하위 그룹에서 훨씬 크게 감소합니다."라고 말했습니다.
간결함과 공정성 간의 트레이드오프
가지치기, 양자화 등 모델 압출 기술은 정확도 손실을 최소화하면 모델 크기를 크게 줄일 수 있습니다. 예를 들어, 정확도 손실을 최소한으로 억제하면서도 모델 매개변수 개수를 90% 줄일 수도 있습니다. 이렇게 최소한도로 억제된 손실이 모든 클래스에 균일하게 분산돼 있으면, 말 그대로 최소한도일 것입니다.
그렇다면 소수의 클래스에만 정확도 손실이 집중되면 어떨까요? 2019년 논문 'What Do Compressed Deep Neural Networks Forget?' 에서는 "서로 다른 개수의 가중치를 가진 모델이 비슷한 최상위 성능 지표를 갖지만, 데이터셋의 샘플 데이터 집합에서는 추론 결과가 매우 다르다"는 것을 발견했습니다. 예를 들어, 성별, 인종, 장애 등 보호된 피처가 데이터 분포의 롱테일 클래스일 때, 즉 저빈도 클래스 일 때 압축 기술이 정확도 손실을 증폭시킵니다. 이는 압축이 제대로 표현되지 않은 피처에 불균형적으로 영향을 미침을 의미합니다.
연구에서 얻은 또 다른 중요한 발견은 그들이 평가한 압축 기법이 모두 불균일한 영향을 미치지만, 모든 기법이 동일한 수준으로 영향을 미치지는 않는다는 점입니다. 예를 들어, 가지치기는 양자화 기법보다 훨씬 더 이질적인 영향을 미칩니다.
유사한 트레이드 오프가 계속 발견되고 있습니다. ML 시스템을 설계할 때 정보에 입각한 결정을 내리려면 이러한 트레이드오프를 인식하는 것이 중요합니다. 압축되거나 차등적으로 비공개인 시스템으로 작업하는 경우 의도치 않은 피해를 방지하려면 모델 동작을 감사하는 데 더 많은 자원을 할당하는 편이 좋습니다.
3.2.4 사전 대응하기
시내에 건물을 새로 짓는 상황을 가정해봅시다. 한 건설업자가 향후 75년 동안 사용할 건물을 짓게 됐습니다. 건설업자는 비용을 줄이려고 저품질시멘트를 사용하고, 건축주는 건축 기간을 줄이려고 감독에 투자하지 않습니다. 건설업자는 열악한 기초 위에 작업을 이어가고 제시간에 건물을 완공합니다.
그런데 1년이 채 안 돼서 균열이 생기기 시작했고 건물은 무너질 것 같습니다. 시에서는 이 건물이 안전상 위험이 있다고 판단하고 철거를 요청합니다. 이처럼 비용을 절약하려던 건설업자와 시간을 절약하려던 건축주가 내린 결정이 결국 훨씬 더 많은 돈과 시간을 소요하는 결과를 낳은 것 입니다.
ML 시스템에서도 이 이야기를 자주 접할 수 있습니다. 회사가 비용과 시간을 절약하려고 ML 모델의 윤리적 문제를 우회하기로 결정한다면 나중에는 결국 비용이 훨씬 높은 위험을 발견할 뿐 입니다. 앞서 살펴본 오프퀄과 스트라바의 사례 연구처럼 말입니다.
ML 시스템 개발 주기가 빨라질수록 ML 시스템이 사용자의 삶에 어떤 영향을 미치는지, 어떤 편향을 가지는지 생각해야 합니다. 이러한 편향은 미리 해결하는 편이 비용이 낮습니다. NASA의 연구에 따르면 소프트웨어 개발에서는 프로젝트 수명 주기의 단계가 넘어갈수록 오류 비용이 몇 배씩 증가합니다.
3.2.5 모델 카드 생성하기
모델 카드는 훈련된 ML 모델과 함께 제공되는 짧은 문서로, 모델이 어떻게 훈련되고 평가됐는지에 대한 정보를 제공합니다. 논문 'Model Cards for Model Reporting'에 따르면 모델 카드는 모델이 사용되는 컨텍스트와 제한 사항 또한 공개하며 "모델 카드의 목표는 이해관계자가 배포를 위한 후보 모델을 비교할 때 전통적인 평가 지표뿐 아니라 윤리적, 포괄적, 공정한 고려사항의 축을 따르도록 함으로써 윤리적 관행과 보고를 표준화하는 것"입니다.
다음은 모델에 대해 보고할 수 있는 정보들입니다.
1. 모델 세부 정보 : 모델에 대한 기본정보입니다.
- 모델을 개발하는 개인 혹은 조직
- 모델 날짜
- 모델 버전
- 모델 유형
- 훈련 알고리즘, 매개변수, 공정성 제약 및 그 외에 적용된 접근법과 피처에 대한 정보
- 추가 정보를 위한 논문과 기타 자료
- 인용 세부 정보
- 특허
- 모델에 대한 질문이나 의견을 보낼 곳
2. 사용 목적 : 개발 중에 구상한 유스 케이스입니다.
- 주요 용도
- 주요 사용자
- 범위 외 유스 케이스
3. 요인 : 요인에는 인구통계학적 또는 표현형 그룹, 환경 조건, 기술적 속성 등이 포함됩니다.
- 관련 요인
- 평가 요인
4. 지표 : 모델의 잠재 영향을 반영하는 지표를 선택해야 합니다.
- 모델 성능
- 결정 임곗값
- 변형 접근법
5. 평가 데이터 : 카드의 정량 분석에 사용한 데이터셋에 대한 세부 정보입니다.
- 데이터셋
- 동기
- 전처리
6. 훈련 데이터 : 실제로는 훈련 데이터를 제공하지 못할 수 있기에 가능하면 이 섹션은 평가 데이터를 반영해야 합니다. 이러한 세부 정보가 가능하지 않다면, 훈련 데이터셋의 다양한 요인에 대한 분포 세부 정보 등 최소한의 정보를 모델 카드에 제공해야 합니다.
7. 정량적 분석
- 단일 결과
- 교차 결과
8. 윤리적 고려 사항
9. 주의 사항과 권장 사항
모델 카드는 ML 모델 개발의 투명성을 높여줍니다. 모델 사용자가 해당 모델을 개발한 사람이 아닌 경우엔 더욱 중요합니다.
모델이 업데이트될 때마다 모델 카드를 업데이트해야 합니다. 자주 업데이트되는 모델의 경우 모델 카드를 수동으로 생성하면 데이터 과학자에게 상당한 오버헤드가 발생합니다. 따라서 모델 카드를 자동으로 생성하는 도구를 보유하는 것이 중요합니다. 텐서플로, 메타플로, 사이킷런 같은 도구의 모델 카드 생성 기능을 활용하거나 사내에서 기능을 구축하는 방법이 존재합니다. 모델 카드에서 추적해야 하는 정보는 모델 스토어에서 추적해야 하는 정보와 겹치므로, 가까운 미래에 모델 스토어가 모델 카드를 자동으로 생성하게 될 수도 있을 것 입니다.
3.2.6 완화를 위한 프로세스 수립하기
책임 있는 AI를 구축하는 프로세스는 복잡하며, 프로세스가 임시방편적일수록 오류가 발생할 여지가 더 많습니다. 기업은 책임 있는 ML 시스템을 만들기 위해 체계적인 프로세스를 수립해야 합니다.
다양한 이해관계자가 접근하기 쉬운 내부 도구 포트폴리오를 만들면 좋습니다. 대기업에서 보유한 도구 세트를 참조하면 도움이 될 것입니다. 예를 들어, 구글에서 게시한 책임 있는 AI에 대한 권장 모범 사례와 IBM이 보유한 오픈 소스 AIF360이 있습니다. 그 외에 서드 파티 감사를 고려할 수도 있습니다.
3.2.7 책임 있는 AI에 관한 최신 정보 파악하기
AI는 빠르게 움직이는 분야입니다. 계속해서 새로운 편향이 발견되고 있으며 책임 있는 AI에 관한 난제도 끊임없이 새로 등장합니다. 이러한 편향과 난제에 맞서기 위한 기술 또한 활발히 개발되고 있습니다. 책임 있는 AI에 대한 최신 연구 동향을 파악하는 것이 중요합니다. ACM FaccT 콘퍼런스, 파트너십 온 AI, 앨런 튜링 연구소와 Fairness, Transparency, Privacy 그룹, AI 나우 그룹을 참조하는 것이 좋습니다.
'IT > 머신러닝 시스템 설계' 카테고리의 다른 글
| [머신러닝 시스템 설계] Ch.9 연속 학습과 프로덕션 테스트 (0) | 2023.09.20 |
|---|---|
| [머신러닝 시스템 설계] Ch.6 모델 개발과 오프라인 평가 (0) | 2023.08.04 |
| [머신러닝 시스템 설계] Ch.3 머신러닝 엔지니어링 기초 (0) | 2023.07.16 |
