Discourse AI + 데이터 탐색기?

기여 기능
, , ,
31

그 방법을 시도해 보았습니다. 결과는 제각각입니다. GPT-3.5에 Discourse 데이터베이스 스키마의 최소 주석 버전만 제공하여 SQL 처리 능력을 테스트하는 것은 흥미로운 실험이 될 것입니다. 이는 토큰 측면에서 비효율적이라는 점을 인지하고 있지만, 가독성은 좋습니다:

최소 스키마 
# == Schema Information
#
# Table name: users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# Table name: groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# Table name: group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# Table name: posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (애플리케이션은 게시물을 "소프트 삭제"합니다. 게시물이 삭제되면 `deleted_at` 속성이 :datetime으로 설정됩니다. 삭제된 게시물을 반환하도록 명시적으로 요청하지 않는 한, 게시물 관련 데이터를 조회하는 쿼리를 작성할 때 `deleted_at` 컬럼이 `NOT NULL`인지 확인하십시오.)
#
# Table name: topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (토픽을 생성한 사용자의 id)
#  deleted_at                :datetime         (애플리케이션은 토픽을 "소프트 삭제"합니다. 토픽이 삭제되면 `deleted_at` 속성이 :datetime으로 설정됩니다. 삭제된 토픽을 반환하도록 명시적으로 요청하지 않는 한, 토픽 관련 데이터를 조회하는 쿼리를 작성할 때 `deleted_at` 컬럼이 `NOT NULL`인지 확인하십시오.)
#
# Table name: categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

지금까지 얻은 결과는 인상적입니다. 이는 프롬프트에 주석이 달린 스키마만 제공하면 문제를 해결할 수 있다는 생각으로 이어집니다.

재미로, GPT-3.5가 어떤 종류의 쿼리에서 어려움을 겪을지 예상하는지 물어보았습니다:

GPT-3.5의 한계
  1. 계층적 쿼리: 재귀적 관계와 같은 계층적 데이터 구조를 포함하는 쿼리는 복잡할 수 있습니다. 예를 들어, 카테고리 계층 구조 내의 부모-자식 관계를 조회하는 경우입니다.
  2. 시간 기반 쿼리: 과거 추세를 계산하거나 특정 시간 간격에 걸쳐 데이터를 분석하는 등 시간 기반 데이터를 포함하는 쿼리는 더 정교한 SQL 구조가 필요할 수 있습니다.
  3. 윈도우 함수: 이전 쿼리에서 윈도우 함수를 사용했지만, 복잡한 분석 작업을 위한 더 고급 윈도우 함수 사용은 어려울 수 있습니다.
  4. 지리 공간 쿼리: 공간 데이터베이스와 지리적 데이터 기반 쿼리(예: 근처 위치 찾기 또는 복잡한 공간 관계)는 복잡할 수 있습니다.
  5. 복잡한 집계: 여러 수준의 그룹화와 계산을 포함하는 고급 집체는 더 정교한 SQL 지식이 필요할 수 있습니다.
  6. 최적화 쿼리: 인덱스, 쿼리 튜닝 및 성능 향상을 포함하는 altamente 최적화된 쿼리를 작성하는 것은 복잡할 수 있습니다.
  7. 사용자 정의 알고리즘: SQL 쿼리 내에서 사용자 정의 알고리즘이나 로직을 구현하는 것은 포함된 로직의 복잡성 때문에 어려울 수 있습니다.
  8. 고급 JOIN: 복잡한 조인 조건 또는 여러 조인의 결합은 신중한 고려와 더 복잡한 SQL 구조가 필요할 수 있습니다.
  9. 서브쿼리와 상관 서브쿼리: 서브쿼리를 처리할 수 있지만, 극도로 복잡하거나 깊게 중첩된 서브쿼리는 더 어려울 수 있습니다.
  10. 피벗과 언피벗: 데이터를 넓은 형식과 긴 형식 간에 변환하는 것(피벗과 언피벗)은 특정 시나리오에서 복잡해질 수 있습니다.

제가 문제를 겪고 있는 부분은 전체 데이터베이스 스키마의 모호성을 제거하는 것입니다. 예를 들어, user_actions 테이블에 주석을 달기 위한 방법을 찾는 것 등이 있습니다. 단순히 action_type 코드의 정의만 제공하기에는 부족합니다. 모델은 user_id, target_user_id, acting_user_id에 대해 추측을 시작합니다.

가장 자주 요청되는 쿼리는 데이터베이스의 대부분의 테이블과 컬럼을 사용하지 않습니다. Data Explorer에 AI가 추가된다면, “기본” 모드와 “고급” 모드를 제공하는 것을 살펴볼 가치가 있을 수 있습니다. 기본 모드에서는 대부분의 사용 사례를 커버하는 프롬프트를 제공할 수 있습니다. 고급 모드에서는 사용자가 프롬프트에 설정할 정보를 선택할 수 있게 할 수 있습니다.

meta에서 쿼리에 대한 몇 가지 요청을 거꾸로 추적하여, GPT-3.5가 쿼리를 성공적으로 생성하기 위해 프롬프트에 무엇을 제공해야 하는지 살펴보는 것도 흥미로울 것입니다.

3개의 좋아요