企业官网建设流程全解析

简介：面向具备一定Python基础的开发者与算法工程师，这份细粒度用户评论情感分析资源包完整覆盖了从数据清洗、分词、情感词典构建，到TF-IDF/N-gram特征提取，再到BiGRU、RCNN、Capsule等深度学习模型训练与评估的整个实验流程。包中提供了多组可直接运行的Python训练、验证、预测脚本、Jupyter预处理笔记、字符向量文件以及对应训练/验证/测试数据集的说明文档，可以帮助使用者快速复现AI Challenger情感分析竞赛方案，理解词向量与注意力层设计、超参数调节和准确率/召回率/F1等评估指标的实际应用。资源共25个文件，包含多个Python脚本、文本说明、Word标注文档等，压缩包仅3.16MB，便于下载与在线学习。目前已有355人学习，尤其适合用于课程设计、毕业课题，也适合想要系统入门深度情感分析的研究者。

1. 细粒度用户评论情感分析：先分清“好评差评”和“哪里有意见”差在哪

拿一万条餐饮评论直接跑二分类，准确率能到九成，可运营看完只说一句“这报告没用”。原因很简单——“口味很好，但上菜太慢”这种评论，模型按句子整体打了正向，差评信息全被淹没了。用户真正表达的是两件事：对口味满意，对上菜速度不满。二分类把这两件事硬压成一个标签，细粒度用户评论情感分析要解决的，正是这个“压扁”的问题：不再只判断评论是正面还是负面，而是定位到“评价对象是谁、情感倾向是什么”，把每条评论拆成若干条可执行的结论。做舆情、做电商评论分析、做本地生活平台运营的人，最终需要的都是这种颗粒度。这篇笔记就按我实际做过的方案，从建模目标、数据设计、规则基线到深度学习模型，把整条链路走一遍，顺便把最容易翻车的地方都交代清楚。

2. 为什么二分类不够用：属性级情感分析的建模目标与数据设计

2.1 从句子级标签到“评价对象-情感对”：细粒度分析到底在预测什么

细粒度情感分析在学术和工程里最常见的叫法是属性级情感分析（Aspect-Based Sentiment Analysis，简称 ABSA）。它预测的不是“整句话正负”，而是“这句话里提到哪些方面，每个方面分别是什么情感”。比如“口味很好，但上菜太慢”，标准输出是两条记录：口味→正向，上菜速度→负向。这就是“评价对象-情感对”的二元组，再严格一点还可以加上情感强度，变成方面、极性、强度三元组。

粗粒度和细粒度的本质差别在于任务定义。粗粒度模型面对一句话只输出一个标签，遇到句子内部极性冲突时只能取一个折中结果；细粒度模型把一句话拆成多个预测单元，每个单元对应一个方面类别。我做过一个对比，粗粒度在“整体准确率”上可以做到 90% 以上，但如果按“情感被完全猜对”来算，同批数据实际只有六成多。这个差距就是业务认为“报告没用”的来源。

细粒度分析的建模目标，本质上是一个结构化预测问题：同时输出方面集合和每个方面的情感极性。工程实现上通常拆成两段：第一段做方面抽取（Aspect Term Extraction），找出“口味”、“上菜速度”这类目标词；第二段对每个方面做情感分类（Aspect Sentiment Classification）。两段可以联合训练，也可以先分别做再拼接。联合的效果通常更好，但工程复杂度高。我一般建议第一版分两段实现，先能跑通，再考虑合并成一个端到端模型。

下面这张表是几个关键维度的对比，能直观看清细粒度和粗粒度的差异：

2.2 细粒度标注体系设计：方面类别、情感极性、强度与真实业务映射

细粒度任务的第一道坎不是模型，而是标注体系怎么定。方面类别没有统一标准，必须从业务目标反推。做过餐饮评论项目，第一版我直接把方面定为“口味、服务、环境、价格、分量、速度”六类，运营看了之后说缺一个“卫生”，补上之后又说“价格”和“性价比”应该分开。后来我养成了一个习惯：先让运营和客服各看 500 条真实评论，把高频出现的话题全部列出来，再合并归纳成统一的方面清单。不要凭直觉定类目，真实评论里的说法远比想象中分散。

