OneTree/ShopTRAINING
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
16 Commits 7 Branches 0 Tags
Commit Graph

9 Commits

Author SHA1 Message Date
xz2000
28bae35783 # 扁平化模型数据处理规范 (最终版) 
**版本**: 4.0 (最终版)
**核心思想**: 逻辑路径被转换为文件名的一部分，实现极致扁平化的文件存储。

---

## 一、 文件保存规则

### 1.1. 核心原则

所有元数据都被编码到文件名中。一个逻辑上的层级路径（例如 `product/P001_all/mlstm/v2`）应该被转换为一个用下划线连接的文件名前缀（`product_P001_all_mlstm_v2`）。

### 1.2. 文件存储位置

-   **最终产物**: 所有最终模型、元数据文件、损失图等，统一存放在 `saved_models/` 根目录下。
-   **过程文件**: 所有训练过程中的检查点文件，统一存放在 `saved_models/checkpoints/` 目录下。

### 1.3. 文件名生成规则

1.  **构建逻辑路径**: 根据训练参数（模式、范围、类型、版本）确定逻辑路径。
    -   *示例*: `product/P001_all/mlstm/v2`

2.  **生成文件名前缀**: 将逻辑路径中的所有 `/` 替换为 `_`。
    -   *示例*: `product_P001_all_mlstm_v2`

3.  **拼接文件后缀**: 在前缀后加上描述文件类型的后缀。
    -   `_model.pth`
    -   `_metadata.json`
    -   `_loss_curve.png`
    -   `_checkpoint_best.pth`
    -   `_checkpoint_epoch_{N}.pth`

#### **完整示例:**

-   **最终模型**: `saved_models/product_P001_all_mlstm_v2_model.pth`
-   **元数据**: `saved_models/product_P001_all_mlstm_v2_metadata.json`
-   **最佳检查点**: `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`

---

## 二、 文件读取规则

1.  **确定模型元数据**: 根据需求确定要加载的模型的训练模式、范围、类型和版本。
2.  **构建文件名前缀**: 按照与保存时相同的逻辑，将元数据拼接成文件名前缀（例如 `product_P001_all_mlstm_v2`）。
3.  **定位文件**:
    -   要加载最终模型，查找文件: `saved_models/{prefix}_model.pth`。
    -   要加载最佳检查点，查找文件: `saved_models/checkpoints/{prefix}_checkpoint_best.pth`。

---

## 三、 数据库存储规则

数据库用于索引，应存储足以重构文件名前缀的关键元数据。

#### **`models` 表结构建议:**

| 字段名 | 类型 | 描述 | 示例 |
| :--- | :--- | :--- | :--- |
| `id` | INTEGER | 主键 | 1 |
| `filename_prefix` | TEXT | **完整文件名前缀，可作为唯一标识** | `product_P001_all_mlstm_v2` |
| `model_identifier`| TEXT | 用于版本控制的标识符 (不含版本) | `product_P001_all_mlstm` |
| `version` | INTEGER | 版本号 | `2` |
| `status` | TEXT | 模型状态 | `completed`, `training`, `failed` |
| `created_at` | TEXT | 创建时间 | `2025-07-21 02:29:00` |
| `metrics_summary`| TEXT | 关键性能指标的JSON字符串 | `{"rmse": 10.5, "r2": 0.89}` |

#### **保存逻辑:**
-   训练完成后，向表中插入一条记录。`filename_prefix` 字段是查找与该次训练相关的所有文件的关键。

---

## 四、 版本记录规则

版本管理依赖于根目录下的 `versions.json` 文件，以实现原子化、线程安全的版本号递增。

-   **文件名**: `versions.json`
-   **位置**: `saved_models/versions.json`
-   **结构**: 一个JSON对象，`key` 是不包含版本号的标识符，`value` 是该标识符下最新的版本号（整数）。
    -   **Key**: `{prefix_core}_{model_type}` (例如: `product_P001_all_mlstm`)
    -   **Value**: `Integer`

#### **`versions.json` 示例:**
```json
{
  "product_P001_all_mlstm": 2,
  "store_S001_P002_transformer": 1
}
```

#### **版本管理流程:**

