스스로를 속이지 않고 LLM 프롬프트를 A/B 테스트하는 방법
예전에 고객 지원 어시스턴트를 만들었을 때, 저는 성공할 것이라고 확신했습니다. 30개의 테스트 케이스를 실행했고, 새로운 프롬프트의 점수가 더 높게 나와서 그대로 배포했습니다.
하지만 6시간 후, 고객 지원 대기열은 불만 사항으로 가득 찼습니다. 그날 밤 바로 변경 사항을 롤백해야만 했습니다.
더 높은 점수는 가짜였습니다. 30개의 예시만으로는 실제 개선과 운을 구분하기에 충분하지 않았습니다. 그 숫자는 그저 노이즈에 불과했습니다.
그런 실수를 하지 않고 프롬프트를 테스트하는 방법은 다음과 같습니다.
작은 테스트로는 큰 변화만 포착할 수 있습니다. 미세한 개선을 찾고 싶다면 훨씬 더 많은 예시가 필요합니다. 아주 작은 변화를 찾아내려면 천 개 이상의 예시가 필요할 수도 있습니다.
두 버전 모두에 동일한 질문을 사용하세요. 버전 A에는 한 그룹의 질문을, 버전 B에는 다른 그룹의 질문을 주지 마세요. 어떤 질문은 다른 질문보다 더 어렵습니다. 만약 버전 B가 쉬운 질문들을 받게 된다면, 실제로는 성능이 더 나쁘더라도 결과가 더 좋아 보일 수 있습니다. 두 버전 모두 정확히 동일한 질문 세트를 통과시켜야 합니다.
평균뿐만 아니라 범위를 확인하세요. 평균값만으로는 개선의 폭이 얼마나 큰지 알 수 없습니다. 예상되는 최소 개선치와 최대 개선치의 범위를 보고하세요. 만약 그 범위에 0이 포함되어 있다면, 배포하지 마세요.
적절한 채점 방식을 선택하세요. • 절대적인 품질을 위해서는 체크리스트를 사용하세요. • 어조나 유용성 같은 모호한 품질을 위해서는 사이드 바이 사이드(side-by-side) 비교를 사용하세요.
여러 버전을 테스트할 때는 밴딧(bandit)을 사용하세요. 세 개 이상의 버전이 있고 사용자의 불편을 최소화하고 싶다면 밴딧을 사용하십시오. 밴딧은 학습을 통해 승리한 버전으로 더 많은 트래픽을 보냅니다. 이를 통해 사용자가 몇 주 동안 나쁜 답변을 보게 되는 상황을 방지할 수 있습니다.
다음과 같은 함정을 피하세요:
- 범위 없이 평균만 비교하는 것.
- 버전마다 서로 다른 질문 그룹을 사용하는 것.
- 테스트 중간에 채점 방식을 바꾸는 것.
- 숫자가 좋아 보인다고 해서 바로 테스트를 중단하는 것.
- 너무 많은 지표를 동시에 관찰하는 것. 이는 가짜 승리를 발견할 확률을 높입니다.
- 인간의 판단과 대조하여 검증하기 전에 채점 방식을 신뢰하는 것.
어려운 점은 테스트를 실행하는 것이 아닙니다. 결과가 진짜인지 아는 것이 진짜 어려운 부분입니다.
Source: https://dev.to/kartik-nvjk/how-i-ab-test-llm-prompts-without-fooling-myself-528f
Optional learning community: https://t.me/GyaanSetuAi