BIRD Mini-Dev 2026 개정판 83.80점은 몇 등인가: 같은 모델이 68.2에서 83.8이 된 78문항을 해부했습니다

TL;DR

• BIRD Mini-Dev는 텍스트-투-SQL(자연어 질문을 SQL로 바꾸는 작업) 분야의 대표 소형 벤치마크입니다. 주최 측이 2026년 10월 28일 개정판을 냈고, 저희는 이튿날 개정판 SQLite 500문항에서 Darwin-180B-NL2SQL 시스템 83.80%(419/500) 를 기록해 예측 파일과 채점 스크립트를 공개했습니다.
• 먼저 불편한 사실부터 적습니다. 같은 개정판에서 주최 측이 공개한 고정 프롬프트 기준선은 Claude Opus 5.5 90.00, GPT-6.1 Sol 88.00, Claude Sonnet 5.5 86.60 입니다. 83.80은 이 셋보다 낮고 공식 표에서 4번째 위치입니다. 이 글은 1위 글이 아닙니다.
• 공식 리더보드의 SQLite 최고 항목은 81.00이지만 날짜가 개정 9일 전인 10월 19일이라, 어느 판의 데이터로 잰 값인지 확인할 수 없습니다. 그래서 83.80과 81.00은 같은 조건의 비교가 아니라고 보고 직접 비교하지 않습니다.
• 같은 가중치(Darwin-180B-RSI)에 공식 고정 프롬프트를 그대로 쓰면 68.20%(341/500) 였습니다. 시스템이 얹히면서 78문항(순증) 이 더 맞았고, 89문항이 정답으로 바뀌고 11문항이 오답으로 바뀐 결과입니다.
• 공개 예측 파일을 공식 채점기로 다시 채점하니 두 번 모두 418이 나왔습니다. 1문항 차이는 60초 제한 때문에 병렬 부하에서 시간 초과가 난 문항이었고, 단독 실행에서는 29초에 정답이었습니다. 점수는 채점 머신의 부하에도 흔들립니다.

BIRD Mini-Dev 2026 개정판은 무엇이 바뀌었나요?

BIRD는 홍콩대와 알리바바 연구진이 만든 텍스트-투-SQL 벤치마크이고, Mini-Dev는 그 가운데 500문항을 추려 SQLite, MySQL, PostgreSQL 세 방언으로 맞춘 소형판입니다. 데이터셋 카드에 따르면 2026 개정판은 커뮤니티 제보와 사람이 개입한 점검을 거쳐 질문, 근거(evidence), 정답 SQL을 고치고 일부 문항을 교체했습니다. 스키마 연결이나 쿼리 계획, 정답을 그대로 알려 주던 근거 문구는 걷어냈다고 밝혔습니다. 에이전트가 요청을 이해하고, 허용된 데이터베이스를 탐색하고, 쿼리를 만드는 능력을 요구하는 방향입니다.

BIRD 사이트의 공지 날짜는 10월 28일입니다. 같은 리더보드 표 안에 2024년 항목, 개정 이전인 10월 19일 항목, 개정 이후 항목이 함께 있을 수 있기 때문에, 점수 옆의 날짜와 데이터 판 번호를 같이 보지 않으면 비교가 어긋납니다.

저희가 내려받은 SQLite 판의 난이도 분포를 직접 세어 보았습니다.

500문항 중 92%가 challenging 입니다. 그래서 전체 점수는 사실상 challenging 점수이고, simple 8문항에서 한 문항(12.5%p)이 틀리는 것은 전체에 0.2%p밖에 영향을 주지 않습니다. 난이도별 정확도를 따로 보아도 표본이 작아 해석할 여지가 거의 없습니다.

83.80은 같은 개정판의 공식 표에서 몇 번째인가요?

데이터셋 카드에는 개정판 기준의 고정 프롬프트 기준선 표가 있습니다. SQLite 열만 옮기면 다음과 같습니다.

(차트의 가로축은 50에서 시작합니다. 막대 길이로 비율을 읽지 말고 숫자를 읽어 주세요.)

이 표를 읽을 때 반드시 짚어야 할 조건 차이가 세 가지 있습니다.

