Text2SQL

第一层：最底层（核心引擎）—— 确实是大模型
无论用什么工具，最终生成SQL这个“翻译”动作，必须由大模型（LLM）完成。因为只有大模型具备理解自然语言（中文/英文）和生成代码（SQL）的泛化能力。

早期用BERT微调，现在几乎统一换成 GPT-4、Claude、Qwen 等基座模型。

如果没有大模型，这个任务就退化成“关键词匹配”，根本听不懂“去年黑五期间销售额前三的品牌”这种复杂逻辑。

第二层：中间层（关键差异）—— RAG（检索增强生成）
这是决定Text-to-SQL好不好用的分水岭。现实中的数据库表结构极其复杂（几百张表，字段名是拼音缩写，枚举值存的是数字）。如果直接把问题发给大模型，它会“瞎猜”字段名，准确率可能不到30%。

因此，成熟的Text-to-SQL流程一定是：

先把库表结构（Schema）、字段注释、外键关系、枚举值含义向量化，存进向量库。

用户提问时，先检索出相关的3-5张表和字段示例。

把这些“元数据”作为上下文（Prompt），塞给大模型。

这一步（RAG）本质上不是大模型，而是传统的检索和工程策略，但它决定了80%的效果。

第三层：最上层（安全防护）—— 规则与校验
生成SQL之后，还不能直接执行。这一层全是传统代码：

权限校验：判断用户是否有权查询这张表。

SQL语法校验：用解析器（如sqlparse）检查语法，防止大模型生成“幻觉”字段。

安全拦截（SQL注入）：限制只能执行SELECT，禁止DROP/UPDATE。

结果重写：如果大模型生成的SQL跑出来数据为空，工程代码会触发“自动修正”机制，换一种检索策略再问一次。