본 글은 Kaggle Benchmarking Challenge에 제출하는 내용입니다.
제가 벤치마킹한 내용
API 클라이언트에게 조언을 제공하는 AI 컴포넌트는 두 가지 임무를 가집니다: 올바른 행동을 선택하고, 클라이언트가 실제로 파싱할 수 있는 무언가를 반환하는 것입니다. RetryBudget-24는 이 두 가지 임무를 함께 테스트한 다음, 분석을 위해 실패 모드를 분리합니다.
각 질문은 실패했거나 완료된 요청을 설명하고 명시적이고 합성적인 재시도 정책을 제공합니다. 모델은 정확히 두 개의 필드만 반환합니다:
{"action":"RETRY","delay_ms":100}
행동(actions)에는 DONE, STOP, RECONCILE, 그리고 RETRY가 있습니다. 이 정책은 상태 우선순위(status precedence), 시도 제한(attempt limits), Idempotency 보장(idempotency guarantees), 제한된 지수 백오프(capped exponential backoff), Retry-After, 그리고 남은 시간 예산(remaining-time budget)을 다룹니다. 재시도는 대기 시간과 다음 시도의 예상 지속 시간이 예산에 맞는지 여부에 따라 허용됩니다. 등가성도 허용됩니다.
이것은 텍스트 기반의 정책 결정 작업입니다. HTTP 요청을 실행하거나, 추론-서빙 지연 시간(inference-serving latency)을 측정하거나, 안전한 프로덕션 재시도를 시연하는 것은 아닙니다.
열두 쌍의 제어된 사례
공식 세트는 12쌍으로 구성된 24개의 원래 합성 사례를 포함합니다. 각 쌍 내에서 정확히 하나의 입력 필드만 변경됩니다. 이는 테스트되는 경계(boundary)를 관련 없는 퍼즐 모음보다 더 쉽게 검사할 수 있게 만듭니다.
예를 들어, 100ms 대기 시간과 200ms 다음 시도를 고정한다고 가정해 봅시다:
- 남은 시간이 299ms이면 STOP입니다.
- 남은 시간이 300ms이면 100ms 지연으로 RETRY합니다.
다른 쌍들은 서버가 Idempotency 키에 대한 중복 제거를 보장하는지, 시도 제한에 도달했는지, 또는 백오프 상한선이 적용되는지를 변경합니다.
사례들, 고정 순서, 프롬프트, 오라클(oracle), 그리고 스코어러(scorer)는 어떤 모델 호출보다 먼저 해시로 고정되었습니다. 네 개의 별도 개발 사례들은 프롬프트를 모델 응답에 맞춰 조정하지 않고 실행을 확인했습니다. 예상 답변은 결정론적 오라클과 비교되었으며, 20개의 오프라인 테스트가 원래의 벤치마크 구현을 검사했습니다.
주요 점수는 두 출력 필드 모두의 정확한 정답 여부를 합산하여 24로 나눈 값입니다. JSON 공백 및 키 순서는 허용됩니다. 코드 울타리(code fences), 설명, 추가 또는 중복된 키, 정수 필드의 부동 소수점(floats) 및 불리언(booleans)은 계약을 위반합니다. LLM 심사관은 관여하지 않습니다.
참고로, 결정론적 기준선(deterministic baselines)은 정책 오라클(policy oracle)에서 24/24점을, 항상 STOP일 때 6/24점을, 그리고 100ms 후에 일시적인 상태를 재시도하는 상태 전용 휴리스틱(status-only heuristic)에서 7/24점을 받았습니다. 오라클은 경쟁 언어 모델이 아닌 정확성 참조점입니다.
테스트된 모델
실험에서는 Kaggle의 Model Proxy를 통해 사용할 수 있는 두 가지 모델을 사용했습니다:
google/gemini-2.5-flashanthropic/claude-haiku-4-5@20251001
이 작고, 여러 제공업체를 아우르는 비교는 실험 비용을 낮게 유지했습니다. 이것은 사용 가능한 가장 강력한 모델들을 조사하는 것은 아닙니다.
두 모델 모두 Kaggle Benchmarks SDK 0.6.1을 통해 동일하게 고정된 프롬프트(frozen prompts)를 받았으며, max_tokens=512, seed 0, temperature 0이 요청되었습니다. 중요하게도, 검사된 SDK 경로는 두 모델 모두에 대해 temperature 설정은 지원되지 않아 해당 설정을 무시했습니다. 따라서 실제 temperature는 통제되지 않았습니다. 추론(Reasoning) 설정은 제공업체의 기본값으로 유지되었으며, 요청된 설정들이 동일한 효과적인 추론 예산(effective inference budgets)을 확립하지 못합니다.
각 케이스에는 별도의 채팅이 사용되었습니다. 오답에 대한 재시도는 없었습니다. 클라이언트 SDK 재시도는 비활성화되었고; 프록시 내부의 재시도는 관찰되지 않았습니다.
결과
계획된 실험
| 모델 | 엄격 점수 (Strict score) | 유효 스키마 (Valid schema) | 쌍의 두 멤버가 정확한 경우 (Both members of pair correct) |
|---|
| Gemini 2.5 Flash | 16/24 | 22/24 | 4/12 |
| Claude Haiku 4.5 | 5/24 | 9/24 | 1/12 |
엄격한 점수 차이가 커 보입니다. 응답을 검사하면 여기서 합리적으로 결론지을 수 있는 내용이 달라집니다.
Haiku는 24개의 답변 중 15개를 완전한 Markdown 코드 울타리로 감쌌습니다. 그중 9개에는 올바른 액션과 지연 시간이 포함되어 있었습니다. Gemini는 올바른 내용의 완전한 울타리 하나와 닫히지 않은 울타리 하나를 생성했습니다.
A narrowly defined, post-hoc diagnostic removed only complete outer fences, without repairing JSON, coercing types, or extracting objects from prose. Correctness then became 17/24 for Gemini and 14/24 for Haiku. These are diagnostic counts, not replacement benchmark scores.
이러한 구별은 통합 설계에 중요합니다. 엄격한 JSON 소비자(consumer)는 실제로 그러한 펜스 처리된 응답을 거부할 것입니다. 그러나 모든 거부를 추론 실패로 간주하는 것은 발생한 일의 상당 부분을 숨기는 것이 됩니다. 파서 어댑터(parser adapter)나 제약 출력 인터페이스(constrained-output interface)를 별도로 고정된 실험에서 테스트해 볼 가치는 있지만, 이 점수는 이에 맞춰 수정되지 않았습니다.
포맷팅이 분리된 후에도 남아있는 오류들
두 모델 모두 100 + 200이 299를 초과함에도 불구하고 299ms 예제에서 RETRY를 선택했습니다. 300ms에서는 두 모델 모두 올바른 결정 내용을 반환했으며, Haiku의 답변은 펜스 처리되었습니다.
멱등성(idempotency) 보장이 없는 안전하지 않은 타임아웃 상황에서, 정책이 RECONCILE을 요구했을 때 Haiku는 RETRY를 반환했습니다. min(1000, 700 * 2)가 1000ms를 생성해야 하는 제한적 백오프(capped-backoff) 사례에서는, Gemini는 1400을 반환했고 Haiku는 700을 반환했습니다.
이러한 예제들은 테스트할 가치가 있는 구체적인 정책 경계들을 식별합니다. 하지만 이들이 두 모델이 실제 API 트래픽 전반에 걸쳐 어떻게 행동할지 확립하는 것은 아닙니다.
의도치 않은 두 번째 실험
출판 준비 과정에서 실행 제어(execution-control) 실수가 있었습니다: 빌드 태스크(Build Task)가 저장/빌드 작업으로 처리되었지만, 원본 노트북을 다시 실행했습니다. 추가 실행은 중지될 수 있기 전에 완료되었습니다. 이로 인해 계획된 56개 클라이언트 호출을 초과했으며 반드시 계산되어야 합니다.
| Batch | Gemini formal score | Haiku formal score | Calls including development | Reported quota cost |
|---|
| Planned experiment | 16/24 | 5/24 | 56 | $0.0521384 |
| ... | | | | |
| All 112 recorded calls completed. 추가 배치(additional batch)는 동일한 프롬프트 해시와 변경되지 않은 채점(scoring)을 사용했습니다. 그 결과물은 별도로 보관되며, 더 나은 Gemini 결과가 계획된 결과를 대체하지 않으며, 이 배치는 새로운 헤드라인 점수(headline score)로 통합되지 않습니다. | | | | |
표시된 금액은 계정의 사용 가능한 무료 할당량 내에서 Model Proxy 할당량 소비를 보고한 것이며, 현금 구매액이 아닙니다. 이는 해당 특정 실험이 저렴했음을 보여줄 뿐, 향후 실행에 대한 보장된 가격을 의미하지는 않습니다.
또한 이로 인해 벤치마크 워크플로우(benchmark-workflow) 요구 사항이 드러났습니다. 즉, 출판 단계(publication steps)는 자체적인 실행 예산(execution budget)이 필요합니다. 하나의 노트북 세션 내의 호출 원장(call ledger)은 새로운 플랫폼 실행 전반에 걸쳐 글로벌 제한을 부과할 수 없습니다.
결과가 말해주지 못하는 것들
이것은 관련 쌍, 케이스당 계획된 샘플 1개, 그리고 우발적인 반복 1개를 포함한 소규모 합성 세트(synthetic set)입니다. 이는 일반적인 모델 순위 지정이나 통계적으로 신뢰할 수 있는 신뢰성 추정치보다는 실패 분석을 지원합니다.
저장된 아티팩트(artifacts)에는 finish_reason이 포함되어 있지 않습니다. 계획된 Gemini 테스트에서, 24개의 보고된 출력 토큰 수 중 21개가 요청된 512 토큰 제한에 비해 최소 450 토큰에 달했습니다. 이는 주의가 필요하지만, 잘림(truncation)을 증명하거나 특정 오류를 설명하지는 않습니다. 모델의 실제 생성 조건이 완전히 통제되지 않았습니다.
다음 유용한 실험은 엄격한 출력 조건 대 제약된 출력 조건, 더 많은 정책 경계(policy boundaries), 그리고 계획된 반복을 사전에 정의해야 합니다. 또한 어떤 모델 호출 진입점(model-call entry point)을 활성화하기 전에 플랫폼의 빌드 동작(build behavior)을 검증할 것입니다.
나의 벤치마크
Kaggle 벤치마크 모음: RetryBudget-24: Policy and JSON Contracts
Source, frozen cases, manifests, 및 원본 결과: [Planned experiment snapshot] (https://www.kaggle.com/code/liwhattao/retrybudget-24-v1?scriptVersionId=356959464)와 [unplanned Build rerun snapshot] (https://www.kaggle.com/code/liwhattao/retrybudget-24-v1?scriptVersionId=356960994)를 참조하세요. 자체 작성한 벤치마크 코드는 Apache 2.0 라이선스로 공개되었습니다.
공개된 Kaggle 태스크와 컬렉션에는 계획되지 않은 배치(unplanned batch)의 Gemini 결과인 0.75 (18/24)만 포함되어 있습니다. 위에 제시된 두 모델 비교는 별도로 보존 및 감사된 원본 실험 아티팩트에서 가져온 것이며, 두 모델이 플랫폼 리더보드에 나타난다는 주장이 아닙니다. 원래의 실행 어댑터(execution adapter) 역시 노트북 컨텍스트에 의존합니다. 자체 포함형 출판 래퍼(publication wrapper)가 준비되어 오프라인으로 테스트되었지만, 실제 모델을 대상으로 실행되거나 측정된 버전을 대체하지는 않았습니다.
AI 지원은 합성 벤치마크를 설계하고 구현하며, 워크플로우를 실행하고, 저장된 출력을 감사하고, 이 기사를 초안 작성하는 데 사용되었습니다. 본 태스크는 제3자 평가 데이터 대신 독창적인 합성 케이스를 사용합니다. SDK는 아래에 명시했습니다. 이 글은 AI 지원 워크플로우의 의도치 않은 재실행(unintended rerun)을 숨기는 대신 명시적으로 유지하고 있습니다.
공식 참고 자료: