企业官网建设流程全解析

当业务侧开始追问“下一个周期的销量为什么预测上涨”时，单纯给一条预测曲线是不够的。时间序列模型通常以滑动窗口作为输入，模型内部又叠加了多层非线性变换，结果就是预测值很容易算出来，但“哪个历史时点对这个预测贡献最大”很难直接回答。Millnew AI 这条技术方案给出了一条完整链路：用 Captum 计算时间步维度的归因值，再把归因结果交给本地 LLM 翻译成自然语言解释。整个流程可以离线运行，比较适合数据敏感、不能把业务数据发送到外部接口的场景。这篇文章会把这条链路拆开，从概念、环境到代码逐个讲清楚，最后给出一份可以直接参考的最小实现。

1. 背景与核心概念

1.1 为什么时间序列模型需要“解释”

时间序列预测模型在企业里并不少见，比如销量预测、库存预测、容量预估、时序异常检测。过去很多团队更关注预测精度，模型只要 MAPE 低、R2 高，就算完成任务。但模型上线之后，业务方、运营人员、管理层都会提出同一个问题：为什么这个值涨了？为什么上周预测没有抓住这个拐点？

这就引出了模型可解释性需求。对结构化数据模型来说，树模型可以直接给出特征重要性，XGBoost、LightGBM 都内置了类似能力。但对 PyTorch 实现的 LSTM、TCN、Transformer 这类深度时序模型，特征重要性不再是一张现成的表格。模型输入是整个滑动窗口，输出是一个未来的值，中间经过了隐藏状态、门控单元、注意力权重等复杂计算，开发者需要借助专门的归因算法来回答“哪个输入维度对输出影响最大”。

从工程角度看，解释性不仅是为了汇报，它还能帮助排查特征失效、数据漂移、预测失效等问题。比如某个重要特征在某段时间内归因值持续异常，往往意味着上游数据质量出了问题。解释能力越强，模型在业务侧的接受度和可维护性也越高。

1.2 Captum 是什么

Captum 是 PyTorch 生态里的模型可解释性库，全称是 “Captum” 这个拉丁词，意思是“理解、抓住”，由 PyTorch 团队维护。它提供了多种归因算法，包括常见的 Integrated Gradients、DeepLIFT、Feature Ablation、Layer GradCAM 等，可以覆盖神经元级别、层级别和输入级别的研究。

对于时间序列任务，最常用的是输入级归因。假设模型的输入形状是(batch, sequence_length, num_features)，Captum 会返回一张同样形状的归因矩阵。每个位置上的数值表示该位置对应的输入特征对最终预测结果的贡献程度。数值越大，说明该位置对预测结果的影响越强；负数则表示该位置在抑制当前预测值。

这里需要区分一个概念：Captum 计算的是“归因”而不是“因果”。归因描述的是输入与输出之间的局部分配关系，它告诉我们“哪个输入变量分配到了多少预测贡献”，不等于“如果把该输入改成某个值，预测结果就会朝某个方向变化”。使用时要注意这个边界，尤其是面向业务方输出结论时，表述要更谨慎。

1.3 本地 LLM 在链路中的角色

Captum 输出的归因矩阵是一堆浮点数。开发者能看懂t-5 时间步贡献度 0.32这样的结构，但业务方不一定能快速理解。此时自然语言生成就派上了用场。如果我们把预测值、历史窗口、归因结果组装成一段结构化的提示词，交给 LLM 去生成一段更友好的描述，比如“过去 3 个时间步中，第 2 天对预测上涨贡献最大，模型可能主要受近端趋势驱动”，整个解释链路才算真正闭环。

为什么要强调“本地 LLM”？主要基于三点考虑。第一是数据隐私，时间序列数据往往来自真实业务，直接调用外部大模型 API 需要把窗口数据发给第三方，这在很多行业是不允许的。第二是稳定性，外部 API 有网络延迟、限流、版本波动等问题，本地推理可以避免这些不可控因素。第三是成本，对于高频的解释请求，本地部署的量化小模型在 GPU 或不错的内存机器上已经能覆盖大部分场景。

1.4 Millnew AI 方案整体思路

Millnew AI 主要解决的是一个组合问题：如何把 Captum 的数值归因结果转换成业务可读的解释文本。它把系统拆成了四个阶段：数据准备、模型预测、归因计算、LLM 解释。每个阶段都有清晰的输入输出，这也方便我们在自己的项目里复用。接下来的章节会按照这个流程逐步搭建一个最小可运行示例。

