DEVOCEAN

안녕하세요! 저희는 'AI Chatbot for Data Analytics Text2SQL' 주제를 연구한 skql팀 입니다.

이번 포스트에서는 10월 31일 진행되었던 최종발표에서 발표한 저희 주제 및 내용을 공유드리겠습니다.

1. Background

연구배경

SQL은 데이터베이스에서 자료를 처리하는 용도로 사용되는 구조적 데이터 질의 언어이며, SQL을 통해 사용자들은 데이터베이스에서 쉽게 자료를 찾거나 저장할 수 있습니다.

데이터 분석을 통해 인사이트를 발견하는 것부터, 파이프라인 개발이나 프로그래밍에 활용하는 등 다양한 곳에 데이터가 사용되면서 SQL의 중요성이 증가하는 추세입니다.

IDCube (ICT Infra의 data warehouse 및 분석 환경 서비스)를 사용하는 유저들 중 SQL에 익숙지 않은 분석가들을 위해, 

자연어로부터 SQL문을 생성하는 한글 LLM/RAG chatbot을 개발하고자합니다.

Text2SQL 적용에 따른 기대효과

[기존 어려움]

• 컬럼명이 직관적이지 않을 경우 docs에서 description을 통해 필요한 컬럼을 찾아야 하므로 시간이 많이 소요됩니다.

• sql문 작성이 능숙하지 않은 분석가는 쿼리문 구성에 있어 어려움을 느낍니다.

• 데이터 보안 문제로 인해 컬럼 정보를 chatGPT, claude 와 같은 웹 서비스에 직접 전달하는 것 또한 불가능하므로 어려움을 해결하기가 쉽지 않습니다.

[기대효과]

• 이를 해결하기 위해, 기본적으로 데이터 보안 문제를 해결하는 동시에 LLM으로 자연어→SQL 생성의 자동화가 필요합니다.

• 유저가 chatGPT, claude와 같은 웹 서비스에 컬럼 정보를 전달하는 것이 아닌, claude-opus-skt/gpt-4o-skt와 같은 데이터 보안 계약이 완료된 api,

  또는 오픈 소스 sLLM을 파인튜닝한 모델에 프롬프트 엔지니어링 및 RAG DB를 활용해야합니다.

  
  

RAG(검색 증강 생성)이란?

• R에 해당하는 Retrieval:사용자의 질문이나 컨텍스트를 입력으로 받아서, 이와 관련된 외부 데이터를 검색하는 단계

  이 때 검색 엔진이나 데이터베이스 등 다양한 소스에서 필요한 정보를 찾아냅니다. 검색된 데이터는 질문에 대한 답변을 생성하는데 적합하고 상세한 정보를 포함하는 것을 목표로 합니다.

• A에 해당하는 Augmented:

  “증강되었다”. 즉 생성 모델에 추가적인 정보(검색된 정보)를 제공하여 그 성능을 향상시킵니다.

• G 에 해당하는 Generation:

  검색된 데이터를 기반으로 LLM 모델이 사용자의 질문에 답변을 생성하는 단계입니다.

  단계에서 모델은 검색된 정보와 기존의 지식을 결합하여, 주어진 질문에 대한 답변을 생성합니다.

  
  

RAG Pipeline

RAG는 아래 단계들을 거칩니다.

① 데이터 로드(Load Data)

② 텍스트 분할(Text Split)

③ 임베딩(Embedding)

④ 벡터 저장(Vector Store)

⑤ 검색(Retrieval)

⑥ 생성(Generation)

2. Motivation

멀티 턴 이벤트 분석에서의 RAG

유저 입력이 요구하는 내용이 과거 채팅 히스토리에 기반해야 하는 경우(e.g. 방금 리스트에서 다섯 번째 내용에 대해 분석해 ),

멀티 턴 상황에서 유저가 시점별로 요구하는 내용에 따라 retrieve 대상 데이터도 달라져야 합니다.

따라서 대화 스텝별로 다른 시스템 프롬프트가 필요합니다.

고정 크기의 큐에 쌓인 누적 채팅 히스토리를 LLM input으로 사용하게 되면, 이벤트 분석 SQL문의 특성 상 입력 토큰이 과하게 길어지는 문제가 있어 서비스 운영 비용의 부담이 심해집니다.

이벤트 분석

저희의 메인 태스크인 이벤트 분석에 대해 설명드리겠습니다.

이벤트 분석은 이벤트가 발생했을 때, 이벤트 기간과 평시 기간을 비교하여 이벤트가 발생한 장소의 기지국/셀의 품질변화를 레포트 형식으로 리턴해주는 시나리오입니다.

이벤트 분석 데이터의 저장 방식은 '웹크롤링'과 '사용자 직업등록' 방식이 있습니다.

