LLM 기능이 계속 회귀할 때 /ai-evals가 실패 유형 평가 기준과 테스트 세트를 만들어, 다음 변경이 실제로 나아졌는지 확인하게 합니다. — Claude Skill
Claude Code용 Claude 스킬 · 제공: Refound · 실행: /ai-evals (Claude 내)·업데이트: 2026년 6월 11일
실제 실패 추적 기록에서 통과/실패 평가 기준과 테스트 세트를 만듭니다.
- 오류 분석 워크플로: 실패 추적 기록을 공개 코딩하고, 패턴으로 묶고, 평가 기준 항목으로 전환합니다
- 실행 가능한 요구사항으로서의 평가: 모델이 제품이면 평가는 제품 요구사항 문서입니다
- 의미 없는 평균을 만드는 1-5점 척도 대신 통과/실패 이진 판단만 사용합니다
- 전문가 합의에 고정된 사람 검증 루프가 포함된 LLM 심판 구성 틀
- 범위 보고서: 테스트된 실패 유형과 아직 사각지대로 남은 부분을 보여줍니다
대상
기능
프롬프트를 조금 바꾼 뒤 지원 봇 정확도가 떨어졌지만 이유를 모릅니다. /ai-evals가 50개 추적 기록에서 오류 분석을 실행하고 6개 실패 유형을 묶은 뒤, 변경 때마다 다시 실행할 수 있는 통과/실패 평가 기준을 만듭니다.
팀이 응답이 '좋은지'를 두고 논쟁합니다. /ai-evals는 각 차원에 예시가 포함된 구체적이고 측정 가능한 기준을 붙여 평가 기준 대화를 강제합니다. 평균 리커트 점수 대신 통과/실패 결정을 사용합니다.
GPT-4로 Claude 출력을 채점하고 그 점수를 믿고 있습니다. /ai-evals는 20개 추적 기록 사람 검증 단계를 추가해, CI 게이트로 쓰기 전에 심판이 도메인 전문가와 일치하는지 확인합니다.
새 에이전트가 코드를 작성하고, 도구를 호출하고, 문서를 편집합니다. /ai-evals는 이미 본 상위 5개 실패 유형과 합성 적대 사례를 포함한 테스트 세트를 설계해, 감이 아니라 회귀 기준으로 배포하게 합니다.
작동 방식
LLM 출력의 실제 추적 기록 20-50개를 붙여 넣습니다(성공과 실패 모두)
공개 코딩을 실행합니다. 각 추적 기록에서 무엇이 잘못됐는지 자연어로 표시합니다
라벨을 예시가 포함된 4-8개 실패 유형 범주로 묶습니다
범주에 고정된 통과/실패 평가 기준과 LLM 심판 프롬프트를 생성합니다
다시 실행 가능한 평가 세트, 범위 보고서, 사람 검증 체크리스트를 받습니다
예시
지난주 지원 봇 대화 50개 CSAT가 나쁨으로 표시한 대화 12개 모델: Claude 3.5 Sonnet, 도움말 문서 기반 RAG 불만: '정책을 지어낸다'
1. 지어낸 정책 18/50 추적 기록 (가장 큼) 2. 잘못된 문서 인용 9/50 3. 범위 안 질문을 거절 7/50 4. 말투: 차가움 5/50 5. 과도한 회피 표현 4/50 6. 잘못된 언어 2/50
policy_grounded: 모든 정책 주장이 실제 문서 ID를 인용함 PASS/FAIL right_citation: 인용 문서가 실제로 주장을 뒷받침함 PASS/FAIL in_scope_answered: 범위 안 질문에 실제 답변 제공 PASS/FAIL tone_acceptable: '도울 수 없습니다'식 거절 없음 PASS/FAIL
지원 봇 응답을 판정하세요. 각 차원마다 PASS 또는 FAIL과 이유 한 문장을 출력하세요. 기준: 제공된 참조 문서와 비교하세요. 리커트 척도를 사용하지 마세요. [평가 기준 삽입]
→ 심판 검증: 추적 기록 20개를 직접 라벨링하고 심판과의 일치율이 85%를 넘는지 확인 → 기준선: 현재 모델의 policy_grounded 점수 64% → 목표: 배포 전 90%
개선되는 지표
지원 도구
AI 평가을(를) 사용해 보시겠어요?
시작 방법을 선택하세요.
이 스킬을 컴퓨터에 로컬로 설치하고 실행합니다.
컴퓨터에서 터미널을 열고 이 명령을 붙여넣으세요:
이 명령은 스킬과 모든 파일을 컴퓨터에 다운로드합니다:
모든 프로젝트에서 사용하려면 끝에 -g를 추가하세요.
Claude Code를 시작한 다음 명령을 입력하세요:
AI 평가
AI 실무자의 통찰을 바탕으로 사용자가 AI 제품을 체계적으로 평가하도록 돕습니다.
도와주는 방식
사용자가 AI 평가 도움을 요청하면:
- 무엇을 평가하는지 이해합니다 - 어떤 AI 기능이나 모델을 테스트하는지, "좋음"이 무엇인지 묻습니다
- 평가 접근법을 설계합니다 - 평가 기준, 테스트 사례, 측정 방법을 제안합니다
- 구현을 안내합니다 - edge case, 채점 기준, 반복 주기를 함께 검토합니다
- 제품 요구사항과 연결합니다 - 평가가 기술 지표만이 아니라 실제 사용자 요구와 맞는지 확인합니다
핵심 원칙
평가는 새로운 PRD입니다
Brendan Foody: "모델이 제품이면 평가는 제품 요구사항 문서입니다." 평가는 AI 제품에서 성공이 무엇인지 정의합니다. 선택적 품질 점검이 아니라 핵심 명세입니다.
평가는 핵심 제품 역량입니다
Hamel Husain과 Shreya Shankar: "Anthropic과 OpenAI의 최고제품책임자 모두 평가가 제품 빌더에게 가장 중요한 새 역량이 되고 있다고 말했습니다." 이는 ML 엔지니어만의 일이 아닙니다. 제품 담당자도 익혀야 합니다.
워크플로가 중요합니다
좋은 평가는 오류 분석, 공개 코딩(무엇이 잘못됐는지 적기), 실패 패턴 묶기, 평가 기준 만들기를 포함합니다. 일회성 테스트가 아니라 체계적 과정입니다.
사용자에게 던질 질문
- "이 AI 출력에서 '좋음'은 어떤 모습인가요?"
- "지금까지 본 가장 흔한 실패 유형은 무엇인가요?"
- "모델이 좋아졌는지 나빠졌는지 어떻게 알 수 있나요?"
- "사용자가 실제로 신경 쓰는 것을 측정하고 있나요?"
- "실패 패턴을 이해할 만큼 충분한 출력을 직접 검토했나요?"
표시해야 할 흔한 실수
- 수동 검토 생략 - 실패 추적 기록을 직접 분석해 패턴을 이해하기 전에는 좋은 평가를 쓸 수 없습니다
- 모호한 기준 사용 - "출력이 좋아야 한다"는 평가는 아닙니다. 구체적이고 측정 가능한 기준이 필요합니다
- 검증 없는 LLM 심판 - LLM으로 판정한다면 그 심판이 사람 전문가와 일치하는지 검증해야 합니다
- 이진 판단 대신 리커트 척도 사용 - 통과/실패 결정을 강제하세요. 1-5점 척도는 의미 없는 평균을 만듭니다
심층 자료
게스트 2명의 통찰 2개는 references/guest-insights.md를 보세요.
관련 스킬
- LLM으로 빌드하기
- AI 제품 전략
- 새 기술 평가
참조 문서
AI 평가(Evals) - 모든 게스트 통찰
게스트 2명, 언급 2개
Hamel Husain & Shreya Shankar
Hamel Husain & Shreya Shankar
"Anthropic과 OpenAI의 최고제품책임자 모두 평가가 제품 빌더에게 가장 중요한 새 역량이 되고 있다고 말했습니다."
통찰: 게스트들은 이를 전통적 소프트웨어 테스트나 일반 AI 전략과 구분되는 "새 역량"으로 명확히 정의합니다. 오류 분석, 공개 코딩, 실패 패턴 묶기, 평가 기준 만들기를 포함한 특정 다단계 워크플로가 필요합니다.
Brendan Foody
Brendan Foody
"모델이 제품이라면 평가는 제품 요구사항 문서입니다."
통찰: 게스트는 우리가 "평가의 시대"에 들어섰다고 말하며, 이를 AI 연구소의 핵심 병목으로 설명합니다. 모델 역량을 측정하는 평가 기준, benchmark, 체계적 테스트를 만드는 일이 포함됩니다.