AI 데이터 분석가 ‘물어보새’ 등장 – 1부. RAG와 Text-To-SQL 활용

Jul.12.2024 BADA팀(Baemin Advanced Data Analytics)

AI Data PM

AI 데이터 분석가 ‘물어보새’는 생성형 AI를 주제로 한 우아톤 2023(우아한형제들 구성원 누구나 참여할 수 있는 사내 해커톤)을 계기로 탄생한 프로덕트입니다.

당시 ‘코드 없이 데이터 추출과 시각화를 자동으로 해주는 서비스’로 1등을 차지했습니다.

우아톤 이후에도 구성원들의 요구와 관심이 지속되어 2024년 1월에 본격적인 개발을 위한 언지니어 태스크포스(TF)가 구성되었습니다. 지난 6개월 동안 TF를 통해 ‘물어보새’는 더욱 발전하여 쿼리문 생성뿐만 아니라 쿼리문 해석, 쿼리 문법 검증, 테이블 탐색 및 로그 안내 등의 다양한 기능을 갖추게 되었습니다.

지금부터 들려드릴 이야기는 지난 6개월 동안 TF 구성원들이 고군분투하며 만든, 세상에 없던 AI 서비스 ‘물어보새’의 개발기입니다.

1. 우리는 ‘왜’ 다시 뭉치게 되었을까?

1.1 문제 정의

TF 시작에 앞서 해결해야 할 문제를 재정의하고, 프로덕트 개발 방향을 명확히 설정해야 했습니다. 이를 위해 모든 구성원을 대상으로 사내 데이터 활용 현황에 대한 설문조사를 진행했습니다.

설문조사 결과, 응답자의 약 95%가 데이터를 활용하여 업무를 수행하고 있었습니다. 그러나 절반 이상의 응답자는 SQL을 업무에 활용하고 싶어도 학습 시간이 부족하거나, SQL 구문에 비즈니스 로직과 다양한 추출 조건을 반영하여 작성하는 데 어려움을 느끼고 있었습니다. 또한, 데이터를 적절히 추출했는지 신뢰도에 대한 고민도 있었습니다.

이 문제를 해결한다면 구성원이 본연의 업무에 집중할 수 있고, 데이터 기반 소통이 더 원활해질 것이라는 가능성을 확인할 수 있었습니다.

1.2 해결 방안

설문조사를 통해 도출한 구성원의 어려움을 해결하기 위해 프로덕트의 목적을 ‘구성원의 데이터 리터러시 상향 평준화’로 설정했습니다. 여기서 정의한 데이터 리터러시는 데이터를 통해 유의미한 정보를 추출하고 해석하며, 신뢰성을 검증하고, 데이터 탐색과 분석을 통해 통찰을 도출하고 합리적인 의사결정을 내릴 수 있는 소통 능력입니다. 이를 통해 구성원의 어려움을 해결하는 것뿐만 아니라 업무 생산성을 크게 향상시키고 효율성을 극대화하는 것이 프로덕트의 방향성입니다. 아래와 같이 프로덕트의 목적을 달성하기 위한 네 가지 핵심 요소를 도출했습니다.

  1. 체계화: 데이터서비스실에서 제공하는 데이터 카탈로그의 테이블 메타 정보, 데이터 거버넌스의 비즈니스 용어, 그리고 검증된 데이터 마트를 활용해 데이터 정보의 일관된 체계를 수립합니다.

  2. 효율화: 우아한형제들의 비즈니스를 이해하고, 사내 정보를 쉽고 빠르게 검색할 수 있는 기술을 개발합니다.

  3. 접근성: 누구나 쉽고 빠르게 질문할 수 있도록 웹 기반이 아닌 업무 전용 메신저 슬랙의 대화창을 이용합니다.

  4. 자동화: 데이터 담당자가 없어도 365일 24시간 언제 어디서나 이용할 수 있는 자동화된 데이터 서비스를 지향합니다.

