“모두가 쉽게 필요한 데이터를 조회하고, 원하는 데이터셋을 생성할 수 있다면 얼마나 좋을까요?”

안녕하세요. HEARTCOUNT 팀의 Sam입니다. 몇 번의 클릭만으로 사용자가 데이터를 직접 조회할 수 있는 HEARTCOUNT ABI의 Text-to-SQL 기능을 이전에 소개해 드린 적이 있는데요.

텍스트를 SQL로 자동변환 해주는 기술, Text To SQL

Text-to-SQL은 SQL 문법이 익숙하지 않아도, 데이터에 쉽게 접근할 수 있도록 만들어진 기능입니다. 그 특징과 사용법을 확인해 보세요.

HEARTCOUNT COMMUNITYheartcount

과거에는 데이터 조회를 위해 복잡한 SQL 쿼리를 작성해야 했고, 이는 비전문가들에게 상당한 장벽이 되었습니다. 하지만 최근에는 LLM을 활용하여 비전문가들도 손쉽게 데이터에 접근하는 길이 열렸습니다. 특히 Text-to-SQL 기능은 LLM을 활용하여 자연어로 된 질문을 이해하고 이를 SQL 쿼리로 변환하여, 사용자가 원하는 정보를 효율적으로 제공하는 대표적인 기능입니다.

그럼에도, 기존의 Text-to-SQL 기술은 몇 가지 한계점에 직면하고 있었고, 최근 이러한 문제를 해결하기 위해 RAG(Retrieval-Augmented Generation, 검색-증강 생성)이라는 기술이 주목받고 있습니다. 이번 글에서는 Text-to-SQL 기술이 어떤 원리로 작동하는지 간단히 설명하고, 기존의 문제점과 이를 해결하기 위해 HEARTCOUNT ABI가 RAG를 도입하게 된 이유, 그리고 새로운 Text-to-SQL 2.0 모델을 여러분께 미리 소개해 드리도록 하겠습니다.

Text-to-SQL이 뭔가요?

Text-to-SQL이란

Text-to-SQL은 자연어로 작성된 질문을 SQL 쿼리로 자동 변환하는 기술로, 데이터베이스에 대한 비전문가들의 접근성을 높이는 데 중요한 역할을 합니다. 복잡한 SQL 쿼리를 작성할 필요 없이, 사용자가 “지난해 매출이 가장 높은 달은 언제인가요?”와 같은 질문을 입력하면, 이 질문을 SQL 문법으로 변환하여 결과를 반환할 수 있습니다.

Text-to-SQL 기능은 단순히 SQL 작성의 수고를 덜어줄 뿐 아니라, 사용자들이 직접 필요한 데이터를 손쉽게 찾아 분석할 수 있도록 돕습니다. 이를 통해 데이터 분석 과정이 한층 빨라지고 효율화 되어, 데이터 팀의 업무 부담도 크게 줄어듭니다.

특히, 데이터에 기반한 빠른 의사결정이 중요한 현대 비즈니스 환경에서, Text-to-SQL 기능은 누구나 데이터에 접근하고 인사이트를 도출할 수 있는 핵심 도구로 자리 잡고 있습니다. 이를 통해 기업은 전반적인 데이터 활용도를 극대화하고, 전 구성원이 데이터를 활용한 전략적 결정을 내릴 수 있는 환경을 조성할 수 있습니다.

ABI Text-to-SQL의 작동 방식

기존 HEARTCOUNT ABI의 Text-to-SQL 모델은 다음과 같은 과정을 거칩니다.

1. Schema Mapping: 데이터베이스 내의 테이블과 컬럼에 대한 정보를 활용해 질문의 특정 테이블과 스키마를 매핑합니다.
2. Prompt Manager: 질문에 최적의 답변을 제공하기 위해, Prompt를 생성하고 관리하는 모듈입니다.
3. LLM + Parser: 생성한 프롬프트와 LLM을 바탕으로 SQL 쿼리를 생성합니다.

정확한 쿼리 생성을 위해서는 데이터베이스의 구조와 질문의 의미를 올바르게 파악하는 것이 중요합니다. ABI Text-to-SQL 모델은 이 과정을 단순 규칙 기반 프롬프팅 혹은 스키마 매핑 방식으로 처리해 왔으나, 복잡한 질문이나 특정 도메인에 특화된 질의에서는 정확성이 떨어지는 문제점이 있었습니다.

기존 ABI Text-to-SQL 모델의 문제점

현재 HEARTCOUNT ABI에서 사용하는 Text-to-SQL 모델의 한계는 크게 두 가지로 요약됩니다.

1. 정확도 문제
   기존 모델들은 특화된 도메인에 대한 질문을 처리할 때 성능이 저하되는 문제가 있었습니다. 특히 도메인 특화된 용어를 사용하거나 복잡한 질의 구조가 포함된 경우, 모델이 정확한 SQL을 생성하지 못하는 경우가 많았습니다. 이는 데이터베이스의 스키마와 질문 사이의 연결을 정확하게 파악하지 못했기 때문입니다. 또한 동일한 규칙이나 프롬프트가 모든 데이터베이스에 적용되다 보니, *few-shot 학습의 장점을 충분히 활용하지 못하는 한계도 있었습니다.