1.  **获取新版本**: 开始训练前，构建 `key`。读取 `versions.json`，找到对应 `key` 的 `value`。新版本号为 `value + 1` (若key不存在，则为 `1`)。
2.  **更新版本**: 训练成功后，将新的版本号写回到 `versions.json`。此过程**必须使用文件锁**以防止并发冲突。

调试完成药品预测和店铺预测
 2025-07-21 16:39:52 +08:00
xz2000
341d8d179c -- 
**日期**: 2025-07-18
**主题**: 统一训练页面UI显示并修复后端数据传递

### 问题描述
1.  在“按店铺训练”和“全局模型训练”页面的任务列表中，模型版本号前缺少 'v' 前缀，与“按品训练”页面不一致。
2.  在“全局模型训练”页面的任务列表中，“聚合方式”一列始终为空，无法显示数据。

### 根本原因
1.  **UI层面**: `UI/src/views/StoreTrainingView.vue` 和 `UI/src/views/training/GlobalTrainingView.vue` 在渲染版本号时，没有像 `ProductTrainingView.vue` 一样添加 'v' 前缀的模板。
2.  **后端层面**: `server/utils/training_process_manager.py` 中的 `TrainingTask` 数据类缺少 `aggregation_method` 字段，导致从任务提交到数据返回的整个流程中，该信息都丢失了。

### 解决方案
1.  **修复前端UI**:
    *   **文件**: `UI/src/views/StoreTrainingView.vue`, `UI/src/views/training/GlobalTrainingView.vue`
    *   **操作**: 修改了 `el-table-column` for `version`，为其添加了 `<template>`，使用 `<el-tag>v{{ row.version }}</el-tag>` 来渲染版本号，确保了显示格式的统一。

2.  **修复后端数据流**:
    *   **文件**: `server/utils/training_process_manager.py`
    *   **操作**:
        1.  在 `TrainingTask` 数据类中增加了 `aggregation_method: Optional[str] = None` 字段。
        2.  修改 `submit_task` 方法，使其在创建 `TrainingTask` 对象时能接收并设置 `aggregation_method`。
        3.  修改 `run_training_task` 方法，在调用 `predictor.train_model` 时，将 `task.aggregation_method` 传递下去。

### 最终结果
通过前后端的协同修复，现在所有训练页面的UI表现完全一致，并且全局训练的“聚合方式”能够被正确记录和显示。
 2025-07-18 18:18:50 +08:00
xz2000
5b2cdfa74a --- 
**日期**: 2025-07-18
**主题**: 模型保存逻辑重构与集中化管理

### 目标
根据 `xz训练模型保存规则.md`，将系统中分散的模型文件保存逻辑统一重构，创建一个集中、健壮且可测试的路径管理系统。

### 核心成果
1.  **创建了 `server/utils/file_save.py` 模块**: 这个新模块现在是系统中处理模型文件保存路径的唯一权威来源。
2.  **实现了三种训练模式的路径生成**: 系统现在可以为“按店铺”、“按药品”和“全局”三种训练模式正确生成层级化的、可追溯的目录结构。
3.  **集成了智能ID处理**:
    *   对于包含**多个ID**的训练场景，系统会自动计算一个简短的哈希值作为目录名。
    *   对于全局训练中只包含**单个店铺或药品ID**的场景，系统会直接使用该ID作为目录名，增强了路径的可读性。
4.  **重构了整个训练流程**: 修改了API层、进程管理层以及所有模型训练器，使它们能够协同使用新的路径管理模块。
5.  **添加了自动化测试**: 创建了 `test/test_file_save_logic.py` 脚本，用于验证所有路径生成和版本管理逻辑的正确性。

### 详细文件修改记录

1.  **`server/utils/file_save.py`**
    *   **操作**: 创建
    *   **内容**: 实现了 `ModelPathManager` 类，包含以下核心方法：
        *   `_hash_ids`: 对ID列表进行排序和哈希。
        *   `_generate_identifier`: 根据训练模式和参数生成唯一的模型标识符。
        *   `get_next_version` / `save_version_info`: 线程安全地管理 `versions.json` 文件，实现版本号的获取和更新。
        *   `get_model_paths`: 作为主入口，协调以上方法，生成包含所有产物路径的字典。

