From 5e83eed48b8a25ae3a25380572d0d41914fba7b8 Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Thu, 7 Sep 2023 20:52:20 +0800 Subject: [PATCH] =?UTF-8?q?Updated=20=E8=B6=85=E9=9F=B3=E6=95=B0=E8=AE=BE?= =?UTF-8?q?=E8=AE=A1=E6=80=9D=E8=B7=AF=20(markdown)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 超音数设计思路.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index d089345..31c6b05 100644 --- a/超音数设计思路.md +++ b/超音数设计思路.md @@ -45,13 +45,19 @@ 前文有提到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可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现。 + ### 引入Semantic Corrector 针对前文提到的推测错误和幻觉问题，一个方向是对prompt不断试验打磨，但现阶段仍然是玄学成分居多。另一个方向是，在LLM输出的后置环节增加**修正机制**，将明显错误的表达予以修复。这就是Semantic Corrector组件的由来。 +当前的设计方案是，从LLM生成的SQL中解析出表、字段、取值等名词，逐个检查合法性，将不合法名词通过类似schema mapping的方式去knowledge base尝试找到正确的匹配。比如，LLM可能将取值映射到了错误的字段，通过corrector尝试找到正确的字段映射，并改写SQL。 + +与此同时，semantic corrector可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现。 + ### 引入Rule-based Parser