Discourse AI + Data Explorer?

Lo he intentado. Los resultados están por todas partes. Un experimento interesante es proporcionar a GPT-3.5 una versión anotada mínima del esquema de la base de datos de Discourse solo para probar su capacidad SQL. Me doy cuenta de que esto es ineficiente en términos de tokens, pero es legible:

Esquema mínimo
# == Información del esquema
#
# Nombre de la tabla: users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# Nombre de la tabla: groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# Nombre de la tabla: group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# Nombre de la tabla: posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (La aplicación "elimina suavemente" las publicaciones. Cuando se elimina una publicación, su propiedad `deleted_at` se establece en un :datetime. A menos que se solicite explícitamente la devolución de publicaciones eliminadas, asegúrese de que la columna `deleted_at` sea `NOT NULL` al escribir consultas que soliciten datos relacionados con las publicaciones.)
#
# Nombre de la tabla: topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (el id del usuario que creó el tema)
#  deleted_at                :datetime         (La aplicación "elimina suavemente" los temas. Cuando se elimina un tema, su propiedad `deleted_at` se establece en un :datetime. A menos que se solicite explícitamente la devolución de temas eliminados, asegúrese de que la columna `deleted_at` sea `NOT NULL` al escribir consultas que soliciten datos relacionados con los temas.)
#
# Nombre de la tabla: categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

Hasta ahora, los resultados que estoy obteniendo son impresionantes. Esto me hace pensar que el problema podría resolverse simplemente proporcionando un esquema anotado en el prompt.

Para divertirme, le pregunté qué tipo de consultas podría esperar que le resultaran difíciles:

Limitaciones de GPT-3.5
  1. Consultas Jerárquicas: Las consultas que involucran estructuras de datos jerárquicas, como relaciones recursivas, pueden ser complejas. Por ejemplo, consultar relaciones padre-hijo dentro de una jerarquía de categorías.
  2. Consultas Temporales: Las consultas que involucran datos basados en el tiempo, como el cálculo de tendencias históricas o el análisis de datos durante intervalos de tiempo específicos, pueden requerir construcciones SQL más intrincadas.
  3. Funciones de Ventana: Si bien he utilizado funciones de ventana en consultas anteriores, los usos más avanzados de funciones de ventana para tareas analíticas complejas pueden ser desafiantes.
  4. Consultas Geoespaciales: Las bases de datos espaciales y las consultas basadas en datos geográficos, como la búsqueda de ubicaciones cercanas o relaciones espaciales complejas, pueden ser complejas.
  5. Agregaciones Complejas: Las agregaciones avanzadas que involucran múltiples niveles de agrupación y cálculos pueden requerir un conocimiento SQL más intrincado.
  6. Consultas de Optimización: Escribir consultas altamente optimizadas que involucren índices, ajuste de consultas y mejoras de rendimiento puede ser intrincado.
  7. Algoritmos Personalizados: La implementación de algoritmos o lógica personalizados dentro de una consulta SQL puede ser desafiante debido a la complejidad de la lógica involucrada.
  8. JOINs Avanzados: Las condiciones de unión complejas o la combinación de múltiples uniones pueden requerir una cuidadosa consideración y posiblemente construcciones SQL más complejas.
  9. Subconsultas y Subconsultas Correlacionadas: Si bien puedo manejar subconsultas, las subconsultas extremadamente complejas o anidadas profundamente pueden ser más desafiantes.
  10. Pivoteo y Despivoteo: Transformar datos entre formatos anchos y altos (pivoteo y despivoteo) puede volverse complejo en ciertos escenarios.

Donde encuentro problemas es al intentar desambiguar el esquema completo de la base de datos. Por ejemplo, encontrar una forma de anotar la tabla user_actions. Simplemente proporcionar definiciones de sus códigos de action_type no es suficiente. Empieza a adivinar sobre user_id, target_user_id y acting_user_id.

Las consultas que se solicitan con más frecuencia no utilizan la mayoría de las tablas y columnas de la base de datos. Si se añade IA al Explorador de Datos, podría valer la pena considerar tener modos “básico” y “avanzado”. El modo básico podría proporcionar un prompt que cubra la mayoría de los casos de uso. El modo avanzado permitiría a los usuarios seleccionar qué información se establece en el prompt.

Sería interesante trabajar hacia atrás a partir de algunas solicitudes de consultas sobre metadatos, para ver qué se necesitaría proporcionar al prompt para que GPT-3.5 cree la consulta con éxito.

3 Me gusta