DEVOCEAN

최근 사내 Data Warehouse 를 기반으로 Text2SQL 챗봇을 구현하고 있습니다.

SNS 눈팅 중에 지인분이 공유해주신 논문내용이 지금 고민하고 있는 주제와 동일하여 읽어보고 리뷰를 해보고자 합니다.

논문에서는 Text2SQL 용어와 NL2SQL 이라는 용어를 혼용하여 있으며, 구현에 활용된 LLM 은 gpt-3.5-turbo-16k-0613 입니다.

논문의 내용을 개인적인 견해를 섞어서 아래와 같이 의역해보았습니다.

• 논문 : https://arxiv.org/pdf/2312.03463v2

DBCopilot: Scaling Natural Language Querying to Massive Databases

ABSTRACT

DB Copilot 프레임워크는 대규모 데이터베이스에 대한 간결하고 유연한 라우팅 모델을 제공합니다.

특별히, 스키마 라우팅을 통해 사용자의 자연어 질의문과 데이터베이스 스키마를 분리시켰습니다.

또한, 대규모 데이터베이스와 자연어 질의를 연결시키기 위해 도메인에 차별화된 검색 기능을 구현하였으며,

실험결과를 통해 DBCopilot 이 대규모 데이터베이스와 자연어 질의 간의 연결에 있어 효율적인 솔루션이라는 것을 증명합니다.

INTRODUCTION

자연어를 SQL(Structured Query Language)로 변환하는 NL2SQL(Natural language to SQL)은 데이터베이스에 대한 질문을

SQL 쿼리로 변환하여 데이터베이스 분석 및 쿼리를 비전문가에게도 유용하지만, 이전까지의 연구는 보통 소규모 데이터베이스에 집중하는 경향이 있어,

다양한 자연어 질문을 데이터베이스 모델 요소로의 의미 매핑을 구축하여 적절한 데이터베이스와 관련 테이블을 자동으로 식별하는 메커니즘 개발이 중요합니다.

그림에서 처럼 DBCopilot 은 아래와 같이 2 단계를 거칩니다.

1. 스키마 라우팅 : 자연어 질의를 차별화된 검색을 기반으로 데이터베이스와 테이블 대상을 찾음

2. SQL 생성 : 스키마 정보와 자연어 질의를 LLM 에 전달하여 SQL 을 생성

이러한 과정이 잘 동작하게 하기 위해 3가지 단계를 거쳤습니다.

1. 단순 테이블 검색이 아닌, 전체 스키마의 관계를 그래프 형태로 고려하여 검색, 검색 시 스키마 라우팅을 시퀀스-투-시퀀스(Seq2Seq) DSI로 모델링하고 DFS 직렬화 및 디코딩 처리

2. 리소스가 많이 들어가는 레이블링 작업을 LLM 에게 수행처리

3. 양질의 정보 생성을 위한 프롬프팅 전략 수립 및 시행

PRELIMINARIES

Schema Linkging vs. Schema Routing 은 두가지 측면의 차이가 있습니다.

첫째, 스키마 링킹은 정확한 생성을 위한 SQL 생성의 하위 단계이며, 스키마 라우팅은 질문의 알려지지 않은 스키마를 식별하기 위한 SQL 생성의 필수 전제 조건입니다.

둘째, 스키마 링킹의 입력은 스키마와 함께 자연어 질문인 반면, 스키마 라우팅의 입력은 자연어 질문이고 출력은 인덱싱되거나 기억된 스키마입니다.

Generative Retrieval

전통적인 정보 검색(IR) 기법은 일반적으로 "인덱스-검색" 패러다임을 따릅니다. 이러한 경우 관계를 포함하는 정보 검색에 한계가 있으며,

이를 해결하기 위해 Generative, Retrieval ](a.k.a. DSI)이라는 신흥 패러다임이 등장합니다.

이는 Seq2Seq 사전 훈련된 언어 모델(PLM)을 훈련하여 쿼리를 직접 관련 문서 식별자로 매핑하고,

전통적인 "인덱스-검색" 파이프라인을 단일 신경 모델 내에서 완전히 매개 변수화하여, 인덱싱 및 검색 작업을 모델 매개 변수로 모델링하는 것입니다.

Methodology

스키마 라우팅의 학습 프로세스는 아래와 같습니다.

쉬운 이해를 위해 아래 예제를 살펴보면,

첫번째 단계에서 주어진 질문의 스키마 라우팅이 되고, 답변으로는 대상 테이블과 컬럼 정보가 응답됩니다.

두번째 단계에서는, 스키마와 질문을 바탕으로 SQL 을 생성하게 됩니다.

Schema Graph Construction

자연어 표현과 달리, 유효한 SQL 쿼리는 데이터베이스의 구조를 따라야 합니다.

따라서 스키마 요소 간의 내재된 관계/제약에 대해 스키마 라우터에게 정보를 제공하는 것이 필요합니다.

이를 위해, 모든 데이터베이스 D와 그 테이블 T의 기본 스키마 구조를 나타내기 위해 방향 그래프 G = ⟨V, E⟩를 구성합니다.

• 포함 관계: 데이터베이스가 데이터베이스 집합의 일부인지, 테이블이 데이터베이스에 속하는지를 나타냄

• 테이블 관계: 테이블 노드 간의 명시적인 주-외래 및 암시적 외래-외래 관계를 포함

알고리즘 1은 이 세 단계 계층적 스키마 그래프를 구축하는 절차를 보여줍니다.

