diff --git a/超音数设计思路.md b/超音数设计思路.md
index e83644c..6430056 100644
--- a/超音数设计思路.md
+++ b/超音数设计思路.md
@@ -15,7 +15,7 @@
 
 **效率相关问题：**
 
-- 当前LLM推理速度还处在10s级别，加上底层数据查询的耗时，同时无法像纯文本那样的增量输出，非常考验用户的耐心。
+- 当前LLM推理速度还处在10秒+量级，再加上底层数据查询的耗时，同时还无法像纯文本那样的增量输出，非常考验用户的耐心。
 - 当前LLM主流是按token计费，如果所有查询都需要走LLM，MaaS成本会随着查询量线性增长。
 
 我们逐渐意识到，LLM只是看作是意图识别和文本生成的引擎，它还需要其他的组件来配套，才构成一个完整的系统解决方案。可与此类比的是传统OLAP引擎，需要有transformation层的清洗、关联、聚合等建模步骤来配套，才能形成高效稳定的data pipeline。