Text2SQL이 어려운 이유
최근 회사에서 사용자가 질의를 하면 ERP 데이터를 가져와 시각화해주는 Agent를 제작하고 있습니다.
여러 부분에서 난관이 있지만 현재 가장 많은 리소스를 쓰고 있고 개인적으로 막막하기도 한 Text2SQL이 특히 어려운 이유에 대해 정리해 봤습니다.
먼저 Text2SQL을 설명을 하면,
자연어를 기반으로 데이터베이스 언어인 SQL문을 제작해 내는 것
이라고 말할 수 있습니다.
쉽게 말하면 LLM을 통해 사용자의 질의를 데이터를 조회할 수 있는 언어로 변환해 주는 작업입니다.
LLM은 정확한 SQL을 생성하기 위해 상당한 양의 지식이나 "맥락"을 필요로 합니다.
필요한 맥락은 두 가지 종류가 있는데 바로 명시적 맥락과 암묵적 맥락입니다.
명시적(스키마는 어떻게 생겼는가, 관련 열은 무엇인가, 데이터 자체는 어떻게 생겼는가?)
암묵적(데이터의 정확한 의미는 무엇인가? 특정 비즈니스 사례에서 어떤 의미를 갖는가?)
명시적 맥락은 RAG를 이용하여 스키마 정보(join, fields)를 가져오는 것으로 어느 정도 해소할 수 있지만,
암묵적 맥락을 전달하기 위해서는 모든 데이터베이스나 데이터세트의 형태를 학습하고 스키마 또는 데이터 변경 사항을 따라가는 것은 어렵고 비용도 많이 드는 작업입니다. 또한, 기업의 비즈니스 지식과 의미론은 애초에 제대로 문서화되어 있지 않은 경우가 많으며, 학습 데이터로 변환하기도 어렵습니다.
Specialized model training, or fine tuning, is typically not a scalable solution to this problem. Training on the shape of every database or dataset, and keeping up with schema or data changes, is both difficult and cost-prohibitive. Business knowledge and semantics are often not well documented in the first place, and difficult to turn into training data.(GCP)
예를 들어, 세계 최고의 DBA라도 표 cat_id2 = 'Footwear'에서 pcat_extension 해당 제품이 신발의 일종이라는 것을 알지 못한다면 신발 판매를 추적하는 정확한 쿼리를 작성할 수 없을 것입니다. 이는 LLM에게도 마찬가지입니다.
사람의 언어(자연어)는 SQL보다 정확도가 떨어집니다.
엔지니어나 분석가는 모호한 질문에 직면했을 때 더 많은 정보가 필요하다는 것을 감지하고 적절한 후속 질문이 가능합니다. 반면, LLM은 답변을 제공하려는 경향이 있으며, 질문이 모호할 경우 환각 증상을 보일 수 있습니다.
예시로 "가장 잘 팔리는 신발은 무엇인가?"와 같은 질문을 생각해 보겠습니다. 여기서 한 가지 분명한 모호점은 비즈니스나 애플리케이션 맥락에서 "가장 잘 팔리는" 것이 실제로 무엇을 의미하는가입니다. 가장 많이 주문된 신발? 가장 많은 수익을 올린 신발 브랜드? 더 나아가, SQL에서 반품된 주문 수를 계산해야 할까요? 보고서에 몇 종류의 신발을 포함해야 할까요? 등등
또한, 사용자마다 필요한 답변의 유형이 다릅니다.
이렇기에 사용자가 기술 분석가나 개발자로서 모호한 질문을 한다면, 합리적이지만 100% 정확하지는 않은 SQL 쿼리를 제공하는 것이 좋은 출발점이 될 수 있습니다.
그러나, 사용자가 기술적인 지식이 부족하고 SQL을 이해하지 못한다면, 정확한 SQL을 제공하는 것이 더욱 중요 해집니다. 이유는 기술적 지식이 없는 사용자는 LLM의 답변을 그대로 믿을 것이기 때문입니다.
그렇기에 모호성을 해소하기 위해 후속 질문을 통해 답변하고, 답변의 논리를 설명하며, 사용자가 원하는 것을 찾을 수 있도록 안내하는 것이 중요합니다.
Google의 연구에 따르면 SQL문 언어 자체가 미묘하게 차이가 있어 LLM이 기존 프로그래밍 언어보다 성능이 떨어집니다.
Python과 Java 같은 프로그래밍 언어의 차이보다 훨씬 미묘한 SQL 언어 간의 차이점을 생각해 보면 됩니다. 간단한 예로, BigQuery SQL을 사용하는 경우 타임스탬프 열에서 월을 추출하는 올바른 함수는 EXTRACT(MONTH FROM timestamp_column)입니다. 하지만 MySQL을 사용하는 경우 MONTH(timestamp_column) 로 미묘한 차이가 있습니다.
.
이러한 Text2SQL의 다양한 제약에도 불구하고, 자연어 만으로 데이터를 핸들링할 수 있다는 너무나 강력한 이유로 최근 AWS와 GCP와 같은 클라우드 기업에서도 Text2SQL과 관련해 활발한 연구가 진행 중입니다.
다음 글에는 Text2SQL이 오류 유형을 정리해 보겠습니다. 감사합니다.