왜 엔터프라이즈 환경에서 Text-to-SQL이 실패하는가
대부분의 Text-to-SQL 데모는 지나치게 깔끔합니다.
단순한 스키마와 명확한 테이블 이름을 사용하며, 한두 개의 테이블이 완벽하게 연결되어 있다고 가정합니다. 데모용으로는 괜찮지만, 실제 기업 환경에서는 실패합니다.
엔터프라이즈 데이터베이스에서 어려운 점은 SELECT 절이 아닙니다. 진짜 어려운 점은 조인 경로(join path)입니다.
모델이 고객별 매출을 구하는 유효한 쿼리를 작성할 수 있습니다. SQL은 실행되고, 대시보드에는 숫자가 나타납니다. 하지만 결과값은 틀렸습니다.
왜 이런 일이 발생할까요?
- 고객 테이블이 공식 마스터 리스트가 아님
- 매출(revenue) 필드가 재무팀에서 승인한 버전이 아님
- 지역별로 레코드가 중복되어 있음
- 조인 과정에서 팬아웃(fanout) 오류가 발생함
- 회계 연도가 달력상의 연도와 다름
구문론적으로 유효한 쿼리가 곧 신뢰할 수 있는 쿼리는 아닙니다.
실제 운영 시스템은 복잡합니다. 외래 키(foreign key) 누락, 레거시 테이블, 그리고 숫자를 부풀리는 일대다(one-to-many) 관계 등에 직면하게 됩니다. 사람조차도 조인 결과를 신뢰하기 전에 예전 보고서를 확인하거나 재무팀에 문의해야 합니다.
AI 모델은 이름과 컬럼만 봅니다. 그리고 추측합니다. 때로는 그 추측이 위험할 수 있습니다.
팬아웃을 생각해 보십시오. 주문(orders)을 주문 상세(order lines)에 조인하고, 이를 다시 배송(shipments)에 조인하면, 하나의 주문이 여러 번 집계될 수 있습니다. SQL은 문법적으로 맞지만, 결과는 틀립니다.
메타데이터가 도움이 되긴 하지만 충분하지 않습니다. 컬럼 이름만으로는 해당 관계가 재무 보고용으로 안전한지 알 수 없습니다. 외래 키는 과거의 예외 상황을 설명해주지 않습니다.
Text-to-SQL에는 관계 지능(relationship intelligence)이 필요합니다.
신뢰할 수 있는 시스템은 다음을 알아야 합니다:
- 특정 비즈니스 질문에 대해 승인된 조인 경로
- 관계의 카디널리티(cardinality)
- 알려진 팬아웃 위험 요소
- 더 이상 사용되지 않는(deprecated) 경로
단순히 코드를 작성하는 대신, 시스템은 안전성에 대해 추론해야 합니다. 신뢰할 수 있는 경로를 선택하거나, 경로가 불분명할 경우 도움을 요청해야 합니다.
현재 시스템의 격차는 이름을 매핑하는 단계에서 SQL을 생성하는 단계로 넘어가는 과정에 있습니다. 관계 컨텍스트(relationship context)라는 계층을 반드시 추가해야 합니다.
Text-to-SQL은 단순한 언어 문제가 아닙니다. 컨텍스트의 문제입니다.
모델이 어떤 조인이 안전한지 이해하기 전까지, 데모에서는 작동할지 몰라도 실제 운영 환경에서는 실패할 것입니다.
Source: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0
Optional learning community: https://t.me/GyaanSetuAi