1.2 核心应用场景

1.2 核心应用场景

本节摘要：SOURCE 1.2 强调文本分类与情感分析的价值在于从海量非结构化文本中提取可行动的结构化信息。本节按行业场景梳理典型输入输出与成功指标，帮助你在立项时选对任务粒度。

本节目标

1. 列举五类以上核心应用场景及对应标签设计
2. 为垃圾邮件与疾病筛查类任务选择更合适的优化指标
3. 说明意图识别在对话系统中的位置

一、文本分类典型场景

SOURCE 1.2：垃圾过滤历史上是文本分类的「杀手级应用」——标签体系简单，但误杀重要邮件的业务代价极高，因此产品侧往往宁可漏杀也不误杀。

二、情感分析典型场景

# 概念：方面级情感结构
aspect_sentiments = [
    {"aspect": "电池续航", "sentiment": "negative"},
    {"aspect": "屏幕", "sentiment": "positive"},
]
​

应用场景分布

三、跨场景架构共性

无论场景如何变化，生产系统通常包含：

1. 采集层 — API、爬虫、日志管道（合规先行）
2. 预处理层 — 去 HTML、统一编码、中文分词
3. 模型层 — 在线/离线推理
4. 反馈层 — 人工纠错 → 再训练

⚠️ 常见坑：舆情项目只做「正负面比例」.dashboard，却不链到工单分级——模型输出无法驱动行动。

💡 关键直觉：场景决定标签体系；标签体系决定该用多类还是 ABSA。

一节小结

• 分类场景：过滤、归档、路由、审核、意图识别
• 情感场景：评论、舆情、客服、调研——粒度从文档到方面
• 指标与业务对齐：垃圾邮件重 Precision，风控筛查重 Recall
• 生产架构需闭环：预测 → 人工反馈 → 迭代

下一节讨论讽刺、多语言与预训练趋势等现实挑战。

深化：从场景指标反推任务设计

场景章节的表格给了输入、输出标签与业务 KPI，这里把「如何从 KPI 反推设计」补完整。以客服工单自动分派为例：工单进来先做意图识别（投诉、退换、咨询、表扬），再用情感分析做紧急度排序。如果 KPI 是「投诉类工单 30 秒内被人工接手」，那么召回率就比精确率重要——宁可把咨询误判成投诉多分派几个坐席，也不能让真投诉沉在队列里。反过来，垃圾邮件场景误杀一封重要邮件可能直接丢失客户，所以宁可让一些垃圾进收件箱，也要保住精确率。这就是「指标即产品语言」的落地含义。

舆情监控场景容易犯的错是只统计「正负面占比」，却不断言该做什么。健康的设计是给每条舆情附上「涉事主体 + 事件类型 + 情感极性 + 建议动作」，例如「物流主体 + 延误事件 + 负面 + 升级客诉」，这样运营能按主体和事件聚合成行动清单。可以把这个结构看作 ABSA 在生产侧的简化版。

内容审核场景则要区分机器初审与人工复审：模型给置信度阈值，低置信度样本进复审队列，高置信度直接通过或拦截。这里常用「精确率优先」策略，宁可复审量大，也不能把违规内容放出。

# 概念：舆情行动清单结构（示例）
alert = {
    "subject": "物流",        # 涉事主体
    "event": "延误",          # 事件类型
    "sentiment": "negative",  # 情感极性
    "action": "upgrade",      # 建议动作
}
​

落地检查：场景自检问题清单

立项前用下面的问题清单自检一遍，能提前发现「看似能做的场景」里的坑。

以情感分析驱动产品改进为例：若只有打分，没有「哪个方面差」的结构，就无法给出可执行的改进项，那么仅做整体正负分类的价值就有限。这也是「场景决定标签体系」的实操含义。