다른 도구의 점수에 대한 두 번째 의견

평가 점수가 올랐습니다. 진짜일까요? 그리고 그것을 측정한 심사 모델을 믿을 수 있을까요? 이미 다른 도구로 평가하고 있다면, 변경 전과 후의 케이스별 결과를 그 도구에서 내보내십시오. Oloproof는 아무것도 다시 실행하지 않고 그 결과로 두 질문에 모두 답합니다.

읽는 것

시스템 버전마다 파일 하나, CSV 또는 JSON Lines 형식이며, 케이스와 기준의 조합마다 행 하나입니다.

그 밖에는 아무것도 읽지 않으며, 다른 열이 있는 파일은 거부됩니다. 파일은 케이스 id와 점수만 담으며, 질문이나 답변, 그 밖의 어떤 내용도 담지 않습니다. 아래의 레시피가 각 도구의 결과를 이 파일로 바꿉니다.

실행하기

oloproof init --example second-opinion second-opinion
cd second-opinion

이 예제에는 지원 어시스턴트가 150개 질문에 대해 보인 충실성을, 프롬프트 변경 전과 후에 대해 다른 도구의 심사 모델이 채점한 그대로 내보낸 파일 두 개가 들어 있습니다. 0에서 1 사이의 점수와, 0.7에서의 통과 또는 실패입니다. make_exports.py는 그 파일들을 쓴 시뮬레이션입니다. 평균 점수는 약 0.02 올랐습니다.

oloproof scores import before.csv after.csv --policy release.yaml

faithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.

각 파일이 실행 하나가 되었고, 두 실행이 케이스별로 비교되었습니다. 답은 두 부분으로 나뉩니다.

• 진짜인가? 아직은 아닙니다. 점수는 0.023 올랐지만, 구간은 0.024 낮은 쪽에서 0.068 높은 쪽까지 걸쳐 있습니다. 질문 150개로는 이만큼 작은 변화를 잡음과 구별할 수 없습니다. 심사 모델이 통과시키는 답변의 비율은 5.3포인트 올랐고, 그 구간은 6.9포인트 낮은 쪽에서 18.0포인트 높은 쪽까지입니다.
• 심사 모델을 믿을 수 있는가? 아무도 확인하지 않았습니다. release.yaml은 사람의 레이블이 심사 모델을 측정한 뒤에야 그 심사 모델이 릴리스를 결정하게 합니다(require_validated_evaluators: true). 그래서 두 규칙 모두 구간에 이르기 전에 evaluator_not_validated에서 멈춥니다.

심사 모델이 확인된 것처럼 가정하고 앞의 절반만 보려면 다음과 같이 합니다.

oloproof scores import before.csv after.csv --policy statistics-only.yaml

  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero

CI에서는 --summary markdown >> "$GITHUB_STEP_SUMMARY"를 추가하세요. 그러면 풀 리퀘스트가 "Is it real?"와 규칙마다 한 줄로 시작하며, 각 줄은 "not established"와 그 이유를 말하고, 종료 코드는 그대로입니다. 가져오기 자체의 줄은 표준 오류로 가므로 요약에는 답만 들어갑니다(CI).

--policy가 없으면 이 명령은 비교를 보고할 뿐 아무것도 결정하지 않습니다. 파일이 하나이면 그 실행을 보고하며, --policy는 정책의 실행 규칙으로 그 실행에 게이트를 겁니다.

심사 모델 확인하기

가져온 실행의 케이스에서 무작위로 뽑은 표본에 사람들이 심사 모델의 판정을 보지 않은 채(블라인드) 레이블을 붙이고, Oloproof는 그 레이블에 대조해 심사 모델을 측정합니다.

oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME

표본에는 각 케이스의 id가 표시되며, 심사 모델의 판정은 전혀 표시되지 않습니다. 레이블러는 케이스를 보관하고 있는 도구에서 그 id로 케이스를 읽고, passed에 pass 또는 fail을 씁니다. 평가기의 id는 oloproof evaluators list가 알려 줍니다. 검증되고 나면, 그 심사 모델을 읽는 규칙은 근거만으로 결정합니다.

레이블은 통과 또는 실패이므로, 레이블이 확인하는 것은 심사 모델의 통과 또는 실패 판정이지 점수가 아닙니다. 예제가 faithfulness_passed로 하듯이 판정을 점수 옆에 함께 가져오십시오. 그것이 사람이 검증할 수 있는 기준입니다.

사용하는 도구에서

예제의 recipes/ 폴더에는 도구마다 짧은 스크립트가 하나씩 들어 있습니다. 각 스크립트는 그 도구의 결과를 읽고, id와 점수만 남겨 파일을 씁니다. 버전마다 하나씩 실행한 다음, 두 파일을 가져오십시오.

레시피는 2026년 10월 16일에 공개된 각 도구의 SDK(DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2)를 따르며, 그런 형태의 결과로 테스트했지만 실제 계정에 대해서는 테스트하지 않았습니다. 도구가 필드 이름을 바꾸면 깨지는 것은 그 레시피이지 가져오기가 아닙니다. 계약은 레시피가 쓰는 파일입니다.

파일이 지켜야 할 것

• 한 파일에만 있는 케이스는 다른 쪽에서 누락으로 세어지고 최악의 값으로 범위가 정해집니다. 다른 케이스와 짝지어지는 일은 결코 없습니다.
• 한 케이스와 기준에 대한 두 번째 행, score_min과 score_max를 벗어난 점수, 점수와 통과 또는 실패를 모두 가진 행, 그리고 한 파일에서는 점수이고 다른 파일에서는 통과 또는 실패인 기준은 그 행을 지목하며 거부됩니다.
• 비교하는 파일들은 각 기준의 척도와 심사 모델이 일치해야 합니다. 두 심사 모델의 점수는 두 개의 측정 도구이며, 그 차이의 일부는 측정 도구의 차이가 됩니다.
• 각 파일은 그 내용으로 식별되는 시스템 버전입니다. 같은 파일을 다시 가져오면 저장된 것을 재사용합니다. 아무것도 실행되지 않으므로, 어떤 재실행도 가져온 점수를 재현하거나 바꿀 수 없습니다.
• --tool은 점수의 출처를 기록하고, --name은 각 파일의 시스템에 이름을 붙입니다. 둘 다 실행과 함께 보관됩니다.

아직 만들어지지 않은 것

• 도구 고유의 내보내기 형식을 직접 읽기. 레시피가 그것을 위의 파일로 바꿉니다.
• 아무것도 설치하지 않고 호스팅 사이트에 파일 업로드하기.
• 심사 모델의 통과 또는 실패 판정이 아닌, 그 점수를 검증하기.

다음 단계

• 후보를 기준선과 비교하기는 짝지은 비교가 무엇을 읽는지 다룹니다.
• 비교 규칙은 우월성, 비열등성, 동등성을 다룹니다.
• 심사 모델은 심사 모델이 게이트를 걸 수 있기 전에 사람과 대조해 어떻게 측정되는지 다룹니다.