‘데이터 리터러시 상향 평준화’라는 장기적인 목표와 네 가지 핵심 요소를 통해 구성원의 업무를 혁신할 수 있는 ‘나만의 데이터 분석가’ 물어보새 프로덕트 개발을 시작했습니다.

2. 우리는 ‘무엇을’ 만들었을까?

2.1 물어보새 기반 기술

물어보새의 기반 기술은 LLM, RAG, Langchain, LLMOps입니다.

LLM(Large Language Model)은 딥러닝 알고리즘 기반의 대규모 언어 모델입니다. 가장 유명한 모델로는 OpenAI의 GPT-4o가 있습니다. 해당 모델은 일반적인 질문에 대해 대답할 수 있지만, 특정 회사에서 통용되는 질문에 대해서는 제대로 답하지 못합니다. 그 이유는 그 회사의 데이터를 모델이 직접 학습하지 않았기 때문입니다.

이를 보완하기 위해 사내 정보를 저장하고 검색하여 활용함으로써 LLM의 답변 성능을 개선하는 기술을 RAG(Retrieval-Augmented Generation)라고 합니다. 모델이 데이터를 직접 학습하지 않고 필요한 정보를 검색하여 답변에 활용하게 됩니다. 이를 효과적으로 구현하기 위해 LLM과 애플리케이션을 개발할 수 있도록 지원하는 오픈소스 프레임워크가 Langchain입니다.

마지막으로 LLMOps(Large Language Model Operations)는 LLM의 배포, 관리, 모니터링을 위한 운영 기법과 도구들을 의미합니다. 구체적으로 모델 학습, 튜닝, 버전 관리, 성능 모니터링, 응답 속도 관리, 데이터 보안 및 비용 등 다양한 요소를 최적화합니다. 파운데이션 모델이 없어도 LLM 관련 엔지니어링 영역에 적용할 수 있습니다.

2.2 물어보새 개발 아키텍처

우아톤 2023의 개발 초기 버전은 프롬프트와 Microsoft Azure OpenAI의 GPT-3.5 API를 이용하여 간단히 구축되었습니다. 그러나 기존 방식은 ‘체계화’, ‘효율화’, ‘접근성’, ‘자동화’를 구현하기에 한계가 있어 새로운 아키텍처를 설계했습니다.

(1) 벡터 스토어 기반 비정형 데이터 파이프라인 구축

  • 사내 방대한 도메인 지식을 이해하기 위해 비즈니스 용어, 테이블 메타 정보, 데이터 추출 코드 등의 비정형 데이터를 자동으로 수집할 수 있는 파이프라인을 구축했습니다.
  • 비정형 데이터는 임베딩을 통해 벡터화하고, 벡터 유사도 검색을 활용할 수 있도록 VectorDB에 저장했습니다.
  • 효율적인 데이터 업데이트를 위해 데이터 영역별 임베딩 인덱스를 적용했습니다.

(2) 다양한 리터러시 기능 제공을 위한 RAG 기반의 멀티 체인 구조 개발

  • 사용자가 질문을 하면 실시간으로 Router Supervisor 체인이 질문 의도를 파악하여 적합한 질문 유형으로 분류합니다.
  • 이후 사용자 질문에 답변을 해줄 수 있는 멀티 체인(예: 쿼리문 생성, 쿼리문 해설, 쿼리 문법 검증, 테이블 해설, 로그 데이터 활용 안내 기능, 칼럼 및 테이블 활용 안내 기능 등)으로 매핑되어 최선의 답변을 생성합니다.
  • 멀티 체인 실행 시, 체인별 서치 알고리즘을 활용하여 retriever가 필요한 데이터를 선별적으로 추출합니다.

