From a3428fd7b13e0a56bcc0e983e7a0b36e63fab474 Mon Sep 17 00:00:00 2001 From: Jun Zhang Date: Mon, 9 Oct 2023 09:52:32 +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 | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/超音数设计思路.md b/超音数设计思路.md index dea80df..17a0520 100644 --- a/超音数设计思路.md +++ b/超音数设计思路.md @@ -7,13 +7,12 @@ - 为了让LLM理解schema，需要将所有字段的名称和描述作为context输入，如果schema字段数量多，可能会超过token限制。 - 同样因为token的限制，基数过大的字段取值一般不会全部放入context，使得LLM无法识别到专有领域的一些术语。 -**稳定性问题：** +**幻觉问题：** -- 即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会推测出错误的字段，甚至可能幻觉出不存在的字段。 +- 即便将schema全部输入且告知LLM不要随意猜测，仍然有一定几率会预测出错误的字段，甚至可能幻觉出不存在的字段。 - 如果涉及多表关联、运算公式、时间转换等情况，SQL语法较为复杂，LLM出错概率会变高。 -- 如果底层OLAP引擎有特殊方言，LLM也无法保证准确度。 -**效率相关问题：** +**推理效率问题：** - 当前LLM推理速度还处在10秒+量级，再加上底层数据查询的耗时，同时还无法像纯文本那样的流式输出，非常考验用户的耐心。 - 当前LLM主流是按token计费，如果所有查询都需要走LLM，MaaS成本会随着查询量线性增长。