本文访谈对象：

◇ Q：衡石科技小石头

◆ 刘诚忠：衡石科技创始人& CEO

◆ 赖林华：衡石科技联合创始人& CTO

◆ 陈家耀：衡石科技首席数据科学家

◆ 韦仕硕：衡石科技资深后端工程师

◆ 陈俊豪：衡石科技资深前端工程师

Q：从 ChatGPT 问世以来，ChatBI 的热度就一直在提升，为什么大家这么关注 ChatBI 领域？

刘诚忠：大家对 AI 的关注和投入都是好事，但总归要落地到某个应用上，技术本身不是应用。其实就当前大模型的能力而言，toB 企业内部真正可以落地的严肃应用场景目前还很少，ChatBI 算是一个既可务实落地又有明确价值的应用场景。

Q：为什么这么说？能展开详细说说这背后的原因么？

刘诚忠：ChatBI 的需求并不是来自这波 AI 的技术进步，而是来自 BI 行业实实在在的长期需求。报表的消费者即业务人员，很难随心所欲的进行数据洞察的探索，因为他们的工作需要 BI 工程师和数据工程师的配合，在看报表时脑中冒出的想法问题无法即时去触及，还需要数据团队在数天后才能给出调整好的报表，这是过去很长时间一直在发生的情况。如何降低业务人员数据探索的门槛，一直是这个方向上待解决的关键问题。

实际上，通过自然语言进行查询及探索的产品工作在 BI 领域已经开展了近二十年了，受限于技术能力，一直效果不佳。ChatBI 的出现直击了这个痛点，让业务人员可以真正开展探索性的工作，而不用完全依赖提前定义的静态报表，这是决定性的提升。

Q：ChatBI 是 BI 的新形态吗？

刘诚忠：准确来说，ChatBI 是 BI 产品的新的使用形态，不是 BI 本身的新形态。ChatBI 和 BI 不是同一个层面的概念。BI 装配 ChatBI 能力。

Q：也就是说，有 ChatBI 了依然还需要 BI 工具？

刘诚忠：对的。企业级 BI 不是看看报表或者探索问题的动作，而是通过数据准备、数据建模、指标体系建设，到最终控权发布传播的系统工程。现代化的 BI 工作其本质在于建立一个完整流程或通道，让数据通过建模去表达出一个明确信息（通常是KPI）。工具平台则保证了这个信息可以轻松、实时的被监控到，也可以灵活的被关联到。

ChatBI 是这个事情里异常闪亮的最后一公里，将大大提升 BI 的普及率和使用效率。也非常有利于组织内部更快形成数据文化，用数据说话。

需要澄清的是，BI 工具不等于报表工具。单一的报表工具，会受到比较大的冲击，这是肯定的。报表是以展现汇报为目的的一个工作场景，但这个场景通常还会对应一个工作流程，所以AI也不会完全取代报表。

另外，ChatBI 也不会是 BI 唯一消费形态，不适合构建独立产品，这太狭窄了，这么思考的产品经理可能没有真正接触过 BI 工作。预先设定好清晰简洁的报表，交互式看板，数据大屏依然会是主流。绝对不能简单偷懒的理解今后就只需要 ChatBI 了，因为提问可能是很好的探索形态，但并不是最高效的信息传播方式。

Q：那么 AI 的迭代发展是否会颠覆 BI 行业？

刘诚忠：我们的判断是，AI 会极大体现并增强 BI 的价值。

非常有启示的信息是，这一年多看到大量的 ChatBI 项目失败了，失败根源就是简单粗暴把 LLM 怼到数据上，而没有很好的去结合 BI 去做实数据建设，这反过来说明了 BI 的价值。

如果要从落地一个项目的视角来观察，可以理解 BI 工作其实在用最低成本构建企业内部数据资产的小模型，然后引导结合大模型精准落地。所以想要落地好 ChatBI 效果，请大家做好 BI 基础建设吧 lol。

Q：所以在 AI 的技术浪潮中，衡石做了什么？未来又有哪些方向性规划？

刘诚忠：衡石团队在过去几年专注做的是一个 BI PaaS 的基础平台产品。我们希望各种企业应用如 ERP，CRM，HCM，MA 等可以随心所欲的调用 BI 能力去零代码构建数据分析场景。衡石的合作伙伴们通常是某一个领域的专业软件厂商。