1. 기준선은 고정 프롬프트 한 번 호출입니다. 저희 83.80은 모델이 쿼리를 만든 뒤 실제 데이터베이스에서 실행해 보고 결과를 근거로 고쳐 쓰는 다단계 시스템입니다. 모델 카드의 평가 조건표에는 정답 SQL 사용 없음, 근거(evidence) 이외의 오라클 지식 없음, BIRD 대상 미세조정 없음, 문항당 최종 후보 1개, 추론 중 데이터베이스는 읽기 전용 실행만으로 적혀 있습니다. 그래도 호출 한 번짜리 기준선과 같은 종목이라고 말할 수는 없습니다.
2. 저희 가중치는 공개된 Darwin-180B-RSI 그대로입니다. 이번 결과를 위해 학습하거나 바꾼 가중치는 없습니다. 기준선 모델과 달리 저희 쪽에는 가중치 바깥의 검증 엔진이 붙어 있다는 뜻이기도 합니다.
3. 자체 보고 점수입니다. 저희가 직접 잰 값이며, BIRD 측이 다시 채점한 값이 아닙니다.

정리하면 같은 개정판에서 Opus 5.5(90.00), GPT-6.1 Sol(88.00), Sonnet 5.5(86.60)가 더 높습니다. 저희 쪽 숫자가 의미를 갖는 곳은 순위가 아니라 같은 가중치에서 시스템이 만든 차이입니다.

공식 리더보드 81.00과 비교해도 되나요?

BIRD 사이트의 Mini-Dev 표에는 schemagate + Claude Opus 5.5(독립 개발자 제출) 항목이 SQLite 81.00으로 올라 있고, 날짜는 10월 19일입니다. 데이터셋 개정은 10월 28일입니다. 그 항목이 개정 전 데이터로 채점되었는지 개정 후 데이터로 채점되었는지는 저희가 확인한 범위에서 표기되어 있지 않습니다.

그래서 이렇게 정리합니다.

• 83.80이 81.00보다 높다는 사실은 숫자일 뿐이고 우위의 근거가 되지 못합니다. 데이터 판이 다를 수 있기 때문입니다.
• 저희의 리더보드 등재 신청(풀 리퀘스트)은 열려 있는 상태이며, 10월 31일 오전 8시 기준 공식 리더보드에는 저희 항목이 없습니다. 등재되면 그때 실린 값이 기준입니다.

벤치마크가 개정되는 시기에는 이런 혼선이 구조적으로 생깁니다. 개정 전 표와 개정 후 표가 같은 페이지에 같은 단위로 놓이기 때문입니다.

같은 가중치가 68.2에서 83.8이 된 것은 무엇이 달랐나요?

저희는 10월 28일 같은 가중치 Darwin-180B-RSI를 공식 고정 프롬프트(baseline_inference의 프롬프트), 온도 0으로 돌려 SQLite 500문항을 채점했습니다. 결과는 341/500, 68.20%였고 실패 유형은 다음과 같았습니다.

이 숫자에는 사연이 하나 있습니다. 추론 모델이라 출력 한도 12,000 토큰으로 처음 돌렸을 때는 빈 답이 98건이었고 점수가 58.60%였습니다. 빈 답만 한도 32,000으로 다시 생성하자 75건이 회복되어 68.20이 되었습니다. 남은 23건은 그래도 비어서 오답으로 쳤습니다. 추론 모델은 출력 한도부터 넉넉히 잡아야 합니다. 한도가 모자라면 모델 실력이 아니라 잘린 출력이 점수를 깎습니다.

이제 공개된 시스템 예측(419개 정답)을 문항 단위로 이 고정 프롬프트 결과와 맞대 보았습니다.

시스템만 맞힌 89문항을 고정 프롬프트 쪽 실패 유형으로 쪼개면 오답 62, 빈 답 17, 시간 초과 10입니다.

여기서 읽을 점이 둘 있습니다.

첫째, 89문항 가운데 27문항(30%)은 의미 오류가 아니라 공정 실패였습니다. 답을 아예 못 낸 17건과 60초 안에 끝나지 않은 10건입니다. 실행 결과를 보고 쿼리를 고치는 구조는 이런 종류의 실패를 줄이는 데 특히 유리합니다. 실행해 보면 비어 있거나 느린 것이 바로 드러나기 때문입니다. 나머지 62문항이 진짜 의미 교정입니다.

둘째, 11문항은 오히려 맞던 것이 틀어졌습니다. 시스템이 순증 78을 만든 것이지 단방향 개선이 아닙니다. 다단계 시스템은 맞던 쿼리를 고치다가 망가뜨릴 수 있고, 이 11건이 그 비용입니다.

