다이어그램을 보여주세요

벤더가 통합 가이드를 전달합니다. 이 가이드는 세 개의 열로 구성되어 있습니다: 시스템이 방출하는 신뢰도 값, 각 수준에서 취해야 할 조치, 그리고 각 호출에 드는 비용입니다. 0.8에서 차단선이 있고, 0.6 미만일 경우 에스컬레이션(escalate)해야 한다는 메모가 붙어 있습니다. 이 문서를 작성한 사람은 유능하고 시스템은 작동합니다.

질문 하나를 합니다: 신뢰도 다이어그램을 보여주세요.

평균 정확도가 아닙니다. 시스템이 얼마나 많은 호출을 하는지 보여주는 차트도 아닙니다. 한 축에는 보고된 신뢰도를, 다른 축에는 시스템이 실제로 맞았던 빈도를, 그리고 각 구간 뒤에 있는 사례 수를 표시하는 플롯입니다. 이 자료는 다음과 같이 말합니다: 이 것이 0.9라고 했을 때, 얼마나 자주 맞았는지; 0.6이라고 했을 때는 얼마나 자주 맞았는지; 그리고 각각 몇 번씩 그렇게 말했다는 것입니다.

만약 그러한 플롯이 존재하지 않는다면, 당신은 측정을 받은 것이 아닙니다. 당신은 숫자가 들어간 디자인 의견의 세 개의 열을 받은 것일 뿐입니다. 그 지침이 여전히 좋을 수도 있습니다. 하지만 정책을 수립하려고 했던 단 하나의 것 — 0.9라는 것이 무엇을 의미하는지 — 는 어느 누구도, 어떤 시점에서도 어디에도 확립되지 않았습니다. 그리고 당신은 여전히 그것을 프로덕션 환경에서 켜게 될 것입니다. 왜냐하면 그 숫자가 바로 거기에 있고, 시스템이 사용하는 다른 숫자들처럼 보이기 때문입니다.

그것이 전체 불만 사항이며, 우리를 포함한 모든 심사관에게 적용됩니다. 곡선(curve) 뒤에 신뢰도 값이 없는 것은 판단이 아닙니다. 그것은 소수점을 가진 느낌일 뿐입니다.

숫자가 주장하는 바

신뢰도 값을 천천히 읽어보세요. 시스템이 0.9를 보고할 때, 이는 이와 비슷한 사례들 중에서 약 100개 중 90개가 자신이 말한 대로 된다고 주장하는 것입니다. 그것은 빈도에 대한 사실적인 주장이며, 빈도는 셀 수 있습니다. 인터페이스의 어떤 부분도 누군가 계산했는지 알려주지 않습니다.

주장(claim)이 정확도(accuracy)와 같지 않기 때문에, 둘을 서로 바꿔치기하는 것이 너무 조용하게 잘못됩니다. 평균 점수는 “우리가 테스트한 모든 것 중에서 이 것이 얼마나 자주 맞는지”에 답합니다. 반면, 보정 곡선(calibration curve)은 “이 특정 숫자가 오류율 측면에서 나에게 무엇을 제공하는가”에 답합니다. 오직 후자만이 컷오프(cut-off) 지점에서 사용 가능하며, 제품에 탑재되는 경우는 거의 아닙니다.

두 시스템이 동일한 정확도를 보고할 수 있지만, 사용자에게는 매우 다른 가치를 가질 수 있습니다. 한 시스템은 88%의 시간 동안 맞고 자신이 모르는 경우를 솔직하게 알려줍니다. 다른 시스템은 88%의 시간 동안 맞지만 모든 것에 대해 0.95라고 보고합니다. 전자는 라우팅(routed)될 수 있지만, 후자는 할 수 없습니다. 왜냐하면 상수는 케이스들을 분리할 수 없기 때문입니다. 그 기반으로 만들어진 게이트는 매번 똑같이 작동하며, 이는 곧 그 게이트가 장식품에 불과하다는 의미입니다. 점수로는 이 둘을 구별할 수 없었습니다. 오직 곡선만이 할 수 있었습니다.

보정(Calibration)은 모델이 아닌 모집단(Population)의 영역

여기서부터 “다이어그램을 보여주세요”라는 요청이 조달 의식(procurement ritual)에서 실제 질문으로 바뀌는 부분이 나옵니다.

저희가 자체적으로 운영하는 JudgeBench에서는, 공식 심사 프로토콜에 따라 620개의 판단을 수행했으며, 첫 번째 판결이 실패한 6쌍의 사례를 숨기지 않고 공개했을 때, 저희가 보고한 90% 이상의 신뢰도(confidence)로 호출된 건들은 **99.6%**의 시간 동안 정확했고, 80–90% 대역의 호출은 **94.0%**의 시간 동안 정확했습니다.

