引言：BI是什么、AI大语言模型结合BI有什么优势
AI+BI的不同模式：主要关注在数据查询分析&可视化呈现环节
AI+BI的实施挑战
产品实践：包括网易、百度、京东、腾讯以及观远数据、神策数据在AI+BI上的不同尝试
百度Sugar BI 智能问数上手初体验
思考与延伸
引言
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能力，还需要具备一定的逻辑推理和动态交互能力。
需要强调的是，这些模式并不是互斥的，在某些情况下可以结合使用效果更佳（当然对于实现的复杂性要求也提高了）。选择哪种模式应根据我们的实际业务需求、目标用户群体的特点、以及所拥有&可投入的技术资源和能力来决定。
AI+BI的实施挑战
虽然将LLM与BI系统结合可以极大地提升数据分析和报告的智能化程度，对用户体验有着不言而喻的好处。但是，就当前的技术进展和结合情况来看，可能会遇到以下挑战：
由于LLM主要通过训练数据学习，如果训练数据不包含足够的行业特定知识或上下文信息，模型可能难以准确理解复杂的业务数据。因此，LLM可能在理解复杂数据集、特定行业术语或上下文中的细微差别方面存在挑战。这可能导致数据分析结果的误解或错误解释。
LLM在生成文本时可能会产生“幻觉”，即创造出与实际数据不符的信息。在BI报告中，这可能导致不准确或虚假的数据洞察和结论。因为LLM在生成文本时，可能会基于其训练数据中的模式进行推断，而这些模式不一定总是反映实际情况。
使用LLM处理敏感或私密数据时，需要确保数据不被非法访问或泄露。LLM的云基础设施和API调用可能成为数据安全的薄弱环节，尤其是在处理敏感信息时。
虽然LLM具有强大的通用性，但在特定行业或复杂的数据分析任务中可能难以满足所有定制化需求。原因在于LLM的训练是基于广泛的数据集进行的，可能无法完全覆盖某些特定领域或复杂场景的细节和特性。
我们需要确保LLM能够提供自然、流畅的交互体验，同时能准确理解用户的查询意图和需求，这可能存在挑战。因为不同用户的查询方式和习惯多样性，对应地表现为自然语言理解的复杂性，可能会影响交互的准确性和用户满意度。
在需要快速响应的BI应用中，确保LLM提供的解决方案能够满足性能和实时性要求可能是一个挑战。原因在于大型模型可能需要显著的计算资源和处理时间，特别是在处理大型数据集或复杂查询时。（不过就我个人目前的体验而言，这个问题不大，反而是BI系统本身可能存在这个瓶颈需要解决）
在不断地妥协之后，我们感觉在 AI 应用落地中存在一个不可能三角，效率-准确-智能的不可能三角。希望能够快速且准确地解决问题，就会对复杂问题束手无策；需要准确地解决复杂问题，就会需要漫长的时间来思考、拆解、处理；希望能够快速地解决复杂问题，就会无可避免地面临幻觉的产生。
（部分）产品实践
网易数帆团队于2023年推出了基于网易自研大模型的对话式数据智能助手——有数ChatBI，它融合了前沿的AIGC技术，通过自然语言理解与专业数据分析能力，用户只需通过日常对话的方式即可获得可信的数据，极大降低数据消费门槛。
图：网易数帆的产品全景图
网易有数ChatBI在结合大模型技术进行数据分析时，面对当前技术无法实现100%准确性的挑战，采取了一系列创新措施来提高产品的可信度和实用性，使之适用于生产环境。网易有数ChatBI通过引入检索增强技术，改善了大模型对数据表的理解能力。传统的基于LLM的NL2SQL方案仅将建表语句作为上下文注入，限制了模型对数据表的全面认知。通过将更多相关的表格元数据融入prompt，大模型能够获得更宽广的“视野”，提升其自适应能力，从而减少选错字段或字段值格式不匹配的问题。
为了适应特定业务领域的定制化需求，网易有数ChatBI支持个性化知识配置功能。这允许客户根据自己的业务特点和行业术语进行个性化设置，如将特定的行业“黑话”映射为模型可以理解的词汇，从而提高大模型在处理定制化问题上的准确性和适应性。
网易有数ChatBI采用了模型自学习机制，模仿ChatGPT等LLM通过对话形式进行自我修正的特性。管理员可以指正模型的错误，使其记录并在下次遇到类似问题时参考修正过的内容生成正确的SQL。这种机制使得ChatBI随着使用而变得更加智能，提升了用户体验和产品的整体性能。从AI+BI产品经理的角度看，网易有数ChatBI通过上述技术创新，解决了大模型在数据分析领域应用的一些核心问题，如准确性、定制化需求适应性及自学习能力，使其成为一款可靠且高效的数据分析工具。回顾我们前面所提到的“模式”，我认为它主要使用了【text-to-SQL+交互式数据探索助手】。在网易内部，有数ChatBI在网易云音乐等业务落地，已经覆盖了产品、运营、市场、财务等非技术人员。而借助网易内部的成功落地，有数ChatBI产品发布后，也吸引了甄云科技等外部客户的使用。
京东数据产品团队推出的ChatBI产品是一个基于GPT大模型的“AI数据分析师”，旨在通过对话方式简化BI工作，目前还只是一个内部产品。
图：京东chatBI实现的基本结构图
它结合了大语言模型、公/私域知识库和数据分析应用扩展，通过自然语言的交互形式，降低了使用门槛，并通过沉淀的业务知识和数据资产提供准确的分析结果，针对的主要用户痛点包括数据理解、获取和分析的复杂性。
（1）知识库的构建与应用
在ChatBI项目中，京东团队采用了Langchain来开发大语言模型，形成了一个包含两大类资产的综合性知识库。首先是数据中台资产，涵盖元数据、指标SQL以及产品指南等，为模型提供了丰富的数据支持。其次是业务资产部分，包括专门针对特定业务场景构建的模型和累积的业务知识。这部分尤其关注于分析师的分析思路，这些通常难以标准化和复用。通过大语言模型，它现在能够将分析师的专业思路转化为可供机器学习和自动化使用的形式，极大地提升了业务分析的效率和广度。（2）核心技术能力
在用户与ChatBI的互动过程中，系统首先通过意图识别来理解用户的查询目的，是希望获得特定知识、进行数据分析，还是简单的对话交流。接着，通过实体识别技术，我们能够从用户的提问中提取出关键信息，如时间、指标和维度等，并结合用户的背景信息如权限和部门来进行更准确的解析。对于知识查询类问题，系统会与知识库进行交互，通过优化算法提高回答的效率。而在数据分析场景下，ChatBI会调用相应的接口，将问题传递给大模型进行深入分析，并最终生成直观的可视化结果。回顾我们前面所提到的“模式”，这里使用的是【text-to-API】，至于自然语言文本报告、动态可视化模板报告、交互式数据探索助手则看起来都有使用到。（3）提升工作效率的应用实例
ChatBI的引入显著提升了工作效率。以往，用户在遇到数据问题时可能需要跨平台搜索指标定义，涉及繁琐的数据分析流程，耗时数小时甚至数天。而现在，用户仅需通过与ChatBI的自然语言对话，即可迅速获得问题的解答和可视化分析结果。这种以对话形式进行的高效数据交互和分析，极大地简化了数据分析流程，让决策支持更加迅速和精准。
SugarBI是百度智能云推出的敏捷BI和数据可视化平台，解决报表和大屏的数据BI分析和可视化问题，通过不断将AI能力融合进自身产品中，推出「文心问数Sugar Bot」功能，大幅度提升用户的数据分析效率。
图：百度SugarBI中所融入的智能化功能
根据官方介绍，SugarBI基于百度AI能力，提供自动分析、AI问答、波动分析等智能化功能，其优势在于：- AI问答：数据可视化Sugar BI接入了百度自然语言处理（NLP）技术，通过对用户输入问题的理解，直接展现Sugar BI智能推荐的合适的可视化形式，根据拖入控制面板的数据字段为您自动推荐图表
- 自动分析：您准备数据，我生成报表。数据可视化Sugar BI 省去拖拽创建报表的过程，系统在几秒钟内，将明细数据自动制作成交互式报表，让您对数据进行快速彻底的智能分析
- 场景1——智能问数页面，常用于业务最新情况的数据洞察。用户可以在相应页面以问答的交互形式，向Sugar BI 提出业务问题，Sugar BI 将以图表的形式返回答案及业务结论。
- 场景2——辅助用户在报表/大屏的编辑页面进行页面编辑。用户可以通过问答交互得到想要的图表类型后，直接「采用图表」将其一键固定至报表/大屏中，Sugar BI 会自动帮您进行图表的数据配置。这也是一种新的报表/大屏制作方式，同时也为编辑者提供了更丰富的制作灵感。
基于 NL-to-JSON 等能力，文心问数 Sugar Bot 帮助用户基于对话来直接完成数据探索，并完成一部分报表制作功能。同时，该团队还在进一步研发意图理解、指令拆解、图像生成等 AIGC 能力，基于对话直接满足用户对报表、大屏的生成需求，其愿景是实现大部分内容的直接生成，也就是 NL-to-X 。这样，可以通过生成式 AI 直接满足更多用户业务目标，逐步实现业务与技术重构。
（1）AI问数
在SugarBI平台上，用户有多种方式表达对数据的需求，包括通过报表、大屏以及探索页等多端入口。用户可以采用语音、自然语言输入或是直观的字段拖拽等多种交互形式来提出问题。对于语音输入，SugarBI利用ASR技术将语音转换为文本，进一步通过NLP技术转化为具体的数据查询需求，展现了平台对用户需求表达方式的全面适应性。SugarBI的核心之一是其表格问答模型，该模型能够理解用户的自然语言查询，并将其转化为对数据的具体需求。这一过程得益于SugarBI背后的数据模型，它将数据宽表的结构（Schema）及同义词等配置进行了高效抽象，以便进行深入的模型训练和部署。这种智能化处理不仅提高了数据查询的准确性，也为用户提供了更加直观和灵活的数据分析体验。用户的查询需求经过智能处理后，SugarBI会自动转换成图表配置，并生成相应的SQL语句进行数据查询。这一过程展示了从需求捕捉到数据检索的无缝链接，极大地提升了数据处理的效率。拉取到的数据根据其特征，将被SugarBI的智能图表功能自动匹配到最合适的图表类型，从而生成直观且信息丰富的数据可视化结果。（text-to-SQL+动态可视化模板报告模式）
图：SugarBI AI问答的整体技术架构
（2）自动分析
数据预处理与分析准备：SugarBI在启动自动分析前，首先确定分析的数据范围，即选定特定的数据字段集合。然后，SugarBI会详细审查这些字段的配置和数据细节，确保分析的准确性。值得注意的是，SugarBI在这一阶段会遵循设定的用户权限规则，确保数据访问的合规性（例如对于表格分析来说，表格会根据报表所设置的用户权限进行权限和数据的过滤，防止发生越权）。
分析模型的运作：收集完必要的信息后，SugarBI会将这些数据输入自动分析模型。这个模型是基于SugarBI内部大量报表数据经过训练得来的，因此具有较强的分析能力。模型会输出两类关键信息：一是数据过滤条件的优先级排名，二是图表展示字段组合的推荐排名。
图表生成与优化：根据模型的推荐，SugarBI会自动生成相应的数据过滤条件和图表展示字段组合。这一过程中，智能图表功能会被用来推荐最合适的图表类型，以最直观地展示数据。生成的图表和过滤条件将被相互关联，提供给用户灵活的数据探索能力，如下钻和筛选等。
报表的自动排版：最后，SugarBI会对选定的过滤条件和图表进行自动排版，形成最终的报表。这意味着从数据选择到报表生成的整个分析流程，都由SugarBI的自动分析功能智能完成，极大地提升了分析效率和用户体验。
图：SugarBI 自助分析的整体技术架构
腾讯的DataBrain团队在GPT4发布之后，尝试结合其能力构建了一个服务于 DataBrain 系统的统一语言智能助手Demo——chatBI，能够让用户在统一的语言交互界面完成数据分析的全过程。和京东的chatBI一样，该产品目前仅供内部使用。
经过多轮尝试，目前了解到其Demo版本是参考了AutoGPT这样的智能体设计思路（把 Prompt 和具体可执行的 Prompt 做了魔改，把 Prompt 中的资源、限制、可执行指令做处理，就能够让 AutoGPT 以数据分析的形状开始跑动）：
整个流程由用户提问开始，GPT 接收到提问后，将任务完成拆解成选表、读取数据信息、拼接 SQL、生成图表、完成分析等。SQL 的生成能力是调用的之前 DataLab 的 SQL 接口，能够基于需要指标、维度、筛选来给出符合具体场景的 SQL。类似的生成图表、简单数据分析的能力均是通过 Command 的方式来确保输入输出的可解释性和透明性。不过其团队也表示，目前的ChatBI 版本还有很大的提升空间，存在速度慢、可解决的数据问题很初级、复杂指标计算失败、图表不够丰富等问题。
BI Copilot 是观远BI利用大语言模型的能力构建的最新模块，接入了微软Azure OpenAI 商用服务权限（大家理解为就是ChatGPT背后的技术即可）：
Chat2Answer利用知识库构建，可以帮助业务用户理解数据的含义，并提供智能解读。当用户提出数据相关的问题时，Chat2Answer会解释数据背后的原因，并给出针对性的建议和可操作的方案。
这个功能早期的时候叫“chat2SQL”（也就是我们前面提到的text-to-SQL模式），通过自然语言交互协助生成 SQL 查询语句。以实际工作流程为例：
1. 接收用户的自然语言查询请求，例如“每个品牌的退款额是多少”；2. 将用户的查询请求转化为机器可理解的 SQL，例如“SELECT `商品名称`, SUM(`退款金额`) AS `退款额` FROM input1 GROUP BY `商品名称`”，将生成的 SQL 查询语句返回给用户；3. 进一步交互式的追问，例如“再加上渠道维度”；4. 再次转换为 SQL，例如“SELECT `商品名称`, `渠道`, SUM(`退款金额`) AS `退款额` FROM input1 GROUP BY `商品名称`, `渠道`”，并返回给用户。
用户在遇到问题时可以直接向Chat2Help寻求帮助。当遇到报错或问题时，只需将报错信息复制粘贴到对话框中与Chat2Help进行问答，它将直接告诉用户报错的含义，并指导一步步排除报错、提供解决方案。
神策数据的产品主要是CDP（客户数据平台）领域的，和我们前面所提及的“BI”不是一个概念。不过在研习过程中发现它也利用大模型技术推出了神策分析 Copilot（另外还支持用于运营Copilot），同样支持自然语言的交互，自助式地进行数据分析与查询，因此还是纳入本文中。
从目前的Demo介绍来看，其支持的一些场景如下：
（1）智能分析：应用大模型技术理解用户问题，自动配置分析模型
以事件分析场景为例，在输入框中用自然语言输入要获取的数据指标，比如最近7天搜索点击的用户数，GPT 模型将自然语言转化为请求查询JSON 并发起查询，并进行图形化展示。
在这里，神策团队采用了text-to-json而不是 text-to-SQL的模式，其考虑有二：一方面更容易理解，便于业务人员判断查询；另一方面更容易进行人为干预，比如生成的査询 JSON 不对，想换种计算方式或查询条件看看指标怎么样，可快速调整。
其实现过程大致为：
首先，把schema（简单理解为是关于数据如何存储、数据之间的关系以及数据应该如何解释的信息）传给GPT，让GPT理解数据的schema以及任务。考虑到存在长度限制，需要优化设计，从报表的上千个字段中筛选出进入到 prompt的字段、以缩短prompt。
其次，筛选出来的 schema 会有很多的字段，字段多了也会影响 GPT 的正确率和精准度，因此需要跟 GPT 进行交互，让它挑选出哪些字段与需求有关。
最后，通过 GPT进行 JSON 的生成。对于复杂的查询，可以先让它生成一个结构，在这个结构下再把内容填充进去。
值得一提的是，神策分析 Copilot 具备可理解、可信任、可干预的特点，能有效规避大模型固有的幻觉问题。在生成分析结果的同时，Copilot 将展示分析模型和指标的应用来源，便于用户理解、校验分析逻辑和指标用法，以确保用户选择正确的指标。若分析结果不符合预期，用户可以手动调整帮助系统持续学习、优化结果（即显式反馈）。
（2）指标搜索：自然语言查询例行指标
应用大模型技术构建指标搜索能力，帮助业务人员快速定位到当下关注的指标和经营概览，或深入探索特定业务的相关指标。支持用户口语化输入，业务人员无需输入专业术语或确切的指标名称，也能获得相关的数据指标。
例如在零售行业中，若用户想知道近期的商品销售数据，直接对Copilot 提问“卖得最好的商品”，它便会推送“当天 Top 商品”“热门访问商品”“商品销售数量”等指标查询结果，无需依赖分析师进行查询。
（3）数据门户融合：数仓对话插件
神策分析Copilot 也可以接入企业数仓，例如在某保险公司的实际应用中，它就作为一个智能问答组件融合至企业自身的数据门户，用户点击“智能问答”即可开启直接对话，对数仓数据进行自助式分析和查询、生成数据结果和报表。
当然啦，除了这些产品，其实还有很多其他的AI+BI实践，但时间和精力有限，我们就不继续拓展了。
就我本人所掌握的情况来看，包括但不限于以上提及的经过大模型加持的AI+BI产品，大多都还处于Demo、内部测试或小范围试用的阶段，部分进行了推广但基本上都尚未大规模商用。
相信随着用户反馈+持续优化完善，再加上大模型能力的进化，更加成熟、稳定、可用的新版本产品将在今年内到来。
SugarBI问数上手初体验
上面所提到的产品大多没有机会上手（例如内部产品或仍在测试阶段）体验，但总算在2月初申请到了百度SugarBI文心问数的体验权限。
参照官方指引，基于示例数据，我进行了简单的探索：
（1）数据模型准备
在数据模型的设置页面，可以选择对应的数据表并建立关系：
在编辑页面可以将字段名称设置为可读性较高的中文别名：
对于原子指标（度量），我们可以设置AI问答的同义词（也就是帮助大模型理解专业术语，可能用户会有不同的问法）作为其“知识库”：
我们也可以新建度量（指标加工），这就是常规的BI功能了：
对于AI问答功能，需要开启并等待模型训练完成才能使用（不过我没有权限）：
我们还可以配置AI问答的推荐问题，这个如果在ChatGPT中自定义过自己的GPTs的小伙伴应该很熟悉：
然后我们就可以通过智能问数Sugar Bot和系统进行交互了：
当我点击上图中的“需要结论”时，系统会自动总结如下：
并且还能发现数据的不合理之处（确实如此）：
整体上来说还是蛮有意思的，确实是一种全新的体验、并且是已经实际落地到现有产品中了。感兴趣的小伙伴可以自行申请体验。
值得注意的是，SugarBI有以下限制：
- 用户提出的问题字数限制为 300 字（空格也算做有效字符）——我想这主要是出于性能与成本控制的考虑。通过限制用户输入的字数，可以有效控制后端大模型处理请求的复杂度和资源消耗，同时鼓励用户提出更精炼、更具针对性的问题，提高处理速度和响应质量。因为除了用户输入的问题，如观远数据所说还需要给大模型传数据schema，因此压缩总的Prompt是必要的。
- 当生成的图表不符合预期时，可以点击「重生生成」但最多可以点击三次——为什么是3次？这个设计可能是为了防止用户无限制地重新生成结果，从而导致资源浪费和系统压力。限制重生次数可以鼓励用户更加仔细地考虑和优化他们的查询，同时也是一种计算资源的管理策略。此外，这也可能是基于用户行为的统计分析，认为三次重试足以覆盖大多数情况下的需求调整。
- 如果在大屏/报表编辑页面中关闭智能问数页面，Sugar BI将会清空之前会话的全部内容——这一限制可能是出于数据安全和隐私保护的考虑。自动清空会话内容可以防止敏感数据残留在系统中，尤其是在多用户环境下。此外，这也有助于保持系统的高效运行，避免不必要的数据积累影响性能。
思考与延伸
在前面的研习内容中，我们主要关注支持自然语言交互模式下的BI数据查询、分析和可视化呈现。实际上，在从问题定义、数据接入、处理、可视化展示、交互分析到决策行动的BI数据分析全链路中，AI大语言模型都有结合的机会。
在前面的研习内容中，我们主要关注支持自然语言交互模式下的BI数据查询、分析和可视化呈现。实际上，在从问题定义、数据接入、处理、可视化展示、交互分析到决策行动的BI数据分析全链路中，AI大语言模型都有结合的机会。让我们从产品经理的视角来粗略地考虑：（1）问题定义：明确业务问题和目标。
- 问题: 确定分析的焦点，如提升销售额、优化库存等。
- AI赋能: 使用AI模型生成初步的数据分析和决策计划草案，再人工校对修改，以确保方向和目标的准确性。
（2）数据接入：确定和接入数据源。
- AI赋能: 利用AI技术直接分析非结构化数据，减少传统的数据清洗步骤，加快从数据到洞察的过程。
（3）数据处理：数据的清洗、转换和加载（ETL）。
- AI赋能: 通过自然语言交互生成ETL任务和代码，辅助数据处理，实现多轮交互式构建，提升数据处理的灵活性和准确性。
（4）可视化展现：将数据转化为易于理解的视觉形式。
- 问题: 快速响应业务问题，提供直观的数据结果和结论。
- AI赋能: 自动根据问题生成SQL、JSON，利用AI生成文字结论、可视化图表和行动建议，实现问答式BI。
（5）交互分析：深入分析数据，生成深度分析报告。
- 问题: 如何自动化深度分析报告的生成，提供可信的业务分析。
- AI赋能: 基于BI系统能力，结合企业内部数据源和AI生成的数据指标，自动识别异常原因并用自然语言展示，减少认知偏差（例如波动分析、异常分析和预警）。
（6）决策行动：基于分析结果，提供决策支持。
- AI赋能: 提供辅助性预测和基于历史数据的推荐建议，支持数据驱动的决策过程。
支付宝团队在基于蚂蚁集团基础大模型开发研制数据分析智能助理 Deepinsight copilot的过程中，比较系统化地梳理了结合大模型的数据分析智能助理功能需求，划分了不同的智能化等级，非常值得我们参考和学习：
注：
CoT即思维链（Chain-of-thought），模仿了一个逐步思考的过程来得出答案。
TOT即Tree-of-thoughts，CoT通常只有一条解决问题的路径，ToT等于是CoT的一个拓展，把一条reasoning路径拓展至多条reasong paths，这样模型可以综合多条reasoning path的结果得到最终的结论。
ReAct：即Reason和Action，Reason生成分析步骤，Action生成工具调用请求。是目前最常见和通用的增强式语言模型（Augmented
LM)范式，它启发于传统强化学习，通过提示词构造“想法”（Thought），“行动”（Action），“观察”（Observation）的思维链，
逐步启发大语言模型根据当前工具的输出产生观察，从而进一步产生下次推理。这种范式被广泛应用在近期爆火的 Auto-GPT 和 LangChain
等项目中。
ReWOO 即Reasoning WithOut
Observation，通过模块化解耦（Decouple）大语言模型的“预见性推理”(Foreseeable
Reasoning) 和工具的执行，从而实现在HotpotQA等任务上数倍的词元效率(Token Efficiency)，
并且提高了模型表现以及复杂环境下的鲁棒性。在ReAct中， 指令微调不可避免的会导致小模型“背住”训练集中的工具输出。然而，ReWOO由于将显式的工具输出跟模型的推理步骤分离， 可以因此借由指令微调使其学会具有泛化性的“预见性推理”能力。
DAL我没有查到，我估计应该是DSL，即将自然语言转化为特定领域的语言（Domain-Specific Language），也就是我们前面提到的text-to-code。
KG即知识图谱，在上一篇文章中正好进行了比较深入的研习。
AI+BI的融合为商业智能领域带来了前所未有的机遇，通过大语言模型的应用，可以极大地提升数据分析的效率、深度和准确性，同时改善用户体验。
作为AI产品经理，理解并把握AI技术在BI产品中的应用，不仅需要技术和业务的深入理解，还需要持续的创新和优化。通过有效地结合AI和BI，我们可以更好地解锁数据的潜力，支持数据驱动的决策，推动企业的智能化转型。
粤ICP备17114055号
支持私有云部署
