YoursSarcastically/eval-design

eval-design은(는) 무엇을 하나요?

당신은 제품이 아니라 측정을 설계하고 있습니다. 이 스킬의 출력물은 누군가가 회의실에서 방어할 수 있는 결정이지, 숫자가 아닙니다.

대부분의 경우 결정은 무엇을 다음에 수정할지입니다. 시스템만 순위 매기는 평가는 보고서일 뿐입니다. 하지만 가장 많은 비용을 유발하는 두 가지를 지목하고, 다시 실행했을 때 수정이 작동했음을 입증하는 평가는 개발 루프입니다. 두 번째를 위해 설계하세요 — 헤드라인 점수보다 실패 분류와 기준별 분석이 더 중요합니다. 왜냐하면 그것이 누군가가 행동할 수 있는 부분이기 때문입니다.

입장

네 가지 규칙입니다. 의견이며, 이 스킬의 핵심입니다.

1. 느낌 없음. "느낌이 더 좋다"는 결과가 아닙니다. 변경 사항을 고정된 집합에서 정의된 기준의 움직임으로 표현할 수 없다면 평가되지 않은 것입니다. 원한다면 출시하세요 — 테스트되었다고 주장하지 마세요.

2. 모든 기준은 논쟁 가능해야 합니다. 신중한 두 검토자가 반대쪽에 설 수 없는 기준은 아무것도 측정하지 않는 것입니다. "출력물이 도움이 되는가?"는 기준이 아닙니다. "응답에 환불 기간이 일 단위로 명시되어 있는가?"가 기준입니다. 루브릭의 모든 기준은 해결하기 위해 작성된 특정 논쟁을 담고 있습니다 — references/rubric-design.md를 참조하세요.

3. LLM-as-judge는 기본값이 아닙니다. 판단자는 자체 오류율을 가진 시스템이며, 검증되지 않은 판단자는 그 오류를 헤드라인 숫자에 섞어 넣습니다. 인간이 먼저 레이블링하고, 판단자는 그 레이블에 대해 교정되며, 일치도는 판단자가 생성한 모든 결과 옆에 게시됩니다. references/judges.md를 참조하세요.

4. 기준선을 보고하거나 평가는 마케팅입니다. 정규식, 키워드 규칙, 현재 프로덕션 시스템, 아무것도 하지 않음. 출시된 AI 기능의 약 1/3이 최소 하나의 기준에서 비용이 거의 들지 않는 무언가에 패배하며, 그 사실을 채용 관리자나 부사장보다 먼저 알아내야 합니다.

다음 두 가지 구조적 규칙이 이어집니다:

• 게이트는 바닥이지 가중치가 아닙니다. 안전, 법률 또는 신뢰 기준은 평균 성능과 교환되지 않습니다. 바닥 아래의 시스템은 어떤 가격에도 후보가 아닙니다. 가중 평균은 정확히 이것을 숨깁니다.
• 신뢰 구간이 없으면 순위 매기지 마십시오. n=150에서 3포인트 차이는 노이즈입니다. 노이즈 내에서 시스템 순위를 매기는 것은 평가 작업이 읽는 사람을 오도하는 가장 흔한 방법입니다.

워크플로

이 순서대로 작업하세요. 점수 매기기로 건너뛰지 마세요 — 모든 평가 실패는 그 위에서 건너뛴 것으로 거슬러 올라갑니다.

1. 결정을 찾으세요. 결과에 따라 무엇이 바뀌나요? "어떤 모델을 출시할까", "이것이 무감독으로 갈 수 있을까", "프롬프트 변경이 회귀했는가". 아무것도 바뀌지 않으면 멈추고 그렇게 말하세요 — 이것은 프로세스에서 가장 가치 있는 순간이며, 정직한 대답은 때로 "평가가 필요하지 않습니다"입니다.
2. 실패 분류를 먼저 작성하세요. 기준 전에. 실제 출력 30–50개를 수집하고, 각각을 읽고, 무엇이 잘못되었는지 군집화하세요. 관찰된 실패에서 도출된 기준이 상상에서 도출된 기준보다 항상 낫습니다. → references/failure-taxonomy.md
3. 분류를 기준으로 바꾸세요. 각각에 가중치, 논쟁, 선택적으로 게이트를 할당하세요. → references/rubric-design.md
4. 골든 세트를 구축하세요. 계층화되고, 적대적이며, 버전 관리되고, 인간이 실제로 레이블링할 수 있을 만큼 작아야 합니다. → references/golden-sets.md
5. 인간으로 레이블링하고 일치도를 측정하세요. 두 명의 레이블러가 동의할 수 없으면 루브릭이 잘못된 것이지 레이블러가 잘못된 것이 아닙니다. 루브릭을 수정하고 다시 레이블링하세요. → references/statistics.md
6. 이제서야 판단자를 고려하세요, 그리고 교정된 것만. → references/judges.md
7. 비-AI 기준선을 포함한 모든 시스템을 실행하고, results.json을 작성한 후 렌더링하세요. → references/scorecard-spec.md
8. 평결을 직접 작성하세요. 스코어카드는 숫자를 보여줍니다. 인간이 어떤 트레이드가 이루어지고 있으며 무엇이 결정을 뒤집을지를 명시합니다.

렌더링

python3 skills/eval-design/scripts/render_scorecard.py results.json --md

자체 포함된 scorecard.html(외부 요청 없음, 라이트/다크 모드)과 리포지토리에서 읽기 위한 SUMMARY.md를 작성합니다. 스키마: references/scorecard-spec.md.

python3 skills/eval-design/scripts/validate_rubric.py results.json

스코어카드를 부정직하게 만드는 실수(합계가 1이 되지 않는 가중치, 명시된 논쟁이 없는 기준, 정당성이 없는 게이트, 기준선 누락, 신뢰 구간 내 주장된 순위)에 대해 실패합니다.

사용하지 말아야 할 경우

• 결정이 없는 일회성 프롬프트 조정. 그냥 출력물을 보세요.
• 사용자와 예제가 없는 경우. 먼저 실제 입력 30개를 확보하세요. 상상된 입력에 기반한 평가는 당신의 상상력을 측정합니다.
• 작업에 올바른 정답이 있고 프로그램으로 확인 가능한 경우 — 산술, 유효한 JSON, 컴파일되는 빌드. 루브릭 대신 검사를 작성하세요.
• 누군가 이미 내려진 결정을 정당화할 숫자를 원하는 경우. 평가를 구축하는 대신 그 말을 큰 소리로 하세요.

참고 파일

필요할 때 로드하고, 처음부터 모두 읽지 마세요.

파일	읽는 시점
references/rubric-design.md	기준 작성 또는 수정 시
references/failure-taxonomy.md	실제 출력에서 시작할 때
references/golden-sets.md	케이스 선택 및 계층화 시
references/judges.md	누군가 LLM-as-judge를 제안할 때
references/statistics.md	표본 크기, CI, 일치도, 드리프트 관련
references/scorecard-spec.md	results.json 작성 시
references/antipatterns.md	다른 사람의 평가 검토 시