2.  **`server/api.py`**
    *   **操作**: 修改
    *   **位置**: `start_training` 函数 (`/api/training` 端点)。
    *   **内容**:
        *   导入并实例化 `ModelPathManager`。
        *   在接收到训练请求后，调用 `path_manager.get_model_paths()` 来获取所有路径信息。
        *   将获取到的 `path_info` 字典和原始请求参数 `training_params` 一并传递给后台训练任务管理器。
        *   修复了因重复传递关键字参数 (`model_type`, `training_mode`) 导致的 `TypeError`。
        *   修复了 `except` 块中因未导入 `traceback` 模块导致的 `UnboundLocalError`。

3.  **`server/utils/training_process_manager.py`**
    *   **操作**: 修改
    *   **内容**:
        *   修改 `submit_task` 方法，使其能接收 `training_params` 和 `path_info` 字典。
        *   在 `TrainingTask` 数据类中增加了 `path_info` 字段来存储路径信息。
        *   在 `TrainingWorker` 中，将 `path_info` 传递给实际的训练函数。
        *   在 `_monitor_results` 方法中，当任务成功完成时，调用 `path_manager.save_version_info` 来更新 `versions.json`，完成版本管理的闭环。

4.  **所有训练器文件** (`mlstm_trainer.py`, `kan_trainer.py`, `tcn_trainer.py`, `transformer_trainer.py`)
    *   **操作**: 修改
    *   **内容**:
        *   统一修改了主训练函数的签名，增加了 `path_info=None` 参数。
        *   移除了所有内部手动构建文件路径的逻辑。
        *   所有保存操作（最终模型、检查点、损失曲线图）现在都直接从传入的 `path_info` 字典中获取预先生成好的路径。
        *   简化了 `save_checkpoint` 辅助函数，使其也依赖 `path_info`。

5.  **`test/test_file_save_logic.py`**
    *   **操作**: 创建
    *   **内容**:
        *   编写了一个独立的测试脚本，用于验证 `ModelPathManager` 的所有功能。
        *   覆盖了所有训练模式及其子场景（包括单ID和多ID哈希）。
        *   测试了版本号的正确递增和 `versions.json` 的写入。
        *   修复了测试脚本中因绝对/相对路径不匹配和重复关键字参数导致的多个 `AssertionError` 和 `TypeError`。

---
**日期**: 2025-07-18 (后续修复)
**主题**: 修复API层调用路径管理器时的 `TypeError`

### 问题描述
在完成所有重构和测试后，实际运行API时，`POST /api/training` 端点在调用 `path_manager.get_model_paths` 时崩溃，并抛出 `TypeError: get_model_paths() got multiple values for keyword argument 'training_mode'`。

### 根本原因
这是一个回归错误。在修复测试脚本 `test_file_save_logic.py` 中的类似问题时，我未能将相同的修复逻辑应用回 `server/api.py`。代码在调用 `get_model_paths` 时，既通过关键字参数 `training_mode=...` 明确传递了该参数，又通过 `**data` 将其再次传入，导致了冲突。

### 解决方案
1.  **文件**: `server/api.py`
2.  **位置**: `start_training` 函数。
3.  **操作**: 修改了对 `get_model_paths` 的调用逻辑。
4.  **内容**:
    ```python
    # 移除 model_type 和 training_mode 以避免重复关键字参数错误
    data_for_path = data.copy()
    data_for_path.pop('model_type', None)
    data_for_path.pop('training_mode', None)
    path_info = path_manager.get_model_paths(
        training_mode=training_mode,
        model_type=model_type,
        **data_for_path  # 传递剩余的payload
    )
    ```
5.  **原因**: 在通过 `**` 解包传递参数之前，先从字典副本中移除了所有会被明确指定的关键字参数，从而确保了函数调用签名的正确性。

---
**日期**: 2025-07-18 (最终修复)
**主题**: 修复因中间层函数签名未更新导致的 `TypeError`

### 问题描述
在完成所有重构后，实际运行API并触发训练任务时，程序在后台进程中因 `TypeError: train_model() got an unexpected keyword argument 'path_info'` 而崩溃。

