엔드투엔드 평가

엔드투엔드 평가 (End-to-End Evaluation)

RAG 애플리케이션의 나침반 구실을 하는 엔드투엔드 평가를 배워요. 평가용 데이터셋을 만들고, 정량적/정성적 평가 옵션을 고르고, 민감도 테스트로 문제를 발견하는 방법을 알아봅시다.

출처: 문서

본문

엔드투엔드 평가는 RAG 애플리케이션을 이끄는 신호여야 합니다. 즉, 데이터 소스와 쿼리 집합이 주어졌을 때 내 워크플로가 올바른 응답을 생성할까요?

초기에는 쿼리와 응답을 개별적으로 검사하는 것이 도움이 되지만, 더 많은 실패 사례와 엣지 케이스를 다루다 보면 각 쿼리를 개별적으로 보는 것이 더 이상 현실적이지 않을 수 있습니다. 대신 요약 메트릭 집합이나 자동 평가를 정의하고, 그것이 무엇을 말해주는지, 어디를 더 깊이 파봐야 할지에 대한 직관을 얻는 것이 도움이 될 수 있습니다.

평가 세트 구성하기

작지만 다양한 쿼리 집합으로 시작하고, 문제가 있는 쿼리나 상호작용을 발견하면서 더 많은 예제를 쌓아가는 것이 도움이 됩니다.

쿼리할 문서 집합이 주어지면 자동으로 데이터셋을 생성해 주는 몇 가지 도구를 만들었습니다. (아래 예제 참조)

미래에는 도구에 대해 자동으로 데이터셋을 만들 수도 있게 될 것입니다.

평가 옵션의 스펙트럼

정량적 평가는 정답이 있는 애플리케이션을 평가할 때 더 유용합니다. 예를 들어 계획이 주어졌을 때 도구 선택과 그 입력이 올바른지 검증하거나, 특정 정보를 검색하거나, 특정 스키마(예: JSON 필드)의 중간 출력을 생성하는 것을 시도하는 경우입니다.

정성적 평가는 도움이 되도록 의도된 긴 형식 응답을 생성할 때 더 유용하며, 반드시 완전히 정확할 필요는 없습니다.

메트릭, 저렴한 모델, 더 비싼 모델(GPT4), 인간 평가에 이르는 평가 옵션의 스펙트럼이 있습니다.

아래는 평가 모듈의 몇 가지 예시 사용법입니다.

발견 - 민감도 테스트 (Sensitivity Testing)

복잡한 워크플로에서는 흐름의 어떤 부분이 결과에 영향을 미치는지 불분명할 수 있습니다.

민감도 테스트는 개별적으로 더 철저히 테스트하거나 조정할 구성 요소를 선택하고, 데이터셋의 어떤 부분(예: 쿼리)이 문제가 있는 결과를 만들어내는지 파악하기 좋은 진입점이 될 수 있습니다.

민감도 테스트 같은 방법으로 문제를 자동으로 발견하는 방법에 대한 자세한 내용은 곧 제공될 것입니다.

전통적인 ML 도메인에서 이에 대한 예시는 Giskard입니다.

메트릭 앙상블링 (Metrics Ensembling)

특히 개발 세트가 커질수록 GPT-4로 평가를 수행하는 것은 비용이 들 수 있습니다.

메트릭 앙상블링은 더 약한 신호의 앙상블(exact match, F1, ROUGE, BLEU, BERT-NLI, BERT-similarity)을 사용해 골드 라벨(인간 라벨링/GPT-4)에 더 가까운 더 비싼 평가 방법의 출력을 예측합니다.

두 가지 목적을 위해 사용됩니다.

  1. 개발 단계에서 큰 데이터셋에 걸쳐 변경 사항을 저렴하고 빠르게 평가하기.
  2. 프로덕션 모니터링 단계에서 추가 평가(GPT-4 / 인간 알림)를 위해 이상값을 표시하기.

또한 메트릭 앙상블링이 해석 가능하기를 바랍니다. 상관관계와 가중치 점수가 어떤 메트릭이 평가 기준을 가장 잘 포착하는지 알려주어야 합니다.

방법론에 대한 자세한 내용은 향후 업데이트에서 다루겠습니다.

더 알아보기 (Learn more)