콘텐츠 조정: 정책을 판정 가능한 것으로 만들기

지난 글에서 탈옥 방어를 고리로 다뤘다. 그 고리가 묻는 질문은 "이 사용자가 정책을 우회하려 하는가"였다. 콘텐츠 조정이 묻는 질문은 다르다. "이 내용이 우리 서비스에서 허용되는가." 의도를 묻지 않고 내용을 묻는다.

둘을 섞어 놓은 시스템을 자주 본다. 섞으면 둘 다 나빠진다. 탈옥 방어는 시도의 패턴을 보고 조정은 결과물의 성격을 보는데, 판정 근거가 다르니 임계값도 조치도 지표도 따로 잡아야 한다. 섞어 두면 탈옥 시도가 늘어난 날에 조정 차단율이 함께 튀고, 그 튐이 어느 쪽에서 왔는지 알 수 없다. 이 글은 조정 쪽만 본다.

그리고 조정은 기능이 아니라 살림이다. 한 번 붙여 두고 잊는 모듈이 아니라 라벨 정의, 임계값, 검토 큐, 지표가 서로 물려 돌아가는 살림이라 어느 하나만 손보면 나머지 셋이 조용히 어긋난다. 아래 일곱 절이 그 넷과 그것을 흔드는 것들이다.

라벨 정의

조정 시스템을 만들 때 첫 작업은 분류기를 고르는 것도 임계값을 정하는 것도 아니다. 정책을 판정 가능한 라벨로 쪼개는 것이다. 여기서 판정 가능하다는 말에는 뜻이 하나뿐이다. 훈련받은 두 사람이 같은 입력에 같은 라벨을 붙이는가.

판정 불가능한 문장

거의 모든 팀이 정책 문서를 먼저 만든다. "폭력적이거나 혐오를 조장하는 콘텐츠를 허용하지 않습니다" 같은 문장들이다. 그리고 그 문서를 그대로 분류 프롬프트에 붙여 넣고 판정을 시킨다. 여기서 무너진다.

이유는 단순하다. 저 문장은 사람이 읽고 동의하라고 쓴 문장이지 무언가를 가르라고 쓴 문장이 아니다. 같은 요청 100건을 두 사람에게 저 기준으로 판정시키면 결과가 20~30% 어긋난다. 사람끼리도 안 맞는 기준을 모델에 주면 모델도 안 맞는다. 그리고 안 맞는 것을 알아채지도 못한다 — 비교할 정답이 없기 때문이다.

정책 문서가 쓸모없다는 말이 아니다. 정책 문서는 약속이고 판정 기준은 도구다. 약속은 "우리는 이런 서비스입니다"를 사용자와 규제 기관에 밝히는 문서라 넓고 원칙적이어야 하고, 도구는 하루 수만 건을 같은 방식으로 갈라야 하니 좁고 기계적이어야 한다. 한 문서가 두 일을 겸하면 넓은 쪽에 맞춰지고, 그러면 판정이 사람마다 갈린다. 두 문서를 따로 두고 판정 기준이 정책의 어느 조항에서 나왔는지만 연결해 둔다.

라벨의 네 칸

라벨 하나는 이 네 가지를 갖춰야 쓸 수 있다.

• 이름 — violence_instructions처럼 코드에서 부를 수 있는 것
• 포함 기준 — 무엇이 이 라벨인지, 예시 서넛과 함께
• 제외 기준 — 무엇이 이 라벨이 아닌지. 이쪽이 더 중요하다
• 인접 라벨과의 경계 — 헷갈리는 다른 라벨과 어디서 갈리는지

네 번째가 빠지면 라벨이 서로를 잡아먹는다. violence_instructions와 weapons_acquisition을 나란히 두고 경계를 안 적어 두면, 검토자 A는 총기 제작 요청을 앞쪽에 넣고 B는 뒤쪽에 넣는다. 둘 다 차단이니 사용자가 보는 결과는 같지만, 지표에서는 두 라벨의 재현율이 함께 낮게 나오고 어느 쪽 정의를 고쳐야 하는지 알 수 없게 된다. 경계 문장은 한 줄이면 된다 — "만드는 방법을 묻는 것이 아니라 구하는 경로를 묻는 것이면 weapons_acquisition이다" 정도다.

라벨 개수도 정할 것이 아니라 견딜 것이다. 처음부터 서른 개를 만들면 각 라벨의 예시가 두세 건뿐이라 정의가 얇아지고, 검토자가 서른 개를 외우지 못해 실제로는 대여섯 개만 쓴다. 여섯에서 열 개로 시작해 실제 트래픽에서 한 라벨이 자꾸 두 갈래로 쓰인다는 신호가 나올 때 쪼개는 편이 낫다.

제외 기준