데이터베이스마다 이득이 같았나요?

아닙니다. 데이터베이스별 정답 수 변화는 다음과 같이 쏠려 있습니다.

superhero가 +18(29에서 47)로 가장 크고, california_schools, card_games, financial이 각각 +11입니다. 반대로 toxicology는 30에서 30으로 변화가 없고, debit_card_specializing은 13에서 12로 1문항 줄었습니다. 문항이 14개뿐인 데이터베이스이므로 이 감소를 해석하지는 않습니다.

데이터베이스당 문항이 14~86개라서 개별 차이는 잡음일 수 있습니다. 다만 열한 곳 가운데 아홉 곳에서 증가했다는 방향성은 한두 문항의 우연으로 설명하기 어렵습니다.

점수가 채점 머신의 부하에 따라 달라질 수 있나요?

네, 저희가 직접 겪었습니다. 모델 카드에는 83.80(419/500)이 "유휴 머신에서 두 번 계산해 동일했다"고 적혀 있습니다. 저희는 오늘 공개 예측 파일을 모델 카드가 배포한 score_ex.py 그대로 사내 PC에서 두 번 채점했고, 두 번 모두 418/500(83.60%) 이 나왔습니다. 시간 초과가 3건이었습니다.

원인을 쫓아가 보니 질의 3건이 60초 제한 근처에서 오갔습니다. 단독 실행(병렬 없이 한 질의씩)으로 바꿔 재 보았습니다.

Q93은 단독으로는 29초에 정답이지만 채점기가 워커 8개를 동시에 돌리는 병렬 상황에서는 60초를 넘겼습니다. 이 문항 하나가 418과 419의 차이입니다. 즉 공개된 83.80은 채점 머신이 한가할 때 성립하는 값이고, 바쁜 머신에서는 83.60이 나올 수 있습니다.

이 현상에서 얻는 교훈은 둘입니다.

• 질의당 시간 제한을 두는 벤치마크는 점수에 하드웨어와 부하가 섞입니다. 두 시스템의 0.2%p 차이는 이 잡음 안에 있습니다.
• 바깥 타임아웃만으로는 sqlite 질의가 멈추지 않습니다. 채점기가 set_progress_handler로 질의 안에서 직접 끊는 이유입니다. 이 장치가 없으면 폭주 질의 하나가 워커를 오래 붙잡아 채점이 끝나지 않습니다.

엄격한 실행 정확도는 코드로 어떻게 정의되나요?

BIRD의 실행 정확도(EX)는 예측 쿼리가 반환한 행의 집합이 정답 쿼리가 반환한 행의 집합과 같으면 정답으로 칩니다. 아래는 위 채점기의 핵심만 줄인 것이고, 공개 예측 파일의 앞 30문항에 대해 실제로 돌려 보았습니다(정답 23, 오답 7).

import sqlite3, time

def rows(db, sql, limit=None):
    con = sqlite3.connect(f"file:{db}?mode=ro", uri=True)  # 읽기 전용
    if limit:  # 질의 안에서 직접 끊는다
        end = time.time() + limit
        con.set_progress_handler(lambda: time.time() > end, 100000)
    try:
        return set(con.execute(sql).fetchall())
    finally:
        con.close()

def judge(db, pred_sql, gold_sql):
    if not pred_sql:
        return "no_sql"
    try:
        return "ok" if rows(db, pred_sql, 60) == rows(db, gold_sql) else "wrong"
    except sqlite3.OperationalError as e:
        return "timeout" if "interrupted" in str(e) else "exec_error"

set으로 비교하므로 행 순서와 중복 행은 무시됩니다. 질문이 정렬을 요구해도 결과 집합만 맞으면 정답이 됩니다. 이 정의를 모르고 점수를 읽으면 "정확도"라는 단어가 실제보다 더 강하게 들립니다.

직접 재현하려면 어떻게 하나요?

모델 카드 저장소에 예측 파일과 채점기가 있습니다. 데이터셋은 birdsql/bird_mini_dev의 data/mini_dev_sqlite.jsonl(모델 카드에 적힌 sha256으로 판 번호를 확인하세요)이고, 데이터베이스는 BIRD가 배포하는 minidev.zip입니다.

# mini_dev_sqlite.jsonl 을 score_ex.py 옆에 둔 뒤
python score_ex.py predictions.jsonl path/to/MINIDEV/dev_databases

