Discourse AI + Data Explorer？

功能
, , ,
31

我试过了。结果参差不齐。一个有趣的实验是为 GPT-3.5 提供一个最小化的、带注释的 Discourse 数据库模式，以测试其 SQL 能力。我知道这在 token 方面效率不高，但它可读性强：

最小模式 
# == 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 限制
  1. 分层查询: 涉及分层数据结构（如递归关系）的查询可能很复杂。例如，在类别层次结构中查询父子关系。
  2. 时间查询: 涉及时间数据的查询，例如计算历史趋势或分析特定时间间隔内的数据，可能需要更复杂的 SQL 结构。
  3. 窗口函数: 虽然我在之前的查询中使用了窗口函数，但窗口函数的更高级用法，用于复杂的分析任务，可能会有挑战性。
  4. 地理空间查询: 空间数据库和基于地理数据（如查找附近位置或复杂空间关系）的查询可能很复杂。
  5. 复杂聚合: 涉及多个分组级别和计算的复杂聚合可能需要更复杂的 SQL 知识。
  6. 优化查询: 编写涉及索引、查询调优和性能改进的高度优化的查询可能很复杂。
  7. 自定义算法: 在 SQL 查询中实现自定义算法或逻辑可能由于所涉及逻辑的复杂性而具有挑战性。
  8. 高级 JOIN: 复杂的连接条件或组合多个连接可能需要仔细考虑，并可能需要更复杂的 SQL 结构。
  9. 子查询和相关子查询: 虽然我可以处理子查询，但极其复杂或深度嵌套的子查询可能更具挑战性。
  10. 透视和反透视: 在某些情况下，在宽格式和高格式之间转换数据（透视和反透视）可能会变得复杂。

我发现问题在于尝试区分完整的数据库模式。例如，找到一种注释 user_actions 表的方法。仅提供其 action_type 代码的定义是不够的。它开始猜测 user_id、target_user_id 和 acting_user_id。

最常请求的查询不使用数据库中的大部分表和列。如果将 AI 添加到 Data Explorer 中，可能值得考虑设置“基本”和“高级”模式。“基本”模式可以提供涵盖大多数用例的提示。“高级”模式允许用户选择在提示中设置哪些信息。

从一些关于元数据的查询请求反向工作，看看需要向提示提供什么才能让 GPT-3.5 成功创建查询，这可能会很有趣。

3 个赞