之前我的一篇文章里提到的使用 RagFlow 知识库配置+Agent 结合的模式，实现简单的 Text2SQL。
后台很多小伙伴留言，按照文章提到的方法，进行 Agent 搭建时，遇到了各种各样的问题。我把问题类型做了一些整理，并且总结对应的优化方法。
首先，我们先来看一下，影响 Text2SQL 成功的几大因素。再逐一分析在 RagFlow 框架中的解决方案。
我把整体流程简单画了一下：
简单来说，从提问到 SQL 成功执行，有这些优化方法：
0、拆解问题。有些问题一个 SQL 就能搞定，但是有些问题，得分成多个 SQL 去完成。
1、确定要写几个 SQL 后，大模型得知道去找哪些表。单表比较简单，但是涉及到多表，就得搞定表关联问题。
2、定位到表，还得知道去找哪个字段；
3、写对 SQL 代码。
接下来，分开一个个聊，各自的策略应该是怎样的。
一、拆解问题：复杂查询的SQL分步生成策略
在Text2SQL任务中，很多时候，一条 SQL 是没办法直接搞定的。约38%的复杂查询需要拆解为多步SQL执行。
例如用户提问“统计华东地区销售额TOP10客户过去三个月的复购率”，实际需要拆解为：
1. 查询客户近90天订单明细 2. 计算每位客户总销售额 3. 筛选华东地区TOP10客户 4. 关联历史订单计算复购周期
在RAGFlow中，可以这么解决：
- Agent任务编排：通过内置工作流引擎自动拆解多步查询，每个子任务生成独立SQL
- 上下文继承机制：将前序查询结果作为后续SQL的临时表，例如将步骤1的中间表tmp_order_detail传递给步骤2使用
二、表定位：数据库模式理解的三大武器
实际的 Text2SQL 中，最难的部分，在于让模型理解复杂的业务分析场景。那么，如何增强模型对于对业务背景知识的理解，如业务模型间的关联关系等。
在RAGFlow通过四重知识库解决业务理解和表定位难题：
1. DSL知识库 存储精确表结构定义，例如商品表的字段注释。模型通过字段语义匹配识别目标表。
DSL 知识库举例：
用户表（users）
用户表用于存储网站或应用的用户信息。以下是该表中每个字段的含义：
- `id`: 这是一个整数类型的自增字段，作为用户的唯一标识符（主键）。每次添加新用户时，该字段会自动增加，确保每个用户都有一个唯一的ID。
- `username`: 字符串类型，用于存储用户的用户名。用户名通常是用户登录时使用的唯一标识符。
- `password`: 字符串类型，用于存储用户的密码。出于安全考虑，密码在存储前应进行加密处理。
- `email`: 字符串类型，用于存储用户的电子邮件地址。电子邮件地址可以是用户的另一个登录凭证，并且用于接收通知或重置密码。
- `mobile`: 字符串类型，用于存储用户的手机号码。手机号码可用于登录、接收短信通知或进行身份验证。
- `create_time`: 时间戳类型，记录用户账户创建的时间。默认值为当前时间。
- `update_time`: 时间戳类型，记录用户信息最后更新的时间。每次更新用户信息时，该字段都会自动更新为当前时间。2. Q->SQL样本库 相当于给模型 Few-shot，包含典型问题-SQL映射，相似问题触发快速匹配。如：
问："查手机库存" →
SQL:SELECT stock FROM products WHERE name LIKE '%手机%'
3. 业务描述知识库 定义表关联关系，例如：
{"商品表": {"关联表": ["库存表", "销售表"，"计划表"], "外键": "product_id"}}当用户查询"华为手机的周销量和计划完成进度时，自动关联商品表、销售表和计划表。
三、字段定位：语义理解的两层保障
通过RAGFlow，可以采用两种组合策略提升字段匹配精度：
1. 数据类型校验：通过DDL约束过滤无效字段，例如金额字段不会出现字符串比较。
DDL 知识库举例：
CREATE TABLE `products` (
`id` INT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(100) NOT NULL,
`description` TEXT,
`price` DECIMAL(10, 2) NOT NULL,
`stock` INT NOT NULL,
`category_id` INT,
`merchant_id` INT NOT NULL,
`create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
FOREIGN KEY (`merchant_id`) REFERENCES `merchants` (`id`)
)2. 管理特定领域的同义词
一些行业专有术语在大模型的预训练数据集里并没有。增加专有名词知识库，可以让模型快速的反应，并且快速识别到准确的数据字段。
专业的领域同义词可以极大地影响 SQL 查询条件的生成。因此，维护一个广泛且最新的同义词库对于缓解这一挑战至关重要。
在业务知识库预置同义词映射关系，如：
{"库存": ["stock", "库存量", "现货数"]，
"批售": ["wholesale", "批发销售量", "批发量"],
"终端": ["terminal", "终端销售量", "零售量"]}四、SQL生成：工业级代码质量的保障体系
RAGFlow中Text2SQL具备自动反思迭代的能力，相关功能集成在官方插件 ExeSQL 内。
针对用户的问题，如果大语言模型生成的SQL查询成功则会直接将结果进行返回。
在配置这个插件的参数时，需要留意Loop参数，Loop 参数设置的是大模型的 SQL 代码执行错误后重试的次数。
如果大语言模型生成的SQL查询失败，则RAGFlow Text2SQL工作流，配置针对数据库查询返回的错误信息和SQL语句进行自动更正进行再次查询。我所使用的 RagFlow v0.17.1版本中，ExeSQL 插件已经内置自动重写 SQL功能。
对应的，我们可以在其开源的代码exesql.py 文件中，看这段代码。
这个插件配置项中的信息输入和大模型，就是用来做SQL 代码功能重写的。
该过程(查询失败->更正SQL语句->再次查询)最大迭代次数则为Loop参数的值，如果迭代次数超过Loop值，查询结果仍然失败，则程序自动结束过程。
我们需要再针对错误类型优化用户问题或知识库数据后，再次做尝试。
五、持续优化：构建闭环学习系统
在系统上线后，还可以通过RAGFlow的运营优化，持续增强，方法包含：
1. 错误SQL回收：将执行失败的SQL存入待审核库，人工修正后反哺训练 2. 热点分析：统计高频访问表字段，动态调整知识库优先级 3. 版本追溯：记录每次SQL生成参数，便于AB测试不同策略效果
六、延伸思考：Text2SQL的未来优化方式
1. 混合执行模式：当前未经训练的大模型直出的 SQL只能满足简单场景的查询。当用户的问题涉及复杂场景的时候，或者需要进行数据分析报告，可以考虑将复杂场景转Python计算。 2. 可视化解释：生成SQL执行流程图，帮助用户理解数据加工逻辑。 3. 权限融合：结合RBAC模型，将查询者的用户账号和权限记录带入查询参数，动态生成带权限过滤的SQL条件
