xz2000
18f505a090
# 修改记录日志 (日期: 2025-07-16) ---未改全
## 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` 现在直接调用实际的训练器，不再有模拟延迟，代码更贴近生产环境。
2025-07-16 16:51:38 +08:00
..
2025-07-02 11:05:23 +08:00
2025-06-18 06:39:41 +08:00
2025-07-16 16:51:38 +08:00
2025-07-16 16:51:38 +08:00
2025-07-16 16:51:38 +08:00
2025-07-16 16:51:38 +08:00