From df036405b6f422c5f3bd2718947a176acc93c16f Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Thu, 7 Sep 2023 17:48:03 +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 | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index ae78bbf..977220b 100644 --- a/超音数设计思路.md +++ b/超音数设计思路.md @@ -2,16 +2,16 @@ 在项目初期，我们也曾尝试过直接让ChatGPT来生成SQL，但经过多轮prompt优化调整，在稳定性和准确度方面始终无法达到生产可用的要求，总的来说有如下问题： -**Schema相关问题：** +**Token限制问题：** - 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过token限制。 -- LLM输出稳定性无法保证，存在一些查询case会推测出错误的字段，甚至有可能幻觉出不存在的字段。 -- 字段取值量太大，一般不会根schema信息一起输入，使得LLM无法识别专有领域的术语。 +- 同样因为token的限制，基数过大的字段取值一般不会全部放入context，使得LLM无法识别到专有领域的一些术语。 -**语法相关问题：** +**稳定性问题：** -- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM无法保证准确度。 -- 如果底层OLAP引擎有特殊方言，LLM可能无法正确生成。 +- 即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会推测出错误的字段，甚至可能幻觉出不存在的字段。 +- 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM出错概率会变高。 +- 如果底层OLAP引擎有特殊方言，LLM也无法保证准确度。 **效率相关问题：** @@ -22,6 +22,9 @@ 因此，在超音数项目中我们围绕LLM引擎引入与之配套的组件，希望通过系统化的工程来达到生产可用要求。下面的篇幅将展开介绍这些组件的设计思考。 +supersonic_components + + ### 引入Semantic Layer 当AI领域的LLM满级输出吸走大部份聚光灯的时候，BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer（另一种常见叫法是Metric Store）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比： @@ -40,7 +43,9 @@ ### 引入Schema Mapper +上文有提到LLM的token限制问题，主要是因为想要暴力求解，将全部字段的名称和取值一股脑都丢给LLM。实际上，可以在前置环节增加一个筛选机制，只保留跟用户输入相关的字段，可以极大地减少token使用，即便不超过限制，也能节省推理成本。这就引出了Schema Mapper。 +当前，我们采用的是 ### 引入Semantic Corrector