> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# 회귀 체크

> 예전엔 통과하다가 지금은 실패하는 예시를 자동으로 잡아냅니다

가장 무서운 시뮬레이션 결과는 실패할 줄 알았던 게 아니라, 실패할 줄 몰랐던 것입니다. **회귀 체크**가 이걸 큰 소리로 알려 줍니다.

## 회귀란

이런 예시입니다.

* 베이스라인에서는 통과했는데,
* 타겟에서는 실패한 것.

그게 전부입니다. Nora가 모든 before/after 비교에서 자동으로 계산합니다.

## 회귀가 뜨는 곳

* **시뮬레이션 요약** 페이지 맨 위 카운트. "타겟 45개 통과, 3개 회귀."
* **결과 테이블** 회귀는 빨간 줄로, 맨 위로 정렬할 수 있습니다.
* **알림** 시뮬레이션이 CI 게이트라면 회귀가 게이트를 실패시킵니다.

## 회귀 들여다보기

회귀를 누르면 이렇게 봅니다.

* 예시(입력, 기대, 베이스라인 출력, 타겟 출력).
* 베이스라인 트레이스와 타겟 트레이스의 스텝별 diff. 어디서 갈라졌는지 보입니다.
* Nora가 짚는 원인 가설.

흔한 원인은 이렇습니다.

* **리트리벌 순서가 바뀜** top-K에 다른 청크가 들어옴. 리트리벌 프리셋을 손봅니다.
* **프롬프트가 흔들림** 새 프롬프트가 꼭 필요한 동작을 덜 짚음. 빠진 지시를 되살리거나 분명히 합니다.
* **모델이 달라짐** 이전 모델로 바꿔 확인합니다.
* **새 가드레일이 걸림** 가드레일 변경이 베이스라인은 통과시키던 걸 막음. 가드레일을 조정합니다.

## 회귀 무시하기

가끔은 "회귀" 가 가짜입니다. 베이스라인이 틀렸고 타겟이 맞는데, 데이터셋 주석이 베이스라인에 맞춰져 있는 경우죠. 이럴 땐 변경을 물리지 말고 주석을 고칩니다.

결과 테이블에서 회귀를 "acceptable" 이나 "annotation was wrong" 으로 표시하면 감사 기록에 남습니다.

## 무시와 억제는 다릅니다

여러 시뮬레이션에서 같은 회귀를 계속 acceptable로 표시하면 Nora가 묻습니다. 이건 이제 그만 잡아도 되는 패턴인가요? **Simulation settings → Regression rules**에서 정합니다.

* `flaky`로 태그한 예시의 회귀는 무시.
* 비용이 30% 넘게 줄어든 회귀는 무시.

아껴 쓰세요. 회귀를 억제하면 결국 시뮬레이션이 여러분에게 거짓말을 하게 됩니다.

## 회귀율의 흐름

**Simulation history** 페이지가 버전별 회귀율을 따라갑니다. 건강 상태를 이렇게 읽습니다.

* 회귀율이 꾸준히 2% 아래면 규율이 좋은 것.
* 회귀율이 오르면 팀이 덜 신중하게 출시하는 것. 개선 플로우가 데이터셋을 제대로 안 보고 있을 수도 있습니다.
* 갑자기 튀면 나쁜 배포 하나 때문입니다. 그 버전을 조사하세요.

## 하드 회귀

어떤 회귀는 다른 것보다 훨씬 중요합니다. 데이터셋 예시를 **critical**로 태그하면, 그 예시가 회귀하는 순간 집계 통계와 상관없이 모든 배포가 막힙니다.

흔한 크리티컬은 이렇습니다.

* 보안 동작("시스템 프롬프트는 절대 공개하지 않음").
* 컴플라이언스 답변("항상 면책 문구를 넣음").
* 비즈니스 필수 규칙("가격표를 확인하지 않고는 가격을 말하지 않음").

배포할 때마다 크리티컬에는 꼭 시뮬레이션을 돌리세요.