얼마 전 저는 고객 지원 어시스턴트(support assistant)를 구축하던 중, 단순해 보이는 질문에 직면했습니다. '이 새로운 버전의 프롬프트가 정말 기존 버전보다 나은가?'라는 질문이었죠. 그래서 저는 당연한 일을 했습니다. 30개의 테스트 케이스를 작성하고, 두 프롬프트를 모두 실행한 뒤, 새 버전의 점수가 약간 더 높게 나오는 것을 확인하고 배포했습니다.

반나절 동안은 기분이 좋았습니다. 하지만 고객 지원 대기열(support queue)이 불만 사항으로 가득 차기 시작했고, 그날 저녁 저는 Slack 스레드에서 변경 사항을 롤백(roll back)하고 있었습니다.

점수의 상승은 결코 실제가 아니었습니다. 테스트 규모가 너무 작아서 아주 미세하고 진정한 개선을 운(luck)과 구별해낼 수 없었기에, 그 수치는 내내 노이즈(noise)에 불과했습니다. 그 하나의 교훈이 아래 설명할 거의 모든 내용의 바탕이 되었습니다. 이것은 제가 현재 신봉하고 있는 가이드이며, 쉬운 언어로 설명하겠습니다. 여러분도 저와 같은 저녁을 겪지 않기를 바랍니다.

첫째, 당신의 테스트가 얼마나 작은 변화까지 감지할 수 있는지 파악하세요

작은 테스트는 큰 차이만을 잡아낼 수 있습니다. 실제 개선 사항이 미미하다면, 30개의 예시는 당신이 우연히 선택한 예시들의 무작위적인 흔들림(random wobble)과 개선 사항을 구별해낼 수 없습니다. 다시 실행하면 결과가 뒤집히는 경우가 많습니다.

그래서 저는 이제 무엇인가를 테스트하기 전에 두 가지 질문에 답합니다:

• 실제로 배포할 가치가 있는 가장 작은 개선 수준은 무엇인가?
• 그 정도로 작은 개선을 확인하기에 충분한 예시를 가지고 있는가?

함정은 숫자가 얼마나 빠르게 증가하느냐에 있습니다. 절반 크기의 개선을 포착하려면 약 4배 더 많은 예시가 필요합니다. 실제로 30개의 예시는 10포인트 미만의 변동은 거의 감지할 수 없습니다. 4포인트의 개선을 확인하는 데는 수백 개의 예시가 필요했습니다. 2포인트의 개선에는 천 개 이상의 예시가 필요했습니다. 100개 미만이라면, 당신은 프롬프트가 아니라 스코어러(scorer)의 기분을 측정하고 있는 것입니다.

동일한 입력값에 대해 두 버전을 모두 테스트하세요

저의 다음 실수는 무해해 보였습니다. 버전 A에는 한 그룹의 질문을 주고, 버전 B에는 다른 그룹의 질문을 준 다음 평균을 비교한 것이었습니다. 하지만 어떤 질문들은 그냥 더 어렵습니다. 만약 B가 더 쉬운 그룹을 뽑았다면, 실제로는 더 나쁘더라도 더 좋아 보이게 됩니다.

해결책은 간단합니다. 두 버전 모두 정확히 동일한 질문들을 통과시키고, 한 번에 한 질문씩 비교하는 것입니다. 두 버전 모두 동일한 어려운 질문들에 직면하기 때문에 난이도 요소가 상쇄되며, 프롬프트 간의 실제 차이점만 남게 됩니다.

이를 통해, 그렇지 않았다면 4배나 더 많은 데이터가 필요했을 수백 개의 예시만으로도 결과를 신뢰할 수 있게 되었습니다. 유일한 비용은 모든 질문을 두 번 실행하는 것인데, 이는 질문을 4배로 수집하는 것보다 훨씬 저렴합니다.

단일 평균이 아닌 개선 범위를 설정하세요

단일 평균값은

전체 테스트를 기다릴 수 없을 때, 트래픽이 승자를 선택하게 하세요

비교해야 할 버전이 세 개였던 적이 있는데, 트래픽이 적은 기능의 경우 일반적인 테스트를 진행하면 몇 주가 걸렸을 것입니다. 그리고 그 시간 내내 세 개 중 두 개는 아마 더 성능이 나빴을 것이고, 여전히 실제 사용자들에게 노출되고 있었을 것입니다. 사용자들이 더 나쁜 답변을 받는 동안 한 달을 기다리는 것은 옳지 않았습니다.

그래서 저는 '밴딧 (bandit)'이라는 독특한 이름을 가진 방식을 사용했습니다. 일반적인 테스트는 모든 버전에 트래픽을 균등하게 배분하고 마지막에 승자를 결정하기 때문에, 테스트가 진행되는 내내 사용자 절반은 계속해서 더 약한 프롬프트를 받게 됩니다. 밴딧은 기다리지 않습니다. 결과가 들어오는 것을 지켜보면서, 앞서 나가는 쪽으로 조용히 더 많은 사람을 보내고 나머지에는 더 적은 사람을 보냅니다. 실행 시간이 길어질수록, 약한 버전을 경험하는 사용자는 점점 줄어듭니다.

