简单和大家聊聊nlp2sql 以及 SQL数据分析存在的问题，以及解决方案。

快速过下背景：

1. nlp2sql 去年大模型一出来，大家就开始搞了，但是目前准确率普遍上不去，导致很难普及。这个技术主要是改变交互，从人讲自然语言需求写SQL改成大模型来理解自然语言，写SQL。

2. SQL内置大模型函数支持实现对传统数据分析能力的突破，这个去年应该是我们和 Databricks 搞的比较早，我们可能略早（纯瞎猜），而且底层技术方案可能也完全不一样。这个技术就是补上了SQL 对非结构化数据分析的能力，实现了很大的突破。去年和今年上半年，受限于大模型速度以及成本，还有就是企业对大模型的认知还停留在知识库构建上，所以没有得到重视。

现在来说下技术的难点。

NLP2SQL

nlp2sql 目前难点有三个：

1.  表召回的准确度 （企业有几万到几十万张表，根据一句话要准确获取到哪些相关的表是一件很困难的事情）

2. 大模型对查询的理解（在企业里需要召回大量背景知识，否则大模型理解一定会有偏差）

3. 目标语言的复杂性（常见sql大模型通常都会搞混，比如把 oracle的函数用在了 spark sql里。此外单条SQL语句复杂度足够高也会导致直接生成不出来） 

可以看到，1,2 两点本质上还是考验RAG召回系统,只要 RAG 系统做的好，效果自然就会好，我们的第二代以大模型为核心的RAG系统很好的提升了召回效果。

对于第三点，Byzer-SQL 可以将一条复杂的SQL语句通过几条简单的SQL语句完成，极大的降低了模型生成SQL的难度。

SQL支持自然语言处理

第二个就是以传统SQL分析的体系，一直没办法对表里的文本字段做NLP分析的。但实际上大量的文本字段存在于用户的业务系统里，数据湖，数仓，甚至以excel,csv 格式存在。

举个例子，对一个评论表，我想统计有多少负面评论，这个在以前单纯使用SQL是没有办法解决的。一般需要找算法团队开发一个算法，然后加一个字段，然后再用SQL统计。基本随便一个需求可能就需要耗时至少一周，以及两个团队的协作。

我们去年就在Byzer SQL里添加了大模型UDF函数，并且已经支持市面上主流的大模型，解决了传统SQL无法分析表文本字段的能力。

效果演示

这个视频的例子很简单，但底层其实不简单，底层其实依赖了三个系统：

1. 一个schema RAG 系统 （企业把业务数据里的表schema 导入进来就行）

2. 一个知识 RAG 系统（比如如何使用 Byzer-SQL, 企业内部的文档和黑话等）

3. 一个支持了大模型函数的 SQL 分布式执行引擎

视频中演示的系统把这三个系统有机的串联起来了。前面我们说到，我们的第二代以大模型 RAG 系统抛弃了一代 以 emb/retrank 为核心的RAG系统。

这里简单的解释下为什么第一代 RAG系统已经很难有提升潜力了：

以chunk 为粒度，使用emb召回的系统，存在严重的信息损耗，并且基本不可解决。这个损耗包括：数据切片导致的信息丢失，召回过程中存在chunk 同质化严重（比如top3 的chunk 可能都是类似的话), chunk 的排序导致人为的将数据打乱，极大的干扰了大模型的理解。这些问题是一代RAG系统的基因问题，很难通过革新来解决，必须推倒重来。

此外，emb/rerank 模型自身提升上限很低。

我们第二代系统的特点：

1. 动态文件为粒度，具有更好的上下文。

2. 召回和理解都采用大模型，效果随着大模型的提升而自动提升。

我们第二代 auto-coder RAG 工程上充分利用大模型，和充分利用GPU 算力的技巧差不多：

1. 使用 deepseek tokenizer 用于离线计算token数，方便无限逼近128k  窗口，窗口和GPU计算一样不能浪费，必须打满。

2. Prompt 构建要尽可能保证前面部分不变，后面部分变化，从而尽可能触发 deepseek 的缓存。目前还有不少可以优化的空间。这个和 GPU kv cache的使用很像。

3. 尽可能输入多，输出少，加上前面两部分，可以实现非常低的成本并且速度很快，从而可以实现高并发低延迟过滤，而过滤质量又远超向量和rerank。

4. 对于超出窗口的内容，我们设计了一套新算法，采用了使用大模型动态根据query 抽取相关上线文，并且能够保证速度可控，成本可控。

当前的还有一些挑战我们正在攻克

当然了，当前的 auto-coder RAG 的效果虽然很好，但也还存在一些限制：诸如 无法在合适的时间处理几十万以及以上的文档，查询时间相比一代较长，整体速度在30-60s 之间， token消耗很大，并且要需要大模型支持高并发。不过这些未来都可以通过工程解决。

而在SQL中调用大模型遇到的问题是类似的，执行速度远比一般 SQL 函数慢几个量级，token成本很容易失控，需要更好的控制并发，但是没半年到一年模型价格至少下降 80%的，速度也会获得很大提升，相信很快这些问题都会得到缓解。