제외 기준이 빠진 라벨이 가장 흔한 실수다. "폭력"이라는 라벨에 포함 예시만 적어 두면 뉴스 요약, 역사 서술, 자기 방어 상담, 게임 설명이 전부 걸린다. 실제로 걸러야 하는 것은 그중 일부인데, 그 일부를 문장으로 못 적으면 분류기도 못 가른다.

경로를 한 번 따라가 보면 왜 이것이 사고로 이어지는지가 보인다. 포함 예시만 있는 "폭력" 라벨을 붙이면 분류기는 폭력 어휘가 나오는 문장 전부에 높은 점수를 준다. 뉴스 요약 기능에서 사건 기사를 넣은 사용자가 막히고, 역사 과제를 하던 학생이 막히고, 가정폭력 상담을 하려던 사용자가 막힌다. 마지막 건이 가장 나쁘다 — 조정이 보호하려던 바로 그 사람이 조정에 막힌다. 팀은 이것을 "모델이 과하게 민감하다"고 읽고 임계값을 올리는데, 임계값을 올리면 이번에는 실제 위반이 새어 나간다. 원인은 임계값이 아니라 제외 기준이 없는 라벨이었다.

제외 기준을 적는 요령은 하나다. 막고 싶지 않은 것부터 적는다. 폭력 라벨이라면 "사실을 서술하는 것", "이미 일어난 일을 요약하는 것", "피해자가 자기 상황을 설명하는 것", "허구 서사 안에서 묘사하는 것"을 먼저 적고 남는 것을 포함으로 잡는다. 이 순서로 적으면 포함 기준이 저절로 좁아진다.

자체 제작과 외부 도입

전부 직접 만들 필요는 없다. 다만 사 올 것과 만들 것의 선이 어디인지는 처음에 그어 둬야 한다.

• 범용 위반 분류 — 사 오는 편이 낫다. 공개된 조정 모델과 상용 API가 이미 충분히 좋고, 우리가 직접 학습 데이터를 모으는 비용이 훨씬 크다
• 서비스 고유 정책 — 직접 만들어야 한다. "우리 서비스에서는 경쟁사 제품 추천을 하지 않는다" 같은 것을 아는 외부 모델은 없다
• 라벨 정의와 평가 세트 — 무조건 직접이다. 이건 도구가 아니라 우리 서비스가 무엇을 허용하는지에 대한 답이라 외부에서 살 수 있는 물건이 아니다

세 번째를 안 만들고 첫 번째만 붙인 시스템이 많다. 그러면 외부 분류기가 우리 대신 정책을 정하고 있는 상태가 되고, 그 분류기가 버전을 올릴 때마다 우리 서비스의 허용 범위가 조용히 바뀐다. 조용히라는 말이 핵심이다 — 공급자가 라벨 하나의 민감도를 조정하면 우리 쪽 차단율이 며칠 뒤부터 달라지는데, 우리 코드는 하나도 안 바뀌었으니 배포 이력에서 원인을 찾을 수 없다. 라벨 정의와 평가 세트를 우리가 들고 있으면 이 변화가 지표에서 먼저 잡힌다. 같은 평가 세트를 매주 돌려 점수가 움직이면 그것이 곧 외부 분류기가 바뀌었다는 신호다.

라벨 일치도

라벨 정의가 쓸 만한지는 의견으로 정하지 않고 숫자로 잰다. 실제 트래픽에서 표본을 뽑아 두 사람에게 독립적으로 라벨을 붙이게 하고 얼마나 겹치는지 센다. 이것을 라벨 일치도라고 한다.

$\text{일치도} = \frac{\text{두 사람이 같은 라벨을 준 건수}}{\text{전체 건수}}$

층화 표본

표본을 무작위로 뽑으면 안 된다. 위반이 1%인 트래픽에서 200건을 무작위로 뽑으면 위반은 평균 두 건이다. 두 사람이 그 두 건에서 완전히 어긋나도 전체 일치도는 99%로 나온다. 라벨 정의의 품질을 재려고 만든 숫자가 트래픽 구성만 되비추는 셈이다.

그래서 층화 표본을 쓴다. 층화 표본은 모집단을 몇 개 층으로 나눈 뒤 층마다 정해진 수를 뽑아 합치는 방법이다. 여기서 층은 분류기 점수다. 낮은 점수 구간에서 60건, 회색 지대에서 80건, 높은 점수 구간에서 60건을 뽑으면 어려운 건이 표본의 절반 가까이 들어온다. 정의가 무너지는 자리는 언제나 회색 지대이니 거기를 두껍게 뽑는 것이 맞다.

대신 이렇게 뽑은 표본에서 나온 일치도는 트래픽 전체의 일치도가 아니다. 어려운 건을 일부러 몰아 뽑았으니 실제보다 낮게 나온다. 이 숫자는 정의를 고칠지 말지를 정하는 데만 쓰고, 서비스 품질을 보고할 때는 쓰지 않는다. 두 숫자를 같은 표에 나란히 두면 반드시 섞인다.