무작위로 테이블을 정렬하는 단순한 방법과 달리, DFS 직렬화는 연관 테이블 같은 중요한 요소를 누락하지 않고 모든 관련 요소를 포괄적으로 다룰 수 있으며,

이를 위해 알고리즘 2의 적용이 필요합니다.

Training Data Synthesis

노동없이 양질의 퀄리티를 보장하기 위해, LLM 을 활용하여 스키마를 바탕으로 역으로 질문을 생성하는 방법을 사용하였습니다.

스키마 라우터를 훈련한 후, 생성된 스키마의 유효성을 보장하기 위해 그래프 기반 제약된 디코딩 알고리즘을 추가로 설계합니다.

그림 4에서 보여지듯이, 자기 회귀 디코딩의 각 단계에서, 디코드된 스키마 요소에서 접근 가능한 노드의 이름을 포함하는 동적 접두사 트리를 유지합니다.

SQL GENERATION

보다 정확한 SQL 생성을 위해 아래와 같은 프롬프트 전략을 연구합니다.

• 최적 스키마 프롬프팅: 스키마 라우터가 생성한 가장 높은 확률의 스키마를 LLM에 지시

• 다중 스키마 프롬프팅: 프롬프트에서 다른 시퀀스의 테이블 스키마를 단순히 연결함으로써 여러 후보 스키마를 사용하여 LLM 에 SQL 생성 지시

• 다중 스키마 COT 프롬프팅: 사슬 생각(Chain of Thought, COT) 추론을 통해 여러 후보 스키마를 사용하여 LLM에 지시하고,

  가장 관련성 높은 후보 스키마를 선택하도록 요청한 다음 SQL 쿼리를 생성

EXPERIMENT

실험 및 평가를 위한 데이터셋은 아래와 같습니다.

• Spider : Spider는 138개 도메인과 200개 데이터베이스에 걸쳐 10,181개의 질문과 5,693개의 고유 SQL 쿼리를 포함하는 널리 사용되는 크로스 도메인 NL2SQL 데이터셋 입니다.

• Bird : Bird는 데이터베이스 값의 중요성을 강조하기 위해 설계된 최근의 NL2SQL 데이터셋 입니다.

• Fiben : Fiben은 152개 테이블을 가진 데이터베이스에서 237개의 다양한 복잡한 SQL 쿼리에 해당하는 300개의 자연어 질문으로 구성되어 있으며,

  주로 중첩 및 집계를 포함하는 복잡한 비즈니스 인텔리전스 쿼리의 처리를 평가하기 위해 설계된 데이터셋 입니다.

BASELINES

DBCopilot 의 성능 평가를 비교하기 위한 베이스라인 모델들은 아래와 같습니다.

• BM25 : BM25는 관련 문서를 검색하는 데 널리 사용되는 잘 알려진 순위 결정 함수입니다.

• SXFMR : SXFMR은 관련 텍스트 쌍에 대한 Transformer(XFMR) 기반 PLM의 대조 학습을 통해 밀집 검색을 위한 일반 임베딩 모델을 얻는 기술입니다.

• CRUSH : CRUSH는 NL2SQL을 위해 스키마 요소를 검색하는 두 단계 접근법을 채택합니다. 먼저 LLM에게 환상적인 스키마를 생성하도록 지시한 다음, 여러 검색 결과를 결합하여 실제 스키마를 얻습니다.

• DTR : DTR은 레이블이 지정된 (질문, 테이블) 쌍에 대한 대조 학습을 사용하여 테이블을 검색하는 도구를 개발하는 접근 방식으로, 테이블 위의 오픈 도메인 질문 응답을 위해 사용됩니다.

EVALUATION METRICS

스키마 라우팅의 경우, 우리는 Recall@k와 mAP(평균 정밀도)를 사용하여 검색된 데이터베이스와 테이블의 관련성을 평가합니다.

Recall@k는 상위 k개 검색 후보 중 관련 인스턴스의 비율을 측정합니다.

예를들면, Recall@1 이라는 것은, 검색 결과 중에서 상위 1개의 항목만 고려할 때, 관련 있는 항목이 얼마나 잘 검색되었는지를 측정하는 지표이며,

가장 관련성이 높은 것으로 추정되는 첫 번째 결과가 실제로 관련 있는지를 평가하는 것 입니다.

mAP는 모든 쿼리에 대한 평균 정밀도를 계산하며, 이는 전체 검색 성능을 반영합니다.

SQL 생성의 경우, 전통적인 표면 수준 메트릭은 LLM 기반 접근 방식에 부적합하며, 우리는 생성된 SQL 의 실행 결과를 정답셋과 비교하여 판단합니다.

CONCLUSION

평가 결과표에 대한 상세 설명은 스킵(DBCopilot 이 좋다는 내용을 길게 써놨음)하고, 현 시점에 진행하는 프로젝트와 비교했을 때 상당히 유사한 아키텍처를 가지고 있다는 것을 알았습니다.

최근 RAG 로 표현되는 정보 검색 및 프롬프트 증강을 통해 대규모 데이터베이스에 일반적으로 적용될 수 있는 Text2SQL 챗봇을 구현 중인데,

논문에 언급된 거의 모든 내용이 고민하던 영역이며 아키텍처도 유사합니다.

다만 그래프 기반의 관계 검색을 하는 부분이 없다는 점 정도가 다른 것 같습니다.

향후 프로젝트가 성능 개선에 포커스 되는 시점까지 진행된다면, 논문에서 제안한 스키마 라우팅도 적용해보고자 합니다.

감사합니다.