Updated 超音数设计思路 (markdown)

超音数设计思路.md

@@ -2,16 +2,16 @@
 
 在项目初期，我们也曾尝试过直接让ChatGPT来生成SQL，但经过多轮prompt优化调整，在稳定性和准确度方面始终无法达到生产可用的要求，总的来说有如下问题：
 
-**Schema相关问题：**
+**Token限制问题：**
 
 - 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过token限制。
-- LLM输出稳定性无法保证，存在一些查询case会推测出错误的字段，甚至有可能幻觉出不存在的字段。
-- 字段取值量太大，一般不会根schema信息一起输入，使得LLM无法识别专有领域的术语。
+- 同样因为token的限制，基数过大的字段取值一般不会全部放入context，使得LLM无法识别到专有领域的一些术语。
 
-**语法相关问题：**
+**稳定性问题：**
 
-- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度。
-- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成。
+- 即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会推测出错误的字段，甚至可能幻觉出不存在的字段。
+- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM出错概率会变高。
+- 如果底层OLAP引擎有特殊方言，LLM也无法保证准确度。
 
 **效率相关问题：**
 
@@ -22,6 +22,9 @@
 
 因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用要求。下面的篇幅将展开介绍这些组件的设计思考。
 
+<img width="722" alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="60%" width="60%">
+
+
 ### 引入Semantic Layer
 
 当AI领域的LLM满级输出吸走大部份聚光灯的时候，BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer（另一种常见叫法是Metric Store）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比：
@@ -40,7 +43,9 @@
 
 ### 引入Schema Mapper
 
+上文有提到LLM的token限制问题，主要是因为想要暴力求解，将全部字段的名称和取值一股脑都丢给LLM。实际上，可以在前置环节增加一个筛选机制，只保留跟用户输入相关的字段，可以极大地减少token使用，即便不超过限制，也能节省推理成本。这就引出了Schema Mapper。
 
+当前，我们采用的是
 
 ### 引入Semantic Corrector