코헨의 카파

일치도를 그대로 쓰면 우연이 섞인다. 코헨의 카파는 두 사람이 아무렇게나 답해도 우연히 맞을 몫을 빼고 남은 일치를 재는 값이다. 우연히 같은 답을 낼 확률을 $p_e$, 실제 일치율을 $p_o$라 할 때

$\kappa = \frac{p_o - p_e}{1 - p_e}$

이다. 라벨 하나에서 한 번 계산해 보자. 200건을 두 사람이 봤고, A는 30건을 위반으로, B는 26건을 위반으로 판정했으며, 둘 다 위반이라 한 것이 22건, 둘 다 정상이라 한 것이 166건이다. 실제 일치율은 $p_o = (22 + 166) / 200 = 0.94$다. 우연 일치는 두 사람이 각각 위반을 고를 확률을 곱하고 정상끼리도 곱해 더한다 — $p_e = 0.15 \times 0.13 + 0.85 \times 0.87 = 0.759$다. 넣으면

$\kappa = \frac{0.94 - 0.759}{1 - 0.759} \approx 0.75$

가 나온다. 일치율만 보면 94%라 훌륭해 보이는데 카파는 0.75다. 위반이 드물어 "둘 다 정상"이 저절로 쌓인 몫을 걷어냈기 때문이다. 드문 라벨일수록 일치율과 카파의 거리가 벌어진다. 그래서 조정에서는 일치율만 보고하면 안 된다.

문턱에는 조치를 붙여 둔다. $\kappa < 0.6$이면 라벨 정의를 고치기 전에는 그 라벨로 아무것도 자동 판정하지 않는다. $0.6 \le \kappa < 0.8$이면 자동 통과는 시키되 자동 차단은 안 시키고 회색 지대를 넓게 잡는다. $\kappa \ge 0.8$이면 자동 차단까지 붙인다. 문턱을 정해 두는 이유는 숫자를 보고 그때그때 판단하면 늘 "이 정도면 됐다"로 흐르기 때문이다.

이 측정을 건너뛰면 나중에 분류기 정확도가 낮게 나올 때 원인을 못 찾는다. 모델이 못하는 것인지 기준이 애매한 것인지 구별할 방법이 없기 때문이다. 사람도 못 맞히는 라벨에서 분류기 정확도 75%가 나왔다면 그건 모델 문제가 아니다.

정의 수정 주기

카파가 낮게 나왔을 때 할 일은 정해져 있다. 어긋난 건만 모아 두 사람이 함께 읽고, 왜 갈렸는지를 한 문장으로 적고, 그 문장을 제외 기준이나 경계 문장으로 정의에 넣는다. 그리고 새 표본으로 다시 잰다. 같은 표본으로 다시 재면 두 사람이 이미 그 건들을 함께 읽었으니 점수가 저절로 오른다 — 정의가 좋아진 것이 아니라 그 200건에 대한 기억이 맞춰진 것이다.

한 바퀴로 끝나지도 않는다. 어긋난 건을 읽다 보면 대개 정의의 한 자리가 아니라 세 자리가 흔들리고 있고, 한 자리를 고치면 다음 표본에서 다른 자리가 드러난다. 카파가 문턱을 넘을 때까지 두세 바퀴는 돈다고 잡아 두는 편이 낫다. 이 시간을 아끼려고 정의를 대충 두고 넘어가면 그 비용이 검토 큐로 옮겨 간다. 정의가 흐린 라벨은 회색 지대가 넓고, 회색 지대가 넓으면 사람이 볼 것이 많아진다.

정의 버전

라벨 정의에 버전을 붙이지 않으면 지금까지 잰 점수가 전부 비교 불가능해진다. 카파 0.71과 0.83이 두 정의에서 나온 값이면 그것은 개선이 아니라 그냥 다른 두 숫자다.

그래서 판정 기록에는 라벨 이름만이 아니라 정의 버전과 분류기 버전을 함께 남긴다. 나중에 "지난달에 왜 이 요청이 막혔나"라는 질문이 들어올 때 답할 수 있는 것은 이 두 값뿐이다. 지금 정의로 그 요청을 다시 판정해 봐야 그때 무슨 일이 있었는지는 알 수 없다. 조정은 사용자에게 불이익을 주는 시스템이라 되짚을 수 있어야 하고, 되짚기의 최소 단위가 버전이다.

이중 임계값

라벨이 정해지면 분류기가 라벨별로 점수를 낸다. 여기서 자주 하는 실수가 임계값을 하나만 두는 것이다. 0.5를 넘으면 차단, 아니면 통과 식이다.

단일 선의 절단면