我们认为 ChatBI 会更进一步的整合进业务场景，很快成为这些企业应用的标配能力，并对外提供给他们的客户使用。衡石会通过产品创新加速助推这个趋势，这能够重构整个数据分析市场的供给关系，并最大化标准产品的价值。我们希望通过 hengshi inside 的方式让所有的软件厂商伙伴都成为自己的垂直领域里具备企业级 BI+AI 能力的数据智能服务商。

Q：回到项目本身，衡石在23年底就启动了 AI 专项的项目组，在我们项目组的研判里，基于 LLM 的特性和 BI 领域的特性，BI+AI 有哪些落地场景？

陈家耀：虽然在众多 ChatBI 的宣传视频中，AI 仿佛无所不能，既能进行数据建模，开发 Dashboard，又能像业务专家和数据科学家那样开展数据预测与根因分析。但实际情况是，不同角色的用户对于 ChatBI 的需求有着天壤之别。

要真正让 ChatBI 发挥价值，精准识别目标用户及其需求场景是关键。一方面，不同场景下用户需求的侧重点截然不同；另一方面，应对场景需求的技术实现路径也会大相径庭。

Q：目标用户和需求场景决定了最终落地场景，那么BI中有哪些关键角色？每个角色目前都受限于哪些问题？

陈家耀：从 BI 中的角色划分来看，用户可分为报表开发者和报表消费者。

报表开发者最为关注的是如何借助 AI 更高效地开发出可发布的 Dashboard，其关键需求在于提升开发效率。因此，他们对 AI 的期望主要集中在批量调整报表样式、构建图表度量计算表达式等方面。

报表消费者，他们业务经验丰富，却缺乏数据素养，难以自行获取数据，或利用统计技术快速从数据中发现洞见，所以他们急需 AI 扮演数据助手的角色。进一步细分，业务人员所需的数据助手，在不同场景下需求也各有不同，可能是能随时查询特定关键指标的查询助手，也可能是进行数据预测和归因等高级诊断分析的数据科学家，或是能够撰写行业数据分析报告的行业专家。这几种场景对于AI的能力要求也差异很大。

Q：那分析了以上角色和场景需求，我们为什么优先选择了赋能业务人员？

陈家耀：一方面，赋能业务的价值更直接，满足业务人员的需求就是解决了分析需求的源头，同时也能减轻开发人员定制个性化报表的压力。

另一方面，ChatBI 对于业务人员来说，是补足了他们急需的技术能力；而对于开发人员来说，ChatBI 只是 Better to have，只是对现有能力的增强，是效率提升工具。

Q：刚才也提到业务人员的需求场景也很多，怎么优先选择了智能查数？为什么不先做看上去更 fancy 的诊断性分析，类似解读、预测等场景？

陈家耀：当前最主要还是 LLM 模型能力的制约。诊断性分析需要很强的推理能力，比如归因分析、what-if 分析。而当前主流的混合专家模型，本质上是个文科生，无法承接这一类需求。当然，在近期 OpenAI o 系列、DeepSeek-R1等推理模型逐渐成熟后，该问题有望能够解决。

另一个原因，诊断性分析需要大量的本地知识作为输入，本质上是定制化很强的项目。比如同样是做营销分析，做品牌营销的企业可能集中关注曝光覆盖的人群，做效果影响的企业可能关注的是后续转化行为。衡石作为标准化产品，不太适合直接提供这样的解决方案，更应该是合作客户，基于衡石的 AI 分析能力，结合自己的本地场景知识，构建出适合自己场景的智能归因、智能预测等功能。

Q：前面刘总也提到去年很多 ChatBI 项目都失败了，那衡石内部怎么分析失败的原因？业界去年都在尝试 NL2SQL，衡石内部怎么看？

陈家耀：从这波大模型浪潮开始兴起，关于 ChatBI 的落地就一直有两种路线。一种是 NL2SQL，在数据库表的基础上直接对接大模型进行问答，大部分是数仓厂商提出的方案；一种是 NL2DSL，一般是 BI 厂商提出的方案，将用户的问题调用 BI 结构化的查询接口，由 BI 下发相应查询。

