월드 모델 드리프트 측정 지표가 오래된 체크포인트를 안정적이라고 평가한 사례

지난 분기에 저는 내부 엔드포인트 하나를 폐기했습니다. 에이전트 스택의 월드 모델 레이어, 즉 도구 호출을 실제로 수행하기 전에 그 결과가 무엇일지 예측하는 부분이 11일 동안 계속해서 이전 응답 형태를 예측했습니다. 제 회귀(regression) 하네스(harness)는 이 체크포인트를 이번 달 가장 안정적인 빌드로 평가했습니다.

이것은 하네스의 버그가 아닙니다. 하네스는 제가 지시한 대로 정확히 작동했습니다. 저는 그것에게 하나의 숫자, 즉 프로브 세트(probe set) 전반에 걸친 예측 상태의 평균 드리프트 값(mean drift in predicted state across my probe set), 체크포인트별로 측정하도록 했습니다. 드리프트가 낮다는 것은 좋았다는 의미였습니다. 자신의 생각을 바꾸기를 거부하는 모델은 올바른 모델처럼 평가받았습니다.

저는 이 역설을 몇 달 동안 가지고 있었지만, 이를 부를 이름이 없었습니다. 이 논문에서 그 이름을 얻었습니다: [https://arxiv.org/abs/2610.03713v1]

_What Should World Models Forget? Stratified Retention for Continual Adaptation_에 제시된 주장은 직설적입니다. 현재의 지속 학습(continual-learning) 벤치마크는 오래된 사실을 올바르게 수정하는 모델보다 고정된 월드 모델을 더 높은 순위로 매길 것입니다. 왜냐하면 단일한 종합적인 성능 저하 지표(single aggregate degradation metric)가 망각(forgetting)과 업데이트(updating)를 구분할 수 없기 때문입니다. 둘 다

둘 다 실패입니다. 각각은 정반대의 수정이 필요합니다. 그리고 제 이전 지표는 이 둘을 평균 내어 하나의 숫자로 만들었기 때문에, 제가 어느 쪽인지 물어봤다고 해도 어떤 것인지는 알려줄 수 없었습니다.

다음 평가(evals)가 어떻게 될지 예측하며

날짜를 찍어서 저의 예측을 말씀드리겠습니다. 앞으로 1년 정도 안에, 심각한 수준의 월드 모델(world-model) 또는 에이전트 벤치마크는 단 하나의 지속적 학습(continual-learning) 점수를 발표하는 것이 아니라, 적어도 두 가지를 나란히 보고서에 게재하기 시작할 것입니다:

불변 회귀율(Invariant regression rate). 인간의 개입 없이는 절대 변해서는 안 되는 사실들의 집합: 도구 스키마(tool schemas), 인증 흐름(auth flows), 단위 규칙(unit conventions), created_at이 UTC라는 사실 등. 무관용 원칙입니다. 만약 모델이 이 중 하나를 수정한다면, 그것은 적응이 아니라 오염(corruption)이며, 마치 빌드 실패가 CI에 실패하는 것처럼 해당 실행을 실패 처리해야 합니다.

수정 지연 시간(Revision latency). 변경되어야 하는 사실들—가격 책정, 속도 제한(rate limits), 지원 중단 기간(deprecation windows), 모델 이름 등—에 대해 모델이 업데이트되기까지 얼마나 많은 관찰(observations)이 필요한가? 벽시계 시간(wall-clock)이 아닌 관찰 횟수로 측정해야 합니다. 왜냐하면 벽시계 시간은 모델이 실제로 본 증거의 양을 숨기기 때문입니다.

그리고 논문에서 암시하지만 명확히 이름 붙이지 않은 세 번째 항목을 추가하고 싶습니다: 부수적 수정(collateral revision). 모델이 오래된 사실을 업데이트할 때, 그 과정에서 얼마나 많은 정확한 사실들을 망가뜨리는가? 지연 시간만으로는 부족합니다. 가장 빠른 수정 지연 시간을 가진 것은 마지막에 본 모든 것을 믿는 모델일 수 있습니다.

제가 가장 크게 베팅하는 부분이 바로 이겁니다. 만약 수정 지연 시간 리더보드를 발표한다면, 누군가는 단 하나의 노이즈가 있는 관찰(noisy observation)만으로 자신의 신념을 뒤집는 에이전트를 출시하여 1위를 차지할 것입니다. 부수적 수정을 고려하지 않은 지연 시간은 적응성의 측정이 아니라, 얼마나 쉽게 속을 수 있는지의 측정입니다. 이 수치들은 쌍으로 나와야 합니다. 그렇지 않으면 단지 Goodhart 목표만 옮긴 것일 뿐입니다.

계층화(Stratification)는 평가 설계가 아닌 아키텍처 결정이다

계층적 틀(stratified framing)이 유용한 점은, 제가 이러한 시스템을 구축할 때 습관적으로, 그리고 서툴게 하는 방식과 일치한다는 것입니다.

불변(Invariants)은 코드에 존재합니다. 도구 스키마(Tool schemas), 인증 정보(auth), 단위(units) 등은 사람이 검토하는 타입 계약(typed contract)에 포함되어야 합니다. 이런 것들은 절대로 가중치(weights) 안에 있어서는 안 됩니다.

변화가 느린 사실들(Slow-changing facts)은 제가 다시 쓸 수 있는 스토어에 존재합니다. 가격 책정, 사용량 제한(rate limits), 어떤 모델이 언제 폐기되는지 등이 해당됩니다. 여기서의 수정 지연 시간(Revision latency)은 몇 번의 관찰(observations)으로 측정되어야 하며, 업데이트는 감사 가능해야 합니다. 무엇이 바뀌었고 왜 바뀌었는지 보고 싶습니다.

변화가 빠른 상태(Fast-changing state) — 기능 플래그(feature flags), 온콜 로테이션(on-call rotation), 장기 실행 작업의 상태 등 — 은 어떤 것에도 '학습'되어서는 안 됩니다. 이것은 호출할 때마다 다시 읽어보는 조회 테이블(lookup)에 속합니다. 만약 당신의 월드 모델이 현재 스프린트(sprint)를 예측하는 데 용량을 쓰고 있다면, 당신은 노후화 버그(staleness bug)가 있는 비싼 캐시를 구축한 것입니다.

따라서 이 논문의 계층화(stratification)는 단순히 벤치마크 제안이 아닙니다. 이는 배포된 에이전트에서 발생하는 대부분의 '지속적 학습(continual learning)' 문제가 실제로는 메모리 배치 문제(memory-placement problems)라는 것을 상기시켜주는 것입니다. 저는 무언가를 훈련하는 것보다 사실 하나를 모델 밖으로 옮김으로써 더 많은 문제를 해결해 왔습니다.

제가 확신하지 못하는 부분

저는 계층적 유지(stratified retention)를 구현하지 않았습니다. 이것은 체크포인트로 가져와 실행할 수 있는 방법론 논문일 뿐이며, 제가 가장 확실하지 않은 부분은 그 계층 경계가 어디서 오는지 하는 점입니다. 제 시스템에서는 도구를 직접 작성했기 때문에 어떤 필드가 안정적인지 알기에 명확합니다. 하지만 개방형 환경에서 '빛의 속도'와 '이 API의 가격'을 다른 버킷에 넣는다고 결정하는 것이 전체 문제입니다. 논문은 이 부분에 대해 제가 원하는 만큼 충분하지 않습니다. 어쩌면 경계가 학습 가능할 수도 있습니다. 아니면 영원히 사람이 유지하는 단순한 설정 파일(config file)일 수도 있습니다. 저는 아직 진정으로 모릅니다.

제가 아는 것은 저의 단일 드리프트 수치(single drift number)가 저를 속이고 있었다는 것, 그리고 그 거짓말이 듣기 좋은 방향이었다는 것입니다.

그래서 이번 주에는 이것을 두 부분으로 나누고 모든 프로브(probe)에 계층(stratum) 태그를 붙일 것입니다. 오후 내내 작업할 예정입니다 — 각 테스트 케이스에 레이블을 지정하고, 두 번째 집계(aggregation)를 수행하며, 버킷별 임계값(threshold)을 설정해야 합니다. 대안은 자신 있게 잘못된 모델을 배포하고 그것이 안정적이라고 부르는 것인데, 이는 제가 너무 자주 저질러서 이제는 보자마자 알아차릴 수 있는 실수입니다.