문제는 조정에서 정말 어려운 건이 전부 0.4~0.7 구간에 몰려 있다는 점이다. 선을 하나만 그으면 그 애매한 것들이 통째로 한쪽에 붙는다. 0.5로 자르면 0.49짜리와 0.51짜리가 완전히 다른 대접을 받는데, 실제로 두 건의 차이는 거의 없다.

점수가 확률이 아니라는 점도 여기서 걸린다. 분류기가 내는 0.51은 "51% 확률로 위반"이라는 뜻이 아니라 그냥 순서를 매기는 값이다. 순서만 믿을 수 있고 크기는 믿을 수 없는 값에 선을 하나 그으면, 그 선의 위치가 모델을 바꿀 때마다 의미를 잃는다. 임계값을 둘로 두는 것은 그 불확실성을 시스템 안에 자리로 만들어 두는 일이다.

임계값을 둘로 두면 세 갈래가 된다.

• 낮은 값 아래 — 통과. 판정 기록만 남긴다
• 두 값 사이 — 사람 검토. 응답을 보류하거나 범위를 줄여서 내보낸다
• 높은 값 위 — 차단. 사유 코드를 함께 남긴다

띠 폭 역산

가운데 띠의 폭이 곧 사람 검토 비용이다. 좁히면 오판이 늘고 넓히면 큐가 커진다. 이 폭은 정책이 정하는 값이 아니라 검토 인력이 하루에 처리할 수 있는 건수가 정하는 값이다.

계산은 뒤에서부터 한다. 하루 요청이 20만 건이고 검토자가 여섯 명, 한 사람이 하루 250건을 본다고 하자. 처리량은 1,500건이고 이는 전체의 0.75%다. 그러니 가운데 띠에 들어오는 건이 하루 1,500건을 넘으면 안 된다. 이제 점수 분포를 열어 본다. 0.4~0.7 구간에 트래픽의 3%가 들어 있다면 그 띠는 하루 6,000건이고, 검토자는 나흘치를 하루에 받는다. 사흘이면 큐가 만 팔천 건이다.

여기서 고를 수 있는 것은 셋뿐이다. 띠를 0.55~0.75처럼 좁혀 0.7%로 만들거나, 라벨을 골라 위험이 큰 것에만 띠를 적용하고 나머지는 선 하나로 자르거나, 검토자를 늘리거나. 어느 쪽도 공짜가 아니라는 것이 요점이다. 띠를 좁히면 오판이 늘고, 라벨을 고르면 고르지 않은 라벨의 회색 지대가 그냥 통과되며, 사람을 늘리면 비용이 는다. 이 셋 중 하나를 고르는 일을 미뤄 두면 시스템은 저절로 세 번째를 뺀 나머지 중 나쁜 쪽으로 굴러간다.

라벨별 띠 동작

가운데 띠에서 무엇을 할지는 라벨마다 다르게 정한다. 위험이 큰 라벨은 검토 결과가 나올 때까지 응답을 보류하고, 위험이 작은 라벨은 일단 내보내고 사후에 검토한다. 전부 보류로 두면 지연이 사용자에게 곧바로 보인다.

보류와 사후 검토 사이에 하나가 더 있다. 범위를 줄여 내보내기다. 요청을 통째로 막지 않고 위험한 부분만 빼고 답하거나, 일반적인 안내까지만 하고 구체적인 절차는 생략하는 것이다. 회색 지대의 절반쯤은 이 처리로 사용자 쪽 체감이 크게 나아진다 — 아무 답도 못 받는 것과 절반의 답을 받는 것은 다르다. 라벨 정의에 "회색일 때 무엇을 빼는가"를 한 줄 적어 두면 이 처리를 자동으로 붙일 수 있다.

과부하 시 이동 방향

큐가 감당 못 할 만큼 쌓이면 선택지는 둘이다. 회색 지대를 통과 쪽으로 흘려보내거나 차단 쪽으로 붙이거나. 어느 쪽으로 흘릴지를 라벨마다 미리 정해 두어야 한다. 안 정해 두면 그 결정을 사고가 난 새벽에 하게 된다.

정하는 기준은 되돌릴 수 있는가 하나다. 놓쳤을 때 피해가 되돌아오지 않는 라벨은 차단 쪽으로 붙이고, 잘못 막았을 때 사용자가 다시 시도하면 되는 라벨은 통과 쪽으로 흘린다. 이 규칙을 코드로 심어 두고 큐 길이가 상한을 넘으면 자동으로 발동하게 한다. 그리고 발동했다는 사실을 반드시 기록에 남긴다 — 나중에 지표가 튄 날을 볼 때 그날 시스템이 다른 모드로 돌고 있었다는 것을 알아야 하기 때문이다.

판정 맥락

조정에서 두 번째로 큰 실수는 요청 문장 하나만 분류기에 넣는 것이다.

맥락 의존