2. 整体链路与技术选型

2.1 系统架构示意

为便于理解，先用一张 ASCII 图描述整体链路：

[历史滑动窗口] --> [LSTM预测模型] --> [预测值] | v [Captum Integrated Gradients] | v [特征归因向量] | v [提示词模板] | v [本地LLM（Ollama）] | v [自然语言解释文本]

从这条链路来看，Captum 和 LLM 之间其实并不直接交互。Captum 负责把“黑盒模型”的输入输出关系转化成归因矩阵，本地 LLM 负责把矩阵翻译成人类语言。两个模块耦合度很低，因此我们可以单独替换其中的任意部分。比如把 LSTM 换成 Transformer，或者把 Qwen 换成 Llama，都不会影响整体设计。

2.2 归因方法选型

Captum 内置了很多归因算法。项目落地时最常用的有几种：

• Integrated Gradients（积分梯度）：沿着输入从基线到实际样本的直线路径累积梯度，满足敏感性和实现不变性。它对大多数连续输入模型都适用，也是本文示例首选。
• DeepLIFT：通过反向传播计算每个神经元对输出的贡献，它对梯度饱和问题有一定改善，但实现上比 Integrated Gradients 复杂一些。
• Feature Ablation：通过逐个屏蔽输入特征观察预测变化，原理直观，但计算量较大，对长序列不友好。
• Layer Integrated Gradients：适合观察中间层特征重要性，适合做深层次模型诊断。

对于时间序列输入，Integrated Gradients 是比较稳妥的起点，参数只有一个基线（baseline），调起来容易，结果解释也直接。

2.3 本地 LLM 选型

本地 LLM 的落地方式有很多，这里选择 Ollama。Ollama 是一个本地模型运行工具，它屏蔽了模型权重下载、量化格式转换、推理服务启动等复杂步骤，一条命令就能拉起一个与 OpenAI 接口兼容的本地推理服务。整体上比较适合快速验证。

模型方面，常见的选择是 Qwen2.5 系列、Llama 3.2 系列、Mistral 系列。以 7B 到 14B 参数量的量化版本为例，在消费级 GPU 或 32GB 内存的机器上基本可以运行。如果机器资源有限，也可以选择 3B 左右的小模型，解释质量会略逊色，但速度更快。具体显存要求取决于上下文长度和量化方式，需要读者根据实际环境调整。

2.4 为什么把“解释生成”放在最后一步

这里包含一个容易忽略的设计原则：LLM 不应该直接读取原始时间序列去推测哪些时间点重要。让 LLM 直接看原始序列，它虽然也能给出一些文字描述，但那是它自己“猜”出来的规律，而不是基于模型捕获的归因信息，甚至可能产生严重幻觉。正确的做法是先用归因算法把“模型真正依赖的信息”提取出来，再让 LLM 基于这些结构化数值做语言组织。这样生成的解释可信度更高，也可以追溯到具体数值。

3. 环境准备与版本说明

3.1 运行环境

本文示例以 Linux 或 macOS 环境为主要演示对象，Windows 也可以运行，但 Ollama 服务安装方式需要参考官方文档。软件版本方面，不同项目可能差异较大，下面给出的是常见可运行组合，具体版本请结合自己的环境确定：

• Python 3.10 及以上
• PyTorch 2.x
• Captum 0.6 及以上
• NumPy 1.24 及以上
• Ollama 0.3 及以上，建议使用最新稳定版
• 本地模型：Qwen2.5:7b 或同等规模量化模型

这里不把版本号固化，是因为 PyTorch 和 Captum 的接口迭代较快，本文的重点是配置思路与代码结构。

3.2 安装 Python 依赖

建议先创建一个虚拟环境，避免依赖冲突。

python -m venv venv source venv/bin/activate

然后安装依赖，可以直接使用 requirements.txt：

torch captum numpy requests matplotlib

安装命令：

pip install -r requirements.txt

Captum 会依赖 PyTorch，如果你需要指定 PyTorch 的版本或 CUDA 版本，建议先单独安装 PyTorch，再安装 Captum。

3.3 安装并启动 Ollama

Ollama 的安装方式很直接，可以到模型工具的官方仓库获取对应安装脚本。安装完成之后，先拉取一个模型：

ollama pull qwen2.5:7b

模型体积接近 5GB，需要确保磁盘空间充足。拉取完成后，启动本地服务：

ollama serve

