引言

图：阿里云Quick BI产品架构

就我目前所在公司的业务情况，AI+BI也是我认为有落地场景和价值的一个方向（当然从可用资源和投入产出比的角度来看，在我司还不适合推进），因此对这个领域多有关注，是以有本文。

需要强调的是，本文接下来所提到的AI，特指以大语言模型（LLMs）为基础的自然语言能力——即对话式的系统交互支持（毕竟在BI领域还有其他的AI技术可以使用，例如机器学习可用于销售预测）。

• 自然语言处理与理解：大模型的强大自然语言处理能力使用户能够用自己熟悉的语言来查询和分析数据，这大大降低了数据分析的学习曲线，使非技术用户也能轻松上手。此外，大模型能够处理和分析非结构化数据，如客户评价和媒体内容，从而提取出有价值的信息和洞察，为企业提供全面的数据视角。
• 智能推理与预测：大模型不仅能够处理当前的数据，还能够基于现有数据进行推理和预测。这意味着它可以帮助用户识别数据中的异常点、趋势以及潜在的问题和机会，从而为决策提供支持。这种能力对于企业来说极其宝贵，因为它可以帮助企业预测市场变化，提前做好准备。
• 代码生成与自动化：大模型还能够通过自然语言指令生成Python、R等编程语言的代码，这极大地降低了技术门槛，使得即使是没有编程背景的用户也能够完成复杂的数据分析任务。这种自动化的代码生成功能，不仅提高了数据分析的效率，也拓宽了数据分析的应用范围。
• 新的交互形式：大模型引入了基于语言的交互方式，这种交互方式更加直观和自然，用户无需学习复杂的软件操作，只需通过自然语言表达自己的查询需求。这种交互方式不仅提升了用户体验，也使得数据分析工具能够更好地融入用户的工作流程中。

接下来就请随我一起探索一番。

AI+BI的不同模式

LLM在BI产品领域，适合作为现有数据分析手段的有效补充，特别是在即席数据查询、传统BI工具能力提升、简单数据挖掘与洞察等方面。

就目前来看，在自然语言的对话式BI数据分析有3种可行的实现模式：

• text-to-API：即根据用户输入的自然语言，进行意图理解，并匹配调用对应的API；

• text-to-SQL：即根据用户输入的自然语言，进行意图理解，直接生成SQL语句对关系型数据库（如MySQL）执行查询；

• text-to-Code：即根据用户输入的自然语言，结合大模型自己对相关数据的“理解”，直接生成代码并执行分析（可以理解为ChatGPT中的代码解释器Code Interpreter）。

当然这些模式并不全面。比如说还有text-to-JSON等。

• text-to-API这种模式相对容易实现，可以快速为现有的BI工具增加自然语言查询的能力，但它的灵活性和扩展性受限于底层BI工具的API。因此，如果API功能较为有限，可能会限制这种模式的应用场景和深度。它适用于企业已经部署了具有丰富API支持的BI工具，并希望快速实现自然语言查询功能时。通过这种模式可以与现有系统紧密集成，且满足对实时性要求较高的场景。
• text-to-SQL是一种较为通用和强大的模式，可以直接利用数据库的强大查询能力。然而，它对大语言模型转换自然语言到精确的SQL语句的能力有较高要求，可能需要进行较多的定制和优化，特别是在处理复杂查询时。此外，SQL查询的性能优化也是一个需要考虑的重要因素。它适用于基于标准SQL数据库的数据分析，特别是在数据结构清晰、查询需求标准化的环境中。对于希望利用现有数据库能力，而不依赖特定BI工具的企业来说，这是一个较好的选择。
• text-to-Code模式提供了最大的灵活性和功能强大的数据处理能力，因为它可以直接利用如Python这样的编程语言及其生态系统。这种模式尤其适合数据科学和复杂数据分析任务。然而，它也带来了较高的实现复杂度和对执行环境的要求，可能需要更多的安全和性能方面的考虑。它应该适用于当数据分析需求高度复杂和定制化，需要利用数据科学库进行深入分析时，以及对数据安全性和隐私有较高要求的场景，因为可以在本地或受控的环境中执行生成的代码。

• 自然语言文本报告：主要依赖于LLM的NLG能力，即将数据点和分析结果转化为易于理解的文本报告；
  
• 动态可视化模板报告：需要LLM理解用户的自然语言查询（NLU），并根据查询的内容和意图选择或生成合适的可视化模板对数据点和分析结果进行合理的呈现；
  
• 交互式数据探索助手：这种模式对LLM的能力要求最高，不仅需要深入理解用户的自然语言查询，还要能够实时处理数据、生成可视化，并且在交互过程中不断调整和优化输出结果。这要求LLM不仅要具备强大的NLU和NLG能力，还需要具备一定的逻辑推理和动态交互能力。