topdog/supersonic
1
0
Fork 0
mirror of https://github.com/tencentmusic/supersonic.git synced 2026-05-04 07:24:52 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated 超音数设计思路 (markdown)

Jun Zhang
2023-09-07 21:38:30 +08:00
parent af16ddb1c5
commit d6eefb8b79
1 changed files with 9 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
超音数设计思路.md

@@ -24,7 +24,6 @@
<img alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="50%" width="50%" > <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）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比： 当AI领域的LLM满级输出吸走大部份聚光灯的时候，BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer（另一种常见叫法是Metric Store）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比：
@@ -61,7 +60,16 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
### Rule-based Parser ### Rule-based Parser
针对前文提到的效率问题，除了做时间的朋友，等待LLM进化突破之外，还可以想办法在应用层规避。比如，对于一些简单的问题输入，可以尝试基于规则来做语义解析，这也是从Google Analyza论文里带来的启发。这就是Rule-based Parser的由来。
当前的设计方案是，通过经验整理一份表单，如下表所示，明确列举每类语义对象（指标/维度/取值/时间/算子）的组合会映射到哪一种查询意图。Rule-based parser再根据schema mapping的结果，从表单中查到对应的查询意图，这个有点类似slot filling的思路。
<img width="1630" alt="rule-based parser slot-filling" src="https://github.com/tencentmusic/supersonic/assets/3949293/1df91461-6f09-45c5-bde0-607deab28a10">
引入Semantic Parser的抽象，分别有rule-based和LLM-based的实现。输入问题首先经过rule-based parser，如果有查询意图命中，则根据启发性算法来决定是否可以跳过LLM-based parser。当前，启发性算法会根据schema mapping命中的词汇总长度除以问题总长度来判断，超过配置的阈值则认为规则可以满足需要，决定跳过LLM，如果跳过那么提升效率的目的就达到了。
与此同时，semantic parser可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现，也可以选择完全去掉rule-based parser配置。
### Chat Plugin ### Chat Plugin