이 글은 [요즘 우아한 AI 개발]에서 발췌했습니다.
글 우아한형제들 / 골든래빗 출판사

AI 데이터 분석가 ‘물어보새’는 생성형 AI를 주제로 한 〈우아톤 2023〉¹을 계기로 탄생한 프로덕트입니다. 당시 ‘코드 없이 데이터 추출과 시각화를 자동으로 하는 서비스’로 1등을 차지했습니다. 우아톤 이후에도 구성원들의 요구와 관심이 지속되어 2024년 1월에 본격적인 개발을 위한 ‘언’지니어’ 태스크포스(TF)가 구성되었습니다. 지난 6개월 동안 TF를 통해 ‘물어보새’는 더욱 발전해 쿼리문 생성뿐만 아니라 쿼리문 해석, 쿼리 문법 검증, 테이블 탐색 및 로그 안내 등의 다양한 기능을 갖추게 되었습니다. 지금부터 들려드릴 이야기는 지난 6개월 동안 TF 구성원들이 고군분투하며 만든, 세상에 없던 AI 서비스 ‘물어보새’의 개발기입니다.

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

문제 정의

TF 시작에 앞서 해결해야 할 문제를 재정의하고, 프로덕트 개발 방향을 명확히 설정해야 했습니다. 이를 위해 모든 구성원을 대상으로 사내 데이터 활용 현황에 대한 설문조사를 진행했습니다. 설문조사 결과, 응답자의 약 95%가 데이터를 활용해 업무를 수행했습니다. 그러나 절반 이상의 응답자는 SQL을 업무에 활용하고 싶어도 학습 시간이 부족하거나, SQL 구문에 비즈니스 로직과 다양한 추출 조건을 반영해 작성하는 데 어려움을 느끼고 있었습니다. 또한 데이터를 적절히 추출했는지 신뢰도에 대한 고민도 있었습니다.

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

해결 방안

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

1. 체계화: 데이터 서비스실에서 제공하는 데이터 카탈로그의 테이블 메타 정보, 데이터 거버넌스의 비즈니스 용어, 그리고 검증된 데이터 마트를 활용해 데이터 정보의 일관된 체계를 수립한다.
2. 효율화: 우아한형제들의 비즈니스를 이해하고, 사내 정보를 쉽고 빠르게 검색할 수 있는 기술을 개발한다.
3. 접근성: 누구나 쉽고 빠르게 질문할 수 있도록 웹 기반이 아닌 업무 전용 메신저 슬랙의 대화창을 이용한다.
4. 자동화: 데이터 담당자가 없어도 365일 24시간 언제 어디서나 이용할 수 있는 자동화된 데이터 서비스를 지향한다.

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

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

물어보새 기반 기술

물어보새의 기반 기술은 LLM, RAG, 랭체인(Langchain), LLMOps입니다.

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

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

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

물어보새 개발 아키텍처

〈우아톤 2023〉에서는 프롬프트와 마이크로소프트 애저 오픈AI의 GPT-3.5 API를 이용해 간단히 구축되었습니다. 그러나 기존 방식은 ‘체계화’, ‘효율화’, ‘접근성’, ‘자동화’를 구현하기에 한계가 있어, 새로운 아키텍처를 설계했습니다. 이 아키텍처는 4가지 관점에서 다음과 같이 설계되었습니다.

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

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

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

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

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

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

4. 슬랙 기반의 다양한 응답 기능 도입

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

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

물어보새 캐릭터 디자인

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

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

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

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

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

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

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

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

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

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

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

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

물어보새 Text-to-SQL

물어보새의 Text-to-SQL 체인 영역을 알아보겠습니다.

데이터 보강

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

이를 기반으로, 테이블 메타 데이터를 풍부하게 할 방법들을 고안했고, 기존보다 고도화된 메타 데이터 생성 작업을 진행했습니다. 기존에도 잘 되어 있었지만, 테이블의 목적과 특성, 컬럼의 상세 설명, 주요 값 및 키워드 등 기존에 기록되지 않았던 상세한 내용을 추가했습니다. 또한, 주로 사용되는 서비스와 질문들을 정리했습니다. 테이블 메타 데이터를 기반으로 테이블 DDL⁶ 데이터를 생성하니 기존보다 훨씬 풍부한 DDL을 만들 수 있었습니다.

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

