NL2SQL 对于堆 table schema ，在表结构太复杂的时候无法控制上下文长度，且 schema 太多了，依靠大模型来写 sql ，非常容易答非所问或者错误 sql 。 semantic layer （下称 SL ）基本上成为了让大模型写出 sql 准确的唯一实现路径。
SL 也不算是一个特别新概念，从好理解的角度来解释：SL 对于 NL2sql 的意义，相当于传统 BI 的指标平台指标层。
大家都知道要做 SL ，做在哪里呢？
1 、snowflake 的方案是做在 db 上，db 级原生支持 SL 创建。https://docs.snowflake.com/en/user-guide/views-semantic/overview 2 、google alloydb ,data agent 方案 https://docs.cloud.google.com/alloydb/docs/ai/natural-language-landing
 |
1
haloandspike 7 days ago  1
之前做过知识图谱，跟这个场景比较类似，在 gpt-4 的时间点，我们的方案是做了一个 NL2SQL 的例子库，把用户 q 召回 NL2SQL 的例子，给模型参考改写。现在我理解模型的 coding 能力很强，而且上下文窗口很大，还会遇到改写准确率低的问题吗？
|
|
2
haloandspike 7 days ago
https://spike.wiki/post/how-we-built-chatbot-with-kg
之前技术方案 |
 |
3
bjfane OP PRO “把用户 q 召回 NL2SQL 的例子，给模型参考改写” 这个是 fewshot ？
你做的好早啊， 什么名词都是 demo 都很好，一到企业级复杂度就蹭蹭的涨， 模型能力变强，在业务歧义和多跳上几乎没什么太大变化。 |
|
4
haloandspike 6 days ago
“把用户 q 召回 NL2SQL 的例子，给模型参考改写” 这个是 fewshot ？
是的，few shot 。 |
|
5
bjfane OP PRO 现在大家方法不一样，但是有一个共识就是要做语义层：
1 、传统的比如 bi 里带指标管理，或者 dbt metricflow cubejs 这种 2 、“in db” snowflake 、databricks 3 、直接就基于 ontology 理论的 4 、上面 google 大概这 4 个方向 |
Select Language