'웹크롤링'은 네이버에 축제하고 검색하면 나오는 이벤트 정보를 크롤링 하는 것이고, '사용자 직접등록'은 사용자가 idcube 이벤트분석앱을 통해 이벤트를 등록하는 방식입니다.

이벤트 분석 질문

이벤트 분석 질문 예제는 아래와 같습니다.

이벤트 분석에서 idcube openwebui 서비스가 겪은 문제점

이벤트 분석에서 idcube openwebui 서비스 적용에 여러 문제점들이 있었습니다.

첫째는 높은 입력 token 비용입니다. 멀티 턴 대화를 유지하려면 이전 대화의 내용을 다음 턴의 대화의 입력으로 모두 활용해야 하는데,

시스템 프롬프트의 길이와 스텝별로 출력되는 sql문의 길이가 너무 길기 때문에 입력 토큰 수가 지나치게 많아지게 됩니다.

두 번째는 할루시네이션입니다. IDCube openwebui 서비스는 openwebui라는 오픈소스

프로젝트를 기반으로 하며, 여기에는 개발자가 의도하지 않은 입력 프롬프트가 곳곳에 산재해 있다는 controllability의 문제가 있습니다.

예를 들어 고정 크기의 채팅 히스토리를 사용하고 그 내용을 역순으로 reranking하는 로직 등, text2sql에 맞지 않는 모듈을 강제로 사용하게 된다는 문제가 있었습니다.

마지막으로, 출력 결과가 3~4만 토큰을 요구하는 경우 llm api들의 일반적인 출력 제한인 8192토큰을 초과하여, 전체 내용을 생성하는 것이 근본적으로 불가능합니다.

3. Methods

LangGraph

저희 팀은 이런 문제들을 개선하기 위해 다음 방법들을 사용했습니다.

먼저 멀티 턴 챗봇에 맞는 파이프라인을 구성하기 위해, LangGraph 프로젝트를 활용했습니다.

랭그래프는 유저 입력을 분류하고, 조건에 맞는 다음 노드로 이동시키는 작업을 반복해서 시스템 프롬프트를 원하는 상황마다 다르게 활용할 수 있는 장점을 가진 유연한 프레임워크입니다.

이를 기반으로 이벤트 분석 시나리오에서 가능한 모든 상황을 커버하는 파이프라인을 구성했습니다.

Reduction of input token

오른쪽 그래프가 최종적으로 사용되는 파이프라인입니다. start와 end는 멀티 턴 채팅에서 하나의 질문과 답변 단위입니다.

유저가 start에서 질문하면, 챗봇은 조건에 따라 그래프의 노드를 이동하면서 상황별 시스템 프롬프트와 데이터를 검색하고, 여러 번의 추론을 거쳐 end에서 답변을 줍니다.

유저는 end의 답변을 토대로 다음 질문을 하게 되고 이는 다음 스텝의 start에서 시작되는 식으로 멀티턴 대화가 이어지게 됩니다.

왼쪽의 파이프라인은 일반적인 멀티 턴 챗봇의 구현 방식입니다.

차별점은 이전 스텝의 end를 다음 스텝의 start에 통합하는 시점입니다.

일반적인 멀티 턴 챗봇은 이전 대화 내용 전체를 다음 유저 질문에 이어붙여서 다음 답변을 얻지만, 저희는 다음 유저 질문의 특성을 분류하는 라우팅을 통해서,

이전 대화 내용에서 다음 유저 질문과 관련이 큰 일부 내용만 선별해서 이어붙이는 작업을 통해 스텝별 입력 토큰의 수를 줄였습니다.

라우터 노드는 위와 같이 동작합니다. 라우터 노드의 구성은 라우터 프롬프트와 llm api이며, 유저의 질문의 성격을 분류하는 기능을 합니다.

라우터 프롬프트에는 유저 질문과 유사한 이전 질문과 그 성격이 매핑된 데이터가 few shot으로 제공되며, 유저 질문은 프롬프트와 few shot을 참고해서 분류됩니다.

유저 질의의 성격을 분류한 다음에는, 분류된 성격에 따라서 이전 채팅 히스토리의 어떤 부분을 입력에 통합할지 결정하는 모듈이 채팅 히스토리의 일부를 잘라냅니다.

이벤트 리스트의 정보가 질문의 기반이 되어야 하므로, 현재 활용할 이벤트 리스트가 출력된 시점의 대화 인덱스만 저장되어 있다면 어떤 시점에서 채팅 히스토리를 잘라낼 지 판단할 수 있습니다.

새로운 이벤트 리스트를 출력하는 대화의 시작 이후로부터는, 이전 이벤트 리스트에 관련된 모든 내용을 제거할 수 있습니다.