마지막으로, 퓨샷 SQL (few-shot SQL) 예제 데이터 구축을 진행합니다. 퓨샷이란 프롬프트에 몇 가지 예시 답변을 입력하는 기법입니다. 이는 모델이 답변에 필요한 여러 정보를 학습해 사용자의 질문에 대해 더 정확하고 관련성 높은 답변을 생성하도록 도울 수 있습니다. 도메인 지식을 쿼리문에 반영하는 데 있어 중요한 부분으로, 예시 쿼리문의 품질이 높을수록 답변 성능에 긍정적인 영향을 미칩니다.

따라서 데이터 분석가가 기존에 생성해놓은 높은 품질의 쿼리문과 주요한 비즈니스 질문에 대한 쿼리문을 추가로 작성해 예제 데이터를 수집했습니다. 그리고 각 쿼리문에 해당하는 질문을 작성해 쿼리문-질문 데이터셋을 구축했습니다. 퓨샷 SQL 예제 데이터의 경우, 늘 새롭게 변경되는 데이터 추출 기준과 급변하는 비즈니스 상황에 대응할 수 있어야 하므로 각 도메인 지식에 특화된 데이터 분석가가 관리해야 합니다. 향후 해당 부분은 도메인 데이터 분석가와 원활하게 의사소통을 하고 데이터를 관리할 수 있도록 협업 체계를 구축할 계획입니다.

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

검색 알고리즘 개발

 

프롬프트 활용 시, 사용자 질문과 단계마다 적합한 검색 알고리즘을 활용해 데이터를 입력시키는 것이 중요합니다. 사용자 질문이 모호하거나 짧고 명확하지 않은 경우, 질문을 구체화해야 합니다. 질문을 구체적으로 만들 때는 반드시 비즈니스 용어를 먼저 이해해야 하므로, 질문의 의도와 관련이 있는 적절한 용어를 추출해야 합니다. 이 단계에서 비슷하지만 의도와 관련이 없는 용어를 추출하면 LLM이 잘못된 질문을 만들 수 있기 때문에, 정교한 검색 알고리즘이 필요합니다.

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

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

프롬프트 엔지니어링

프롬프트는 질문 구체화 프롬프트와 쿼리 생성 프롬프트로 나뉘지만, 공통적으로 활용하는 요소가 있습니다. 먼저, 두 프롬프트 모두 데이터 분석가의 페르소나를 부여받습니다. 설정된 페르소나에 따라 결과물의 품질이 달라질 수 있으므로, 원하는 역할과 기대하는 결과물에 대해 충분한 논의가 필요합니다.

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

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

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

 

실험 및 평가 시스템 구축

Text-to-SQL 성능을 평가하고 경쟁하는 다양한 리더보드가 있습니다. 가장 유명한 리더보드는 예일 스파이더⁹와 알리바바 버드¹⁰가 있습니다. 또한 LLM과 RAG 애플리케이션의 지속적인 개선을 위해 지표 기반의 개발을 추구하는 라고스¹¹도 있습니다. 이러한 평가 방법과 지표들의 공통점은 Text-to-SQL의 성능을 평가 데이터와 평가 지표를 통해 판단하고, 현황을 파악해 개선할 수 있다는 점입니다.

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

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

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

자체적으로 사내 리더보드를 구축하고 각자의 아이디어를 실현하기 위해 500번 이상의 A/B 테스트를 수행했습니다. 특히, 개개인이 만든 결과가 순위로 측정되면서 게임 요소로 작용해 재미있게 참여할 수 있었습니다. 주 단위 싱크 업을 통해 가장 높은 성능을 낸 결과를 운영에 배포해 점진적으로 서비스를 고도화했습니다. 위의 요소 외에도 랭서브 플레이그라운드¹²를 활용하면 변경된 프롬프트나 체인의 성능 변화를 빠르게 확인할 수 있습니다.

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

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

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

물어보새 1부를 마치며

