분석: 공개 벤치마크는 더 이상 «프로덕션 품질»을 예측하지 않는다 — 예측하는 평가셋 만드는 법

언어 모델로 제품을 내는 팀이라면 대개 겪어 본 특정한 실망이 있다. 새 모델이 모든 차트에서 더 좋은 숫자를 달고 나온다. 갈아 끼운다. 일주일 안에 문의가 늘고, 내부 사용자가 «요약이 나빠졌다»고 알려 오고, 누군가 조용히 되돌린다.

속인 사람은 없다. 벤치마크 점수는 진짜였고, 그 모델은 아마 «대체로» 더 세다. 잘못은 추론에 있었다. 리더보드는 어떤 배포도 하지 않는 질문에 답한다.

벤치마크가 실제로 재는 것

공개 벤치마크는 과학에는 도움이 되고 «판단»에는 도움이 안 되는 성질 몇 가지를 공유한다.

고정돼 있다. 바뀌는 벤치마크는 시간축 비교가 안 되므로 문항이 고정된다. 그러면 같은 문제가 수천 편의 논문·글·저장소에서 풀리고, 그것이 열린 웹에 올라가고, 학습 말뭉치에 들어간다. 이것이 «오염»이고 부정행위 고발이 아니다 — 시험을 공개해 두고 인터넷으로 학습하면 나오는 기본값이다. 결과적으로 점수는 «능력»보다 빠르게 올라간다.

좁다. 객관식 지식, 경시대회 수학, 고립된 코딩 문제, 짧은 추론은 전부 정당한 탐침이다. 다만 그것과 «구두점이 엉망인 고객 문의를 환불 정책을 지어내지 않고 처리한다» 사이의 상관은 약하고, 아무도 그렇지 않다고 주장한 적이 없다.

최적화 대상이다. 어떤 숫자가 업계의 «진보 약칭»이 되는 순간, 그 숫자는 모든 학습·평가 루프에 목표로 들어간다. 나머지는 굿하트의 법칙이 한다. 누가 부정을 저지를 필요가 없고, 모두가 신경 쓰기만 하면 된다.

프로덕션 품질을 정하는 제약을 전부 버린다. 지연 예산, 컨텍스트 길이, 도구 스키마, 검색 품질, 우리 프롬프트, 출력 형식, 그리고 «어떤 종류의 오류가 우리에게 얼마나 나쁜가».

사람 선호 기반 리더보드는 이 중 일부를 고치고 자기만의 왜곡을 넣는다. 과제가 우리 것과 다른 인구 집단 위에서 집계되고, 나란히 놓고 훑을 때 좋아 보이는 성질에 상을 준다 — 매끄러운 구조, 자신 있는 어조, 넉넉한 길이. 제품이 «짧고 문자 그대로이며 모르면 거절하는» 동작을 필요로 한다면, 선호 순위는 정확히 반대 방향을 가리킬 수 있다.

대안은 생각보다 «작다»

팀이 자체 평가셋을 안 만드는 이유는 뭔가 거대한 것을 상상하기 때문이다. 그렇지 않다. 쓸모 있는 평가셋은 보통 50~300건이고, 첫 판은 하루면 모인다.

① 실제 트래픽에서 가져온다. 지어낸 예시가 아니라 로그에서. 실제 사용자 메시지, 실제 문서, 실제 도구 호출 열. 지어낸 사례는 지어낸 사람의 사각지대를 그대로 물려받는다.

② «주제»가 아니라 «대가»로 층을 나눈다. 본능은 주제별로 묶는 것이다. 쓸모 있는 축은 «틀렸을 때 얼마짜리인가»다.

• 조용한 오답 — 그럴듯하고, 자신 있고, 틀렸다. 가장 비싼 층이고 일부러 많이 담을 가치가 있다.
• 거절했어야 하는데 답한 것 — 물러서거나 사람에게 넘겨야 했는데 모델이 답해 버린 경우.
• 형식 파손 — 내용은 맞는데 모양이 깨져 뒷단 파서가 죽는 경우.
• 표면적인 것 — 어조·길이·순서. 실재하지만 싸다.

표면적인 층에서 좋아지고 조용한 오답 층에서 나빠진 모델은 «평균 점수는 더 높고 제품으로는 더 나쁘다». 층을 나눈 평가셋만 그것을 드러낸다.

