개선 제안

근본 원인이 밝혀지면 Nora가 제안을 만듭니다. 그 원인을 다룰 구체적인 변경이죠. 개선 하나당 보통 후보가 1~3개 나옵니다. 어느 걸 시뮬레이션하고 어느 걸 출시할지는 여러분이 고릅니다.

​

제안의 구성

제안마다 이런 게 담깁니다.

• 이름 사람이 읽을 짧은 요약(“리트리벌 키워드에 refund 동의어 추가”).
• 레버 시스템의 어느 부분을 바꾸는지(레버 참고).
• diff 정확히 무엇이 어떻게 바뀌는지, 줄 단위로.
• 근거 Nora가 왜 이게 근본 원인을 다룬다고 보는지.
• 예측 실패 클러스터와 홀드아웃에서 얼마나 나아질지. 비슷한 과거 개선을 근거로 삼습니다.
• 신뢰도 이게 먹힐 거라고 Nora가 얼마나 확신하는지.

핵심은 diff 입니다. 나머지는 그걸 이해할 맥락입니다.

​

제안 예시

리트리벌 미스 클러스터

• P1: 리트리벌 프리셋의 쿼리 확장에 “money back” 을 동의어로 추가.
• P2: 프리셋에서 refund-policy 태그를 1.3배 부스트.
• P3: Agent에 룰 추가. “사용자가 환불을 물으면 정책 청크를 항상 먼저 조회.”

프롬프트 클러스터

• P1: Agent 역할에 “항상 해당 정책 문서를 인용” 추가.
• P2: Agent 톤 지시를 면책 문구에 더 분명하도록 수정.

데이터 클러스터

• P1: 빠진 정보를 담은 새 문서를 넣기(자동 수정이 아니라 노트로 띄움).

​

제안 살펴보기

제안 뷰가 모든 후보를 나란히 보여줍니다. 제안을 누르면 전체 diff를 봅니다.

​

시뮬레이션

제안에서 Simulate를 누르면 클러스터와 더 넓은 데이터셋에 돌립니다. 결과가 제안 카드로 돌아와, 예측을 실제 측정 델타로 바꿔 놓습니다. 모든 제안을 한 번에 시뮬레이션할 수도 있고(비교 뷰는 Before/after 참고), 하나씩 할 수도 있습니다.

​

제안 손보기

시뮬레이션 전에는 모든 제안을 고칠 수 있습니다. 흔히 이렇게 손봅니다.

• diff를 좁히기(동의하지 않는, Nora가 덧붙인 부분을 뺌).
• 타겟 바꾸기(Agent B가 아니라 Agent A에 적용).
• 표현 다듬기(Nora가 제안한 프롬프트 변경을 여러분 식으로).

손본 내용은 추적되므로, 감사 기록에 Nora가 제안한 것과 여러분이 출시한 것이 나뉘어 남습니다.

​

거부

제안을 이유와 함께 거부합니다. 이 이유가 다음 제안 생성을 돕습니다. Nora가 비슷한 클러스터에 비슷한 제안을 피하게 되죠. 제안을 모두 거부하면 클러스터는 열린 채로 남습니다. 이럴 수 있습니다.

• 다시 진단하기(근본 원인이 틀렸을 수 있음).
• Draft에 수정을 손수 써넣기.
• 그냥 두기(아직 고칠 때가 아닌 문제도 있음).

​

이긴 제안

시뮬레이션이 끝나면 성능이 가장 좋은 제안에 “recommended” 배지가 붙습니다. 보통 홀드아웃 통과율이 가장 많이 오르고 회귀가 가장 적은 제안이죠. 물론 뒤집어도 됩니다. 추천은 제안이지 결정이 아닙니다. 특히 동점이거나 차이가 잡음 수준일 때 유용합니다.

​

이긴 제안을 고른 뒤

고른 제안은 승인으로 넘어갑니다(승인·배포 참고). 승인되면 diff가 Draft에 적용되고, 그다음 여러분이 배포합니다.