Post four에서 나는 내 이메일 분류기(classifier)가 점수를 매기는 네 가지 특징인 신뢰도 (confidence), 발신자 신뢰도 (sender trust), 가역성 (reversibility), 긴급성 (urgency) 중에서 신뢰도 (confidence)가 이질적이라고 주장했다. 신뢰도는 모델 자신의 의견 외에는 외부 소스가 없는 유일한 특징이기 때문이다. 그런데 댓글 섹션이 포스트보다 더 나은 일을 해냈다. 네 명의 사람들 — @jugeni, @txdesk, @taekim, 그리고 @nazar_boyko — 이 느슨한 아이디어를 가져와 하나의 명세 (spec)로 탈바꿈시켰다. 이 포스트는 그들에게 공을 돌리는 해당 명세이며, 현재 리포지토리 (repo)의 이슈 (issues)로 등록되어 있다.

제대로 기술된 원칙

특징들의 소스가 모델로부터 독립적인지 여부에 따라 분류하라. 그리고 그것들을 기준으로 게이트 (gate)를 설정하라. 스스로 작성한 특징은 컨텍스트 (context)로만 취급하고, 결코 권한 부여 (authorization)로 취급하지 마라. 이것이 @txdesk의 문장이었으며, 이는 이메일 사례를 완전히 넘어선다. 이는 모델이 점수를 매기는 모든 결정에 적용되는 규칙이다.

포스트 four에서 내가 틀렸던 부분은 신뢰도 (confidence)를 "타이브레이커 (tiebreaker)"라고 부른 것이다. @jugeni가 이를 바로잡았고, 그 교정은 매우 중요하다. 신뢰도는 약한 신호로 격하되는 것이 아니라, _역전 (inverts)_된다. 스스로 평가한 신뢰도는 적대적 입력 (adversarial input)에서도 협력적 입력 (cooperative input)에서와 동일한 계산적 형태를 가지며, 그 동일성이 바로 확신에 찬 환각 (confident hallucination)의 정의이다. 신뢰할 수 있는 발신자로 읽히는 정교한 사칭은 정확히 높은 신뢰도, 높은 발신자 신뢰도, 가역적으로 보이는 이메일이다. 따라서 협력적 입력에서 신뢰도는 풍경과 같지만, 적대적 입력에서 그것은 반대 증거 (counter-evidence)가 된다. 동일한 숫자가 게이트의 나머지 부분이 무엇을 보느냐에 따라 의미가 뒤바뀐다. 그것은 타이브레이커 (tiebreaker)가 될 수 없다. 왜냐하면 당신이 그것을 가장 신뢰하고 싶을 때 바로 그 시점에 그것이 틀리기 때문이다.

배선 (The wiring)

게이트(gate)는 세계에 고정된(world-anchored) 특징들만을 결정합니다. 관찰된 발신자 이력에 근거한 senderTrust, 액션 유형 조회(action-type lookup)에서 가져온 reversibility — 이 두 가지 모두 모델이 아닌 런타임(runtime)에 속합니다. 분류기(classifier)는 제안하고, 런타임은 모델이 작성할 권한이 없는 사실들을 바탕으로 중재합니다.

신뢰도(Confidence)는 다른 역할, 즉 카나리(canary) 역할을 맡게 됩니다. 게이트가 결정을 내린 후, 신뢰도를 게이트의 결론과 비교합니다. 만약 두 값이 일치하면 침묵합니다. 만약 신뢰도는 높은데 게이트가 거부했다면 — 그것이 바로 당신이 원하는 사후 분석(post-mortem) 대상이며, 이는 아무도 읽지 않는 로그 한 줄이 아니라 분류(triage) 큐로 전달됩니다. @jugeni의 프레임워크에 따르면: 신뢰도가 게이트를 읽는 것이지, 그 반대가 아닙니다. 이를 통해 모델이 스스로 작성한 수치가 투표에 영향을 미치지 않도록 차단하며, 불일치를 감사(audit) 가능한 상태로 전환합니다.

한 가지 구현 세부 사항이 이 모든 것을 증명 가능하게 만듭니다: 결정 추적(decision trace) 내에서 런타임 확증자(runtime corroborator)를 이름이 지정된 외부 컨텍스트(external-context) 객체로 가져오는 것입니다. 모델은 이를 읽을 수는 있지만, 쓸 수는 없습니다. 이것이 바로 결정이 모델 외부의 무언가에 고정되었다는 것을 사후에 증명할 수 있게 해주는 핵심이며, 평가(eval)가 실질적인 힘을 갖게 되는 지점이기도 합니다.

