검증 시스템(Verification systems)은 보통 답변을 기록하고 질문은 버립니다.

그것이 바로 허점입니다.

검증자(Verifier)는 입력을 고정하고, 해시 아티팩트(hash artifacts)를 생성하며, 판결에 서명하고, 그 모든 것을 추가 전용 로그(append-only log)에 기록할 수 있습니다. 이 기록은 특정 검사기(checker)가 특정 블롭(blob)에 대해 특정 결과를 생성했음을 증명할 수 있습니다. 하지만 그것이 검사기가 올바른 질문을 던졌음을 여전히 증명하지 못할 수도 있습니다. 술어(predicate) 자체는 기록 외부에 남아 있을 수 있기 때문입니다: 어떤 속성이 테스트되었는지, 어떤 동작 지점에서, 어떤 수락 규칙(acceptance rule) 하에, 어떤 사례 계층(stratum of cases)을 대상으로 했는지 말입니다.

그 누락된 술어가 바로 검증(verification)입니다.

서명은 귀속(Attribution)이다

서명은 주장을 귀속(attributes)시킵니다. 그것은 주장의 선택을 검증(validate)하지는 않습니다.

만약 서명된 기록에 passed라고 되어 있다면, 서명은 판결의 생성자가 해당 비트(bit)를 발행했음을 확립할 수 있습니다. 또한 조작을 가시화할 수도 있습니다. 공개 키(public key), 아티팩트 다이제스트(artifact digest), 그리고 서명된 페이로드(signed payload)가 주어지면, 제3자는 기록이 변경되었는지 확인할 수 있습니다.

이것은 유용합니다. 또한 보기보다 더 중요한 의미를 갖습니다.

"검사기가 실행되었고 조작되지 않았다"와 "검사기가 올바른 것을 검사했다"는 서로 다른 주장입니다. 첫 번째는 암호학적 메커니즘(cryptographic machinery) 내에 들어맞습니다. 두 번째는 서명의 상류(upstream)에 존재합니다. 산술(Arithmetic)로는 그곳에 도달할 수 없습니다.

모델 출력이 검사기에 의해 평가된다고 가정해 봅시다. 로그에는 프롬프트 해시(prompt hash), 출력 해시(output hash), 검사기 버전(checker version), 컨테이너 다이제스트(container digest), 그리고 서명된 판결(signed verdict)이 저장됩니다. 판결은 acceptable이라고 말합니다. 나중에 소비자가 acceptable이 무엇을 의미했는지 묻습니다. 그것이 참조 답변(reference answer)과의 정확한 일치를 의미했나요, 특정 점수 이상의 의미론적 동등성(semantic equivalence)을 의미했나요, 금지된 토큰(forbidden tokens)의 부재를 의미했나요, 스키마(schema)와의 일관성을 의미했나요, 아니면 예외 사항이 있는 비즈니스 규칙을 의미했나요? 만약 그 술어가 고정(pinned)되지 않았다면, 그 기록은 다른 질문에 답하고 있는 것입니다. 그것은 누가 판결에 서명했는지는 말해줍니다. 하지만 그 판결이 반증 가능(falsifiable)했는지는 말해주지 않습니다.

암호학 (Cryptography)은 그 경계를 상류로 이동시킵니다. 그것은 서명된 봉투(signed envelope) 안에 들어간 것을 보호합니다. 그 봉투 밖에 있는 모든 것은 개인적인 판단, 관습, 또는 기억의 영역으로 남습니다. 시스템이 완벽한 서명을 갖추고 있더라도, 서명된 진술이 정말로 중요했던 바로 그 진술이었음을 증명하지 못할 수 있습니다.

이러한 실패는 서명이 최종적인 것처럼 느껴지기 때문에 놓치기 쉽습니다. 서명은 깔끔한 증거 조각을 만들어냅니다. 문제는 명세가 불충분한 (underspecified) 주장에 대한 증거 역시 여전히 명세가 불충분한 증거라는 점입니다.

결과 이후의 술어 선택 (Predicate Selection After the Result)

사후 술어 선택 (Post-hoc predicate selection)은 데이터를 확인한 후에 가설을 선택하는 것과 유사한 소프트웨어적 대응물입니다.

만약 결과가 가시화된 이후에 술어 (predicate)가 작성된다면, 거의 모든 판결을 충족 가능하게 (satisfiable) 만들 수 있습니다. 실패한 출력값은 더 낮은 유사도 임계값 (similarity threshold)을 통과하게 됩니다. 안전 판결은 "허용되지 않는 동작 없음"에서 "이 분류 체계 (taxonomy) 버전 및 심각도 차단 기준(severity cutoff) 하에서의 허용되지 않는 동작 없음"으로 슬그머니 변합니다. 각각의 개별적인 움직임은 합리적으로 들릴 수 있습니다. 하지만 이들이 모이면 검증 (verification)을 끼워 맞추기 (fitting)로 변질시킵니다.