### 根本原因
这是一个典型的“中间人”遗漏错误。我成功地修改了调用链的两端（`api.py` -> `training_process_manager.py` 和 `*_trainer.py`），但忘记了修改它们之间的中间层——`server/core/predictor.py` 中的 `train_model` 方法。`training_process_manager` 尝试将 `path_info` 传递给 `predictor.train_model`，但后者的函数签名中并未包含这个新参数，导致了 `TypeError`。

### 解决方案
1.  **文件**: `server/core/predictor.py`
2.  **位置**: `train_model` 函数的定义处。
3.  **操作**: 在函数签名中增加了 `path_info=None` 参数。
4.  **内容**:
    ```python
    def train_model(self, ..., progress_callback=None, path_info=None):
        # ...
    ```
5.  **位置**: `train_model` 函数内部，对所有具体训练器（`train_product_model_with_mlstm`, `_with_kan`, etc.）的调用处。
6.  **操作**: 在所有调用中，将接收到的 `path_info` 参数透传下去。
7.  **内容**:
    ```python
    # ...
    metrics = train_product_model_with_transformer(
        ...,
        path_info=path_info
    )
    # ...
    ```
8.  **原因**: 通过在中间层函数上“打通”`path_info` 参数的传递通道，确保了从API层到最终训练器层的完整数据流，解决了 `TypeError`。

---
**日期**: 2025-07-18 (最终修复)
**主题**: 修复“按药品训练-聚合所有店铺”模式下的路径生成错误

### 问题描述
在实际运行中发现，当进行“按药品训练”并选择“聚合所有店铺”时，生成的模型保存路径中包含了错误的后缀 `_None`，而不是预期的 `_all` (例如 `.../17002608_None/...`)。

### 根本原因
在 `server/utils/file_save.py` 的 `_generate_identifier` 和 `get_model_paths` 方法中，当 `store_id` 从前端传来为 `None` 时，代码 `scope = store_id if store_id else 'all'` 会因为 `store_id` 是 `None` 而正确地将 `scope` 设为 `'all'`。然而，在 `get_model_paths` 方法中，我错误地使用了 `kwargs.get('store_id', 'all')`，这在 `store_id` 键存在但值为 `None` 时，仍然会返回 `None`，导致了路径拼接错误。

### 解决方案
1.  **文件**: `server/utils/file_save.py`
2.  **位置**: `_generate_identifier` 和 `get_model_paths` 方法中处理 `product` 训练模式的部分。
3.  **操作**: 将逻辑从 `scope = kwargs.get('store_id', 'all')` 修改为更严谨的 `scope = store_id if store_id is not None else 'all'`。
4.  **内容**:
    ```python
    # in _generate_identifier
    scope = store_id if store_id is not None else 'all'

    # in get_model_paths
    store_id = kwargs.get('store_id')
    scope = store_id if store_id is not None else 'all'
    scope_folder = f"{product_id}_{scope}"
    ```
5.  **原因**: 这种写法能正确处理 `store_id` 键不存在、或键存在但值为 `None` 的两种情况，确保在这两种情况下 `scope` 都被正确地设置为 `'all'`，从而生成符合规范的路径。

---
**日期**: 2025-07-18 (最终修复)
**主题**: 修复 `KeyError: 'price'` 和单ID哈希错误

### 问题描述
在完成大规模重构后，实际运行时发现了两个隐藏的bug：
1.  在“按店铺训练”模式下，训练因 `KeyError: 'price'` 而失败。
2.  在“按店铺训练”模式下，当只选择一个“指定药品”时，系统仍然错误地对该药品的ID进行了哈希处理，而不是直接使用ID。

### 根本原因
1.  **`KeyError`**: `server/utils/multi_store_data_utils.py` 中的 `get_store_product_sales_data` 函数包含了一个硬编码的列校验，该校验要求 `price` 列必须存在，但这与当前的数据源不符。
2.  **哈希错误**: `server/utils/file_save.py` 中的 `get_model_paths` 方法在处理 `store` 训练模式时，没有复用 `_generate_identifier` 中已经写好的单ID判断逻辑，导致了逻辑不一致。

### 解决方案
1.  **修复 `KeyError`**:
    *   **文件**: `server/utils/multi_store_data_utils.py`
    *   **位置**: `get_store_product_sales_data` 函数。
    *   **操作**: 从 `required_columns` 列表中移除了 `'price'`，根除了这个硬性依赖。
