mirror of
https://github.com/tencentmusic/supersonic.git
synced 2026-05-04 07:24:52 +08:00
Updated 超音数设计思路 (markdown)
10
超音数设计思路.md
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%" >
|
||||
|
||||
|
||||
### Semantic Layer
|
||||
|
||||
当AI领域的LLM满级输出吸走大部份聚光灯的时候,BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer(另一种常见叫法是Metric Store)。所以它的核心价值是什么?我们可以用两个拟人化的角色来类比:
|
||||
@@ -61,7 +60,16 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
|
||||
|
||||
### 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
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user