(3) LLM 서비스 개발, 배포, 운영을 위한 LLMOps 구축

  • A/B 테스트를 수행할 수 있는 실험 환경을 구축하고, 리더보드를 통해 성능이 가장 우수한 체인을 배포합니다.
  • 응답 안정성, 속도, 오류 대응을 위해 API 로드 밸런싱, GPT 캐시, 피드백 루프, 운영 모니터링 대시보드 등 서비스 운영 품질을 개선하기 위한 기능과 환경을 구축했습니다.
  • CI/CD를 통해 서비스 배포는 자동으로 진행됩니다.

(4) Slack 기반의 다양한 응답 기능 도입

  • 구성원은 간편하게 Slack 앱을 통해 언제든지 궁금한 내용을 질문하고 답변을 받을 수 있습니다.
  • 답변의 만족도를 긍정과 부정으로 평가할 수 있으며, 해당 결과가 GPT 캐시에 반영되어 다른 사용자에게도 표준화된 데이터 지식이 확산됩니다.
  • 쿼리문 생성 기능의 경우 쿼리 검증을 통해 해당 쿼리문이 잘 실행되는지, 오류가 있는지 판단하여 부가적인 설명을 제공합니다.

위의 기술들이 유기적으로 연결되어 물어보새는 양질의 답변을 안정적으로 제공하고 있습니다.


그림1. 물어보새 아키텍처

2.3 물어보새 캐릭터 디자인

기술적인 부분 외에도, 구성원이 적절한 답을 찾아가는 과정에서 로봇과 대화하는 것처럼 거부감을 느끼지 않고 친숙함을 느끼게 하는 요소가 중요하다고 판단했습니다. 또한, 적절한 답변을 받지 못했을 때 부정적인 의견을 주기보다 함께 문제를 해결하는 동료와 같은 이미지를 주기 위해 캐릭터를 제작하게 되었습니다.

캐릭터 제작에 진심인 디자인실의 도움을 받아 우아한형제들 AI 데이터 분석가 ‘물어보새’가 탄생했습니다. 물어보새는 넓디넓은 우아한 데이터 바다에서 무엇이든 물어보면 가져다주는 친구입니다. 펠리컨과 폴더가 결합한 귀여운 너드 이미지를 갖추고 있으며, 겉모습은 귀엽지만 내부는 복잡한 시스템 구조로 이루어져 있습니다.


그림2. 물어보새 캐릭터 디자인

3. 우리는 ‘어떻게’ 일을 했는가?

TF는 특정 기간 안에 제한된 리소스로 목표를 달성해야 하므로 짧은 호흡으로 작업을 진행했습니다. 개발 로드맵을 세 단계로 구분했고, 각 단계 안에서는 2주 단위로 스프린트를 진행했습니다.

LLM 기반의 프로덕트를 개발하는 것은 TF 구성원 모두에게 처음이라 각자의 강점이나 흥미를 명확히 알기 어려웠습니다. 이를 해결하기 위해 업무를 컴포넌트 형태로 분리하고, 스프린트마다 업무를 순환하는 방법을 도입했습니다. 업무 선택은 각 구성원이 하고 싶은 업무를 자율적으로 결정하도록 했습니다.

이 방법은 초기에 중복되는 업무도 있어 진척이 더딜 수 있지만, 스프린트가 반복될수록 업무의 진행 속도가 점차 빨라집니다. 그 이유는 업무를 순환하면서 각자 몰입할 수 있는 흥미 영역이 자연스럽게 형성되고, 각자의 강점을 살릴 수 있는 업무가 메인 업무가 되기 때문입니다.

이로 인해 피로도가 높은 TF 업무 수행에도 불구하고 팀원들은 흥미를 잃지 않고 지속적으로 높은 성과를 낼 수 있었습니다. 또한, 순환 업무를 경험함으로써 구성원은 폭넓은 기술 셋을 갖추게 되었고, 서로의 업무에 대한 이해도가 올라가면서 자연스럽게 팀워크가 강화되었습니다.

