블로그
VectorDB로 에이전트형 SQL 생성에서 고카디널리티 범주형 데이터 다루기

VectorDB로 에이전트형 SQL 생성에서 고카디널리티 범주형 데이터 다루기

Sep 17, 20248 min read

에이전틱 워크플로와 대규모 언어 모델(LLMs)은 텍스트-to-SQL 시스템에 접근하는 방식을 근본적으로 바꾸었으며, 사용자가 이전과는 전혀 다른 방식으로 자연어를 사용해 데이터베이스를 쿼리할 수 있게 합니다. 이러한 시스템이 발전함에 따라, 인간의 의도를 정확한 SQL 쿼리로 변환하는 과정에서 다양한 새로운 과제에 직면하게 됩니다.

한 가지 중요한 문제는 고카디널리티 범주형 데이터를 처리하는 것입니다. 이 글에서는 벡터 데이터베이스를 에이전틱 텍스트-to-SQL 시스템과 통합함으로써 이 과제를 어떻게 해결할 수 있는지 살펴봅니다. 구체적으로, Waii와 Zilliz Cloud(완전 관리형 Milvus 벡터 데이터베이스)의 조합이 이 문제를 어떻게 자동으로 처리하는지 보여드리겠습니다.

고카디널리티 범주형 데이터의 과제

범주형 데이터는 데이터베이스에서 어디에나 존재합니다 - 제품 카테고리, 고객 세그먼트, 거래 유형을 생각해 보세요. 많은 경우, 이러한 범주의 고유 값 수(카디널리티)는 관리 가능한 수준입니다. 예를 들어, 미국 주를 나타내는 열에는 최대 50개의 고유 값(및 준주)이 있습니다. 이러한 저카디널리티 열은 자연어 쿼리와 데이터베이스 값 사이의 간극이 작기 때문에 텍스트-to-SQL 시스템이 비교적 쉽게 처리할 수 있습니다.

고카디널리티 범주형 데이터를 접할 때 문제가 발생합니다. 우리가 작업해 온 데이터베이스의 60% 이상에서 이러한 상황의 예가 있었습니다: 수백만 개의 고유한 제품 ID가 있는 제품 카탈로그나 수십만 개의 회사 식별자가 있는 금융 데이터베이스를 상상해 보세요.

데이터베이스는 이러한 범주에 대해 정확하고 엄격한 조회를 요구하지만, 자연어 쿼리는 종종 유동적이고 부정확합니다. 사용자는 "인기 있는 스마트폰"이나 "최근 실적이 좋았던 기술 기업"을 요청할 수 있지만, 이러한 모호한 용어를 특정 데이터베이스 값으로 변환하는 지점에서 기존 텍스트-to-SQL 접근 방식은 한계를 보이며, 풍부한 데이터를 접근할 수 없는 상태로 남겨 둡니다.

기존 방법이 작동하지 않는 이유

텍스트-to-SQL 시스템은 고카디널리티 범주형 데이터가 포함된 자연어 쿼리를 변환할 때 흔히 다음 두 가지 방법 중 하나를 사용합니다:

전처리된 데이터베이스 기법: 이 접근 방식은 입력 전처리와 결합된 텍스트 검색 및 정규 표현식 같은 전통적인 데이터베이스 기능에 의존합니다. 단순한 매치는 처리할 수 있지만, 특히 복잡하거나 미묘한 쿼리의 경우 사용자의 의도를 정확히 표현하기에는 너무 융통성이 없는 경우가 많습니다. 이러한 기법의 경직된 특성은 자연어의 변동성과 정확한 데이터베이스 값 사이의 간극을 메우는 데 어려움을 겪습니다.
LLM 기반 변환: 이 방법에서는 시스템이 훈련 데이터나 few-shot 예제를 기반으로 올바른 범주형 값을 예측하기 위해 LLM을 사용합니다. LLM은 맥락과 자연어를 이해하는 데 뛰어나지만, 고카디널리티 데이터를 다룰 때는 종종 부정확한 결과를 만들어냅니다. 이는 LLM이 전체(그리고 종종 비공개인) 데이터셋에 대한 지식이 부족하며, 훈련 데이터의 일부가 아니었던 수백만 개의 고유 식별자를 정확히 기억해 내는 데 어려움을 겪기 때문입니다.