默认情况下，Ollama 会监听http://localhost:11434，后续代码中可以直接请求该地址。注意不要把这个端口直接暴露到公网，本地 LLM 服务通常不需要外部访问权限。

3.4 示例项目结构

为方便阅读，项目代码按功能拆分如下：

millnew-ai-demo/ ├── venv/ ├── requirements.txt ├── train_timeseries.py ├── explain_captum.py ├── generate_explanation.py └── main.py

其中train_timeseries.py负责训练一个简单的 LSTM 模型，explain_captum.py负责计算归因，generate_explanation.py负责调用本地 LLM，main.py把整条链路串起来。

4. 构建一个 LSTM 时间序列预测模型

在解释模型之前，需要先有一个模型。为了演示方便，这里构造一组带趋势、周期和噪声的模拟序列数据，并使用 PyTorch 训练一个基于 LSTM 的单步预测模型。

4.1 生成模拟时间序列

下面的函数会生成一段长度为 2000 的模拟序列，包含线性趋势、24 小时周期项和高斯噪声：

import numpy as np def make_synthetic_series(n=2000): t = np.arange(n) trend = 0.02 * t season = 5 * np.sin(2 * np.pi * t / 24) noise = np.random.normal(0, 1.0, n) return trend + season + noise

这里引入周期为 24 的组件，是为了模拟“小时级”或者“日级”数据里常见的昼夜节律。趋势项则让序列整体向上移动，配合噪声项后会更接近真实业务数据的一点特征。

4.2 构造滑动窗口数据集

时间序列预测通常把过去一段窗口作为模型输入，把下一时刻作为预测目标。下面的函数实现了这个转换：

def build_windows(series, window_size=24, horizon=1): X, y = [], [] for i in range(len(series) - window_size - horizon + 1): X.append(series[i:i + window_size]) y.append(series[i + window_size:i + window_size + horizon]) return np.array(X), np.array(y)

假设window_size=24，那么每个样本就是连续 24 个历史值，预测目标是第 25 个值。由于这里每个时间点只有一维特征，最终张量形状是(样本数, 24, 1)。

4.3 定义 LSTM 模型

模型的实现很简洁，核心是用一层 LSTM 读取序列，取最后一个时间步的隐藏状态，再通过全连接层输出预测值：

import torch import torch.nn as nn class LSTMPredictor(nn.Module): def __init__(self, input_size=1, hidden_size=32, num_layers=2, output_size=1): super().__init__() self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, batch_first=True ) self.fc = nn.Linear(hidden_size, output_size) def forward(self, x): out, _ = self.lstm(x) out = self.fc(out[:, -1, :]) return out

这里的batch_first=True是为了让输入形状符合(batch, seq_len, features)，这也是 Captum 后续归因时比较容易处理的格式。

4.4 训练模型

训练脚本train_timeseries.py的完整示例如下：

import numpy as np import torch import torch.nn as nn from torch.utils.data import DataLoader, TensorDataset # 生成数据 series = make_synthetic_series(2000) X, y = build_windows(series, window_size=24, horizon=1) X = X.reshape(-1, 24, 1) y = y.reshape(-1, 1) # 划分训练集和验证集 split = int(len(X) * 0.8) X_train, X_val = X[:split], X[split:] y_train, y_val = y[:split], y[split:] train_dataset = TensorDataset( torch.tensor(X_train, dtype=torch.float32), torch.tensor(y_train, dtype=torch.float32) ) val_dataset = TensorDataset( torch.tensor(X_val, dtype=torch.float32), torch.tensor(y_val, dtype=torch.float32) ) train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True) val_loader = DataLoader(val_dataset, batch_size=128, shuffle=False) # 初始化模型 model = LSTMPredictor() optimizer = torch.optim.Adam(model.parameters(), lr=0.001) criterion = nn.MSELoss() # 训练循环 epochs = 30 for epoch in range(epochs): model.train() train_loss = 0.0 for xb, yb in train_loader: optimizer.zero_grad() pred = model(xb) loss = criterion(pred, yb) loss.backward() optimizer.step() train_loss += loss.item() * xb.size(0) model.eval() val_loss = 0.0 with torch.no_grad(): for xb, yb in val_loader: pred = model(xb) loss = criterion(pred, yb) val_loss += loss.item() * xb.size(0) train_loss /= len(train_dataset) val_loss /= len(val_dataset) print(f"epoch={epoch + 1} train_loss={train_loss:.6f} val_loss={val_loss:.6f}") # 保存模型权重 torch.save(model.state_dict(), "lstm_ts.pt")

