RAG增效SQL语句生成，开启大模型做数据查询新思路，本地Qwen2-7b模型也能又快又准
介绍如何通过RAG技术辅助大模型生成SQL语句，利用向量数据库检索相似案例提升查询准确度并支持人工修正。
UP主: 偷星九月333 · 时长: 23:20 · 🔗 B站原视频
发布: 2024-08-17 · 收录: 2024-09-05
标签: RAG · Text-to-SQL · 大模型 · 数据查询 · Qwen2
开场：大模型做数据查询的两种方式
哈喽小伙伴们，好久不见。最近在做大模型数据查询这一块的工作。
目前大模型做数据查询主要就两种方式：
- 一种是通过 Python 代码去查询。
- 另一种是通过 SQL 语句去查询。
这两种方式本质上都是借助大模型的能力：根据用户提出的问题做意图识别，生成相应的 Python 代码，或者生成相应的 SQL 语句。
Python 代码主要面向运行一个 cell，还有 CSV 这种表格型的数据；SQL 语句就是面向数据库做查询。不管你用 Python 代码还是 SQL 语句，其实都比较吃大模型本身的能力。
现有框架体验：DB-GPT 和 PandasAI 的差异
现在用大模型做数据查询有很多现成框架，比如 DB-GPT、PandasAI。这俩我也试过。
DB-GPT 我个人感觉对大模型能力要求挺高的，而且里面没有纠正机制：你生成 SQL 语句如果一次没生成成功，它就回答不出来了，没有纠错流程。
PandasAI 里有一个自纠错机制：大模型生成 SQL 或 Python 代码后先执行，如果执行不成功，它会把报错信息返回给大模型，让大模型重新生成，直到达到最大迭代次数或者能返回结果再终止。它引入了一定的纠错方法，所以生成正确率会更高一点，但还是比较考验模型能力。
今天的核心思路：RAG 增效 SQL 生成
今天要介绍的方法思路很棒：也是通过 SQL 去做查询，但在 SQL 的基础上增加了现在很火的 RAG（检索增强生成），也就是增加检索这一块。
整体流程大概是这样：
-
准备一些“训练数据”（不是真正意义上的训练）：
- 数据库建表语句
- 针对具体业务的问题和对应的 SQL
- 和业务相关的文档说明
把这些存到向量数据库里。
-
对于给定问题，先去向量数据库做相似度搜索，返回和问题相似的 SQL、文档等。
-
用检索到的内容构建提示词，让大模型在这个提示词基础上生成 SQL。
-
大模型生成 SQL 后去数据库查询，把结果给用户判断是否正确：
- 如果正确：把这条 SQL 和对应问题存回向量数据库，作为新的数据沉淀。
- 如果不正确：用户修正后再存回去。
随着问答次数累积，向量库里案例越来越多，后续遇到相同或相似问题时，生成 SQL 的准确度就会越来越高。第一次结果不理想也没关系，修正后存进去，下次就会更准。
项目演示：Vanna + SQLite3 快速跑通
下面通过代码和可视化界面体验一下这个项目，叫 Vanna。
我这里找了一个 CSV 文件，大概是电视节目的数据，有类型（连续剧、体育等）、语言、题材（戏剧、喜剧等）、播放时长、发布时间、评分等。
我把这个 CSV 存到数据库里。这里就不用 MySQL 了，部署起来比较麻烦，直接用 SQLite3。SQLite3 是把数据存到一个文件里，也可以用 SQL 查询。
- 我们把数据存到一个临时库里，表名叫
TV。 - 大约存了 48000 条数据。
- 然后把建表语句拿出来，等会作为训练数据之一。
启动与配置：本地大模型参数
Vanna 的启动代码很简单，几行就够了：
- 配置本地大模型的 Base URL 和 API Key。
- 模型参数包括温度系数、模型名等。
做 SQL 生成时，温度系数一般不要调太低，让模型输出更有多样性。有些情况下生成的 SQL 可能执行不成功，可以让它再生成一次，可能就对了。
执行后会创建一个 Vanna 项目，连接到前面建好的 SQLite 数据库。
训练这里也不是真训练，就是把建表语句传进去；后面也可以加“问题 + 对应 SQL”。我这里先只加建表语句。
此外，很多操作也可以直接在等会的可视化界面完成，不一定非要在代码里加训练数据。
可视化界面体验：简单问题直接命中
启动服务后进入界面。
先问个简单问题：表中有多少数据。这个没难度，能直接查出来。
再查“所有数据”。也没难度，不过界面默认只显示 10 条；如果想看完整数据，可以下载。
界面还能生成一些可视化图表。
还有个参数 Allow LLM to see data（大概意思），打开后它会对查询结果做语言描述。
例子：SQL 大小写错误与人工修正回写
问一个稍微难一点的问题：评分超过 0.8 的英语节目。
它第一次没查出来，因为 SQL 写错了：它生成的是 Language = 'Enger'（或者类似），但实际数据里语言字段是小写的，所以匹配不上。
这时候可以点 No，进行修正：
- 方法一：把 SQL 里的语言改成小写，再运行，就能出结果。
- 方法二：把修正后的这条结果加入训练数据。
加入之后再问相同的问题，就没问题了，生成的 SQL 里语言就会变成小写。
例子：新增业务定义（“热点节目”）让模型理解专有名词
再问：2018 年有多少节目，这个也没啥问题。
然后问：热点节目有哪些。
它回答错了，因为它不知道“热点节目”是什么意思。这个时候我们可以在训练数据里加一条文档说明，比如：
- “热点节目 = 评分超过 0.9 的节目”
保存后再问同样的问题“热点节目有哪些”，它就能回答出来了。
从它生成的 SQL 看，至少它理解了“热点节目”代表评分 > 0.9。虽然它可能第一次选错字段（比如选了题材而不是具体节目），但方向已经对了。
如果业务里有一些专有名词，数据库字段里并不存在，模型也不知道这个名词代表什么，就很难生成正确 SQL。把名词解释放到训练数据里，检索时就能把相关说明拿出来，模型基于这些内容就能理解并生成正确语句。
继续修正：把查询字段改成节目 ID，迭代变准
刚才“热点节目有哪些”它返回的是题材，不是具体节目。那就继续修正：
- 把 SQL 改成选择节目 ID（或者你想要的具体字段）。
- 运行后得到正确的热点节目列表。
- 再把这条正确 SQL 存到训练数据。
再问同一个问题“热点节目有哪些”，它就能直接给出正确答案。
这个项目的一个很大优点是：起始准确度可能没你想象那么高，但随着你不断迭代、沉淀正确数据，它后续回答的准确率会越来越高，而且给了你比较方便的修正入口。
总结：7B 本地模型也能跑出不错效果
这份演示数据字段不多、含义也简单；但在实际项目里，字段可能几十个，定义也没那么明确。用这种“检索 + 生成 + 修正回写”的方式，不断调整依然能达到很高的准确度。
我个人感觉这个项目挺值得用的。对比市面上一些大模型数据查询的项目和框架，这是我用过的最好用的之一。
我本地用的是 7B 的模型（Qwen2-7B），模型不大，但效果依然保持得很好。
今天视频先到这里，喜欢的小伙伴可以一键三连、点个关注，也欢迎在评论区留言讨论。拜拜。