topdog/supersonic
1
0
Fork 0
mirror of https://github.com/tencentmusic/supersonic.git synced 2026-05-08 11:14:19 +08:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity

Updated 超音数设计思路 (markdown)

Jun Zhang
2023-09-07 18:04:05 +08:00
parent 05f6895dd4
commit 3242d33b8a
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
超音数设计思路.md

@@ -22,7 +22,7 @@
因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用要求。架构图里黄色背景块就是引入的配套组件，下面的篇幅将展开介绍设计思考。
<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
@@ -43,9 +43,9 @@
### 引入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 Corrector