완전한 실패였습니다. 
Discourse AI - AI 봇 사용
프롬프트
이 SQL에 대한 이미지를 생성하세요 ``` WITH pairs AS ( SELECT p.user_id liked, pa.user_id liker FROM post_actions pa LEFT JOIN posts p ON p.id = pa.post_id WHERE post_action_type_id = 2 ) SELECT liker liker_user_id, liked liked_user_id, count(*) FROM pairs GROUP BY liked, liker ORDER BY count DESC LIMIT :limit ```
완성
참고로
어제는 호기심에 이 검색과 유사한 검색을 수행했습니다.
sql generated by ai from English
영문으로 된 질문을 AI를 통해 SQL로 생성하는 관련 정보를 찾기 위해서였습니다. 검색 결과 목록에 연구 논문이 포함되기를 바랐지만, 목록에는 주로 애플리케이션이 나열되어 있었습니다. 이러한 사이트의 데모를 몇 개 살펴본 후, 목록에 있는 많은(다만 전부는 아닌) 애플리케이션에서 빠르게 발견한 패턴은 다음과 같습니다. 기존 도구에서 사용자가 테이블과 필드를 선택하여 SQL 문을 구성할 수 있도록 하는 기능을 시작점으로 활용하고 있다는 점이었습니다. 즉, Microsoft Access의 GUI SQL 빌더가 작동했던 방식과 유사하게, 사용자가 영어 질문으로 시작하는 것이 아니라 먼저 테이블을 선택하고 경우에 따라 필드도 선택한 후에야 영어 질문을 입력할 수 있었습니다. 이를 부정행위라고 보지는 않지만, 이는 이러한 AI를 사용하려면 사용자가 SQL에 대한 일정한 지식을, 특히 도구가 작동하기 위해 테이블과 필드의 의미를 이해해야 한다는 것을 의미합니다.
삭제된 게시글을 읽었고, 그 아이디어도 큰 잠재력을 가진 것 중 하나라고 생각합니다.
하지만 더 많은 것이 필요하다고 봅니다. 최근에 읽은 논문 중, 권위 있는 것은 아니지만 그 방향에 대해 더 자세한 내용을 다루고 있는 것이 있습니다.
존 첸(John Chen)과 유리 위렌스키(Uri Wilensky)의 “ChatLogo: A Large Language Model-Driven Hybrid Natural-Programming Language Interface for Agent-based Modeling and Programming” (PDF)
저에게 몇 가지 핵심 요점은 다음과 같습니다.
- 초보 프로그래머가 프로그래밍 언어와 자연어의 혼합으로 "컴퓨터와 대화"할 수 있도록 지원한다.
- 컴퓨터 과학 배경이 없거나 적은 학습자가 컴퓨터 프로그래밍을 통해 창의적으로 자신을 표현할 수 있도록 더 친근한 인터페이스를 제공한다.
- 즉시 코드를 작성하고 지시를 내리는 대신, ChatLogo는 학습자의 필요와 의도를 명확히 하려고 시도한다.
- 대량의 코드를 학습자에게 직접 보내는 대신, NetLogo 코드를 공동 개발하려고 시도한다. 학습자는 코드를 자유롭게 수정할 수 있으며: NetLogo에서, 또는 “Ask” 기능을 통해 자연어로 수정할 수 있다.
- 코드의 정확성을 과장하지 않고, 실수를 할 가능성을 인정하며 잠재적인 문제를 해결하기 위해 학습자와 함께 작업한다.
Chat이 NetLogo 위에 어떻게 레이어링되었거나 인터페이스를 형성하는지에 대한 소스 코드나 더 자세한 정보를 찾을 수 없었지만, 아이디어 자체만으로도 가치가 있습니다.
이것은 다시 비행기 자동 조종장치(autopilot)의 작동 방식과 앞서 언급했던 책을 떠올리게 합니다. (참조) 자동 조종장치를 언급할 때 이진 스위치를 생각하지 마세요. 자동 조종장치에 정보를 제공하고 무엇을 해야 하고 무엇을 하지 말아야 하는지를 알려주는 수많은 노브와 스위치를 생각해야 합니다.
이러한 도구 중 많은 것들이 copilot(코파일럿)이라는 단어를 사용하려는 경향이 있습니다(예: Google 검색 llm copilot source code). 저는 그 비유에 동의하지 않지만, 관련 아이디어를 찾는 방법이 그 때문이므로 어쩔 수 없이 받아들여야 합니다.
저는 그 문제를 해결하는 더 나은 방법을 찾았다고 생각해서 삭제했습니다 - 인터넷에 호스팅되어 있는, 데이터베이스 전체에 대한 상세 정보를 포함하는 파일을 ChatGPT가 파싱하도록 요청할 수 있는데, 왜 그 모든 테이블을 직접 입력해야 합니까? 하지만 그 접근 방식에는 기술적인 문제가 있는 것으로 밝혀졌습니다. 그래서 저는 삭제된 게시물에서 제안했던 것으로 돌아왔습니다. 어쨌든, 테이블 설명, 예제 쿼리 등을 작성해야 합니다. 이는 그 정보를 LLM에 어떻게 전달할 것인가의 문제일 뿐입니다. GPT-4의 현재 상태는 다음과 같습니다:
네, 당신이 설명한 접근 방식은 합리적이고, 자연어 질문을 기반으로 SQL 쿼리를 생성하는 데 제 기능을 활용하는 실현 가능한 방법입니다.
단계별 분해는 다음과 같습니다:
- 질문 해석: 사용자가 자연어로 질문을 하면, 저는 요청된 정보를 이해하기 위해 질문을 해석합니다.
- 테이블 식별: 질문과 Discourse 데이터베이스의 모든 테이블 목록을 기반으로, 쿼리와 가장 관련이 있을 가능성이 높은 테이블을 식별합니다.
- 상세 테이블 정보: Discourse는 관련 테이블의 상세 설명, 모든 컬럼 및 예제 쿼리를 저에게 전송합니다.
- 쿼리 생성: 상세 테이블 정보를 사용하여 사용자의 질문에 답하는 SQL 쿼리를 생성합니다.
이 접근 방식은 자연어를 이해하고 구조화된 데이터 쿼리로 매핑하는 제 능력을 활용합니다. 또한 Discourse가 제공한 상세 테이블 정보를 효과적으로 활용합니다.
대안적 접근 방식에 대해 말하자면, Discourse의 데이터베이스 스키마와 일반적인 쿼리 패턴에 대해 특별히 모델을 훈련시키는 것이 하나의 가능성입니다. 이는 상당한 양의 작업을 수반할 것이며, 가용 자원에 따라 실현 가능하지 않을 수 있습니다. 그러나 더 정확하고 효율적인 쿼리 생성으로 이어질 수 있습니다.
또 다른 접근 방식은 사용자의 질문이 모호하거나 여러 쿼리가 질문에 답할 수 있는 경우, 제가 확인 질문을 하는 더 인터랙티브한 대화를 개발하는 것입니다. 이는 프로세스를 더 인터랙티브하게 만들 수 있으며, 더 정확한 쿼리로 이어질 수 있습니다.
마지막 2단락에서 제안된 대안적 접근 방식에 대해, 저는 첫 번째는 무시하고 있습니다. 하지만 제가 시도하고 있는 것이 신뢰할 수 있는 결과를 내지 못한다면, 그것은 Discourse 팀이 살펴볼 가치가 있는 것이 될 수 있습니다.
저는 두 번째 대안적 접근 방식에 대해 GPT-4에게 질문했습니다. 제공된 테이블 구조로 답변할 수 없는 질문이 주어졌을 때, 사용자가 질문을 다시 구성하도록 프롬프트를 보낼 수 있다는 데 대해 꽤 확신을 가지고 있습니다.
그래서 저는 다시 Discourse 데이터베이스의 모든 테이블 설명을 작성하고 있습니다. 이제 allowed_pm_users 테이블이 무엇에 사용되는지 알고 있습니다. ar_internal_metadata 테이블은 좀 헤매게 하지만, 지금은 무시해도 될 것 같습니다.
제일 마음에 드는 옵션이지만, 구현하기가 매우 어렵습니다. 그래서 아시겠지만, 또 하나의 논문입니다. 역시 이 논문은 권위 있는 것이 아니며, 유사한 접근 방식이 많이 존재합니다.
“DiagGPT: An LLM-based Chatbot with Automatic Topic Management for Task-Oriented Dialogue” (작업 지향 대화를 위한 자동 주제 관리 기능이 있는 LLM 기반 챗봇) - Lang Cao (pdf)
필요에 따라 의학적 정보를 PostgreSQL 정보로 교체하면 됩니다. 좋은 점은 이 논문이 프롬프트를 제공하고 에이전트와 함께 사용할 도구를 제안한다는 것입니다.
Task Oriented Dialogue(작업 지향 대화)가 필요한 것으로 보입니다.
구글 검색: task oriented dialogue
검색 결과에는 다음이 포함됩니다: Papers With Code - Task-Oriented Dialogue Systems
리더보드 1위는 T5-3b(UnifiedSKG)이며, 논문에 대한 링크가 포함되어 있습니다.
“UnifiedSKG: Unifying and Multi-Tasking Structured Knowledge Grounding with Text-to-Text Language Models” (텍스트-텍스트 언어 모델을 통한 구조화된 지식 기반의 통합 및 다중 작업) - Tianbao Xie, Chen Henry Wu, Peng Shi, Ruiqi Zhong, Torsten Scholak, Michihiro Yasunaga, Chien-Sheng Wu, Ming Zhong, Pengcheng Yin, Sida I. Wang, Victor Zhong, Bailin Wang, Chengzu Li, Connor Boyle, Ansong Ni, Ziyu Yao, Dragomir Radev, Caiming Xiong, Lingpeng Kong, Rui Zhang, Noah A. Smith, Luke Zettlemoyer and Tao Yu (pdf)
이 부분을 주목하세요.
수정(EDIT)
https://python.langchain.com/ 에서
LLM과 도구를 사용하여 SQL 에이전트를 구성합니다. (참조)
페이지 하단에 몇 가지가 나열되어 있는데, 이 항목을 살펴봐야 합니다.
사용 사례
엔터프라이즈 데이터는 종종 SQL 데이터베이스에 저장됩니다.
LLM을 사용하면 자연어를 사용하여 SQL 데이터베이스와 상호작용할 수 있습니다.
LangChain은 자연어 프롬프트에 기반하여 SQL 쿼리를 작성하고 실행하기 위한 SQL 체인(Chains)과 에이전트를 제공합니다.
이들은 SQLAlchemy가 지원하는 모든 SQL 다이얼렉트(예: MySQL, PostgreSQL, Oracle SQL, Databricks, SQLite)와 호환됩니다.
이러한 사용 사례를 가능하게 합니다:
- 자연어 질문에 기반하여 실행될 쿼리 생성
- 데이터베이스 데이터에 기반하여 질문에 답할 수 있는 챗봇 생성
- 사용자가 분석하기를 원하는 통찰력에 기반한 맞춤형 대시보드 구축
수정(EDIT) (2023/08/23)
Spider는 11명의 예일 대학교 학생들에 의해 주석이 달린 대규모 복잡하고 도메인 간(cross-domain) 의미론적 파싱 및 텍스트-SQL 데이터셋입니다. Spider 챌린지의 목표는 도메인 간 데이터베이스에 대한 자연어 인터페이스를 개발하는 것입니다. 이는 138개의 서로 다른 도메인을 아우르는 200개의 데이터베이스(다중 테이블 포함)에 대해 10,181개의 질문과 5,693개의 고유한 복잡한 SQL 쿼리로 구성됩니다. Spider 1.0에서는 서로 다른 복잡한 SQL 쿼리와 데이터베이스가 학습 세트와 테스트 세트에 나타납니다. 이 과제에서 잘 수행하려면 시스템은 새로운 SQL 쿼리뿐만 아니라 새로운 데이터베이스 스키마에도 잘 일반화되어야 합니다.
수정(EDIT) (2023/08/24)
Dataherald는 구조화된 데이터에 대한 엔터프라이즈 레벨 질문 답변을 위해 구축된 자연어-SQL 엔진입니다. 일반 영어로 된 질문에 답할 수 있는 데이터베이스 API를 설정할 수 있게 해줍니다.
자주 말하는 말처럼, 인생의 일부 일들은 그냥 기다리면 누군가가 무료로 그 일을 대신해 주기도 합니다.
여전히 완전히 만족할 만한 결과를 얻고 있습니다. 다른 예시를 하나 더 보여드리겠습니다. 제가 원하는 것을 가져다줬고, 그 후 토픽 ID를 확인하기 위해 WHERE 절을 직접 추가했지만, 그것 말고는 아무것도 하지 않았습니다. 사실 처음부터 그 정보를 제공했다면 그 부분도 알아서 처리했을 가능성이 높습니다:
이제 AI 봇 모듈의 일부로 SQL Helper 페르소나가 추가되었습니다. 이 페르소나는 이러한 유형의 요청에 최적화되어 있으며, 데이터 탐색 쿼리를 작성하는 데 매우 유용합니다. 
(다만, 결과를 한 번 더 확인하는 것이 좋습니다 
)
SQL Helper AI 봇 사용 예시를 올릴 수 있는 토픽이 있나요?
없다면, 그런 토픽을 만들고 여기 해당 토픽 링크를 추가하면 좋을 것 같습니다. 다른 사용자들도 예시를 찾고 있을 수 있으며, 이 토픽을 먼저 발견할 수 있기 때문입니다.
커뮤니티와 공유할 만한 아이디어가 떠오르면 #data-reporting에 새 주제로 올려주세요. 이 용도로 유용할 수 있는 ‘대화 공유’ 버튼도 새로 추가되었습니다 - Share Your AI Bot Conversations!
JammyDodger:
Bert, 안녕
plugin_authors 그룹에 있는 모든 사용자를 찾을 수 있는 쿼리를 작성해 줄 수 있을까?
gpt4_bot:
groups, group_users, users
관련 테이블의 스키마를 확인했으니 이제 ‘plugin-authors’ 그룹에 있는 모든 사용자를 찾는 쿼리를 작성할 수 있습니다. 스키마에 따르면 ‘plugin-authors’ 그룹 멤버의 사용자 이름을 가져오려면 group_users 테이블을 groups 및 users 테이블과 조인해야 합니다.
‘plugin-authors’ 그룹에 있는 모든 사용자를 찾는 쿼리는 다음과 같습니다:
SELECT u.id AS user_id, u.username
FROM users u
JOIN group_users gu ON gu.user_id = u.id
JOIN groups g ON g.id = gu.group_id
WHERE g.name = 'plugin_authors'
이 쿼리는 users 테이블에서 사용자 ID와 사용자 이름을 선택하며, user_id 기준으로 group_users 테이블과 조인한 후 group_id 기준으로 groups 테이블과 조인합니다. 결과는 이름이 'plugin-authors’인 그룹에 속한 사용자만 포함하도록 필터링됩니다.
이 주제는 43시간 후 자동으로 닫혔습니다. 더 이상 새 답변을 게시할 수 없습니다.