其实不管是 NL2SQL，还是 NL2DSL，最终都是将用户的问题，转为一段（或若干）查询 SQL。

而问题→SQL 这件事情看起来很简单，但实际是一个包含诸多本地信息输入的复杂过程。如果我们拆解一下，可能包括下图中的多个步骤：

NL2SQL 其实是让大模型直接完成上述所有工作，其间辅以相应的本地知识库文档，这对大模型的理解能力和推理能力提出了极高的要求。假设每一小步，都有10%左右的准确率逃逸，整体下来，准确率就可能从100%降到30%~40%左右。

这也是，谷歌、智谱等顶级团队进行过类似方案的验证后，最终都没有得到理想的准确率效果的原因。

因此行业内大家的认知都逐渐转为 NL2DSL。这也是衡石一开始就采取的路线。

Q：NL2DSL 又有什么优势？衡石在 NL2DSL 方向上有什么优势？

陈家耀：与 NL2SQL 不同，在 NL2DSL 中，大模型只需要完成第1步，也就是将用户的问题，转为一个规范的结构化查询，其余的过程都基于 BI 平台本身的能力和信息完成。

这个方式的好处，一方面是问答准确率高。大模型只需要处理很少的工作，也是它最擅长的工作（意图识别和翻译），对大模型的要求低了很多，也更容易保证模型回答的准确率，其他步骤借由 BI 的能力可以保证100%的准确率。

另一方面，本地知识迭代和维护的成本很低。很多本地数据知识的工作，不需要再额外维护知识库文档了，本身 BI 平台使用的过程中（数据表的关联模型、指标库维护），就已经自然而然地沉淀下来。

采用使用 NL2DSL 方式，实现的关键是，相应的 DSL 是否具有简洁而又足够强大的表达能力（绝大部分用 SQL 能实现的复杂逻辑应该能用 DSL 简洁地写出来）。比如微软 PowerBI 的 DAX，可能就是这样一种比较理想的 DSL。而衡石从18年开始就自研了类似DAX这样的语义层能力（HengshiQL），这也是衡石能在 BI 厂商中较快上线 ChatBI 的一个关键因素。

24年中国软件大会上陈家耀讲述衡石 ChatBI 技术方案

Q：技术方向很明确，这中间也有很多细节，先聊聊最关键的，结合查数的场景，大模型的选型有什么考虑？

陈家耀：在 BI 场景中的模型选择，准确率是最重要的因素。

商业分析对精确度的要求极高，数据无法查询只是影响决策速度，但数据查询错误则可能导致致命的决策失误。所以一般在 BI 分析中，准确率低于80%就很难有客户使用。

其次的因素是性能，数据探索需要切换不同的数据切面和频繁追问，响应过慢容易让用户失去提问耐心。

最后是成本。但目前国内外的环境下，普遍成本都降到比较低了，所以对选型的影响相对比较小。

Q：在研发初期测试了哪些模型？DeepSeek是怎么引起我们注意的？

陈俊豪：最开始的时候，ChatGPT 的输出质量一直是最高的，也是成本最高的，Moonshot 确实在效果和成本上都很不错，但受限于 API 速度，我们内部用的一直不多，智谱在效果上跟 Moonshot 是一个梯队，成本比 Moonshot 高，但是 API 速度更快，对于我们的测试和演示来说速度也很重要。

24年8月模型内部测试结果

韦仕硕：DeepSeek V1开始价格方面就很有优势，差不多是同期 API 价格最低的，模型能力却是排在前列的，一直是性价比最高的模型。这也吸引我们持续关注。

去年 OpenAI 的推理模型 o1出来后，一直有传闻，国内 DeepSeek 和阿里巴巴都分别在尝试做推理模型，没想到是 DeepSeek 第一个取得突破，并产生如此大的影响。DeepSeek R1把整个思维过程展示出来，对于当前大模型不能保证100%正确的情况下，更容易获得用户的理解，并给用户改进问法提供了方向，是一个值得学习的产品特性。

Q：我们接入 DeepSeek 的过程中，有没有什么精彩的小故事可以蹭一蹭热度？

