학습 데이터

프로그램에 판단을 시키는 방법은 원래 규칙을 적어 주는 것이었습니다. 스팸 계정을 골라내려면 "하루에 문서를 100건 넘게 만들고 바깥 링크가 80퍼센트를 넘으면 스팸" 같은 조건을 사람이 적었습니다. 조건을 적은 사람이 왜 그렇게 정했는지 설명할 수 있다는 것이 장점이었습니다.

문제는 조건이 늘어나는 속도였습니다. 예외가 나올 때마다 조건이 하나씩 붙습니다. 문서를 많이 만들지만 정상인 팀이 있고, 링크가 많지만 정상인 팀도 있습니다. 반년 지나면 조건이 마흔 개가 되는데 그중 어느 것이 쓸모 있는지는 아무도 모르고, 하나를 지우면 무엇이 깨지는지 알 수 없어 아무도 지우지 못합니다. 스팸 쪽이 수법을 바꾸면 마흔 개를 다시 손봐야 합니다.

학습 데이터는 그 순서를 뒤집습니다. 조건을 적는 대신 이미 답이 붙은 사례를 모아서 보여 줍니다. 스팸으로 판정된 계정 2,000개와 정상 계정 46,000개를 넣으면 프로그램이 둘을 가르는 경계를 스스로 찾습니다. 사람이 하는 일이 규칙을 쓰는 일에서 사례를 모으고 답을 붙이는 일로 옮겨 간 것입니다. 그래서 모델의 품질을 묻는 질문은 대개 알고리즘 질문이 아니라 데이터 질문이 됩니다.

한 줄이 어떻게 생겼는지부터 봅니다. 입력 값 묶음과 그 줄의 정답이 한 쌍으로 붙어 있습니다. 계정 하나라면 가입 후 경과일, 하루 평균 문서 수, 초대한 사람 수, 바깥 링크 비율이 입력이고 스팸인지 아닌지가 정답입니다. 정답을 붙인 데이터로 가르치는 방식에는 지도 학습이라는 이름이 붙어 있습니다.

모은 데이터는 세 덩어리로 나눠 씁니다.

1. 학습 세트 — 전체의 70퍼센트쯤입니다. 모델이 경계를 찾는 데 실제로 쓰는 몫입니다.
2. 검증 세트 — 15퍼센트쯤입니다. 설정을 바꿔 가며 어느 쪽이 나은지 견주는 데 씁니다. 여러 번 봅니다.
3. 시험 세트 — 나머지 15퍼센트입니다. 마지막에 한 번만 봅니다. 중간에 들여다보면 그 결과에 맞춰 손대게 되고, 그러면 새 데이터에서의 성적을 가늠하는 기능을 잃습니다.

나누는 이유는 과적합을 잡아내기 위해서입니다. 과적합은 학습에 쓴 데이터에만 지나치게 맞춰진 상태로, 기출문제 답만 외운 것과 같습니다. 학습 세트에서 98점인데 시험 세트에서 71점이면 이쪽을 먼저 의심합니다.

정답을 붙이는 일은 사람이 하고, 갈리는 것은 기준입니다. 같은 계정을 두고 한 명은 스팸, 두 명은 정상이라고 답하면 그 데이터로 배운 모델도 흔들립니다. 그래서 판정 기준을 문서로 적고 같은 계정 200개를 두 사람에게 겹쳐 붙여 봅니다. 불일치가 10퍼센트를 넘으면 기준을 다시 씁니다.

양보다 먼저 볼 것은 대표성입니다. 실제로 들어올 데이터와 같은 모양이어야 합니다. 기업 계정만 5만 개 모아 학습시킨 모델은 개인 계정에서 엉뚱한 답을 냅니다.

세 자리에서 실제로 다뤄집니다. 첫째는 모델을 직접 만들 때입니다. 분류 과제가 가장 흔합니다. 분류는 어느 범주에 속하는지 맞히는 일로, 들어온 문의가 환불 건인지 버그 건인지 가르는 식입니다. 이 경우 지난 문의 3만 건에 유형을 붙인 것이 학습 데이터가 됩니다.