고카디널리티 데이터의 경우, 두 방법 모두 한계가 있습니다. 전처리된 데이터베이스 기법은 자연어 쿼리의 뉘앙스를 효과적으로 처리하기에는 너무 융통성이 없고 문자 그대로입니다. 반면 LLM은 쿼리 의도를 이해할 수는 있지만, 훈련되지 않은 크고 특정한 데이터셋에서 올바른 값에 안정적으로 매핑할 수 없습니다. 이로 인해 고카디널리티 범주형 데이터에 대해 자연어 쿼리를 정확한 SQL로 변환하는 데 상당한 간극이 남게 됩니다.

벡터 데이터베이스의 등장

여기서 벡터 데이터베이스가 중요한 역할을 합니다. 최신 정보 검색은 키워드 매칭이 아니라 벡터 임베딩을 사용하여 시맨틱 검색을 수행합니다. 벡터 데이터베이스는 데이터의 고차원 벡터 표현을 저장하고 효율적으로 쿼리하도록 설계되었습니다. 우리의 맥락에서는 이를 활용하여 자연어 쿼리와 고카디널리티 범주형 데이터를 연결할 수 있습니다.

작동 방식은 다음과 같습니다:

벡터 임베딩 생성: 고카디널리티 열의 각 고유 값에 대해 벡터 임베딩을 생성합니다. 이 임베딩은 값을 고차원 공간의 벡터로 매핑하여 해당 값의 의미론적 의미를 포착합니다.
VectorDB에 인덱싱: 이러한 임베딩을 Milvus와 같은 벡터 데이터베이스에 저장합니다. Milvus는 고차원 공간에서 빠른 유사도 검색에 최적화되어 있습니다.
쿼리 처리: 사용자가 자연어 쿼리를 제출하면 LLM을 사용하여 의도를 이해하고 예비 SQL 쿼리를 생성합니다. 고카디널리티 열의 경우, LLM은 특정 값을 생성하려고 하기보다 원하는 값의 설명이나 특성을 생성합니다.
벡터 검색: 이 설명의 임베딩을 사용하여 벡터 데이터베이스에 있는 방대한 수의 고유 값 임베딩에 대해 유사도 검색을 수행하고, 가장 관련성 높은 범주형 값을 검색합니다.
정제: 그런 다음 LLM은 사용자의 쿼리 전체 맥락을 기반으로 관련 없는 매치를 걸러내며 이러한 결과를 정제할 수 있습니다.
SQL 생성: 정제된 범주형 값 목록을 사용하여 적절한 필터와 집계를 구성함으로써 최종 SQL 쿼리를 생성합니다.

Text-to-SQL에서 벡터 검색을 사용할 때의 이점

이 vectorDB 강화 접근 방식은 여러 가지 이점을 제공합니다:

확장성: 성능 저하를 크게 일으키지 않고 수백만 개의 고유 값을 가진 범주를 처리할 수 있습니다.
정확성: LLM의 의미론적 이해와 벡터 데이터베이스의 정밀한 재현율을 결합함으로써 사용자 의도를 특정 데이터베이스 값으로 더 정확하게 변환할 수 있습니다.
유연성: 이 방법은 전체 시스템을 재학습하지 않고도 데이터베이스의 변화에 적응할 수 있습니다.

구현 고려사항

설명된 접근 방식을 구현하는 데 필요한 흐름을 처음부터 구축하는 것은 당연히 가능하지만, 우리는 Waii 와 Zilliz Cloud를 결합하는 것이 상당한 이점을 제공한다고 믿습니다.

Waii는 에이전트형 워크플로를 기반으로 구축된 세계 최초의 text-to-SQL API입니다. 가장 정확한 쿼리 생성을 위해 컴파일러 기술과 자동 생성된 지식 그래프를 결합합니다.

Waii의 기능을 보완하는 Zilliz Cloud는 AI 워크플로를 뒷받침하는 벡터 데이터베이스입니다. 낮은 지연 시간으로 확장하고 정확한 결과를 제공하는 능력은 AI 스택에서 자연스러운 선택이 되게 합니다.

