2025年被视为AI Agent元年，ChatBI作为企业关注的重点领域，在实际应用中面临诸多挑战。文章对比了NLP2SQL、基于指标平台和基于报表系统三种ChatBI解决方案的优缺点。NLP2SQL方案灵活但准确率低，计算成本高；指标平台方案数据一致性高，但前期投入大，灵活性差；报表系统方案能充分利用现有投资，但受限于现有系统。我司目前采用基于指标平台方案，并探索NLP2DSL的方式，以提升问答准确率。要改善ChatBI表现，需优化提示词、丰富知识库、微调模型、持续监测与迭代。

✨NLP2SQL方案：允许非技术用户通过自然语言查询数据，即时获得数据洞察，提升效率。但存在“幻觉”风险，计算成本高昂，且在处理大型数据库模式时面临挑战，SQL效率也需优化，并高度依赖高质量的训练数据和严格的数据治理。

📊基于指标平台的方案：通过预定义业务指标，确保数据一致性和准确性，统一指标口径，减少“幻觉”和误解的风险，简化LLM任务，统一数据治理。然而，前期投入大，需要构建和维护全面的语义层，对高度碎片化或定义不一致的数据环境构建复杂，灵活性差，只能回答预定义的指标，覆盖范围有限。

📈基于报表系统的方案：充分利用现有BI工具和数据基础设施的投资，用户接受度高，部署速度快，可视化能力强。但洞察深度和灵活性受限于现有报告结构和数据模型，现有BI平台可能更新缓慢，集成复杂性高，数据质量依赖性强，仅能回答已有报表范围内的问题。

🔑提升ChatBI问答准确率的关键：优化提示词，精确定义用户查询与系统响应关系；丰富和完善知识库，定期更新数据库内容；考虑微调模型，使其适应特定领域的术语和场景；持续监测与迭代，建立有效的反馈机制。

背景

2025年被视为AI Agent发展的元年，这一年标志着AI技术特别是智能代理（Agent）进入了一个全新的发展阶段。随着技术的不断成熟与普及，各行各业见证了大量创新性AI Agent的诞生。从大型跨国公司到初创企业，不同规模的企业都在积极探索如何将AI Agent融入自身业务流程中，以提高效率、降低成本，并为用户提供更加个性化和高效的服务体验。
在这股浪潮中，ChatBI成为了众多企业关注的重点领域之一。ChatBI是指结合了聊天机器人技术和商业智能分析能力的一种新型应用模式。它不仅能够通过自然语言处理技术理解用户需求，还能够基于大数据分析给出精准建议或解决方案。对于零售业来说，这意味着可以通过ChatBI来提供更加个性化的购物推荐；对于医疗健康领域，则可能意味着患者可以获得更加快速准确的初步诊断建议；而在金融服务行业，ChatBI则可以帮助投资者更好地理解市场动态并做出投资决策。
在尝试构建和实施ChatBI的过程中，虽然其潜在价值显而易见，但实际操作中却面临着诸多挑战。这些困难可能来源于技术限制、成本考量、用户接受度等多个方面。为了更好地理解当前市场上流行的几种ChatBI解决方案及其各自的优缺点，接下来我们将进行详细的探讨。

NLP2SQL

自然语言翻译成SQL，这也许是大部分的企业都会想到的第一个实现方案。其实现流程如下：

用户在页面上选择数据集，然后开始进行提问。大模型的system message为生成SQL的规则提示词，user message为第一步选择的数据集的表结构以及用户的提问，主要基于这三个组成部分，生成SQL。大模型生成的SQL，再去数据库里执行，得到的数据返回到UI界面上，进行可视化展示。用户可以选择图表，柱状图，折线图，饼状图等展示。也可以再有一个大模型，负责对查询结果进行数据解读

大家可以参考一个dify的案例：

这是大模型直接生成SQL的示例，他的优缺点如下：

优点：

数据访问民主化： 允许非技术用户直接通过自然语言查询数据，无需学习 SQL 或理解复杂的数据库结构。即时洞察： 能够快速响应查询，提供实时数据洞察，加速决策过程。效率提升： 自动化 SQL 生成和可视化，显著缩短报告创建时间，例如将数小时的工作缩短到数分钟。对底层数据透明：不依赖已有报表或指标体系。灵活性强： 支持任意 SQL 查询能力，适用于结构化数据分析。

缺点：

