07 Aug 2026

从评论标注到在线预测：小林的 AI 评论分类项目

这是一篇写给初学者的 AI 业务流程科普。文章不讨论具体系统和基础设施，只用一个完整故事解释：什么是标注、开发、训练、评估、推理和上线。

一、业务问题是什么？

一家电商公司每天都会收到大量用户评论：

“物流很快，产品也很好用。”
“软件更新以后经常崩溃。”
“感觉一般，没有特别满意。”
“客服一直不处理我的退款申请。”

运营人员不可能每天手工阅读几十万条评论。他们希望自动识别：

• 正面评价
• 负面评价
• 中性评价
• 需要优先处理的投诉

算法工程师小林的工作，就是开发一个评论分类模型。以后每收到一条新评论，系统都能自动给出分类结果。

输入：客服一直不处理退款
输出：投诉，置信度 96%

整个项目可以概括为：

收集评论
→ 人工标注
→ 整理数据集
→ 开发和小规模试验
→ 正式训练
→ 评估效果
→ 推理测试
→ 上线为在线服务
→ 收集反馈并继续改进

二、数据标注：先给模型准备“标准答案”

为什么需要标注？

模型一开始不知道什么是正面、负面或投诉。小林必须先给它看大量“题目和标准答案”。

这个给原始数据添加正确答案的过程，就叫数据标注。

标注时要注意什么？

小林需要先和运营人员明确规则。例如：

“商品很好，但客服太差了”算负面还是投诉？
“一般般”算中性还是负面？

如果标注人员理解不一致，模型也会学得混乱。因此，标注之前要先写清楚标签定义，并抽查标注质量。

最直白地说：

标注就是给模型准备带答案的练习题。

三、整理数据集：把练习题分成三份

标注完成后，小林不会把全部数据一股脑交给模型，而是通常分成三份：

可以类比为：

训练集 = 平时练习题
验证集 = 模拟考试
测试集 = 最终考试

小林还要检查：

• 是否有空评论、乱码和重复数据
• 各类评论数量是否严重失衡
• 标签是否存在明显错误
• 用户隐私是否已经去除
• 训练集和测试集是否意外包含相同内容

最直白地说：

数据集不是“文件放在一起”就完成了，还要清洗、检查和合理划分。

四、开发：先把方法和代码调通

小林要开发什么？

小林需要编写一套程序，完成：

读取评论
→ 清理文本
→ 把文字转换成模型能处理的数字
→ 加载基础模型
→ 训练模型
→ 保存结果
→ 评估模型

她通常会使用 Python、PyTorch 和 Transformers 等工具，也可能使用 JupyterLab 查看数据和快速试验。

为什么不能直接正式训练？

正式训练可能运行几小时甚至几天。如果代码在开始几分钟后就因为路径错误而失败，会浪费大量时间。

所以小林会先用 100 条评论做一个小实验，检查：

• 数据能否正常读取
• 标签是否正确
• 模型能否加载
• 代码是否报错
• 训练结果能否保存
• 一条新评论能否得到预测结果

最直白地说：

开发阶段不是为了得到最终模型，而是先证明整套方法能够跑通。

五、选择基础模型：不从零开始学习语言

小林通常不会从零创造一个语言模型，而是选择一个已经具备中文理解能力的基础模型，例如 BERT 类模型。

基础模型已经知道一些通用语言规律：

“非常满意”通常表达积极情绪
“一直崩溃”通常表达消极情绪
“但是”前后可能出现意思转折

但它还不知道这家公司的具体分类规则。因此，小林要使用公司的带标签评论继续训练它。

这个过程叫微调（Fine-tuning）：

已经掌握中文基础知识的模型
        +
公司的带标签评论
        ↓
专门判断公司评论的模型

最直白地说：

基础模型像一个已经学过语文的学生，微调是让它继续学习公司的专门业务规则。

六、训练：让模型反复做题并改正错误

训练过程可以简化为：

模型读取一批评论
→ 尝试预测标签
→ 与正确答案比较
→ 计算错误程度
→ 调整内部参数
→ 继续学习下一批评论

例如：

评论：客服拒绝退款
正确答案：投诉
模型预测：负面

模型发现自己答得不够准确
→ 调整内部参数
→ 下次更可能识别为投诉

为什么训练需要时间和 GPU？

模型内部可能有数百万甚至更多参数。训练需要对大量评论反复计算，并不断调整这些参数。

GPU 擅长同时进行大量数学计算，因此通常比 CPU 更适合训练模型。

小林需要决定哪些配置？

常见配置包括：