이 조합은 즉시 사용할 수 있는 확장 가능한 솔루션을 제공합니다:

지능형 Text-to-SQL을 위한 Waii

자동 감지: Waii는 이러한 고카디널리티 열을 자동으로 식별하여 수동 구성의 필요성을 없앱니다.
스마트 임베딩 생성: 다양한 유형의 열에 대한 임베딩을 구축하고 업데이트하기 위해 맞춤형 워크플로를 사용하며, 정확성과 리소스 효율성을 모두 최적화합니다.
적응형 기법: Waii는 다양한 열 유형에 적합한 기법을 자동으로 선택하여 사용자가 깊은 전문 지식을 갖추지 않아도 최적의 성능을 보장합니다.

벡터 시맨틱 검색을 위한 Zilliz Cloud

확장성: Zilliz Cloud는 수십억 개의 벡터를 손쉽게 처리할 수 있어 고카디널리티 데이터 시나리오에 이상적입니다.
초고속 쿼리: 최적화된 인덱싱을 통해 빠른 유사도 검색을 보장하며, 이는 프로덕션 환경에서 낮은 지연 시간을 유지하는 데 매우 중요합니다.
보안 및 액세스 제어: Zilliz Cloud는 안전한 네트워킹 옵션과 암호화 프로토콜을 통해 엔터프라이즈급 데이터 보안 및 개인정보 보호 규정 준수를 제공합니다. 이를 통해 전송 중과 저장 중 모두에서 데이터 안전성을 보장합니다. 또한 Zilliz Cloud는 Role-Based Access Control(RBAC) 및 안전한 중앙 집중식 Single Sign-On(SSO) 기능을 위한 OAuth 2.0을 포함하여 정교한 ID 제어 및 액세스 관리를 제공합니다.

Waii와 Zilliz Cloud의 통합

원활한 워크플로: Waii의 자동 전처리와 Zilliz의 강력한 벡터 저장소를 결합하면 text-to-SQL 시스템에서 고카디널리티 데이터를 처리하기 위한 매끄러운 엔드투엔드 솔루션이 만들어집니다.
프로덕션 준비 완료: 이 조합은 실제 대규모 과제에 맞게 설계되어, 다양한 산업 전반의 프로덕션 배포에 적합합니다.

Waii의 자동 감지 및 임베딩 생성 기능을 Zilliz와 함께 활용하면, 메타데이터 관리나 임베딩 생성을 위한 사용자 지정 코드 없이도 text-to-SQL 시스템에서 고카디널리티 범주형 데이터를 처리하기 위한 견고한 솔루션을 구현할 수 있습니다.

실제 예시

수백만 개의 이벤트가 있는 글로벌 이벤트 관리 플랫폼을 생각해 보겠습니다. 데이터베이스 스키마에는 다음이 포함됩니다:

CREATE TABLE events (
    event_id INT PRIMARY KEY,
    event_name VARCHAR(255),
    event_date DATE,
    category VARCHAR(100),
    total_spent DECIMAL(10, 2)
);

event_name은 "Global AI Ethics Summit 2024", "Sustainable Living Expo: Greening Our Future", 또는 "5th Annual Quantum Computing Breakthrough Conference"와 같은 수백만 개의 고유하고 설명적인 이름을 가진 고카디널리티 범주형 열입니다.

분석가는 이렇게 물을 수 있습니다: "지난달 AI 이벤트에 얼마나 많은 돈이 지출되었나요?"

다양한 접근 방식이 이를 어떻게 처리할 수 있는지 살펴보겠습니다:

기존 키워드 매칭

이 접근 방식에서는 사용자가 제공한 용어를 사용하여 검색어로 쿼리에 삽입합니다. 여기서는 대소문자를 구분하지 않는 전체 텍스트 검색을 사용하지만, 이 시나리오에서는 동등성 필터를 생성하는 것도 일반적입니다.

SELECT SUM(total_spent) 
FROM events 
WHERE event_name ILIKE '%AI%' 
  AND event_date >= 
 DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND event_date < 
 DATE_TRUNC('month', CURRENT_DATE);

문제: 이 접근 방식은 "Machine Learning Symposium"이나 "Neural Network Workshop"처럼 AI와 관련되어 있지만 이름에 "AI"가 포함되지 않은 이벤트를 놓칩니다. 또한 "HAIR styling convention"과 같은 이벤트를 잘못 포함할 수도 있습니다.