方面类别定好后，还要确定情感极性的档位。我强烈建议默认用三级：正向、中性、负向。五级标注看起来更精细，但不同标注员对“一般”和“较差”的边界理解差异很大，一致性很难达标。三级极性配合强度副词（“非常”“有点”“稍微”）其实已经够业务使用，而且后面可以用规则或模型对强度做二次修正。

标注规范里最容易漏的一条是“无评价对象”怎么处理。比如“太失望了”这句话没提任何方面，学术上通常标为 O（其他），工程上我会要求标注员把这类标为“整体”或直接跳过，避免模型学到“无中生有”。另一点是双属性同时出现的情况，比如“性价比高”既涉及价格又涉及质量，规范里要提前约定归到哪一类，我一般约定按用户最直接的语义落，这里落到“价格”。

实操层面不需要上复杂标注平台。用一张 CSV，每行一个句子，列分别填句子编号、句子文本、方面类别、情感极性、标注人。双人背靠背标注同一批数据，抽检 10% 计算一致性（Cohen‘s Kappa），Kappa 低于 0.7 就说明标注规范还有歧义，需要重新讨论再标。这一套流程虽然原始，但比直接上个昂贵标注系统靠谱得多。

2.3 数据怎么来：公开数据集与人工标注的取舍

中文评论数据有两个常见来源：公开数据集和业务自有数据。公开数据集的优势是量大、有标签，但大多数是句子级标注，真正带方面级标签的中文公开数据很少。即便拿到标注数据，领域差异也是大问题：用酒店评论训练的模型去跑外卖评论，表现会明显下降，因为评价对象和情感表达习惯都不同。我测过一个公开数据集上效果不错的模型，直接迁移到电商评论，F1 掉了一截，原因就是“客服态度”这类电商高频方面在原有标注里占比太低。

如果业务方有历史评论数据但没有标注，我的建议是放弃“一次性标很多”的思路，改用冷启动方案：先用规则基线（下章会详细展开）跑一个初版结果，让人工只修正错得明显的部分，逐步积累标注样本。按一条评论平均包含 1.5 个方面来算，积累 3000 条评论就有 4000 多个标注样本，足够让一个深度学习模型跑出不错的效果。

数据采集还有一个现实问题：评论数据从哪来。合规的做法是通过平台官方接口或业务方授权获取，爬虫抓公开评论也要遵守平台条款和法律法规，只用于个人学习和研究。爬虫能抓到评论不等于可以拿来商用，这一步很多人栽跟头，后面细节不展开，但务必自己把关。

3. 用 Python 搭一个能跑的细粒度情感分析最小系统：数据清洗、规则基线到模型训练

3.1 系统总体结构：数据层、分析层、展示层怎么拆

一个能长期维护的细粒度评论分析系统，我习惯拆成三层，各层之间只通过接口通信。数据层负责评论采集、清洗、存储；分析层负责方面抽取、情感分类和结果汇总；展示层负责统计图表和报表导出。这样拆最大的好处是分析层的模型可以被独立替换——今天跑规则，明天换深度学习模型，对上下两层透明。

我搭建第一版时的目录结构大概长这样，供你参考：

review_sentiment/ ├── data/ # 原始数据和标注数据 ├── features/ # 处理后的中间结果 ├── models/ # 训练好的模型权重和配置 ├── src/ │ ├── preprocess.py # 数据清洗、分词、自定义词典 │ ├── rule_base.py # 规则基线模型 │ ├── dataset.py # 深度学习数据封装 │ ├── train.py # 模型训练入口 │ └── predict.py # 推理与结果输出 └── output/ # 报表和图表

这个分层结构不复杂，但能保证每个环节都能单独验证。新手最容易犯的错是把所有逻辑写在一个大脚本里，出了问题很难定位。

3.2 数据预处理与中文分词：jieba 的常用参数与停用词选择

