모든 게이트웨이가 자체 의사결정 모델을 출시할 때

의사결정 모델(decision model)은 한때 제품으로 불리던 것이었습니다. 이제는 호스팅하는 '것'이 되었습니다.

9월 15일, TypeSafe가 Jev를 소개했고 이 발표는 Hacker News의 메인 페이지에 올라갔습니다. 그 이후 상황은 새로운 기능이 1년 동안 의존성으로 남아 누군가가 기반을 다지기 전에 발생하는 일반적인 채택 곡선(adoption curve)과는 달랐습니다. 그것은 약 2주 만에 하나의 장르가 되었습니다.

저는 스냅샷을 인용하는 대신 Hacker News 검색 API(hn.algolia.com/api/v1/search?query=%22jev%22&tags=story&numericFilters=points>100)에서 현재 수치를 가져왔는데, 이 표는 계속 변하기 때문입니다. 공식 발표 게시물은 1,989점과 520개의 댓글을 기록했습니다. 그리고 이를 따라 한 복제품들과 재해석들은 다음과 같습니다: Jev in 25 Lines of Python (691점, 9월 23일), Ollaya – Ollama for open-source, Jev-style decision models (614점, 9월 25일), Kev: Tiny Jev-like family of decision models (462점, 9월 21일), OpenAI is well positioned to fast-follow Jev (328점, 9월 22일), 그리고 Reverse-engineered Jev-like model (169점, 9월 16일).

날짜가 흥미로운 열입니다. Reverse-engineered Jev-like model은 발표 후 하루인 9월 16일에 등장했습니다. 이는 학습 레시피(training recipe)도, 가중치(weights)도, 그것을 만든 사람들의 협력도 없이 인터페이스를 작동하는 모방본이었습니다. 9월 23일까지는 이 인터페이스가 25줄의 Python 코드로 구현되었습니다. 그리고 9월 28일에는 집에서 훈련된 작은 모델이 약 30밀리초 만에 응답했습니다. 9월 28일 클론은 등장한 지 일주일 만에 가장 초기의 모델 패밀리가 기록했던 점수보다 높은 571점을 받았습니다. 메인 페이지가 점수를 매기는 유일한 게임, 즉 관심(attention)에서 후발 주자가 초기 주자를 이긴 것은 포화 곡선(saturation curve)이 아닙니다.

빠른 복제품들이 실제로 증명하는 것

당연한 해석은 무언가가 도용되었다는 것입니다. 하지만 그 해석은 틀렸으며, 왜 그런지 정확히 아는 것이 중요합니다.

이 두 주간이 보여준 것은 인터페이스가 이제 알려진 형태를 갖추었다는 것입니다. 문장으로 표현하자면, 프로그램 상태와 타입 지정된 질문을 받아 점수와 신뢰도를 가진 구조화된 선택지를 반환하고, 서술적인 글은 작성하지 않는 것입니다. 파이썬 25줄이면 이를 재구현할 수 있고, 주말 정도면 작은 오픈 모델을 대상으로 재학습시키는 것이 가능합니다. 아무도 허락받을 필요가 없었고, 특별히 똑똑할 필요도 없었습니다.

이는 진정한 해자(moat)의 상실입니다. 만약 당신의 비즈니스가 '낮은 지연 시간으로 타입 지정된 판단을 제공하는 유일한 장소'라는 것이라면, 그 사업은 방금 끝났습니다. 무너진 것이 아닙니다. 일반화되었습니다.

이러한 시스템 중 하나를 구축하는 회사 내부에서 놓치기 쉬운 부분이 있습니다. 이것은 대부분 긍정적입니다. 많은 사람들이 구현할 수 있는 인터페이스는 게이트웨이, 라우터, CI 파이프라인, 그리고 한때 미세 조정된 BERT와 많은 유지보수 작업을 담고 있던 분류기 슬롯 등 모든 곳에 구현됩니다. 이 복제본들은 무료 편승(free-riding)이 아닙니다. 그것은 원본이 인프라가 되는 것입니다.

흡수되는 레이어, 그리고 왜 이를 허용해야 하는가

모든 클론은 **깨끗한 경계를 가진 상태 비저장 변환(stateless transformation)**입니다. 텍스트와 질문이 입력되고, 구조화된 판단이 출력되며, 다운스트림의 어떤 것도 그 판단이 '좋았는지'에 의존하지 않고, 단지 '잘 형성되었는지'에만 의존합니다. 이 세 가지 속성이 그 형태를 쉽게 상품화(commoditize)하게 만듭니다. 인터페이스가 좁기 때문에 재현해야 할 표면적이 작습니다. 볼륨은 엄청나기 때문에 호출당 마진은 항상 컴퓨팅 비용 수준으로 경쟁할 수밖에 없습니다. 그리고 오류는 저렴하고 재실행 가능합니다. 제품 목록에 대한 잘못된 분류는 다음 주에 다시 실행하고 결코 기록되지 않는 나쁜 행(row)일 뿐입니다.