这段代码虽然只是示例，但它完整覆盖了“构造样本、定义模型、训练验证、保存权重”的流程。读者可以把里面的数据生成替换成自己的真实业务数据，比如数据库里取出的销量表、日志里的时序指标等。

4.5 训练结果预期

在模拟数据上，损失通常会快速下降。前几个 epoch 训练损失可能在0.05附近波动，随着训练推进，验证集损失会下降到0.01到0.03之间。由于噪声项的存在，损失不会趋近于 0，这是正常现象。

5. 使用 Captum 计算特征归因

模型训练完成后，我们需要回答“模型为什么预测出这个值”。这一步通过 Captum 完成。

5.1 加载训练好的模型

新建explain_captum.py，首先加载模型权重：

import torch import numpy as np model = LSTMPredictor() model.load_state_dict(torch.load("lstm_ts.pt", map_location="cpu")) model.eval()

这里需要保证模型结构和保存时完全一致，否则加载权重会报错。

5.2 构造解释样本

从验证集或者最新一段真实数据中抽取一个窗口作为待解释样本：

import torch # 使用验证集第一个样本 window = torch.tensor(X_val[:1], dtype=torch.float32) # shape: (1, 24, 1)

这里选择X_val[:1]表示一个形状为(1, 24, 1)的张量，即 1 个样本、24 个时间步、1 个特征。Captum 在计算归因时需要传入一个 batch 维度，即使只解释一个样本也不能省略这一维。

5.3 Integrated Gradients 归因

Integrated Gradients 需要一个基线（baseline）。基线代表“无信息输入”，对时间序列来说一般使用全 0 序列。代码如下：

from captum.attr import IntegratedGradients # 构造基线：全 0 窗口 baseline = torch.zeros_like(window) ig = IntegratedGradients(model) attributions = ig.attribute( window, baselines=baseline, target=0, n_steps=50 ) print("attributions shape:", attributions.shape) print(attributions)

这里的target=0指模型输出第 0 维，也就是我们需要解释的预测值。n_steps=50表示积分路径上的采样步数，值越大结果越稳定，但计算时间也会增加。

5.4 把归因结果转成每个时间步的重要性

Captum 返回的归因矩阵形状与输入一致，即(1, 24, 1)。由于当前示例每个时间步只有一个特征，可以先把绝对值按时间步取出来，再归一化成权重：

attrs = attributions.squeeze().detach().numpy() step_scores = np.abs(attrs) # 简单归一化到 0~1，便于后续拼接到提示词 step_scores = step_scores / (step_scores.sum() + 1e-8) for i, score in enumerate(step_scores): print(f"t-{len(step_scores) - i}: {score:.4f}")

如果输入包含多个特征，通常的做法是先对特征维度做聚合，比如取绝对值后按时间步求和，得到每个时间步的总贡献度；如果想单独看某个特征的重要性，则需要保留特征维度，分别生成不同特征的解释。

5.5 如何理解归因结果

归因值并不等同于“真实的因果贡献”。它只是描述了模型决策路径中每个输入位置的相对重要性。比如某个时间步归因值达到0.35，说明该输入对当前预测结果贡献较大。如果归因值接近 0，则说明模型在预测时基本没有参考该位置。

实际项目中，归因结果经常出现“局部波动大”的情况，尤其当输入窗口较长时。此时可以在归因前对数据做标准化，或者多次抽样基线取平均，以降低噪声。

6. 用本地 LLM 生成自然语言解释

模型归因矩阵已经算出来了，但业务方不会直接看这些浮点数。接下来需要把数值整理成文字。

6.1 提示词设计的基本原则

想让本地 LLM 给出高质量解释，提示词至少要包含四类信息：

• 模型的基本任务描述，例如“这是一个基于滑动窗口的销量预测模型”。
• 当前窗口的预测值。
• 每个时间步的归因结果，最好格式清晰。
• 输出要求，例如用中文、不超过 150 字、不要编造数据等。

其中“输出要求”非常关键。如果我们不做任何约束，LLM 很有可能会自由发挥，编造出归因结果里不存在的结论。比较稳妥的做法是明确要求它“只能基于给出的数据描述，不要推断未提供信息”。

6.2 结构化提示词模板

下面是一个可复用的提示词模板：