2.  **修复哈希逻辑**:
    *   **文件**: `server/utils/file_save.py`
    *   **位置**: `_generate_identifier` 和 `get_model_paths` 方法中处理 `store` 训练模式的部分。
    *   **操作**: 统一了逻辑，确保在这两个地方都使用了 `scope = product_ids[0] if len(product_ids) == 1 else self._hash_ids(product_ids)` 的判断，从而在只选择一个药品时直接使用其ID。
3.  **更新测试**:
    *   **文件**: `test/test_file_save_logic.py`
    *   **操作**: 增加了新的测试用例，专门验证“按店铺训练-单个指定药品”场景下的路径生成是否正确。

---
**日期**: 2025-07-18 (最终修复)
**主题**: 修复全局训练范围值不匹配导致的 `ValueError`

### 问题描述
在完成所有重构后，实际运行API并触发“全局训练-所有店铺所有药品”时，程序因 `ValueError: 未知的全局训练范围: all_stores_all_products` 而崩溃。

### 根本原因
前端传递的 `training_scope` 值为 `all_stores_all_products`，而 `server/utils/file_save.py` 中的 `_generate_identifier` 和 `get_model_paths` 方法只处理了 `all` 这个值，未能兼容前端传递的具体字符串，导致逻辑判断失败。

### 解决方案
1.  **文件**: `server/utils/file_save.py`
2.  **位置**: `_generate_identifier` 和 `get_model_paths` 方法中处理 `global` 训练模式的部分。
3.  **操作**: 将逻辑判断从 `if training_scope == 'all':` 修改为 `if training_scope in ['all', 'all_stores_all_products']:`。
4.  **原因**: 使代码能够同时兼容两种表示“所有范围”的字符串，确保了前端请求的正确处理。
5.  **更新测试**:
    *   **文件**: `test/test_file_save_logic.py`
    *   **操作**: 增加了新的测试用例，专门验证 `training_scope` 为 `all_stores_all_products` 时的路径生成是否正确。

---
**日期**: 2025-07-18 (最终优化)
**主题**: 优化全局训练自定义模式下的单ID路径生成

### 问题描述
根据用户反馈，希望在全局训练的“自定义范围”模式下，如果只选择单个店铺和/或单个药品，路径中应直接使用ID而不是哈希值，以增强可读性。

### 解决方案
1.  **文件**: `server/utils/file_save.py`
2.  **位置**: `_generate_identifier` 和 `get_model_paths` 方法中处理 `global` 训练模式 `custom` 范围的部分。
3.  **操作**: 为 `store_ids` 和 `product_ids` 分别增加了单ID判断逻辑。
4.  **内容**:
    ```python
    # in _generate_identifier
    s_id = store_ids[0] if len(store_ids) == 1 else self._hash_ids(store_ids)
    p_id = product_ids[0] if len(product_ids) == 1 else self._hash_ids(product_ids)
    scope_part = f"custom_s_{s_id}_p_{p_id}"

    # in get_model_paths
    store_ids = kwargs.get('store_ids', [])
    product_ids = kwargs.get('product_ids', [])
    s_id = store_ids[0] if len(store_ids) == 1 else self._hash_ids(store_ids)
    p_id = product_ids[0] if len(product_ids) == 1 else self._hash_ids(product_ids)
    scope_parts.extend(['custom', s_id, p_id])
    ```
5.  **原因**: 使 `custom` 模式下的路径生成逻辑与 `selected_stores` 和 `selected_products` 模式保持一致，在只选择一个ID时优先使用ID本身，提高了路径的可读性和一致性。
6.  **更新测试**:
    *   **文件**: `test/test_file_save_logic.py`
    *   **操作**: 增加了新的测试用例，专门验证“全局训练-自定义范围-单ID”场景下的路径生成是否正确。
 2025-07-18 16:45:29 +08:00
xz2000
7a4bfedcaa --- 
**日期**: 2025-07-15 11:43
**主题**: 修复因PyTorch版本不兼容导致的训练失败问题

### 问题描述
在修复了路径和依赖问题后，在某些机器上运行模型训练时，程序因 `TypeError: ReduceLROnPlateau.__init__() got an unexpected keyword argument 'verbose'` 而崩溃。但在本地开发机上运行正常。