이어서 본격적으로 물어보새의 개발 상세 히스토리에 대해 말씀드리겠습니다.

4. Text-to-SQL을 ‘어떻게’ 구현했을까?

처음 두 달 동안 집중한 키워드는 ‘Text-to-SQL(Structured Query Language)’입니다. Text-to-SQL은 물어보새의 핵심 기능 요소 중 하나로, 자연어를 SQL로 변환하는 기술입니다. SQL은 기업에서 데이터 기반의 의사결정을 위해 필수적이며, 사용자가 데이터를 자유자재로 다루고 싶다면 반드시 배워야 할 핵심적인 역량입니다.

기본적으로 GPT-4와 같은 LLM 모델들은 상당히 높은 수준의 SQL 쿼리문을 작성할 수 있습니다. 그렇다면 GPT-4만을 활용해서 사내의 다양한 지식을 반영한 Text-to-SQL 기술을 구현할 수 있을까요?

정답은 어렵습니다. GPT-4만 활용해서 쿼리문을 생성할 수 있지만, 실제 업무에 활용되기에는 품질이 떨어집니다. 이는 사내 도메인과 데이터 정책에 대한 이해도가 부족하고, 기본적으로 제공되는 retriever의 성능이 떨어져 불필요한 데이터가 포함되기 때문입니다. 또한, LLM의 고질적인 문제인 허위 생성(=Hallucination)으로 인해 쿼리문 생성의 품질이 들쭉날쭉합니다. 결과적으로 그럴싸한 쿼리문 형태로 보이지만, 실제로는 활용할 수 없는 결과입니다. 이는 파운데이션 모델의 성능이 향상됨에 따라 답변 품질이 일정 수준 올라갈 수 있지만, 결국 한계에 도달할 수 있음을 보여줍니다.

그렇다면 이를 어떻게 해결할 수 있을까요? 물어보새는 LangChain에서 제공하는 DocumentLoader, Vectorstore, RAG QA 등을 활용하여 도메인 지식을 기반으로 LLM 답변을 생성하는 기능을 만들었습니다. 그리고 다음과 같은 네 가지 요소인 ‘데이터 보강’, ‘검색 알고리즘 개발’, ‘프롬프트 엔지니어링’, ‘실험 및 평가 시스템 구축’에 집중하여 새로운 구조를 개발했습니다.

4.1 물어보새 Text-to-SQL

물어보새 Text-to-SQL chain 영역에 대해 알아보도록 하겠습니다.


그림3. 물어보새 Text-to-SQL Chain

(1) 데이터 보강

"Garbage in Garbage Out"이라는 표현을 많이 들어보셨겠지만, 이는 LLM에도 여전히 통용되는 문장입니다. GPT 기반의 Text-to-SQL 성능을 향상시키려면 어떤 문서를 수집하는지가 가장 중요합니다. 2023년 NeurIPS 학회에서 발표된 Data Ambiguity Strikes Back: How Documentation Improves GPT’s Text-to-SQL 논문에 따르면, 데이터 모호성 문제 개선의 중요성과 방법을 다루고 있습니다.

이를 기반으로 테이블 메타 데이터를 풍부하게 할 방법들을 고안하였고, 기존보다 고도화된 메타 데이터 생성 작업을 진행했습니다. 기존에도 잘 되어 있었지만, 테이블의 목적과 특성, 칼럼의 상세 설명, 주요 값 및 키워드 등 기존에 기록되지 않았던 상세한 내용을 추가했습니다. 뿐만 아니라 주로 사용되는 서비스와 그에 따른 질문들을 정리했습니다. 테이블 메타 데이터를 기반으로 테이블 DDL 데이터를 생성할 때 기존보다 훨씬 풍부한 DDL을 만들 수 있었습니다. 테이블 DDL 데이터 수집 작업은 사내 데이터 카탈로그 시스템이 잘 구축되어 있어, 손쉽게 정보를 추가하고 API를 통해 자동으로 최신 데이터를 수집할 수 있었습니다.

