Skip to main content
신호가 입구고 개선이 출구입니다. 그 사이에 무슨 일이 벌어지는지 봅니다.

경로

단계마다 사람이 정하고, 뒤집고, 되돌릴 체크포인트가 있습니다.

단계별로

1. 신호 발화

사용자가 답변에 👎 를 누릅니다. 또는 검증이 응답을 막습니다. 또는 도구가 거듭 에러를 냅니다. 어떤 소스든 큐에 신호를 만듭니다.

2. 추리기

신호가 진짜인지 확인합니다(확인·묵음 참고). 묵음은 여기서 멈춥니다. 오탐은 더 나아가지 않습니다.

3. 묶기

신호가 들어오면서 클러스터에 합류합니다(클러스터 참고). 신호 하나는 데이터 한 점이고, 클러스터는 고칠 값이 있는 패턴입니다. 신호 하나를 바로 올릴 수도 있지만, 클러스터가 더 나은 바탕입니다. 낱개가 아니라 부류를 고치니까요.

4. 개선으로 올리기

클러스터(또는 신호)에서 Create Improvement를 누르면 개선 플로우가 열립니다.
  • 클러스터 맥락(신호, 근본 원인 가설, 샘플 실패).
  • 진단(실패 진단 참고).
  • 바꿀 제안 레버(레버 참고).

5. 제안

Nora가 후보 수정을 1~3개 제안합니다. 제안마다 이렇습니다.
  • 변경에 이름을 붙임(프롬프트 조정, 도구 설명 다듬기, 리트리벌 프리셋 변경, 새 메모리 룰 등).
  • diff를 보여줌. 정확히 무엇이 바뀌는지.
  • 영향을 예측함(비슷한 지난 개선을 근거로).
어느 제안을 테스트할지 고릅니다. 제안을 참고하세요.

6. 시뮬레이션

모든 제안을 클러스터의 신호와 더 넓은 데이터셋에 돌립니다. 지표는 이렇습니다. 예전에 실패하던 것 중 몇 개가 이제 통과하는지, 예전에 통과하던 것 중 몇 개가 이제 실패하는지(회귀), 비용과 지연 델타. 시뮬레이션Before/after를 참고하세요.

7. 승인

가장 나은 제안이 눈에 띄게 표시됩니다. 여러분(또는 다른 리뷰어)이 승인하면 변경이 Draft에 적용됩니다. 승인은 기본으로 사람이 거치는 게이트입니다. 시뮬레이션 결과가 탄탄한 저위험 변경은 자동으로 승인할 수 있습니다.

8. 배포

승인된 변경은 평소 배포 흐름을 탑니다. Draft에 적용한 뒤 Publish 합니다(배포 참고).

9. 지켜보기

배포한 뒤 클러스터가 다시 살아나는지 지켜봅니다. 패턴에 맞는 새 신호가 나오면 다시 열립니다(회귀). 30일 동안 안 나오면 클러스터를 해결로 닫습니다.

수정까지 걸리는 시간

대체로 이렇습니다.
  • 단순 프롬프트 수정 신호에서 배포까지 몇 분.
  • 피드백에서 나온 새 룰 몇 시간(테스트 → 승인 → 배포).
  • 리트리벌 프리셋 변경 몇 시간에서 며칠(더 넓은 시뮬레이션이 필요).
  • 새 데이터나 그래프 편집이 필요한 복잡한 수정 며칠.
목표는 복리입니다. 수정 하나가 다음을 알려 주고, 사이클이 짧아지고, 신호가 줄어듭니다.

수정이 안 먹히면?

안전밸브가 둘 있습니다.
  • 시뮬레이션이 잡음 제안이 아예 배포되지 않습니다. 다른 레버를 시도하세요.
  • 배포가 잡음 클러스터가 회귀로 다시 열립니다. 개선을 롤백(한 번 누르면 됨)하고 다시 시도합니다.
변경이 버전으로 관리되므로 롤백은 즉시입니다(롤백 참고).

다음 단계

데이터셋

수정을 정직하게 지켜 줄 테스트 케이스를 큐레이션합니다.

시뮬레이션

변경을 프로덕션에 내보내기 전 데이터로 돌립니다.

최적화

개선 플로우를 깊이 있게.