순서가 중요합니다.

결과가 존재하기 전에 선택된 술어는, 지형이 가시화된 후에 선택된 술어와는 다른 증거적 지위 (evidentiary status)를 갖습니다. 바이트는 동일할 수 있습니다. 하지만 타이밍이 기록이 증명할 수 있는 내용을 바꿉니다. 만약 술어가 나중에 나왔다면, 서명된 판결은 가능한 질문들에 대한 선택과 양립할 수 있습니다. 만약 술어가 먼저 나왔다면, 제3자가 해당 시퀀스를 재현하여 불일치를 감지할 수 있습니다.

해결책은 이미 알려진 형태를 띠고 있습니다: 사전 등록 (pre-registration)입니다.

결과가 존재하기 전에 술어를 고정하십시오. 검사기 (checker)가 판결 대상인 아티팩트 (artifact)를 확인하기 전에, 술어의 해시 (hash), 술어 본문, 또는 콘텐츠 주소 지정 참조 (content-addressed reference)를 기록에 넣으십시오. 수락 규칙 (acceptance rule)을 결합할 수 있을 만큼 충분한 데이터를 포함하십시오. 그러면 나중에 판결이 나타났을 때, 로그는 믿음을 요구하는 대신 순서를 보여줄 수 있습니다.

이는 특별한 장치가 필요하지 않습니다. 추가 전용 로그 (append-only log)는 검사기 식별자 (checker identity), 술어 다이제스트 (predicate digest), 동작 지점 (operating point), 수락 규칙 (acceptance rule), 그리고 의도된 입력 클래스 (intended input class)를 포함하는 predicate_registered 항목을 기록할 수 있습니다. 이후의 verdict_emitted 항목은 다이제스트와 로그 인덱스를 통해 해당 술어 항목을 참조할 수 있습니다. 스키마 이름은 협의 가능합니다. 반드시 지켜져야 할 점은, 결과가 술어에 영향을 미치기 전에 술어가 커밋된 객체 (committed object)로서 존재해야 한다는 것입니다.

그러한 순서가 없다면, 로그는 의식(ceremony)만 거행된 채 결론만을 기록하게 됩니다.

동작 지점은 술어의 일부입니다

임계값 (Thresholds) 또한 술어입니다.

흔히 발생하는 오류 모드는 동작 지점을 설정 (configuration)으로 취급하고, 검사의 나머지 부분을 실제 검증기 (verifier)로 취급하는 것입니다. 이러한 분리는 잘못되었습니다. 만약 검사기가 "점수가 최소 0.82일 때 통과"라고 말한다면, 0.82는 질문의 일부입니다. 이를 0.79로 옮기면 시스템은 다른 것을 묻고 있는 것입니다.

이러한 문제는 이질적인 난이도 (heterogeneous difficulty) 사이에서 더욱 악화됩니다.

혼합된 요청 클래스에 적용된 단일 전역 임계값 (global threshold)은 별도로 점수를 매겨야 할 모집단들을 조용히 평균화해 버립니다. 쉬운 사례, 모호한 사례, 적대적 사례 (adversarial cases), 그리고 긴 문맥 사례 (long-context cases)는 동일한 분포를 차지하지 않습니다. 전역 컷오프 (global cutoff)는 여러 계층을 하나의 스칼라 (scalar)로 평탄화하는 단 하나의 동작 지점일 뿐임에도 불구하고, 정확도 수치를 마치 차별의 한계치 (discrimination ceiling)처럼 보이게 만들 수 있습니다.

두 개의 계층에 걸쳐 평가되는 분류기를 생각해 보십시오. 한 계층에서는 점수가 깔끔하게 분리됩니다. 다른 계층에서는 정답과 오답 사례가 겹칩니다. 전역 임계값은 하나의 통과율과 하나의 실패율을 생성합니다. 이 집계된 수치는 검사기가 한계에 도달했다는 인상을 줄 수 있습니다. 사실, 한 계층은 더 엄격한 임계값을 허용할 수 있는 반면, 다른 계층은 다른 규칙이 필요하거나 별도로 보고되어야 할 수도 있습니다. 숨겨진 결정은 이들을 하나로 붕괴시킨 것입니다.

