Updated 超音数设计思路 (markdown)

超音数设计思路.md

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