### 根本原因
此问题是典型的**环境不一致**导致的兼容性错误。
1.  **PyTorch版本差异**: 本地开发环境安装了较旧版本的PyTorch，其学习率调度器 `ReduceLROnPlateau` 支持 `verbose` 参数（用于在学习率变化时打印日志）。
2.  **新环境**: 在其他计算机或新创建的虚拟环境中，安装了较新版本的PyTorch。在新版本中，`ReduceLROnPlateau` 的 `verbose` 参数已被移除。
3.  **代码问题**: `server/trainers/mlstm_trainer.py` 和 `server/trainers/transformer_trainer.py` 的代码中，在创建 `ReduceLROnPlateau` 实例时硬编码了 `verbose=True` 参数，导致在新版PyTorch环境下调用时出现 `TypeError`。

### 解决方案：移除已弃用的参数
1.  **全面排查**: 检查了项目中所有训练器文件 (`mlstm_trainer.py`, `transformer_trainer.py`, `kan_trainer.py`, `tcn_trainer.py`)。
2.  **精确定位**: 确认只有 `mlstm_trainer.py` 和 `transformer_trainer.py` 使用了 `ReduceLROnPlateau` 并传递了 `verbose` 参数。
3.  **执行修复**:
    *   **文件**: `server/trainers/mlstm_trainer.py` 和 `server/trainers/transformer_trainer.py`
    *   **位置**: `ReduceLROnPlateau` 的初始化调用处。
    *   **操作**: 删除了 `verbose=True` 参数。
        ```diff
        - scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, 'min', ..., verbose=True)
        + scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, 'min', ...)
        ```
    *   **原因**: 移除这个在新版PyTorch中已不存在的参数，可以从根本上解决 `TypeError`，并确保代码在不同版本的PyTorch环境中都能正常运行。此修改不影响学习率调度器的核心功能。
 2025-07-15 11:56:21 +08:00
xz2000
b1b697117b **日期**: 2025-07-14 
**主题**: UI导航栏重构

### 描述
根据用户请求，对左侧功能导航栏进行了调整。

### 主要改动
1.  **删除“数据管理”**:
    *   从 `UI/src/App.vue` 的导航菜单中移除了“数据管理”项。
    *   从 `UI/src/router/index.js` 中删除了对应的 `/data` 路由。
    *   删除了视图文件 `UI/src/views/DataView.vue`。

2.  **提升“店铺管理”**:
    *   将“店铺管理”菜单项在 `UI/src/App.vue` 中的位置提升，以填补原“数据管理”的位置，使其在导航中更加突出。

### 涉及文件
*   `UI/src/App.vue`
*   `UI/src/router/index.js`
*   `UI/src/views/DataView.vue` (已删除)

**按药品模型预测**
---
**日期**: 2025-07-14
**主题**: 修复导航菜单高亮问题

### 描述
修复了首次进入或刷新页面时，左侧导航菜单项与当前路由不匹配导致不高亮的问题。

### 主要改动
*   **文件**: `UI/src/App.vue`
*   **修改**:
    1.  引入 `useRoute` 和 `computed`。
    2.  创建了一个计算属性 `activeMenu`，其值动态地等于当前路由的路径 (`route.path`)。
    3.  将 `el-menu` 组件的 `:default-active` 属性绑定到 `activeMenu`。

### 结果
确保了导航菜单的高亮状态始终与当前页面的URL保持同步。

---
**日期**: 2025-07-15
**主题**: 修复硬编码文件路径问题，提高项目可移植性

### 问题描述
项目在从一台计算机迁移到另一台时，由于数据文件路径被硬编码在代码中，导致程序无法找到数据文件而运行失败。

### 根本原因
多个Python文件（`predictor.py`, `multi_store_data_utils.py`）中直接写入了相对路径 `'data/timeseries_training_data_sample_10s50p.parquet'` 作为默认值。这种方式在不同运行环境下（如从根目录运行 vs 从子目录运行）会产生路径解析错误。

