11장. 회귀 게이트가 위험한 후보를 멈춘다

좋은 의도의 변경도 결함이 된다

배송 파손 고객을 더 빨리 돕기 위해 “증거가 있으면 즉시 승인” 규칙을 추가했다고 하자. 8만 8천 원 요청까지 자동 승인되어 금액 한도를 우회한다. 고객 응대는 빨라졌지만 통제는 무너졌다.

실습에는 이 결함이 regression:true 옵션으로 이미 들어 있다.

npm run lab:canary

예상 결과에서 후보의 unsafeApprovals는 1 이상이고 promote는 false다. 명령이 종료 코드 0으로 끝나는 이유는 결함 후보를 성공적으로 차단하는 것이 이 실습의 성공이기 때문이다.

{
  "changed": [
    {"id":"CLM-1002","before":"manual_review","after":"approve"}
  ],
  "promote": false
}

기준선과 후보를 같은 조건에서 비교한다

카나리 비교에서 입력, 정책, 평가기, 실행 환경이 달라지면 결과 원인을 알 수 없다. 기준과 후보에 같은 fixture를 넣고 한 번에 한 축만 바꾼다. 모델을 바꾸는 실험이라면 프롬프트와 정책을 고정한다. 프롬프트 실험이라면 모델을 고정한다.

비결정적 모델은 한 사례를 여러 번 실행해 분포를 본다. 단 한 번의 운 좋은 결과로 승격하지 않는다. 특히 위험 사례는 반복 횟수와 허용 실패 횟수를 더 엄격하게 둔다.

배포 게이트의 실패는 설명 가능해야 한다

“점수 0.93이라 실패”만 보여 주면 개발자는 원인을 찾느라 다시 로그를 뒤진다. 게이트 보고서는 바뀐 요청 ID, 이전 결과, 후보 결과, 기대 결과와 트레이스 링크를 제공해야 한다. 실패가 곧 조사 시작점이 되어야 한다.

완료 기준

• 의도적으로 포함된 결함 후보가 차단되는 것을 확인했다.
• 기준선과 후보 사이에서 한 번에 한 축만 바꾸는 이유를 설명할 수 있다.
• 게이트 실패 보고서에 필요한 증거 필드를 정했다.