• 学习率：每次调整参数的幅度
• Epoch：完整学习全部训练数据的次数
• Batch Size：一次处理多少条评论
• 最大文本长度：过长评论如何处理

最直白地说：

训练就是让模型大量做题，根据错误不断调整自己，最后学会分类规律。

七、评估：模型训练完，不代表模型真的好用

训练结束后，小林必须使用模型没有见过的测试数据进行检查。

最简单的指标：准确率

如果模型判断 100 条评论，答对 90 条：

准确率 = 90%

但只看准确率可能不够。假设 100 条评论中只有 5 条投诉，模型把这 5 条全部漏掉，整体准确率仍然可能很高，但业务价值很差。

因此，小林还会关心：

• 投诉有没有被漏掉
• 正面评论是否经常被误判
• 每个类别分别表现如何
• 模型对新评论是否稳定
• 预测速度是否满足要求

她还会人工阅读错误案例：

评论：产品不错，但是售后非常差。
模型预测：正面

这可能说明模型只注意到了“产品不错”，没有理解后面的转折。

最直白地说：

训练是学习，评估是考试；模型能运行，不等于模型考得好。

八、推理：让训练好的模型回答新问题

推理是使用已经训练好的模型处理新的、没有参与训练的数据。

新评论：这款手机续航很好
        ↓
训练好的评论分类模型
        ↓
正面，置信度 95%

训练和推理的区别：

最直白地说：

训练是让模型学习，推理是让学会后的模型正式答题。

九、上线：把模型变成其他系统能调用的服务

训练完成后，小林得到的是一组模型文件。模型文件本身不能直接接收电商后台的网络请求。

因此，她还需要编写一个推理程序：

接收评论
→ 使用与训练时相同的文本处理方式
→ 调用模型进行推理
→ 返回标签和置信度

对外接口可能是：

POST /predict
Content-Type: application/json

{
  "text": "物流很快，商品也很好用"
}

返回：

{
  "label": "positive",
  "confidence": 0.96
}

上线后，电商后台就可以自动处理新评论：

用户提交评论
→ 电商后台调用模型接口
→ 模型返回分类结果
→ 后台保存结果
→ 高风险投诉转交人工处理

最直白地说：

上线就是把模型包装成一个长期可调用的接口，让模型真正进入业务流程。

十、上线不是结束：还要监控和持续改进

用户的表达方式会变化，新产品也会带来新的问题。例如，以前用户抱怨物流，后来可能开始集中反馈直播、会员或支付问题。

小林需要持续观察：

• 每天处理多少条评论
• 接口响应是否稳定
• 模型是否经常给出低置信度结果
• 哪些评论被运营人员纠正
• 新出现的表达是否经常判断错误

运营人员纠正的错误案例，可以重新加入数据：

线上错误案例
→ 人工重新标注
→ 加入新数据集
→ 再次训练和评估
→ 发布新的模型版本

这就形成了持续改进的闭环。

最直白地说：

模型不是开发一次就永远不变，而是要根据真实业务反馈不断更新。

十一、小林最终交付了什么？

小林最终交付的不只是一个模型文件，而是一套完整成果：

清晰的标签定义
经过检查的评论数据集
数据处理和训练代码
训练后的模型
模型评估报告
处理新评论的推理程序
供业务调用的在线接口
后续监控和改进方案

十二、用一张图回顾完整业务

业务提出问题
“能否自动识别评论情绪和投诉？”
        ↓
收集历史评论
        ↓
人工标注正确类别
        ↓
清洗并划分数据集
        ↓
编写代码和小规模试验
        ↓
使用业务数据微调基础模型
        ↓
使用测试集评估效果
        ↓
对新评论进行推理
        ↓
包装为在线接口
        ↓
业务系统正式调用
        ↓
收集错误案例并继续改进

十三、核心概念速记

数据标注 = 给原始评论添加标准答案
数据集 = 模型学习和考试使用的材料
开发 = 编写、调试和验证处理方法
基础模型 = 已经掌握通用语言知识的模型
微调 = 使用业务数据继续训练基础模型
训练 = 让模型做题、计算错误并调整参数
评估 = 使用未见过的数据检查模型效果
推理 = 使用训练好的模型处理新评论
在线推理服务 = 持续接收评论并返回预测结果的接口
持续改进 = 用真实错误案例重新标注和训练

小林完成的事情，可以用一句话概括：

她把历史评论整理成带标准答案的数据集，用这些数据训练并检查一个评论分类模型，再把模型做成可供电商后台长期调用的在线接口。

LEo at 00:12