제가 지켜본 결함 있는 측정 시스템을 출시한 모든 팀은 동일한 방식으로 실패했습니다. 잘못된 수학 때문이 아니라, 코드 안에 자리 잡은 조직도(org chart) 문제 때문이었습니다.

주장을 하는 주체가 그 주장이 맞는지 결정하는 주체가 되어버린 것입니다.

이 구조를 머릿속에 그려두면 어디에서나 보이기 시작할 것입니다.

두 개가 아닌 세 가지 역할

대부분의 엔지니어는 측정을 두 가지 역할, 즉 '행동하는 것'과 '그것을 채점하는 것'으로 생각합니다. 하지만 역할 하나가 부족합니다. 실제로는 세 가지가 있습니다:

• 플레이어 (Player) — 주장을 합니다. 당신의 모델, 당신의 서비스, 당신의 PR(Pull Request).
• 스코어러 (Scorer) — 루브릭 (rubric, 채점 기준)을 적용합니다. 당신의 평가 하네스 (eval harness), 당신의 테스트 스위트 (test suite), 당신의 메트릭 대시보드 (metrics dashboard).
• 세틀러 (Settler) — 실제로 무슨 일이 일어났는지 결정합니다. 프로덕션 결과 (Production outcomes). 현실.

스코어러는 대리자 (proxy)입니다. 세틀러는 그 대리자가 근사(approximate)하려고 노력하는 대상입니다.

규칙: 스코어러가 되되, 결코 세틀러가 되지 마십시오. 플레이어가 세틀러를 장악하면, 루프가 자기 자신에게 닫히게 되어 시스템이 더 이상 틀릴 수 없게 됩니다. 이는 성공처럼 들리겠지만, 실제로는 실패입니다.

코드에서의 모습

테스트 세트에서의 튜닝 (Tuning on the test set). 테스트 정확도를 확인하고, 하이퍼파라미터 (hyperparameters)를 조정하고, 다시 확인합니다. 20번의 반복이 지나면 테스트 세트는 추가 단계가 있는 학습 데이터 (training data)가 되어버립니다. 이제 플레이어가 스스로의 세틀러를 선택하고 있는 것입니다. 이것이 바로 과적합 (overfitting)의 구조적 본질입니다. 수학적 실패가 아니라, 역할 붕괴 (role-collapse)의 실패입니다.

동일한 계열의 LLM-as-judge. 당신의 생성기 (generator)가 GPT 계열이고 당신의 판사 (judge)도 GPT 계열입니다. 이들은 사전 학습 데이터 (pretraining data), 실패 모드 (failure modes), 그리고 사각지대 (blind spots)를 공유합니다. 판사는 품질을 평가하는 것이 아니라, 자신이 생성했을 법한 결과물과의 유사성을 평가합니다. 상관관계가 있는 오류 (Correlated error)는 평균화 과정에서 보이지 않습니다. 이를 1,000번 실행하면 당신은 똑같이 틀린 답에 대해 더 확신하게 될 뿐입니다.

벤치마크 오염 (Benchmark contamination). 모델이 자신의 학습 데이터에 포함된 벤치마크에서 94%의 점수를 기록합니다. 아무도 거짓말을 하지 않았습니다. 단지 세틀러가 플레이어 내부로 조용히 이동했을 뿐입니다.

자가 보고된 상태 (Self-reported health). 자신의 상태 체크(health check)를 반환하는 서비스는 스스로의 주장에 대해 스스로 판결을 내리는 주장자(claimant)와 같습니다. 만약 프로세스가 멈춰버린다면(wedged), 체크 또한 멈추게 되며, 장애가 발생하는 동안에도 당신의 대시보드는 초록색(정상)을 유지할 것입니다.

의사결정 시점 재구성 없는 백테스트 (Backtests without decision-time reconstruction). 결과가 알려진 후에 계산된 피처(feature)를 사용하여 과거의 의사결정에 점수를 매기는 것입니다. 과거가 미래의 정보로 채점되는 셈입니다. 당신의 샤프 지수(Sharpe ratio)는 매우 아름답겠지만, 완전히 허구적인 수치일 뿐입니다.

동일한 실패가 다섯 가지 모습으로 나타난 것입니다: 주장자(claimant)가 세틀러(settler)를 포획한 것입니다.

해결책은 도덕이 아닌 구조에 있습니다

