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