모델 스탬프를 기준으로 점수 차이를 비교하지 마십시오

모델 스탬프나 서버 리비전이 변경된 경우, 점수 델타(score delta)가 프롬프트 변경의 증거는 아닙니다. 교체 가능한 모델 엔드포인트를 호출하는 나이틀리 하네스(nightly harness)는 단 하나의 프롬프트 라인을 편집하지 않고도 이러한 변수들을 혼합할 수 있습니다. 기록된 실행은 모델 스탬프와 서버 리비전이 모두 저장된 기준선과 일치할 때까지 그러한 비교를 거부해야 합니다. 그 거부가 바로 회귀(regression) 신호이며, 어떤 grader assertion이 실행되도록 허용되기 전에 표면화되어야 합니다.

팀들은 종종 무료 모델 경로를 어제 후보 모델의 드롭인 대체품으로 취급하고, 새로운 평균 점수를 품질로 간주합니다. 이러한 대체는 비용이 적게 들기 때문에 인시던트 검토, 할당량 일시 중단, 루틴 호스트 유지보수 중에 발생합니다. 낮은 점수는 실제 프롬프트 회귀일 수도 있고, 모델 자체가 약해졌을 수도 있으며, 토큰화가 변경된 서버 이미지 때문일 수도 있습니다. 식별자 스탬프(identity stamp) 없이는 이 세 가지 원인이 하나의 숫자로 붕괴되어 온콜 엔지니어에게는 스택 트레이스(stack trace)조차 남기지 않습니다.

이전의 검사들은 이미 diff가 신뢰되기 전에 피처(fixture), grader, 케이스 슬롯을 고정합니다. 이러한 고정 장치들은 움직이는 루브릭(rubric)이 역사를 다시 쓰지 못하게 막지만, 완료본을 생성한 모델 자체를 이름 붙여주지는 않습니다. 피처 해시(fixture hash)는 안정적으로 유지될 수 있지만 엔드포인트가 조용히 다른 가중치 세트(weight set)로 라우팅될 수 있습니다. 누락된 필드는 모델 스탬프이며, 이는 점수로부터 추론되는 것이 아니라 피처 해시 옆에 저장되어야 합니다.

diff를 거부할 수 있는 기록

실질적인 해결책은 매일 밤 실행(nightly run)과 모든 수동 재실행 시 함께 전송되는 세 부분으로 구성된 레코드입니다. 케이스 매니페스트(case manifest)는 골든 입력값, 예상 범위(expected envelopes), 그리고 정규 파일 바이트에 대해 계산된 콘텐츠 해시를 나열합니다. 후보 어댑터(candidate adapter)는 완료본과 호스트가 보고하는 모델 식별자 및 서버 리비전을 반환합니다. 격리 단계(quarantine step)는 매니페스트 해시, 모델 스탬프, 그리고 서버 리비전이 모두 기준선 행과 일치할 때만 점수 델타를 계산합니다.

스탬프를 습식 실험실의 시약병 로트 번호라고 생각해 보세요. 두 개의 평가가 하나의 프로토콜 카드를 공유할 수 있지만, 밤사이에 시약병이 교체되었기 때문에 여전히 의견 불일치가 발생할 수 있습니다. 양쪽 로트 번호가 노트북과 일치하기 전까지는 그 불일치를 방법론 개선으로 출판하지 않을 것입니다. 프롬프트 평가(prompt eval)도 같은 배려를 받아야 합니다. 왜냐하면 무료 호스트는 스코어보드에 통지하지 않고 병을 교체할 수 있기 때문입니다.

아래에 표시된 매니페스트는 실제 라이브 평가 호스트에서 캡처된 생산 추적 기록이 아니라 제안 아티팩트(proposal artifact)입니다. 각 케이스는 모델이 볼 수 있는 입력과 호출 반환 후에만 채점자(grader)가 볼 수 있는 예상 엔벨로프(expected envelope)를 가집니다. 프롬프트에서 골드(gold)를 제외하는 것은 별도의 제어이며, 이 메모는 그 논쟁을 다시 여는 것이 아닙니다. 새로운 요구 사항은 파일 바이트가 해시된다는 것이므로, 예상 필드의 조용한 수정이 모델 교체 안에 숨어 있을 수 없습니다.

