AI 벤치마크 숫자 비교 전: 평가 데이터 오염과 실행 조건 확인하기

점수에는 문제 집합과 실행 조건이 붙어야 합니다

AI 모델 발표가 이어질수록 리더보드의 짧은 점수표가 도입 논의에 자주 등장합니다. LiveCodeBench와 LiveBench는 문제의 시점과 갱신을 통해 평가 오염을 줄이려는 연구입니다. 이 접근은 새 벤치마크라면 언제나 오염이 없다는 보증과 다릅니다. 비교하려는 점수가 어떤 문제 묶음과 실행 조건에서 나왔는지 확인하는 출발점으로 읽어야 합니다.

• LiveCodeBench · Official research repository
• LiveBench: A Challenging, Contamination-Limited LLM Benchmark

예를 들어 두 모델이 같은 코딩 평가에서 비슷한 점수를 얻었어도 한쪽은 한 번만 답하고 다른 쪽은 여러 후보를 실행해 고른 결과일 수 있습니다. 검색, 테스트 실행, 재시도와 추론 예산이 다르면 모델 능력과 실행 구조의 효과가 섞입니다. 회사가 실제로 허용할 응답 시간과 도구 범위를 먼저 정한 뒤 그 조건과 가까운 결과를 비교하세요.

오염은 학습 데이터에 정답이 있는 경우만 뜻하지 않습니다

평가 문제나 해설이 학습 자료에 포함되는 경로 외에도, 검색 도구가 공개 정답을 가져오거나 프롬프트 예시에 같은 문제가 들어갈 수 있습니다. 반복적인 내부 튜닝에서 평가 실패를 모두 학습 자료로 옮기면 처음의 평가 집합은 더 이상 독립된 기준이 아닙니다. 어느 단계에서 누가 문제와 정답을 보았는지 데이터 흐름을 기록해야 원인을 구분할 수 있습니다.

단순 문자열 중복 검사만으로도 일부 누출을 찾을 수 있지만, 이름과 숫자를 바꾼 문제나 번역된 문제는 놓칠 수 있습니다. 원본 문서·거래·프로젝트 단위로 묶어 학습과 평가를 분리하고 유사 사례도 점검하세요. 공개일이 모델의 알려진 학습 시점보다 늦다는 사실은 유용한 단서지만, 검색이나 후속 학습 경로까지 배제하는 증거는 아닙니다.

내부 평가도 개발 과정에서 닳습니다

가상의 고객 문의 분류기를 평가한다면 같은 상담 대화의 앞부분은 학습에, 뒷부분은 평가에 들어가지 않도록 묶음 단위로 분리합니다. 담당자가 평가 질문을 보고 프롬프트를 계속 조정했다면 그 집합은 개발용으로 전환하고 별도 최종 확인 표본을 남기세요. 실패를 학습하는 과정 자체는 필요하지만 그 뒤에도 같은 점수를 독립 검증이라고 부를 수는 없습니다.

합성 데이터를 추가할 때도 생성에 사용한 씨앗 사례와 파생 문장을 같은 그룹으로 관리합니다. 정답 문장을 조금 바꾼 질문은 새로운 업무 사례처럼 보여도 지식을 재활용한 것일 수 있습니다. 테스트 목적, 생성 출처와 사용 이력을 기록하면 전체 평가를 폐기하지 않고 영향을 받은 구간을 찾아 교체하거나 결과에서 분리할 수 있습니다.

벤치마크는 후보 선정과 최종 검증에서 역할이 다릅니다

공개 평가는 어떤 능력이 필요한지 파악하고 비교할 후보를 좁히는 데 도움이 됩니다. 최종 도입은 실제 입력 분포, 실패 비용과 처리 시간 조건을 반영한 평가로 결정하세요. 작은 점수 차이를 순위로 단정하기보다 반복 실행의 변동과 실패 유형을 살펴봅니다. 오염이 의심되더라도 근거 없이 특정 모델의 부정을 주장하지 말고 비교에서 확인하지 못한 조건을 명시합니다.

• 문제 버전과 수집 기간을 확인했는가
• 검색·추론·재시도 예산이 비교 가능한가
• 동일 원본에서 파생된 사례를 분리하지 않았는가
• 튜닝에 쓰지 않은 최종 업무 표본을 남겼는가