陈俊豪：我们在接入初期测试的时候就发现，DeepSeek 对中文的处理比 ChatGPT 更好，这说明 DeepSeek 确实是国产模型而不是当时有人传言的套壳 GPT。

Q：这一年来，我们项目组的成员一直在研究大模型，研究怎么和 BI 结合做出更好的效果，有什么沉淀和心得？

赖林华：BI+AI 应用，和其他使用 LLM 构建的比较完整的 AI 应用一样，是重度依赖 RAG 的。不仅依赖信息类知识，也依赖领域经验，还需要动态获取 API 服务的数据，并且可能需要这些知识、经验、数据来动态组织形成复杂的执行链得到最后的结果。如何编排这个执行链是一个大话题，实际上基于开源项目 LangChain 已经有许多框架进行不同的尝试。粗略来看的话，可以大概分为 Function Call、Agent 和 Workflow 几种方式。

Function Call 倾向于让 LLM 一次性完成结果生成，Agent 则是让 LLM 来进行多轮路径规划来驱动 API  调用，而 Workflow 的方式则是在确定的处理流中调用 LLM 和其他 API。

Function Call 的方式对 LLM 的要求是比较高的。我们目前的实践中看来 Workflow 的方式在准确性、可控性上才可以达到一个可用的状态，但是它处理不了用户比较随机的，预设之外的问题。因此我们采用的是固定 Workflow+Agent 兜底的方式，通过固定 Workflow 来解决大部分的数据域场景的问题场景，通过 Agent 的方式来让 LLM 尝试理解并规划新的 Workflow。

在这个框架下，大模型展现出了较好的自适应能力，能够满足我们对能力要求的上下限。LLM 能力弱的情况下固定的 Workflow 可以保证预设的数据查询能力，LLM 强的情况下则可以响应更多的 Ad-hoc 的指标生成需求。

Q：类似 DeepSeek-R1这样的新推理模型的出现，会带来什么变化？哪些场景适合，哪些场景可能不适合？

陈家耀：推理模型的出现，让一些复杂的分析问题，有可能得到比较好的回答。

推理模型和混合专家模型各有特点。相对混合专家模型，推理模型擅长逻辑推理，但性能较差。

即使对于查数问数这样的场景，其实不同环节也会有不同的模型适用。个人认为，简单的数据查询问题（本质上就是检索指标和匹配维度），不需要很强的推理能力，适合用混合专家模型，快速地问答。从衡石的实践看，混合专家模型基本能回答好一些规范的、明确的、简单的数据查询问题，比如“昨天xx平台的销售完成率是多少？”。这种场景用推理模型，就有些杀鸡用牛刀，而且性能还不好，一个问题的回答时间要从10s变成1~2分钟。

而复杂问题，特别是需要拆解多步骤的问题，往往混合专家模型回答很差，比如“昨天总体销量比元气森林高的品牌，主要是在哪些平台上销量超过了元气森林？”。类似问题其实就需要引入推理能力，将问题拆解成多个子问题，且子问题间涉及依赖数据的填入，这种情况下推理模型就大有用武之地了。

不过即使复杂问题，也不一定完全由推理模型回答，最终实现上，个人认为很可能还是多个模型相互配合，能达到比较好的性能和效果平衡，比如由R1进行问题拆解，V3封装简单的查数接口作为工具让R1调用，既能满足推理需求，又能提升回答性能。

Q：这波热度非常高，除了用好新类型的模型之外，衡石对 ChatBI 的发展趋势还有什么看法？

陈家耀：被集成，是 ChatBI 的最终形态。

一直以来，数据分析领域，分析与业务流程的深度融合就是一个不可逆的趋势。数据分析本身是为了驱动业务决策，BI 报表应该被打散嵌入在日常的决策流程中，而不是独立的一个系统平台。随着 ChatBI 带来零门槛分析能力，分析助手更应该在任何需要进行业务决策的页面、对话框内被随时随地唤起，提供精确的决策辅助数据。因此，ChatBI 应该被嵌入任何需要的应用和页面。

另一方面，随着企业内其他AI应用的场景越来越多，ChatBot 本身承载的 AI 能力，很可能不会仅局限于数据分析。作为一个 AI Agent，与其他 AI 应用一起，被整合到一个统一的 ChatBot 中，很可能是大多数 ChatBI 的最终形态。