Updated 超音数设计思路 (markdown)

超音数设计思路.md

@@ -1,6 +1,6 @@
 通过自然语言界面（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优化调整，始终无法达到生产可用的要求，总的来说有以下方面问题：
+在项目初期，我们也曾尝试过直接让ChatGPT来生成SQL，但经过多轮prompt优化调整，始终无法达到生产可用的要求，总的来说有以下问题：
 
 **Schema相关问题：**
 
@@ -10,13 +10,10 @@
 
 **语法相关问题：**
 
-- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度；
+- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度。
-- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成；
+- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成。
 
-除此之外，在数据服务领域常见的一些功能，也无法通过LLM生成SQL来直接满足，比如：
+我们逐渐意识到，LLM只是看作是意图识别和文本生成的引擎，它还需要其他的组件来配套，才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎，需要有transformation层的清洗、关联、聚合等建模步骤来配套，才能形成高效稳定的data pipeline。
-
-- 权限校验：
-- 查询路由：
 
 ### 引入Semantic Layer