中文评论分析绕不开分词。细粒度任务里，分词质量直接影响接下来的方面匹配和情感打分。“服务员态度差”如果被切成“服务/员/态度/差”，方面词“服务”还在，但“服务员”这个整体语义就丢了。我的处理习惯是在 jieba 分词基础上叠加自定义词典，把业务方高频提到的菜品名、品牌名、服务专有名词都加进去，让这些词不被内部切碎。

先写一段清洗和分词的代码：

import re import jieba jieba.load_userdict("custom_dict.txt") def clean_text(text: str) -> str: # 去掉URL、@用户等噪声，保留中文和基本标点 text = re.sub(r"http\S+", "", text) text = re.sub(r"@\S+", "", text) # 去掉多余空格和回龙车符 text = re.sub(r"\s+", " ", text).strip() return text def tokenize(text: str) -> list: text = clean_text(text) # HMM=True可以识别一些未登录词，但对细粒度匹配不稳定，可视情况关闭 return [w for w in jieba.lcut(text) if w.strip()] text = "口味很好，但上菜太慢，服务员态度也一般。" tokens = tokenize(text) print(tokens) # 输出: ['口味', '很', '好', '，', '但', '上菜', '太', '慢', '，', '服务员', '态度', '也', '一般', '。']

这段代码有三个参数值得注意。jieba.load_userdict的自定义词典是纯文本文件，每行一个词，格式是“词 词频 词性”，词频可以省略。HMM 参数处理方式很关键：开着 HMM 能识别新词，但对特定细粒度词的切分可能不稳定；我一般开着，因为关闭后对长尾菜品名反而更不友好。最后的正则过滤只删 URL 和多余空白，不做停用词剔除——在细粒度任务里，“不”“太”“一般”这些词在短文本里覆盖大量情感线索，一刀切过滤会直接损失信息。

停用词表选择也提一句：不要用通用大表。通用表里往往包含“好”“不”“是”这类高频词，但在评论语境里它们是重要的情感信号。如果需要停用词表，建议从自己数据里统计高频词，人工审一遍挑选真正无意义的词。我踩过这个坑，第一版直接用了网上的中文停用词表，结果情感分类准确率掉了好几个点。

3.3 规则与统计基线：基于词典的方面检测和情感打分

训练深度学习模型之前，一定要先搭一个规则基线。它有三个作用：一是冷启动阶段在没有标注数据时直接产出结果；二是给后续模型提供一个对比基准，模型必须打得过规则基线才有意义；三是规则部分的输出可以作为弱标注数据喂给模型训练。

基于词典的规则方法做细粒度分析，核心思路是三步：匹配方面词、在窗口内找情感词、结合否定词和程度副词计算极性。代码可以直接跑：

import re from collections import defaultdict aspect_tables = { "口味": ["口味", "味道", "口感", "好吃", "难吃"], "服务": ["服务", "服务员", "态度", "热情", "冷漠"], "环境": ["环境", "装修", "卫生", "干净"], "价格": ["价格", "价钱", "性价比", "贵", "便宜"], "速度": ["速度", "上菜", "出餐", "等位"], } pos_words = ["好", "不错", "赞", "棒", "快", "美味", "满意", "推荐", "热情", "干净", "便宜"] neg_words = ["差", "慢", "一般", "难吃", "敷衍", "贵", "冷漠", "脏", "失望", "不推荐"] negators = ["不", "没", "别", "不太", "没那么", "没有"] intensifiers = {"很": 2, "太": 2, "非常": 2, "特别": 2, "有点": 0.5, "稍微": 0.5, "比较": 1.2} def rule_based_predict(text: str, window: int = 5) -> dict: tokens = tokenize(text) results = {} for aspect, keywords in aspect_tables.items(): for keyword in keywords: if keyword in tokens: idx = tokens.index(keyword) start = max(0, idx - window) end = min(len(tokens), idx + window + 1) context = tokens[start:end] score = 0.0 matched = False for word in context: if word in pos_words: score += 1.0 matched = True elif word in neg_words: score -= 1.0 matched = True elif word in negators: score *= -1.0 elif word in intensifiers: score *= intensifiers[word] if matched: polarity = "正向" if score > 0 else ("负向" if score < 0 else "中性") results.setdefault(aspect, polarity) return results text = "口味很好，但上菜太慢，服务员态度也一般。" print(rule_based_predict(text)) # 输出: {'口味': '正向', '速度': '负向', '服务': '中性'}

