Created 超音数设计思路 (markdown)

超音数设计思路.md

@@ -0,0 +1,33 @@
+通过自然语言界面（Natural Language Interface）访问数据是数据库上古大神们就开始畅想的情境，在学术界也一直是专门的研究方向。对我们影响比较大的一篇论文是谷歌在2017年发表的[Analyza](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/45791.pdf)，但它是纯基于规则的工程实现。2017年之后，随着[Seq2SQL](https://arxiv.org/pdf/1709.00103.pdf)和[Spider](https://aclanthology.org/D18-1425.pdf)引入经过人工标注的大规模数据集，基于AI模型的解决方案如雨后春笋般涌现，从seq2seq到slot filling，从schema linking到pretraining，各种奇淫技巧不一而足。直到ChatGPT横空出世，基于LLM来实现text-to-SQL几乎成了大家的共识。
+
+在项目初期，我们也曾尝试过直接让ChatGPT来生成SQL，但经过多轮prompt优化调整，始终无法达到生产可用的要求，总的来说有以下方面问题：
+
+**Schema相关问题：**
+
+- 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过token限制。
+- LLM输出稳定性无法保证，存在一些查询case会推测出错误的字段，甚至有可能幻觉出不存在的字段。
+- 字段取值量太大，一般不会根schema信息一起输入，使得LLM无法识别专有领域的术语。
+
+**语法相关问题：**
+
+- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度；
+- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成；
+
+除此之外，在数据服务领域常见的一些功能，也无法通过LLM生成SQL来直接满足，比如：
+
+- 权限校验：
+- 查询路由：
+
+### 引入Semantic Layer
+
+
+
+### 引入Schema Mapper
+
+
+
+### 引入Semantic Corrector
+
+
+
+### 引入RuleBased Parser