같은 문장이 서비스 종류와 앞선 대화에 따라 완전히 다른 판정을 받는다. 의료 상담에서는 정당한 질문이고, 창작 지원에서는 검토가 필요한 회색 지대이며, 앞 턴에서 특정인을 해치겠다고 말한 대화에서는 명백한 차단이다.

문장만 보는 분류기는 이 셋을 하나로 뭉갠다. 그리고 뭉갠 결과를 임계값으로 고쳐 보려는 시도가 이어진다 — 임계값을 낮추면 의료 상담이 막히고 올리면 세 번째가 새어 나간다. 어떤 값을 골라도 두 실수 중 하나는 남는다. 임계값으로 못 푸는 문제를 임계값으로 풀려고 하는 자리가 여기다. 입력에 없는 정보는 임계값이 만들어 내지 못한다.

함께 넘기는 셋

그래서 판정기에 최소한 이 셋을 함께 넘긴다.

• 서비스 맥락 — 이 요청이 어느 기능에서 왔는가. 의료·법률·창작·아동 대상 여부는 판정을 완전히 바꾼다
• 직전 대화 — 두세 턴이면 충분하다. 전체를 넣으면 비용도 오르고 정확도도 안 오른다
• 사용자 자격 — 연령 확인 여부, 사업자 계정 여부 등 이미 알고 있는 것

두 번째의 "두세 턴"에 근거가 있다. 대화를 길게 넣을수록 좋아질 것 같지만 조정 판정에서는 그렇지 않다. 판정을 뒤집는 정보는 거의 언제나 직전 몇 턴에 있고, 그보다 앞은 판정과 무관한 잡음이라 오히려 분류기의 주의를 흩는다. 게다가 대화가 길어질수록 그 안에 위반 어휘가 하나쯤 섞일 확률이 높아져 전체 점수가 위로 밀린다. 스무 턴을 넣으면 스무 턴짜리 대화가 두 턴짜리 대화보다 무조건 잘 걸리는 시스템이 된다. 넣는 턴 수는 늘려 가며 재 보고 점수가 더 안 오르는 지점에서 멈춘다.

주장된 자격

세 번째를 넣을 때 주의할 것이 있다. 자격 정보로 판정이 느슨해지는 경로를 만들면 그 자격을 위조하는 것이 곧 우회 경로가 된다. 자격은 검증된 것만 쓰고, 사용자가 대화 중에 주장한 것("저는 의사입니다")은 자격이 아니라 그냥 텍스트다.

이 구별이 흐려지는 자리는 대개 프롬프트 안이다. 직전 대화를 통째로 넘기면 그 안에 "저는 의사입니다"라는 문장이 들어 있고, 판정 모델은 그것을 맥락으로 읽는다. 검증된 자격은 대화와 다른 자리에 넣고 "아래 대화 본문에 적힌 자격 주장은 근거로 쓰지 않는다"를 판정 프롬프트에 못 박아 둔다. 그래도 완전히 막히지는 않으니, 자격으로 느슨해지는 폭 자체를 작게 잡는 것이 더 확실하다. 자격이 있으면 차단이 통과로 바뀌는 것이 아니라 차단이 검토로 바뀌는 정도로 설계한다.

출력과 첨부물

지금까지는 사용자 입력만 이야기했는데, 조정이 걸리는 자리는 셋이다. 사용자 입력, 모델 출력, 그리고 첨부물이다.

모델 출력에도 같은 라벨 체계를 적용한다. 입력이 멀쩡해도 출력이 위반일 수 있고, 실제로 사고가 되는 것은 대개 출력 쪽이다 — 사용자가 쓴 문장은 그 사용자만 봤지만 모델이 쓴 문장은 우리 서비스가 한 말이기 때문이다. 다만 임계값은 입력과 다르게 잡는다. 출력을 막으면 사용자는 아무 답도 못 받으니 보류의 비용이 더 크고, 대신 우리가 만든 내용이라 놓쳤을 때의 책임도 더 크다. 두 값이 반대로 당기니 라벨마다 따로 정하는 수밖에 없다.

첨부 이미지와 파일은 라벨 체계는 같이 쓰되 판정기가 다르다. 같은 이름의 라벨을 쓰는 것이 중요하다 — 텍스트에서는 violence_graphic, 이미지에서는 gore처럼 이름이 갈리면 두 갈래의 지표가 합쳐지지 않고 정책 검토도 두 번 해야 한다. 이름을 맞춰 두면 판정기가 몇 개든 위쪽에서는 한 체계로 보인다.

언어와 문화

영어로 만든 조정 시스템을 한국어 서비스에 그대로 붙이면 성능이 떨어진다. 흔히 "다국어 모델이니 괜찮다"고 넘어가는데, 실제로 갈리는 자리는 모델의 언어 능력이 아니라 다른 데 있다.

금칙 표현 목록

