mirror of
https://github.com/tencentmusic/supersonic.git
synced 2026-05-06 09:14:19 +08:00
Updated 超音数设计思路 (markdown)
@@ -45,13 +45,19 @@
|
|||||||
|
|
||||||
前文有提到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)相对成熟,可以满足需要。
|
||||||
|
|
||||||
Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得分一并保存到info对象,传递给后续semantic parsing环节引用,最终会由parser挑选输入给LLM。
|
Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得分一并保存到info对象,传递给后续semantic parsing环节引用,最终会由parser挑选输入给LLM。
|
||||||
|
|
||||||
|
与此同时,schema mapper可以定制扩展,并通过SPI配置的方式替换或补充超音数的默认实现。
|
||||||
|
|
||||||
### 引入Semantic Corrector
|
### 引入Semantic Corrector
|
||||||
|
|
||||||
针对前文提到的推测错误和幻觉问题,一个方向是对prompt不断试验打磨,但现阶段仍然是玄学成分居多。另一个方向是,在LLM输出的后置环节增加**修正机制**,将明显错误的表达予以修复。这就是Semantic Corrector组件的由来。
|
针对前文提到的推测错误和幻觉问题,一个方向是对prompt不断试验打磨,但现阶段仍然是玄学成分居多。另一个方向是,在LLM输出的后置环节增加**修正机制**,将明显错误的表达予以修复。这就是Semantic Corrector组件的由来。
|
||||||
|
|
||||||
|
当前的设计方案是,从LLM生成的SQL中解析出表、字段、取值等名词,逐个检查合法性,将不合法名词通过类似schema mapping的方式去knowledge base尝试找到正确的匹配。比如,LLM可能将取值映射到了错误的字段,通过corrector尝试找到正确的字段映射,并改写SQL。
|
||||||
|
|
||||||
|
与此同时,semantic corrector可以定制扩展,并通过SPI配置的方式替换或补充超音数的默认实现。
|
||||||
|
|
||||||
### 引入Rule-based Parser
|
### 引入Rule-based Parser
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user