### 解决方案：集中配置，统一管理
1.  **修改 `server/core/config.py` (核心)**:
    *   动态计算并定义了一个全局变量 `PROJECT_ROOT`，它始终指向项目的根目录。
    *   基于 `PROJECT_ROOT`，使用 `os.path.join` 创建了一个跨平台的、绝对的默认数据路径 `DEFAULT_DATA_PATH` 和模型保存路径 `DEFAULT_MODEL_DIR`。
    *   这确保了无论从哪个位置执行代码，路径总能被正确解析。

2.  **修改 `server/utils/multi_store_data_utils.py`**:
    *   从 `server/core/config` 导入 `DEFAULT_DATA_PATH`。
    *   将所有数据加载函数的 `file_path` 参数的默认值从硬编码的字符串改为 `None`。
    *   在函数内部，如果 `file_path` 为 `None`，则自动使用导入的 `DEFAULT_DATA_PATH`。
    *   移除了原有的、复杂的、为了猜测正确路径而编写的冗余代码。

3.  **修改 `server/core/predictor.py`**:
    *   同样从 `server/core/config` 导入 `DEFAULT_DATA_PATH`。
    *   在初始化 `PharmacyPredictor` 时，如果未提供数据路径，则使用导入的 `DEFAULT_DATA_PATH` 作为默认值。

### 最终结果
通过将数据源路径集中到唯一的配置文件中进行管理，彻底解决了因硬编码路径导致的可移植性问题。项目现在可以在任何环境下可靠地运行。

---
### 未来如何修改数据源（例如，连接到服务器数据库）

本次重构为将来更换数据源打下了坚实的基础。操作非常简单：

1.  **定位配置文件**: 打开 `server/core/config.py` 文件。

2.  **修改数据源定义**:
    *   **当前 (文件)**:
        ```python
        DEFAULT_DATA_PATH = os.path.join(PROJECT_ROOT, 'data', 'timeseries_training_data_sample_10s50p.parquet')
        ```
    *   **未来 (数据库示例)**:
        您可以将这行替换为数据库连接字符串，或者添加新的数据库配置变量。例如：
        ```python
        # 注释掉或删除旧的文件路径配置
        # DEFAULT_DATA_PATH = ...

        # 新增数据库连接配置
        DATABASE_URL = "postgresql://user:password@your_server_ip:5432/your_database_name"
        ```

3.  **修改数据加载逻辑**:
    *   **定位数据加载函数**: 打开 `server/utils/multi_store_data_utils.py`。
    *   **修改 `load_multi_store_data` 函数**:
        *   引入数据库连接库（如 `sqlalchemy` 或 `psycopg2`）。
        *   修改函数逻辑，使其使用 `config.py` 中的 `DATABASE_URL` 来连接数据库，并执行SQL查询来获取数据，而不是读取文件。
        *   **示例**:
            ```python
            from sqlalchemy import create_engine
            from core.config import DATABASE_URL # 导入新的数据库配置

            def load_multi_store_data(...):
                # ...
                engine = create_engine(DATABASE_URL)
                query = "SELECT * FROM sales_data" # 根据需要构建查询
                df = pd.read_sql(query, engine)
                # ... 后续处理逻辑保持不变 ...
            ```
 2025-07-15 10:37:33 +08:00
xz2000
484f39e12f 完成模型训练调试，修改模型预测的导航栏 2025-07-14 19:27:06 +08:00
gdtiti
71a6975159 临时版本 2025-07-02 11:05:23 +08:00
gdtiti
02b4e0b894 移动了server里的wwwroot目录 2025-06-18 06:42:04 +08:00
gdtiti
441bbdcc56 v2.1.0: 建立LLM编程文档体系与API规范化 - 重大更新：建立完整的.codelf/文档体系，为LLM编程提供准确的知识库 - 创建详细的API参考文档，防止意外修改破坏API设计 - 规范化25+个API端点，包含6大分类和完整的请求/响应示例 - 新增功能：LLM编程文档体系、API保护文档、开发工具配置 - 问题修复：修复HistoryView.vue前端错误，改善数据访问安全性 - 架构改进：清理项目根目录，统一文档格式和API响应规范 - 技术价值：提升AI辅助开发效率，建立标准化开发流程，改善可维护性 - 此更新为未来的AI编程奠定坚实基础，确保系统架构稳定性 2025-06-18 06:39:41 +08:00