LLM 평가 하네스

무엇을 해주나

base_url + model + 환경변수에 담긴 API 키만 주면, 벤더가 광고하는 숫자 대신 실제로 측정한 값을 돌려줍니다.

• 가용성(Availability): 어떤 모델 ID가 실제로 라우팅되는지 3단계 판정(no-channel / upstream-error / empty-content). 추론 모델이 죽은 것처럼 보이지 않도록 max_tokens를 8192로 유지합니다.
• 요청 충실도(Fidelity): system prompt·tools·대화 히스토리가 정말 모델까지 도달하는지를 카나리 코드로 검증합니다. 200 OK로 멀쩡히 대답하면서 system prompt만 조용히 버리는 게이트웨이를 잡아냅니다.
• 속도(Speed): TTFT와 지속 디코드 tok/s. reasoning_content를 빼먹고 completion_tokens로 나누는 흔한 실수(750 tok/s를 4700 tok/s로 착각) 를 방지합니다.
• 동시성(Concurrency): 10/20/40/60 램프업으로 성공률·p50/p90 지연이 무너지는 지점을 찾습니다. 주변 프록시와 keep-alive를 차단해 진짜 모델 한계를 잽니다.
• 프로토콜 준수: Anthropic thinking 블록이 생성되는지, 그리고 히스토리로 되돌려 보냈을 때 수락되는지(에이전트 세션이 끊기는 주범)를 따로 검사합니다.
• 품질 회귀: 내 유스케이스 라이브러리로 답변을 수집한 뒤, 서로를 모르는 블라인드 심사 에이전트 3개가 독립 채점하고 다수결로 통과 여부를 정합니다.

API 키는 항상 환경변수 이름으로만 전달해 ps·셸 히스토리·리포트에 남지 않으며, 유스케이스와 키는 ~/.llm-eval/ 처럼 스킬 밖에 보관하도록 안내합니다.

이런 분께 추천

• 새 LLM 게이트웨이/리셀러를 도입하기 전에 "진짜 쓸 만한가"를 검증해야 하는 백엔드·플랫폼 엔지니어
• "모델이 system prompt를 무시한다"는 원인 불명 버그를 쫓고 있는 에이전트 개발자
• 워크숍·데모 전에 동시 접속을 감당할지 확인해야 하는 운영자
• 모델 교체 시 품질 저하 여부를 데이터로 증명해야 하는 팀 리드

활용 예시

1. 신규 채널 온보딩: "이 게이트웨이 접속해봤는데 쓸 만한지 봐줘" → 가용성 프로브로 지원 모델 ID 목록을 만들고, 충실도 프로브로 system prompt 전달률을 10회 샘플링해 intermittent 6/10 같은 판정을 받습니다.
2. 세션이 자꾸 끊길 때: 멀티턴 대화 중 400 "invalid part type: thinking" 이 뜨면 protocol_probe.py --check history-replay 로 히스토리 재전송 거부 여부를 확인하고, 벤더 직결 엔드포인트와 교차 검증합니다.
3. 벤더 tok/s 주장 검증: speed_probe.py --mode both 로 실제 작업 처리량과 지속 디코드 상한을 함께 뽑아, 광고 수치와 비교한 정직한 리포트를 만듭니다.

클로드스킬마트에서 찾은 스킬을 설치해줘.
GitHub 저장소 daymade/claude-code-skills 의 llm-eval-harness 폴더를 내 ~/.claude/skills/llm-eval-harness/ 에 그대로 복사해줘.
설치가 끝나면 이 스킬로 무엇을 할 수 있는지 한 줄로 알려줘.