질의당 60초 제한이 있으므로 머신 부하를 낮추고 돌려야 모델 카드의 값에 가까워집니다. 저희는 병렬 8개로 두 번 돌려 418을 얻었습니다.

이 숫자를 어디까지 믿어야 하나요?

• 자체 측정입니다. 제작사가 직접 잰 값이며, 기관의 재채점을 받지 않았습니다. 예측 파일과 채점기를 공개한 이유는 이 한계를 독자가 직접 확인할 수 있게 하기 위해서입니다.
• 순위 주장을 하지 않습니다. 같은 개정판의 공식 기준선에서 상용 모델 세 개가 더 높습니다. 개정 전 리더보드 항목과는 비교하지 않습니다.
• 500문항 소형판입니다. 한 문항이 0.2%p이고, 채점 머신 부하만으로 1문항이 움직입니다.
• 핵심 엔진은 공개하지 않았습니다. 질의를 데이터베이스에서 실행해 확인하는 검증 엔진은 비공개이고, 이 글의 분석은 공개 예측 파일과 공개 데이터에서 재현되는 부분만 다룹니다.
• 공식 등재는 아직 아닙니다. 등재 신청이 접수된 상태이고, 리더보드에 오르면 그 표기가 기준입니다.

FAQ

Q. 83.80이 BIRD 1위라는 뜻인가요?
아닙니다. 같은 개정판의 공식 기준선 표에서 Claude Opus 5.5(90.00), GPT-6.1 Sol(88.00), Claude Sonnet 5.5(86.60)가 더 높습니다. 공식 리더보드에는 아직 저희 항목이 없습니다.

Q. 그러면 이 결과의 의미는 무엇인가요?
같은 가중치가 고정 프롬프트에서는 68.20이었고, 실행 결과로 쿼리를 고치는 시스템에서는 83.80이 되었다는 점입니다. 순증 78문항 가운데 27문항은 빈 답이나 시간 초과 같은 공정 실패의 회복이었습니다.

Q. 개정 전후 점수를 섞어 비교해도 되나요?
권하지 않습니다. 개정판은 정답 SQL, 질문, 근거를 고치고 일부 문항을 바꿨습니다. 점수 옆의 날짜와 데이터 판을 확인하고, 확인이 안 되면 비교하지 않는 편이 안전합니다.

Q. 공개 예측 파일을 채점하면 정확히 419가 나오나요?
저희 머신에서는 병렬 8개로 두 번 모두 418이 나왔고 Q93 한 문항이 60초 제한에서 갈렸습니다. 단독 실행에서는 그 문항이 29초에 정답이라 419와 일치합니다. 머신 부하에 따라 한 문항이 흔들릴 수 있습니다.

Q. 정답 SQL을 추론에 쓰지 않았다고 어떻게 믿나요?
모델 카드의 평가 조건표에 그렇게 적었지만 이것도 자체 보고입니다. 믿음의 근거가 필요하다면 저희 말이 아니라 공개 예측 파일, 채점기, 데이터 판 번호로 확인하세요. 공식 채점은 BIRD 측 등재 절차에서 이뤄집니다.

정리

개정판이 나온 직후에는 점수보다 점수가 놓인 조건이 더 중요합니다. 저희 시스템의 83.80은 같은 개정판의 상용 모델 기준선 세 개보다 낮고, 개정 전에 올라온 리더보드 항목과는 비교할 수 없습니다. 그 가운데 확인된 사실은 두 가지입니다. 같은 가중치에서 시스템이 68.2를 83.8로 올렸고, 그 이득의 30%는 빈 답과 시간 초과의 회복이었으며, 11문항은 오히려 망가졌다는 점입니다. 공식 등재 결과가 나오면 숫자가 어떻게 되든 그대로 공유하겠습니다.

• 모델 카드와 예측 파일: FINAL-Bench/Darwin-180B-NL2SQL
• 데이터셋: birdsql/bird_mini_dev
• BIRD 공식 사이트: bird-bench.github.io
• 공개 데모(한국어·영어, 읽기 전용, 가상 데이터): ViSQL 데모

Further reading

• OWASP Benchmark 52.8점이 77.8점이 된 이유: AI 검증층이 거짓 양성을 줄이면 점수가 움직이는 산술
• 같은 모델인데 AUROC 0.835가 0.565로: 신약 AI 벤치마크에 시간 분할이 필요한 이유