Dify + 本地大模型：一个数据分析项目原型验证的正确打开方式

原创于 2025-06-24 15:46:55 发布 · 835 阅读

CC 4.0 BY-SA版权

文章标签：

#数据分析 #数据挖掘 #人工智能 #大模型 #ai大模型 #dify #LLM

前段时间，我构思了一个关于数据分析的个人项目，代号叫“明镜”。简单来说，就是想用一套现代化的数据技术栈（FastAPI, SQLAlchemy, PostgreSQL, Pandas.ai，Streamlit等等），打造一个能整合、分析个人银行流水，这是基础功能。同时高端一点的就是为关于银行流水证据调查提供数据分析支持的工具。

这个计划，从后端、数据库到前端，如果按部就班地开发，会是一个比较长的过程，特别是这个已经超出了我学习 FastAPI 的范畴了。数据分析是 Python 中非常大的一块专业的知识了。那么我们这个项目当中的第四阶段：“拥抱AI，智能分析”是我最期待的部分，因为比较有趣，我也好奇当我把大量的表格数据喂给 AI 的话，他到底能不能像我设想的那样，能全面准确地给我分析一遍。

正好最近看到一个观点，就是在构思项目原型的时候，可以先用 Dify 或者 n8n 这样的平台先搭建个工作流，把项目的各个模块功能放进去串起来跑一下，验证一下效果。当然对于我这个项目来说，本身的构想并没有多么新颖，现成的数据分析产品应该有好多了，整合好的数据喂给 AI 来分析研究也不是什么新鲜玩意儿。

因为要给之前的那个 RAG 的小项目在本地部署方便使用的模型，我用 Ollama 拉了个 deepseek-r1:8b 的模型作为回答问题的模型，然后加上想试试本地部署 Dify 。正好用这个组合来实践一下我在网上看到的这个观点，总之就是各种捣鼓。

这篇文章，就是想和大家聊聊这次原型试验的大体过程，也算是非常有趣了。我的 Ollama 和 Dify 都是使用 Docker 在本地部署的，具体的部署情况就不介绍了非常简单，看看官方文档跟着搞一下就好了。

第一部分：用 Dify 编排工作流

在正式动工前，先验证最核心、最不确定的部分，这是敏捷开发的精髓。我的目标很明确：就是想体验一下Dify这个产品，同时看看AI分析流水到底靠不靠谱。

为了让这次试验能纯粹地聚焦在AI的分析能力上，我决定先绕开真实项目中最头疼的一步：数据清洗。另外一个原因就是 Dify 还是聚焦于 AI 相关的功能，他的节点当中主要是跟 AI 相关的各种功能节点，其他的基本上没有。这方面 n8n 可能更好点，后面再研究下 n8n 。现实中的银行流水格式五花八门，处理起来非常麻烦。那么这里是为了验证使用我先用了一个非常简单的小表格，里面就放了几条数据。看看 AI 这位“大厨”到底能做出什么菜。

我在Dify上搭建的原型流程非常经典，只有简单的四个节点：

开始` ➡️ `文档提取器` ➡️ `LLM（AI模型）` ➡️ `结果输出

\1. 开始：这里就是我的操作台，可以上传准备好的CSV文件，还能输入我想问AI的问题，那么对这个简单的表，我问的问题是“帮我计算一下总支出是多少？”。
\2. 文档提取器：这个节点特别关键。AI自己其实不认识“.csv”这种文件。这个节点就像一个翻译官，负责把文件打开，把里面的文字内容提取出来，变成AI能看懂的格式。没有它，后面的一切都无从谈起。
\3. LLM：这是整个流程的大脑。我把它连接到我本地电脑上通过Ollama跑的deepseek-r1:8b大模型。它会同时收到从文件里提取出来的数据，和我提出的问题。
\4. 结果输出：把AI分析后的答案显示出来。

整个过程几分钟就搭好了，一个可以和AI对话的分析工具原型就这么诞生了。那么最后 AI 经过思考，把所有标记为负数的值做个了求和，最后给我算出来总支出。简单的数据模型处理起来还是比较游刃有余的。

第二部分：测试复杂数据

基础的流程跑通之后，就让他来试试复杂数据，我让 AI 给出了一份带有可疑交易的，内容多一点的 mock 表格。

结果一言难尽。AI 思考了半天，确实输出了洋洋洒洒的分析报告，但仔细一看，都没在点子上。

• 它能看到一些最表面的东西，比如交易时间在半夜，或者交易地点在国外。
• 但对于需要把好几条数据连起来看才能发现的“拆分交易”模式，它完全没反应。
• 对于那笔“巨款流入后短时间又迅速流出”的明显洗钱特征，它也视而不见，还认为这是“正常的投资理财和家庭开支”。

然后我尝试去优化提示词，把各种金融专家的分析方法都写进去教它，结果适得其反，它干脆“罢工”了，把所有交易都判断为“正常”。