逻辑说明：对每个方面词，在它前后各window个词的窗口范围里扫描情感词，命中正情感词加分、负情感词减分；遇到否定词直接翻转当前累计分数；遇到程度副词对分数乘权重。最后按分数正负输出极性。窗口大小的选择是核心参数：窗口太大容易把别的方面情感混进来，窗口太小会漏掉“太慢”里的“太”。我实测下来 5 比较平衡，短评为主可以缩到 4，长评多可以放到 6。

这段代码在真实数据上的效果，取决于方面词典的完整度。一个方面词覆盖不到，这一类的预测就是空的。因此跑完第一轮规则结果后，要抽一批样本看哪些方面没被覆盖，补词典再跑，迭代两三轮。这个迭代本身就是在积累“线索”，后续喂给模型的弱标签也主要靠它。

3.4 训练一个 BiLSTM+Attention 的细粒度分类模型

规则基线兜底之后，就该上数据驱动模型了。对小规模标注数据，BiLSTM+Attention 是成本低、效果稳定的经典组合。它的思路是：用双向 LSTM 编码上下文，再用注意力机制突出和当前分类任务最相关的 token。相对直接用词向量平均，它能学到“太慢”中“太”对“慢”的强调作用，这正是细粒度情感分类特别需要的能力。

下面是用 PyTorch 实现的核心模型结构，为了控制篇幅我删减了 EarlyStopping 等外围逻辑，只保留主路径：

import torch import torch.nn as nn class BiLSTMAttention(nn.Module): def __init__(self, vocab_size, embed_dim=128, hidden_dim=128, num_classes=3, dropout=0.5): super().__init__() self.embedding = nn.Embedding(vocab_size, embed_dim, padding_idx=0) self.lstm = nn.LSTM( embed_dim, hidden_dim, batch_first=True, bidirectional=True, num_layers=2, dropout=dropout ) # 可学习的注意力打分向量 self.attention_w = nn.Parameter(torch.randn(hidden_dim * 2)) self.classifier = nn.Linear(hidden_dim * 2, num_classes) self.dropout = nn.Dropout(dropout) def forward(self, input_ids, mask=None): emb = self.embedding(input_ids) # [B, L, embed_dim] lstm_out, _ = self.lstm(emb) # [B, L, hidden*2] # 注意力得分，排除padding位的影响 score = torch.tanh(lstm_out) @ self.attention_w if mask is not None: score = score.masked_fill(mask == 0, -1e9) attn_weight = torch.softmax(score, dim=-1) context = torch.bmm(attn_weight.unsqueeze(1), lstm_out).squeeze(1) logits = self.classifier(self.dropout(context)) return logits

模型设计的几个关键参数：embed_dim=128是基于小规模语料的经验值，换更大语料可以升到 200 以上，但收益趋缓；LSTM 用 2 层、双向，输出维度变成hidden_dim * 2；num_classes对应三级极性的分类数，中性类在评论数据里占比往往不高，训练时注意按类别加权重。注意力部分我给 mask 设了-1e9，是为了让 padding 位置的 attention 权重趋近于 0，否则模型会在补齐的空位上学到无关模式。

训练部分的代码重点在损失函数和优化器选择：

from torch.utils.data import DataLoader, Dataset class ReviewDataset(Dataset): def __init__(self, samples, max_len=64): self.samples = samples # 每条样本是 (token_ids, label) self.max_len = max_len def __len__(self): return len(self.samples) def __getitem__(self, idx): token_ids, label = self.samples[idx] ids = token_ids[: self.max_len] + [0] * (self.max_len - len(token_ids)) mask = [1 if w != 0 else 0 for w in ids] return torch.tensor(ids), torch.tensor(mask), torch.tensor(label) def train(model, dataloader, epochs=10, lr=1e-3): optimizer = torch.optim.Adam(model.parameters(), lr=lr) criterion = nn.CrossEntropyLoss() model.train() for epoch in range(epochs): total_loss = 0.0 for token_ids, mask, label in dataloader: optimizer.zero_grad() logits = model(token_ids, mask) loss = criterion(logits, label) loss.backward() optimizer.step() print(f"epoch {epoch + 1}, loss {total_loss / len(dataloader):.4f}")

