引言
BI（Business Intelligence，商业智能）是指利用软件工具和系统来分析组织内外可获得的原始数据，以支持更快、更精确的决策过程。BI产品已经是比较成熟的应用，例如Tableau、帆软FineBI、微软PowerBI、永洪BI、观远数据、思迈特Smartbi、阿里云Quick BI等，部分小伙伴应该有所耳闻或使用过。
BI工具通常包括数据仓库、数据挖掘、报告、在线分析处理（OLAP）等功能，帮助企业理解市场趋势、评估业务流程的效率，并识别新的增长机会。
图：阿里云Quick BI产品架构
随着人工智能技术的不断进步，AI+BI成为了一个新兴领域，它指的是将人工智能，尤其是机器学习和自然语言处理技术，集成到商业智能系统中，以自动化和增强数据分析和决策过程。特别地，结合AIGC技术，可以支持用户通过对话来完成数据探索、报表制作等工作，进一步提升数据分析效率，重构 BI 产品的人机交互方式。
就我目前所在公司的业务情况，AI+BI也是我认为有落地场景和价值的一个方向（当然从可用资源和投入产出比的角度来看，在我司还不适合推进），因此对这个领域多有关注，是以有本文。
需要强调的是，本文接下来所提到的AI，特指以大语言模型（LLMs）为基础的自然语言能力——即对话式的系统交互支持（毕竟在BI领域还有其他的AI技术可以使用，例如机器学习可用于销售预测）。
从产品经理的角度看，大模型结合数据分析进行应用具有以下优势：
- 自然语言处理与理解：大模型的强大自然语言处理能力使用户能够用自己熟悉的语言来查询和分析数据，这大大降低了数据分析的学习曲线，使非技术用户也能轻松上手。此外，大模型能够处理和分析非结构化数据，如客户评价和媒体内容，从而提取出有价值的信息和洞察，为企业提供全面的数据视角。
- 智能推理与预测：大模型不仅能够处理当前的数据，还能够基于现有数据进行推理和预测。这意味着它可以帮助用户识别数据中的异常点、趋势以及潜在的问题和机会，从而为决策提供支持。这种能力对于企业来说极其宝贵，因为它可以帮助企业预测市场变化，提前做好准备。
- 代码生成与自动化：大模型还能够通过自然语言指令生成Python、R等编程语言的代码，这极大地降低了技术门槛，使得即使是没有编程背景的用户也能够完成复杂的数据分析任务。这种自动化的代码生成功能，不仅提高了数据分析的效率，也拓宽了数据分析的应用范围。
- 新的交互形式：大模型引入了基于语言的交互方式，这种交互方式更加直观和自然，用户无需学习复杂的软件操作，只需通过自然语言表达自己的查询需求。这种交互方式不仅提升了用户体验，也使得数据分析工具能够更好地融入用户的工作流程中。
作为产品经理，理解这些优势不仅有助于我们更好地利用大模型技术来优化现有产品，也为我们提供了新产品开发的灵感。我们可以探索如何将这些优势整合到BI产品中，以满足用户的具体需求。
接下来就请随我一起探索一番。
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等。
每种模式都有其适用场景和限制，作为AI产品经理，选择最合适的模式需要综合考虑您的具体需求、现有的技术栈、以及预期的用户体验。根据我对大语言模型（LLMs）和BI系统的粗浅了解，个人的一点看法：
- text-to-API这种模式相对容易实现，可以快速为现有的BI工具增加自然语言查询的能力，但它的灵活性和扩展性受限于底层BI工具的API。因此，如果API功能较为有限，可能会限制这种模式的应用场景和深度。它适用于企业已经部署了具有丰富API支持的BI工具，并希望快速实现自然语言查询功能时。通过这种模式可以与现有系统紧密集成，且满足对实时性要求较高的场景。
- text-to-SQL是一种较为通用和强大的模式，可以直接利用数据库的强大查询能力。然而，它对大语言模型转换自然语言到精确的SQL语句的能力有较高要求，可能需要进行较多的定制和优化，特别是在处理复杂查询时。此外，SQL查询的性能优化也是一个需要考虑的重要因素。它适用于基于标准SQL数据库的数据分析，特别是在数据结构清晰、查询需求标准化的环境中。对于希望利用现有数据库能力，而不依赖特定BI工具的企业来说，这是一个较好的选择。
- text-to-Code模式提供了最大的灵活性和功能强大的数据处理能力，因为它可以直接利用如Python这样的编程语言及其生态系统。这种模式尤其适合数据科学和复杂数据分析任务。然而，它也带来了较高的实现复杂度和对执行环境的要求，可能需要更多的安全和性能方面的考虑。它应该适用于当数据分析需求高度复杂和定制化，需要利用数据科学库进行深入分析时，以及对数据安全性和隐私有较高要求的场景，因为可以在本地或受控的环境中执行生成的代码。
简言之，如果一个组织已经有成熟的BI工具和APIs，那么text-to-API可能是一个较为直接的选择。对于需要高度灵活性和定制化分析的场景，text-to-Code可能提供了更多的可能性。而text-to-SQL则在很多标准化的数据库查询场景中提供了一种高效且通用的解决方案。当然啦，在LLMs已经提取到对应的分析数据后，我们还需要进一步支持对话式的BI数据呈现，理论上来说也存在3种模式：
- 自然语言文本报告：主要依赖于LLM的NLG能力，即将数据点和分析结果转化为易于理解的文本报告；
- 动态可视化模板报告：需要LLM理解用户的自然语言查询（NLU），并根据查询的内容和意图选择或生成合适的可视化模板对数据点和分析结果进行合理的呈现；
- 交互式数据探索助手：这种模式对LLM的能力要求最高，不仅需要深入理解用户的自然语言查询，还要能够实时处理数据、生成可视化，并且在交互过程中不断调整和优化输出结果。这要求LLM不仅要具备强大的NLU和NLG能力，还需要具备一定的逻辑推理和动态交互能力。
需要强调的是，这些模式并不是互斥的，在某些情况下可以结合使用效果更佳（当然对于实现的复杂性要求也提高了）。选择哪种模式应根据我们的实际业务需求、目标用户群体的特点、以及所拥有&可投入的技术资源和能力来决定。
粤ICP备17114055号
支持私有云部署