다음 예시로 의료 분야와 같은 특화된 도메인을 가정해 보겠습니다. LLM을 활용한 Text-to-SQL 모델은 ‘심혈관계 질환’의 개념을 이해할 수는 있을 겁니다. 하지만 데이터에서 ‘심혈관계 질환’이 질병 코드로만 표현된다면, 관련 질병 코드를 찾아 SQL에 포함시키는 일은 쉽지 않습니다. 도메인 특화 용어가 많아질수록, 참조해야 할 테이블과 컬럼을 정확히 파악하지 못해 정확도가 떨어질 수 있습니다. 그러나 few-shot 학습으로 심혈관계 질환 관련 질문과 SQL 예시를 추가로 학습시키면, 모델이 참조할 질병 코드와 사용된 테이블 및 컬럼을 파악하여 더 정확한 SQL을 생성하는 데 도움이 될 것입니다.

2. 토큰 사용량 문제
   대규모 데이터베이스나 복잡한 질문에 대한 처리 과정에서, 모델이 많은 토큰을 소비하여 비효율적인 자원 사용이 발생합니다. 이 문제는 특히 다양한 데이터베이스 스키마와 다량의 매핑 정보가 요구되는 경우 심각해지며, 전체 질의와 데이터베이스 구조를 프롬프트로 함께 제공할 때 프롬프트가 길어지기 때문에 모델의 맥락 파악이 어려워져 *정확도 문제(Lost in the Middle)로 이어질 수 있습니다.

Lost in the Middle: How Language Models Use Long Contexts

While recent language models have the ability to take long contexts as input, relatively little is known about how well they use longer context. We analyze the performance of language models on two tasks that require identifying relevant information in their input contexts: multi-document question answering and key-value retrieval. We find that performance can degrade significantly when changing the position of relevant information, indicating that current language models do not robustly make use of information in long input contexts. In particular, we observe that performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models. Our analysis provides a better understanding of how language models use their input context and provides new evaluation protocols for future long-context language models.

arXiv.orgNelson F. Liu

RAG란 무엇인가?

RAG(Retrieval-Augmented Generation)는 대형 언어 모델(LLM)의 한계를 보완하기 위해 고안된 방식으로, 질문에 대한 외부 정보를 검색해 답변을 생성하는 통합 접근 방식입니다. 기존 LLM은 학습된 데이터에 의존하기 때문에 최신 정보나 학습 데이터에 포함되지 않은 특수한 도메인에 대한 지식이 부족할 수 있습니다. RAG는 이러한 문제를 해결하기 위해 모델이 특정 질문에 대해 외부에서 관련 데이터를 검색하고 이를 기반으로 답변을 생성할 수 있게 합니다.

RAG는 일반적으로 검색과 생성 두 가지 단계를 거칩니다:

1. 검색 단계: 질문에 대한 관련 정보를 데이터베이스나 지식 베이스에서 검색하여 필요한 정보를 가져옵니다.
2. 생성 단계: 검색된 정보를 바탕으로 질문에 대한 답변을 생성합니다. LLM은 검색된 정보와 질문을 함께 입력으로 받아 적절한 답변을 구성합니다.

이러한 통합 방식 덕분에, RAG는 모델이 학습 데이터에 포함되지 않은 최신 정보나 특정 도메인에 대한 질문에 대해 더 정확하고 신뢰성 있는 답변을 제공할 수 있습니다.

눈에는 눈, SQL에는 SQL

RAG의 강점은 검색과 생성의 결합에서 비롯됩니다. 일반적인 생성 모델은 학습된 데이터에만 의존하지만, RAG는 모델이 검색한 연관성이 높은 자료를 포함하여 답변의 정확성을 높입니다. 예를 들어, 사용자가 Text-to-SQL 모델에 특정한 데이터베이스 스키마와 관련된 질문을 던지면, RAG는 해당 데이터베이스와 유사한 질문을 검색하여 모델에 제공하고 이를 통해 보다 정확한 SQL 쿼리를 생성할 수 있도록 합니다.

이처럼 검색된 정보가 모델의 입력으로 들어가면서, few-shot 학습과 같은 기술의 효과가 극대화됩니다. 특히, RAG는 유사한 질문과 그에 대한 답변을 프롬프트에 포함해, 모델이 질의 응답의 문맥을 더 잘 이해하고 결과적으로 더 정확한 쿼리를 생성하도록 돕습니다.

Text-to-SQL 2.0 소개

RAG를 통해 해결 가능한 점