둘째는 남이 만든 모델을 우리 용도에 맞출 때입니다. 파인튜닝은 이미 학습된 모델에 우리 데이터를 더 먹여 특정 용도에 맞추는 일입니다. 필요한 양이 훨씬 적습니다. 처음부터 만들면 수만 건이 필요하지만 파인튜닝은 잘 고른 수백에서 수천 건으로 됩니다. 대신 고르는 기준이 까다롭습니다. 답의 형식이 들쭉날쭉하면 모델이 형식까지 따라 배웁니다.

셋째는 갱신입니다. 한 번 만든 데이터로 계속 갈 수 없습니다. 제품에 새 기능이 붙어 정상 사용 패턴 자체가 달라지면 예전 데이터로 배운 모델이 무뎌집니다. 그래서 분기마다 최근 사례를 얹고 오래된 것을 덜어 냅니다.

"모델을 바꾸기 전에 학습 데이터부터 보죠. 스팸 사례가 2,000건뿐입니다."

성능 문제를 데이터 쪽에서 먼저 의심하는 말입니다.

"라벨 기준 문서 없이 붙이면 두 사람 판정이 갈립니다. 먼저 기준을 씁시다."

정답의 일관성을 확보하려는 요구입니다.

"시험 세트는 마지막까지 열지 마세요. 지금 보면 그 숫자에 맞춰 손대게 됩니다."

평가용 데이터를 오염시키지 않으려는 주의입니다.

페이지덱에서는 태오가 스팸 계정을 걸러내는 모델을 돌리고 있습니다. 학습 데이터는 지난 2년간 정지된 계정 2,100개와 무작위로 뽑은 정상 계정 20,000개입니다. 정지 사유를 다섯 가지로 나눠 적어 두었고, 그중 결제 실패로 정지된 건은 학습에서 뺐습니다. 스팸과 성격이 다른 정지라서 섞으면 경계가 흐려집니다.

지현은 라벨 기준 문서를 관리합니다. 분기마다 새로 정지된 계정 100개를 태오와 각자 판정해 답이 갈린 건을 셉니다. 지난 분기에는 12건이 갈렸고 그중 여덟 건이 외부 협력사와 문서를 많이 주고받는 팀이었습니다. 기준 문서에 그 경우를 정상으로 본다는 문장을 넣었습니다.

많으면 좋다고 보는 경우가 가장 많습니다. 사례가 늘면 배울 것도 늘 것처럼 계산됩니다. 다만 늘어나는 것이 같은 종류뿐이면 성적이 오르지 않습니다. 스팸 사례를 2,000건에서 4,000건으로 늘렸는데 새 2,000건이 모두 같은 수법이면 모델은 그 수법만 더 잘 잡습니다. 여기에 라벨이 부정확한 데이터를 섞으면 성적이 오히려 내려갑니다. 양을 늘리기 전에 볼 것은 지금 틀리는 사례가 어떤 종류인지이고, 그 종류를 골라 채우는 쪽이 전체를 두 배로 늘리는 쪽보다 빠릅니다.

우리 서버에 있는 기록은 전부 학습에 쓸 수 있다고 보는 것도 흔합니다. 우리가 운영하는 제품의 데이터라서 그렇게 느껴집니다. 하지만 고객이 올린 문서는 고객의 것이고, 무엇에 쓸 수 있는지는 이용약관에 적힌 범위가 정합니다. 학습에 쓰겠다는 내용이 없는 상태로 고객 문서를 모델에 넣으면 나중에 계약 위반 주장을 받습니다. 여기에 걸리는 쟁점을 학습 데이터 권리라고 부릅니다. 기업 고객과의 계약에서는 자기 회사 데이터를 학습에 쓰지 말라는 조항을 요구하는 경우가 흔하고, 그 조항이 들어가면 그 고객사 데이터는 따로 빼서 관리해야 합니다.