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

회귀 감지 방식

모든 해결된 개선이 시그니처 (다룬 시그널 패턴) 를 유지. Nora 가 그 시그니처에 대해 새 시그널 감시. 시그널이 회귀 로 플래그되는 조건:
  • 이전에 해결된 개선의 시그니처에 매치.
  • 그 개선의 배포 시간 후 발화.
  • 같은 Flow 에서 (Flow 안의 회귀가 Flow 간보다 훨씬 흔함).
회귀 플래그는 정규 시그널 그룹화에 추가적 — 회귀도 여전히 자체 클러스터의 정규 시그널.

회귀 뷰

시그널의 필터 뷰: Signals → Regressions. 표시:
  • 회귀된 시그널.
  • 그것을 고쳤다고 여겨진 개선 (개선 이력 링크와 함께).
  • 회귀가 나타난 버전.
  • 수정과 회귀 사이 일수 갭.

회귀가 왜 일어나나

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

무엇을 할지

  1. 실제 회귀인지 확인 (그냥 오래된 시그니처 매치가 아님).
  2. 무엇이 바뀌었는지 보기 — flow diff, 데이터 변경, 외부 발표.
  3. 수정을 넓히거나 재적용 — 보통 처음부터가 아니라 개선을 정제.
수정이 프롬프트 변경이었고 누군가 프롬프트를 편집했으면 revert 또는 재구성. 수정이 데이터 추가였고 데이터가 제거됐으면 복원. 수정이 너무 좁았으면 회귀를 새 예로 사용해 더 넓은 패턴으로 개선 플로우 재실행.

회귀 알림

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

회귀 방지

가장 깨끗한 방지: retention 테스트. 개선을 해결할 때 관련 실패 트레이스를 retention 데이터셋 으로 저장하고 모든 시뮬레이션 실행에 실행 (시뮬레이션 참고). 이 테스트를 깨는 미래 변경은 배포 전 잡힘. 개선 플로우가 큰 클러스터를 해결할 때 기본으로 이걸 제안.