너프 테스트로는 모델이 너프됐는지 제대로 확인할 수 없음

이게 바로 내 요점임. 최소한 그런 프로젝트가 하나 있긴 한데, 이름이나 사이트가 기억이 안 나네.

이거 쩌네

너프 테스트가 문제라는 게 무슨 말인지 이해가 안 가는데... 너프 테스트의 핵심은 같은 제품이 같은 작업에서 성능이 급격히 떨어지는지 확인하는 거잖아.

테스트는 한 계정에서 실행됨. 하지만 메시지는 '모델'로 바로 가는 게 아니라 서버로 가고, 앤스로픽이 어떤 모델을 쓸지 결정함. 그러니까 앤스로픽은 일부 사용자에게 더 싼 버전(양자화, 생각 적게 하기 등)을 배정할 수 있고, 여전히 Opus 5.5라고 부를 거임. A/B 테스트처럼 말이야. 넌 절대 모르겠지.

우리는 우리가 제어할 수 없는 부분(특정 모델, 하네스, 프롬프트, 설정 등)을 바꾸지 않고 전체 제품을 벤치마킹하는 거임. 만약 양자화, 숨겨진 라우팅, 앤스로픽 백엔드 변경 같은 우리 통제 밖의 이유로 성능이 떨어지기 시작한다면, 그런 것들이 바로 너프 테스트가 감지하려는 대상임.

당연히 앤스로픽이 A/B 테스트를 하고 있고 네가 대조군에 속해 있다면, 너 자신을 테스트하는 것만으로는 다른 사용자들이 너프당하고 있다는 걸 절대 알아낼 수 없겠지.

근데 너 이거에 대한 증거는 있어?

걔네가 어떻게 하는지 궁금하네. 연결된 기기나 IP 등을 추적해서 같은 사용자가 여러 계정을 쓰는지 판단하는지 궁금함. 거의 확실히 그럴걸. 만약 그렇다면, 계정 단위가 아니라 사용자 단위로 양자화된 A/B 모델을 라우팅할 가능성이 높음. 네 말대로라면 우리가 너프당하는지 알아채기 더 어렵게 만드는 거지.

맞아, 더 나아갈 수도 있지. 진짜 Opus 5.5라면 작업을 훨씬 빨리 끝낼 텐데, 걔네가 사용자의 인내심을 측정할 수도 있음. 얼마나 재시도하는지, 얼마나 계속하는지 같은 걸 보고, 그걸 바탕으로 다음 API 호출을 더 싼 모델로 라우팅하는 거지.

우리 모바일 게임에서 이렇게 함. 사용자가 얼마나 참을성 있는지 측정해서 광고를 더 보여주거나 덜 보여주거든. 그러니까 이 아이디어가 미친 소리는 아님, 제품 설계에서는 흔한 일이지. 앤스로픽이 실제로 하는지는 모르겠지만, 충분히 가능한 일임.