训练时的参数配置和调参方向：学习率 1e-3 配 Adam 是稳妥起点，模型收敛太慢就把 lr 调到 2e-3，训练发散了就调到 5e-4；batch_size设 32，评论长度较短时显存压力可以忽略；max_len=64后文 5.4 个坑会专门说到，截断策略对长评论的方面提取影响很大。另外每轮训练后要在验证集上算 F1，不要只盯 loss——细粒度任务经常出现 loss 在降但 F1 不动的情况。

这一阶段输出的模型效果，目标是超过规则基线。如果标注数据少于 2000 条，模型可能不如规则，这是正常的，优先扩数据而不是换模型。

3.5 模型训练与评估：数据集划分、早停与怎么看损失

数据划分这里有一个常见误解：直接把一条条句子随机拆训练/验证。但细粒度任务一条评论拆开后，同一评论的不同方面可能被分到两个集合，造成信息泄漏。正确做法是先按评论 ID 分组再切分，把我 3.1 中的样本结构理解成“评论内部多条方面记录”，训练时按评论维度划分。同一条评论的不同方面具有很强的上下文关联性，泄漏会给验证集 F1 带来虚高的假象。

评估指标不能只用准确率。方面级情感分类有三层口径：方面抽取准不准、极性判得对不对、两个都做对的完整匹配率。我建议至少同时打印 macro-F1（各类别 F1 的平均）、每个类别的 precision/recall，以及“完全正确率”（一个方面及其极性都猜中才算对）。这几项指标能帮你快速定位问题：precison 低说明模型容易误报方面，recall 低说明有方面没抽出。

早停是防止过拟合最简单实用的手段。每轮训练后检查验证集 F1，连续 3 轮没有提升就停止，保存最好一轮的模型权重。我第一版训练时没有早停，跑了 20 轮直接过拟合，测试集 F1 反而比第 8 轮差了 4 个点。训练结束后要顺手把最佳轮次和对应的参数都记录到一个文本文件里，否则复盘时根本不知道当前权重是怎么训出来的。

4. 把模型结果变成能用的东西：统计口径、可视化与报告生成

4.1 从预测结果到业务图表：词频、情感分布与方面热度

模型输出只是中间产物，业务方要的是直观结论。最低成本的展示方式是把预测结果做成三张图：方面提及量柱状图、方面情感占比堆叠条形图、关键词词云。为什么不是词云优先？因为纯词频会突出“很好”“非常”这类高频废话。我一般用 TF-IDF 过滤后拿前 20 个词做词云，词云只是辅助，真正看分布靠前两张图。

用 pandas 聚合数据，按步骤来：

import pandas as pd df = pd.read_csv("predictions.csv") # 列: text, aspect, polarity, source aspect_stats = df.groupby(["aspect", "polarity"]).size().unstack(fill_value=0) aspect_stats["total"] = aspect_stats.sum(axis=1) aspect_stats["positive_ratio"] = aspect_stats.get("正向", 0) / aspect_stats["total"] print(aspect_stats.sort_values("total", ascending=False).head(10))

逻辑说明：groupby(["aspect", "polarity"]).size()统计每个方面下各类极性出现的次数，unstack把极性转成列，方便横向看分布。这里的“正向”列名要和模型输出保持一致，模型如果用英文标签（0/1/2），这里先映射成中文。聚合后按total降序排列，能一眼看出“哪个方面被讨论最多、哪个方面负向占比最高”。

如果业务方有渠道维度（美团、饿了么、口碑、自有 App），把source加进 groupby 里再做一轮交叉统计，就能回答“哪个平台的投诉集中在哪个方面”。这一步是让报告增值最明显的操作。

4.2 让结果可解释：按维度、渠道、时间的交叉分析

