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

# 회귀

> 이전에 고친 문제가 돌아옴. 빠르게 잡기.

가장 무서운 시그널은 이미 해결한 줄 알았던 것. **회귀 감지** 가 이것 특화 감시 — 이전에 고친 것과 비슷해 보이는 새 시그널.

## 회귀 감지 방식

모든 해결된 개선이 시그니처 (다룬 시그널 패턴) 를 유지. Nora 가 그 시그니처에 대해 새 시그널 감시.

시그널이 **회귀** 로 플래그되는 조건:

* 이전에 해결된 개선의 시그니처에 매치.
* 그 개선의 배포 시간 후 발화.
* 같은 Flow 에서 (Flow 안의 회귀가 Flow 간보다 훨씬 흔함).

회귀 플래그는 정규 시그널 그룹화에 추가적 — 회귀도 여전히 자체 클러스터의 정규 시그널.

## 회귀 뷰

시그널의 필터 뷰: **Signals → Regressions**. 표시:

* 회귀된 시그널.
* 그것을 고쳤다고 여겨진 개선 (개선 이력 링크와 함께).
* 회귀가 나타난 버전.
* 수정과 회귀 사이 일수 갭.

## 회귀가 왜 일어나나

흔한 원인:

* **Flow 변경이 수정 되돌림** — 누군가 같은 프롬프트나 설정을 재편집.
* **데이터 변경** — 문서가 superseded 되거나 제거되어 그 데이터에 의존한 수정 무너짐.
* **외부 변경** — 도구 API 바뀜, 모델 제공자 업데이트, 상류 소스 드리프트.
* **새 인접 행동** — Agent 가 새 영역으로 확장해 새 컨텍스트에서 옛 패턴 재생성.
* **수정이 너무 좁음** — 개선이 특정 경우 커버했지만 약간 다른 변형 놓침.

회귀 뷰가 수정과 회귀 출현 사이 무엇이 바뀌었는지 기반으로 Nora 의 최선 원인 추측 표시.

## 무엇을 할지

1. **실제 회귀인지 확인** (그냥 오래된 시그니처 매치가 아님).
2. **무엇이 바뀌었는지 보기** — flow diff, 데이터 변경, 외부 발표.
3. **수정을 넓히거나 재적용** — 보통 처음부터가 아니라 개선을 정제.

수정이 프롬프트 변경이었고 누군가 프롬프트를 편집했으면 revert 또는 재구성. 수정이 데이터 추가였고 데이터가 제거됐으면 복원. 수정이 너무 좁았으면 회귀를 새 예로 사용해 더 넓은 패턴으로 개선 플로우 재실행.

## 회귀 알림

회귀는 기본 고우선순위. 회귀 시그널 특화 Slack/이메일 알림 켜기 — 시그널 설정 → **Regression alerts**. 잡음 추가 안 함 (회귀 드묾) 하지만 즉시 듣고 싶을 것.

## 회귀 방지

가장 깨끗한 방지: **retention 테스트**. 개선을 해결할 때 관련 실패 트레이스를 **retention 데이터셋** 으로 저장하고 모든 시뮬레이션 실행에 실행 ([시뮬레이션](/ko/reliable/simulation/regressions) 참고). 이 테스트를 깨는 미래 변경은 배포 전 잡힘.

개선 플로우가 큰 클러스터를 해결할 때 기본으로 이걸 제안.