온프레미스 Open LLM은 Text-to-SQL에서 어디까지 도달했는가? BIRD 데이터셋을 통한 모델군별 크기 x 기술 프런티어 분석

데이터를 클라우드 API로 전송할 수 없는 조직들은 점점 더 다음과 같은 질문을 던지고 있습니다: 모델이 오픈 웨이트 (open weights) 기반으로 온프레미스 (on-premises)에서 실행되어야 한다면 Text-to-SQL 성능은 어느 정도이며, 어떤 대중적인 정확도 "레시피 (recipes)"가 연산 비용 (compute)을 들일 가치가 있는가? 우리는 BIRD 개발 분할 데이터셋 (n=1534, 실행 정확도 (Execution Accuracy))을 사용하여 정직하고 완전히 재현 가능한 벤치마크를 통해 이에 대한 답을 제시합니다. 우리는 두 세대에 걸친 세 가지 오픈 모델군인 Qwen2.5-Coder (7B/14B/32B), CodeLlama-Instruct (7B/13B/34B), 그리고 Llama-3.x (8B, 70B)를 동일한 프로토콜 하에서 평가하였으며, 모델 불가지론적 (model-agnostic) 레시피 구성 요소(스키마 연결 (schema linking), 자기 수정 (self-correction), 자기 일관성 (self-consistency))를 구성 요소별로 절제 연구 (ablation)하였고, 모든 차이점은 대응 표본 McNemar 검정 (paired McNemar test)을 통해 테스트되었습니다. 네 가지 주요 발견 사항이 눈에 띕니다. (i) 모델의 크기보다 생성 (Generation) 능력이 더 중요하며, 레시피는 모델군에 관계없이 견고합니다: Qwen2.5-Coder는 동일한 크기에서 이전 세대인 CodeLlama를 압도하지만 (7B 기준 39.1 대 20.9), 현대적인 비-Qwen 모델 (Llama-3.3-70B, 동일 서빙 환경에서 49.2)도 경쟁력이 있습니다. 따라서 CodeLlama의 약점은 "비-Qwen = 약함"이 아니라 2023년 세대라는 점을 반영합니다. (ii) 자기 수정 (Self-correction)은 개선의 여지가 있는 세 모델군 모두에서 유의미하며, 비용이 거의 들지 않는 견고한 승리입니다. (iii) 스키마 연결 (Schema linking)은 도움이 되지 않으며, 더 강력한 연결기를 사용해도 이를 구제할 수 없습니다: 96.5%의 골드 테이블 재현율 (gold-table recall)을 가진 검색/임베딩 (retrieval/embedding) 연결기는 연결을 하지 않았을 때와 통계적으로 구별되지 않으며, 이를 통해 세 모델군 전체에서 "약한 어휘적 허수아비 (weak lexical strawman)"라는 반론을 배제합니다. (iv) 자기 일관성 (Self-consistency)은 가성비가 낮습니다 (약 5배의 토큰 사용 대비 +0.13%p 증가, 유의미하지 않음). 우리는 각 단계별 실제 비용 ($/1k 쿼리)을 보고하며 모든 코드, 예측값, 요약본을 공개합니다; 아카이브된 코드 및 데이터: https://doi.org/10.5281/zenodo.20952794