금칙 표현 목록은 라벨 정의와 별개로 두는, 나오면 곧바로 점수를 올리는 낱말과 구절의 목록이다. 이것은 언어마다 완전히 새로 만들어야 한다. 번역으로는 안 된다. 실제로 쓰이는 비속어와 은어는 번역기에 안 나오고, 나오더라도 그 언어에서 실제로 쓰이지 않는 형태로 나온다.

목록은 만들어 두고 끝나지도 않는다. 회피 표기가 계속 생기기 때문이다. 자모를 쪼개거나 비슷한 모양의 글자를 끼우거나 사이에 기호를 넣는 식인데, 이 변형은 언어마다 방식이 다르다. 한국어에서는 자모 분리가, 다른 언어에서는 발음이 비슷한 철자 바꾸기가 흔하다. 정규화 단계에서 어디까지 되돌릴지도 언어별로 따로 정해야 한다. 이 목록의 유지 비용을 처음에 세어 두지 않으면 언어를 늘릴 때마다 목록이 하나씩 방치된다.

모욕의 기준

무엇이 모욕인지는 언어가 아니라 사회가 정한다. 같은 말이 한 사회에서는 친근한 농담이고 다른 사회에서는 심각한 비하다. 어떤 주제는 한 나라에서 일상적인 논쟁거리인데 다른 나라에서는 법적으로 다루는 문제다.

그래서 라벨 정의를 번역하는 것으로는 부족하다. 정의 자체를 그 시장에서 다시 쓰거나, 최소한 그 시장의 사람에게 읽히고 예시를 그쪽 것으로 갈아야 한다. 예시가 특히 중요하다 — 판정 프롬프트에 든 예시가 전부 영어권 상황이면 모델은 그 상황과 비슷한 것만 잘 잡는다. 시장을 늘릴 때 드는 비용의 큰 몫이 여기다. 번역비가 아니라 정의를 다시 쓰는 일의 값이다.

코드 스위칭

코드 스위칭은 한 문장이나 한 대화 안에서 두 언어를 오가는 것이다. "이거 진짜 sketchy한데"처럼 쓰는 말이고, 실제 트래픽에는 이런 문장이 아주 많다. 그런데 평가 세트는 대개 한 언어로만 만들어져 있어 여기서 정확도가 얼마나 떨어지는지를 아무도 모른다.

떨어지는 이유는 둘이다. 하나는 회피에 쓰이기 때문이다 — 걸리는 낱말만 다른 언어로 바꿔 쓰면 그 언어의 금칙 목록에 없으니 통과한다. 다른 하나는 판정 모델 자체가 섞인 문장에서 약해지기 때문이다. 평가 세트에 코드 스위칭 문장을 일부러 넣어 두지 않으면 이 구멍은 사고가 나기 전까지 보이지 않는다.

언어별 평가 세트

대응은 하나뿐이다. 서비스하는 언어마다 평가 세트를 따로 만들고 지표를 따로 본다. 전체 정확도 하나로 보면 트래픽이 적은 언어의 문제가 평균에 묻힌다.

숫자로 보면 명확하다. 트래픽의 90%가 한국어이고 10%가 다른 언어인 서비스에서, 한국어 재현율이 0.85이고 다른 언어가 0.40이면 전체는 $0.9 \times 0.85 + 0.1 \times 0.40 = 0.805$다. 0.805는 나쁘지 않아 보이는 숫자다. 그 안에 절반 넘게 새는 언어가 하나 들어 있다는 사실은 평균이 전부 가린다. 언어별로 갈라 보면 첫 줄에서 보인다.

세트 크기는 언어마다 같을 필요가 없고 같을 수도 없다. 트래픽이 적은 언어는 표본을 모으는 데 시간이 더 걸린다. 그래도 라벨마다 몇 건이라는 최소선은 정해 두고, 그 선을 못 채운 언어는 "측정 안 됨"으로 표시한다. 적은 표본으로 낸 점수를 채워 넣으면 그 칸이 초록색으로 보이고, 초록색은 아무도 다시 안 본다.

검토 큐

사람 검토를 붙이면 반드시 큐가 생기고, 큐는 방치하면 반드시 터진다. 터진 큐는 조정 시스템이 없는 것보다 나쁘다 — 있다고 믿고 있는데 실제로는 며칠 밀린 상태이기 때문이다.

네 가지 설정

설계할 때 정해 둘 것이 넷이다.

정할 것	안 정하면	실무 기준
라벨별 처리 기한	급한 것과 안 급한 것이 같은 줄에 선다	위험 큰 라벨은 시간 단위, 나머지는 하루 단위
큐 상한	밀린 것을 아무도 모른다	상한을 넘으면 알림, 그리고 임계값을 자동으로 조인다
우선순위	오래된 것부터 처리하다 급한 것을 놓친다	위험도 × 노출 규모 순
검토자 합의 방식	판정이 사람마다 다르다	위험 큰 라벨만 2인 판정, 나머지는 1인