def build_prompt(pred_value, history_values, step_scores): history_text = ", ".join([f"{v:.2f}" for v in history_values]) score_text = ", ".join([ f"t-{len(step_scores) - i}(贡献度 {score:.4f})" for i, score in enumerate(step_scores) ]) prompt = f""" 你是一个时间序列预测解释助手。 模型输入是一个长度为 {len(step_scores)} 的滑动窗口，窗口内数值按时间先后排列。 模型对下一个时间点的预测值为：{pred_value:.4f} 当前窗口最后 5 个历史值为：[{history_text}] 基于 Integrated Gradients 方法，每个时间步对预测值的归因贡献为： {score_text} 请用中文生成一段简洁解释，要求： 1. 说明哪些时间步对预测结果贡献最大； 2. 说明整体趋势是推动预测值上升还是下降； 3. 不要添加归因列表中不存在的信息； 4. 总字数控制在 150 字以内。 """ return prompt

这里让 LLM 关注“哪些时间步贡献最大”和“整体方向是上涨还是下跌”。如果需要更细致的分析，还可以把特征名传入模板，让 LLM 按特征维度解释。

6.3 调用 Ollama

Ollama 提供 HTTP 接口，可以直接用requests调用。代码如下：

import requests def explain_with_ollama(prompt, model_name="qwen2.5:7b"): resp = requests.post( "http://localhost:11434/api/chat", json={ "model": model_name, "messages": [{"role": "user", "content": prompt}], "stream": False, "options": { "temperature": 0.2, "num_predict": 256 } }, timeout=120 ) resp.raise_for_status() return resp.json()["message"]["content"]

temperature=0.2是为了让输出更稳定，避免同一份归因结果每次生成不同解释。num_predict=256限制了最大输出长度。如果机器性能较弱，可以把超时时间调大。

6.4 输出示例

在模拟数据上，解释结果大致会像下面这样：

在最近 24 个时间步中，t-1、t-2 和 t-3 对预测上涨贡献较大，其中 t-1 贡献度最高，说明模型对该预测主要依赖于最近三个时间步的短期变化。整体归因方向为正，模型认为短期趋势将继续推动预测值上升。

这段文本才是最终可以展示给业务方的结果。它保留了归因结果的核心信息，同时避免了密密麻麻的数字表格。

7. 完整串联示例与效果演示

7.1 串联脚本 main.py

为了演示完整的流程，这里把前三节的内容整合到main.py中。实际项目中建议保持模块拆分，这里只是展示链路：

# main.py 核心片段 import torch import numpy as np # 1. 准备数据 series = make_synthetic_series(2000) X, y = build_windows(series, window_size=24, horizon=1) X = X.reshape(-1, 24, 1) y = y.reshape(-1, 1) split = int(len(X) * 0.8) X_val, y_val = X[split:], y[split:] # 2. 加载模型 model = LSTMPredictor() model.load_state_dict(torch.load("lstm_ts.pt", map_location="cpu")) model.eval() # 3. 选择要解释的样本 sample_idx = 0 window = torch.tensor(X_val[sample_idx:sample_idx + 1], dtype=torch.float32) with torch.no_grad(): pred_value = model(window).item() # 4. Captum 归因 from captum.attr import IntegratedGradients baseline = torch.zeros_like(window) ig = IntegratedGradients(model) attributions = ig.attribute(window, baselines=baseline, target=0, n_steps=50) attrs = attributions.squeeze().detach().numpy() step_scores = np.abs(attrs) step_scores = step_scores / (step_scores.sum() + 1e-8) # 5. 生成自然语言解释 history_values = window.squeeze().numpy()[-5:] prompt = build_prompt(pred_value, history_values, step_scores) explanation = explain_with_ollama(prompt) print("预测值:", round(pred_value, 4)) print("解释文本:", explanation)

运行命令：

python main.py

7.2 预期输出结构

脚本会先打印模型预测值，再打印 LLM 生成的解释文本。因为模型和数据都带随机性，数值每次运行会有一点差异，但解释文本的结构应该保持稳定：先指出贡献最大的时间步，再描述整体趋势方向，最后落到预测变化的总结上。

7.3 如何验证解释效果

解释效果不能只看文字是否通顺。一个常用的验证方法是“删掉归因值最高的几个时间步，重新预测”，观察预测值是否发生明显变化。如果发生明显变化，说明归因结果和模型行为一致；如果几乎不变，说明归因结果可能与模型真实决策路径不一致。这种验证方法虽然朴素，但在项目中非常实用。

