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