▲

GN⁺: Vanna.ai: SQL 데이터베이스와 대화하기

 (github.com/vanna-ai)
3P by neo 8달전 | favorite | 댓글 1개
  • RAG (Retrieval-Augmented Generation)를 적용한 LLM으로 정확한 Text-To-SQL 생성하는 오픈소스

Vanna 작동 방식

  • RAG "모델" 학습: 사용자의 데이터에 대해 RAG 모델을 학습시킴.
  • 질문하기: 학습된 모델을 사용하여 질문하면, 데이터베이스에서 자동으로 실행될 수 있는 SQL 쿼리를 반환함.

사용자 인터페이스

  • Vanna를 사용하여 구축된 몇 가지 사용자 인터페이스는 Jupyter Notebook, vanna-ai/vanna-streamlit, vanna-ai/vanna-flask, vanna-ai/vanna-slack 등이 있음.

시작하기

  • 설치: pip install vanna 명령어로 Vanna를 설치할 수 있음.
  • 가져오기: import vanna as vn 코드를 통해 Vanna를 사용할 수 있음.

훈련

  • DDL 문장으로 훈련: 데이터베이스의 테이블 이름, 컬럼, 데이터 타입, 관계 등에 대한 정보를 포함하는 DDL 문장을 사용하여 모델을 훈련시킬 수 있음.
  • 문서로 훈련: 비즈니스 용어나 정의에 대한 문서를 추가하여 모델을 훈련시킬 수 있음.
  • SQL로 훈련: 기존에 있는 SQL 쿼리를 훈련 데이터로 추가하여 새로운 SQL을 생성할 수 있음.

질문하기

  • vn.ask("질문") 메서드를 사용하여 질문하면 관련 SQL 쿼리를 받을 수 있음.

RAG 대비 파인 튜닝

  • RAG는 LLM에 걸쳐 이식 가능하고, 학습 데이터를 쉽게 제거할 수 있으며, 비용이 저렴하고 미래에 대한 적응력이 높음.
  • 파인 튜닝은 프롬프트 내 토큰을 최소화할 필요가 있을 때 유용하지만, 시작이 느리고 훈련 및 실행 비용이 비쌈.

Vanna 선택 이유

  1. 복잡한 데이터셋에 대한 높은 정확도: 학습 데이터에 기반하여 Vanna의 능력이 결정됨.
  2. 보안 및 개인 정보 보호: 데이터베이스 내용이 LLM이나 벡터 데이터베이스로 전송되지 않음.
  3. 자가 학습: Jupyter를 통해 사용하면 성공적으로 실행된 쿼리에 대해 자동 학습할 수 있음.
  4. 모든 SQL 데이터베이스 지원: Python으로 연결할 수 있는 모든 SQL 데이터베이스에 연결할 수 있음.
  5. 프론트 엔드 선택: Jupyter Notebook에서 시작하여 Slackbot, 웹 앱, Streamlit 앱 또는 사용자 정의 프론트 엔드로 사용자에게 제공할 수 있음.

Vanna 확장

  • Vanna는 모든 데이터베이스, LLM, 벡터 데이터베이스에 연결하도록 설계됨.
  • VannaBase 추상 기본 클래스는 기본 기능을 정의하며, OpenAI와 ChromaDB를 사용하는 구현을 제공함.

추가 자료

  • 전체 문서, 웹사이트, 지원을 위한 Discord 그룹 등이 제공됨.

GN⁺의 의견:

  • Vanna는 데이터베이스 관리 및 SQL 쿼리 생성을 자동화하는 강력한 도구로, 사용자가 복잡한 데이터셋에 대해 높은 정확도의 SQL 쿼리를 쉽게 생성할 수 있게 해줌.
  • 사용자 친화적인 인터페이스와 자가 학습 기능을 통해 비전문가도 효율적으로 데이터베이스를 활용할 수 있게 되며, 이는 데이터 기반 의사결정을 더욱 가속화할 수 있음.
  • Vanna의 확장성과 미래 적응력은 기업이 기술 변화에 유연하게 대응하고 지속적으로 데이터 관리 프로세스를 개선할 수 있는 기회를 제공함.