“幻觉”风险： LLM 可能会生成不准确或不可靠的 SQL 查询，即所谓的“幻觉”。计算成本高昂： LLM 直接生成复杂 SQL 的计算成本可能很高，且容易出错。模式复杂性挑战： 在包含数百甚至数千列的大型数据库模式中，LLM 可能会因token限制而难以有效处理。SQL 效率问题： 生成的 SQL 查询可能并非总是最优，需要额外的优化来减少数据库负载和提高响应速度。数据质量和训练数据依赖： 高质量、领域特定的训练数据难以获取，且数据质量问题可能导致错误的查询结果。安全与信任挑战： 存在提示注入、敏感信息泄露、不当输出处理等安全漏洞，需要严格的数据治理和访问控制。

基于指标平台

基于指标平台的方案，其核心思路是预定义业务指标（如 GMV、转化率），通过自然语言匹配指标口径并返回结果。

实现流程如下：

先在指标平台上把业务指标和相关维度都设置好。用户用自然语言提出查询问题。第一个大模型会根据用户的问题找出需要查询的指标名称或别名。用第三步提取出来的指标名称去指标平台里查对应的定义，看看这个指标可以用哪些维度。把用户的问题和第四步得到的指标定义一起给第二个大模型，让它提取出指标名称、适用维度、筛选条件、排序规则、时间范围和返回条数等基本信息。用第五步提取出来的信息再去调用指标平台的接口进行查询。最后，把查询结果展示在前端，让用户能直观看到。

优缺点如下：

优点：

数据一致性与准确性：语义层提供“单一事实来源”，确保不同工具和用户查询结果的一致性，指标统一口径，解决了数据孤岛和指标二义性的问题，并帮助 LLM 准确理解领域特定知识。业务上下文理解：LLM 能够更好地理解业务术语和指标，减少“幻觉”和误解的风险。简化 LLM 任务：LLM 可以生成更简单的中间格式（如 JSON），而不是直接生成复杂的 SQL，从而提高生成的一致性和准确性。统一数据治理：语义层有助于集中管理数据治理、访问控制和安全策略，确保敏感数据的保护。查询优化：语义层可以预定义和优化查询逻辑，提高数据查询性能。

缺点：

前期投入大：构建和维护一个全面、准确的语义层需要大量的前期工作和持续投入，包括定义指标、数据模型和元数据。复杂性管理：对于高度碎片化或定义不一致的数据环境，语义层的构建可能非常复杂。“人工干预”需求：尽管自动化程度高，但仍需要“人工干预”来验证和创建重要的指标定义，以确保数据质量和准确性。灵活性差：只能回答预定义的指标，难以支持自定义查询，重度依赖指标平台。覆盖范围有限：不能解决非指标类的问题。

基于报表系统

其核心思路是对接现有报表工具（如 Tableau、Power BI），通过自然语言指令调用预制报表或仪表盘。

实现流程如下：

预先在BI系统上，构建报表。用户用自然语言提出查询问题。大模型用于意图识别，报表匹配，通过问题语义匹配最相关的报表然后通过BI提供的API，或者其他集成方式，或者爬虫技术，获取到报表的数据/图表将结果展示到前端页面

当然，第四步也可以不通过额外的方式获取数据，直接打开报表页面也是可以的。

优缺点如下：

优点：

充分利用现有投资：组织可以继续利用其在现有 BI 工具和数据基础设施上的投资，降低新系统的实施成本和风险。用户接受度高：用户可以在熟悉的 BI 环境中通过自然语言进行交互，减少学习曲线，提高新功能的采用率。快速部署：由于是基于现有系统进行增强，部署速度可能相对较快。可视化能力强：继承了现有 BI 工具强大的可视化能力，能够自动生成高质量的图表和报告。

缺点：

受限于现有系统：洞察的深度和灵活性可能受限于现有报告和仪表板的预定义结构和数据模型。如果现有报告存在数据孤岛或僵化模型，ChatBI 也会受到影响。平台演进速度：现有 BI 平台可能更新缓慢，缺乏支持 ChatBI 所需的动态功能和高级 AI 能力。集成复杂性：与各种 BI 工具和报告定义进行无缝集成可能仍然具有挑战性。数据质量依赖：最终洞察的质量仍然高度依赖于底层报告系统的数据质量和准确性。灵活性差：仅能回答已有报表范围内的问题。另外，无法应对个性化组合查询，如组合多个报表、修改维度粒度等。报表很多的时候，匹配的准确率也会下降。

总结对比

