Text-to-SQL 深度学习 Workshop：基于 Amazon Bedrock 的自然语言转 SQL 实践

图1：Text-to-SQL Workshop 概览

一、背景与痛点：为什么 Text-to-SQL 至今仍是难题？

企业数据仓库是过去二十年间各行业最大规模的技术投资之一。数据驱动决策已经成为现代企业的核心能力——然而，访问这些数据的"通行证"是 SQL，一门需要掌握集合论、数据类型、外键关系的技术。

即使对技术人员来说，理解一张陌生数据表的结构、找出外键关联、写出一个能正确 JOIN 的查询，都可能耗费大量时间。更不用说业务人员了：他们知道自己想从数据中找什么答案，却无法用 SQL 表达。

生成式 AI 提供了弥合这道鸿沟的可能：将自然语言问题翻译为正确的 SQL 查询。但research界多年的探索表明，Text-to-SQL 的核心难题集中在三个方面：Schema Linking（识别哪些表/列与问题相关）、JOIN 生成（处理多表关联）、各数据库方言语法差异。据统计，仅 Schema Linking 和 JOIN 两项，就在超过 50% 的测试用例中导致失败。

当前 SOTA 在 BIRD 基准上的执行准确率约为 60%，距离人类水平仍有差距。但一年内从 T5 基线的 7% 跃升至 60%，进步速度已经令人瞩目。

这个 Workshop 正是为解决上述问题而生：AWS 通过 Amazon Bedrock 提供的基础设施，结合 LangChain、DIN-SQL、RAG 等主流技术栈，构建了一套从入门到进阶的 Text-to-SQL 学习路径。

图2：SageMaker Studio 中的 Jupyter Notebook 实验环境

二、项目架构：模块化递进式设计

本 Workshop 采用模块化递进的课程设计，每个模块在前一个模块的基础上引入新技术，形成完整的学习曲线。整体架构基于 AWS SageMaker Studio 运行 Jupyter Notebook，底层通过 Amazon Bedrock 调用 LLM（大语言模型），数据库层支持 Amazon Athena（数据湖）和 RDS（关系型数据库）。

仓库根目录结构：

• module_1/ ~ module_5/：五个递进模块
• cloudformation/：AWS CloudFormation 模板，一键部署基础设施
• libs/din_sql/：DIN-SQL 核心算法库
• utilities.py：通用工具函数（Bedrock 调用、CloudFormation 输出提取等）
• build_boto3_layer.sh：Lambda Layer 打包脚本

基础设施架构（通过 CloudFormation 部署）：

用户浏览器
    │
    ▼
Amazon SageMaker Studio（JupyterLab 实验环境）
    │ 读取 Notebooks
    ▼
Amazon Bedrock（Claude / Titan LLM 推理）
    │
    ├──► Amazon Athena（数据湖查询）
    │
    └──► Amazon RDS / Aurora（关系型数据库）

VPC 私有网络
  ├─ Public Subnet（NAT Gateway）
  └─ Private Subnet × 2（RDS + SageMaker）

三、五大模块详解

模块 1：单表 LangChain（延迟优化）

使用 Amazon Bedrock + LangChain 的 SQLDatabase Toolkit，专注于单表查询场景下的延迟优化。Module 1 是整个 Workshop 的起点，演示了最基础的 Text-to-SQL Pipeline：从用户提问 → Schema 注入 → Prompt 组装 → LLM 推理 → SQL 执行 → 结果返回。

这个模块的核心价值在于提供一个可运行的基线系统，让学习者快速看到端到端效果，再逐步引入更复杂的场景。Module 1 内容：

• 01_single-table-optimized-for-latency.ipynb：单表优化版 Notebook
• diabetes.csv：糖尿病医疗数据集（示例数据）

模块 2：DIN-SQL + Few-Shot（多表复杂查询）

这是 Workshop 的核心技术模块。DIN-SQL（Decomposed Intermediate representation N-to-SQL）是当前社区表现最好的 Text-to-SQL 方法之一，其核心思想是将复杂 SQL 生成任务分解为多个子任务，逐步解决：

1. Schema Linking：识别问题涉及的表和列
2. Query Classification：判断查询复杂度（Easy / Medium / Hard）
3. SQL Generation：根据复杂度选择对应策略生成 SQL
4. Query Cleaning：后处理优化生成的 SQL

每个子步骤都通过 Jinja2 模板（libs/din_sql/prompt_templates/）驱动，配合 Few-Shot 示例实现精准控制。相比单步端到端生成，分解策略能显著提升复杂多表 JOIN 查询的准确率。

同时 Module 2 还包含 02_few_shot_text2sql.ipynb，展示如何通过精心设计的示例提升少样本场景下的 Text-to-SQL 效果。