사용자의 질문에는 사내 구성원만 이해할 수 있는 다양한 비즈니스 용어들이 사용됩니다. 해당 용어는 서비스 또는 조직별로 다를 수 있어, 커뮤니케이션 혼동이 없도록 표준화와 관리가 필수적입니다. 우아한형제들에는 데이터 거버넌스를 관리하는 조직이 있어 데이터와 비즈니스 용어를 잘 관리하고 있었습니다. 따라서 기존에 구축되어 있던 비즈니스 표준 용어 사전을 활용하여 Text-to-SQL 전용 비즈니스 용어집을 구축했습니다.

마지막으로, few-shot SQL 예제 데이터 구축입니다. Few-shot이란 프롬프트에 몇 가지 예시 답변을 입력하는 기법입니다. 이는 모델이 답변에 필요한 여러 정보를 학습하여 사용자의 질문에 대해 더 정확하고 관련성 높은 답변을 생성하도록 도울 수 있습니다. 도메인 지식을 쿼리문에 반영하는 데 있어 중요한 부분으로, 예시 쿼리문의 품질이 높을수록 답변 성능에 긍정적인 영향을 미칩니다. 따라서 데이터 분석가가 기존에 생성해놓은 높은 품질의 쿼리문과 주요한 비즈니스 질문에 대한 쿼리문을 추가로 작성하여 예제 데이터를 수집했습니다. 그리고 각 쿼리문에 해당하는 질문을 작성하여 쿼리문-질문 데이터셋을 구축했습니다. Few-shot SQL 예제 데이터의 경우 늘 새롭게 변경되는 데이터 추출 기준과 급변하는 비즈니스 상황에 대응할 수 있어야 하므로 각 도메인 지식에 특화된 데이터 분석가가 관리해야 합니다. 향후 해당 부분은 도메인 데이터 분석가와 원활하게 의사소통을 하고 데이터를 관리할 수 있도록 협업 체계를 구축할 계획입니다.

위의 데이터는 비정형 데이터 수집 파이프라인을 통해 매일 수집됩니다. 따라서 시시각각 변화하는 최신 데이터 정책을 자동으로 수집하여 빠르게 확인하고 서비스에 반영할 수 있습니다. 그뿐만 아니라, 데이터의 양이 점점 증가함에 따라 데이터 업데이트 속도를 향상시키기 위해 VectorDB에 인덱싱을 적용하여 변경이 발생한 부분만 업데이트하는 환경을 구축했습니다.

(2) 검색 알고리즘 개발

프롬프트 활용 시, 사용자 질문과 단계마다 적합한 검색 알고리즘을 활용해 데이터를 입력시키는 것이 중요합니다. 사용자 질문이 모호하거나 짧고 명확하지 않은 경우, 질문을 구체화하는 것은 이를 해결할 수 있는 중요한 방법입니다.

질문을 구체적으로 만들 때는 반드시 비즈니스 용어를 먼저 이해해야 하므로 질문의 의도와 관련이 있는 적절한 용어를 추출해야 합니다. 이 단계에서는 비슷하지만 의도와 관련이 없는 용어를 추출하면 LLM이 오히려 잘못된 질문을 만들어낼 수 있기 때문에 의도를 정확히 파악할 수 있는 정교한 검색 알고리즘이 필요합니다.

구체화된 질문을 기반으로 쿼리 작성에 필요한 정보를 추출하는 단계에서는 테이블 및 칼럼 메타 정보, 테이블 DDL, few-shot SQL 등 다양한 정보를 활용합니다. 이 단계에서는 수많은 정보 중 사용자 질문에 대답하기 가장 적합한 정보를 추출하는 것이 중요합니다. 다시 말해, 사용자 질문의 문맥을 파악하여 가장 유사도가 높은 정보를 추출하거나, 특정한 단어가 포함된 정보를 선별하는 등 다양한 검색 알고리즘을 활용하여 조합해야 합니다.

