ChatBI三种实现路径对比评析

先说说几个核心判断。

DataFocus在ChatBI这个方向上摸索了八年。从第一版开始，交互方式就只有一种：一个对话框，或者说，一个搜索框。这背后是一句话：问答即交互，搜索即分析。

选择这条路，填过的坑可以写一本书。今天聊的，是这些年积累下来的心得体会，希望能给正在做ChatBI产品的同行们一点参考，少走些弯路。

先统一一下概念。ChatBI是个新词，大模型火了之后，所有交互都想往对话上靠，才有了这个叫法。查了一下，大概网易有数或者帆软BI都开始用这个说法了。在这之前，行业里管这叫搜索式BI。国外最早做的是ThoughtSpot，国内起步最早、产品最成熟的是DataFocus，后来还有个创业公司北极九章，也做同样的事。

到底什么是ChatBI？两个维度看。
从产品角度，能chat的BI就是ChatBI——交互方式变了，但BI的基本功能不能少，像数据接入、看板制作这些。
从用户角度，能聊天提问就能做数据分析的软件，就叫ChatBI。

两个角度都绕不开一个核心：用问答的方式取用数据。取最小公倍数，就是——用自然语言去查数据库。

所以，ChatBI要解决的本质问题，就是一个Text2SQL（或者说NL2SQL）的问题。我们需要找到一种函数或算法，实现从自然语言到SQL查询语句的精确映射。这件事难在哪里？自然语言的表达空间是无限的，SQL虽然是一种领域特定语言，但同样是无限的。这和翻译不一样——英语翻译，直译、意译、各种说法都算对。但Text2SQL必须完全精确，一点偏差都不能有。

Text2SQL的研究并不新鲜。IBM研究团队做过，Salesforce也挑战过，还建了一个不小的WikiSQL数据集。学术界也有大量研究，远的有哈佛的SpiderSQL数据集，近的有阿里巴巴和香港大学联合推出的BirdSQL。

十几年前，深度学习技术被引入这个领域，Sequence2Sequence、Bert、T5……各种模型都有进展，但收效不大。核心问题还是准确度不够。做别的事可以，但企业级用户在真实场景里用不了——数据这东西，准就是准，不准就是不准，马虎不得。

转折点出现在ChatGPT。大家发现大模型在Text2SQL上的进步非常明显，GPT4在简单问题上已经能达到相当不错的准确率，SpiderSQL这个数据集最近一年甚至被GPT4的方案刷了好几次榜。整个行业都兴奋了起来，工业界迅速跟进，ChatBI这个概念一下就火了。

目前来看，做一款ChatBI产品，主要就三条技术路线：

1. 最直接的方法：靠枚举硬来

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

就像小朋友做算术题。10以内的加减法掰手指，20以内的加脚趾，但手指脚趾总有不够用的时候。枚举法最直接，也最笨拙。

这条路实施成本高，适合定制化项目——企业有人力有技术，用这种方式自研可以快速出成果。一些咨询项目的落地也确实在用。但缺点很明显：通用性太差，不适合做产品。

2. 借大模型的能力，直接生成SQL

LLM（Language input）= ∑ SQL

大模型的通用能力确实强。拿业界最好的GPT4来看，简单问题的SQL生成正确率能到80%左右，但复杂问题就掉得厉害。

LLM本质上是很好的通用信息压缩算法，但问题不少。Text2SQL这个领域，不仅仅是训练数据不够——我们前面说过，预测下一个token的随机概率机，没办法保证结果的正确性。现在能做的事就是堆更多数据、加更多参数，降低出错概率。理论上有一天能达到生产标准，但眼下的投入产出比太低——花大价钱，模型提升有限。在局部领域问题上，效率很低，相当不经济。

总的来说，用大模型直接生成SQL，适用范围还比较窄，更多是给数据库工程师提效用的。业务人员一般没有审查SQL的能力，这条路不太适合做业务自助分析。想做产品化，风险不小，交付成本偏高，商业价值存疑。

3. 用大模型收敛问题，用领域模型拿精确解

FS（LLM（language input））= ∑ SQL

换个思路：用LLM处理自然语言表达上的复杂性，但不要求它给出精确解；精确的查询逻辑，交给一个小模型——比如FocusSearch，这个我们花了8年打磨的Text2SQL引擎。它的解析效率远高于大模型，只有CPU就能跑，并发处理效率比大模型高三到四个数量级。

三种路线，各有优劣，下面这个表格做了总结：

补充一句。Copilot路线，说白了就是市面上最常见的那种做法，本质上是枚举，先人工后智能。优势是结果可控，面向业务场景能落地。只要实施能力强，用户没太多个性化需求，交付可以很快。

完全依赖大模型的Chat-to-DB模式，更适合有SQL基础的用户——本质就是让大模型帮忙写代码，效率确实高，但适用范围有限，推广给没有技术背景的业务人员，不太现实。

DataFocus走的是第三条路。优势在于能用低成本实现精确的自然语言到SQL的查询转换，没有代码基础的业务人员也能轻松上手。既用上了大模型的自然语言处理能力，又绕开了幻觉问题，成本也降下来了。

值得一提的是，这套方法已经沉淀成了组件级的能力，可以以API的方式提供给第三方调用。对于正在做ChatBI产品的团队来说，用DFC的小慧加上FocusSearch解析引擎，实现精准自然语言到SQL的解析，效率比前两种方案都要高。

来源：互联网