mirror of
https://github.com/tencentmusic/supersonic.git
synced 2026-05-09 20:24:23 +08:00
Updated 超音数设计思路 (markdown)
@@ -26,7 +26,7 @@
|
|||||||
|
|
||||||
### Semantic Layer
|
### Semantic Layer
|
||||||
|
|
||||||
当AI领域的LLM满级输出吸走大部份聚光灯的时候,BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer(另一种常见叫法是Metric Store)。所以它的核心价值是什么?我们可以用两个拟人化的角色来类比:
|
当AI领域的LLM满级输出吸走大部份聚光灯的时候,BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer(也有称为是Headless BI或者Metric Store)。所以它的核心价值是什么?我们可以用两个拟人化的角色来类比:
|
||||||
|
|
||||||
- **翻译官**:将技术名词(表/字段)翻译成业务术语(维度/指标/标签),便于业务用户理解。
|
- **翻译官**:将技术名词(表/字段)翻译成业务术语(维度/指标/标签),便于业务用户理解。
|
||||||
- **大管家**:将技术口径(关联关系/运算公式)统一化、精细化地管理起来,便于查帐比对,消除口径混乱。
|
- **大管家**:将技术口径(关联关系/运算公式)统一化、精细化地管理起来,便于查帐比对,消除口径混乱。
|
||||||
@@ -42,7 +42,7 @@
|
|||||||
|
|
||||||
### Schema Mapper
|
### Schema Mapper
|
||||||
|
|
||||||
前文有提到LLM的token限制问题,主要是因为想要暴力求解,将全部字段的名称和取值一股脑都丢给LLM。直观分析,可以在前置环节增加**筛选机制**,只保留跟用户输入相关的字段,可以极大地减少token使用,即便不超过限制,也能节省推理成本。这就是Schema Mapper组件的由来。
|
前文有提到LLM的token限制问题,主要是因为想要暴力求解,将全部字段的名称和取值一股脑都丢给LLM。直观分析,可以在前置环节增加**映射机制**,只保留能在输入文本中映射上的字段,可以极大地减少token使用,即便不超过限制,也能节省推理成本。这就是Schema Mapper组件的由来。
|
||||||
|
|
||||||
当前的设计方案是,定期从semantic model中抽取名称、别名、取值来构建词典,形成内部的knowledge base。查询解析阶段,先对输入文本分词,再采用n-gram词典探测的机制。经过前期调研,中文NLP框架[HanLP](https://github.com/hankcs/HanLP)相对成熟,可以满足需要。
|
当前的设计方案是,定期从semantic model中抽取名称、别名、取值来构建词典,形成内部的knowledge base。查询解析阶段,先对输入文本分词,再采用n-gram词典探测的机制。经过前期调研,中文NLP框架[HanLP](https://github.com/hankcs/HanLP)相对成熟,可以满足需要。
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user