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