넷째 줄이 처리량과 직접 물린다. 2인 판정을 붙인 라벨은 같은 인원으로 볼 수 있는 건수가 절반이 된다. 앞 절의 예에서 하루 1,500건이던 처리량은 모든 라벨에 2인 판정을 붙이면 750건으로 떨어지고, 그러면 가운데 띠도 절반으로 좁혀야 한다. 합의 방식은 품질 이야기처럼 들리지만 실제로는 용량 이야기다. 그래서 위험이 큰 몇 라벨에만 붙인다.

우선순위

우선순위를 시간순으로 두면 오래 기다린 순서대로 처리되고, 그러면 방금 들어온 심각한 건이 어제 들어온 사소한 건 뒤에 선다. 대신 위험도 × 노출 규모로 잡는다.

노출 규모라는 축이 낯설 수 있는데, 같은 내용이라도 1:1 대화에서 한 사람이 본 것과 공개 게시물로 나가 수천 명이 볼 것은 다르다. 위험도를 1~3으로, 노출을 예상 열람자 수로 두면 위험도 3짜리 1:1 대화가 3점, 위험도 2짜리 공개 게시물이 수백 점이 되어 뒤쪽이 먼저 처리된다. 두 축의 눈금을 어떻게 맞출지는 서비스마다 다르지만, 축이 둘이라는 것 자체가 시간순보다 낫다.

되먹임

검토 결과는 반드시 데이터로 되돌린다. 사람이 뒤집은 판정은 분류기가 틀린 지점이고, 그게 다음 평가 세트와 다음 프롬프트 수정의 재료다. 검토 결과를 그냥 처리하고 버리면 큐는 영원히 같은 양으로 유지된다.

되돌리는 길은 셋이다. 뒤집힌 건을 평가 세트에 넣어 다음 변경 때 회귀 검사로 쓰고, 같은 라벨에서 뒤집힘이 몰리면 라벨 정의를 다시 열고, 특정 표현이나 상황에서 반복되면 판정 프롬프트의 예시를 갈아 끼운다. 이 셋 중 어느 것도 자동으로 일어나지 않으니 주기를 정해 둔다 — 주마다 한 번 뒤집힌 건을 라벨별로 세어 보는 자리 정도면 된다. 세어 보는 것만으로도 어느 라벨이 계속 새는지가 드러난다.

되먹임을 붙일 때 함께 정할 것이 하나 있다. 뒤집힌 판정이 그 사용자에게도 되돌아가는가다. 잘못 막았던 요청을 뒤늦게 통과로 바꿨다면 그 사실을 사용자에게 알릴 것인지, 알린다면 어디로 알릴 것인지를 정해야 한다. 이 경로가 없으면 사용자 입장에서는 이의를 제기해도 아무 일도 일어나지 않는 시스템이 된다.

검토자 보호

검토자는 위반 콘텐츠만 골라 하루 종일 보는 사람들이다. 이 일이 사람에게 남기는 부담은 실제로 있고, 설계에서 빠뜨리면 이직률로 돌아온다. 그리고 이직률은 곧 품질 문제다 — 라벨 정의를 익히는 데 시간이 걸리는데 그 시간이 쌓이기 전에 사람이 바뀌면 일치도가 계속 낮게 유지된다.

장치는 몇 가지 있다. 가장 무거운 라벨을 한 사람에게 몰지 않고 돌려 배치하는 것, 하루에 볼 수 있는 건수에 상한을 두는 것, 이미지와 영상은 흐림 처리를 기본으로 두고 필요할 때만 걷게 하는 것, 그리고 상담 창구를 실제로 접근 가능하게 두는 것이다. 이것을 복지로만 읽으면 안 된다. 검토 품질이 사람의 상태에 직접 달려 있는 시스템이라 지표와 같은 자리에 놓고 봐야 한다.

라벨별 지표

조정 시스템의 성능을 전체 정확도 하나로 보면 아무것도 안 보인다. 봐야 하는 것은 라벨마다의 정밀도와 재현율이다.

정확도의 함정

대부분의 트래픽이 정상이라 정확도는 항상 높게 나온다. 위반이 1%인 트래픽에서 전부 통과시키는 분류기의 정확도는 99%다. 아무것도 안 하는 시스템이 99점을 받는 지표를 성능 지표로 쓸 수는 없다.

이 함정이 위험한 이유는 숫자가 틀려서가 아니라 방향을 반대로 가리키기 때문이다. 재현율을 올리려고 임계값을 낮추면 오탐이 늘어 정확도는 내려간다. 정확도를 보고 있는 팀은 그 변경을 되돌린다. 지표를 잘못 고르면 시스템을 나쁜 쪽으로 몰아간다.

정밀도와 재현율

