벤치마크 점수 보고 전 캐나리 프로브 실행하기

벤치마크 점수는 하네스(harness), 그레이더(grader), 모델에 대한 동시적인 주장임에도 불구하고, 공개 토론에서는 거의 항상 세 번째 요소만 불확실한 것으로 취급됩니다. 패키지에 추가되고 출판 전에 게이팅되는 세 가지 프로브 계열은 측정 장치가 조용히 결과를 만들어내고 있는지 여부를 보여줄 수 있습니다. 여기서의 주장은 좁고 테스트 가능합니다. 점수는 바닥(floor), 천장(ceiling), 캐나리 프로브가 모두 예상 값을 반환할 때까지 배포되지 않으며, 프로브 행은 헤드라인 숫자에서 제외되어야 합니다.

프로브되지 않은 패키지가 숨기는 것

대부분의 에이전트 벤치마크는 모델에서 크게 실패하기보다는 내부 시스템(plumbing)에서 조용히 실패합니다. 잘림 버그(truncation bug)나 엄격 일치 규칙(strict-match rule)은 정답을 0으로 만들 수 있으며, 관대한 심사관(lenient judge)은 자신감 있는 헛소리에도 만점을 줄 수 있습니다. 누수(Leakage)는 세 번째 실패 모드로, 참조 답안이 검색 코퍼스(retrieval corpus), 몇 가지 예시(few-shot example), 또는 러너가 한 번도 지우지 않은 이전 세션에 나타나는 경우입니다.

이러한 왜곡은 체계적이기 때문에 더 큰 샘플 크기가 이를 해결하지 못합니다. 시도 횟수를 두 배로 늘리는 것은 편향된 추정치 주변의 간격을 좁히고 잘못된 숫자를 더 권위 있게 보이게 만듭니다. 매주 출판되고 캐주얼하게 비교되는 현재 에이전트 평가 주장은 점수에 의존해야 하는 모든 사람에게 그 실수 비용을 높입니다.

세 가지 프로브 계열 설계하기

바닥 프로브(Floor probes)는 모호하지 않은 정답을 가진 사소하게 해결 가능한 작업으로, 하네스에서 최대 점수보다 낮은 어떤 점수라도 됩니다. 단일 에코 명령어(echo instruction)나 두 개의 피연산자 산술 질문만으로 충분하며, 그레이더 계약이 결정론적(deterministic)인 상태를 유지하는 한도 내에서 그렇습니다. 이들의 임무는 모델 실패로 기록된 출력 파싱 실패, 잘린 완성본, 네트워크 오류를 포착하는 것입니다.

천장 탐지(Ceiling probes)는 산술을 모순 없이 전개하는 과정에서 정수 2가 홀수임을 증명하는 것과 같은 참된 전제 하에서는 만족 불가능한 과제입니다. 0보다 큰 크레딧은 심사관이 정확성 대신 유창한 자신감에 보상한다는 것을 의미합니다. 이러한 탐지(probes)는 비용이 거의 들지 않으며 모델 기반 평가에서 가장 흔한 루브릭 결함을 노출시킵니다.

캐나리 탐지(Canary probes)는 의도적으로 모델의 컨텍스트에서 숨겨진 은닉 참조값(hidden reference)을 가지고 있으며, 이에 대한 기대 점수는 0입니다. 만약 모델이 이 숨겨진 값을 생성한다면, 이는 검색(retrieval), 프롬프트 예시(prompt examples), 또는 공유된 상태를 통해 유출되었거나 심사관이 표면적인 문자열로 일치했기 때문일 수 있습니다. 따라서 캐나리 행은 일반적인 해석을 뒤집는데, 여기서 높은 점수는 모델의 승리가 아니라 장치 자체의 실패를 의미하기 때문입니다.

탐지(probes)가 정직하게 유지되도록 하는 세 가지 구성 규칙이 있습니다. 탐지들은 팩(pack)과 함께 버전 관리되고 고정되어야 하며, 보고되는 총합계에서는 제외되어야 하고, 더 이상 아무도 놀라게 하지 못하는 탐지는 측정할 것이 없으므로 폐기되어야 합니다. 또한 각 탐지에는 서면 근거가 필요하며, 이를 통해 미래의 독자가 어떤 결함을 포착하기 위해 설계되었는지 알 수 있습니다.

