gptsql

数据库的LLM聊天界面。此工具理解Postgres语法，可以轻松地将英语查询翻译成正确的SQL查询。由于LLM模型的广泛训练，它还可以推断有关您表和数据的结构和含义的相关信息。通过Assistant API使用Open AI模型。

有很多工具可以实现“与您的数据聊天”（大多基于RAG架构），但这实际上是最快实现LLM与您的数据聊天的方式——无需任何准备。

以下是一个快速演示，展示了关于IMDB电影数据库的自然语言查询。您甚至可以看到助理遇到SQL错误，然后自行纠正

https://github.com/tatari-tv/gptsql/assets/80947/7e946bdd-1ed9-4a03-9dc1-aca8d3a44926

安装

您需要

1. 数据库凭据
2. 从您的OpenAI账户获取的API密钥。

然后

pip install gptsql

或下载源代码。

使用以下命令运行CLI

gptsql

或使用python -m gptsql从源运行。

它能做什么？

Open AI模型理解大多数Postgres语法，因此它可以生成通用SQL命令以及非常具体的Postgres SQL命令，如查询系统设置。

LLM还擅长分析表，理解它们可能用于什么，以及推断表之间的关系。它在不明确指令的情况下编写表连接也非常出色。

它可以编写查询以分组和总结结果。

借助助理API，它还可以编写多步查询并合并查询结果。它还在维护聊天历史，因此您可以轻松提出后续问题，例如“现在按月份总结”，这些问题会引用先前的查询。

目前该工具仅限于SELECT查询，不允许突变操作（但请参阅安全性部分的详细信息）。

聊天示例

% gptsql

Welcome to GPTSQL, the chat interface to your Postgres database.
        
> show me the available schemas
⠋ thinking...  Running select query: SELECT schema_name FROM information_schema.schemata ORDER BY schema_name;
[assistant] --> The available schemas in the database are:

1. information_schema
2. pg_catalog
3. pg_toast
4. public

显示匹配字符串的表

> show all tables that have "sales" in the name
⠴ thinking...  Running select query: SELECT table_name FROM information_schema.tables WHERE table_name LIKE '%%sales%%' ORDER BY table_name;
[assistant] --> The tables with 'sales' in the name are as follows:

- salesorderdetail
- salesorderheader
- salesorderheadersalesreason
- salesperson
- salespersonquotahistory
- salesreason
- salestaxrate
- salesterritory
- salesterritoryhistory
- vsalesperson
- vsalespersonsalesbyfiscalyears
- vsalespersonsalesbyfiscalyearsdata

列出表的列

> show the columns of the salesorderheader table
⠹ thinking...  Running select query: SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'salesorderheader' ORDER BY ordinal_position;
[assistant] --> The columns of the `salesorderheader` table along with their data types are as follows:

- `salesorderid` (integer)
- `revisionnumber` (smallint)
- `orderdate` (timestamp without time zone)
- `duedate` (timestamp without time zone)
- `shipdate` (timestamp without time zone)
- `status` (smallint)
- `subtotal` (numeric)
- `taxamt` (numeric)
- `freight` (numeric)
- `totaldue` (numeric)
- `comment` (character varying)
- `rowguid` (uuid)
- `modifieddate` (timestamp without time zone)

对表运行计算

> calculate the sum of the totaldue column by month
⠇ thinking...  Running select query: SELECT DATE_TRUNC('month', orderdate) AS month, SUM(totaldue) AS total_sales FROM sales.salesorderheader GROUP BY month ORDER BY month;
[assistant] --> Here are the sums of the `totaldue` column by month:

Month               Total Sales
-------------------------------------
2011-05-01          567,020.95
2011-06-01          507,096.47
2011-07-01        2,292,182.88
2011-08-01        2,800,576.17
2011-09-01          554,791.61
2014-02-01        1,478,213.29
2014-03-01        8,097,036.31
2014-04-01        1,985,886.15
2014-05-01        6,006,183.21
2014-06-01           54,151.48
These figures represent the total sales for each month.

从表中查询数据

> show me the names of the stores
⠹ thinking...  Running select query: SELECT name FROM sales.store;
> print the results
⠧ thinking...LAST QUERY RESULTS:
⠇ thinking...                                    name
0                   Next-Door Bike Store
1         Professional Sales and Service
2                         Riders Company
3                     The Bike Mechanics
4                      Nationwide Supply
5                  Area Bike Accessories
6           Bicycle Accessories and Kits
7                  Clamps & Brackets Co.
8             Valley Bicycle Specialists
9                      New Bikes Company
10   Vinyl and Plastic Goods Corporation
11                 Top of the Line Bikes
12                    Fun Toys and Bikes
13                          Great Bikes 
14         Metropolitan Sales and Rental
15                     Irregulars Outlet
16                      Valley Toy Store
17             Worthwhile Activity Store

