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