오늘 실행할 수 있는 탐지(probe) 하네스

아래 스크립트는 완전하고 실행 가능한 탐지 레이어입니다. call_model 인수는 팀이 이미 사용하는 클라이언트를 감싸는 얇은 래퍼이며, 탐지 실행이 실제 팩과 동일한 클라이언트, 매개변수 및 재시도 정책을 공유하도록 파라미터로 유지됩니다.

# probes.py - 테스트 중인 심사관을 위한 플로어, 천장, 캐나리 탐지
from dataclasses import dataclass

...

이후 두 가지 지표가 모든 게시된 숫자와 함께 전달됩니다. 탐지 무결성(Probe integrity)은 기대치에 맞는 탐지의 비율이며, 실제 팩이 실행되기 전에 반드시 완벽해야 합니다. 심사관 일치도(Judge agreement)는 동일한 루브릭과 다른 샘플링 매개변수로 탐지를 두 번 점수화하여 측정되는데, 설정된 임계값을 초과하는 불일치는 모델의 분산보다는 모호한 루브릭을 가리키기 때문입니다.

무료 모델 접근 방식이 산술에 변화를 주는 곳

프로브 계층(Probe layers)은 실행당 비용은 저렴하지만, 반복(iteration)당 비용은 비쌉니다. 왜냐하면 모든 하네스 변경은 전체 패키지에 대한 새로운 스윕(sweep)을 요구하기 때문입니다. MonkeyCode의 무료 모델 접근 및 무료 서버 옵션은 이 루프에 직접적으로 들어맞습니다: 프로브는 예산 라인이 의심스러워져서 버려지는 대신 모든 실행에서 유지될 수 있으며, 무료 서버 옵션은 전사 기록(transcripts), 프로브 버전, 그리고 심판 출력물(judge outputs)을 노트북 여기저기에 흩어 놓기보다 한 곳에 보관합니다. 또한 이 프로젝트는 무료 등급에서 제공되는 무료 토큰 할당량도 설명하는데, 작성 당시에는 천만 토큰으로 보고되었으나 여기서는 독립적으로 검증되지 않았으므로 아무도 이를 기반으로 계획하기 전에 최신 문서를 확인해야 합니다.

공개 고지: 본 기사는 MonkeyCode의 제품 홍보 활동의 일환으로 준비되었습니다.

한계점 및 건너뛰어도 되는 경우

프로브는 장치(apparatus)를 검증할 뿐, 모델 자체를 검증하지 못하며, 의도된 사용 사례에 대해 사양이 단순히 잘못된 작업을 감지할 수는 없습니다. 캐나리 프로브(canary probe)는 또한 유출된 답변이 팀이 다른 이유로 필요한 코퍼스(corpus)에 합법적으로 존재하는 경우 거짓 양성(false-positive)일 수 있으므로, 이 프로브를 신뢰하기 전에 유출원(leak source)을 식별해야 합니다. 오버헤드도 실제적입니다. 왜냐하면 각 프로브는 전혀 능력 신호(capability signal)를 생성하지 못하는 실행 및 심판 호출을 소모하기 때문입니다.

벤치마크를 한 번만 실행하고, 출력물을 손으로 읽고, 하네스를 절대 재사용하지 않는 팀은 이 내용을 완전히 건너뛰어야 합니다. 왜냐하면 프로브 계층은 반복되는 실행에 걸쳐 효과가 나타나기 때문입니다. 그레이더(grader)를 고정하거나 패키지를 버전 관리할 수 없는 팀은 먼저 그것을 수정해야 합니다. 왜냐하면 프로브는 이미 존재하는 불안정성만을 문서화할 것이기 때문입니다. 하네스 증거 없이 단일 헤드라인 숫자만 발표하는 사람과, 어떤 심판이 그 숫자를 생성했는지 말할 수 없는 사람은 그 숫자를 꾸미려고 하기보다 제거하는 것이 더 낫습니다.

만약 어떤 프로브 레이어가 무료 비용 계층(zero-cost tier)에서 시도해 볼 가치가 있다고 느껴진다면, 유료 용량을 사용하기 전에 첫 번째 스윕(sweep)을 실행해 보기 적절한 장소가 MonkeyCode의 무료 모델과 무료 서버 옵션입니다.