평가 세트(eval set)에 합성 데이터(synthetic data)를 추가했습니다. 통과율(pass rate)은 올라갔지만, 운영

우리는 더 큰 평가 세트(eval set)가 필요했고, 그래서 직접 생성했습니다. 모델이 우리 트래픽과 유사해 보이는 수천 개의 테스트 케이스를 작성했고, 이를 바탕으로 점수를 매겼더니 통과율(pass rate)이 올라갔고 기분이 좋았습니다. 하지만 그 후, 합성 세트가 잘 처리한다고 말했던 바로 그 입력값들에 대해 운영 장애(production incidents)가 발생했습니다. 테스트 세트는 커졌지만, 동시에 그 예측 가치(predictive value)는 떨어졌습니다.

이것이 합성 평가 데이터(synthetic eval data)의 함정이며, 이는 도구(tooling)의 문제가 아닙니다. 이제 케이스를 생성하는 것은 쉽습니다. 모든 프레임워크가 수천 개씩 제공할 것입니다. 어려운 부분, 즉 어떤 생성기(generator)도 대신 해주지 않는 부분은 합성 세트가 실제로 들어오는 트래픽과 유사하게 동작한다는 것을 증명하는 것입니다. 당신의 분포(distribution)와 일치하지 않는 테스트 세트는 운영 환경(production)의 축소판이 아닙니다. 그것은 별개의 테스트이며, 운영 환경이 실패하는 동안에도 통과할 수 있습니다.

그래서 저는 평가 데이터를 생성하는 도구들을 비교할 때, 얼마나 많은 케이스를 뱉어내는지 또는 프롬프트(prompt)가 얼마나 깨끗한지로 등급을 매기지 않습니다. 저는 단 하나의 질문으로 등급을 매깁니다. '생성된 세트가 생성된 수치를 신뢰하기 전에, 그것이 현실과 유사한지 확인하는 데 얼마나 도움이 되는가?'

정확하게 명시된 기준

합성 평가 세트(synthetic eval set)는 두 가지 조건이 충족될 때 신뢰할 수 있습니다. 첫째, 커버리지(coverage): 케이스들이 지저분하고 드문 케이스들을 포함하여, 실제 트래픽이 포함하는 것과 거의 동일한 비율로 동일한 종류의 입력값들을 포괄해야 합니다. 둘째, 난이도 교정(difficulty calibration): 합성 케이스가 실제 케이스만큼 어려워야 하며, 그래야 합성 데이터에서의 통과율(pass rate)이 실제 데이터에서의 통과율을 추적할 수 있습니다.

두 가지 모두 측정 가능하지만, 기본적으로 측정되는 것은 아무것도 없습니다. 커버리지(Coverage)는 실제 입력과 합성 입력을 임베딩(embedding)하여 분포를 비교하거나, 양쪽 모두에 동일한 분류 체계(taxonomy)를 라벨링하여 히스토그램(histogram)을 비교함으로써 확인할 수 있습니다. 교정(Calibration)은 라벨링된 실제 데이터의 일부를 따로 떼어두고(hold out), 해당 데이터에 대한 모델의 통과율이 합성 세트의 통과율 근처에 도달하는지 확인함으로써 확인할 수 있습니다. 만약 이 두 수치가 갈라진다면, 합성 세트는 당신에게 거짓말을 하고 있는 것이며, 아무리 양을 늘려도 해결되지 않습니다.

이것이 아래의 모든 내용을 바라보는 관점입니다.

생성기(Generators)가 검증에 얼마나 도움이 되는가

DeepEval (Synthesizer). 강력하고 제어 가능한 생성 능력을 갖추고 있습니다. 문서로부터 또는 처음부터 테스트 케이스를 구축하며, 진화(evolution)와 복잡도(complexity)를 조절할 수 있는 노브(knobs)를 제공합니다. 생성 품질은 좋습니다. 하지만 실제 트래픽(real traffic)과의 분포 일치 여부(distribution-match check)를 자동으로 제공하지는 않습니다. 즉, 생성한 후에는 사용자가 직접 현실성(realism)을 검증해야 합니다. 합성 데이터 평가 관련 문헌, 예를 들어 생성된 지시문(instructions)을 교정하지 않으면 다양성과 난이도 측면에서 드리프트(drift)가 발생한다는 점을 솔직하게 밝힌 Self-Instruct 연구(Wang et al., arXiv:2212.10560)와 함께 읽어볼 가치가 있습니다.