그 결정은 기록에 남아야 합니다.

로그에는 해당 사례가 어느 계층 (stratum)에 속했는지, 어떤 임계값 (threshold)이 적용되었는지, 그 임계값이 어떻게 선택되었는지, 그리고 어떤 수락 규칙 (acceptance rule)이 점수를 소비했는지가 기록되어야 합니다. "점수는 0.81이다"는 관찰 (observation)입니다. "semantic_equivalence_v4 규칙에 따라 이 계층의 임계값이 0.80이므로 수락됨"은 판결 (verdict)입니다.

이것들은 서로 다른 기록입니다.

이는 재현 (replay)을 위해 중요합니다. 제삼자는 점수를 재계산하고, 적용 가능한 동작 지점 (operating point)을 찾아내며, 수락 규칙을 적용하여 동일한 판결에 도달할 수 있어야 합니다. 만약 임계값이 배포 플래그 (deployment flag), 명령줄 오버라이드 (command line override), 노트북 셀 (notebook cell), 또는 서비스 기본값 (service default) 속에 숨겨져 있다면, 재현은 고고학이 되어버립니다. 서명된 판결은 여전히 검증될 수 있을지 모릅니다. 하지만 판단 (judgment)은 그렇지 못할 것입니다.

공유된 결정 규칙은 공유된 운명을 만든다

여러 개의 검사기 (checker)를 실행한다고 해서 자동으로 독립적인 검증이 생성되는 것은 아닙니다.

서로 다른 머신, 빌드, 제공자, 구현체라 할지라도 하나의 수락 규칙을 공유한다면 여전히 하나의 검사기와 다름없을 수 있습니다. 판단이 동일하다면 기질 (substrate)의 다양성은 큰 이득을 주지 못합니다. 공통 모드 고장 (common-mode failure)은 술어 (predicate)에 존재합니다.

이는 이론적인 깔끔함을 따지는 것이 아닙니다. Knight와 Leveson의 1986년 N-버전 프로그래밍 (N-version programming) 실험은 전형적인 경고입니다. 독립적으로 제작된 구현체들이 어려운 입력값 (hard inputs)에 대해 여전히 상관관계가 있는 방식으로 실패했습니다. 어려운 입력값은 모두에게 어렵습니다. 코드 수준의 독립성이 공유된 고장 모드 (failure modes)를 제거하지 못했습니다.

검증 시스템이 판단을 중앙 집중화하면서 실행을 다양화할 때, 동일한 함정을 다시 만들어냅니다.

세 개의 검사기를 상상해 보십시오. 하나는 로컬에서 실행되고, 하나는 호스팅된 환경에서 실행되며, 하나는 별도의 빌드 내부에서 실행됩니다. 각각은 서로 다른 바이너리 (binary)와 서로 다른 서명 키 (signing key)를 가집니다. 세 검사기 모두 동일한 수락 규칙을 호출합니다: 정규화된 유사도 (normalized similarity)가 단일한 전역 임계값 (global threshold)을 초과하면 통과한다. 경계선에 있는 사례들에 대해, 시스템은 세 개의 서명을 갖지만 의견은 하나뿐입니다.

인프라는 다양해 보이지만, 판결은 그렇지 않습니다.

더 강력한 설계는 검사기(checker)별로 술어(predicate)의 정체성을 기록하여 불일치(disagreement)가 의미를 갖도록 만듭니다. 한 검사기는 정확한 구조적 불변량(structural invariant)을 사용할 수 있습니다. 다른 검사기는 계층(stratum)별로 보정된 점수(calibrated score)를 사용할 수 있습니다. 세 번째 검사기는 생성된 변형(variants)들에 대해 단조성(monotonicity)을 확인할 수 있습니다. 만약 이러한 술어들이 독립적으로 고정(pinned)되어 있다면, 불일치는 유용한 무언가를 드러냅니다. 만약 세 가지 모두 동일한 숨겨진 규칙을 감싸고 있다면, 추가 전용 로그(append-only log)는 중복된 신뢰도(redundant confidence)만을 수집하게 될 것입니다.

중복성(Redundancy)은 독립성(independence)이 아닙니다.

멱등성(Idempotency)도 같은 형태를 띱니다. 더 많은 인프라에 걸쳐 동일한 술어를 재시도하는 것은 가용성(availability)에는 좋지만, 정확성(correctness)에 대한 증거로는 약합니다. 만약 질문 자체가 틀렸다면, 멱등한 재생(idempotent replay)은 틀린 답을 깔끔하게 반복할 뿐입니다.

술어를 레코드 필드로 만들기