解释你的数据

> what is the purpose of the salespersonquotahistory table?
[assistant] --> The purpose of the `salespersonquotahistory` table is typically to maintain a record of the sales quota assigned to each salesperson over time. The table likely includes columns for:

- Identifying the salesperson, which may reference a `businessentityid` or similar key that links to another table containing salesperson details.
- The sales quota amount, which indicates the target sales figure the salesperson is expected to meet for a given period.
- Date fields, which may specify the period or specific dates for the quota.
- Any changes or historical adjustments made to the quota over time.

It serves as a historical log that can be used for performance tracking, compensation calculation, sales management, and analysis. The exact columns and usage may vary depending on the specific design of the database. If you have access to the table structure, you can review the columns to understand more about the data it holds. Would you like me to retrieve the columns of the `salespersonquotahistory` table to provide more detailed information?

轻松运行自定义Postgres SQL

> show the top 10 tables by size on disk
⠸ thinking...  Running select query: SELECT table_schema || '.' || table_name AS full_table_name,
pg_total_relation_size('"' || table_schema || '"."' || table_name || '"') AS size_on_disk
FROM information_schema.tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY size_on_disk DESC
LIMIT 10;
[assistant] --> The top 10 tables by size on disk are as follows:

1. `sales.salesorderdetail`: 15,073,280 bytes
2. `person.person`: 14,688,256 bytes
3. `production.transactionhistory`: 11,304,960 bytes
4. `production.workorderrouting`: 9,355,264 bytes
5. `production.transactionhistoryarchive`: 8,896,512 bytes
6. `production.workorder`: 7,823,360 bytes
7. `sales.salesorderheader`: 6,676,480 bytes
8. `production.productphoto`: 4,431,872 bytes
9. `person.address`: 3,522,560 bytes
10. `person.password`: 2,842,624 bytes

These sizes are in bytes, and the tables are listed in decreasing order of their size on disk.

配置

您可以使用psql风格的命令行参数或环境变量DBHOST、DBNAME、DBUSER、DBPASSWORD、DBPORT来配置数据库连接。

否则，当您第一次运行程序时，它将提示您输入连接凭据以及您的OpenAI API密钥。

首次设置后，所有配置信息都存储在~/.gptsql中。如果您想重新开始，请删除该文件。

工作原理

gptsql使用OpenAI的助手API创建一个智能助手来与您的数据库一起工作。访问数据库的关键是向助手提供一个名为tool的函数。令人惊讶的是，只需要一个函数

        {
            "type": "function",
            "function": {
                "name": "run_sql_command",
                "description": "Execute any SQL command against the Postgres datbase",
            }
        }

当请求时，LLM自动生成正确的SQL并调用此函数来执行它。然后，将查询结果返回到助手，助手可以决定打印或总结结果。

如果LLM需要了解您的表，它将仅对information schema执行SQL命令以提取它。

由于表引用非常常见，我们通过预先将表列表注入LLM提示中来帮助助手。

由于LLM上下文限制，您可能无法始终看到查询返回的所有行。因此，我们提供了一个第二个函数工具show_query_results，可以打印最后查询产生的最多200行结果。有时助手足够聪明，可以自行调用此函数，但有时您可能需要请求“打印结果”才能看到所有结果行。

命令参考

支持一些系统命令用于元操作

help - 显示系统命令

connection - 显示当前的数据库连接详情和活动的LLM模型

history - 打印助手的消息历史记录

new thread - 开始一个新的线程（清除任何现有的对话上下文）

exit或ctrl-d退出

如果您想更改LLM模型，可以通过OpenAI网页门户编辑助手。

安全性

请不要在生产数据库上运行此操作！并且请确保您有数据的备份。尽管如此，查询函数有一个简单的保护器，它将拒绝运行不以SELECT开头的任何查询。请注意，这并不是万无一失的。如果您正确请求，LLM很可能构建一个破坏性查询来绕过这个简单的检查。因此，不要完全依赖这个来保证安全性。我强烈建议仅使用只读数据库连接。

此外，请注意，此工具会将您的数据发送到OpenAI。查询结果会被发送回助手API进行处理。请自行决定是否接受这一点。

限制

最大的限制是LLM非常慢。在我的测试中，它可能需要20-30秒的“思考”时间才能响应。其中一个原因是LLM在您提出问题时会运行一次，然后再次运行以处理从函数返回的任何结果。

同样，助手API也会运行多个“步骤”来处理您的问题，即使在这个过程中我们没有得到很多反馈。

还有一点：这个工具很贵 :): 我只做开发就花掉了大约100美元。如果您想降低成本，建议坚持使用GPT3模型。