{
  "suite": "envelope-v3",
  "cases": [
...

어댑터 계약(adapter contract)은 검토자가 새로운 프레임워크를 채택하지 않고도 동일한 확인 작업을 재구현할 수 있을 만큼 작게 유지됩니다. 조작된 스탬프는 서로 다른 실행들을 비교 가능하게 보이게 할 것이므로, 생략된 호스트 식별자(host identifier)는 알려지지 않은 상태로 남아 있어야 합니다. '알려지지 않음'은 어제 모델이 여전히 연결되어 있다고 가장하는 조용한 기본값(silent default)이라기보다는 실패한 격리(failed quarantine)를 의미합니다. 다음 스니펫은 실행되지 않은 제안 코드이며, 네트워크 호출을 수행하지 않고 로컬 파일만 해시합니다.

#!/usr/bin/env python3
"""제안 하네스: 스탬프가 다르면 점수 차이 거부. 측정된 실행 아님."""
import hashlib
...

로컬 확인은 기록된 모델 스탬프에서만 다른 두 개의 고정 파일(fixture files)을 사용합니다. 아래 명령은 해당 크로스-모델 쌍에 대해 격리(quarantine)가 작동할 때 상태 2로 종료되어야 합니다. 상태 0은 세 가지 스탬프 필드가 일치하고 숫자 델타가 표준 출력으로 인쇄되었음을 의미합니다. 어느 쪽의 종료 상태도 프롬프트 자체가 개선되었는지, 퇴보했는지, 아니면 의미적으로 동일하게 유지되었는지를 주장하는 것은 아닙니다.

기준선(baseline) 검토를 통과한 행은 아래 객체와 같을 수 있으며, 이때 passed는 정수형으로 저장됩니다. passed를 정수형으로 저장하면 나중에 계산되는 delta가 판단의 문단이 아니라 뺄셈 연산이 됩니다. 모델 스탬프(model stamp)는 호스트 응답에서 복사된 불투명한 문자열이며, 하네스(harness)가 선택한 별명이 아닙니다. 만약 호스트가 같은 마케팅 이름에 대해 나중에 다른 문자열을 반환하면, quarantine는 그 문자열을 새로운 로트(lot)로 취급합니다.

{
  "manifest_hash": "recorded-sha256",
  "model_stamp": "host-reported-id",
...

만약 기준선 passed 플래그가 1이고 후보(candidate)의 passed 플래그도 1이지만, 모델 스탬프는 변경되었다고 가정해 봅시다. 이 플래그들을 단순하게 빼면 결과는 0이 되어 차트를 보는 사람에게 안정성처럼 보일 것입니다. 하지만 quarantine는 대신 null delta를 반환합니다. 왜냐하면 서로 다른 스탬프에 걸쳐 일치하는 점수가 안정성의 증거가 아니기 때문입니다. 표시되는 0은 이 특정 하네스가 생성할 수 있는 가장 오해의 소지가 큰 결과였을 것입니다.

후보가 manifest_hash는 유지하지만 model_stamp를 변경하면, 출력된 결정(decision) 이름이 해당 필드를 명시하고 delta를 null로 설정합니다. 이 null 값은 대시보드에서도 살아남아야 합니다. 왜냐하면 null을 0으로 강제 변환하는 것은 quarantine 상태를 숨기고 버그를 재현하기 때문입니다. reasons 리스트는 null 옆에 저장해야 하며, 점수가 임계값을 넘었을 때가 아니라 comparable이 false일 때 경고를 발생시켜야 합니다. 임계값 경고는 실행들이 비교 가능(comparable)했다고 가정하는데, 이것이 바로 이 하네스가 테스트하기 위해 존재하는 가정이기도 합니다.

동일한 거절 사유는 서버 리비전만 변경되고 모델 마케팅 문자열은 그대로 유지될 때도 적용됩니다. 새로운 이미지 다이제스트(image digest)는 광고되는 모델 이름이 일정하게 유지되더라도 토크나이저, 타임아웃 또는 도구 스키마를 변경할 수 있습니다. 리비전 필드(revision field)가 존재하는 이유는 이러한 종류의 변화가 프롬프트 수정처럼 위장하는 것을 방지하기 위해서입니다. 호스트 비용(Host cost)은 별개의 축이며, 어댑터를 실행하기에 더 저렴한 장소가 정체성을 고정시키지는 않습니다.

공개 정보: 이 문서는 MonkeyCode의 제품 홍보 활동의 일환으로 작성되었습니다. MonkeyCode는 운영자에 의해 무료 모델 접근 및 무료 서버 옵션을 제공하는 오픈 소스 프로젝트로 설명됩니다. 이러한 두 가지 가용성 주장은 운영자가 제공한 것이며, 후보 어댑터가 야간 패스를 위해 충분히 저렴한 호스트를 필요로 하기 때문에 중요합니다. 정확한 토큰 허용량, 모델 식별자, 하드웨어 및 제공 기간은 주요 문서가 이 초안에 첨부되지 않았기 때문에 생략되었습니다.

제안 스크립트는 세 개의 스탬프 필드가 일치하고 숫자 델타(delta)가 출력되었을 때만 상태 0을 반환합니다. 상태 2는 격리(quarantine)가 발동되었다는 의미이며, 이는 예상치 못한 프로세스 충돌이라기보다는 성공적인 탐지입니다. 래퍼(wrapper)는 상태 2를 페이지로 취급해야 하며, 누락된 입력 파일은 별도의 운영 오류로 취급해야 합니다. 이 두 가지 결과를 하나의 경고 규칙 안에 혼합하면 온콜 로테이션이 해당 페이지를 무시하도록 학습될 것입니다.

점수가 평평하게 유지될 때는 특히 사일런트 회귀(Silent regressions)가 발생하기 쉽습니다. 왜냐하면 평평한 차트는 검토자를 불러내지 못하기 때문입니다. 패스 카운트를 보존하는 모델 교체는 스탬프 비교가 차트가 그려지기 전에 실행되지 않으면 눈에 띄지 않습니다. 이것이 바로 결정 객체(decision object)가 두 개의 '통과' 플래그(passed flags)가 우연히 동일하더라도 이유 목록(reasons list)을 가지고 있는 이유입니다. 차트는 나중에 여전히 그려질 수 있지만, 격리가 이미 비교 가능하다고 표시한 행들로부터만 그럴 수 있습니다.

유용한 야간 흐름(nightly flow)은 네 가지 검사를 고정된 순서로 유지하며, 그중 어느 것도 모델 품질에 대한 슬로건이 아닙니다. 먼저 매니페스트를 해시하고, 이 해시가 기준선 인덱스(baseline index)에 없을 경우 실행을 거부합니다. 두 번째로 후보 어댑터(candidate adapter)를 호출하고, 완료가 실패하더라도 호스트가 보고한 모델 스탬프와 서버 리비전(server revision)을 영속화합니다. 세 번째로 저장된 완료 기록(completion)의 등급을 매기고, 마지막으로 격리(quarantine)를 실행하여 실행 결과가 비교 가능하지 않을 경우 사람에게 알립니다.

이러한 검사들은 어댑터 언어보다 더 중요하며, 셸 래퍼(shell wrapper)는 수동 재실행 후에도 동일한 결정을 호출할 수 있습니다. 각 후보 기록을 새 경로에 작성하고, 사람이 두 스탬프와 델타(delta)를 모두 승인한 후에만 승격시켜야 합니다. 자동화가 실행 파일을 추가할 수는 있지만, 자동화가 스스로 새로운 로트 번호(lot number)를 부여해서는 안 됩니다. 사람은 여전히 두 스탬프를 읽은 후 참조 행(reference row)을 대체하도록 허용된 유일한 단계입니다.

원시 파일 바이트의 콘텐츠 해시는 편집자가 새 줄을 다시 쓰거나 매니페스트 내부의 키 순서를 재배열할 때 변경됩니다. 이러한 민감도는 의도적이며, 조용한 형식 지정 과정(formatting pass)만으로도 사람이 건너뛸 것으로 예상되는 필드를 변경할 수 있기 때문입니다. 만약 여러 기기에서 안정적인 해시가 중요하다면, 해싱하기 전에 JSON을 표준화(canonicalize)하고 그 표준 바이트를 저장해야 합니다. 제안 스크립트는 파일이 저장된 대로 해시하므로, 다른 줄 끝 문자(line endings)는 바이트가 일치할 때까지 격리됩니다.

정확한 엔벨로프가 증명하지 못하는 것들

정확한 엔벨로프 동등성(Exact envelope equality)은 미묘한 의역을 실패로 간주하며, 예상되는 키를 여전히 포함하고 있는 유해한 완료 기록도 놓칩니다. 이 접근 방식은 개방형 글쓰기 품질, 선호도 순위 지정 또는 두 번째 모델을 심사위원으로 필요로 하는 모든 등급자에게 잘못된 도구입니다. 호스트가 안정적인 식별자를 보고할 수 없는 경우에도 잘못된 도구인데, 왜냐하면 모든 실행이 격리되고 페이지는 노이즈가 되기 때문입니다. 고정된 케이스 매니페스트(case manifest)를 갖지 못한 팀은 그 파일을 먼저 구축해야 합니다. 움직이는 케이스 세트(moving case set)에 대한 스탬프도 여전히 읽을 수 없는 델타를 생성하기 때문입니다.

이미 하나의 고정된 모델 내부에서 이미 차이를 계산하는 팀의 경우, 두 개의 스탬프 필드를 재구축할 필요 없이 추가할 수 있습니다. 이전 행에는 'unknown' 문자열을 채우고, 새로운 기준선이 관찰(observation) 하에 기록될 때까지 'unknown'은 비교 불가로 간주하십시오. 기억에서 추측한 마케팅 이름을 채워 넣지 마십시오. 왜냐하면 추측된 스탬프는 비교할 수 있다는 잘못된 권한을 생성하기 때문입니다. 누락된 스탬프는 정직한 차단(honest block)이지만, 추측된 스탬프는 원래의 버그를 재도입하는 조용한 방법이 됩니다.

만약 현재 기록에 호스트 식별자(host identifier)가 이미 저장되어 있다면, 두 개의 저장된 행을 비교하여 서버 이동이 해당 문자열을 변경했을지 확인하십시오. 한 번의 비교만으로 지난주 야간 작업(nightly job)에서 격리(quarantine)가 발동되었는지 여부를 알 수 있습니다. 이 점검은 새로운 루브릭(rubric), 새로운 공급업체(vendor), 또는 어떤 모델이 더 좋다는 주장을 요구하지 않습니다. 단지 차트에 이미 있는 점수가 단일 로트 번호(lot number) 하에서 획득되었는지를 물을 뿐입니다.