在表结构比较复杂、字段较多的时候总是容易漏字段，目前的方案是加一层模板匹配，预先设计好一部分模板，然后先和模板做一次相似度匹配，找到相似度较高的模板，再在模板的基础上让 LLM 去修改 where 条件
目前的问题有 2 个：
匹配到的模板不准确，比如我问一个 a 业务有关的问题，然后相似度匹配到了一个意思相近的 b 业务上，这个时候 LLM 就很难基于 b 业务的模板去生成正确的 sql ，有时候甚至语法上都会出问题。
老是漏条件，比如我已经指明了要查询『已解决』的记录，LLM 总是会漏掉这种查询条件，但是系统明明已经在组装提示词的时候把表结构给他了
 |
1
fgwmlhdkkkw 2 days ago
让 agent 分部生成。
1：让他根据需求列出需要的表 2：让他根据需求列出需要的列 3：让他生成 sql （这里甚至可以让他主动来拆分子查询） 4：使用 sql parse 验证语法正确和 1 ，2 的共识 这样依然不能保证正确，但是概率会提示一些。 |
 |
2
lancevps 2 days ago
记得以前的模型可以用提示词双写来提高准确率
|
 |
3
novojo 2 days ago
用 DBVibe ，有生成 SQL 的工具，Agent 会调用 skills ，自动连接到数据库获取模式，表结构，字段信息进行分析，能生成准确的 SQL
|
 |
4
DaXiGa 2 days ago
需要交代清楚表结构，字段最好注释清楚，比如你要查询的『已解决』的状态使用的值是什么，可以参考下我这个项目 https://github.com/peisp/catdb
|
 |
5
PolarBears 2 days ago
如果有业务系统的代码的话，不妨把代码交给 AI 读让他理解？
|
 |
6
billzhuang 2 days ago
可验证
|
 |
7
laminux29 2 days ago
提升不了。这和文档场景是一样的，命中了目前 AI 的短板：上下文窗口容量。
|
 |
8
OctopusGO 2 days ago
先生成对应的表的关联关系
|
 |
9
fankangsong 2 days ago
大模型的产出 SQL 质量，取决于你喂入的上下文质量。自然语言生成 SQL 要背靠大模型对你业务的理解、指标的理解。
|
 |
10
NemoAlex 2 days ago
关键是让它理解业务。
可以直接让模型把项目的后端代码库作为资料库。例如用 CodeX ，直接在你的项目仓库里提问。 推荐用我做的开源工具： https://github.com/NemoAlex/SQLTunnel 使用方法： https://github.com/NemoAlex/SQLTunnel/blob/main/docs/readme/zh-CN/codex.md |
|
11
NemoAlex 2 days ago
@NemoAlex 忘记问你是方便自己用，还是给用户提供一个对话式的数据库查询功能。
如果是给用户用，那么最好使用现成的方案，例如 Dify 提供的知识库+对话解决方案。关键是建立知识库，以及对知识库的召回进行调优。 如果是自己用，那么我刚才说的方法就挺好的。 |
 |
12
yidinghe PRO 自然语言的模糊性是天生的，我会直接说 “在 A 库的 B 表中找 status 为已解决的记录”。
|
 |
13
yinmin 2 days ago via iPhone
我是从数据库服务器导出表结构的 create table sql 文件放在项目文档目录里，然后把 sql 文件路径、字段说明贴在聊天框里发给 glm5.2 ，让 glm5.2 写数据库文档。
大概有 20 多个 table ，之后用 glm5.2 或者 gork 4.5 写 sql 基本没错过。关键：写 sql 要用一线 ai 模型（ gpt 5.6 terra 、glm5.2 、grok4.5 这个级别） |
 |
14
lianyue 2 days ago
生成 后交给最少三个不同 3 个模型(2 家不同企业模型)验证结果
不对再生成 直到全对为止 |
 |
16
getadoggie 1 day ago via iPhone
加一层程序，做语法之类的检查？
|
Select Language