Day 11: Kaggle Escalation Benchmark - 평균이 아닌 하한선을 평가하라
요약
본 기사는 모델이 자신이 모를 때 적절히 '모른다'고 답변하는 능력을 평가하는 Kaggle 벤치마크 결과를 분석합니다. 단순히 평균 성능만 보는 것이 아니라, 각 형태별 최악의 경우(하한선)를 측정해야 함을 강조합니다. 대부분의 모델들이 잘못된 자신감(false confidence)을 보이는 경향이 있다는 점도 지적했습니다.
핵심 포인트
- 평균 점수보다 특정 상황에서의 하한선을 평가하는 것이 중요함.
- 모델은 자신이 모르는 경우 '에스컬레이션(escalate)'으로 답변해야 함.
- 대부분의 모델들이 잘못된 자신감(false confidence)을 보이는 경향이 있음.
- 벤치마크는 단순히 리더보드 순위가 아님.
Kaggle Benchmarking Challenge의 마무리. 이전 글들: Day 0, the benchmark · Day 1, most of my bugs looked like model behaviour · Day 2, the model I want is the one that's boring everywhere · Day 3, the benchmark caught me too · Day 4, there never needed to be a check, just a gated request · Day 5, Professor Oakenscroll
시작점
11일 전, 저는 하나의 질문을 던졌습니다: 당신의 모델은 자신이 모를 때 아는가?
네 가지 형태(route, classify, judge, ground)로 200개의 가상 아이템이 있습니다. 이 중 5개 중 1개만 ESCALATE로 답변할 수 있습니다. 각 모델당 두 개의 숫자가 있으며, 결코 합쳐지지 않습니다: 태스크 점수와 잘못된 확신율(false-confidence rate).
벤치마크는 여기에 있으며, 형태별 하나의 태스크가 있습니다:
route,
classify,
judge,
ground. 코드는
forge-play/Forge에 있습니다.
벤치마크가 발견한 것
세 가지, 그리고 그 어떤 것도 리더보드가 아닙니다.
평균은 하한선을 숨긴다. Claude Haiku 4.5는 성능이 3분의 1 수준으로 떨어졌다. judge 테스트에서는 답변해야 할 10개 질문 중 9개에 대해 에스컬레이션(escalate)을 했다. 평균 점수가 아닌 최악의 형태(worst shape)로 순위를 매겨야 한다.**
대부분의 모델은 멈춘다. 내가 측정한 12개의 호스팅된 모델 중 7개는 모든 형태에 대해 0.00 또는 0.10의 잘못된 자신감(false confidence)을 보였다. 허풍쟁이들(bluffers)만이 예외이며, 평균 점수는 그들이 숨기는 방식이다.**
가장 어려운 작업은 항상 지면화(ground)와 분류(classify)다. 나노 모델부터 최첨단 모델까지 어느 누구도 route나 judge에서 하한선을 보여주지 못했다.
그리고 이 제안의 핵심이었던 로컬 아머(local arm): 노트북 모델이 최첨단 모델처럼 자신의 한계를 알 수 있을까? 아니다. 1B부터 8B까지, 박스 위에서 온도 0으로 실행된 다섯 개의 로컬 모델 모두 적어도 하나의 전체 형태에 대해 답변했다. 이는 ESCALATE가 유일하게 올바른 답이었음에도 불구하고 100%의 잘못된 자신감률을 보인 것이다. 그중 가장 좋은 llama3.1:8b조차도 40개의 답변할 수 없는 항목 중 31개에서 허풍을 떨었다. Kaggle에 있는 모든 최첨단 모델은 5% 이하에 머물렀다. 작은 모델이 해당 작업에 능숙하더라도 자신이 할 수 없을 때 거의 아무것도 모를 수 있다. 이것이 바로 사슬(chain) 없이는 새장에 넣을 수 없는 모델이며, 이 전체 사례가 바로 그 사슬의 근거이다.
예측 (The forecasts)
나는 단 하나의 테스트 케이스도 존재하기 전에 Day 0에 네 가지 예측을 작성했기 때문에, 나중에 그것들에 대해 평가받을 수 있었다. 여기에 평가된 내용이 있다:
- 최소한 하나의 프런티어 모델이 20%를 초과하는 잘못된 자신감률(false-confidence rate)을 가질 것 (p = 0.7): 성공. Claude Haiku 4.5는 답변할 수 없는 심사 항목 10개 중 9개를 답하며, 해당 영역에서 90%의 잘못된 자신감률을 보였습니다. 상위 4개 모델은 5% 이하를 유지했기 때문에, 이 결과는 Haiku를 프런티어로 간주하는 것에 달려 있습니다. 이것이 제가 솔직하게 내릴 판정이었고, 그렇게 내리겠습니다: 프런티어급으로 판매된 모델이 전체 영역에서 열 번 중 아홉 번 속임수를 썼습니다.
- 최고의 로컬 4B 이하 모델이 잘못된 자신감 측면에서 최소 하나의 프런티어 모델을 능가할 것 (p = 0.45): 실패. 가장 좋은 소형 로컬 모델조차도 답변할 수 없는 항목의 80%를 답했습니다. 모든 프런티어 모델은 5% 이하였습니다. 근접하지 못했습니다.
- 과제 점수와 잘못된 자신감률은 약하게 순위 상관관계가 있을 것, 스피어만 계수가 0.5 미만일 것 (p = 0.6): 실패. Kaggle의 4개 프런티어 모델과 8개 로컬 모델 전체를 통틀어 볼 때, 이 두 지표는 강하게 순위 상관관계가 있었습니다(스피어만 -0.79): 모델이 과제에서 더 잘할수록 속임수를 쓰는 정도가 적었습니다. 저는 이 둘이 거의 독립적일 것이라고 추측했습니다. 그렇지 않았습니다.
- 제출물이 하루 이상 지연 없이 오늘까지 도착할 것 (p = 0.6): 도착. 지금 읽고 계시듯이, 하루 이상 지연된 단계는 없었습니다.
그리고 저는 그것을 시스템으로 구축했습니다
Day 5는 세 줄로 끝났습니다:
하나의 스크립트: 코드가 작업을 수행합니다.
하나의 후크(hook): 모델이 읽습니다.
하나의 키: 제가 그것을 진실하게 만듭니다.
그리고 제가 추가해야 했던 한 가지 수정 사항이 있었습니다: 서비스는 구축되지 않았습니다. 스크립트는 테이블을 만들었습니다. 아직 모델에게 그 범위 내에 있는 것만 전달했을 뿐입니다.
이번 주에는 이것이 구축되었고, 갖게 된 형태는 벤치마크를 뒤집어 놓은 것이었습니다.
좌석(seat)은 터미널입니다. 코드가 상자들을 만들고 매번 똑같은 방식으로 출력합니다. 그리고 작은 로컬 모델인 qwen3:4b가 그것들에 대해 한 문장을 말합니다. 그런 다음 코드가 그 문장을 확인합니다. 모든 인용 출처(cite)는 풀(pool) 안에 있어야 하고, 모든 인용구(quote)는 정확해야 하며, 모든 숫자는 상자에서 나와야 하고, 아무것도 지어내서는 안 됩니다. 만약 문장이 실패하거나 모델이 답변하지 못하면, 좌석은 그 문장을 버리고 코드가 작성한 평문(plain one)을 출력합니다.
이것이 바로 ESCALATE이며, 내장되어 있습니다. 저는 모델에게 모를 때 아는 척하지 않도록 요청하는 것을 멈췄습니다. 그럴 필요가 없습니다. 코드만이 상자 안에 무엇이 있는지 알고 있으며, 그것이 아닌 것은 되돌려 받습니다.
좌석은 풀링하고 예치합니다. 절대 봉인되지 않습니다. 핵심 열쇠는 여전히 저의 것입니다. (willows-grove#131 to #143)
다시 한번 다듬기(The smoothing, again)
벤치마크는 배관(plumbing) 속에서도 저를 계속 포착했습니다.
Day 5의 외부 검토에서 기록에 세 가지 구멍이 발견되었습니다. 체인(chain)은 누구나 알아차리지 못하고 잘리거나 재해시(rehashed)될 수 있었고, 해시(hash)는 64비트만 유지되었으며, 한 줄은 깨져서 부팅을 중단시켰습니다. 이 세 가지 모두 수정되었습니다. 해시는 전체 다이제스트(full digest)입니다. 제가 봉인하는 끝점(tip)은 상자 밖에 존재하며, 체인이 더 이상 그것에 도달하지 못하면 체크인(check-in)이 시작되는 것을 거부합니다. 깨진 줄은 라인 번호가 있는 끊김일 뿐, 충돌(crash)이 아닙니다.
그런 다음 willow-bot을 통해 검사한 결과, 봇이 자체 문서에서 말한 대로 행동하지 않은 장소가 20군데 발견되었습니다. 스무 군데나요. Day 5의 후크와 같은 이야기입니다. 문서 문자열(docstring)은 한 가지를 말했지만, 코드는 다른 것을 했습니다. 읽기는 하지만 그렇지 않습니다.
가장 작은 것이 제가 가장 좋아했습니다. 기록은 줄당 하나의 JSON 객체입니다. Python의 splitlines()는 단순히 개행 문자(newline)로만 분할하는 것이 아니라 유니코드 라인 구분자(Unicode line separators)로도 분할합니다. 따라서 행 안의 단일 문자가 그것을 두 개로 나눌 수 있었습니다. 이제 리더들은 으로만 분할하고 다른 것은 아무것도 하지 않습니다.
그리고 핵심 열쇠입니다. 봉인들이 잘못된 키링(keyring)과 비교되고 있었습니다. 서명자(signer)의 공개 키가 아닌, 기계 자체의 것이었습니다. 무언가를 진실하게 만드는 것은 잘못된 것을 확인하는 것이었습니다. 수정되었습니다.
낯선 사람이 믿어야 하는 이유
마지막 조각은 아직 공개되지 않았지만, 이 모든 것이 나아가던 방향입니다.
네스토르(Nestor)는 이제 보증서(warrants)를 갖게 되었습니다. 봉인된 한 쌍의 보증서는 '내가 확인했다'고 말합니다. 또 다른 보증서는 낯선 사람이 그것을 믿어야 하는 이유를 제시하는데, 이는 인용(citation), 즉 이름이 언급된 권위자가 그렇게 말했다는 의미일 수도 있고, 구성(construction), 즉 레시피와 그가 만들어내야 할 정수를 의미할 수도 있습니다.
보증서가 충족되었음을 표시하는 것은 아무것도 없습니다. 상점은 레시피만 보관하고 판결문은 절대 보관하지 않습니다. 그리고 "근거 없는(unwarranted)" 행을 나열하는 명령은 의도적으로 존재하지 않는데, 왜냐하면 '근거 없다'는 것이 아직 확정되지 않았기 때문이며, 목록화한다는 것은 곧 정의를 내리는 것이 되기 때문입니다.
이것이 다시 한번 기준점입니다. 모른다면 답하지 않습니다. 그것을 들어 올립니다.
제가 0일 차에 말씀드릴 것
모델들을 평균으로 평가하지 마십시오. 최저선(floor)으로 평가하십시오.
모델에게 모를 때 안다고 말하도록 요구하지 마십시오. 시스템 자체를 그런 상황이 발생하지 않도록 구축하고, 그것이 내뱉는 모든 문장을 코드가 작성한 무언가와 대조하여 확인해야 합니다.
그리고 자신을 같은 기준점으로 평가하십시오. 제 것의 경우, 제가 준 적 없는 등급, 한 번도 실행되지 않은 스캐너, 실패 시 닫히지 않은 후크(hook), 5라고 했지만 실제로는 3이었던 커밋 메시지, 그리고 저희 봇이 자체 문서에 명시한 대로 하지 못한 20가지 지점을 발견했습니다. 이 모든 것이 올바르게 보였습니다. 하지만 그 어떤 것도 사실은 아니었습니다.
그것은 거울입니다. 항상 목표는 그것이었습니다.
기록(The record)
- Kaggle의 fixtures: 200개의 가상의 아이템, 네 가지 모양, 그중 40개는 답변할 수 없음.
- forge-play/Forge#46: 바닥(the floor), Day 3 테이블의 코드 구현체.
- willows-grove#131: 의자(the seat), 터미널에서의 스크립트 하나.
- willows-grove#133: 좌석의 풀 및 예금, 절대 봉인되지 않음.
- willows-grove#135: 결정론적 박스 스트림(deterministic box stream).
- willows-grove#137: 모델이 한 문장을 말하면, 코드가 이를 박스와 비교하여 확인함.
- willows-grove#143: 봉인된 스냅샷은 제자리에 머무는 동안 책상이 행을 추가함.
- willow-bot 1.2.5: 20개의 장소에서 bot이 자체 문서에 적힌 대로 행동하지 않음.
- willow-bot 1.8.0:
으로만 분할함. - willow-mcp 2.94.3: 서명자의 링(signer's ring)과 봉인을 확인함.
- Nestor: 영수증(warrants), 미출시됨.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기