Updated 超音数设计思路 (markdown)

超音数设计思路.md

@@ -25,7 +25,7 @@
 <img alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="50%" width="50%" >
 
 
-### 引入Semantic Layer
+### Semantic Layer
 
 当AI领域的LLM满级输出吸走大部份聚光灯的时候，BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer（另一种常见叫法是Metric Store）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比：
 
@@ -41,7 +41,7 @@
 
 因此，既然semantic layer可以帮助人更好地把数据用起来，为什么不顺便帮一下LLM，举手之劳而已。
 
-### 引入Schema Mapper
+### Schema Mapper
 
 前文有提到LLM的token限制问题，主要是因为想要暴力求解，将全部字段的名称和取值一股脑都丢给LLM。直观分析，可以在前置环节增加**筛选机制**，只保留跟用户输入相关的字段，可以极大地减少token使用，即便不超过限制，也能节省推理成本。这就是Schema Mapper组件的由来。
 
@@ -51,7 +51,7 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
 
 与此同时，schema mapper可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现。
 
-### 引入Semantic Corrector
+### Semantic Corrector
 
 针对前文提到的推测错误和幻觉问题，一个方向是对prompt不断试验打磨，但现阶段仍然是玄学成分居多。另一个方向是，在LLM输出的后置环节增加**修正机制**，将明显错误的表达予以修复。这就是Semantic Corrector组件的由来。
 
@@ -59,5 +59,9 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
 
 与此同时，semantic corrector可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现。
 
-### 引入Rule-based Parser
+### Rule-based Parser
+
+
+
+### Chat Plugin