8. 常见问题与排查思路

在实践这条链路时，比较常见的坑集中在维度、环境、模型调用几个方向。下表整理了典型问题：

8.1 维度问题排查

如果attributions.shape不是(1, 24, 1)，首先要检查模型的输入张量是否保留了 batch 维度。Captum 的attribute方法要求输入是一个可调用的模型输入张量，缺少 batch 维会导致归因维度错乱。

8.2 Ollama 服务排查

调用失败时，先做两步检查：

curl http://localhost:11434/api/tags

如果能返回模型列表，说明服务正常；如果连接失败，查看 Ollama 日志确认是否已启动。生产环境中不建议把 Ollama 监听地址设为0.0.0.0，避免未授权访问。

8.3 归因质量排查

如果归因结果“看起来非常随机”，先确认数据是否做了归一化。LSTM 对输入尺度比较敏感，如果原始数值差异过大，梯度路径会被少数大数值时间步主导。通常建议在训练和解释时使用同一套归一化参数。

9. 最佳实践与工程建议

9.1 数据归一化要贯穿训练与解释

在训练之前对序列做标准化，能够显著提升 LSTM 的稳定性。需要特别注意，解释阶段使用的归一化参数必须与训练阶段一致，否则归因结果会失真。比较好的做法是把归一化器持久化保存，例如使用 joblib 保存scaler，在预测服务和解释服务中复用。

9.2 归因结果要多次计算取平均

Integrated Gradients 的n_steps越大，结果越稳定。除了调大n_steps，还可以对同一个样本设置多个不同的随机基线，计算多次归因后取均值。Captum 的NoiseTunnel提供了类似功能，可以直接实现平滑归因。这个方法适合对稳定性要求较高的生产场景。

9.3 提示词模板要纳入版本管理

在工程实践中，提示词并不是一次性写死的。LLM 输出质量会随模型版本、任务场景变化，因此建议把提示词模板单独放在一个模块或配置文件中管理。后续如果需要切换模型、调整语言风格，不必改动业务代码。

9.4 输出内容需要加安全边界

LLM 生成解释时，仍有可能产生少量幻觉，例如描述“第三天的数据异常”，但归因结果里并没有这个信息。除了在提示词里约束之外，还可以在输出后做一个简单校验：如果解释中出现了归因列表里不存在的时间步描述，可以降级处理或提示“自动解释生成失败，请查看归因图表”。

9.5 生产环境应关注数据合规

本地 LLM 的最大优势是数据不出内网，但这不代表可以放松合规要求。如果系统服务于金融、医疗等敏感行业，建议保留解释生成日志，并建立人工复核机制。另外，模型解释只能作为辅助决策参考，不应直接替代业务判断。

9.6 模型迭代后要回归验证解释链路

当 LSTM 模型重新训练后，归因分布可能发生明显变化。建议在模型评估阶段加入“解释一致性检查”，即比较新旧模型在相同样本上的归因排位变化。如果变化过大，说明模型决策逻辑发生了实质改变，需要通知业务方，而不是默默上线新版本。

10. 总结与进一步探索

本文围绕 Millnew AI 的技术思路，从零搭建了一条“LSTM + Captum + 本地 LLM”的时间序列模型解释链路。核心要点可以归纳为：先用 PyTorch 训练一个时间序列预测模型，然后用 Captum 的 Integrated Gradients 计算输入窗口的归因值，最后把归因值、历史窗口和预测结果组装成提示词，交给 Ollama 托管的本地 LLM 生成自然语言解释。整条链路可以完全在本地环境运行，适合数据敏感型业务。

如果要在真实项目中继续深入，有几个方向值得尝试。一是把示例中的 LSTM 换成更强的时序模型，比如 TCN、Transformer 或 PatchTST，检查 Captum 是否仍然能保持稳定的归因效果。二是把解释结果接入监控看板，让运维和业务人员每天查看模型预测依据。三是把这条服务封装成 FastAPI 接口，提供给上游系统调用。

对于刚开始接触模型可解释性的读者，建议先不要贪多。可以从最简单的单特征序列数据开始，跑通本文的最小示例，再逐步引入多特征、多步预测、注意力权重对比等复杂内容。当你亲手在 Captum 输出中看到某个时间步归因值突然抬高时，对模型行为的理解会比只看指标深刻得多。如果这篇文章对你有帮助，可以收藏备用，后续实践中有新的问题也欢迎继续交流。