摘要：在今天的商业世界里，数据就是新的石油。然而，对于许多企业来说，从海量数据中提炼价值依然是个耗时耗力的过程。一个简单的“能帮我拉个报告吗？”可能需要数据分析师打开 SQL 编辑器，编写查询，导出结果，再制作图表，整个流程下来，不仅占用了专业人员宝贵的时间，也让业
用 Python 和 AI 构建你的专属数据分析助理
在今天的商业世界里，数据就是新的石油。然而，对于许多企业来说，从海量数据中提炼价值依然是个耗时耗力的过程。一个简单的“能帮我拉个报告吗？”可能需要数据分析师打开 SQL 编辑器，编写查询，导出结果，再制作图表，整个流程下来，不仅占用了专业人员宝贵的时间，也让业务人员的“快速提问”变成了漫长的等待，效率低下，人人皆输。
这种“人工取数”模式的痛点，催生了自助式数据分析工具的崛起。然而，早期的自助工具往往功能有限，只能解决一些预设的、高频的问题。一旦遇到新的、预料之外的请求，大家又不得不回到老路上，继续手动操作。
但现在，大语言模型（LLMs）的出现，彻底改变了游戏规则。借助 Python，我们有能力构建一个全新的工具，让它能够理解自然语言的提问，自动查询数据并生成可视化图表。本文将深入探讨如何从零开始，构建一个能将自然语言转化为 SQL 查询和图表的 AI 驱动数据助理，带你从“求人”时代迈向“自助”时代。
想象一下，你不再需要通过繁琐的 SQL 语句，只需要用大白话提问，比如“把每个客户的订单量用柱状图展示出来”。这个 AI 数据助理就能做到：
理解自然语言：直接理解你的提问，无论是简单的查询还是复杂的图表需求。实时生成 SQL：后台自动将你的问题翻译成 SQL 查询语句，并实时展示给你。数据可视化：执行查询后，根据你的要求生成对应的图表，甚至可以通过对话进行后续调整。为了模拟真实的商业环境，我们将使用一个名为“Northwind”的小型示例数据库，其中包含客户、订单和产品数据，麻雀虽小，五脏俱全。我们的目标不是打造一个“开箱即用”的商业产品，而是提供一个坚实的技术框架，一个可以让你学习、改造和扩展的蓝图。
你或许会问，市面上不是已经有很多能生成图表的 AI 服务了吗？为什么还要费时费力自己构建？答案主要在于三个核心优势：安全性、集成性和成本效益。
当我们将敏感的业务数据上传到第三方 AI 工具时，就不可避免地引入了数据泄露的风险。例如，曾有第三方 AI 工具因技术漏洞，无意中将部分用户对话（包括可能包含敏感信息的对话）暴露在公共网络上。
而通过自建工具，我们可以更灵活地控制数据流。尽管本文的方案仍会利用在线大语言模型，但我们只向模型发送数据库的元数据（例如表名、列名等），而非完整的数据集本身。这样，模型在没有暴露敏感信息的前提下，依然能够提供有价值的服务。如果对安全性有更高的要求，你甚至可以选择在本地部署大语言模型，确保所有数据都留在你的私有环境中。
每个企业都有其独特的 IT 架构，可能使用 AWS、Google Cloud 或其他私有数据库。如果依赖通用的 SaaS 工具，你可能需要频繁地进行数据导出和导入。而利用 Python 构建自定义助理，你可以直接连接到你现有的数据库，无论是关系型数据库还是云数据仓库，无需任何数据迁移，实现真正的无缝集成。
许多 SaaS 工具的收费模式是按使用量或用户数来计算的。随着查询频率的增加或用户规模的扩大，成本可能会像滚雪球一样迅速膨胀。自建解决方案虽然需要前期的开发投入，但它能让你避免长期高昂的许可费用，从长远来看，在规模化应用时将更具成本效益。
这个 AI 数据助理的核心是一个名为**检索增强生成（RAG）**的机制，它巧妙地结合了三个关键概念：上下文、记忆和意图。
大语言模型本身没有数据库知识，如果直接给它一个问题，它可能会生成一个完全无法执行的 SQL 查询。这就是为什么我们需要提供上下文。在我们的系统中，每当用户提出问题，我们都会自动将以下信息打包并传递给 LLM：
数据库模式（Schema）：告诉模型有哪些可用的表、列以及它们的数据类型。表间关系（Relationships）：明确地定义了主键、外键，以及如何连接不同的表。SQL 方言（Dialect）：指定数据库的 SQL 类型（例如 SQLite、Postgres 或 BigQuery），确保生成的查询语法正确。只有提供了这些上下文，LLM 才能生成针对特定数据库的、可执行的有效查询。
当 SQL 查询成功执行并返回数据后，系统的第二阶段才开始。这时，我们会再次请求 LLM，要求它生成一个 Python 绘图函数。这一次，我们提供的数据上下文是查询结果的列名和前五行数据。有了这些信息，模型就能够生成与实际数据结构相匹配的有效可视化代码。
一个好的助理不应该把每个问题都当成全新的开始。它需要具备状态（state），即能记住之前的对话内容。在我们的系统中，记忆功能至关重要，主要有以下两个原因：
节点依赖：我们的后端系统采用了一种图设计（graph design）。不同的功能模块（节点）相互依赖。例如，execute_query节点必须依赖于write_query节点生成的 SQL 查询才能运行。连贯的用户体验：记忆让助理具备了“对话能力”。如果用户先问了一个问题，然后说“现在把图表的颜色改成红色”，系统会记住之前生成的图表，并直接对其进行修改，而不会重新开始整个流程。在最初的版本中，每个问题都会触发完整的流程：提问 → 生成 SQL→ 执行 → 生成图表。但这种模式效率低下。如果用户只想知道“去年我们做了多少销售额？”，系统无需生成图表。如果用户只想“把折线图的颜色改为红色”，那么重新生成 SQL 查询也是不必要的。
为了解决这个问题，我们引入了一个意图分类器。它会根据用户的提问，为问题分配一个标签，例如DATA_QUERY（只想要数据）、VISUALIZE（想要图表）、ADJUST_PLOT（想调整图表）等。这些标签就像是“指令”，告诉系统应该激活哪些节点、跳过哪些步骤。
在我们的项目中，我们选择了一个巧妙而简单的方案：让大语言模型自己来完成意图分类。通过一个定制化的提示词，我们引导 LLM 为每个问题打上正确的“意图”标签。
现在，让我们深入到代码层面，看看这个 AI 数据助理是如何一步步构建起来的。我们将主要使用以下几个关键工具：
LangChain：一个用于连接 LLM 与数据库、API 等外部工具的框架。LangGraph：基于 LangChain，用于编排有状态的（stateful）工作流。Chainlit：一个“聊天优先”的 Python 框架，提供易于使用的 UI、记忆和调试功能，非常适合构建 LLM 应用。项目的核心逻辑被清晰地组织在不同的文件中，各司其职：
backend/：包含了助理的核心管道，即AssistantGraph。prompts/ & context/：存放了所有用于指导 LLM 行为的提示模板和数据库上下文信息。app.py：Chainlit 应用的入口文件，负责处理 UI 和后端逻辑的集成。northwind.db：一个预先准备好的 SQLite 数据库，用于演示。为了让助理表现得足够可靠，我们为它准备了结构化的上下文和清晰的提示模板。
数据库上下文 (database_context.py)：一个文本描述，详细说明了 Northwind 数据库的模式（表、列、关系）。这可以防止模型“凭空”创造出不存在的字段。意图检测提示 (intent_detection.py)：明确地告诉模型它是一个意图分类器，并给出了可能的标签及其含义。这个提示词还会考虑会话的状态（例如“是否存在一个已有的查询或图表？”），以做出更准确的判断。SQL 生成提示 (sql_generator.py)：为 LLM 提供了两个模板，一个用于生成全新的查询，另一个用于在已有查询的基础上进行修改。这些模板包含了限制条件（如结果数量、相关列等），并强调要使用提供的数据库上下文。绘图生成提示 (plot_generator.py)：同样包含两个模板，一个用于根据数据生成新的绘图函数，另一个用于修改现有函数。这些模板要求模型返回纯粹的 Python 代码，并明确了输入（DataFrame 结构）和输出（Matplotlib Figure对象）。后端的“大脑”位于backend/graph.py文件中，它像一个精心设计的流水线，严格按照以下步骤处理用户的请求：
定义状态（State）：我们首先定义了一个名为State的类型字典，用于在整个流程中追踪所有关键信息，包括用户的提问、检测到的意图、生成的查询、结果 DataFrame、绘图函数、图表对象以及可能出现的错误。意图检测：这是流程的第一步。detect_intent函数会根据用户的问题和会话状态，调用 LLM 进行意图分类。如果模型返回的标签不在预设列表中，系统会自动将其归类为CLARIFY（需要用户澄清）。SQL 查询生成：根据意图（VISUALIZE、DATA_QUERY或ADJUST_QUERY），系统会调用write_query函数，选择合适的提示模板，并传入数据库上下文、用户的提问以及（如果需要）之前的查询，生成正确的 SQL 语句。查询执行：execute_query函数接收上一步生成的 SQL 语句，直接在本地的 SQLite 数据库上执行，并将结果以 Pandas DataFrame 的形式返回。绘图函数生成：如果意图是关于可视化的（VISUALIZE、VISUALIZE_EXISTING或ADJUST_PLOT），write_plot_function函数会被激活。它会根据是生成新图表还是调整旧图表，选择相应的提示模板，并向 LLM 提供查询结果 DataFrame 的前几行作为上下文，以确保生成的绘图代码是有效的。绘图函数执行：这是最后一步，execute_plot_function函数会动态地执行上一步生成的 Python 代码，生成一个 Matplotlib 图表对象，并将其存储在状态中。由于这个系统会执行由 LLM 生成的 SQL 和 Python 代码，错误是不可避免的。因此，我们为每一个节点都设计了结构化的错误处理机制。当出现异常时，系统不会崩溃，而是返回一个包含stage（在哪一步失败）、code（标准化错误码）和debug（完整的 Python 追溯信息）的 JSON 对象。这使得开发者能够迅速定位并诊断问题。
Chainlit 为我们提供了一个现成的、功能强大的聊天 UI，将后端引擎和用户连接起来。
历史记录：通过 Chainlit 的元素，我们可以轻松地在侧边栏显示用户的历史提问，保持会话的连续性。状态与展示：on_message函数是整个 UI 的核心。当用户发送消息时，它会调用后端AssistantGraph，并根据返回的状态（特别是意图），决定如何向用户展示结果。元素展示：对于 SQL 查询结果，我们使用cl.Dataframe将其渲染在侧边栏；对于生成的图表，我们使用cl.Pyplot或cl.Plotly（取决于图表类型）将其展示出来。调试信息：当出现错误时，UI 会向用户展示友好的错误提示，并在后台提供详细的 JSON 调试信息，方便开发者快速排查问题。虽然这个 AI 数据助理原型功能强大，但要将它真正投入生产环境，还需要解决一些挑战和限制。
当前的原型仅连接了一个单一的 SQLite 数据库。在实际工作中，企业的数据通常分散在多个数据源中（例如云数据仓库、数据湖、SaaS 应用等）。要打造一个真正可用的产品，需要增加对多种数据库连接器的支持。
目前这个项目止步于本地原型。要实现大规模应用，需要将其容器化并部署到云端。这需要考虑负载均衡、容错和监控等问题。
大语言模型的输出是非确定性的，同样的提问在不同时间可能会产生不同的结果，甚至有时会生成错误的查询或代码。因此，在实际应用中，人工审核和干预仍然是必不可少的，我们需要一个机制来让用户能够纠正错误，并帮助模型学习。
本文使用的是 GPT-4o-mini。不同的 LLM 在 SQL 或代码生成方面各有优劣，选择适合特定任务的模型至关重要。此外，尽管本文的方案在安全性方面做了考虑，但最安全的做法仍然是使用在私有环境中运行的本地大语言模型，确保任何数据都不会离开企业网络。
这个演示项目没有包含访问控制和查询限制。在真实环境中，必须严格管理权限，防止未经授权的用户执行敏感查询，或者生成具有破坏性的代码（例如DELETE或DROP TABLE语句）。
本文所介绍的 AI 数据助理项目，提供了一个坚实的技术框架，它不仅仅是一个将自然语言转化为 SQL 和图表的工具，更是一种全新的工作模式的体现。它通过将复杂的“取数”工作自动化，解放了数据专业人员的生产力，同时赋予了业务用户强大的自助分析能力。
从手动查询到智能对话，从数据等待到即时洞察，这种 AI 驱动的数据助理正逐步改变我们的工作方式。它虽然还有待完善，但其核心思想——利用 AI 赋予数据自助分析新的生命力——无疑指明了数据工作的未来方向。
代码地址：https://github.com/raphaelschols/plot-my-prompt
来源：高效码农