Promptfoo. 데이터셋 및 테스트 케이스 생성이 CI 우선(CI-first) 도구에 통합되어 있어, 생성된 케이스를 게이트(gate)에 즉시 투입할 수 있습니다. 파이프라인에 빠르게 대량의 데이터를 확보하는 데 편리합니다. 하지만 현실성 문제는 여전히 사용자의 몫입니다. 생성하고 실행은 해주지만, 생성된 세트의 분포를 운영 환경(production)과 비교해주지는 않습니다.

Giskard. 리스크(risk) 관점에서 접근하여, 평균적인 트래픽을 반영하기보다는 실패 사례를 드러내기 위해 적대적 사례(adversarial cases)와 엣지 케이스(edge cases)를 생성합니다. 이는 무엇이 고장 나는지를 찾아낸다는 점에서 다르고 유용한 목표이지만, 스트레스 세트(stress set)와 대표 세트(representative set)를 혼동해서는 안 됩니다. Giskard 스타일의 프로브(probes)로만 구축된 평가 세트는 하드 테일(hard tail, 극단적 사례)을 과잉 대표하게 되는데, 이는 시스템을 강화(hardening)하는 데는 훌륭하지만 실제 환경의 통과율(pass rate)을 추정하는 데는 오해를 불러일으킬 수 있습니다.

Ragas. RAG(Retrieval-Augmented Generation)에 특화되어 있으며, 멀티홉 질문(multi-hop questions)을 포함하여 사용자의 문서로부터 질문-답변 테스트 세트를 생성합니다. 시스템이 검색(retrieval) 중심이라면 적합한 도구입니다. 다만 생성된 질문 역시 동일한 커버리지 체크(coverage check)가 필요합니다. 사용자가 소유한 문서의 분포는 사용자가 실제로 묻는 질문의 분포와 동일하지 않기 때문입니다.

Future AGI. 이것이 기존과 다르게 수행하는 점은 생성기 (generator) 자체가 아니라 통합 (integration)입니다. 이는 엔드 투 엔드 (end-to-end) 오픈 소스 플랫폼이며, 합성 데이터 생성 (synthetic data generation)이 평가 (evals)를 실행하고 트레이스 (traces)를 보유하는 동일한 데이터셋 (Datasets) 및 평가 표면 (evaluation surface) 내에 존재합니다. 따라서 생성된 세트, 이를 점수화하는 평가 (eval), 그리고 이를 검증할 운영 트레이스 (production traces)가 세 곳이 아닌 한 곳에 모이게 됩니다. 리포지토리는 github.com/future-agi/future-agi 입니다. 이것이 무엇을 제공하고 무엇을 제공하지 않는지 명확히 해야 합니다. 이것은 다른 도구들과 마찬가지로 합성 세트 (synthetic set)가 운영 환경 (production)과 일치한다는 것을 자동으로 증명해주지는 않으며, 그 확인 작업은 여전히 사용자가 수행해야 하는 방법론 (methodology)입니다. 이 도구가 제거하는 것은 연결 (stitching) 작업입니다. 왜냐하면 생성기 (generator), 평가 라이브러리 (eval library), 트레이싱 도구 (tracing tool) 사이에서 CSV 파일을 내보내는 것보다, 합성 세트 (synthetic-set)의 동작과 실제 트레이스 (real-trace)의 동작이 이미 동일한 시스템 내에 존재할 때 두 가지를 비교하는 것이 훨씬 쉽기 때문입니다. 순수 생성 제어 가능성 (raw generation controllability) 측면에서, DeepEval의 Synthesizer는 최소한 그만큼 설정이 가능합니다.

다섯 가지 도구 전체에 대한 솔직한 요약은 다음과 같습니다: 모든 도구가 생성 (generates)은 수행하지만, 단 하나도 기본 첫 단계로서 현실성 (realism)을 검증 (validates)하지는 않습니다. 검증은 작업 (work)이며, 어떤 생성기 (generator)를 선택하든 그것은 사용자의 몫입니다.

내가 실제로 실행하는 절차

도구는 차치하고, 이것이 순서이며, 1단계와 4단계는 팀들이 건너뛰는 단계입니다.