③ 기대 «문자열»이 아니라 기대 «동작»을 적는다. 대부분의 사례에서 올바른 라벨은 단언들의 집합이다 — 문서 3 을 인용해야 함, 가격을 언급하면 안 됨, 이 필드들을 가진 유효한 JSON 이어야 함, 거절해야 함. 단언은 표현이 바뀌어도 살아남고, 정답 문자열은 못 살아남는다.

④ 결정적 검사를 먼저 돌린다. 스키마 유효성, 필수 필드, 금지 문자열, 수치 허용오차, 인용 존재, 지연, 토큰 비용. 이 층은 싸고 정확하며, 실제 회귀의 놀랄 만한 비율을 잡는다. assert 로 판정할 수 있는 것은 심판에게 가면 안 된다.

⑤ 남은 것만 모델 심판에게. 출처에 대한 충실성, 어조, 완결성, 설명이 실제로 질문에 응답하는가. 심판에게는 구체적 기준이 적힌 채점표, 있을 때는 기준 답안, 두 출력을 비교할 때는 무작위 순서가 필요하다. 표본에 대해 «심판과 사람의 일치도»를 보고한다 — 낮으면 문제는 심판이 아니라 채점표다.

결과를 «자기 자신에게 속지 않고» 읽기

평가 데이터로 내린 나쁜 판단의 대부분은 두 가지 실패에서 온다.

첫째, 작은 차이를 차이로 취급하는 것. 100건에서 82%→85% 는 잡음 안이다. 신뢰구간을 함께 보고하거나, 여러 번 돌려 분산을 보거나, 승자를 선언하고 싶은 충동을 참는다. 샘플링 온도만으로도 작은 셋은 몇 포인트 움직인다.

둘째, 정작 중요한 것을 평균으로 지우는 것. 총 통과율은 실패의 «모양»을 감춘다. 평가 실행의 쓸모 있는 산출은 숫자가 아니라 표다 — 층별 통과율, 그리고 «어느 사례가 뒤집혔는가»의 diff. 통과에서 실패로 뒤집힌 사례가 신호의 전부다. 읽어야 한다.

평가셋은 시간이 지나며 «어디서» 오는가

첫 판은 로그에서 온다. 오래 가는 판본은 사고에서 온다. 사람에게까지 올라온 모든 프로덕션 실패는 «기대 동작을 적은 사례 한 건 추가»로 끝나야 한다. 이렇게 하면 고객지원 부하가 회귀 커버리지로 바뀌고, 평가셋이 일반적인 품질 대리지표가 아니라 «우리 제품의 것»이 된다.

검색 기반 시스템에도 같은 규율이 적용되지만 한 층이 더 필요하다. 검색과 생성을 따로 평가한다. 맞는 문서가 애초에 검색되지 않아서 답이 틀린 것이라면 모델을 아무리 갈아 끼워도 안 고쳐지는데, 종단 간 점수는 계속 «모델이 문제»라고 말해 준다.

그래도 벤치마크가 좋은 자리

이 글의 어느 것도 공개 평가를 무가치하게 만들지 않는다. 리더보드를 통째로 무시하는 반사 반응은 그 자체로 또 다른 오류다.

선별로는 합리적이다. 스무 개 모델에서 제대로 시험할 셋을 골라야 한다면, 공개 점수 + 컨텍스트 길이 + 가격이면 변호 가능한 셋이 나온다. 분야 수준의 추세선으로도 유용하다 — 지난 2년간 오픈 웨이트 모델이 프런티어 모델에 대해 움직인 궤적은 실재하는 신호이고 다른 방법으로는 보기 어렵다. 그리고 «실행된 결과»를 요구해 암기에 저항하는 일부 에이전트·저장소 수준 벤치마크는 능력 변화에 대해 진짜로 정보를 준다.

규칙은 좁고, 그대로 적어 둘 만하다. 무엇을 «시험할지»는 공개 벤치마크로 정하고, 무엇을 «출시할지»는 우리 평가셋으로 정한다. 이 둘을 뒤집는 팀은 업그레이드가 왜 상황을 악화시켰는지 사용자에게 설명하는 데 많은 시간을 쓴다.