实践篇：构建基于LLM与本地Pandas的混合式数据分析引擎

超人阿亚

于 2025-07-23 22:22:38 发布

阅读量1k

点赞数 28

CC 4.0 BY-SA版权

文章标签： pandas 数据分析数据挖掘

本文链接：https://blog.csdn.net/xiaonie1986/article/details/149584132

公众号：dify实验室

基于LLMOps平台-Dify的一站式学习平台。包含不限于：Dify工作流案例、DSL文件分享、模型接入、Dify交流讨论等各类资源分享。

在上一篇《思路探索：当大型语言模型遇见数据分析的现实挑战》中，我们阐述了团队确立的技术路线：利用大型语言模型（LLM）作为自然语言到代码的“翻译器”，并结合Python Pandas库作为后端的高性能“计算核心”。本文将从工程实践的角度，详细拆解该方案的技术实现路径，分享我们如何从零开始，搭建一个稳定、高效且安全的混合式数据分析引擎。

一、核心组件：本地Pandas API服务的构建

我们的架构基石是一个能够接收数据和代码、执行分析并返回结果的Web服务。为保证轻量化与开发效率，我们选择了Flask作为Web框架，并遵循标准的Python项目管理实践。

1.1 环境隔离：虚拟环境的建立

为避免依赖冲突并确保项目环境的纯净性，我们首先通过venv模块创建了一个独立的Python虚拟环境。这是所有专业Python开发的标准起点。

# 在项目根目录创建名为venv的虚拟环境
python -m venv venv

# 激活虚拟环境 (Windows PowerShell)
.\venv\Scripts\activate

在激活状态下，所有后续的包安装都将被隔离在此环境中。

1.2 核心依赖安装

我们的API服务仅需两个核心库：Flask用于构建Web服务，pandas用于数据处理。

pip install Flask pandas

1.3 API接口设计与实现 (`app.py`)

我们设计了一个单一的API端点/execute_on_data，它通过POST方法接收JSON格式的请求体。该请求体包含两个关键字段：code（由LLM生成的Pandas代码字符串）和csv_data（待分析的、CSV格式的完整数据字符串）。

以下是经过多轮迭代后，最终稳定运行的服务端核心代码结构：

from flask import Flask, request, jsonify
import pandas as pd
import io, json, traceback

app = Flask(__name__)

# 关键配置：确保返回的JSON响应能正确显示中文字符
app.json.ensure_ascii = False

def parse_and_clean_data(raw_data_string: str) -> pd.DataFrame:
    # 此处省略了我们最终实现的、用于解析Dify传入的
    # 多种不规范文本格式（如Markdown表格）的健壮解析函数。
    # 其核心是手动进行字符串分割、清理和列名重塑，
    # 而非依赖可能出错的pd.read_csv高级功能。
    # ...
    # 最终目标是返回一个列名干净、数据正确的DataFrame
    pass

@app.route('/execute_on_data', methods=['POST'])
def execute_on_data():
    try:
        data = request.get_json()
        code_to_execute = data['code']
        raw_data_string = data['csv_data']

        # 1. 数据解析与清洗
        df = parse_and_clean_data(raw_data_string)
        if df.empty:
            return jsonify({"status": "error", "message": "解析后的DataFrame为空"}), 400

        # 2. 动态代码执行
        local_vars = {'df': df, 'pd': pd}
        exec(code_to_execute, globals(), local_vars)
        result = local_vars.get('result')

        # 3. 结果序列化
        # to_json确保了Pandas对象能被正确转换为JSON字符串
        # orient='records'生成更易于前端处理的格式
        # force_ascii=False保证了Pandas层面的中文直出
        final_result = result.to_json(orient='records', force_ascii=False)

        return jsonify({"status": "success", "result": final_result})

    except Exception as e:
        # 在调试模式下，打印完整错误堆栈，方便快速定位问题
        traceback.print_exc()
        return jsonify({"status": "error", "message": str(e)}), 500

if __name__ == '__main__':
    # 启动服务，并开启调试模式
    app.run(host='0.0.0.0', port=5000, debug=True)

通过python app.py启动服务，一个本地计算中心便搭建完成。它不仅提供了计算能力，还通过精细的错误处理和调试模式，为后续的联调提供了极大的便利。

二、 Dify工作流编排：构建自动化的数据处理流水线

在Dify的可视化编排界面，我们将上述API服务作为核心节点，构建了一个端到端的数据分析工作流。

架构核心思想
将复杂任务分解，让每个组件专注于其最擅长的部分。LLM负责语言理解与代码生成，本地API负责数据安全与精确计算。

2.1 流水线节点设计

开始节点
配置两个输入变量，一个File类型用于用户上传Excel文件，一个String类型用于用户输入自然语言分析请求。
HTTP请求节点 (数据预处理)
此节点调用Dify内置的文件预览API (/v1/files/preview)，将用户上传的Excel文件转换为CSV格式的文本，并仅截取前10行作为数据样本。这一步是实现“让模型看样本，让代码处理全体”的关键。
大型语言模型节点 (代码生成)此节点是“翻译官”。它接收上一步生成的数据样本和用户的分析请求，通过一个高度优化的提示词（Prompt）模板，生成纯净、可执行的Pandas代码。
关键Prompt策略：在规则中以强制性语气指令模型“必须且只能输出纯粹的Python代码，严禁使用任何Markdown标记”，这是确保后端exec()函数能成功执行的前提。
HTTP请求节点 (核心计算)此节点调用我们本地部署的Pandas API。其请求体（Body）中动态地包含了上一个LLM节点生成的code，以及“开始”节点上传的完整文件内容csv_data。
关键网络配置：当Dify与API服务都通过Docker本地部署时，访问URL需使用Docker内部DNS名称http://host.docker.internal:5000，而非localhost，以实现容器间的正确通信。
大型语言模型节点 (报告生成)
接收本地API返回的、经过精确计算的JSON格式结果，并根据用户的原始问题，将其组织、解读为一段通俗易懂的分析报告。

三、关键技术决策与最终成果

在整个实践过程中，我们做出了一些关键的技术决策，这些决策最终保证了系统的稳定性和健壮性：

数据处理的归属
坚持将海量原始数据的解析和计算任务保留在本地Python环境中，仅将少量、脱敏的样本数据传递给LLM。这在保障数据安全的同时，也极大地降低了LLM的调用成本和响应延迟。
API的健壮性设计
在本地API中编写了强大的数据清洗与格式化函数，使其能够容忍Dify端传入的、可能不完全规范的文本数据，从而避免了因上游微小变化导致的后端服务崩溃。
调试与日志
在开发阶段，充分利用Flask的debug=True模式和traceback模块，使得我们能够快速定位到诸如KeyError、数据格式不匹配等深层次问题，极大地加速了开发迭代周期。

最终，我们成功构建了一个闭环的、自动化的数据分析系统。用户只需通过自然语言交互，即可在数秒内获得对大型Excel文件的深度分析结果。这套架构不仅验证了我们最初的技术设想，也为未来集成更复杂的数据源（如数据库）和更高级的分析模型（如机器学习）打下了坚实的基础。

希望这份详尽的实践分享，能为正在探索LLM应用边界的同行者们提供一份可供参考的技术蓝图。我们相信，通过将LLM的语言能力与专业工具的计算能力进行创造性地结合，将是未来智能应用发展的核心趋势之一。觉得好，请帮忙点赞在看，也可以留言讨论！