单一维度统计只能回答“有什么问题”，交叉统计才能回答“问题从哪来”。我常做的三个交叉切口：渠道 × 方面、时间 × 方面、星级 × 方面。比如把一条评论同时拆出渠道、评分、方面、极性四个字段，就能建立“低分评论主要吐槽环境”“最近两周某渠道的服务差评异常上升”这样的结论。

这里的时间分析要特别注意季节和活动的干扰。我做某品牌外卖评论时，某周“包装”差评突然暴增，第一反应是模型抽错了，后来排查是平台统一换了包装，用户吐槽新包装漏油。这类事件驱动的波动不是模型问题，但必须在报告里标注出背景，避免误导运营决策。

图表生成我常用 matplotlib 或 seaborn，中文字体需要额外配置，plt.rcParams["font.sans-serif"] = ["SimHei"]这行建议放到所有绘图脚本的公共模块里，否则写一次忘一次。报告输出直接做成 CSV + PNG 图片的组合，不搞复杂的 HTML 报告，轻量、易归档、可直接发给业务方。

5. 细粒度情感分析最容易翻车的 5 个坑：现象、原因与排查方法

5.1 标注数据不一致，模型指标虚高

现象：双人标注同一批数据后，用其中一个人的标签训练，另一个人验证，F1 有零点九几，但放到生产环境效果立刻变差。

原因：标注一致性低，验证集里的“标准答案”本身就不可靠，指标虚高是假象。根源是标注规范里没定义清楚边界情况，比如“价格有点贵”里的“有点贵”算正向还是负向，两个人理解不同。

解决：训练前先做一致性检验，Kappa 低于 0.7 就返回去重新统一标注规范。正式实验里，我给每个标注人员分配重叠的 10% 数据，实时监控 Kappa，低于阈值时暂停标注、开会讨论，直到所有边界情况都有明确约定。

5.2 分词切碎了细粒度方面词，导致抽取失败

现象：评论是“服务态度不错”，规则基线输出里没有“服务”这个方面；查日志发现分词结果是“服务/态度/不错”，关键词“态度”虽然在方面表里，但“服务”词条没匹配上。

原因：jieba 默认按最大匹配切分，第二个“服务”被切开，而你的方面词典里同时写了“服务”和“态度”，两者都没完整命中。本质原因是方面词典在扩展，而分词词典没有同步。

解决：每轮迭代新增方面词时，同步把它们加进 jieba 的自定义词典里，强制不被拆分。注意加完自定义词典后要重启进程，load_userdict只能加载一次，重复加载不会生效。这个坑排错最快的方法是打印分词结果对比，别靠猜。

5.3 类别样本严重不平衡，“中评”永远学不会

现象：训练集里正向样本占 70%，负向占 25%，中性只占 5%，模型训练结束后中性类的 F1 几乎为 0，预测时把所有样本都判成正向。

原因：损失函数对所有类别一视同仁，模型只需要全猜正向就能把整体 loss 压得很低，没必要学中性类。

解决：给CrossEntropyLoss传入类别权重，反向传播时给样本少的类别更大的梯度。公式是把每个类别的样本数量倒数归一化，正向权重约 0.6，中性权重约 4。另外一个更直接的办法是过采样中性样本，但要注意同一条评论的多个方面一起复制，别拆开导致重复上下文。

5.4 长评论被截断，后半句的方面全部丢光

现象：模型预测“口味很不错”这半句能对上，但后面“就是结账太慢”的“速度”方面没被抽出来，数据预处理阶段把长文本截到 64 个 token，后半句直接丢了。

原因：max_len固定为 64，长评论从尾部截断，但评论的方面往往分布在后半段，尤其抱怨类内容常常写在最后。

解决：双重处理。第一，截断策略改成“先截尾部再截头部”或者按重要度截取，比如保留开头 32 个 token 和结尾 32 个 token；第二，如果训练数据里长评论比例少，用max_len=128重跑一版对比，很多时候长文本的信息增量比不上提高短文本的覆盖度。

5.5 随机种子不固定，昨晚的效果今天复现不出来

现象：同一条命令跑训练脚本，昨天验证集 F1 是 0.78，今天变成了 0.74，甚至每次结果都不一样。

