늑대만 외치는 드리프트 감지기가 감지기 자체가 없는 것보다 더 나쁘다

나의 드리프트 감지기(drift detector)가 건강한 에이전트를 격리시켰다. 에이전트가 나빠진 것은 아니었다. 벤치마크 자체가 커졌을 뿐이다. 이 감지기는 코퍼스 버전 전반에 걸친 실패 횟수(failure counts)를 비교했기 때문에, 벤치마크가 10개 작업에서 20개로 증가하자 10/10 에이전트가 전체 테스트 스위트의 절반을 "실패"한 것처럼 보이게 만들었다. 코퍼스 성장이 감쇠(decay)처럼 보인 것이다.

나는 HivePlane v0.2.0을 위해 드리프트 감지기를 구축하여, v0.1.0에서 언급했던 실패 모드—"위험한 에이전트는 보통 편집되는 것이 아니라 드리프트를 겪는다"—를 포착하고자 했다. 더 어려운 문제는 드리프트를 감지하는 것이 아니었다. 드리프트가 존재하지 않는 것을 감지하지 못하는 것이었다. 개가 짖는 소리만 내는(cries wolf) 감지기는 운영자들에게 신호를 무시하도록 훈련시키고, 무시된 게이트는 아무런 게이트도 아니다.

자체 벤치마크를 먹어버린 감지기

릴리즈에서 가장 무서운 부분은 놓친 드리프트가 아니었다. 그것은 감지기가 더 이상 존재하지 않는 벤치마크와 비교했기 때문에 건강한 에이전트가 격리된 것이었다.

감쇠처럼 보였던 벤치마크

#530은 내가 드리프트 기준선(drift baselines)에 대해 생각하는 방식을 바꿨다. 이 감지기는 코퍼스 버전 전반에 걸친 실패 *횟수(failure counts)*를 비교했다. 만약 벤치마크가 10개 작업에서 20개로 증가했다면—학습 루프가 검토된 케이스를 추가했기 때문에—이전 계산법으로는 10/10을 통과했던 건강한 에이전트가 20개 중 10개를 "실패"한 것처럼 보였다. 코퍼스 성장이 감쇠처럼 보인 것이다.

에이전트가 나빠진 것은 아니었다. 벤치마크 자체가 커졌을 뿐이다. 감지기는 그 차이를 알 수 없었기에, 완벽하게 좋은 에이전트를 격리시켰다.

해결책: 드리프트는 에이전트의 *비교 가능한 코퍼스에 대한 자체 기준선(own baseline)*을 기준으로 측정되어야 한다. 다른 횟수를 비교하는 것이 아니라 같은 작업을 재평가 과정에서 비교해야 한다. 코퍼스 버전 변경은 드리프트 신호가 아니라 새로운 기준선을 확립한다. 벤치마크의 성장은 퇴행(regression)이 아니라 성장이다.

팁: 드리프트 측정치가 카운트(count)인 경우, 벤치마크 변경이 행동 변화처럼 보일 수 있습니다. 에이전트를 동일한 작업에 대해 스스로 비교하거나, 코퍼스 편집을 수행할 때 임의로 격리하는 것은 잘못된 조치(false quarantine)가 될 수 있습니다.

자체 격리를 거부한 복구 과정

F-13은 대칭성이 깨진 지점이었습니다. 드리프트 자동 격리는 인증 상태를 UNCERTIFIED로 재설정할 뿐, QUARANTINED로 설정하지는 않습니다. 복구(Reinstatement)가 이루어지려면 status == QUARANTINED여야 했습니다. 따라서 격리를 만든 게이트가 그것을 해제하는 것을 거부했습니다. 워크로드는 자동 격리된 후, 감지기가 결코 설정하지 않은 상태를 전제 조건으로 삼았기 때문에 영원히 복구되지 않을 수 있었습니다.

수정 사항은 오래된 전제 조건을 제거하는 것이었습니다. 활성 격리 기록(quarantine record)은 복구가 가능합니다. 즉, 워크로드는 재인증되고 입장이 다시 확인됩니다. 상태 필드(status field)가 진실의 원천(source of truth)이 아닙니다. 격리 기록이 그렇습니다. 게이트가 잘못된 것을 기준으로 삼고 있었습니다.

필드 테스트에서 S5 시나리오를 통해 이를 포착했습니다. 이 시나리오에서는 S4의 자동 격리 이후 복구 과정이 순차적으로 실패했기 때문입니다. 두 가지 시나리오, 하나의 버그, 그리고 교훈은 다음과 같습니다:

오탐(False-positive) 제어는 사소한 기능이 아니라 필수적인 요소입니다. 단 한 번의 초과 실행은 경고일 뿐이며, 격리(quarantine)를 위해서는 N번 연속 실패하거나 강력한 신호가 필요합니다. 안정적인 에이전트는 노이즈 때문에 절대 격리되지 않습니다. 드리프트를 측정할 때는 비교 가능한 기준선(baseline)을 사용해야 합니다. 즉, 동일한 태스크와 동일한 코퍼스 버전을 사용해야 하며, 코퍼스 업데이트는 회귀(regression)가 아니라 새로운 기준선입니다. 격리 기록이 진실의 원천이지, 상태 열거형(status enum)이 아닙니다. 복구는 이 기록을 기반으로 이루어져야 하며, 그렇지 않으면 자신이 해제해야 할 격리조차 거부하게 됩니다. 또한 프로브(probe)는 단지 실행이 허용되었다는 것 이상으로 예상되는 출력을 주장해야 합니다. 생존성(liveness)은 준비 상태(readiness)가 아닙니다.

v0.2.0 필드 테스트에서는 시나리오 S4, S5, S8, 그리고 S24를 통해 전체 루프—드리프트 감지/평가/프로브, 자동 격리, 새로운 인증을 거친 후 복구—를 입증합니다. 합성 프로브는 S24에서 드리프트 임계값보다 앞서 성능 저하(decay)를 플래그 지정합니다. 전체 증거는 field-test report에서 확인할 수 있으며, 인증 및 학습 루프 설계는 certification v2 design와 learning loop design에 있습니다.

참고 자료 (References)

• HivePlane — pip install hiveplane==0.2.0
• Field test report (36/36)
• Certification v2 design · Learning loop design
• Operator runbook — drift & quarantine

당신의 감지기가 정상적인 것을 격리했던 마지막 순간은 언제였나요? 만약 운영자들이 읽지 않고도 복구하는 법을 배웠다면, 당신의 감지기는 제어 장치(control)가 아니라 체크박스에 불과합니다.