위 목록의 그 누구도 부정직하지 않았습니다. 바로 그것이 핵심입니다. 이것은 주의력이나 연차로 해결될 문제가 아닙니다. 왜냐하면 이것은 규율(discipline)의 문제가 아니기 때문입니다. 독립성(Independence)은 반드시 _설계(engineered)_되어야 하며, 그렇지 않으면 일반적인 압력 아래에서 부패하게 됩니다.

구체적으로 의미하는 바는 다음과 같습니다:

세틀러(settler)에 도달하는 비용을 높이십시오. 자유롭게 쿼리할 수 있는 홀드아웃(holdout) 데이터는 홀드아웃이 아닙니다. 속도 제한(Rate-limit)을 걸고, 모든 접근을 기록하며, 하나의 쿼리를 하나의 비용(spend)으로 취급하십시오. 테스트 세트를 확인한 횟수가 어디에도 기록되지 않는다면, 당신은 이미 그것이 얼마나 오염되었는지 파악할 능력을 상실한 것입니다.

다른 실패 유형을 가진 판사를 선택하십시오. 사람이 검토할 수 없다면, 최소한 다른 모델 계보(lineage)를 사용하십시오. 당신이 원하는 것은 서로 일치하는 오류가 아니라, 상관관계가 없는(uncorrelated) 오류입니다.

프로덕션(production)이 세틀러가 되게 하십시오. 예측값을 배포하고, 실제로 실현된 결과(realized outcome)를 포착하여 비교하십시오. 현실의 상류(upstream)에 있는 모든 것은 대리 지표(proxy)이며, 모든 대리 지표는 세틀러의 코트를 입은 채 점수를 매기는 채점자입니다.

의사결정 시점의 상태를 재구성하십시오. 과거의 의사결정에 점수를 매기기 전에, 그 순간에 알 수 있었던 정보를 정확히 재구축하십시오. 만약 이것이 어렵다면, 그 어려움 자체가 발견(finding)입니다. 즉, 현재의 백테스트에서 정보 누출(leaking)이 발생하고 있으며 당신은 이를 모르고 있었다는 뜻입니다.

누가 지표를 소유하는지 주시하십시오. 피처를 배포하는 팀이 성공의 기준을 정의하고 수치를 보고한다면, 당신은 측정을 하고 있는 것이 아니라 오차 범위(error bars)가 포함된 보도 자료를 보고 있는 것입니다.

이를 잡아내는 체크 방법

시스템이 생성하는 어떤 숫자에도 적용할 수 있는 질문 하나가 있습니다:

만약 이 주장이 틀렸다면, 무엇이 우리에게 그것을 알려줄 수 있을까요? 그리고 그 요소는 우리가 통제할 수 있는 것인가요?

만약 아무것도 알려줄 수 없다면, 그 주장은 거짓인 것이 아니라 _반증 불가능 (unfalsifiable)_한 것이며, 이는 더 나쁜 상황입니다. 그리고 만약 당신에게 알려줄 수 있는 요소가 당신이 소유하거나, 튜닝하거나, 혹은 침묵시킬 수 있는 것이라면, 당신이 바로 결정자 (settler)이며 루프 (loop)가 닫힌 것입니다.

닫힌 루프는 요란하게 실패하지 않습니다. 그것은 현실이 수습될 때까지 자신만만하게 표류합니다. 그리고 현실은 당신의 스프린트 (sprint) 일정에 맞춰 움직이는 것이 아니라, 자신만의 시계에 따라 움직입니다.

내가 이 문제를 계속 생각하는 이유

나는 의료 기관에 어떤 청구(claims)가 항소할 가치가 있는지를 알려주는 소프트웨어를 만듭니다. 여기서 결정자 (settler)는 보험사의 실제 송금액입니다. 우리 모델의 확신도 (confidence)도, 우리의 내부 루브릭 (internal rubric)도, 우리 대시보드가 말하는 것도 아닙니다. 만약 우리가 그것들이 결정자가 되도록 허용한다면, 우리는 겉보기에는 훌륭해 보이지만 그것을 사용해 급여 결정을 내리는 사람들에게 조용히 거짓말을 하고 있는 제품을 갖게 될 것입니다.

결국 나는 이 내용을 제대로 글로 정리하게 되었습니다. 동일한 구조가 시장 거품, 과적합 (overfitting), 그리고 내가 예상치 못한 몇몇 곳에서도 나타난다는 사실이 밝혀졌습니다: The Uncapturable Judge.

당신의 스택 (stack)에서 닫힌 루프는 어디에 있나요? 나의 경우 그것은 헬스 체크 (health check)였고, 그것을 찾아내기 위해서는 서비스 중단 (outage)이 발생해야만 했습니다.