무료 티어는 조용히 실패하지만, 당신의 테스트 환경(Harness)은 크게 실패해야 한다
요약
LLM의 성능 비교 시, 단순히 패스율에 의존하는 것은 위험하며, 모델 자체보다 평가 환경(harness) 설계가 더 중요합니다. 특히 꼬리 부분에서 발생하는 실패 케이스를 포착하고, '정답당 토큰 수'와 같은 비용 효율성 지표로 모델을 객관적으로 비교해야 합니다.
핵심 포인트
- 모델 성능보다는 결정론적이고 엄격한 테스트 환경(harness) 설계가 핵심이다.
- LLM-as-judge는 변동성이 크므로, 구조화된 추출이나 유닛 테스트 등 명확한 기준이 필요하다.
- 단순 패스율 대신 '정답당 토큰 수'를 측정하여 정확도와 비용 효율성을 동시에 평가해야 한다.
저렴한 모델 접근 방식이 정확도 면에서 손해를 보는 경우는 거의 없습니다. 손해를 보는 곳은 꼬리 부분입니다. 즉, 시간 초과가 발생하는 3%의 호출, JSON 형식이 깨지는 단 하나의 입력값, 또는 네 개의 요청을 한 번에 보낼 때만 나타나는 재시도 폭풍 같은 경우입니다.
그래서 저는 실제 작업을 수행할 때는 어떤 무료 엔드포인트도 바로 신뢰하지 않습니다. 먼저 프롬프트를 작성하는 것이 아니라, 크게 실패하도록 설계된 테스트 환경(harness)을 작성하고, 무언가를 실행하기 전에 임계값(thresholds)을 기록합니다.
공개 사항: 이 글은 MonkeyCode의 제품 홍보 활동의 일환으로 준비되었습니다. 제가 다룰 수 있게 받은 두 가지 주제, 즉 MonkeyCode의 무료 모델 접근과 무료 서버 티어를 중심으로 내용을 구성했습니다. 운영자는 무료 토큰 할당량(작성 시점 기준 10M)과 무료 서버 티어에 대해 언급합니다. 이 둘 모두 운영자의 주장으로 간주하고 현재 약관을 직접 확인하시기 바랍니다. 아래 테스트 환경은 엔드포인트와 무관하게 작동하며, OpenAI-compatible chat completions 형태가 지원되는 곳이라면 어디서든 실행할 수 있습니다.
저는 통과율(pass rates)을 인용하지 않을 것입니다. 저는 그것들을 가지고 있지 않으며, 임의로 만들어내는 것은 이 전체 과정을 무효화할 것이기 때문입니다. 제가 제공해 드릴 수 있는 것은 측정 장비, 즉 저의 생각을 실제로 바꾸는 두 가지 숫자, 그리고 표가 무엇을 말하든 적용하는 규칙입니다.
모델보다 평가자(grader)부터 시작하라
제가 목격한 모든 잘못된 모델 비교는 같은 지점에서 잘못되었습니다. 바로 평가 과정이었습니다. 누군가가 20개의 출력을 대충 보고, 무료 모델이 '비슷하게 느껴진다'고 판단하고 배포합니다. 그러다가 일주일 후 추출 작업이 아무도 읽지 않는 열에 조용히 null을 기록하는 식입니다.
따라서 평가자(grader)가 먼저 와야 하며, 그것은 결정론적(deterministic)이어야 합니다. 주된 측정 기준에 LLM-as-judge를 사용해서는 안 됩니다. 심사위원(judge)은 자체적인 변동성을 추가하기 때문이며, 만약 당신이 그 심사위원이 실패하는 방식을 설명할 수 없다면, 단지 모호함을 한 단계 아래로 옮긴 것일 뿐입니다.
시작하기에 충분한 세 가지 작업군이 있습니다. 엄격한 스키마를 가진 구조화된 추출, 유닛 테스트로 평가되는 작은 코드 복구, 그리고 어설션(assertions)(길이, 금지 구문, 필수 하위 문자열)으로 평가되는 재작성 작업입니다. 쉽고 어려운 케이스에 걸쳐 총 30개의 사례가 있습니다. 이들을 파일에 고정하세요. 만약 어떤 사례가 모호하다면 삭제하십시오. 모호한 사례는 나중에 모델 실패로 오해하기 쉬운 동전 던지기 같은 것입니다.
논쟁을 끝내는 지표: 정답당 토큰 수 (tokens per correct answer)
단순히 패스율(Pass rate)만으로는 모델이 작업을 수행할 수 있는지 여부만을 알려줄 뿐, 그 작업에 비용이 얼마나 드는지까지는 말해주지 않습니다. 성공할 때마다 세 번의 재시도(retries)를 사용하면서 80%의 정확도를 달성하는 모델은, 첫 시도에 70%를 달성하는 모델보다 더 비쌉니다.
그래서 저는 호출당 total_tokens을 기록하고, 총 지출액을 정답 개수로 나눕니다. 정답당 토큰 수입니다. 이 단일 비율이 정확도, 재시도 횟수, 그리고 장황함을 하나의 숫자로 응축하여 엔드포인트 간 비교할 수 있게 해주며, 제가 리뷰에서 실제로 방어하는 숫자이기도 합니다.
모델의 정확도가 거의 완벽에 가까운데도 불구하고 저자가 더 저렴한 모델을 출시하는 게시글이라는 반복되는 장르가 있습니다. 그것은 반항심이 아닙니다. 그건 표의 올바른 열을 읽는 사람입니다.
테스트 환경 (The harness)
여기 실행기(runner)가 있습니다. 의도적으로 작게 만들었습니다. 커피가 식을 때까지 이 전체 내용을 다 읽을 수 있어야 합니다.
# harness.py — 모든 OpenAI 호환 엔드포인트에 대해 고정된 작업 세트를 N번 시도합니다. 기록만 남깁니다. 표가 가득 찰 때까지는 결론이 없습니다.
import asyncio, json, os, random, time
...
async def one_call(client, case, trial):
t0 = time.perf_counter()
payload = {
...
재시도 횟수는 구현 세부 사항이 아닙니다. 그것은 신호입니다. 그 횟수를 계산하십시오.
async def call_with_retries(client, case, trial, attempts=3):
for n in range(attempts):
rec = await one_call(client, case, trial)
...
def summarize(rows):
passed = [r for r in rows if r[
세마포어(semaphore)를 사용하여 동시성(concurrency)을 제어할 수 있는 노브로 구동하고, 모든 행을 JSONL 형식으로 작성하며, 원본 출력을 보관하세요. 평가자(grader)와 당신의 눈이 의견이 다를 때 처음으로 필요하게 될 것입니다.
## 표를 읽고, 데모는 읽지 마세요
좋은 데모 하나는 모델이 작업을 한 번 수행할 수 있음을 증명할 뿐입니다. 다음 주 화요일에 대해서는 아무것도 증명하지 못합니다. 제가 적용하는 규칙은 다음과 같으며, 저는 실행하기 *전에* 이 임계값(threshold)을 설정합니다. 왜냐하면 실행한 후에는 모든 것을 합리화하게 될 것이기 때문입니다.
| 신호 (Signal) | 사전에 설정한 임계값 (Threshold I set in advance) | 임계값을 넘었을 때 취하는 조치 (What I do when it's crossed) |
| :--- | :--- | :--- |
| pass_rate | 현재 기준선(baseline) 이상 또는 그 이상 | 저렴한 경로의 후보 (candidate for the cheap path) |
| ... |
그 마지막 행이 사람들이 건너뛰는 부분입니다. 만약 동일한 사례가 트라이얼 1에서는 통과하고 온도 0에서 트라이얼 3에서는 실패한다면, 모델에 문제가 있는 것이 아닙니다. 결정 경계(decision boundary)에 너무 가깝고, 아무리 프롬프트 다듬기(prompt polish)를 해도 해결되지 않는 작업 문제입니다.
## 이것이 깨지는 지점 (Where this breaks)
세 번의 트라이얼은 통계가 아닙니다. 이는 심각한 불안정성만을 포착하는 연기 테스트(smoke test)일 뿐입니다. 만약 신뢰 구간(confidence intervals)이 필요하다면, 사례당 30번의 트라이얼을 예산으로 잡고 토큰 사용량 증가를 받아들이세요.
평가자(grader)가 항상 약한 고리입니다. 너무 엄격한 정규 표현식(regex)은 올바른 답변을 실패로 점수 매기며, 당신은 자신의 버그 때문에 엔드포인트(endpoint) 탓을 할 것입니다. 첫 번째 실행 시에는 거짓 음성(false negatives)을 수동으로 감사하세요—단순히 통과율만 읽지 말고 모든 실패를 읽으세요.
엔드포인트는 표류합니다(drift). 가중치(weights)가 교체되고, 양자화(quantizations)가 변경되며, 속도 제한(rate limits)이 이동합니다. 당신의 표는 날짜가 찍힌 스냅샷일 뿐, 모델의 속성이 아닙니다. 그리고 여기서 핵심은 무료 티어이기 때문에, 무료 티어의 약관은 누군가가 바꿀 수 있다는 것을 기억하세요: 파이프라인을 구축하기 전에 허용량과 서버 제공 사항을 확인하십시오.
## 누가 이것을 해서는 안 되는가 (Who should not do this)
만약 당신의 경로가 사용자에게 노출되고 초 단위(sub-second)로 작동한다면, 무료 티어는 비용을 절감할 장소가 아닙니다. 지연 시간(latency)에 토큰을 사용하는 데 써야 합니다. 만약 레이블링된 태스크 스위트(labeled task suite)가 없고 만들 계획도 없다면, 이 하네스(harness)는 답처럼 느껴지지만 실제로는 그렇지 않은 수치를 제공할 것입니다. 그리고 단 하나의 잘못된 출력이 당신이 절약한 토큰보다 더 많은 비용을 초래한다면, 산술 계산은 이미 결정되었으니 실험을 건너뛰세요.
다른 사람들은: 위의 장치는 아마 90줄 정도일 것이고, 당신이 이미 평가하고 있는 같은 무료 서버 티어에서 실행됩니다. 그것을 야간 스케줄로 배치해 두세요. 하네스는 스크린샷이 아니라 일련의 과정으로서만 가치가 있습니다. 그리고 패스율(pass rate)을 보기 전에 p95 열을 보세요. 그곳에 진실성이 담겨 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기