DataFocus致力于ChatBI的研发已经有8个年头了。从第一个版本开始，DataFocus始终只有一种交互方式，只有一个对话框（搜索框）。我们一直有一个说法：问答式交互，搜索式分析！

GIF图1-搜索

DataFocus在8年前选择的这条路，一路走过来填坑无数，遇到很多问题，体会深刻。今天给大家分享一些我们的心得，希望对致力于ChatBI开发的产品经理有所帮助，也希望大家少走弯路。

今天大家探讨的主题是ChatBI，这是最近新出来的一个概念。大模型火了以后，所有的交互方式都变成对话了，所以有了这么一个名字。我查了一下，大概网易有数或者帆软BI都提到这么个说法。在这之前，我们管这种交互方式叫搜索式BI，国外最早做的是ThoughtSpot，国内最早做的是DataFocus，也是最成熟的两款产品。还有一个创业公司叫北极九章的，做得比较晚，也做搜索式分析。

图2-三个BI

什么是ChatBI？有必要先统一一下认知，要保证大家在讨论的是同一个东西。有两个维度，从产品角度来看，顾名思义，能chat的BI就是ChatBI。讲的是一种交互方式上的变化，大体上BI的功能还是得有的，比如数据的接入，看板的制作等等

图3-数据看板

从用户角度来说，能聊天提问就可以做数据分析的软件就叫ChatBI；

GIF图4-FocusGPT

两种角度都涉及到用问答的方式取用数据，我们取最小公倍数：就是要用问答的方式，查询数据库。

GIF图5-搜索

那么ChatBI，本质上要解决的问题就是一个Text2SQL（NL2SQL）的问题，我们需要寻找一个函数（或算法），实现从自然语言到数据库查询语言SQL的精确映射。这个问题的难点在哪里呢？从自然语言这个巨大的状态空间到SQL语句的映射，是很困难的，自然语言表达是个无限的空间，SQL算是一种领域特定语言，但它也是无限的。和简单的自然语言到另一种语言的翻译不一样，比如我们做英语翻译，有直译，有意译，表达方式多种多样，都算正确。 但text2SQL的映射，是要求是完全精确的。

Text2SQL的问题，很早以前就有人研究，从最早的IBM研究团队到Salesforce公司，都挑战过。Salesforce公司还创建了一个相当规模的WikiSQL数据集。当然，学术界也有很多学者在这个领域做了广泛的研究，远的比如哈佛大学提出SpiderSQL数据集，近的如阿里巴巴和香港大学提出了BirdSQL数据集。

10几年前深度学习技术也被应用到这个领域，Sequence2Sequence，Bert、T5等等各种模型都有一定的进展，但是收效都不大。主要的问题还是准确度不够，涉及到数据的准确性，尤其是企业级用户没办法在真实场景中使用。    

           Text2SQL的难点：如何实现从自然语言到SQL的精确映射

自从OpenAI的ChatGPT推出以后，大家发现大模型在Text2SQL领域有了长足的进步，最好的模型GPT4已经可以在简单问题上达到相当不错的准确率，以至于SpiderSQL这个数据集最近一年刷榜好几次，都是基于GPT4的方案。这个结果让整个行业都很兴奋。看起来Text2SQL这个问题好像又有了解决办法，于是工业界也快速行动起来，所以就有了ChatBI这个概念快速的火爆起来。从目前的情况来看，如果要开发一款ChatBI产品，通常有以下三种方法：

1、最容易想到的方法，通过枚举实现

Q&A ∑（LLM（Language input）） → ∑ SQL    

这就像小朋友做算术题。10以内的加减法，可以掰手指来算；20以内的加减法，手指头不够用，可以加上脚趾头。但是，显然手指头总有不够的时候。这种枚举方法最直接，也是最低效的。

这种技术路线实施成本高，适合定制化项目。企业有相应的人力资源和技术能力，用这种方式自研，可以快速出成果。一些咨询项目的落地，也可以采用这种方法。 现实中也的确有不少公司采用这种方法，但是，这种技术路线通用性较差，不适合产品化。

2、借用大模型的能力，直接生成

LLM（Language input）=∑ SQL

大模型出来以后，大家发现确实具有很强的通用能力。拿业界最好的GPT4来看，简单问题的SQL生成正确率80%左右，复杂问题就要差很多。

    图6-ChatGPT

事实证明LLM是一种从通用性上来说很好的信息压缩算法，但它也存在各种问题。Text2SQL这个领域，不仅仅是训练数据不足的。我们前面讲过这种预测下一个token的随机概率机是没办法保证结果的正确性的。目前能做的工作就是堆更多的数据，加更多的参数，降低出错概率。理论上讲，这种改良总有一天可以达到生产标准。但是，从当前的模型能力来看，这种投入产出比还太低，花费高昂的成本，模型的提升有限。在处理局部领域问题时，这显然是一个效率很低，相当不经济的技术路线。

总体上来讲，基于大模型生成SQL的技术路线，适用范围仍然较窄，更多的用于数据库工程师赋能。由于业务人员一般缺乏SQL代码的审查能力，因此，不适合用于业务人员的自助分析场景。当然，依赖于这种技术进行产品化，风险也相对较高，交付成本偏高很可能不具备商业价值。

3、用大模型收敛问题，用领域特定模型获得精确解

FS（LLM（language input））=∑ SQL

如果我们把问题分解成，用LLM处理语言表达上的复杂性，但不要求精确解，而用一个小模型如Focus Search处理查询逻辑上的精确性，这种组合处理方式，就可以获得局部问题的最优解。Focus Search是我们花了8年时间打造的Text2SQL引擎，具有远高于大模型的解析效率，只有CPU就可以运行，并发处理效率超过大模型的3个数量级。    

DataFocus的两级Text2SQL模型

这三种技术路线各有优劣，下面这个列表做了大致的总结。可以看出来，Copilot这种方法就是市面上最常见的方法，本质上就是枚举，先人工后智能。这种方法优势很明确，就是结果可控，面向业务场景，可落地。如果有很强的落地实施能力，而企业用户又没有太多个性化的要求，用这种方法可以快速完成交付。

而完全依赖于大模型的Chat-to-DB模式，更多的可以用于有一定SQL编程基础的用户使用，这本质上就是让大模型帮忙写代码，更快更高效，但是使用范围就比较有限，也没办法推广给无技术背景的业务用户使用。

第三种方法是DataFocus的技术路线，优点就是可以低成本的实现精确的自然语言到SQL的查询转换，并且无代码技术的业务人员也可以轻松用起来。这个技术路线既有效的利用了大模型的自然语言处理能力，又规避了其幻觉问题，并且有效降低了成本。

GIF图7-小慧

值得一提的是，DataFocus沉淀下来的这一套技术方法，已经形成了组件级的能力，可以API的方式提供给第三方调用。我们欢迎有志于ChatBI开发的产品经理，使用DFC的小慧+Focus Search解析引擎，高效实现精准自然语言到SQL的解析功能，成本比以上两种方案低得多。