UniQL은 BIRD의 1,534개 Text-to-SQL 질문을 16개의 SQL 방언으로 변환하는 새로운 벤치마크입니다. 이 중 Oracle 컬럼이 까다롭습니다. 현재까지 발표된 최고 결과는 49.61% (Claude Sonnet 4.5)이며, Gemini 2.5 Pro는 26.14%를 기록했습니다.
저는 schemagate에 경량 모델인 Gemini 2.5 Flash를 사용하여 테스트를 진행했습니다. 아래 점수는 UniQL 자체 평가 도구를 사용했으며, Oracle Free 23ai 환경에서 측정되었습니다.
| UniQL Oracle, 1,534개 질문 | 첫 시도 (First try) | 오류 수정 포함 (With error repair) |
|---|
| schemagate + Gemini 2.5 Flash | 35.0 | 69.9 |
| ... | | |
| 첫 번째 실행 결과는 잘못된 이유로 좋아 보였습니다. 69.9%라는 수치는 주로 schemagate의 오류 수정 루프(repair loop) 덕분이었습니다. 즉, 쿼리를 실행하고 Oracle에서 발생한 오류를 모델에게 보여준 후, 이를 수정하도록 한 것입니다. 첫 시도만 놓고 보면 Flash는 35%에 그쳤습니다. 이는 기본적인 모델들의 성능보다 낮으며, 단일 시도 결과와 비교하기에는 공정한 비교가 아닙니다. | | |
거의 모든 문제의 원인은 두 가지 실수였습니다. 실패한 694개의 첫 번째 쿼리 중:
- 551개는
FROM account AS a를 작성했습니다. Oracle은 테이블 별칭(alias) 앞에 AS를 허용하지 않습니다.
- 100개는 따옴표 없이
DATE 또는 NUMBER라는 컬럼 이름을 사용했습니다. 둘 다 예약어(reserved words)입니다.
따라서 schemagate는 이제 타겟이 Oracle일 경우 모델에게 Oracle의 규칙을 알려줍니다. 그 결과, 첫 시도 정확도는 **35.0%에서 64.5%**로 향상되었는데, 이는 가장 좋은 성능을 보인 발표된 모델보다 약 15포인트 높은 수치이며, 더 가벼운 모델을 사용했습니다. 실패한 첫 번째 쿼리 수는 694개에서 85개로 감소했습니다. 다른 데이터베이스의 프롬프트는 변경되지 않았습니다.
제가 얻은 교훈은 다음과 같습니다: 튜닝(tune)하기 전에 측정하고, 다른 사람들이 보고하는 수치와 일치하는 숫자를 보고해야 합니다. 오류 수정 루프는 좋은 설계이지만, 단일 시도 결과 열에 포함되어서는 안 됩니다.
UniQL 리더보드 제출: JerryGao818/UniQL#2. 예측값, 평가 도구 출력 및 재현 워크플로우: https://github.com/ashishsinha1602/schemagate/tree/main/benchmarks/results/uniql_oracle