从这个结果来看：我们真的不能对当前通用大模型的逻辑推理能力抱有不切实际的幻想。 让它去独立完成这种需要高度严谨、多步推理的复杂分析任务，它真的会“力不从心”。目前可以引入，但是只能安排点辅助工作。至于使用 API 来直接调用普通的模型，我觉得可能会好点，但也不能幻想用 AI 来代替人的分析。

第三部分：我们到底该让AI做什么？

那么回到之前的这个项目构思里，想引入 AI 的话，他在项目里到底能干点什么？

AI的终极定位：一个能听懂人话的“数据库查询翻译官”

不应该是指望 AI 包办一切，而应该是一个各司其职、完美协作的专业团队。

我用一个大餐厅的运作流程来解释，会非常清晰：

• 1. 食材初加工区 (Pandas)：
餐厅每天从不同的供应商那里收到各种食材（就像我们从不同银行拿到格式五花八门的流水文件），有的带着泥，有的尺寸不一。这些原始食材是不能直接进仓库或下锅的。Pandas 就像是这个初加工区里最得力的帮厨团队，他们负责把所有杂乱的食材进行清洗、整理和标准化。比如，把A供应商送来的长条土豆和B供应商送来的圆形土豆，全都削皮、清洗，然后统一切成标准的滚刀块。这个过程，就是我们项目中的“数据清洗”阶段，确保所有进入我们系统的交易数据都是干净、统一、立即可用的。
• 2. 后台数据库（PostgreSQL）：
这里是餐厅那个巨大、干净、所有食材都摆放得井井有条的恒温仓库。经过“食材初加工区”处理好的标准食材（干净、统一的交易数据），被整齐地码放在这里，随时等待厨房调用。它的特点是精确、可靠、存取快速。
• 3. 后端代码（FastAPI + SQLAlchemy）：
这是全自动化的机器人厨房。厨房里有各种精确的菜谱（我们的代码逻辑），它知道怎么根据订单，从“数据仓库”里又快又准地取出需要的食材（数据），然后进行分毫不差的烹饪（计算、聚合、筛选）。
• 4. 前端界面（Streamlit）：
这就是你坐的餐桌，干净整洁。你在这里点餐，也在这里享用厨房做好的菜品（数据分析结果）。
• 5. AI（聪明伶俐的点餐员）：
现在，AI的真正角色来了。你不需要去研究厨房厚厚的、写满专业术语的菜单（比如SQL查询语句），你只需要用大白话对这个点餐员说：“我想要一份上个月所有吃饭的账单，再帮我算算一共花了多少钱。”

这个聪明的“点餐员”在将你的话翻译成“厨房行话”时，就可以使用像 PandasAI 这样的神奇工具。你告诉它“我想看看上个月什么东西花钱最多”，PandasAI就能帮助AI生成一段精确的查询指令，去操作刚刚从后厨取出的那盘“食材”（数据），然后找出答案，最后再由AI用你最舒服的方式告诉你。

总结一下这个流程：

原始、混乱的银行流水文件 ➡️ Pandas进行清洗和标准化 ➡️ 存入干净的PostgreSQL数据库 ➡️ 你在Streamlit前端用大白话提问 ➡️ AI（在PandasAI等工具的帮助下）将你的话翻译成精确的查询指令 ➡️ FastAPI后端执行指令，从数据库中取出数据并计算 ➡️ 最终结果呈现在你的面前。

在这个流程里：

• Pandas 保证了我们“入库数据”的质量。
• AI (PandasAI) 保证了我们“人机交互”的流畅和智能。
• 后端和数据库 保证了我们“数据处理”的准确和高效。

这样一来，整个“明镜”项目的蓝图就非常清晰、完整且可靠了。每一个环节都有最适合它的工具来负责，这才是构建一个强大数据分析应用的正确方式。

AI能立刻听懂你的话，然后转身用厨房能听懂的“行话”，在点餐系统上下单。几秒钟后，机器人厨房就把精确无误的菜品（数据结果）送到了你的餐桌上。

在这个模式里，AI负责和人打交道，代码和数据库负责保证结果的绝对准确。这才是最靠谱、最强大的工作方式。

AI的其他定位：一个有趣、有温度的“贴心财务管家”

那么除了作为自然语言查询的翻译，AI 还能干什么。也可以做点有趣的工作，把这个项目当作个人财务分析小工具来用的话。

• 它可以是“财务顾问”：我们用代码把上个月的总收支、储蓄率算好，然后把这些准确的数字喂给AI，让它用鼓励的、友善的语言，帮我们生成一份图文并茂的财务月报，再提点小建议。它负责“表达”，我们负责“准确”。
• 它可以是“百变伙伴”：我们可以通过改变给AI的“人设”指令，让它扮演不同的角色。今天可以让它当一个说话严谨的“CFO”，明天可以让他当一个满嘴骚话的“毒舌监工”，后天又可以变成一个给你加油打气的“热心伙伴”。这让枯燥的财务分析过程，充满了互动和乐趣。