电商运营分析系统产品系统

一个面向淘宝电商运营的内部客服与聊天数据分析系统。它要解决的问题是：客服聊天记录分散在各台电脑的千牛客户端里，运营人员不方便统一查看，也难以基于聊天内容做客服质检和商品需求分析。

客服与会话:维护客服，查看客服与买家会话
聊天记录导入
商品与图片查询:页面包含店铺，商品相关聊天等，聊天可直接从商品或图片打开
账号与权限:支持登录，动态菜单和基于权限的页面访问，用户角色，菜单管理
分析页面:接入大模型，对客服质量进行评价，以及产品洞察等

系统采用前后端分离：前端用 React 做客服、会话、聊天详情、商品、图片、导入和权限管理等页面；后端用 FastAPI 提供业务 API，数据存储在 MySQL
技术栈与架构:
前端：React 18、Vite、JavaScript。
后端：Python、FastAPI、SQLAlchemy、Pydantic、Uvicorn。
数据库：MySQL；数据访问按 Repository 封装。
AI 分析：通过 OpenAI 兼容接口调用大模型，支持配置不同服务商。
调用链：React 页面 → 统一 API 客户端 → Vite 代理 → FastAPI routes → services → repositories → MySQL。应用入口和路由装配分别见后端入口和API 路由，前端代理配置见Vite 配置。
两个实现重点
千牛数据导入链路：因为数据在客服本机，服务器无法直接读取，我实现/参与了本机助手与网页协作的导入方式：助手从本机千牛数据生成 ZIP，网页上传后由后端读取 SQLite、归一化消息类型，再按客服、买家、会话关系写入业务表。导入时会识别已有消息，避免重复写入；商品和图片也会建立关联。入口和处理逻辑可参考千牛导入 API及导入服务。
耗时分析任务的处理：客服评价和商品洞察会调用大模型，不能让页面请求一直等到分析结束。系统先生成带 run_id 的分析记录，再通过 FastAPI 后台任务启动处理；多会话或多商品分析时使用线程池并发执行，并把成功、失败等状态写回数据库。客服评价还会把分析结果关联到聊天消息证据，方便查看依据。任务入口见客服评价路由和商品洞察路由。
难点与处理方式
一个难点是千牛数据源位于用户本机，且消息结构包含文本、图片、商品卡等不同类型。我通过本机助手导出、后端统一解析归一和业务表关联，隔离了本机数据读取与服务器业务处理；对可识别的既有消息做查重，减少重复导入。
另一个难点是聊天记录量大且格式不规整，大模型也有输入长度和调用失败的限制。分析时会整理聊天文本、控制输入长度和并发数，把运行状态与错误结果持久化；客服评价结果保留消息证据 ID，尽量让评分可追溯，而不是只输出一个分数。