diff --git a/超音数设计思路.md b/超音数设计思路.md
index dd5b36d..8063019 100644
--- a/超音数设计思路.md
+++ b/超音数设计思路.md
@@ -2,13 +2,16 @@
 
 在项目初期，我们也曾尝试通过prompt engineering让ChatGPT直接生成SQL，但经过多轮迭代，在稳定性和可靠性方面始终无法达到生产可用的期望，总的来说有如下问题：
 
-**幻觉问题：**
+**SQL复杂度**
+- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM输出可靠性会进一步降低。
+- 涉及指标计算的场景，如果依赖用户问询来描述，无法保证口径的一致性与确定性。
 
-- 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过context window限制。因此，基数过大的字段取值一般不会全部放入context，使得LLM无法识别到专有领域的术语。
-- 即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会预测出错误的字段，甚至可能幻觉出不存在的字段。
+**LLM幻觉**
+
+- 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过context window限制。因此，基数过大的字段取值一般不会全部放入context，使得LLM无法识别到专有领域的术语。即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会预测出错误的字段，甚至可能幻觉出不存在的字段。
 - 相同的语义，不同的语言表达，可能会导致大相径庭的输出结果，无法保证一致性。
 
-**效率问题：**
+**推理效率**
 
 - 当前LLM推理速度还处在10秒+量级，再加上底层数据查询的耗时，同时还无法像纯文本那样的流式输出，非常考验用户的耐心。
 - 当前LLM主流是按token计费，如果所有查询都需要走LLM，MaaS成本会随着查询量线性增长。