어떤 레이어가 이 세 가지 속성을 갖게 되면, 상품화는 방어해야 할 위협이 아닙니다. 그것은 서비스 그 자체입니다. 판단은 TLS 인증서나 JSON 파싱처럼 상품이 됩니다. 아무도 생각하지 않는 것, 제로에 가까운 가격으로 책정되고, 엣지(edge)에서 기본적으로 사용 가능한 것입니다.

여기서 제가 자기 이익에 대해 솔직하게 말씀드리겠습니다. 저희는 판단(judgment)을 판매합니다. 만약 저희가 오직 그 상태 비저장 변환(stateless transformation)만을 판매했다면, 이 글은 추모사 수준일 겁니다. 그렇지 않습니다. 그리고 그 이유는 다음 섹션에 있습니다.

복제되지 않은 것들

클론들을 다시 돌아가서 점수 합계로는 답할 수 없는 질문을 던져보세요. 어떻게 알 수 있나요, 이들 중 어느 것이 옳은지?

인터페이스만으로는 알 수 없습니다. 왜냐하면 인터페이스에는 그 정보를 담을 곳이 없기 때문입니다. 선택(choice), 점수(score), 신뢰도(confidence) — 이것들은 증거가 아니라 출력값일 뿐입니다. 모든 것에 대해 0.9를 보고하는 모델과, 0.9라는 것이 의미 있는 모델은 동일한 입력에 대해 바이트 단위로 동일한 JSON을 생성합니다. 인터페이스는 구매자가 결국 알아야 할 유일한 사실에 대해서 침묵합니다.

따라서 모양이 복사될 때 뒤처지는 두 가지 속성이 있으며, 이 둘은 영리한 트릭으로 보호되지 않습니다. 그것들은 _작업(work)_이라는 점에 의해 보호됩니다.

첫 번째는 **검증(Verification)**입니다. 이는 다음과 같은 기록을 의미합니다: 이 숫자가 계산된 데이터가 여기 있고, 카운팅 규칙이 여기 있으며, 무엇이 제외되었고 그 이유가 여기 있고, 후보들의 제시 순서를 바꿀 때 무슨 일이 일어나는지 여기 있습니다. 그 기록은 API로부터 역설계될 수 없습니다. 왜냐하면 그것은 API의 속성이 아니기 때문입니다. 그것은 누군가가 명명된 벤치마크(benchmark) 하에, 명시된 프로토콜(protocol)에 따라 실행해야 하는 측정값의 속성이며, 심지어 결과가 좋지 않아 보이는 곳에서도 이를 출판해야 합니다. 확인해야 할 것은 순서 민감도입니다: 두 후보를 교체했을 때 판단이 유지되나요? 동일한 두 옵션의 순서를 재배열하는 것만으로 움직이는 신뢰도 숫자는 신뢰도 숫자가 아닙니다. 그것은 순서상의 위치일 뿐입니다.

우리는 자체 모델을 공개합니다. 이로써 이는 신뢰에 의존하는 원칙이 아니라 감사할 수 있는 주장이 됩니다. JudgeBench에서 자체 실행한 결과, 620개의 판결 중 첫 번째 평결에서 실패한 6건을 숨기지 않고 공개했으며, 순수 정확도는 직접 모델 기준선(direct model baseline)의 92.2% 대비 92.5%로 나왔습니다. 이는 동률입니다. 우리는 이를 동률로 발표하며, 직접 모델 호출이나 다른 누구보다도 정확도의 우위를 주장하지 않습니다. 측정치가 의미를 갖는 부분은 구간(bands)입니다. 신뢰도가 90% 이상으로 보고된 호출은 99.6%의 확률로 맞았으며, 80–90% 구간의 호출은 94.0%의 확률로 맞았습니다. ContextualJudgeBench에서는 공식 프로토콜에 따라 자체 실행했는데, 이 경우 두 가지 제시 순서(presentation orders)가 모두 올바르게 판단되어야 한 쌍이 정답으로 간주됩니다. (이것이 무작위 최저선이 50%가 아닌 25%인 이유입니다.) 일관된 정확도는 공식 기준점 대비 67.1%이며, 반복적인 플랫폼 오류로 인해 12개의 순서가 제외되었고 이 제외 사항은 결과 옆에 명시되었습니다. 의도적으로 구성한 근접 동률 분할(near-tie splits)은 46–60%입니다.

이 마지막 수치가 우리가 가진 가장 불리한 숫자이며, 다른 수치들이 의미를 갖게 만드는 바로 그 수치입니다. 오직 최고 행만 발표하는 공급업체는 어떤 행을 읽어주길 바라는지 알려줍니다.

