프롬프트 개선 검증하기

프롬프트 변경은 모델 교체보다 위험이 작습니다. 되돌리기 쉽고, 비용 구조도 그대로입니다. 그래서 트래픽을 반씩 나눠 표본을 빨리 모으는 쪽이 유리합니다. “요약이 밋밋하다”는 피드백을 받고 고친 프롬프트를 예로 듭니다.

요청까다로운 입력 가져오기 테스트프롬프트만 바꿔 비교 라우팅트래픽 반씩 배정 비교행동으로 판정

불만이 나온 그 입력

요청에서 피드백의 원인이 됐을 법한 호출, 까다로웠던 호출을 찾아 “테스트에서 열기”로 가져옵니다. 불만이 나온 바로 그 입력이 시험 케이스가 되는 것이 이 단계의 요점입니다.

프롬프트만 바꿔 나란히

테스트에서 현재 옵션과 고친 프롬프트를 나란히 돌립니다. 이때 모델과 파라미터는 그대로 두세요. 여러 가지를 한꺼번에 바꾸면 나중에 무엇이 효과를 냈는지 알 수 없습니다.

응답이 눈에 띄게 나아졌다면 “옵션으로 저장”합니다. 차이를 모르겠다면 여기서 멈춰도 됩니다. 배포할 뻔한 무의미한 변경 하나가 걸러진 것입니다.

반씩 나눠 표본 모으기

라우팅에서 두 옵션에 트래픽을 반씩 줍니다. 표본이 두 배 빨리 쌓입니다. 신중하고 싶다면 10%부터 시작해도 됩니다. 어느 쪽이든 첫날은 비교에서 두 옵션의 에러율만 확인해 두세요.

좋아졌다는 증거

비교에서 성공 지표로 두 옵션을 견줍니다. “요약이 좋아졌다”의 증거는 좋아 보이는 문장이 아니라 요약을 복사하고 이어서 구매하는 사용자의 비율입니다. 기능과 가까운 행동(요약 복사)이 변화에 민감해서 판정이 빠릅니다.

저표본 경고가 사라진 뒤에도 두 선이 계속 엎치락뒤치락하면 그 변경은 사용자에게 의미 있는 차이가 아니었던 것입니다. 한쪽이 확실히 앞서면 100%로 올리고, 계속 겹친 채라면 고친 프롬프트를 0으로 내리고 다음 후보로 넘어가세요.