## 1. 训练流程与模型保存逻辑修复 (重大) - **背景**: 用户报告在“按店铺”和“按药品”模式下,如果选择了特定的子集(如为某个店铺选择特定药品),生成的模型范围 (`scope`) 不正确,始终为 `_all`。此外,所有模型都被错误地保存到 `global` 目录下,且在某些模式下训练会失败。 - **根本原因**: 1. `server/core/predictor.py` 中负责准备训练参数的内部函数 (`_prepare_product_params`, `_prepare_store_params`) 逻辑有误,未能正确处理传入的 `product_ids` 和 `store_ids` 列表来构建详细的 `scope`。 2. 各个训练器 (`server/trainers/*.py`) 内部的日志记录和元数据生成逻辑不统一,且过于依赖 `product_id`,导致在全局或店铺模式下信息展示不清晰。 - **修复方案**: - **`server/core/predictor.py`**: - **重构 `_prepare_product_params` 和 `_prepare_store_params`**: 修改了这两个函数,使其能够正确使用 `product_ids` 和 `store_ids` 列表。现在,当选择特定范围时,会生成更具描述性的 `scope`,例如 `S001_specific_P001_P002`。 - **结果**: 确保了传递给模型管理器的 `scope` 是准确且详细的,从而使模型能够根据训练范围被保存到正确的、独立的文件夹中。 - **`server/trainers/*.py` (mlstm, kan, tcn, transformer)**: - **标准化日志与元数据**: 对所有四个训练器文件进行了统一修改。引入了一个通用的 `training_description` 变量,该变量整合了 `training_mode`、`scope` 和 `aggregation_method`。 - **更新输出**: 修改了所有训练器中的日志消息、图表标题和 `metadata.json` 的生成逻辑,使其全部使用这个标准的 `training_description`。 - **结果**: 确保了无论在哪种训练模式下,前端收到的日志、保存的图表和元数据都具有一致、清晰的格式,便于调试和结果追溯。 - **总体影响**: 此次修复从根本上解决了模型训练范围处理和模型保存路径的错误问题,使整个训练系统在所有模式下都能可靠、一致地运行。 --- ## 2. 核心 Bug 修复 ### 文件: `server/core/predictor.py` - **问题**: 在 `train_model` 方法中调用内部辅助函数 `_prepare_training_params` 时,没有正确传递 `product_ids` 和 `store_ids` 参数,导致在 `_prepare_training_params` 内部发生 `NameError`。 - **修复**: - 修正了 `train_model` 方法内部对 `_prepare_training_params` 的调用,确保 `product_ids` 和 `store_ids` 被显式传递。 - 此前已修复 `train_model` 的函数签名,使其能正确接收 `store_ids`。 - **结果**: 彻底解决了训练流程中的参数传递问题,根除了由此引发的 `NameError`。 ## 3. 代码清理与重构 ### 文件: `server/api.py` - **内容**: 移除了在 `start_training` API 端点中遗留的旧版、基于线程(`threading.Thread`)的训练逻辑。 - **原因**: 该代码块已被新的、基于多进程(`multiprocessing`)的 `TrainingProcessManager` 完全取代。旧代码中包含了大量用于调试的 `thread_safe_print` 日志,已无用处。 - **结果**: `start_training` 端点的逻辑变得更加清晰,只负责参数校验和向 `TrainingProcessManager` 提交任务。 ### 文件: `server/utils/training_process_manager.py` - **内容**: 在 `TrainingWorker` 的 `run_training_task` 方法中,移除了一个用于模拟训练进度的 `for` 循环。 - **原因**: 该循环包含 `time.sleep(1)`,仅用于在没有实际训练逻辑时模拟进度更新,现在实际的训练器会通过回调函数报告真实进度,因此该模拟代码不再需要。 - **结果**: `TrainingWorker` 现在直接调用实际的训练器,不再有模拟延迟,代码更贴近生产环境。
药店销售预测系统
这是一个基于多种深度学习模型的药店销售预测系统,支持多种时序预测模型,包括 Transformer、mLSTM、KAN 和 TCN。
功能特点
- 支持多种深度学习模型进行销量预测
- 提供命令行界面和API服务两种使用方式
- 支持模型训练、预测和评估
- 提供预测结果可视化和分析
- 支持模型比较和管理
项目结构
├── core/ # 核心模块
│ ├── __init__.py
│ ├── config.py # 全局配置参数
│ └── predictor.py # 核心预测器类
├── trainers/ # 模型训练器
│ ├── __init__.py
│ ├── mlstm_trainer.py # mLSTM模型训练函数
│ ├── kan_trainer.py # KAN模型训练函数
│ ├── tcn_trainer.py # TCN模型训练函数
│ └── transformer_trainer.py # Transformer模型训练函数
├── predictors/ # 预测模块
│ ├── __init__.py
│ └── model_predictor.py # 模型预测函数
├── analysis/ # 分析模块
│ ├── __init__.py
│ ├── metrics.py # 评估指标计算函数
│ ├── trend_analysis.py # 趋势分析函数
│ └── explanation.py # 预测解释函数
├── utils/ # 工具模块
│ ├── __init__.py
│ ├── data_utils.py # 数据处理工具函数
│ └── visualization.py # 可视化工具函数
├── models/ # 模型定义
│ ├── transformer_model.py
│ ├── mlstm_model.py
│ ├── kan_model.py
│ ├── tcn_model.py
│ └── optimized_kan_forecaster.py
├── pharmacy_predictor.py # 主接口文件
├── run_pharmacy_prediction.py # 命令行运行入口
├── api.py # API服务入口
└── pharmacy_sales.xlsx # 示例数据文件
支持的模型
- Transformer: 基于自注意力机制的时序预测模型
- mLSTM: 矩阵LSTM模型,结合了LSTM和Transformer的优点
- KAN: Kolmogorov-Arnold Network,一种基于柯尔莫哥洛夫-阿诺德定理的神经网络
- TCN: 时间卷积网络,使用因果卷积进行时序建模
- 优化版KAN: 经过优化的KAN模型,提高了预测精度和训练效率
使用方法
命令行界面
运行命令行界面:
python run_pharmacy_prediction.py
API服务
启动API服务:
python api.py
代码中使用
from pharmacy_predictor import PharmacyPredictor
# 创建预测器实例
predictor = PharmacyPredictor(data_path='pharmacy_sales.xlsx')
# 训练模型
metrics = predictor.train_model(product_id='P001', model_type='tcn', epochs=50)
# 使用模型预测
result = predictor.predict(product_id='P001', model_type='tcn', future_days=7, analyze_result=True)
依赖库
- PyTorch
- pandas
- numpy
- matplotlib
- scikit-learn
- Flask (用于API服务)
- pytorch-tcn (用于TCN模型)
Description
Languages
Python
73.3%
Vue
22%
HTML
1.8%
CSS
1.1%
Batchfile
0.8%
Other
1%