기술 요약: FlexSQL

문제 정의

텍스트-SQL 시스템은 분석용 데이터베이스의 규모와 복잡성이 증가함에 따라 점점 더 큰 도전에 직면하고 있습니다. 현대의 데이터 웨어하우스 (예: Snowflake, BigQuery) 는 종종 여러 스키마로 조직된 수백 개의 테이블을 포함하며, 일부 데이터베이스는 6 만 개가 넘는 컬럼을 보유하기도 합니다. 기존 시스템은 일반적으로 고정된 파이프라인을 따릅니다. 즉, 사전에 스키마 요소를 한 번 검색한 후, 그 정적 스냅샷을 기반으로 쿼리를 생성하며, 오류가 발생한 경우에만 사후 수리를 위해 데이터베이스를 다시 참조합니다.

이러한 경직성은 두 가지 주요 실패 모드를 초래합니다:

1. 초기 오류로부터 회복하지 못함: 모델이 초기 스키마 링크 단계에서 잘못된 테이블을 선택하거나 컬럼의 의미를 오해할 경우, 하류의 수리 메커니즘은 복구할 수 없습니다. 에이전트가 근본적인 가정을 수정하는 대신 코드 수정에 갇힌 루프에 빠지기 때문입니다.
2. 쿼리 모호성: 자연어 쿼리는 종종 여러 가지 유효한 해석을 허용합니다 (예: 인용 테이블의 어떤 부분집합을 사용할지). 고정된 파이프라인은 종종 단일 해석에 확정하여 유효한 대안 솔루션을 놓칩니다.

방법론: FlexSQL 프레임워크

FlexSQL 은 유연한 데이터베이스 상호작용을 중심으로 설계된 텍스트-SQL 에이전트를 도입합니다. 고정된 파이프라인 대신, 에이전트는 추론 과정의 어느 시점에서든 스키마 구조를 탐색하고, 데이터 값을 검사하며, 검증 쿼리를 실행할 수 있습니다.

핵심 구성 요소

1. 도구 기반 데이터베이스 상호작용:
   에이전트는 점진적으로 데이터베이스와 상호작용할 수 있는 도구 세트를 갖추고 있습니다:

   • 스키마 탐색: GetSchema(스키마 내 테이블 목록) 와 GetTableCol(컬럼 및 샘플 값 검사) 을 통해 상향식 탐색이 가능합니다.
   • 데이터 검사: GetColValues 와 FindRows 는 에이전트가 메타데이터에만 의존하는 대신 실제 데이터 값을 기반으로 결정을 내릴 수 있게 합니다 (예: "재료 과학"이 "MS-01"과 같은 특정 코드에 해당함을 발견).
   • 코드 실행: SQLExecutor 와 PythonExecutor 는 에이전트가 부분 쿼리를 테스트하고, 중간 결과를 검증하며, 부분 솔루션을 반복적으로 디버깅할 수 있게 합니다.

2. 다양성 강제 계획 생성:
   쿼리 모호성을 처리하기 위해 FlexSQL 은 **구술화된 샘플링 (verbalized sampling)**을 사용하여 $K$개의 다양한 실행 계획을 생성합니다. 이러한 계획은 테이블 선택, 조인 경로, 술어 해석에 관한 서로 다른 해석을 포괄합니다. 에이전트는 계획을 최종 확정하기 전에 각 계획을 실제 데이터에 기반하여 적극적으로 데이터베이스를 탐색합니다.

3. 이중 언어 프로그램 합성 (SQL 및 Python):
   FlexSQL 은 작업의 복잡성에 따라 각 계획을 SQL 또는 Python 중 하나로 구현할 수 있게 합니다.

   • SQL은 선언적 관계형 쿼리에 사용됩니다.
   • Python은 순수 SQL 로는 번거로운 절차적 워크플로우, 다단계 변환, 반복적 논리에 활용됩니다.
   • Python 솔루션은 최종 출력을 위해 SQL 로 변환 (트랜스파일) 됩니다.

4. 2 단계 수리 및 백트래킹:

   • 코드 수준 수리: 생성된 프로그램이 실패할 경우 (구문 오류, 잘못된 집계 등), 에이전트는 오류 피드백을 받아 코드를 재생성합니다.
   • 계획 수준 백트래킹: 오류가 잘못된 테이블 선택이나 누락된 조인과 같은 더 깊은 추론 결함에서 비롯된 경우, 시스템은 계획 생성 단계로 백트래킹합니다. 에이전트는 단순히 코드를 패치하는 대신 계획 자체를 수정하고, 필요시 데이터베이스를 다시 탐색합니다.

