Updated 超音数设计思路 (markdown)

Jun Zhang
2023-10-09 09:50:20 +08:00
parent 398bbccb4f
commit 58a1042431

@@ -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几乎成了大家的共识。 通过自然语言界面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优化调整在稳定性和可靠性方面始终无法达到生产可用的期望,总的来说有如下问题:
**Token限制问题** **Token限制问题**
@@ -20,7 +20,7 @@
我们逐渐意识到LLM只是看作是意图识别和文本生成的引擎它还需要其他的组件来配套才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎需要有transformation层的清洗、关联、聚合等建模步骤来配套才能形成高效稳定的数据服务。 我们逐渐意识到LLM只是看作是意图识别和文本生成的引擎它还需要其他的组件来配套才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎需要有transformation层的清洗、关联、聚合等建模步骤来配套才能形成高效稳定的数据服务。
因此在超音数项目中我们围绕LLM引擎引入与之配套的组件,希望通过系统化的工程来达到生产可用要求。架构图里黄色背景块就是引入的配套组件,下面的篇幅将展开介绍设计思考。 因此在超音数项目中我们围绕LLM引入与之配套的工程化组件来增强语义解析和SQL生成的可靠性。架构图里黄色背景块就是引入的配套组件,下面的篇幅将展开介绍设计思考。
<img alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="50%" width="50%" > <img alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="50%" width="50%" >