图3：Decompose-and-Prompt 方法流程图

模块 3：RAG 增强的 Text-to-SQL

将 RAG（检索增强生成）引入 Text-to-SQL，解决企业场景中的文档知识缺失问题——比如列名缩写、缩写语义、业务规则说明等，均以文档形式存储在向量数据库中。

Module 3 (01_text_to_sql_rag.ipynb) 演示了如何：

• 对数据库 schema 文档和业务说明文档进行 Embedding
• 检索与用户问题最相关的上下文片段
• 将检索结果注入 Prompt，提升 LLM 对业务语义的理解

模块 4：安全性（不可忽视的最后一环）

Text-to-SQL 的安全性问题至关重要：LLM 生成的 SQL 如果被直接执行，可能导致数据泄露、数据篡改甚至整个数据库被清空。Module 4 直面这个风险，提出了三层防护体系：

1. 拒绝危险 SQL：通过 Prompt Engineering 限制 LLM 生成 INSERT、UPDATE、DELETE 等写操作
2. 防止 Prompt 注入：检测并拒绝包含恶意指令的输入
3. 数据库权限加固：在 LLM 层之外，从数据库角色权限层面限制只读访问

这个模块体现了 AWS 对生产环境的重视——Workshop 代码虽然以教育为目的，但安全意识贯穿始终。

模块 5：Amazon Titan 微调

最后一个模块 (01_Fine_Tune_Amazon_Titan.ipynb) 展示了如何通过模型微调进一步提升 Text-to-SQL 效果：

• 使用 Spider / BIRD 等标准数据集微调 Amazon Titan 模型
• 在特定领域数据集上微调，提升领域适配性
• 对比微调前后的执行准确率差异

这一模块为有更高准确率要求的生产场景提供了进阶路径。

四、技术栈全景

层次	技术选型
LLM 推理	Amazon Bedrock（Claude、Titan）
数据库连接	SQLAlchemy（统一接口支持 Athena/RDS）
Prompt 管理	Jinja2 模板引擎
Agent 框架	LangChain（SQLDatabase Toolkit）
Notebook 环境	SageMaker Studio JupyterLab
基础设施	AWS CloudFormation（VPC、SageMaker、Lambda、S3）
底层 SDK	Boto3 >= 1.3
编程语言	Python + Jupyter Notebook

五、部署体验

部署本 Workshop 需要以下步骤：

1. 执行 build_boto3_layer.sh 打包 Boto3 Lambda Layer，上传至 S3
2. 修改 CloudFormation 参数（DB 凭证、S3 Bucket 名等）
3. 在 us-west-2 或 us-east-1 区域部署 CloudFormation 堆栈
4. 等待 SageMaker Studio Domain 创建完成（约 10-20 分钟）
5. 打开 SageMaker JupyterLab，从 Git 克隆本仓库
6. 按模块顺序运行 Jupyter Notebook

部署要求：

• AWS 账户（VPC 配额至少 5 个，Workshop 会创建 1 个）
• 支持区域：us-west-2 或 us-east-1（其他区域 CloudFormation 会失败）
• IAM 权限：CloudFormation、SageMaker、Athena、RDS、Lambda、S3
• 无需 GPU，本 Workshop 为纯推理场景

图4：SageMaker Studio 环境初始化

六、局限性与适用边界

1. 非生产级代码：代码库明确声明仅供演示和教育用途，不适合直接投入生产
2. 区域锁定：仅支持 us-west-2 和 us-east-1，对使用其他区域的团队不友好
3. 延迟敏感场景：分解式 DIN-SQL 需多次 LLM 调用，单次查询耗时可能超过数秒，不适合低延迟要求的 BI 场景
4. 成本考量：Bedrock 按 token 计费，分解式推理调用次数多，成本高于单步端到端方案
5. 无容器化：缺少 Dockerfile/docker-compose，无法在本地快速复现

七、行业意义与价值

本 Workshop 代表了 Text-to-SQL 从理论研究走向工程实践的一个重要节点。它不是追求 SOTA 准确率的学术项目，而是：一个真实可运行的 AWS 生产参考架构。

其价值在于：

• 工程教育：帮助数据工程师、AI 开发者理解 Text-to-SQL 的完整技术栈
• 架构参考：DIN-SQL 的分解策略、LangChain 集成、RAG 增强方案可直接迁移到生产系统
• 安全示范：展示了 Text-to-SQL 系统中必须考虑的安全防护层次
• AWS 生态整合：与 Bedrock、SageMaker、Athena、RDS 的深度集成，展示了企业级 LLM 应用的标准部署模式

对于希望在 AWS 生态中构建智能数据查询系统的团队，这是一份不可多得的参考实现。