점진적으로 테스트 참가자와 대상 조직을 늘려나가면서, 쿼리문 생성 답변뿐만 아니라 데이터 디스커버리 영역에 대한 질문 비중이 상당히 높다는 것을 알게 되었습니다. 데이터 디스커버리(Data Discovery)는 테이블 컬럼, 테이블 구조, 테이블 유형 등을 탐색하고 이해해 유의미한 인사이트를 도출하고, 이를 비즈니스 인텔리전스(BI) 리포트로 작성하는 과정을 의미합니다. 이를 위해서는 쿼리문 작성뿐만 아니라 다양한 데이터 질문에 대해 답변할 수 있어야 하기 때문에, Text-to-SQL을 넘어서서 데이터 디스커버리 영역으로 물어보새의 기능을 확장하게 되었습니다.

지금까지 프로덕트 소개와 Text-to-SQL 기능 구현에 대해 설명드렸습니다. 이어서 이 글의 2부에서는 데이터 디스커버리 기능들과 향후 계획을 이야기하겠습니다.

¹우아한형제들 구성원 누구나 참여할 수 있는 사내 해커톤. https://techblog.woowahan.com/13929/

²Retriever: 검색기 또는 검색자로 번역될 수 있으며, 주로 정보 검색 시스템에서 데이터나 문서를 찾아오는 역할을 하는 구성 요소

³DocumentLoader: 문서를 불러와 처리하거나 데이터로 변환하는 역할을 하는 컴포넌트나 모듈. 주로 문서에서 데이터를 읽어오는 데 사용됩니다.

⁴Vectorstore: 벡터 데이터를 저장하고 관리하는 데이터베이스나 시스템. 주로 벡터 임베딩을 효율적으로 검색하고 저장하는 데 사용됩니다. 우리말로는 벡터 저장소 또는 벡터 데이터 저장소라도 부릅니다.

⁵〈Data Ambiguity Strikes Back: How Documentation Improves GPT’s Text-to-SQL〉

⁶DDL(Data Definition Language): 테이블의 구조를 정의하거나 변경하는 데 사용되는 SQL 명령어

⁷〈ReAct:Synergizing Reasoning and Acting in Language Models〉

⁸ReAct: LLM(대형 언어 모델) 기반의 프롬프트 설계 기법으로, 모델이 추론(Reasoning)과 행동(Action)을 반복하며 문제를 해결하도록 설계된 방식. 주로 지식 기반 시스템이나 에이전트 설계에서 사용되며, 모델이 논리적으로 문제를 해결하는 동시에 외부 도구(예: 검색기, 계산기 등)를 활용해 최적의 답을 도출할 수 있도록 합니다.

⁹YALE Spider: 복잡한 도메인 간 시맨틱 파싱 및 텍스트에서 SQL로 변환하는 대규모 데이터셋. 예일 대 학 연구진이 개발했으며, 200개 이상의 데이터베이스에서 5,693개의 고유한 SQL 쿼리와 10,181개의 질 문을 포함합니다. 이 데이터셋의 목적은 자연어로부터 SQL 쿼리를 생성하는 모델의 성능을 평가하고 향상 시키는 것입니다. https://yale-lily.github.io/spider

¹⁰Alibaba BIRD: 알리바바에서 개발한 대규모 데이터 처리와 지능형 연구 개발을 지원하기 위해 구축한 인프라 https://bird-bench.github.io/

¹¹Ragas: Retrieval Augmented Generation(RAG) 파이프라인을 평가하는 프레임워크. 이 프레임워크는 외부 데이터를 사용해 LLM의 컨텍스트를 확장하는 응용 프로그램을 평가하는 데 필요한 다양한 평가 지표 를 제공합니다. https://docs.ragas.io/

¹²LangServe Playground : 체인의 실험 환경으로, 개발자가 다양한 입력 값과 구성 요소를 실시간으로 테스트할 수 있는 이를 제공합니다. 이를 통해 LLM 애플리케이션의 구성 요소(예 : 모델)를 쉽게 조정하고, 스트리밍 출력과 중간 단계를 시각적으로 확인할 수 있습니다. 또한 팀원들과 공유하여 협업할 수 있으며, 기술적이지 않은 사용자도 애플리케이션을 쉽게 테스트해볼 수 있는 기능을 제공합니다.