From bd23dbd22802089b8f260332aa94530e5eb00267 Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Thu, 7 Sep 2023 15:46:01 +0800 Subject: [PATCH] =?UTF-8?q?Updated=20=E8=B6=85=E9=9F=B3=E6=95=B0=E8=AE=BE?= =?UTF-8?q?=E8=AE=A1=E6=80=9D=E8=B7=AF=20(markdown)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 超音数设计思路.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index df081b7..4b76630 100644 --- a/超音数设计思路.md +++ b/超音数设计思路.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无法保证准确度； -- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成； +- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度。 +- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成。 -除此之外，在数据服务领域常见的一些功能，也无法通过LLM生成SQL来直接满足，比如： - -- 权限校验： -- 查询路由： +我们逐渐意识到，LLM只是看作是意图识别和文本生成的引擎，它还需要其他的组件来配套，才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎，需要有transformation层的清洗、关联、聚合等建模步骤来配套，才能形成高效稳定的data pipeline。 ### 引入Semantic Layer