Text2DSL（Text-to-DSL）技术是将自然语言转换为领域特定语言（DSL）及在ChatBI中的应用

wangqiaowq

903人浏览 · 2025-09-26 10:04:47

wangqiaowq · 2025-09-26 10:04:47 发布

参考：一文分享ChatBI实践经验,chatbi,saas,CIO之家

“领域特定语言”听起来有点抽象，但可以理解为是一种更易于用户理解和使用的语言，例如在BI领域，它指的是从底层数据集中抽象出的指标、维度和过滤条件等报表配置化参数。

结合SQL这种数据库操作的标准语言，Text2DSL既简化了用户表达，又确保了系统能高效执行查询。

一、用户提问时，大模型依据Prompt来理解用户的需求意图，并将自然语言需求转换为结构化的DSL查询。

二、业务方根据规则将DSL转换为SQL以执行数据查询，并将结果进行可视化展示。

例如：

我要找到华南区上个月业绩表现最好的3名员工

在Text2SQL的方案中，需要大模型对用户的提问进行理解后，输出一段可执行的SQL，如：

SELECT
  f_user_name,SUM(f_amount) AS total_amount
FROM user_performance
WHERE f_department_id='华南大区' /* '华南大区'是部门名称 */
  AND f_date >='2024-11-01'
AND f_date <='2024-11-30'   /* 时间筛选为上个月 */
GROUP BY f_user_name /* 对员工进行分组 */
ORDER BY total_amount DESC /* 对订单成交金额进行倒叙 */
LIMIT 3; /* 取前三 */

在Text2DSL的方案中，会对SQL进行了一层业务封装，只需要大模型识别提问后返回关键参数如：
时间='上月'
数据范围='华南大区'
指标='订单成交金额'
维度='员工名称'
排序='倒叙'

然后业务方基于大模型返回的参数（DSL），根据规则生成对应的SQL，执行查数命令。

由此可见，Text2DSL本质上是一个text to DSL to SQL的过程。简而言之，DSL是对于SQL的一层抽象，而SQL是对于数据输出的具体执行。

缺点：

Text2DSL方案同样面临挑战：基于Text2DSL搭建的ChatBI需要依赖成熟的指标体系，而且查询的灵活性和扩展性受限于现有指标和维度，本质上是报表搭建参数智能检索召回后的自动化数据查询流程。

优点：

但相比于Text2SQL，Text2DSL更易于实现，并且在指标体系能够满足大多数用户需求的情况下，能提供更准确、时效性更强的结果。

Text2DSL：适合业务场景明确，产品已建立成熟的数据资产（例如完善的指标体系和数据服务API）且分析深度可控的情况，如：企业内部系统或垂直业务软件系统的BI工具。

尽管自助分析能满足大多数用户的日常需求，但在实际使用中仍有一些问题：

使用门槛：CRM产品面向的用户主要是销售人员，在配置报表前需要他们掌握“指标”和“维度”等较为抽象的概念，还需要理解每个指标的具体含义，这尤为困难。
数据获取链路过长：即使用户已配置了一个满足业务需求的数据看板，但在实际使用中仍需根据不同的分析场景动态调整过滤条件来获得数据，例如：报表默认配置为“本周直销部的业绩数据”，若临时需要查看“上周渠道部的业绩数据”，需要找到【时间】与【统计成员】过滤条件后，切换条件值。

在前期调研中，我们首选了Text2SQL方案，但经过多次测试，结果未达预期。举个例子：

在当前的自助分析BI产品中，用户可以在一张报表内配置多个跨数据集的指标，例如“通话次数”和“订单成交量”，这些指标存储在不同的数据集中，并且每个指标支持多个实时过滤条件。因此，在技术方案中，我们无法创建太多的大宽表，也无法进行大量的数据预聚合。

前端报表搭建实际上是对底层数据查询的业务封装。用户只需选择适合业务需求的指标来搭建报表，而跨数据集的查询等复杂业务则由业务方统一处理。

然而，这种业务特定的场景并不适用于Text2SQL方法，因为它需要将大量元数据整合到Prompt中以支持跨数据集查询。这在与大模型交互时可能会导致表字段识别不准和返回SQL响应时间过长。

采用Text2DSL方案，该方案本质上是在保持现有报表搭建框架的基础上，将用户手动选择参数和拖拉拽搭建报表的过程交由大模型完成。此外，对于常规SQL难以处理的特定业务查询，Text2DSL能够通过其原生的快速计算功能轻松实现。

Chat BI的业务方案设计。刚开始我们遇到了一些问题：

由于涉及到7个数据域的400多个指标和50多个维度，若全部整合到Prompt中，可能会影响大模型语义理解和意图识别的准确性。
用户对数据指标的叫法各异，例如“订单成交量”可能被用户称为“成交业绩”或“订单转化”等。

BI元数据库和业务知识库进行了向量化存储。BI元数据库涵盖了指标、维度、过滤条件、图表类型、同环比和排序等基本信息；而业务知识库则包含了行业特定术语和针对特定业务的SQL编写规则等垂直领域知识

ChatBI初步的业务流程如下：

一、知识召回：当用户提问时，先通过RAG技术对知识库进行相似度检索，以召回高匹配度的知识。

二、关键信息提取：针对召回的知识动态组装Prompt后让大模型进行语义理解与关键词识别，当无法识别关键词时可通过多轮对话的方式进行交互，直至提取用户提问中的关键信息，如指标、维度、过滤条件等。然后让大模型按照Prompt中的规则返回DSL。
三、SQL转换：接收大模型返回的参数后，进行参数合法性和数据权限校验，确认无误后将DSL转换为SQL以执行数据查询。

四、数据可视化：查询结果后，进行数据报表组装，并在前端进行可视化展示。