같은 인터페이스와 같은 점수 규칙을 사용했지만, 다른 코퍼스(corpus)를 사용한 ContextualJudgeBench에서는, 쌍별 프로토콜(pairwise protocol)에 따라 전체 공식 세트를 자체 운영했습니다. 이 프로토콜에서 한 쌍이 올바르다고 간주되려면 두 가지 제시 순서가 모두 정확하게 판단되어야 합니다. (이것이 무작위 하한선(random floor)이 50%가 아닌 25%인 이유입니다.) 플랫폼의 반복적인 오류로 인해 12개의 순서를 제외하고, 그 제외 사실을 결과 옆에 명시했을 때, 저희의 일관된 정확도는 **67.1%**로, 이는 벤치마크의 공식 기준값인 65.4%와 비교했을 때입니다. 이 벤치마크에서 의도적으로 구성한 근접한 동점(near-tie) 분할 지점은 **46–60%**에 위치합니다.

이제 두 실행 결과를 나란히 놓고 비교해 보세요. 심사위원도 같고, 신뢰 구간(confidence field)도 같습니다. 두 번째 코퍼스에서는 가장 높은 보고된 밴드 값이 첫 번째 코퍼스에서보다 현저하게 가치가 떨어집니다. 그 벤치마크는 실제로 매우 근접한 쌍을 포함하도록 설계되었으며, 근접한 쌍으로 가득 찬 모집단은 '90% 확신'이라는 것이 지난주에 사던 것과 같은 가치를 제공하지 못하는 곳입니다.

이러한 격차(gap)가 발생했다고 해서 아무도 잘못 행동해서 그런 것은 아닙니다. 이것은 산술적인 과정에서 자연스럽게 도출되는 것입니다. 보정(Calibration)은 모델의 속성이자 모집단의 속성입니다. 이는 입력으로 제공하는 사례들의 혼합, 그중 실제로 결정 가능한 사례가 얼마나 되는지, 그리고 기본 비율(base rate)이 어떻게 자리 잡는지에 달려 있습니다. 이 수치는 지연 시간(latency)이나 가격처럼 소프트웨어 자체의 고정된 속성이 아닙니다. 이것은 분포(distribution)를 측정한 것이며, 그 분포는 부분적으로 사용자의 책임입니다.

이는 애초에 해당 공급업체로부터 얻고자 했던 세 가지 핵심 사항을 제공합니다. 이 곡선은 귀하의 트래픽이 아닌 코퍼스에 대한 주장입니다. 이 곡선은 귀하가 부분적으로 설명할 수는 있지만 완전히 검사할 수 없는 코퍼스에 대한 주장입니다. 그리고 이 곡선은 측정된 모델 버전에 따라서만 최신성을 유지합니다. 인터페이스는 변하지 않았지만 재훈련된 모델은 이를 조용히 무효화시킵니다.

다이어그램이 포함해야 할 내용

모든 차트가 증거인 것은 아닙니다. 세 가지 세부 사항이 가장 큰 비중을 차지하며, 이들이 빠져 있다는 사실 자체가 헤드라인 수치보다 더 많은 정보를 제공합니다.

빈 경계(bin edges)와 각 빈의 개수. 사례 4개를 가진 빈은 축 레이블이 붙은 일화에 불과합니다. 사례 300개를 가진 빈은 비율입니다. 대부분 출판되는 보정 요약본들은 이 둘 중 어느 것도 보여주지 않으며, 이는 독자가 어떤 것을 읽고 있는지 알 수 없게 만듭니다.

실패 사례에 대한 설명. 어떤 케이스가 제외되었는지, 재실행되었는지, 폐기되었는지, 또는 대치(imputed)되었는지, 그리고 각각 몇 건인지 명시해야 합니다. 저희는 결과를 각주로 처리하는 대신 결과 옆에 다음과 같이 제시합니다: JudgeBench에서 첫 판결이 실패한 6쌍의 사례, ContextualJudgeBench에서 전체 2,000쌍 공식 세트 중 재실행되어 제외된 12개의 명령입니다. 어떤 항목을 제외했는지 명시하는 프로토콜은 그 위에 있는 행들을 얼마나 신뢰해야 하는지 알려줍니다. 제외할 것이 없다고 명시하는 프로토콜은 보통 보고할 내용이 없었기 때문일 가능성이 높습니다.

레이블 세트, 모집단, 그리고 날짜. 보정 곡선(calibration curve)은 측정된 코퍼스(corpus)와 그 시점이 없으면 의미가 없습니다. 이 디테일 때문에 현재 유통되는 거의 모든 다이어그램—저희 것도 포함하여—이 무효화되는데, 이는 곡선을 제품의 일반적인 속성이 아닌 특정 대상에 대한 누군가의 측정치로 만들기 때문입니다.

