数据文件保存机构改为### 1.2. 文件存储位置 - **最终产物**: 所有最终模型、元数据文件、损失图等,统一存放在 `saved_models/` 根目录下。 - **过程文件**: 所有训练过程中的检查点文件,统一存放在 `saved_models/checkpoints/` 目录下。 ### 1.3. 文件名生成规则 1. **构建逻辑路径**: 根据训练参数(模式、范围、类型、版本)确定逻辑路径。 - *示例*: `product/P001_all/mlstm/v2` 2. **生成文件名前缀**: 将逻辑路径中的所有 `/` 替换为 `_`。 - *示例*: `product_P001_all_mlstm_v2` 3. **拼接文件后缀**: 在前缀后加上描述文件类型的后缀。 - `_model.pth` - `_loss_curve.png` - `_checkpoint_best.pth` - `_checkpoint_epoch_{N}.pth` #### **完整示例:** - **最终模型**: `saved_models/product_P001_all_mlstm_v2_model.pth` - **最佳检查点**: `saved_models/checkpoints/product_P001_all_mlstm_v2_checkpoint_best.pth` - **Epoch 50 检查点**: `saved_models/checkpoints/product_P001_all_mlstm_v2_checkpoint_epoch_50.pth`
50 lines
2.9 KiB
Markdown
50 lines
2.9 KiB
Markdown
# 模型预测路径修复记录
|
||
|
||
**修改时间**: 2025-07-18 18:43:50
|
||
|
||
## 1. 问题背景
|
||
|
||
系统在进行模型预测时出现“文件未找到”的错误。经分析,根本原因是模型加载逻辑(预测时)与模型保存逻辑(训练时)遵循了不一致的路径规则。
|
||
|
||
- **保存规则 (新)**: 遵循 `xz训练模型保存规则.md`,将模型保存在结构化的层级目录中,例如 `saved_models/product/{product_id}_all/mlstm/v1/model.pth`。
|
||
- **加载逻辑 (旧)**: 代码中硬编码了扁平化的文件路径查找方式,例如在 `saved_models` 根目录下直接查找名为 `{product_id}_{model_type}_v1.pth` 的文件。
|
||
|
||
这种不匹配导致预测功能无法定位到已经训练好的模型。
|
||
|
||
## 2. 修复方案
|
||
|
||
为了解决此问题,我们采取了集中化路径管理的策略,确保整个应用程序都通过一个统一的管理器来生成和获取模型路径。
|
||
|
||
## 3. 代码修改详情
|
||
|
||
### 第一处修改:增强路径管理器
|
||
|
||
- **文件**: [`server/utils/file_save.py`](server/utils/file_save.py)
|
||
- **操作**: 在 `ModelPathManager` 类中新增了 `get_model_path_for_prediction` 方法。
|
||
- **目的**:
|
||
- 提供一个专门用于**预测时**获取模型路径的函数。
|
||
- 该函数严格按照 `xz训练模型保存规则.md` 中定义的层级结构来构建模型文件的完整路径。
|
||
- 这使得路径生成逻辑被集中管理,避免了代码各处的硬编码。
|
||
|
||
### 第二处修改:修复API预测接口
|
||
|
||
- **文件**: [`server/api.py`](server/api.py)
|
||
- **操作**:
|
||
1. 修改了 `/api/prediction` 接口 (`predict` 函数) 的内部逻辑。
|
||
2. 修改了辅助函数 `run_prediction` 的定义和实现。
|
||
- **目的**:
|
||
- **`predict` 函数**: 移除了所有旧的、手動拼接模型文件名的错误逻辑。转而实例化 `ModelPathManager` 并调用其新的 `get_model_path_for_prediction` 方法来获取准确、唯一的模型路径。
|
||
- **`run_prediction` 函数**: 更新了其函数签名,增加了 `model_path` 参数,使其能够接收并向下传递由 `predict` 函数获取到的正确路径。同时,简化了其内部逻辑,直接调用 `load_model_and_predict`。
|
||
|
||
### 第三处修改:修复模型加载器
|
||
|
||
- **文件**: [`server/predictors/model_predictor.py`](server/predictors/model_predictor.py)
|
||
- **操作**: 修改了 `load_model_and_predict` 函数。
|
||
- **目的**:
|
||
- 更新函数签名,添加了 `model_path` 参数。
|
||
- **彻底移除了**函数内部所有复杂的、用于猜测模型文件位置的旧逻辑。
|
||
- 函数现在完全依赖于从 `api.py` 传递过来的 `model_path` 参数来加载模型,确保了加载路径的准确性。
|
||
|
||
## 4. 结论
|
||
|
||
通过以上三处修改,我们打通了从API请求到模型文件加载的整个链路,确保了所有环节都遵循统一的、正确的结构化路径规则。这从根本上解决了因路径不匹配导致模型读取失败的问题。 |