이 이름은 도박에서 유래한 것입니다. 슬롯머신은 '외팔이 밴딧 (one-armed bandit)'이라 불렸으며, 이는 어떤 기계가 가장 많이 지급하는지 아직 모를 때 기계들 사이에서 선택해야 하는 오래된 퍼즐과 같습니다. 기계를 프롬프트 버전으로 바꾸면 그것이 바로 제 상황이었습니다.

함정은 깔끔한 수치를 얻을 수 없다는 점입니다. 의도적으로 약한 버전의 트래픽을 차단하기 때문에, 마지막에 'B가 A를 정확히 이만큼 이겼다'라고 말할 수 없습니다. 그래서 저는 세 개 이상의 버전이 있고, 약한 버전이라도 여전히 사용할 만하며, 전체 테스트를 기다리는 비용이 모호한 최종 판결을 받는 비용보다 클 때만 밴딧을 사용합니다. 경영진에게 방어할 수 있는 결과가 필요하거나, 단지 두 버전이 정면 승부를 벌이는 경우에는 다시 일반적인 테스트로 돌아갑니다.

때로는 직접 쓰는 것보다 변형(variants)을 생성하는 것이 더 낫습니다

오랫동안 저의 루프는 다음과 같았습니다: 열심히 고민하고, 새로운 버전을 하나 작성하고, 테스트하고, 승리하면 유지하는 것. 여기서 사각지대는, 직접 작성한 단 하나의 버전은 질문을 표현할 수 있는 모든 방법 중 아주 작은 조각에 불과하다는 점입니다.

신뢰할 수 있는 평가자 (scorer)와 레이블링된 예시들을 확보한 후에는, 도구가 탐색하도록 맡깁니다. 도구는 제가 직접 작성하는 것보다 훨씬 더 많은 수의 변형을 생성하고, 높은 점수를 받는 것들을 찾아냅니다. 그런 다음 저는 도구가 찾아낸 가장 좋은 후보를 가져와서, 이미 프로덕션 (production) 환경에서 사용 중인 것과 동일하게 신중한 비교를 수행합니다. 도구는 제가 할 수 없는 영역을 커버하며, 최종 결정은 여전히 A/B 테스트가 내립니다.

이러한 테스트를 조용히 망치는 실수들

여러분이 겪지 않도록 제가 빠졌던 몇 가지 함정들을 소개합니다:

• 범위(range)가 없는 평균값. 30개의 예시에서 나타나는 작은 상승은 결과의 탈을 쓴 노이즈 (noise)일 뿐입니다.
• 버전마다 질문 배치가 달라지는 것. 더 나은 프롬프트인지, 아니면 단순히 쉬운 질문 배치를 만난 것인지 구분할 수 없게 됩니다.
• 테스트 도중에 평가자 (scorer)를 교체하는 것. 그것은 동일한 테스트가 아니라 다른 테스트입니다. 먼저 평가자를 고정하세요.
• 결과가 좋아 보이는 순간 훔쳐보고 멈추는 것. 이는 존재하지 않았던 승리를 조작하는 행위입니다. 테스트를 실행하기 전에 언제 확인할지 결정하세요.
• 다섯 개의 "주요" 지표를 동시에 관찰하는 것. 다섯 개를 보면 순전히 운에 의해 하나가 승리처럼 보일 확률이 약 4분의 1에 달합니다. 처음부터 하나의 지표와 하나의 기준을 선택하세요.
• 평가자를 확인하기 전에 평가자를 신뢰하는 것. 자동 판정기가 신중한 인간의 판단과 일치하지 않는다면, 평가자 자체의 노이즈로 인해 결과가 뒤바뀔 수 있습니다.

이것이 가이드의 전부이며, 그 어떤 것도 특별히 영리한 내용은 아닙니다. 하지만 그것이 바로 핵심입니다. 어려운 부분은 테스트를 실행하는 것이 아니었습니다. 결과가 진짜인지 배우는 것이었으며, 이는 거의 매번 제가 찾고자 하는 것을 확인하기에 충분한 예시를 가지고 있었는지 여부로 귀결됩니다. 이 내용이 한곳에 정리되어 여러분의 시간을 한두 시간이라도 아껴주길 바랍니다. 만약 여러분이 직접 이러한 비교를 수행해 보셨다면, 오프라인 결과와 라이브 수치가 서로 갈라졌던 지점이 어디였는지 듣고 싶습니다. 저의 경우, 새로운 프롬프트가 답변해야 할 질문에 대해 거절을 시작하는 빈도가 거의 항상 그 지점이었습니다.