이벤트 분석 시나리오는 결국 유저가 이전 이벤트 리스트를 통해 다음 요청을 하거나, 현재 이벤트를 기반으로 다른 분석을 요청하거나,

혹은 새로운 이벤트 리스트가 필요한 요청이기 때문에 이런 유한한 조건의 분류기로 모든 케이스를 커버하는 것이 가능합니다.

이런 특성을 이용해서, 저희는 채팅 히스토리의 내용을 질문 시점과 의도에 따라 잘라내는 방식으로 api의 입력 토큰 수를 줄일 수 있었습니다.

Reduction of hallucination & output tokens

또한 출력 sql문 포멧의 대부분은 고정된 포멧이고, 이 포멧의 일부를 대체하는 것만으로 의도한 결과를 도출할 수 있다는 관찰을 바탕으로,

최종 결과 전체를 출력하는 것이 아니라 llm은 대체할 정보만을 식별하고, 식별된 정보만을 포멧에서 대체하여 유저에게 제시하는 방식을 채택했습니다.

llm api들은 입력 context의 토큰 제한은 12만8천~20만 토큰으로 많은 데 비해 출력 토큰은 8192토큰으로

작은데, 이 방식을 사용하면 입력 context의 제한을 넘지 않으면서 출력 토큰을 최소화할 수 있었습니다.

이를 통해 생성해야 하는 sql문이 3~4만 토큰으로 api의 출력 한계를 넘는 경우를 해결할 수 있었습니다.

이벤트 분석 시나리오 이외의 상황을 추후 추가하게 되더라도,

sql문의 작성은 주로 정해진 포멧의 일부를 대체하는 작업이기 때문에 대부분의 케이스에서 유저가 원하는 sql문을 제시하는 데 문제가 없는 확장성이 높은 방식입니다.

Improvement

저희가 제시하는 메소드는 다음의 세 문제에 대한 해결책을 제시했습니다.

첫째로 채팅 히스토리를 라우터의 판단에 따라 잘라내는 방식으로 입력 토큰의 수를 줄였고,

둘째로 langGraph를 통해 기존 서비스가 가지던 문제점들로부터 비롯된 할루시네이션을 완화했습니다.

마지막으로 템플릿과 대체 정보의 조합을 통해 출력 토큰을 크게 줄였고, 유저에게 전달되는 sql문은 동일하게 유지하거나 생성이 불가능하던 sql문을 제시할 수 있게 되었습니다.

event list retriever

다음은 전체 파이프라인을 구현한 streamlit demo의 스크린샷입니다.

유저가 지난주 이벤트 리스트를 알려달라고 질문하면, 라우터는 이것이 이벤트 리스트 출력을 위한 sql문의 생성, 실행, 그리고 결과 출력의 요구임을 판단합니다.

질문의 의도를 파악했기 때문에 현재 시각을 바탕으로 지난주에 해당 하는 기간을 추론하여 sql문의 where절에 입력하고 실행하여 원하는 결과를 얻습니다.

유저가 이 리스트를 읽은 뒤 4번 이벤트에 대한 분석을 요구하면, 라우터는 이것이 직전 이벤트 리스트에 대한 질문임을 파악하고,

이전 대화 내역 중 마지막 대답만을 채팅 히스토리에서 잘라내어 현재 유저 입력과 통합합니다.

이를 입력으로 활용해서 4번 이벤트가 무엇인지 추론하고, 분석 방법 추천을 통해 다음 질문을 유도합니다.

추천된 분석을 유저가 요구하면, 마찬가지로 라우터가 의도를 파악하고 이 요구에 맞는 시스템 프롬프트와 데이터를 검색하여 sql문을 생성합니다.

event analyzer

만약 유저가 다른 이벤트에 대한 분석을 요구하면, 라우터는 요청사항을 해결하기 위한 채팅 히스토리의 일부를 잘라냅니다.

이 경우 현재 시나리오에서 최초로 요청됐던 이벤트 리스트 이전의 대화를 잘라냅니다.

이벤트 분석 시나리오에서 유저의 질문은 유저가 목격한 이벤트 리스트에 근거하기 때문에, 해당 정보 이전의 채팅 히스토리는 입력과 무관함을 이용하는 것입니다.

event analyzer & common SQL generator

또한 이벤트 분석과 무관한 다른 분석 요구사항을 입력할 때는 일반적인 RAG즉 질문과 정답 sql문이 매핑된 데이터가 다량 저장된 db에서 질의와 상관있는 few shot을 통한 생성을 합니다.

이는 보조적인 기능으로, 이벤트 분석 시나리오와 섞이지 않게 하기 위해 가이드라인에서 !로 질의를 시작하라고 지시하며, 챗봇은 이때 일반적인 RAG로 대응합니다.