마찬가지로 few-shot SQL 예시도 질문과 가장 유사한 예시를 선별해야 하며, 유사한 예시가 없으면 새롭게 추가해야 합니다. 각 단계별로 합쳐진 입력값을 GPT에 입력하면 허위 생성이 줄어든 고품질의 쿼리문 답변을 생성할 수 있습니다.

(3) 프롬프트 엔지니어링

프롬프트는 질문 구체화 프롬프트와 쿼리 생성 프롬프트로 나뉘지만, 공통적으로 활용하는 요소가 있습니다.

먼저, 두 프롬프트 모두 데이터 분석가의 페르소나를 부여받습니다. 설정된 페르소나에 따라 결과물의 품질이 달라질 수 있으므로 원하는 역할과 기대하는 결과물에 대해 충분한 논의가 필요합니다.

다음으로 프롬프트 구조 설계에 대해 설명하겠습니다. 프롬프트 구조 설계에는 다양한 방법이 존재합니다. 그중 ICLR 2023 학회에서 발표된 ReAct: Synergizing Reasoning and Acting in Language Models 논문에 따르면, LLM 기반 ReAct 방법은 다양한 벤치마크에서 모방 학습과 강화 학습에 비해 더 높은 답변 성능을 보여준다고 발표했습니다. ReAct 방법은 문제 해결 과정을 위한 순차적 추론 단계(chain-of-thought, COT)와 특정 작업 수행을 위한 도구 또는 행동으로 나뉩니다. 이 두 가지 요소를 함께 활용하면 시너지가 발생하여 단일 방법만을 사용한 답변보다 더 정확한 답변이 나오게 됩니다.

물어보새는 ReAct 방법의 아이디어를 응용하여 쿼리 생성 프롬프트를 개발했습니다. 이 프롬프트는 사용자 질문에 적합한 쿼리문을 생성하기 위해 단계별 추론 과정(COT)을 거칩니다. 또한, 사용자 질문에 적합한 데이터를 동적으로 검색하여 선별합니다. 이처럼 추론 과정과 검색 과정이 결합되면서 답변이 점점 정교해집니다. 이는 단순 추론 기법만을 사용할 때보다 훨씬 더 정확한 답변을 제공할 수 있었습니다.

그 외에도 다양한 프롬프트 엔지니어링 방법이 적용되고 있으며, 지속적인 실험을 통해 점진적으로 Text-to-SQL 성능을 향상시키고 있습니다.

(4) 실험 및 평가 시스템 구축

Text-to-SQL 성능을 평가하고 경쟁하기 위해 전 세계 사람들이 참여하는 다양한 리더보드가 있습니다. 가장 유명한 리더보드는 YALE SpiderAlibaba BIRD입니다. 또한, LLM과 RAG 애플리케이션의 지속적인 개선을 위해 지표 기반의 개발을 추구하는 RAGAS 스코어도 있습니다.

위의 평가 방법과 지표들의 공통점은 Text-to-SQL의 성능을 평가 데이터와 평가 지표를 통해 판단하고, 현황을 파악하여 개선할 수 있다는 점입니다.

그러나 공개된 지표와 리더보드를 사용하여 사내의 다양한 비즈니스 문제를 해결하기에는 한계가 있습니다. 구체적으로, 일반적인 문제가 아닌 도메인에 특화된 문제를 해결해야 하고, 비즈니스 상황에 따라 중요하게 판단되는 주요 지표를 새롭게 업데이트하기 어렵기 때문입니다. 이를 해결하기 위해 리더보드와 지표를 벤치마킹하여 사내 Text-to-SQL 성능 측정의 기반이 되는 평가 지표와 평가 데이터를 직접 개발하였습니다.