方案	灵活性	易落地性	可控性	成本	依赖项	适用场景
NLP2SQL	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	高质量结构化数据、NLP能力	数据自由查询、探索式分析
指标平台方案	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	完善的指标平台	核心指标查询、运营分析
报表系统方案	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	报表命名规范、检索系统	固定报表问答、低成本上线

推荐落地方案

我司目前采用的是基于指标平台方案，高度依赖指标平台，目前正在测试阶段。

之前我们采用的是NLP2SQL的防范，经过一些客户现场的检验，我们发现NLP2SQL的方式，准确率实在是太低，尤其是多表连接、复杂聚合等场景。 单表的准确率稍微高点，但是用户习惯性术语有的时候令大模型很难理解。

同环比如何计算，或者说衍生指标的计算逻辑，实际上这个就是典型的多表连接，复杂聚合的场景，大模型很难生成正确的SQL。太依赖Schema定义了，表结构定义必须要有表描述信息，表的别名的维护，字段名，字段类型，字段描述，字段别名等维护。需要严格的数据标准，元数据治理。SQL方言的差异性，Doris/Clickhouse/Hive等OLAP引擎数据库，语法各不相同，虽说大家都遵循sql 92/95标准，但还是会有差异，比如分页，函数，数据类型等用法就不一样。

换成了指标平台，SQL的准确度得到了保证，准确率从生成SQL的问题转变成了语义解析的问题。但也还是会有相同的问题，比如用户的一些行为习惯

当用户说一些时间范围的时候，比如“当下”，“当今”，“如今”，“本年”，“目前”，“截止到目前”，“现在”，“截止到现在”等，大模型有的时候确实会理解不了，不能正确给出startTime和endTime当用户说一些业务相关术语的时候，比如大订单，不合格的订单，优秀的产品等等，大模型如何理解何为大订单，何为不合格的订单，何为优秀的产品等。当用户说部门，或者店铺名称，店铺地址，都是简称，大模型无法理解，SQL也不支持分词查询。例如上海步行街店铺，用户不知道具体的店铺地址，就直接说这样的地址，对于SQL而言，只能实现左右模糊查询，address like '%上海步行街%'，但是对于用户，他想实现的SQL是 address like '%上海市%步行街%'，这种模糊匹配，这是指标平台和SQL，报表都无法直接解决的问题。

所以的话，除了要有指标平台，也要有提示词的维护管理，数据不一定要从数据库里查询，也可以从es里获取，我们可以把指标平台的方案，抽象成NLP2DSL的方式，直接根据es rest api获取到指标查询的结果。

当然，有兴趣的同学，也可以将NLP2SQL，NPL2DSL，报表系统，混合起来使用，以 NLP2SQL 为核心，通过语义层提供统一的业务上下文和数据治理，并与现有 BI 报表系统无缝集成以提升用户体验和利用现有投资。同时，将数据安全、权限管理和持续的人机协作作为贯穿始终的关键要素，才能构建一个高效、准确、可信赖且易于采用的智能对话式商业智能系统。

总结

ChatBI正逐渐成为众多企业竞相探索的第一个Agent应用场景。然而，在实际应用过程中，许多组织发现其效果可能并未达到最初的预期。面对这样的情况，如何有效提升问答准确率成为了亟待解决的问题之一。
要改善ChatBI的表现，可以从以下几个方面入手：

优化提示词：通过更加精确地定义用户查询与系统响应之间的关系，可以帮助模型更好地理解问题背景及意图。这包括了对输入文本进行更细致地处理，比如使用自然语言处理技术来识别关键信息点等。丰富和完善知识库：一个全面且结构良好的知识库对于提高回答准确性至关重要。这意味着需要定期更新数据库内容，并确保其中包含最新最全的信息资源。此外，还可以考虑引入外部数据源以进一步扩展知识覆盖面。（存疑？知识库质量层次不齐，知识库如何更新，是否有必要有知识库）考虑微调模型：如果标准预训练模型无法满足特定业务需求，则可以考虑对其进行定制化调整。通过对模型进行专门训练或微调，使其能够更好地适应特定领域的术语和场景，从而提高相关问题的解答质量。持续监测与迭代：建立一套有效的反馈机制，收集用户互动数据并分析模型表现。根据反馈结果不断调整优化策略，形成良性循环，逐步提升整体服务水平。

总之，虽然ChatBI在初期可能会遇到一些挑战，但通过上述方法的综合运用，运用得当的话，可以显著提高其性能，使之成为真正助力企业发展的重要工具。同时，随着AI技术的不断进步，未来ChatBI将拥有更加广阔的应用前景和发展空间。