From 3242d33b8a5c299a86ccb613215aac9e2a59d4cd Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Thu, 7 Sep 2023 18:04:05 +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 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index 0b235fc..118b973 100644 --- a/超音数设计思路.md +++ b/超音数设计思路.md @@ -22,7 +22,7 @@ 因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用要求。架构图里黄色背景块就是引入的配套组件，下面的篇幅将展开介绍设计思考。 -supersonic_components +supersonic_components ### 引入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