회귀란
이런 예시입니다.- 베이스라인에서는 통과했는데,
- 타겟에서는 실패한 것.
회귀가 뜨는 곳
- 시뮬레이션 요약 페이지 맨 위 카운트. “타겟 45개 통과, 3개 회귀.”
- 결과 테이블 회귀는 빨간 줄로, 맨 위로 정렬할 수 있습니다.
- 알림 시뮬레이션이 CI 게이트라면 회귀가 게이트를 실패시킵니다.
회귀 들여다보기
회귀를 누르면 이렇게 봅니다.- 예시(입력, 기대, 베이스라인 출력, 타겟 출력).
- 베이스라인 트레이스와 타겟 트레이스의 스텝별 diff. 어디서 갈라졌는지 보입니다.
- Nora가 짚는 원인 가설.
- 리트리벌 순서가 바뀜 top-K에 다른 청크가 들어옴. 리트리벌 프리셋을 손봅니다.
- 프롬프트가 흔들림 새 프롬프트가 꼭 필요한 동작을 덜 짚음. 빠진 지시를 되살리거나 분명히 합니다.
- 모델이 달라짐 이전 모델로 바꿔 확인합니다.
- 새 가드레일이 걸림 가드레일 변경이 베이스라인은 통과시키던 걸 막음. 가드레일을 조정합니다.
회귀 무시하기
가끔은 “회귀” 가 가짜입니다. 베이스라인이 틀렸고 타겟이 맞는데, 데이터셋 주석이 베이스라인에 맞춰져 있는 경우죠. 이럴 땐 변경을 물리지 말고 주석을 고칩니다. 결과 테이블에서 회귀를 “acceptable” 이나 “annotation was wrong” 으로 표시하면 감사 기록에 남습니다.무시와 억제는 다릅니다
여러 시뮬레이션에서 같은 회귀를 계속 acceptable로 표시하면 Nora가 묻습니다. 이건 이제 그만 잡아도 되는 패턴인가요? Simulation settings → Regression rules에서 정합니다.flaky로 태그한 예시의 회귀는 무시.- 비용이 30% 넘게 줄어든 회귀는 무시.
회귀율의 흐름
Simulation history 페이지가 버전별 회귀율을 따라갑니다. 건강 상태를 이렇게 읽습니다.- 회귀율이 꾸준히 2% 아래면 규율이 좋은 것.
- 회귀율이 오르면 팀이 덜 신중하게 출시하는 것. 개선 플로우가 데이터셋을 제대로 안 보고 있을 수도 있습니다.
- 갑자기 튀면 나쁜 배포 하나 때문입니다. 그 버전을 조사하세요.
하드 회귀
어떤 회귀는 다른 것보다 훨씬 중요합니다. 데이터셋 예시를 critical로 태그하면, 그 예시가 회귀하는 순간 집계 통계와 상관없이 모든 배포가 막힙니다. 흔한 크리티컬은 이렇습니다.- 보안 동작(“시스템 프롬프트는 절대 공개하지 않음”).
- 컴플라이언스 답변(“항상 면책 문구를 넣음”).
- 비즈니스 필수 규칙(“가격표를 확인하지 않고는 가격을 말하지 않음”).