신념을 숫자로 바꾸는 평가 (The eval that turns a belief into a number)

Post four의 솔직한 결론은 "바닥(the floor)이 우리를 구한다"는 것은 측정되기 전까지는 하나의 신념일 뿐이라는 것이었습니다. @jugeni와 @taekim이 이 측정을 설계했으며, 이는 제가 구축했을 것보다 훨씬 더 정교합니다.

임계값(threshold, "사칭이 AUTO에 도달했는가")을 측정하지 마세요. 델타(delta, 차이)를 측정하세요: 즉, (신뢰도(confidence) − 세계 기반 상호 확인(world-anchored-corroboration))의 편차가 분포 내에서 적대적(adversarial) 샘플과 협력적(cooperative) 샘플을 분리해내는지 측정해야 합니다. 협력적 세트는 홀드아웃(held-out)된 알려진 안전한 발신자들로 구성되며, 이것이 당신의 하한 분포(floor distribution)가 됩니다. 적대적 세트는 의도적으로 높은 신뢰도와 낮은 상호 확인(thin-corroboration)을 갖도록 수작업으로 제작되며 — 이것이 제가 (과거에) 건너뛰었을 훈련 방식입니다 — 신뢰도 측면에서 협력적 세트와 일치하도록 맞춥니다. 만약 적대적 세트의 신뢰도가 협력적 세트보다 낮다면, 해당 평가는 어딘가에서 신호(signal)를 유출하고 있는 것이며, 그 편차는 의도한 대로 측정되지 않고 있는 것입니다.

전형적인 사례: 런타임 가역성 테이블(runtime reversibility table)이 내부 전용으로 표시한 동작에 대해, 0.92의 AUTO 점수를 기록하는 발신자 사칭 사례입니다. 그 지점이 바로 하한(floor)이 모든 역할을 수행하고 점수(score)는 아무런 역할도 하지 못하는 정확한 모퉁이(corner)입니다.

이 문제는 이메일뿐만이 아닙니다

@taekim은 이 원칙이 검색(retrieval) 분야로도 그대로 일반화된다는 점을 지적했습니다. 검색된 답변에 대한 모델의 신뢰도가 높은 이유는 그것이 근거(grounded)가 있기 때문이 아니라, 단지 해당 청크(chunk)가 그럴듯하게 들리기 때문입니다 — 이는 동일한 자기 참조적 함정(self-referential trap)입니다. 검색된 청크들 간의 인용 중복(citation overlap), 지식 그래프(knowledge graph)와의 엔티티 수준 일관성(entity-level consistency): 이것들이 바로 모델이 스스로 작성할 수 없는 상호 확인자(corroborators)들입니다. '높은 신뢰도 + 외부 신호의 희박함 또는 모순'은 해당 도메인에서도 카나리(canary, 경고 신호) 역할을 합니다. 모델이 결정을 위해 특징(features)에 점수를 매길 때마다 동일한 원칙이 적용됩니다.

현재 상태

이 중 어느 것도 아직 배포되지는 않았습니다. 현재 신뢰도는 여전히 0.85에서 AUTO를 제한(gate)하고 있으며, 이를 안전하게 만드는 것은 그 아래에 있는 결정론적 하한(deterministic floor)입니다. 즉, AUTO의 자율 실행(autonomous execution)은 꺼져 있으며, 세 가지 비가역적 동작(irreversible actions)은 점수와 상관없이 실패 시 차단(fail closed)되도록 설계되어 있습니다. 이것은 실시간 취약점이 아니라, AUTO가 실제로 작동할 때를 대비한 설계 강화(design hardening) 과정입니다. 이 스레드가 참조할 수 있도록 두 가지 사항을 이슈(issue)로 등록해 두었습니다: 세계 기반 게이트 + 카나리(world-anchored gate + canary)와 델타 평가(delta eval)입니다.

네 개의 포스트와 댓글 섹션을 거친 후, 논지는 처음보다 더 작고 날카로워졌습니다: 모델을 인지 계층 (perception layer)에 유지하고, 모델이 직접 작성할 수 없는 것에 대해 게이트 (gate)를 설정하며, 모델 스스로에 대한 의견은 카나리 (canary)로 취급하되 결코 투표 (vote)로 간주하지 마십시오. 답글에서 저보다 더 나은 설계를 제안해 주신 모든 분께 감사드립니다 — 계속 이어가고 싶다면 리포지토리는 공개되어 있습니다: github.com/k08200/klorn.