지난 글이 서버가 얼마나 빠른지 재는 이야기였다면, 이번에는 모델이 얼마나 잘하는지 재는 쪽이다. 여기에는 속도 측정에 없는 고약한 문제가 하나 있다. 시험 문제가 이미 유출돼 있을 수 있다는 것.
공개된 벤치마크는 인터넷 어딘가에 문제와 정답이 함께 놓여 있다. 그 인터넷을 긁어 모델을 학습시킨다. 그러면 채점을 하는데 답안지를 외운 학생을 앉혀 놓은 셈이 된다. 이것을 오염(contamination)이라 부른다.
어떤 길로 들어오는가
경로가 하나가 아니라는 점이 이 문제를 성가시게 만든다.
넷을 나눠 보면 대응할 수 있는 것과 없는 것이 갈린다.
| 갈래 | 무엇이 일어나나 | 알아채기 |
|---|---|---|
| ① 웹 크롤 | 데이터셋 원문이 저장소·풀이 블로그에 그대로 올라 있다 | 겹침을 세면 보인다 |
| ② 합성 데이터 | 벤치마크를 흉내 내 만든 학습 데이터에 원문이 섞인다 | 어렵다. 표현이 조금씩 다르다 |
| ③ 사람을 거친 과적합 | 같은 테스트 세트로 수십 번 고르고 다시 학습한다 | 가중치에는 흔적이 없다 |
| ④ 평가 중의 검색 | 모델이 채점 도중 정답 페이지를 직접 읽는다 | 도구 호출 로그에 남는다 |
③은 특히 눈에 안 띈다. 학습 데이터에 문제가 한 줄도 안 들어가도 생기기 때문이다. 테스트 점수를 보며 하이퍼파라미터를 고르고, 데이터를 섞고, 다시 재기를 서른 번 반복하면 사람이 그 테스트 세트에 맞춰 간다. 모델은 깨끗한데 절차가 오염된 경우다.
④는 에이전트가 흔해지면서 새로 생긴 갈래다. 검색 도구를 쥔 모델을 공개 벤치마크로 평가하면, 모델이 문제 문장을 그대로 검색해 정답이 적힌 페이지를 찾아 읽는 일이 실제로 일어난다. 넷 중 평가하는 쪽에서 막을 수 있는 것은 이것뿐이다.
오염을 의심하는 방법
「이 점수가 진짜인가」를 확인하는 실용적인 방법은 몇 가지가 있다. 완전한 증명은 어렵고, 대신 증거를 모으는 쪽에 가깝다.
겹침 세기. 평가 문제의 13-그램(연속한 낱말 열세 개)이 학습 코퍼스에 그대로 있는지 센다. 학습 데이터에 접근할 수 있을 때만 되는 방법이라 남의 모델에는 못 쓴다. 표현을 조금만 바꾼 ②번 경로도 못 잡는다.
변형 대조. 접근 권한 없이 쓸 수 있는 가장 실용적인 방법이다. 같은 문제를 여러 형태로 바꿔 점수를 견준다.
세 변형이 각각 다른 것을 확인한다.
- 숫자만 바꾸기: 푸는 방법은 그대로다. 방법을 아는 모델이라면 점수가 유지된다
- 보기 순서 섞기: 정답 내용은 그대로다. 「세 번째가 정답」을 외웠다면 여기서 무너진다
- 새로 만든 문제: 같은 범위·같은 난이도로 새로 낸다. 가장 믿을 만하지만 만드는 비용이 크다
깨끗한 모델이라면 넷이 비슷하게 나온다. 원본만 스무 점 넘게 솟아 있다면 그 격차가 곧 기억의 크기다.
시점으로 가르기. 모델의 학습 마감 시점 뒤에 만들어진 문제만 골라 재고, 그 앞 문제와 비교한다. 마감 뒤 문제에서만 점수가 뚝 떨어지면 앞쪽 점수를 그대로 믿기 어렵다. 다만 최근 사건일수록 문제 자체가 어려운 경향이 있어, 떨어진 이유가 오염 때문인지 난이도 때문인지는 갈라 봐야 한다.
카나리아 문자열. 데이터셋을 만드는 쪽이 쓰는 방법이다. 파일 안에 사람이 절대 안 쓸 무작위 문자열을 심어 두고, 나중에 모델에게 그 문자열을 이어 써 보라고 시킨다. 모델이 완성하면 그 파일이 학습에 들어간 것이다. 크롤링에서 이 파일을 빼 달라는 표시이기도 하다.
그래서 무엇을 하나
공개 벤치마크를 아예 안 볼 수는 없다. 다른 모델과 견주는 공통 자가 그것뿐이기 때문이다. 다만 의사결정을 거기에 걸지 않는 것이 요령이다.
우리 서비스에 어느 모델을 쓸지 정하는 자리라면, 순위표 대신 우리 데이터로 만든 평가가 훨씬 낫다. 그 평가를 만들 때 지킬 것이 몇 가지 있다.
| 지킬 것 | 이유 |
|---|---|
| 우리 로그에서 문제를 뽑는다 | 어차피 인터넷에 없는 데이터다 |
| 정답을 공개하지 않는다 | 저장소에 올리는 순간 다음 크롤에 들어간다 |
| 홀드아웃을 따로 둔다 | 매번 보는 세트와 가끔 보는 세트를 나눈다 |
| 주기적으로 새 문제를 넣는다 | 오래 쓴 세트는 절차 쪽으로 오염된다 |
| 도구 접근을 통제한다 | 평가 중 검색은 끄거나 로그를 남긴다 |
정답을 공개하지 않는다는 항목이 실무에서 가장 자주 깨진다. 평가 세트를 사내 위키나 공개 저장소에 정답과 함께 올려 두는 것이 편해서다. 사내 위키는 괜찮지만, 공개 저장소는 몇 달 뒤 크롤에 들어가고 그다음 모델이 그것을 학습한다.
홀드아웃을 따로 두는 것도 눈여겨볼 만하다. 평가 세트를 둘로 나눠 하나는 개발하며 매일 보고, 다른 하나는 배포 직전에만 연다. 매일 보는 쪽은 시간이 갈수록 ③번 오염이 쌓이지만, 가끔 여는 쪽은 오래 깨끗하다. 두 세트의 점수가 벌어지기 시작하면 그것이 신호다 — 자주 보던 쪽에 맞춰 가고 있다는 뜻이다.
순위표를 읽는 법
모델을 고를 때 공개 순위표를 볼 수밖에 없다면, 이렇게 읽으면 덜 속는다.
- 점수 하나가 아니라 여러 벤치마크의 모양을 본다. 한 벤치마크에서만 유난히 높으면 의심할 자리다
- 최근에 만들어진 벤치마크를 함께 본다. 나온 지 오래된 데이터셋일수록 오염 확률이 높다
- 비공개 채점 벤치마크를 우선한다. 정답을 공개하지 않고 제출만 받는 쪽이 오염에 강하다
- 점수 차이가 1~2점이면 없는 차이로 여긴다. 그 정도는 프롬프트 형식이나 채점 방식만 바꿔도 뒤집힌다
- 결국 우리 문제로 다시 잰다. 순위표는 후보를 좁히는 데 쓰고, 고르는 것은 우리 평가로 한다
정리
오염은 없앨 수 있는 문제가 아니라 관리하는 문제다. 공개 데이터로 학습하는 한 공개 시험지는 계속 새어 들어가고, 같은 세트를 오래 보면 사람 쪽이 먼저 그 세트에 맞춰 간다.
그러니 답은 하나다. 결정에 쓰는 자는 우리가 만들고, 우리만 갖고 있고, 가끔 갈아 끼운다. 공개 벤치마크는 남과 대화할 때 쓰는 공용어로 남겨 두면 된다.
읽어주셔서 감사합니다. 😊