Text-to-SQL 모델에서 RAG(Retrieval-Augmented Generation)는 기존의 한계를 극복하는 데 크게 기여합니다. 이전에는 모든 질문에 대해 동일한 규칙과 프롬프트가 적용되면서, 도메인이나 질문 유형에 따른 정확도와 유연성이 떨어졌습니다. 하지만 RAG는 유사한 질문과 데이터를 검색하여 이를 모델의 프롬프트로 추가함으로써, 사용자가 던지는 특정한 질문과 상황에 적응하도록 돕습니다. 예를 들어, 사용자가 "2022년 판매가 가장 많았던 월을 알고 싶어요"라고 질문할 때, RAG는 유사한 판매 분석 질문을 검색하여 이를 기반으로 SQL 쿼리를 생성하는 방식으로 정확도를 높일 수 있습니다.

이 접근 방식 덕분에 RAG는 모델이 few-shot 학습의 장점을 보다 효과적으로 활용하게 해줍니다. 기존 Text-to-SQL 모델에서는 질문의 맥락을 충분히 반영하지 못했던 것과 달리, RAG는 유사 질문의 사례를 활용해 질문의 의도를 더 깊이 이해할 수 있게 합니다. 이로써 특정 데이터베이스 스키마나 도메인에 특화된 질의에 대해서도 유연한 대응이 가능해졌습니다.

Text-to-SQL 2.0의 주요 기술 구성 요소

RAG 기반의 Text-to-SQL 2.0 모델은 검색 엔진과 대형 언어 모델(LLM)의 결합으로 이루어집니다. 이 과정의 주요 구성 요소는 다음과 같습니다:

1. 질문 언어 확인: 입력된 질문에 사용된 언어를 LLM을 통해 파악합니다. 벡터 스토어에서 정보를 언어에 따라 구분 지어 저장하기 때문에 질문의 언어를 확인하는 과정을 거치게 됩니다.
2. 질문 임베딩: 질문을 벡터 스토어에서 검색하기 위해 임베딩하는 과정을 거칩니다. 임베딩이 완료된 질문은 벡터 형태가 되며, 벡터 스토어에서 가장 유사한 벡터들을 검색하게 됩니다.
3. 검색 단계(Semantic Search): 입력된 질문과 유사한 질문, 테이블 구조, 메타 정보 등을 벡터 스토어에서 검색하여 관련성이 높은 정보를 찾습니다. 예를 들어, 판매 데이터를 묻는 질문이라면 과거 판매 관련 쿼리와 테이블 구조를 참조함으로써, 복잡한 데이터베이스 구조를 효율적으로 파악합니다.
4. ReRank: 테이블 구조나 메타 정보와 같은 데이터는 텍스트 형태로 프롬프트에 추가하게 될 경우, 토큰이 많아질 뿐만 아니라 ‘Lost in the Middle’ 문제를 겪을 수 있습니다. 이를 해결하기 위해 검색된 데이터를 압축시키고 재배치하는 과정이 필요합니다.
5. 프롬프트 생성: 검색된 정보(테이블 구조, 메타 정보 등)는 프롬프트에 포함되며, 검색된 비슷한 질문은 few-shot 학습을 시켜 모델이 더 정확한 SQL 쿼리를 생성할 수 있도록 도와줍니다.
6. 쿼리 검증 단계: LLM 모델을 통해 받은 쿼리가 실제로 실행이 가능한 쿼리인지 검증하는 단계입니다. 만약 실행되지 않는 경우, 틀린 쿼리와 에러 메세지를 프롬프트에 추가하여 다시 LLM으로부터 답변을 받는 과정이 진행됩니다. 이 과정은 최대 5번까지만 진행됩니다.
7. 쿼리 설명 생성: 성공적으로 실행되는 것이 확인된 쿼리는 LLM을 통해 쿼리에 대한 설명을 응답받습니다. 응답은 질문에 사용된 언어와 동일한 언어를 사용하여 제공합니다. 또한 사용자의 피드백에 따라 벡터 스토어에 저장을 하게 될지 판단하게 됩니다.

Text-to-SQL 기술은 데이터를 접근하고 활용하는 데 있어 사용자 경험을 크게 혁신할 수 있는 잠재력을 지니고 있습니다. 특히 비전문가들이 직접 데이터베이스에 접근하여 필요한 데이터를 자유롭게 조회할 수 있는 가능성은 기업 내 모든 구성원이 데이터 기반 의사 결정을 내릴 수 있는 환경을 조성하는 데 중요한 역할을 합니다.

기존 Text-to-SQL 모델이 도메인 적응성과 정확성 측면에서 한계를 겪으면서도, 최근 RAG(Retrieval-Augmented Generation) 기술이 도입됨에 따라 이러한 한계는 극복의 길을 찾았습니다. RAG를 활용한 Text-to-SQL 2.0은 검색과 생성을 통합하여, 유사한 질문을 검색하고 few-shot 형태로 학습을 적용함으로써 질의의 맥락을 더 깊이 이해하고, 정확도와 실행 결과의 일관성을 높일 수 있게 되었습니다.