【无标题】

斜月三星844

447人浏览 · 2026-04-12 00:23:04

斜月三星844 · 2026-04-12 00:23:04 发布

智能消费管理系统：基于多模态大模型的个人财务助手

一、项目背景：消费数据碎片化的困境

移动支付的普及让“无现金生活”成为常态，但也带来了新的问题：个人的消费数据分散在微信、支付宝、银行App等多个平台，每个平台的数据格式各不相同，缺乏统一的管理视角。

传统记账工具的痛点：

手动输入效率低：每笔消费都需要手动记录，体验割裂
数据孤岛严重：各平台数据无法打通，难以形成全局视图
缺乏智能分析：只能记录流水，无法提供消费洞察和理财建议

这促使我们思考：能否打造一款工具，让用户像聊天一样管理财务，让分散的账单数据自动汇聚、智能分析？

二、项目目的：从“记录工具”到“智能财务助手”

我们设想的系统不是又一个记账软件，而是一个具备认知能力的财务助手：

传统记账	本系统
手动输入每一笔	截图/语音/文件自动识别
固定分类标签	AI自动语义分类
静态流水展示	多维度分析+趋势预测
无交互能力	自然语言对话式查询
无理财建议	个性化优化建议生成

核心目标： 实现从“用户适应工具”到“工具理解用户”的转变。

三、技术选型详解

3.1 整体架构

采用前后端分离 + 模块化设计，支持容器化部署和横向扩展：

┌─────────────────────────────────────────────────┐
│                移动端 (Flutter)                   │
├─────────────────────────────────────────────────┤
│              API Gateway (FastAPI)               │
├──────────────┬──────────────┬───────────────────┤
│   MySQL      │   FAISS      │     Redis         │
│  (结构化数据)  │  (向量检索)   │    (缓存)          │
├──────────────┴──────────────┴───────────────────┤
│              大模型服务层                         │
│  (通义千问/智谱 + Embedding API + Whisper)       │
└─────────────────────────────────────────────────┘

3.2 后端技术栈

组件	选型	理由
Web框架	FastAPI	异步高性能、自动生成OpenAPI文档、类型提示友好
认证	JWT + bcrypt	无状态、安全性高、适合移动端
ORM	SQLAlchemy	功能强大、支持复杂查询、与FastAPI生态融合
数据库	MySQL	成熟稳定、事务支持、索引优化空间大
向量数据库	FAISS	轻量级、内存高效、适合Embedding检索
缓存	Redis	高并发场景下的Token缓存、会话管理
大模型	通义千问/智谱	中文理解优秀、API稳定、支持Function Calling
语音识别	Whisper API	多语言支持、准确率高

3.3 移动端技术栈

组件	选型	理由
跨平台框架	Flutter	单代码库覆盖iOS/Android、高性能、UI表现力强
网络请求	Dio	拦截器支持、请求取消、文件上传功能完善
本地数据库	Drift	类型安全的SQLite、响应式查询、与Flutter结合好
状态管理	GetX	轻量级、路由管理、依赖注入一体化
安全存储	secure_storage	加密存储Token、支持生物识别
原生通信	Pigeon	类型安全的MethodChannel代码生成
无障碍服务	Android原生	监听支付事件、自动识别账单

3.4 为什么选择这些技术？

1. FastAPI + JWT：

移动端需要无状态认证，JWT天然适配
异步处理能力适合大模型调用的IO密集型场景

2. FAISS而非专用向量数据库：

项目初期数据量可控，FAISS足够
避免引入额外运维负担（如Milvus需要独立部署）

3. Flutter跨平台：

目标用户覆盖iOS和Android
热重载提升开发效率
性能接近原生，动画流畅

4. 双数据库策略：

MySQL：存储结构化账单数据，支持复杂筛选
FAISS：存储账单Embedding，支持语义检索

四、核心技术亮点

4.1 多模态统一解析

系统支持三种输入方式，通过不同技术链路统一转化为结构化账单：

输入类型         处理链路                              输出
─────────────────────────────────────────────────────────────
📷 图片账单  →  多模态大模型 / OCR  →  提取金额、商户、时间
🎤 语音输入  →  Whisper API        →  文本 → LLM解析  
📄 文件导入  →  正则解析 + LLM补充  →  标准化数据

技术细节： 对于微信/支付宝导出的Excel文件，我们先通过规则引擎解析标准格式，对异常字段调用LLM进行智能修正。

4.2 消费语义建模

不是简单的关键词匹配，而是基于大模型推理的智能分类：

# 示例：LLM分类Prompt
你是一个消费分类专家，请将以下商户归类到指定类别：
- 餐饮：餐厅、咖啡店、外卖
- 交通：地铁、打车、加油
- 娱乐：电影、游戏、演出
- 购物：超市、电商、服装
- 居住：房租、水电、物业

商户名称："星巴克（国贸店）" → 输出：餐饮

4.3 RAG增强的对话式分析

用户提问 → 向量化 → FAISS检索相关账单 → 构建上下文Prompt → LLM生成回答

用户问：“我这个月是不是在吃上面花太多了？”
         ↓
系统检索：本月餐饮类TOP10消费记录 + 上月对比数据
         ↓
LLM回答：“您本月餐饮支出3200元，较上月增长15%，其中外卖占比60%。建议适当增加做饭频率...”

4.4 无障碍自动识别（Android独有）

利用Android无障碍服务监听支付成功页面的文本变化，自动提取金额和商户：

用户支付完成 → 无障碍服务捕获页面文本 → 正则提取金额/商户 → 弹出确认对话框 → 一键添加

隐私保护： 只读取支付成功页面的文本，不上传任何敏感信息，所有识别均在本地完成。

五、数据流设计

┌──────────┐    ┌──────────┐    ┌──────────┐
│ 用户输入  │ -> │ 多模态解析 │ -> │ 结构化存储 │
└──────────┘    └──────────┘    └──────────┘
                                      ↓
┌──────────┐    ┌──────────┐    ┌──────────┐
│ LLM回答  │ <- │  RAG检索  │ <- │ 向量化    │
└──────────┘    └──────────┘    └──────────┘

增量同步机制：