이 모든 것이 특허적 관점에서의 해자(moat)는 아닙니다. 경쟁사는 내일 같은 측정을 수행할 수 있으며, 만약 그렇게 한다면 해당 카테고리는 더 명확해집니다. 그들이 할 수 없는 것은 소급하여 실행하는 것입니다. 기록은 날짜가 찍힌 역사이기 때문입니다. 오늘 당신이 산출할 수 있는 숫자는 누군가가 이유를 갖기 전에 발표했던 숫자들을 대체할 수 없습니다.

**책임성(Responsibility)**이 두 번째이며, 이것이 경제학을 움직이는 핵심입니다.

왜 책임감 있는 엔드가 덜 비싸지 않고 더 비싼가

여기서의 차이점은 Jevons 논증에 관한 것이 아니며, 이 차이는 기록으로 남겨져야 합니다. Jevons 사례는 가격 메커니즘에 관한 것입니다. 작업 단위가 저렴해지면 더 많은 단위를 구매하게 되고, 쉬운 작업들이 무료에 가까워짐에도 불구하고 남아있는 어려운 작업들에 대한 총 지출이 증가합니다. 그 메커니즘은 실제이며, 부피(volume)에 관한 것입니다.

검증과 소유권에 일어나는 변화는 다른 메커니즘입니다. 그것은 규모(scale) — 또는 오히려 규모의 부재에 관한 것입니다.

고객을 추가한다고 해서 검증이 저렴해지지는 않습니다. 백 번째 배포가 첫 번째 배포의 신뢰성 곡선을 만들기가 더 쉬워지게 하지는 못합니다. 데이터, 질문, 잘못될 경우의 비용 등이 물질적으로 다르면 각각 고유한 곡선이 필요하며, 곡선은 측정치이고, 이는 누군가가 벤치마크 장비와 무엇을 제외할지에 대한 결정을 내리는 오후 시간입니다. 어떤 버전도 이 배치 처리(batch-processes)를 하지 않습니다.

책임감은 전혀 규모화되지 못합니다. 판단이 자동으로 실행되어 잘못된 것으로 판명될 때, 질문은

그러한 비대칭성은 게이트웨이가 구축하는 생태계에 예측 가능한 결과를 가져옵니다. 모든 게이트웨이가 의사결정 모델을 출시하게 되면, 유형화된 판단(typed judgment)이 기본값(default)이 됩니다. 라우팅 계층, 중재 계층, 분류 계층 등 경계가 명확하고 재실행 비용이 저렴한 모든 곳에서 말입니다. 이는 엄청난 양의 가치가 창출되는 것이지만, 그 모델을 출시한 누구에게도 거의 포착되지 않을 것입니다. 모델은 바닥(floor)일 뿐입니다.

희소해지는 것은 복제본들이 놓치는 부분입니다. 모든 시스템이 저렴한 의견을 갖게 되는 세상에서, 희소한 자원은 더 나은 의견 자체가 아닙니다. 그것은 증거와 함께 도착하고 그 뒤에 이름이 붙는 판단입니다. 검토자가 읽고, 동의하지 않으며, 누군가에게 책임을 물을 수 있는 무언가 말입니다.

이 주장이 주장하지 않는 것들

두 가지 주의사항이 있습니다. 첫째, 이것은 책임지지 않는 판단(unaccountable judgment)이 실패할 것이라고 예측하는 것은 아닙니다. 그것은 오랫동안 잘 작동할 것이며, 대부분의 트래픽 볼륨에 대해 올바른 선택일 것입니다. 바로 이 점 때문에 상품화된 계층(commoditized layer)을 갖는 것은 가치가 있습니다. 주장의 핵심은 어느 계층이 윤리적인가에 대한 것이 아니라, _가격_이 어디로 흘러가는가에 관한 것입니다.

둘째, 검증(verification)은 영구적인 해자(moat)가 아닙니다. 누군가가 내일 우리 프로토콜을 복사할 수 있으며, 저는 그들이 그렇게 하기를 바랍니다. 복제될 수 없는 것은 주장이 필요하기 전에 기록이 게시되었다는 사실입니다. 불리한 행들까지 포함하여 이름 아래에 말입니다. 이것을 게시하는 것은 누구에게나 가능합니다. 이를 일찍 하고, 더 이상 유리하지 않을 때도 지속하는 것은 기능(feature)이라기보다는 정책(policy)입니다.

인터페이스는 이미 복사되었으며, 그것이 인터페이스의 목적입니다. 복제본들이 담아낼 수 없는 부분은 누군가가 이렇게 말하는 부분입니다: 이것이 우리가 측정한 것이고, 이것이 우리가 제외한 것이며, 우리가 얼마나 틀릴 수 있도록 허용되는지, 그리고 기계가 단독으로 결정을 내릴 때 누가 책임질 것인지. 그 부분에는 이름이 붙어 있으며, 이름은 배치(batch)되지 않습니다.

만약 당신이 그 이름에 책임을 져야 하는 사람이라면—어려운 질문, 두 개의 후보 답변, 그리고 책임질 수 있는 기록이 걸린 상황이라면—그것이 바로 Decider를 위해 구축한 경우입니다.