一次 Text-to-SQL 系统的深度优化实践

一、痛点：维护成本高、准确率低

1.1 数据化的痛点

在我们的 ChatBI 智能问答系统上线了一段时间。在运营阶段，遇到了三个费时费力的核心问题：

问题1：海量别名维护成本极高

问题2：用户表达多样化导致准确率低

问题3：扩展性差

1.2 量化的业务影响

二、效果：准确率提升至 95%，维护成本降低 90%

项目组大概用了 1 个月的时间，参考了行业诸多 N2SQL 类产品的解题思路。

在 dify 系统上，通过巧妙的 别名配置知识库优化+代码提取 ，实现了 查询准确性提升 和 维护难度降低 以及 响应时间缩短的多项指标成果。

2.1 核心指标对比

2.2 实际测试结果

测试规模：100+ 测试用例

测试结果：

三、解决方案思路总览

3.1 核心理念：三层混合架构

我们采用了 "不穷举、分层处理、智能匹配" 的设计理念：

**用户问题**
    ↓
【第一层】Prompt 约定（10-20 个核心高频词）
    ↓ 100% 准确，零延迟
【第二层】RAG 知识库检索（中低频+长尾情况解决）
    ↓ 语义理解，自动召回
    ↓ 无需穷举，自动处理
标准化问题 → SQL 生成

3.2 技术架构

四、分步解决方案

步骤 1：构建实体别名知识库

1.1 按表分文件策略

我们为每个数据表创建独立的别名知识库文件：

为什么按表分文件？

文件结构：

### 集团：比亚迪汽车
**标准查询名**：比亚迪汽车 
**常见别名**：比亚迪、BYD、byd、迪子 
**所属表**：行业表 
**字段名**：group_name

1.2 知识库配置

在 Dify 中创建知识库：

名称：实体别名库_全部
文件：5 个 md 文件（行业表、批发表、终端表、产量表、库存表）
配置：
  检索模式：混合检索
  权重设置：语义 0.7，关键词 0.3
  Top K：3

关键配置说明：

步骤 2：构建实体链接处理器（30 分钟）

2.1 知识检索节点设计

在 Dify 工作流中添加知识检索节点：

2.2 RAG 实体解析（代码节点）

输入变量 arg1 ：选择上一个节点输出的检索结果。

代码区域输入如下代码：

def main(arg1: dict) -> dict:
    return {
        "result": [item["content"] for item in arg1]
    }

输出变量：result，变量类型选择 Array [String]

步骤 3：修改 AI 生成 SQL 节点（15 分钟）

3.1 简化 Prompt

删除内容（约 2500 字）：

# 二、组织和别名
- **一汽集团**（又名 一汽、一汽汽车）
- **长安汽车**（又名 长安）
- **东风**（又名 东风集团）
- **长城**（又名 长城汽车）
- **悦达**（又名 悦达集团）
- **零跑汽车**（又名 零跑）
- **福特**（又名 福特汽车）
- **小鹏汽车**（又名 小鹏）
- **小米汽车**（又名 小米）
- **蔚来汽车**（又名 蔚来）
- **比亚迪**（又名 比亚迪汽车）
- **上汽**（又名 上汽集团）
- **吉利**（又名 吉利汽车）
（删除所有硬编码的别名定义）

保留内容：

# 黄金准则 0-5（核心 SQL 生成规则）
# 一、核心指标说明
# 三、报表和字段说明（DDL）

3.2 修改知识检索

修改为：

{{#提取标准查询信息.result#}}

效果：

五、意义和价值

技术价值

1. 架构创新

2. 可扩展性

3. 可复用性

六、后续优化方向

6.1 短期优化（1-3 个月）

1. 自动化补充

2. 跨表关联优化

3. 多模态支持

4. 智能推荐

5. 知识图谱集成

七、总结

核心经验

附录：技术栈

如果这篇文章对您有帮助，欢迎点赞、转发、收藏！

有任何问题或建议，欢迎在评论区交流讨论。