단일 숫자 요약(single-number summary)에는 적용되는 하나의 주의사항이 있습니다: 스칼라 값은 당신이 중요하게 생각하는 유일한 구간(bin)을 숨길 수 있습니다. 코퍼스 전체에 걸쳐 평균화된 집계 오류 수치(aggregate error figure)는 평균적인 성능에 대해서만 알려줄 뿐, 당신의 임계값(threshold)이 실제로 어느 구간에 위치하는지에 대해서는 아무것도 말해주지 않습니다. 구간표(bin table)가 진정한 산출물이며, 단일 숫자는 결정이 내려져서는 안 되는 편리한 수단입니다.

저희는 동일한 자(ruler)로 측정해 달라고 요청합니다

이 모든 내용을 다른 누군가의 제품에 대한 반론으로 읽기 쉬우므로, 그런 해석은 배제하겠습니다.

TypeSafe는 Jev에 대해 신뢰성 다이어그램(reliability diagram)이나 예상 보정 오류(expected calibration error)를 발표한 적이 없습니다. 이는 공개적으로 이용 가능한 정보에 대한 진술일 뿐, 내부적으로 사실인지를 말하는 것은 아닙니다. 그들이 권장하는 사용법은 임계값 라우팅(threshold routing)—즉, 특정 선 위에서 작동하고 나머지는 사람이나 더 느린 심사관에게 보내는 것—이며, 이 권장 사항은 타당합니다. 이는 단순히 신뢰성 문제를 의도된 배포의 핵심 경로에 직접 배치하며, 그 과정에서 곡선 데이터가 미발표 상태로 남게 만듭니다.

제가 그 문장을 자신 있게 쓸 수 있는 이유는, 우리에게도 똑같은 자가 겨누어져 있고, 특정 지점에서 더 나쁘게 읽히기 때문입니다. 저희 자체 벤치마크에서 나온 근소한 동점(near-tie) 분할 값은 46–60%로 나타납니다. 이것이 저희가 가진 가장 좋지 않은 수치이며, 저희 페이지에 실려 있고, 다른 행들이 의미를 갖게 만드는 바로 그 수치입니다. 오직 최고의 행만 발표하는 공급업체는 당신에게 어느 행을 읽어주길 원하는지 알려줬기 때문입니다.

따라서 이 초대는 문자 그대로의 것이며, 수사적인 꾸밈이 아닙니다. 저희 빈(bins)은 카운트와 함께 발표됩니다. 저희 제외 항목(exclusions)도 번호가 매겨져 있습니다. 근소한 동점 역시 좋은 행들과 함께 발표됩니다. 만약 여러분이 저희 곡선(curve)을 가져다가 자신만의 트래픽, 자신만의 빈 경계값(bin edges), 그리고 자신만의 결과로 다시 그리는데 밴드(bands)가 유지되지 않는다면, 그것은 저희 어떤 행보다도 더 유용한 결과입니다. 그리고 저희는 그것을 얻고 싶어 합니다. 저희는 이 다이어그램을 요청받았고, 발표했고, 똑같은 자를 가진 누구라도 여기서부터 먼저 적용해야 합니다.

실질적인 버전으로 말씀드리자면, 만약 당신이 서명하는 사람이라면: 고려하고 있는 어떤 심사위원에게든 플롯(plot), 카운트, 제외 항목, 그리고 날짜를 요청하십시오. 밴드 값은 다른 누군가의 평균값에 대비하기보다 자신만의 오차 예산(error budget)에 맞춰 가격을 책정하십시오. 그런 다음 그 기준점(cut-off)을 누가 선택했는지 이름과 함께 기록하십시오. 왜냐하면 임계값(threshold)은 설정값이 아니라 약속이기 때문입니다.

그리고 만약 다이어그램이 존재하고 평범해 보인다면—부드러운 중간 지점과 '여기가 근접함'이라고 말하는 낮은 밴드를 가진 정직한 곡선이라면—그것을 실망으로 여겨서는 안 됩니다. 그것이야말로 의사결정 도구가 줄 수 있는 가장 가치 있는 것입니다. 그것은 기계가 멈추는 곳과 인간의 판단이 시작되는 곳을 알려줍니다.

만약 당신이 한 질문에 대해 두 개의 후보 답변을 받고, 보정된 신뢰도와 이견을 제시할 수 있는 서면 논리를 담아 선택(pick)을 내리는 심사위원에게 그 자를 겨누고 싶다면, 진입점은 여기에 있습니다: [https://api.turingcorp.net/platform/go/decider?src=jev-10]