From d7f838ed0652a1d33916fb0ee81429a9f41b504e Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Thu, 7 Sep 2023 16:10:14 +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 | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index 6430056..e546b09 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相关问题：** @@ -15,16 +15,16 @@ **效率相关问题：** -- 当前LLM推理速度还处在10秒+量级，再加上底层数据查询的耗时，同时还无法像纯文本那样的增量输出，非常考验用户的耐心。 +- 当前LLM推理速度还处在10秒+量级，再加上底层数据查询的耗时，同时还无法像纯文本那样的流式输出，非常考验用户的耐心。 - 当前LLM主流是按token计费，如果所有查询都需要走LLM，MaaS成本会随着查询量线性增长。 我们逐渐意识到，LLM只是看作是意图识别和文本生成的引擎，它还需要其他的组件来配套，才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎，需要有transformation层的清洗、关联、聚合等建模步骤来配套，才能形成高效稳定的data pipeline。 -因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用的要求。下面的篇幅将展开介绍这些组件的作用。 +因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用要求。下面的篇幅将展开介绍这些组件的设计思考。 ### 引入Semantic Layer - +当AI领域正在大杀四方， ### 引入Schema Mapper