中文 NLP 模型部署实战：FastAPI 接口 + Streamlit 看板

一、为什么要做服务化

训练脚本只能由开发者运行，业务系统无法直接调用。服务化之后，其他系统只需要发送 HTTP 请求，就能获得模型预测结果。

本项目采用 FastAPI 提供接口，Streamlit 提供可视化操作页面。

二、服务架构

Streamlit 看板 :8501
        |
        +--> 投诉分流 API :8000
        +--> 广告检测 API :8006
        +--> 其他模型推理模块

三、FastAPI 接口设计

投诉分流服务提供：

• GET /health：检查服务是否正常；
• POST /predict：单条评论预测；
• POST /predict/batch：批量评论预测。

请求示例：

{
  "text": "快递太慢了，等了一个星期"
}

返回内容包括问题类型、置信度、路由部门和人工复核标记：

{
  "text": "快递太慢了，等了一个星期",
  "problem_type": "物流问题",
  "confidence": 0.95,
  "route_to": "物流履约组",
  "manual_review": false
}

四、接口参数校验

使用 Pydantic 限制文本长度和批量数量，避免空输入、超长输入或异常大批量请求拖垮服务。

class PredictRequest(BaseModel):
    text: str = Field(min_length=1, max_length=5000)

五、模型推理注意事项

服务启动后应尽量复用已加载模型，避免每次请求重新加载权重。预测阶段需要：

model.eval()
with torch.no_grad():
    logits = model(input_ids, attention_mask)

这样可以关闭 Dropout 和梯度计算，降低内存占用和推理开销。

六、低置信度人工复核

AI 系统不应假设模型永远正确。项目设置置信度阈值：

置信度 >= 0.60 -> 自动处理
置信度 < 0.60  -> 进入人工复核

这个设计可以降低边界样本被错误自动分流的风险，也为后续数据回流提供入口。

七、Streamlit 看板功能

看板支持：

• 数据概览；
• 模型选择；
• 单条文本分析；
• CSV / TSV 批量上传；
• 置信度和类别概率展示；
• 低置信度样本标记；
• 结果下载；
• 多模型联合分析。

八、当前架构不足

1. 前端和模型耦合偏重

看板当前会直接加载部分模型，适合 demo，但会导致启动慢、资源占用高、扩缩容困难。生产环境更适合让前端只调用统一模型服务。

2. 技术栈没有完全统一

部分历史基线接口使用 Flask，而主线接口使用 FastAPI。后续应统一服务框架，减少维护成本。

3. 模型文件和配置需要统一管理

训练、量化、API 和看板必须绑定同一个模型版本，避免出现训练产物名称不一致或不同入口加载不同权重的问题。

九、生产化改进方向

• 使用统一模型注册表；
• 增加 Docker Compose 部署；
• 增加请求日志、耗时监控和错误告警；
• 使用队列处理大批量任务；
• 将模型服务与前端彻底解耦；
• 增加鉴权、限流和输入安全检查。

十、总结

FastAPI 解决模型能力如何被其他系统调用的问题，Streamlit 解决业务人员如何使用的问题。真正的 AI 系统需要同时关注模型效果、接口稳定性、用户体验和人工兜底。

---