$\text{정밀도} = \frac{TP}{TP + FP}, \qquad \text{재현율} = \frac{TP}{TP + FN}$

$TP$는 위반을 위반이라 한 건, $FP$는 정상을 위반이라 한 건, $FN$은 위반을 놓친 건이다. 정밀도는 차단한 것 중 실제로 위반인 비율이고, 재현율은 실제 위반 중 잡은 비율이다. 둘 중 무엇을 중시할지는 라벨마다 다르다.

라벨 성격	중시하는 쪽	이유
피해가 되돌릴 수 없는 것	재현율	놓치는 비용이 오탐 비용보다 훨씬 크다
표현·창작에 걸리는 것	정밀도	오탐이 곧 제품 품질 저하다
법적 의무가 걸린 것	재현율 + 기록	판정 근거를 남기는 것 자체가 요구사항이다

전부 한 방향으로 맞추려 하면 안 된다. 라벨마다 다른 임계값을 쓰는 이유가 이것이다. 그리고 목표치도 라벨마다 따로 적어 둔다 — "정밀도 0.95 이상, 재현율은 그 아래에서 최대"처럼 한쪽을 제약으로 두고 다른 쪽을 목표로 두는 형식이 실무에서 다루기 쉽다. 두 값에 동시에 목표를 걸면 어느 쪽도 못 맞춘다.

오탐의 실제 크기

한 가지 더 재야 하는 것이 있다. 오탐이 사용자에게 어떻게 보이는가이다. 숫자를 사람 수로 옮겨 보면 체감이 달라진다.

하루 요청 20만 건에 위반이 1%면 위반은 2,000건이다. 재현율 0.8이면 1,600건을 잡는다. 정밀도 0.95면 차단한 것이 $1600 / 0.95 \approx 1684$건이고 그중 84건이 정상 요청이다. 하루에 84명이 아무 잘못 없이 막힌다. 한 달이면 2,500명이 넘는다. 전체 정상 요청 198,000건으로 나누면 0.04%라 서비스 쪽 숫자로는 거의 0에 가깝지만, 그 84명에게 이 서비스는 그냥 안 되는 서비스다.

반대쪽도 같이 센다. 재현율 0.8이면 400건이 새어 나간다. 이 400건과 저 84명이 같은 저울에 올라 있고, 임계값을 움직이면 한쪽이 줄고 다른 쪽이 는다. 지표를 비율로만 보면 이 저울이 안 보인다. 라벨별 대시보드에는 비율과 함께 하루 몇 건인지를 같이 적어 둔다.

이 문제는 임계값으로는 다 못 푼다. 84명이 막히는 것 자체를 0으로 만들 수는 없으니, 남는 일은 그 84명이 무엇을 보고 무엇을 할 수 있는가를 설계하는 쪽으로 넘어간다.

정밀도-재현율 곡선

임계값을 움직이면 정밀도와 재현율이 반대로 움직인다. 임계값을 높이면 확신하는 것만 차단하니 정밀도가 오르고 재현율이 내려가며, 낮추면 반대다. 이 관계를 점 하나가 아니라 곡선으로 보는 것이 정밀도-재현율 곡선이다. 임계값을 0에서 1까지 훑으며 두 값의 짝을 찍은 그림이다.

이 곡선을 그려 두면 두 가지가 달라진다. 하나는 임계값을 고르는 일이 협상이 아니라 선택이 된다 — "정밀도 0.95를 지키면 재현율은 0.72까지밖에 못 간다"처럼 대가가 숫자로 보인다. 다른 하나는 모델을 바꿨을 때 진짜 좋아졌는지가 보인다. 점 하나로 비교하면 임계값이 달라 생긴 차이인지 모델이 좋아진 차이인지 알 수 없는데, 곡선 전체가 위로 올라갔으면 그건 모델이 좋아진 것이다.

라벨마다 이 곡선이 다르게 생겼다는 점도 중요하다. 정의가 선명한 라벨은 곡선이 오른쪽 위에 붙어 있어 임계값을 어디에 둬도 둘 다 괜찮고, 정의가 흐린 라벨은 곡선이 대각선 쪽으로 주저앉아 어느 점을 골라도 한쪽을 크게 내줘야 한다. 곡선이 주저앉은 라벨은 임계값 문제가 아니라 정의 문제다. 여기서 이 글의 첫 절로 돌아온다 — 조정 시스템에서 고칠 곳이 없어 보일 때 대개 남아 있는 것은 라벨 정의다.

다음 글은 이 글 끝에서 남긴 문제를 이어받는다. 잘 판정해서 막기로 정했을 때, 그 거절을 어떻게 전달할 것인가다. 거절은 안전 장치의 마지막 동작이면서 동시에 사용자가 제품을 평가하는 순간이라, 판정만큼이나 설계가 필요하다.

---

읽어주셔서 감사합니다. 😊