▲
neo 8달전  [-]
Hacker News 의견

  • ChatDB.ai 프로젝트 개발 중인 사용자 경험

    • ChatDB.ai라는 유사한 프로젝트를 개발 중임.
    • AI와 SQL을 결합하여 가장 성공적이었던 경험은 SQL 제공자의 오류를 각 반복 후 LLM에 피드백하는 것이었음.
    • 포맷된 오류 메시지 래퍼를 사용하여 시스템 테이블 쿼리를 강력하게 제안함으로써, 스키마 정보를 발견하는 데 매우 효과적이었음.
    • 이러한 작은 조정으로, 4개 이상의 테이블 조인이 필요한 쿼리를 찾는 데 놀라울 정도로 능숙해짐.

  • GPT-4를 사용한 개인 경험

    • GPT-4를 사용하여 이미 유사한 작업을 수행함.
    • MySQL CLI의 SHOW TABLE 명령어로 테이블 구조를 확인하고, 해당 테이블을 기반으로 장바구니 포기율 등 비즈니스 지표를 보여주는 쿼리를 생성함.
    • 이 방법이 상당히 잘 작동함을 경험함.

  • 자연어를 SQL로 번역하는 시스템에 대한 회의적인 견해

    • 자연어를 SQL로 번역하는 시스템 개발 노력을 인정하면서도, 자연어와 모델의 근본적인 특성이 추정적이고 정밀도가 떨어진다는 점에서 회의적임.
    • SQL 데이터베이스는 대부분의 경우 정확하고 정밀한 정보 처리를 위해 설계되었으며, 추정적인 레이어를 도입하는 것은 문제를 더 악화시킬 수 있음.
    • 이러한 시도가 실제 세계의 요구를 효과적으로 해결하는 데 생산적인지 의문을 제기함.

  • YC 지원 스타트업들을 포함한 유사 제품에 대한 관심

    • Minds DB (YC W20), Buster (YC W24), DB Pilot 등과 같은 몇 가지 유사 제품을 추적하고 있으며, 이 분야에 관심이 많음.
    • 자신도 이러한 솔루션을 찾고 있음.

  • duckdb 기반 보고 서비스에 대한 경험

    • 전반적으로 잘 작동하지만 몇 가지 문제에 부딪힘:
      • 낮은 온도 설정에도 불구하고 GPT-4가 때때로 예제나 스키마에서 벗어남.
      • 서비스는 일반적인 데이터를 호스팅하지만, 고객은 자신들의 도메인 언어로 보고서 생성을 요청함.
      • LLM 프롬프트 디버깅이 까다로움. 고객이 모델을 쉽게 혼란시킬 수 있음.
      • 생성된 쿼리에 대한 "설명"을 고객에게 제공하여 보고서 작성에 사용된 내용을 투명하게 함.

  • RAG 작동 방식에 대한 우려와 설명

    • "train"이라는 용어 사용에 대해 우려를 표함.
    • RAG가 훈련이나 미세 조정 없이 데이터 준비, 청킹, 벡터화만을 필요로 한다는 점을 강조하며 설명하는 데 많은 시간을 할애함.

  • LLM의 환각 문제에 대한 궁금증

    • LLM이 "어제"와 같은 시간 개념을 어떻게 해석하는지, 생성된 SQL이 문법적으로 유효하더라도 의도와 다를 수 있는 문제에 대해 궁금함.
    • 특히 MAX, COUNT와 같은 집계 쿼리에서 잘못된 숫자를 내놓을 위험이 있으며, 이를 확인하기 위해서는 SQL을 직접 읽어야 하는데, 이는 전체 목적에 어긋남.

  • 자체 데이터셋과 기술을 사용한 경험 공유

    • 내부 직원들이 구조화된 데이터셋과 대화할 수 있는 봇을 개발하는 데 유사한 기술을 사용함.
    • 실제로는 어느 정도 작동하지만 몇 가지 도전 과제가 있음:
      • 기존 모델에는 없는 특정 업무 관련 열거형과 데이터 타입이 많아, 이를 수동으로 정의하고 프롬프트에 문맥으로 추가해야 함.
      • 시간 관련 질문에 대한 처리가 어려움.
      • 사용자가 무엇이든 물어볼 수 있기 때문에, 단일 테이블에 대해 많은 예시 SQL 쿼리가 필요함.
      • 다양한 테이블로 확장하는 데 어려움이 있으며, 더 효율적인 방법이 있는지 궁금함.
      • Llama2 70B Gen 모델을 사용했지만, 다른 모델이 SQL 쿼리 생성에 있어 더 나은 성능을 보이는지 궁금함.

  • bit.io에서의 경험과 고객 반응

    • bit.io에서 유사한 작업을 수행했으며, 사람들이 이를 좋아함.
    • 작업 중 발견한 내용에 대한 여러 기사가 있으며, 현재는 Databricks에 인수되어 서비스를 종료함.
    • 가능한 한 질문에 답변할 준비가 되어 있음.
답변달기