原因：PyTorch 和 NumPy 都有随机性，不固定种子时，词序打乱、参数初始化和 dropout 都随机器变，训练结果自然不可复现。

解决：在训练脚本最前面固定三处随机源，random.seed(42)、numpy.random.seed(42)、torch.manual_seed(42)；如果用了 GPU 还要加torch.cuda.manual_seed_all(42)。注意DataLoader里的shuffle=True依赖 Python 随机源，种子没固定这一步照样乱。固定种子后重跑一次对比 loss 曲线，基本能对齐。

6. 进阶：预训练模型做微调，几招把精度再提一档

6.1 用预训练模型替换 BiLSTM：几行代码的升级路径

BiLSTM+Attention 在小数据量下有稳定表现，但数据和算力允许时，预训练模型是更省心的升级方向。中文场景下用 BERT 类模型做微调，相比自己训练词向量的优势在于：模型对“宫保鸡丁”“疯狂星期四”这类长尾表达的语义理解直接从预训练阶段继承，不需要从零学习。细粒度任务用预训练模型时，注意任务设计的差异——前者是一个句子一个标签，这里是一个句子里可能有多个方面，每个方面一个标签。

实践上我用的是两阶段管道：阶段一用规则或一个小的序列标注模型做方面抽取，阶段二把“评论 + 方面词”拼接成一个输入，喂给预训练模型做三分类。这种方式比直接接多输出头更简单，也更容易排查问题：

from transformers import AutoTokenizer, AutoModelForSequenceClassification tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese") model = AutoModelForSequenceClassification.from_pretrained( "bert-base-chinese", num_labels=3 ) text = "口味很好，但上菜太慢" aspect = "口味" inputs = tokenizer( text, text_pair=aspect, truncation=True, max_length=128, return_tensors="pt" ) outputs = model(**inputs) pred = outputs.logits.argmax(dim=-1).item() # 0=负向, 1=中性, 2=正向

这段代码里有个值得注意的参数：text_pair=aspect把方面词作为次句输入，模型能学习“评论在谈论哪个方面”。单独传评论文本而不告诉模型在问什么，等于让模型自己猜方面，效果差很多。此处的学习率要调整，预训练模型微调一般用 2e-5 到 5e-5 之间，直接用 1e-3 很容易让预训练权重被冲掉，后面怎么调都救不回来。

如果有条件，我还试过在微调时把方面类别也作为额外输入特征，比如“服务”和“口味”是不同的分类任务但共享同一个编码器。这个做法能进一步提升效果，但工程上要多维护一个方面元信息表，属于锦上添花，不用第一版就上。

6.2 用一致性检验和人工抽检验证模型可信度

模型上线前，除了看指标，我必做两件事：第一是计算模型预测与人工标注样本的 Kappa 一致性，第二是抽 20 条错误样本做归因分析。Kappa 能反映模型预测和人工判断的吻合程度，比单纯看准确率更抗“样本里本身类别比例失衡”的干扰。sklearn 里直接可以算：

from sklearn.metrics import cohen_kappa_score y_true = [2, 1, 0, 2, 0, 1, 2, 2, 0, 1] y_pred = [2, 1, 0, 1, 0, 1, 2, 2, 0, 1] kappa = cohen_kappa_score(y_true, y_pred) print(f"Kappa: {kappa:.3f}") # 通常0.6以上认为基本可用

归因分析是把预测错的样本分成三类：标注本身有歧义、规则/模型抽方面抽错了、极性判断错了。我统计过，不少“错误”其实是标注人员也拿不准的模糊案例，这类样本占总错误的 20% 到 30%。把这三类比例写清楚，跟业务方沟通时就能明确“哪些错误是模型要优化的，哪些是任务本身没有标准答案的”，避免被质疑模型选型方向有问题。

最后说一个我自己踩过的习惯性错误：早年做这类项目时，总想着换更复杂的模型来提升精度，后来发现真正决定项目成败的反而是目标定义和标注质量。先跑规则基线拿到业务可用的初版，再逐步用模型迭代，才是细粒度用户评论情感分析最省力、最不容易翻车的路径。这些方法和坑，希望帮到你。

本文还有配套的精品资源，点击获取