해결책은 구체적입니다. 술어를 검증 레코드(verification record)의 일급 필드(first-class field)로 만드는 것입니다.

술어를 검사기 코드, 배포 설정(deployment config), 산문 정책(prose policy), 또는 이슈 스레드(issue thread) 속에 묻어두지 마십시오. 레코드는 최소한 네 가지 사항을 결합해야 합니다: 테스트 중인 아티팩트(artifact), 실행한 검사기(checker), 요청된 술어(predicate), 그리고 생성된 판결(verdict)입니다. 술어에는 작동 지점(operating point)과 수락 규칙(acceptance rule)이 포함되어야 합니다. 만약 점수 산정이 계층화되어 있다면, 계층 선택 규칙(stratum selection rule) 또한 그곳에 포함되어야 합니다.

최소한의 레코드는 다음과 같은 내용을 포함할 수 있습니다:

{
  "artifact_digest": "sha256:...",
  "checker_digest": "sha256:...",
...

정확한 형태는 다양할 수 있습니다. 하지만 불변량(invariant)은 변해서는 안 됩니다.

술어는 결과가 나오기 전에 확정(committed)됩니다. 판결은 그 확정된 술어를 참조합니다. 로그는 검사를 실행한 주체의 협조 없이도 재생(replay)할 수 있을 만큼 충분한 정보를 포함해야 합니다.

그 마지막 문구가 바로 테스트 기준입니다.

검사가 실행될 당시 부재했던 제삼자가 로그만으로 판결을 재구성하고 이에 대해 불일치(disagree)를 표할 수 있어야 합니다. 불일치하는 것이 중요합니다. 만약 제삼자가 서명(signature)만을 검증할 수 있다면, 그 레코드는 귀속(attribution)에 관한 것입니다. 만약 제삼자가 판결을 재계산하여 "고정된 규칙에 따르면 이것은 실패했어야 한다"라고 말할 수 있다면, 그 레코드는 반증 가능(falsifiable)합니다.

그것이 기준입니다.

레코드에는 순서(ordering)도 필요합니다. 만약 동일한 추가 전용 로그(append-only log)에 술어 등록(predicate registration)과 판결 발행(verdict emission)이 모두 포함되어 있다면, 검증자(verifier)는 술어 항목이 결과보다 앞선다는 것을 확인할 수 있습니다. 만약 술어가 다른 콘텐츠 주소 지정 시스템(content-addressed system)에 다이제스트(digest) 형태로 저장되어 있다면, 로그에는 여전히 해당 다이제스트에 대한 사전 커밋(prior commitment)이 필요합니다. 그렇지 않으면 술어를 결과 주변에 다시 작성하여 마치 처음부터 그곳에 있었던 것처럼 제시할 수 있기 때문입니다.

여기에는 정직한 한계가 존재합니다. 술어를 고정(pinning)한다고 해서 술어가 올바르게 되는 것은 아닙니다. 잘못된 질문을 고정하더라도 그것은 여전히 잘못된 질문입니다.

고정(pinning)을 통해 얻는 것은 노출(exposure)입니다. 잘못된 질문이 공개되고 귀속(attributable) 가능해지며, 이는 곧 그 질문에 대해 논쟁할 수 있음을 의미합니다. 요구사항과 비교할 수 있게 됩니다. 임계값(threshold)이 계층(strata)을 평탄화했거나, 수용 규칙(acceptance rule)이 하류(downstream)의 누군가가 중요하게 여기는 오류 유형을 무시했기 때문에 검토에서 탈락할 수도 있습니다. 이는 유효한 서명 뒤에 숨은 사적인 결정 규칙(private decision rule)보다 훨씬 더 나은 실패 방식입니다.

현재의 검증 레코드들은 종종 자신들의 해시(hash) 값에 너무 만족해합니다. 이들은 실제 판단(judgment)을 증거 경계(evidence boundary) 밖에 떠다니게 방치하면서 아티팩트(artifacts)만을 보존합니다. 그 결과는 알 수 없는 질문에 대한 서명된 답변이 됩니다.

내일, 검증 로그 하나를 골라 런타임 설정(runtime config), 비공개 메모(private notes), 서비스 기본값(service defaults), 또는 생성자(producer)의 협조 없이 판결을 재현(replay)해 보십시오. 만약 술어(predicate), 임계값(threshold), 계층 규칙(stratum rule), 그리고 수용 규칙(acceptance rule)이 결과가 나오기 전에 모두 레코드에 포함되어 있지 않다면, 그 로그는 누군가가 내린 결론만을 기록하고 있는 것입니다.