1. 项目概述当Power BI遇上开源AI数据洞察的“智能副驾”如果你和我一样长期和数据打交道用过Power BI做报表那你肯定有过这样的时刻面对一堆复杂的DAX公式或者想快速从数据里找出异常点、做个预测却感觉像是在手动“挖矿”效率低下还容易遗漏关键信息。最近我在GitHub上发现了一个名为“powerbi-master-openclaw-skill”的项目它像是一把为Power BI量身定制的“瑞士军刀”试图将开源大语言模型LLM的能力直接注入到我们的数据分析工作流中。简单来说它让Power BI具备了“听懂人话”并“自动执行”的能力。这个项目的核心是构建一个基于开源大模型比如Llama、ChatGLM等的“技能”Skill系统并将其与Power BI深度集成。你可以把它想象成Power BI里的一个“智能副驾”。以前你需要手动编写DAX、设计复杂的度量值、或者通过一系列点击操作来筛选和可视化数据。现在你或许可以直接用自然语言告诉它“帮我找出上季度华东地区销售额下降最多的三个产品类别并预测下个月的走势。” 这个“副驾”就能理解你的意图自动调用背后的模型进行分析并将结果以图表或数据的形式呈现在Power BI报告里。这不仅仅是“聊天机器人查数据”那么简单。openclaw-skill这个词组很有意思“OpenClaw”听起来像是一个开源框架或工具集而“Skill”则指向了具体的、可复用的能力模块。这意味着项目可能提供了一套标准化的接口和开发范式让开发者可以基于不同的开源模型为Power BI开发各种各样的“技能”比如自动生成报告摘要、智能数据清洗建议、异常检测、趋势预测、甚至根据描述自动生成合适的可视化图表。对于数据分析师、业务人员乃至IT开发者来说这个项目的价值在于它试图打破专业工具与自然交互之间的壁垒。它不要求你成为DAX专家或机器学习工程师就能享受到高级分析能力。同时由于其开源属性它避免了商业AI服务可能带来的数据隐私、成本高昂和定制化困难等问题。当然这条路也充满挑战比如如何保证分析的准确性、如何处理复杂的业务逻辑、以及如何将模型能力稳定、高效地集成到Power BI的生态中。接下来我就结合自己的理解和实践经验深入拆解这个项目的实现思路、技术细节以及我们如何在自己的环境中尝试和运用它。2. 核心架构与设计思路拆解要理解powerbi-master-openclaw-skill我们需要从两个核心部分入手一是“Power BI Master”所代表的集成层二是“OpenClaw Skill”所代表的能力层。整个项目的设计思路可以看作是在微软Power BI这个强大的数据可视化平台之上构建一个轻量级、可插拔的AI代理Agent框架。2.1 Power BI集成层从外部工具到嵌入式智能传统的Power BI与AI结合大多是通过外部服务如Azure OpenAI调用API或者在Power Query中利用Python/R脚本进行机器学习。powerbi-master这个命名暗示了更深度的集成方式。我推测其实现路径可能包含以下几种或者它们的组合Power BI自定义视觉对象Custom Visual这是最直接的前端集成方式。开发一个自定义视觉对象该对象内嵌了一个聊天界面或任务触发按钮。用户在这个界面中输入自然语言指令视觉对象通过HTTP请求与后端的Skill服务通信获取分析结果可能是JSON格式的数据或生成的图表配置然后动态更新自身显示的内容。这种方式对用户最友好体验最无缝。Power BI API与数据流通过Power BI的REST API外部服务可以自动刷新数据集、更新报告页、甚至创建新的报告。一个Skill服务可以监听指令通过API将分析结果写回Power BI的某个特定数据表报告则基于这个数据表进行可视化。这种方式更侧重于后台自动化。混合方案自定义视觉对象负责交互和指令接收然后将指令发送到后端Skill服务。Skill服务处理完成后可能通过API更新数据源也可能直接将渲染图表所需的配置数据返回给视觉对象。视觉对象再利用Power BI的SDK进行动态渲染。注意与Power BI深度集成需要处理身份认证AAD、权限管理、以及确保在Power BI Service在线服务和Power BI Desktop桌面版中都能稳定运行。这通常是此类项目最大的工程挑战之一。2.2 OpenClaw Skill层基于开源LLM的技能引擎“OpenClaw”很可能是一个用于构建和管理AI技能Skills的轻量级框架或库。“Skill”在这里是一个核心概念它代表一个独立的、可完成特定任务的能力单元。例如“数据摘要”Skill输入一个数据表输出一段文字总结核心趋势和关键指标。“异常检测”Skill分析时序数据自动标记出异常点并解释原因。“图表推荐”Skill根据用户想要表达的观点和数据特征推荐最合适的图表类型折线图、柱状图、散点图等。“DAX生成”Skill根据自然语言描述如“计算每个月的滚动平均销售额”生成正确的DAX公式。每个Skill的实现通常遵循一个标准流程指令解析与规划接收用户的自然语言指令LLM首先判断需要调用哪个或哪几个Skill并将复杂指令分解为一系列可执行的子任务。上下文获取Skill需要获取Power BI报告当前的上下文信息比如当前页面的数据模型、筛选器状态、已存在的视觉对象等。这可能需要通过Power BI的JavaScript SDK或API来获取。工具调用与执行LLM根据规划调用相应的“工具”Tools。这些工具就是具体的函数例如query_data(sql)用于查询数据calculate_measure(dax)用于执行DAX计算create_visualization(config)用于生成图表。项目需要为LLM预先定义好这些工具集。结果生成与格式化工具执行后返回结果数据、状态等LLM负责将这些结果整合并以人类可读的自然语言或Power BI可识别的结构化数据如JSON格式返回。为什么强调“开源”LLM这关乎成本、数据隐私和可控性。使用Llama 3、Qwen、DeepSeek等本地或私有化部署的模型可以确保敏感业务数据不出内网同时长期使用成本可能更低也便于针对特定业务领域进行微调Fine-tuning。openclaw-skill框架需要能灵活适配不同的开源模型后端。2.3 技术栈选型推测与考量基于上述架构我们可以推测其技术栈可能包含以下组件后端Skill服务PythonFastAPI/Flask。Python是AI生态的事实标准拥有丰富的LLM调用库如LangChain、LlamaIndex、数据处理库pandas, numpy和HTTP框架。AI框架与编排很可能会使用LangChain或LlamaIndex。这两个框架专门用于构建基于LLM的应用程序提供了便捷的链Chain、代理Agent、工具Tool抽象能极大地简化Skill的开发。OpenClaw甚至可能就是基于它们二次封装的。LLM后端支持通过Ollama本地运行模型、vLLM高性能推理、或直接调用开源模型API如DeepSeek、通义千问来接入各种开源模型。前端Power BI自定义视觉对象TypeScript/JavaScript使用Power BI Visuals SDK进行开发。内部可能会嵌入一个简单的聊天UI组件。通信前后端通过RESTful API或WebSocket进行通信。考虑到分析任务可能耗时异步处理和进度反馈会很重要。设计思路的核心在于解耦和标准化。将AI能力Skill与Power BI平台解耦通过一套标准的接口API、数据格式进行通信。这样Skill的开发者可以专注于AI算法和业务逻辑而不必深究Power BI的内部细节同时Power BI用户也能通过统一的界面灵活地调用不断增长的Skill库。3. 关键组件与核心技能实现解析理解了宏观架构我们深入到微观层面看看一个具体的“Skill”是如何从想法变成在Power BI中可用的功能的。这里我以两个最可能优先实现的技能为例“智能问答”和“自动图表生成”来拆解其实现细节。3.1 技能一基于报告上下文的智能问答这个技能允许用户针对当前看到的报告页面提问例如“为什么这个月的利润比上个月低了”。实现它远不止是让LLM读一遍数据那么简单。3.1.1 上下文嵌入与向量检索报告页面包含大量信息多个视觉对象图表、表格、页面级筛选器、可能还有书签状态。我们不能把所有这些原始数据都塞给LLM有Token长度限制且噪音大。标准的做法是索引与检索。元数据提取通过Power BI Visuals API我们可以获取当前页面所有视觉对象的属性包括视觉对象类型是柱状图、折线图还是表使用的数据字段这个图表用了哪几个表、哪几个列度量值图表中使用的所有DAX度量值定义。筛选器当前应用于页面、视觉对象或报告级别的所有筛选条件。 将这些信息结构化后形成一份当前报告状态的“元数据描述”。数据摘要生成对于关键图表可以采样或汇总其背后的数据生成统计摘要例如“销售额折线图显示趋势在Q2上升但在7月份出现明显下跌最低点为X元。”构建向量数据库将上述的“元数据描述”和“数据摘要”文本化然后使用嵌入模型如BGE、text-embedding-ada-002的替代开源方案将其转换为向量Embeddings存入本地的向量数据库如ChromaDB、Qdrant或FAISS。问题路由与检索当用户提问时先将问题也转换为向量然后在向量数据库中执行相似性搜索找出与问题最相关的报告上下文片段可能是某个图表的描述或某个度量值的定义。这些片段作为“上下文”与用户问题一起组装成Prompt发送给LLM。3.1.2 Prompt工程与回答生成这是决定回答质量的关键。一个精心设计的Prompt模板可能长这样你是一个专业的Power BI数据分析助手。请基于以下提供的报告上下文信息回答用户的问题。 ### 报告当前上下文 {检索到的相关上下文片段} ### 用户问题 {用户输入的问题} ### 回答要求 1. 严格基于上述上下文信息回答。如果上下文信息不足以回答问题请如实告知“根据当前报告信息无法确定”。 2. 回答需专业、简洁、聚焦于数据本身。 3. 如果涉及数据变化请尽量引用具体的数值或趋势描述。 4. 避免臆测上下文之外的原因。 请开始回答通过这种方式LLM的回答就能紧扣用户正在查看的报告内容实现真正的“上下文感知”问答。实操心得上下文检索的精度直接决定回答质量。除了图表元数据把重要的DAX度量值定义、数据表的关系说明也索引进去能极大提升对复杂计算问题回答的准确性。另外设置一个相似度阈值过滤掉低相关度的片段能有效防止“幻觉”胡编乱造。3.2 技能二从描述到图表的自动生成“帮我画一个展示各地区销售额和利润率的散点图。”——将这个指令变成真实的Power BI图表需要跨越自然语言到图形语法的鸿沟。3.2.1 指令解析与图表规约首先LLM需要将用户的自然语言描述解析成一个结构化的“图表规约”Chart Specification。这个规约通常是一个JSON对象定义了图表的所有必要属性。我们可以利用LLM的Function Calling或JSON模式输出能力来实现。定义工具Tool{ type: function, function: { name: generate_chart_spec, description: 根据用户描述生成创建Power BI图表所需的规约。, parameters: { type: object, properties: { chart_type: {type: string, enum: [Bar, Line, Scatter, Pie, Table]}, x_axis_field: {type: string, description: X轴字段名}, y_axis_field: {type: string, description: Y轴字段名}, legend_field: {type: string, description: 图例/颜色字段名}, aggregation: {type: string, enum: [Sum, Average, Count, DistinctCount]}, title: {type: string} }, required: [chart_type, y_axis_field] } } }LLM在理解用户指令后会调用这个工具并填充参数。例如对于“各地区销售额”它可能返回{“chart_type”: “Bar” “x_axis_field”: “Region” “y_axis_field”: “Sales” “aggregation”: “Sum” “title”: “各地区销售额汇总”}。3.2.2 字段映射与验证生成的规约中的字段名如“Region”、“Sales”必须是当前Power BI数据模型中存在的字段。这里需要一个“字段目录”或“数据模型Schema”作为上下文提供给LLM。LLM需要完成从用户口语化表述如“销售额”到精确字段名如“Sales[Amount]”的映射。更稳健的做法是两步走字段识别让LLM先从用户描述中提取出可能的字段概念。Schema匹配在后端将提取的概念与数据模型中的实际字段名进行模糊匹配或基于预定义同义词表的匹配。例如用户说“销量”程序能匹配到“SalesQuantity”字段。3.2.3 调用Power BI API生成视觉对象获得验证后的图表规约后后端服务需要通过Power BI的JavaScript SDK在自定义视觉对象中或REST API来实际创建或更新图表。对于自定义视觉对象可以将规约转化为Power BI视觉对象的数据视图DataView格式然后调用视觉对象的update方法动态渲染。对于更通用的创建可能需要使用Power BI的“克隆报告页”或“通过API添加视觉对象”等更高级的功能这通常更复杂但灵活性更高。注意事项自动生成的图表在美观度和信息有效性上可能不如资深分析师手工制作的。因此这个技能更适合作为快速探索和草稿生成的工具。生成的图表应允许用户方便地进行后续微调修改图表类型、调整颜色、格式等。此外必须加入边界检查例如防止用户尝试用“产品名称”字段去做求和聚合这需要在规约验证阶段就进行逻辑判断。4. 本地化部署与集成实操指南假设我们想在内部环境中尝试部署和使用powerbi-master-openclaw-skill或其类似理念的自建方案以下是一个基于常见技术栈的实操路线图。请注意由于原项目具体细节未完全公开本指南是一种合理的、可实现的构建思路。4.1 环境准备与模型选型4.1.1 基础软件环境操作系统推荐LinuxUbuntu 20.04/22.04 LTS或Windows Server用于部署后端服务。开发机Windows/Mac均可。Python环境使用conda或venv创建独立的Python 3.9环境。关键Python包pip install fastapi uvicorn langchain langchain-community langchain-core pydantic pip install sentence-transformers chromadb # 用于向量检索 pip install ollama # 或 vllm用于本地模型推理 pip install pandas numpy # 数据处理4.1.2 开源大模型选择与部署模型的选择需要在能力、速度和资源消耗间权衡。轻量级/快速响应用于简单问答、分类Llama 3.1 8B、Qwen2.5 7B。使用Ollama部署最为简单ollama run llama3.1:8b。高能力/复杂推理用于代码生成、深度分析Qwen2.5 32B、DeepSeek-Coder。这类模型需要更多GPU内存至少24GB以上建议使用vLLM部署以获得更好的推理吞吐量。# 使用vLLM启动一个模型服务示例 vllm serve qwen2.5-32b-instruct --api-key token-abc123 --port 8000嵌入模型用于将文本转换为向量。推荐BAAI/bge-small-zh-v1.5或thenlper/gte-base它们对中文支持好且模型较小。4.1.3 Power BI开发环境Power BI Desktop最新版用于测试自定义视觉对象。Power BI视觉对象开发工具安装Node.js和Power BI Visuals SDK。npm install -g powerbi-visuals-tools pbiviz new myOpenClawVisual # 创建一个新的视觉对象项目4.2 后端Skill服务搭建我们使用FastAPI构建一个简单的后端服务。4.2.1 项目结构openclaw-backend/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI应用入口 │ ├── core/ │ │ ├── config.py # 配置管理 │ │ └── security.py # 认证如需 │ ├── models/ # Pydantic数据模型 │ ├── services/ │ │ ├── llm_service.py # LLM调用封装 │ │ ├── skill_orchestrator.py # 技能编排器 │ │ └── pbi_context_service.py # Power BI上下文获取服务 │ ├── skills/ # 各个技能的实现 │ │ ├── base_skill.py │ │ ├── qa_skill.py │ │ └── chart_gen_skill.py │ └── routers/ # API路由 │ └── api_v1.py ├── requirements.txt └── Dockerfile4.2.2 核心服务实现示例技能编排器skill_orchestrator.py是大脑负责理解用户意图并调用合适的技能。from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain_community.llms import OllamaLLM # 示例使用Ollama from app.skills.qa_skill import QASkill from app.skills.chart_gen_skill import ChartGenSkill import json class SkillOrchestrator: def __init__(self, llm_endpoint: str): # 初始化LLM self.llm OllamaLLM(base_urlllm_endpoint, modelllama3.1:8b) # 初始化各个技能并封装成LangChain Tool self.qa_skill QASkill() self.chart_skill ChartGenSkill() self.tools [ Tool( nameData_QA, funcself.qa_skill.execute, description回答关于当前Power BI报告数据的问题。输入应为清晰的自然语言问题。 ), Tool( nameCreate_Visualization, funcself.chart_skill.execute, description根据描述创建或修改图表。输入应为图表描述如‘创建一个显示各产品类别销售额的柱状图’。 ), ] # 创建ReAct智能体 self.agent create_react_agent(llmself.llm, toolsself.tools) self.agent_executor AgentExecutor(agentself.agent, toolsself.tools, verboseTrue) async def process_query(self, user_query: str, pbi_context: dict): 处理用户查询。 :param user_query: 用户自然语言指令 :param pbi_context: 从Power BI前端获取的上下文信息 :return: 执行结果 # 将Power BI上下文作为系统提示的一部分传递给Agent prompt f 你是一个Power BI智能助手。当前报告上下文如下 {json.dumps(pbi_context, ensure_asciiFalse)} 用户指令{user_query} 请使用合适的工具来完成任务。如果你需要更多信息才能使用工具请向用户提问。 try: result await self.agent_executor.ainvoke({input: prompt}) return result[output] except Exception as e: return f处理请求时出错{str(e)}4.2.3 API路由暴露在routers/api_v1.py中暴露一个主要的处理端点。from fastapi import APIRouter, HTTPException from pydantic import BaseModel from app.services.skill_orchestrator import SkillOrchestrator router APIRouter(prefix/api/v1, tags[skills]) orchestrator SkillOrchestrator(llm_endpointhttp://localhost:11434) # Ollama默认地址 class QueryRequest(BaseModel): query: str pbi_context: dict # 包含报告ID、页面名、视觉对象信息等 router.post(/process) async def process_query(request: QueryRequest): try: result await orchestrator.process_query(request.query, request.pbi_context) return {success: True, data: result} except Exception as e: raise HTTPException(status_code500, detailstr(e))使用uvicorn启动服务uvicorn app.main:app --host 0.0.0.0 --port 8001。4.3 Power BI自定义视觉对象开发这是用户直接交互的界面。4.3.1 视觉对象核心逻辑在视觉对象的src/visual.ts中主要增加一个聊天输入框和一个结果显示区域。核心是update函数它负责与后端通信。// 部分关键代码示意 export class Visual implements IVisual { private chatContainer: HTMLDivElement; private inputBox: HTMLInputElement; private resultDiv: HTMLDivElement; // ... private async sendQueryToBackend(query: string) { // 1. 获取当前Power BI上下文 const pbiContext this.getPBIContext(); // 需要实现此函数利用Visual API获取数据视图、筛选器等 // 2. 构建请求 const requestBody { query: query, pbi_context: pbiContext }; // 3. 调用后端API假设地址为 http://localhost:8001 try { const response await fetch(http://your-backend-server:8001/api/v1/process, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(requestBody) }); const result await response.json(); // 4. 处理结果 if (result.success) { this.displayResult(result.data); // 如果结果是图表规约可以调用Power BI SDK来更新数据视图 if (result.data.type chart_spec) { this.applyChartSpec(result.data.spec); } } else { this.displayError(result.error); } } catch (error) { this.displayError(网络请求失败: ${error}); } } private getPBIContext(): any { // 这是一个简化示例实际需要从this.dataView中提取丰富的信息 const dataViews this.dataViews; let fields []; if (dataViews dataViews[0] dataViews[0].metadata) { fields dataViews[0].metadata.columns.map(col col.displayName); } return { pageName: this.getPageName(), // 需要额外API获取 visualFields: fields, filters: this.getActiveFilters() // 获取当前筛选器 }; } }4.3.2 打包与部署在视觉对象项目根目录运行pbiviz package生成.pbiviz文件。在Power BI Desktop中通过“…” - “从文件导入” 来导入这个自定义视觉对象。对于Power BI Service在线版需要将视觉对象发布到组织的视觉对象市场或通过“开发人员视觉对象”方式加载需要管理员设置。重要提示在生产环境中后端服务的地址不能是localhost。需要部署到内部服务器并确保Power BI Service运行在云端能够通过安全的HTTPS端点访问到它。这通常涉及配置网关、设置CORS和身份认证如使用Azure AD服务主体。5. 挑战、优化与未来展望将开源LLM深度集成到Power BI中构建一个可用的“智能副驾”在激动人心之余也面临着诸多实实在在的挑战。在实际的探索和构建过程中我总结出以下几个关键难点和对应的优化思路。5.1 面临的核心挑战与应对策略5.1.1 准确性、幻觉与可控性这是所有LLM应用的头号敌人。在数据分析场景下一个错误的数字或误导性的结论可能带来严重的业务后果。挑战LLM可能“自信地”编造不存在的数据幻觉或者对DAX公式、业务逻辑理解有偏差。应对策略严格检索增强RAG坚持所有回答必须基于检索到的上下文数据摘要、字段定义。在Prompt中强制要求“引用来源”并可以设计一个后处理步骤验证回答中提到的数据点是否能在上下文中找到依据。代码执行沙箱对于生成DAX或SQL的Skill绝不让LLM直接在生产数据库上执行。应在一个隔离的沙箱环境中如Power BI Desktop的本地实例、或一个专用的分析数据库副本先执行验证确认语法正确且结果合理后再提示用户确认是否应用。人机协同而非完全自动将系统定位为“副驾”输出标记为“建议”。对于重要的图表生成或度量值创建必须经过用户的审查和确认才能生效。5.1.2 性能与响应速度LLM推理尤其是大参数模型可能很慢。用户无法忍受点击后等待30秒才看到一个图表。挑战复杂的分析请求可能导致链式思考Chain-of-Thought过程很长响应延迟高。应对策略技能路由与轻量化模型在入口处用一个非常快的小模型如Phi-3 mini进行意图识别和技能路由。简单的查询如“销售额总和是多少”直接路由到基于规则或检索的快速问答模块复杂的分析如“预测下季度趋势”才调用重型LLM。异步处理与进度反馈对于耗时任务后端立即返回一个任务ID前端轮询状态。在等待期间前端可以显示“正在分析中…”的进度提示提升用户体验。结果缓存对于相同的查询和相同的报告上下文可以缓存LLM的响应结果在一定时间内直接返回避免重复计算。5.1.3 数据安全与权限继承Power BI有精细的行级权限RLS和模型权限控制。AI助手必须严格遵守这些规则。挑战当AI助手查询数据时它必须以“当前用户”的身份进行不能看到该用户无权访问的数据。应对策略在Power BI上下文内执行所有数据查询操作都应通过Power BI前端SDK发起或者通过模拟用户令牌调用Power BI REST API。这样所有的权限筛选都会自动生效。避免让后端服务直接连接底层数据库。最小化数据暴露传递给LLM的上下文应该是高度摘要化和脱敏的而不是原始行数据。例如传递“销售额的统计分布”而不是每一笔交易记录。5.2 效果优化与实用技巧除了解决挑战一些优化技巧能显著提升系统的实用性和用户体验。构建领域知识库针对你所在行业如零售、金融、制造业准备一份业务术语与数据模型字段的映射表以及常见的分析模式如“同比”、“环比”、“客户留存率”的计算方法。将这些知识作为系统提示词的一部分或存入向量库能极大提升LLM对专业问题的理解能力。设计渐进式交互不要指望LLM一次就理解所有模糊的需求。设计多轮对话的能力。例如当用户说“分析一下销售情况”时助手可以反问“您是想看整体趋势、区域对比还是产品线表现”通过交互逐步明确需求。提供解释与溯源AI给出的每一个结论、生成的每一个图表都应该能提供“为什么”。例如在回答“销售额下降”时可以附上“依据华东区Q3销售额环比下降20%是主要拖累因素”。对于生成的DAX公式添加简要的注释。实现“撤销”与“迭代”用户应该能轻松地说“这个图表换成折线图看看”或“不对我指的是毛利率而不是利润”。系统需要维护对话历史并支持基于上一步结果的快速修改。5.3 未来可能的演进方向powerbi-master-openclaw-skill这类项目代表了一个起点。随着技术的发展我们可以期待更多演进多模态输入从纯文本指令扩展到支持用户上传一张草图来生成图表布局或者圈选报告上的某个区域直接提问。自动化工作流从单次问答升级到自动化工作流。例如用户可以吩咐“每周一早上自动分析上周的销售数据找出异常门店生成摘要报告并发送到团队频道。”主动洞察从“你问我答”的被动模式变为“主动告知”的预警模式。系统持续监控数据流当检测到显著异常或达成重要里程碑时主动推送通知和简要分析。技能市场形成一个开放的Skill开发社区让第三方开发者可以贡献针对特定场景如供应链风险预测、营销活动归因的专用技能用户像安装插件一样在Power BI中启用它们。这条路无疑充满挑战从模型精度、系统稳定性到用户体验每一个环节都需要精心打磨。但它的潜力是巨大的——让最强大的数据分析工具变得平易近人让业务人员能直接与数据对话让数据分析师从重复劳动中解放出来专注于更高价值的策略思考。这不仅仅是给Power BI加了一个功能而是在重塑我们与数据交互的方式。