这套方案在处理用户常规的结构化数据查询提问，如“昨天入库多少个客户”或“上周打了多少通电话"时表现良好，但在应对例如“总结欧汶本周新增客户的转化情况”或“欧汶最近的业绩表现如何”等要求非结构化回答时就显得力不从心。这是因为基于结构化SQL语言生成的回答显得过于生硬，有时甚至让用户一种答非所问的感觉。

意图识别机制。大模型首先通过识别意图来区分用户是需要简单的数据查询，还是针对特定业务的分析。对于后者，我们会在SQL查询得到数据后，重新组装Prompt，再次利用大模型进行语义理解分析，并根据用户的提问提供针对性的回答。

ChatBI主要聚焦于解答What（是什么）的数据查询，为了帮助用户探索Why（找原因）和How（给方案）的问题，以形成完整的业务闭环，我们从应用层面提供了以下方案。

Why：在数据可视化环节，支持用户根据需要调整维度、指标和图表组件等，以便进行全面分析，并能够根据用户的设定进行“多维分析”以及“下钻分析”。

How：通过“推荐提问”的功能，针对不同指标数据异常的场景，提供针对性的解决方案，如：设置指标预警、调整销售目标、分配销售任务等。

团队还通过嵌入式将 ChatBI 产品整合到多端。PC端用户可以直接在输入框中输入文字；移动端用户则可以通过语音方式描述数据需求，从而快速查询数据，增强用户体验。

参考：放弃幻想，ChatBI其实跟你想的不一样,知识库,chatbi,问答,CIO之家

LLM写SQL不靠谱。

LLM写SQL是真的不靠谱，体现在3个方面：精度、性能和可信性。

1、精度

对业务用户来说，即使再有容忍度，平均精度要达到75%~80%才能保证不会弃用。

LLM幻觉是一个已知问题，它在一定程度上是可以被容忍的，但如果在数据的应用，它会被严重放大；在用户眼里，对于非结构化的数据，结果不满意，大不了我再问一次，而结构化数据答案是不可以错的。

LLM写SQL时，会在哪些地方会有幻觉？目前已经发现并且判断很难解决的地方比如对时间理解错误、排序逻辑错误、子查询错误、错误理解表关联关系等等；

用LLM把用户的问题转写成结构清晰的查询语言（表达清晰的语句甚至不需要转写），用OLAP分析操作指令集调用BI成熟的底座，以模拟人工拖拉拽的形式直接出图，这样生成的图表直接和转化后清晰的问题意图相匹配，精度得到大幅的提升。
2、性能

现在一个写SQL为主的产品，返回一个问题能做到6s已经是优秀了，部分Text2SQL产品的返回时间甚至能到都在12s甚至15s以上。一个问题等10s，这个性能，用户真的能接受么？

一个用户能接受的最长问题的返回时长必须控制在3S内，否则体验太过糟糕，用户也不会坚持用下去；

影响LLM写SQL性能的变量有：LLM模型的尺寸、是否本地化部署、硬件资源投入如何、SQL语句复杂度等；

BI并没有选择让LLM写SQL，而是通过一个小尺寸的语义解析模型处理清晰语义，LLM去处理模糊语义，实现了清晰语义返回平均能到0.2s，模糊语义平均能做到2s。
3、可信性

ChatBI在应用中，难免会有错误的答案，怎么才能排查到结果对错？如果答案是错的，怎么能快速修复？解决这两个问题，才能代表一个ChatBI产品具有可信性。

Text2SQL路线，一般会给到用户一串SQL语句，这个思路最开始被很多IT认可，因为直觉表明这样是可以看清楚答案，也容易调试；实际上，这不是一个用户思维导向的设计：业务用户看得懂SQL么？他们想要看SQL么？另一方面，SQL的调试工作难易程度是和SQL语句的复杂度正相关的，再考虑到多表关联查询，如果在测试期间没有探索到它的边界，在应用实际落地的时候，结果排查和错题修复的挑战会很大。

ChatBI给到了用户一段可以清楚读懂的图表生成规则，同时，用户可以调整其中的维度、指标、枚举值、分组条件等，按照自己的设想二次点选生成新的相关图表；

从用户数、使用频次、使用场景来出发，适合使用ChatBI的用户群：

2、底层准备

1）数据侧

50%的数据消费应用的推动都受到了数据底层准备的影响，ChatBI对数据的要求比BI要更高一些，一般体现在避免字段名歧义、数据不能有冗余、确保字段类型正确等；

准备好宽表，或干脆搭配指标管理平台吧，否则你会无比痛苦。

2）知识侧

知识配置分为两类，一类是同义词，一类是企业独有的一些其他知识，如重点城市=成都市+贵阳市华北地区=山东+山西+河南+河北；

ChatBI中，同义词只需要配置必要的、预计AI肯定猜不出来的企业独有知识，相似的语义或相似的字段是不需要配置的：

对于相似的语义，如字段名为销售额，问业绩，这个通过LLM是可以猜出来的；

对于相似的字段，如字段名为娃哈哈100ml矿泉水，问娃哈哈矿泉水，这个通过算法可以匹配到的。

参考：ChatBI：数据分析的未来,chatbi,决策支持,数据分析,数据驱动,未来,CIO之家

随着技术的发展，聊天式BI（ChatBI）应运而生，成为一种更具互动性和易用性的解决方案。

ChatBI，也称为搜索式BI，是一种采用对话交互方式的商业智能产品。与传统BI工具通过拖拽组件、创建仪表盘和报告不同，ChatBI允许用户通过自然语言查询数据。这种交互方式使得数据分析过程更加直观、灵活和高效。用户只需输入类似于与搜索引擎互动的自然语言问题，系统便能快速解析并返回相应的数据分析结果。