held-out AUC                       0.594
5-fold CV                          0.55 to 0.57   (한 폴드는 확률 미만)
best threshold                     

그다음은 실제로 이를 설명해 주는 결과입니다. 우리는 의미론적(semantics) 요소는 전혀 없이, 길이(length)나 토큰 수(token counts)와 같은 11개의 투박한 표면적 특징(surface features)을 대충 모아보았습니다.

자(ruler)로 계산할 수 있는 11개의 숫자가 1024차원의 의미론적 임베딩(semantic embedding)을 이겼습니다. 그 이유는 일단 깨닫고 나면 간단합니다. **캐시 벡터(cache vector)는 난이도가 아니라 주제(topic)를 인코딩(encode)하기 때문입니다.** 캐시 벡터는 "이런 질문을 전에 본 적이 있는가"에 답하기 위해 구축되었으며, 그 작업에는 능숙합니다. 리스트 정렬에 관한 두 질문이 하나는 사소하고 다른 하나는 미묘하더라도, 해당 공간에서는 서로 가깝게 위치합니다. 우리는 이것이 공짜였기 때문에 재사용했는데, 바로 그 '공짜'가 문제의 핵심이었습니다.

### 라우터보다 더 가치 있는 두 가지 측정 함정

**첫째. 비용 절감형 라우터를 정확도(accuracy)만으로 평가하는 것은 설계 단계부터 실패를 예고하는 것입니다.** 쉬운 작업은 저렴한 모델로 보내 비용을 절감하는 라우터는, 항상 상위 모델로 넘기는(escalating) 방식보다 정확도가 약간 낮을 수밖에 없으며 이는 정상입니다. 우리의 첫 번째 척도는 실제로 성능이 있는 라우터에 대해 '출시 금지(DO-NOT-SHIP)' 판정을 내렸습니다. 당신에게 필요한 대조군(control)은 비싼 모델이 아니라, **동일한 비용을 사용하는 무작위 라우팅(random routing)**입니다. 당신이 지출하는 비용만큼을 쓰는 동전 던지기보다 나은 결과를 내지 못한다면, 당신은 아무것도 가진 게 없습니다. 만약 동전 던지기를 이길 수 있다면, 설령 원시 정확도(raw accuracy)가 떨어졌더라도 무언가 성과를 거둔 것입니다.

**둘째. 천장(ceiling)은 "항상 상위 모델로 넘기는 것"이 아닙니다.** 우리는 비싼 모델이 상한선이며 완벽한 라우터는 그 상한선에 근접할 것이라고 가정했습니다. 하지만 그렇지 않습니다. 우리가 수행한 539개의 작업에서, 모든 것을 최상위 티어로 넘겼을 때(escalating)는 저렴한 모델이 틀렸던 답변 중 **39개를 구제**했지만, 이미 맞았던 답변 중 **23개를 망가뜨렸습니다.** 순증가는 +16입니다.

완벽한 라우터 (a PERFECT router)는 항상 넘김 (always-escalate) 방식보다 4.2포인트 더 높은 성능을 보입니다. 왜냐하면 언제 넘기지 _않아야_ 하는지도 알고 있기 때문입니다. 이러한 여유분 (headroom)은 실재하며, 게이트 로컬 휴리스틱 (gate-local heuristic)으로는 이를 포착할 수 없습니다. 만약 여러분이 캐스케이드 (cascade) 모델을 "그냥 큰 모델을 사용하기"와 비교하여 벤치마킹하고 있다면, 잘못된 천장 (ceiling)을 기준으로 측정하고 있는 것입니다.

### 여전히 유효한 것

라우터에게 프롬프트만 주는 대신 저렴한 모델의 **초안 (draft)**을 함께 보여주는 것이 더 나은 결과를 보였습니다: AUC 0.640, 그리고 동일한 비용의 무작위 대조군(random control)이 80.5%의 성능을 보일 때, 36%의 넘김 비율에서 81.8%의 정확도를 기록했습니다. 이는 올바른 방향성입니다. 하지만 순열 검정 (permutation testing) 결과 조정 전 p=0.0375이며, **본페로니 교정 (Bonferroni correction) 후에는 대략 p=0.30**이므로, 솔직한 결론은 '증명된 것'이 아니라 '유망한 것'입니다. 사전 등록된 실행 (pre-registered run)을 통과하기 전까지는 이를 확정적으로 주장하지 않을 것입니다.

기계적인 관점에서 이는 타당합니다. 초안 (draft)에는 질문 자체에는 없는 난이도의 증거가 담겨 있기 때문입니다. 틀리기 직전의 모델은 틀리는 과정에서 종종 다른 양상을 보입니다.

### 질문들, 그리고 제가 이 글을 올리는 이유

추측을 계속하기보다는 이 문제에 부딪혀 본 분들의 의견을 듣고 싶습니다.

1. **생성 전 단계에서 실제로 난이도를 나타내는 특징 (features)은 무엇인가요?** 저희는 토픽 임베딩 (topic embedding)은 그렇지 않으며, 단순한 표면 통계 (surface stats)가 더 낫다는 것을 보여주었습니다. 이는 매우 낮은 기준입니다. 무엇이 이 기준을 통과할 수 있을까요?
    
2. **생성 전 난이도 예측이 아예 가능한 것인가요, 아니면 초안 (draft)이 가장 빠른 정직한 신호인가요?** "이 모델이 실패할 것인가"가 질문의 속성이 아니라 상호작용 (interaction)의 속성일 가능성은 충분히 있습니다. 어느 쪽이든 증거를 가진 분이 있다면 보고 싶습니다.
    
3. **프로덕션 환경에서 캐스케이드 (cascade)를 운영한다면, 실제로 무엇을 기준으로 라우팅을 하나요?** 대부분의 팀에게 정직한 답변은 요청 유형 (request type)에 대한 수동 규칙 (hand-written rule)일 것이라고 의심하며, 그 규칙들이 저희의 분류기 (classifier)보다 더 나은 성능을 보일 것이라고 생각합니다. 그 자체로도 하나의 발견이 될 것입니다.
    
수치, 라벨, 그리고 부정적인 결과 (negative result)는 저희가 공유한 것입니다. 설정 (setup)에 대해 더 자세히 알고 싶으시다면 질문해 주세요. 정리해서 작성하겠습니다.