5. 다수결 투표:
   $K$개의 프로그램 (SQL 과 Python 의 혼합) 을 생성한 후, 시스템은 실행 결과에 따라 이를 그룹화합니다. 합의된 답변 (가장 큰 동치 클래스) 이 선택됩니다. 합의된 답변이 Python 솔루션인 경우, SQL 로 변환됩니다.

주요 기여

• 유연한 상호작용 아키텍처: 전 추론 과정에서 스키마 탐색, 데이터 검사, 코드 실행을 위한 온디맨드 도구로 고정된 파이프라인 단계를 대체하는 텍스트-SQL 에이전트.
• 백트래킹이 포함된 2 단계 계획 - 프로그램 아키텍처: 에이전트가 오류가 감지되었을 때 코드뿐만 아니라 근본적인 계획과 스키마 가정도 수정할 수 있게 하는 아키텍처.
• 다양성과 이중 언어 생성: 모호성을 처리하기 위한 다양성 강제 계획 샘플링과 다양한 전략을 유연하게 구현하기 위한 이중 언어 (SQL/Python) 생성의 결합.
• 실증적 검증: 다양한 모델 크기와 테스트 시간 확장성에서 효과성을 입증한 Spider2.0 벤치마크에서의 강력한 성능.

실험 결과

저자들은 Spider2-Snow(Snowflake 데이터베이스의 544 개 질문) 와 Spider2-SQLite(SQLite 데이터베이스의 135 개 질문) 에서 FlexSQL 을 평가했으며, gpt-oss-120b와 gpt-oss-20b를 사용하여 강력한 오픈소스 베이스라인 (ReFoRCE 및 DSR-SQL) 과 비교했습니다.

• 성능: gpt-oss-120b를 사용할 때, FlexSQL 은 Spider2-Snow 에서 65.44% Majority@8를 달성했습니다. 이는 FlexSQL 이 훨씬 작은 백본 모델을 사용했음에도 불구하고 DeepSeek-R1 을 사용한 DSR-SQL 과 gpt-o3 를 사용한 ReFoRCE 를 능가했습니다.
• 파라미터 효율성: gpt-oss-20b버전 FlexSQL 은 더 큰 120b 모델을 사용한 베이스라인을 능가하거나 동등한 성능을 보였습니다.
• 테스트 시간 확장: 샘플링 예산 ($K$) 이 8 에서 64 로 증가함에 따라 FlexSQL 은 일관된 향상을 보여주어, 다양성 강제 접근법의 유효성을 확인했습니다.
• 절대성 연구 (Ablation Studies):
  • Python 지원을 제거하면 성능 저하가 가장 크게 발생하여, 복잡한 논리를 위한 이중 언어 생성의 필요성을 강조했습니다.
  • 다양한 계획을 제거하면 Majority@8 정확도가 감소하여, 여러 해석을 포괄하는 것이 합의의 질을 향상시킨다는 것을 확인했습니다.
  • 백트래킹을 제거하면 성능이 저하되어, 단순히 코드를 수정하는 대신 고수준 계획을 수정하는 것의 가치를 보여주었습니다.
• 일반화: FlexSQL 을 범용 코딩 에이전트 (Claude Code) 의 기술로 통합했을 때, Spider2-Snow 에서 10% 이상의 상대적 개선이 있었습니다.

중요성과 주장

이 논문은 유연성이 차세대 텍스트-SQL 에이전트의 핵심 설계 원칙이라고 주장합니다. 에이전트가 언제든지 스키마를 탐색하고, 데이터를 검사하며, 오류에서 백트래킹할 수 있게 함으로써 FlexSQL 은 초기 추론 오류로부터 회복하지 못하는 고정된 파이프라인의 한계를 극복합니다.

저자들은 그들의 접근 방식이 다음을 강조한다고 말합니다:

1. 실제 데이터에 기반한 결정: 정적 스키마 메타데이터를 넘어 실제 값을 검사함으로써 메타데이터만으로는 해결할 수 없는 모호성을 해소합니다.
2. 추론 시간 컴퓨팅 활용: 다양한 계획을 생성하고 다수결 투표를 사용하여 증가된 샘플링 예산을 효과적으로 활용하여 견고성을 향상시킵니다.
3. 선언적 논리와 절차적 논리 간의 간극 해소: 이중 언어 접근법 (SQL/Python) 은 에이전트가 특정 추론 작업에 가장 효과적인 도구를 선택하고, 복잡한 절차적 논리를 실행을 위해 다시 SQL 로 변환할 수 있게 합니다.

이 연구는 대규모 복잡한 분석용 데이터베이스의 경우, 사전 검색된 스키마 스냅샷에서 단순히 쿼리를 생성하는 것보다 가설을 반복적으로 탐색하고 수정하는 능력이 더 중요함을 시사합니다.