순진한 LLM 접근 방식

이 접근 방식에서는 LLM이 검색과 관련이 있을 수 있는 여러 용어를 생성하고, 이를 바탕으로 필터를 구성합니다. 이는 선택적으로 해당 열의 샘플 값과 데이터베이스에 대한 추가 컨텍스트를 사용하여 수행할 수 있습니다. 일반적으로 다음과 같은 결과를 생성합니다:

SELECT SUM(total_spent) 
FROM events 
WHERE (event_name ILIKE '%AI%' 
       OR event_name ILIKE '%Artificial Intelligence%' 
       OR event_name ILIKE '%Machine Learning%' 
       OR event_name ILIKE '%Neural Network%')
  AND event_date >= 
DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND event_date < 
DATE_TRUNC('month', CURRENT_DATE);

문제: 이는 더 많은 AI 관련 이벤트를 포착하지만, 여전히 사전 정의된 용어 목록으로 제한되며 더 구체적이거나 새로운 AI 관련 이름을 가진 이벤트를 놓칠 수 있습니다. 관련 없는 이벤트를 찾는 문제도 여전히 존재합니다.

Vector DB + LLM 접근 방식

다음 다이어그램은 전체 흐름을 보여줍니다. 왼쪽은 events 테이블에 대해 수행되는 전처리이고, 오른쪽은 쿼리 생성 흐름을 보여줍니다.

그림- Zilliz Cloud와 Waii의 통합이 작동하는 방식

쿼리 생성 흐름은 다음과 같습니다.

Waii는 쿼리를 해석하고 설명을 다시 작성합니다: "인공지능, 머신러닝, 신경망 및 기타 AI 기술과 관련된 이벤트."
이 설명은 Zilliz Cloud를 쿼리하는 데 사용되며, 의미적 유사성을 기반으로 관련 이벤트 ID 목록을 반환합니다.
Waii는 이 목록을 정제하여 실수로 포함되었을 수 있는 비-AI 이벤트를 필터링합니다.
Waii는 에이전트형 워크플로를 사용하여 이러한 이벤트 ID를 최종 SQL 쿼리에 통합합니다.

SELECT SUM(total_spent) 
FROM events 
WHERE event_id IN (1234, 5678, 9101, 1121, 3141, 5161, 7181, 9202, 1222, 3242) 
AND event_date >= 
DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month') 
AND event_date < 
DATE_TRUNC('month', CURRENT_DATE);

이 접근 방식은 전문 용어를 사용하거나 명확한 키워드를 포함하지 않더라도 AI 관련 이벤트를 정확하게 식별할 수 있습니다. 이는 다른 접근 방식이 놓칠 수 있는 "생성적 적대 신경망에 관한 제3회 심포지엄" 또는 "강화 학습의 윤리적 고려사항에 관한 워크숍"과 같은 이벤트를 포착할 수 있습니다.

벡터 유사도 검색을 활용함으로써, 사용자의 의도를 더 정확하게 해석하고 이를 데이터베이스의 고카디널리티 이벤트 이름과 매칭하여 더 포괄적이고 정확한 결과를 제공할 수 있습니다.

결론

데이터 양이 계속 증가하고 직관적인 데이터 상호작용에 대한 사용자 기대치가 높아짐에 따라, 텍스트-to-SQL 시스템에서 고카디널리티 범주형 데이터를 처리하는 일은 더욱 일반화될 것입니다. Zilliz Cloud의 강력한 기능을 Waii와 함께 활용함으로써, 우리는 더 견고하고 확장 가능하며 정확한 시스템을 만들 수 있습니다.

우리는 이 접근 방식에서 유망한 결과를 확인했으며, 유사한 과제에 직면한 다른 사람들에게도 유익하다고 믿습니다. 이와 같거나 유사한 접근 방식을 시도해 보셨다면 언제든지 연락하여 여러분의 인사이트를 공유해 주시기 바랍니다.

Jul 13, 2026에 업데이트됨

계속 읽기

What Is a Vector Lakebase?

A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.

My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.

Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.

Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search

Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.