개발된 평가 지표와 평가 데이터를 활용하여 Text-to-SQL 기능의 성능을 향상시키기 위해 단계별로 테스트를 진행했습니다. 테스트 단계는 쿼리 문법 이해도를 평가하는 단계부터 복잡한 도메인 지식이 반영된 쿼리의 실행 결과 정확도를 평가하는 단계까지 나뉩니다. 현재는 복잡한 도메인 지식을 이해하고 쿼리 실행 결과의 정확도를 평가하는 테스트를 진행 중이며, 사용자들의 질문도 추가하여 개선 작업을 진행하고 있습니다.


그림4. 물어보새 Text-to-SQL 성능 평가 결과

위와 같은 실험이 가능한 이유는 자동화된 실험 및 평가 시스템을 구축하여 누구나 손쉽게 성능을 평가할 수 있는 기반을 마련했기 때문입니다. 이를 통해 누구나 일관된 평가 데이터, 프롬프트, Retriever, 체인 등 다양한 요소를 선택하여 실험할 수 있으며, 수십 개의 지표를 개발하여 세부적인 요소를 모두 측정할 수 있게 되었습니다.

자체적으로 사내 리더보드를 구축하고 각자의 아이디어를 실현하기 위해 500번 이상의 A/B 테스트를 수행하였습니다. 특히, 개개인이 만든 결과가 순위로 측정되면서 게임 요소로 작용하여 재미있게 참여할 수 있었습니다. 가장 높은 성능을 가져온 결과는 주 단위 싱크 업을 통해 승인되면 운영에 배포하여 서비스 성능을 점진적으로 고도화할 수 있었습니다.

위의 요소 외에도 Langserve Playground를 활용하면 변경된 프롬프트나 체인의 성능 변화를 빠르게 확인할 수 있습니다.

4.2 물어보새 쿼리문 생성 및 해설 기능

앞서 말씀드린 물어보새의 기본 아키텍처와 Text-to-SQL 기능 구현을 통해 쿼리문 생성 및 해설 기능을 두 달 만에 개발할 수 있었습니다. 이 기능은 30초에서 1분 이내에 사용자에게 답변을 제공하며, 업무에 참조할 수 있는 수준의 쿼리문을 제공합니다.


그림5. 물어보새 쿼리문 생성 및 해설 기능 예시

회사에 처음 입사했거나 다른 서비스 도메인 업무를 맡은 구성원은 물어보새의 쿼리문 생성 및 해설 기능이 업무 이해도를 높이는 데 큰 도움이 된다고 평가합니다. 그러나 일부 구성원들은 비즈니스 로직의 정확성과 질문 이해도의 개선이 필요하다고 의견을 주었습니다. 보다 정확한 정보 전달을 위해 다양한 의견과 질문 이력을 참고하여 여러 가지 방법과 실험을 통해 성능 개선 작업을 진행하고 있습니다.

5. 물어보새 1부를 마치며

점진적으로 테스트 참가자와 대상 조직을 늘려나가면서, 쿼리문 생성 답변뿐만 아니라 데이터 디스커버리 영역에 대한 질문 비중이 상당히 높다는 것을 알게 되었습니다.

데이터 디스커버리는 테이블 칼럼, 테이블 구조, 테이블 유형 등을 탐색하고 이해하여 유의미한 인사이트를 도출하고, 이를 비즈니스 인텔리전스(BI) 리포트로 작성하는 과정을 의미합니다. 이를 위해서는 쿼리문 작성뿐만 아니라 다양한 데이터 질문에 대해 답변할 수 있어야 하기 때문에, Text-to-SQL을 넘어서서 ‘데이터 디스커버리(Data Discovery)’ 영역으로 물어보새의 기능을 확장을 하게 되었습니다.

1부에서는 프로덕트 소개와 Text-to-SQL 기능 구현에 대해 설명했지만, 2부에서는 데이터 디스커버리 기능들과 향후 계획에 대해 상세히 이야기해 보겠습니다.