1. 실제 샘플을 추출합니다. 수백 개의 실제 운영(production) 입력값과, 가능하다면 그에 따른 결과값(outcomes)을 준비합니다.
2. 귀하의 형태에 적합한 도구를 사용하여 합성 데이터 세트(synthetic set)를 생성합니다.
3. 실제 입력값과 합성 입력값을 모두 임베딩(embed)하여 분포(distributions)를 비교합니다. 만약 합성 데이터 세트가 실제 트래픽이 없는 곳에 클러스터(cluster)를 형성하거나, 실제 트래픽이 가진 클러스터를 놓치고 있다면, 생성 프롬프트(generation prompts)를 수정하고 다시 생성합니다.
4. 라벨이 지정된 실제 데이터 일부(labeled real slice)를 별도로 떼어 놓습니다(hold out). 모델을 이 데이터와 합성 데이터 세트 모두에 대해 평가(score)합니다. 만약 두 데이터의 통과율(pass rates) 차이가 몇 퍼센트 이상 벌어진다면, 해당 합성 데이터 세트는 보정(miscalibrated)이 잘못된 것이며, 그 통과율은 아무런 대리 지표(proxy)로서의 가치가 없습니다. 두 수치가 수렴할 때까지는 합성 데이터를 신뢰하지 마십시오.
5. 그 이후에야 비로소 합성 데이터 세트를 볼륨(volume) 확보용으로 사용하고, 실제 데이터 일부를 재확인을 위한 앵커(anchor)로 유지합니다.

생성기(generator)는 2단계와 3단계를 얼마나 수월하게 만드는지를 결정할 뿐입니다. 1, 4, 5단계를 수행해야 한다는 사실 자체를 바꾸지는 못합니다.

FAQ

왜 그냥 실제 데이터를 사용하고 합성 데이터를 완전히 건너뛰지 않나요?
실제 데이터는 종종 부족하거나, 불균형하거나, 민감하기 때문입니다. 또한 중요한 희귀 사례(rare cases)를 충분히 확보할 수 없습니다. 합성 데이터는 이러한 공백을 메우는 합리적인 방법입니다. 핵심은 합성 데이터를 피하는 것이 아니라, 그것이 만들어내는 수치를 신뢰하기 전에 반드시 검증하는 것입니다.

합성 데이터 세트를 검증하기 위해 실제 데이터가 얼마나 필요한가요?
사용 가능한 신뢰 구간(confidence interval) 내에서 분포와 통과율을 추정할 수 있을 만큼이면 충분합니다. 이는 보통 수만 개가 아니라 수백 개의 예시 정도입니다. 검증용 데이터 일부(validation slice)는 검증 대상인 합성 데이터 세트보다 크기가 작습니다.

가장 흔하게 발생하는 단일 실패 사례는 무엇인가요?
보정(miscalibration)의 어려움입니다. 생성된 사례들은 쉬운 쪽으로 치우치는 경향이 있습니다. 모델은 깔끔하고 모호하지 않은 입력을 작성하지만, 실제 사용자는 그렇지 않기 때문입니다. 이 경우 통과율은 매우 좋게 보이지만 아무런 의미가 없습니다. 별도로 떼어 놓은 실제 데이터 일부(held-out real slice)가 바로 이 문제를 잡아냅니다.

적대적 사례(adversarial cases)를 생성하는 것도 합성 평가 세트(synthetic eval set)에 해당하나요?
그것은 스트레스 테스트 세트(stress set)이지, 대표성 있는 세트(representative set)가 아닙니다. 시스템을 강화(harden)하는 데 사용하되, 실제 세계의 통과율을 추정하는 데 사용하지는 마십시오. 두 세트와 두 가지 질문을 분리하여 유지하십시오.

공개 질문 (Open question)

분포 일치 (Distribution-match) 방식은 진정으로 새로운 기능(feature)에 대해 '닭과 달걀'의 문제에 직면합니다. 이러한 기능은 아직 실제 트래픽(real traffic)이 거의 없거나 전혀 없기 때문에, 합성 세트(synthetic set)를 검증할 대상이 존재하지 않습니다. 즉, 생성된 데이터를 가장 확인하기 어려운 시점에 정확히 그 데이터를 신뢰해야만 하는 상황에 놓이게 됩니다. 이에 대해 저는 명확한 해답을 가지고 있지 않습니다. 제가 드릴 수 있는 최선의 방법은, 완전히 새로운 기능에 대한 합성 통과율(synthetic pass rate)을 측정치(measurement)가 아닌 스모크 테스트 (smoke test)로 취급하고, 실제 트래픽이 유입되는 즉시 공격적으로 재검증(re-validate)하는 것입니다. 만약 비교할 실제 데이터가 있기 전까지 합성 세트가 얼마나 틀릴 수 있는지 그 범위를 제한할 수 있는 원칙적인 방법이 있다면, 저는 진심으로 그것을 보고 싶습니다.