简介：这是一份用于细粒度情感分析与方面级情感分析的标准评测数据集，面向NLP研究者、算法工程师及高校相关专业学生，可支撑情感词典构建、情感目标抽取、情感极性判断以及深度学习模型的训练与评估。压缩包共11个文件，以10个XML标注数据和1份PDF标注指南为主，整体仅1.31MB，包含餐厅与笔记本电脑两个领域的训练集、验证集及PhaseA/PhaseB两阶段测试数据，其中训练与验证数据分别用于模型构建和参数调优，两阶段测试数据则递进检验模型的泛化能力；XML文件负责存储带方面级情感极性的评论标注，PDF详细解释标注规则与评测标准。已有1220人学习下载，适合作为学术实验、课程设计或竞赛复现的基准资源。读者可借此直接开展跨领域细粒度情感分析研究，在统一任务上客观对比不同模型的表现，同时借助配套标注指南快速理解数据结构并校验算法输出。1. 别拿 SemEval-2014 Task 4 当普通情感分类数据：这是细粒度 ABSA 的起点情感分析和自然语言处理方向的同学，迟早会撞上这个数据集。它全名 Aspect-Based Sentiment Analysis（基于方面的情感分析），是 SemEval-2014 第四个子任务（Task 4）的官方标注数据。很多人第一眼看到它以为是 SST-2 那种句子级正负情绪分类，直接拿一个句子一个标签喂给模型跑 Softmax，结果指标刷得好看，一上自己的业务场景就完全失灵——因为它的标注单位是句子里的评价对象，不是整个句子。这份数据集解决的，是“这家餐厅的寿司好吃但服务慢”这种复杂句里，机器能不能分开判断寿司和服务的情感倾向。它面向的目标人群很明确：正在做细粒度情感分析、需要标准评测基准的算法工程师、NLP 方向的研究生、以及想用 ABSA 思路改造自己评论分析系统的从业者。理解了这一点，这个 zip 包的解压才是有意义的动作。2. 数据包内部结构：XML 标注体系与 train/test 划分逻辑2.1 两个领域、四层标注字段，先搞清楚每个文件是什么解压 SemEval-2014 Task 4数据集.zip 之后，目录层级很规整。根目录下是 Laptop 和 Restaurant 两个领域的文件夹，每个文件夹里各有 train 和 test 两个 XML 文件。Laptop 领域源自笔记本产品的用户评论，样本量偏小但句子表达更零散；Restaurant 领域是餐饮评论，句子结构更完整，也是后来绝大多数 ABSA 论文跑实验的主力数据。两个领域共享同一套标注规范，这点特别关键——你在餐饮数据上调好的代码，直接换路径就能在笔记本数据上跑，不需要改解析逻辑。每个 XML 文件里的基本单元是<sentence>标签，一个 sentence 对应一条原始评论句子。sentence 内嵌两个核心块：<text>存原文，<aspectTerms>和<aspectCategories>存标注结果。aspectTerms 处理的是“评价对象在原文里出现过的词”，比如“寿司”和“服务”这种实体词；aspectCategories 处理的是“评价对象在原文里没直接出现但语义明确”的类别，比如“价格”“食品质量”。抓重点：一个句子可以同时有多个 aspect term、多个 aspect category，每个 aspect 都有自己的情感极性标签——这就是细粒度这个说法的来源。2.2 解析 XML 的正确姿势：用 ElementTree 而不是正则外部看是 XML，内部看是带坐标的标注格式。aspectTerm 节点长这样：<aspectTerm term="sushi" from="x" to="y" polarity="positive"/>，其中 from 和 to 是这个词在 sentence text 里的字符级偏移量。第一次解析这个文件的人，最容易踩进去的坑是在<text>里用find()去找词的位置，然后把索引当作 from/to。事实证明，因为 XML 特殊字符会被转义（比如&还原成&后长度发生变化），这个索引经常和标注对不上。我一般直接用 xml.etree.ElementTree 解析，代码不长，也不需要引入额外的第三方库。import xml.etree.ElementTree as ET def parse_semeval2014(xml_path): tree = ET.parse(xml_path) root = tree.getroot() samples = [] for sentence in root.iter('sentence'): text = sentence.find('text').text or '' aspects = [] terms = sentence.find('aspectTerms') if terms is not None: for term in terms.findall('aspectTerm'): aspects.append({ 'target': term.get('term'), 'from': int(term.get('from')), 'to': int(term.get('to')), 'polarity': term.get('polarity') }) categories = sentence.find('aspectCategories') if categories is not None: for cat in categories.findall('aspectCategory'): aspects.append({ 'category': cat.get('category'), 'polarity': cat.get('polarity') }) if aspects: samples.append({'text': text, 'aspects': aspects}) return samples这段代码的核心逻辑是遍历每个 sentence，先取原文，再分别处理 aspectTerms 和 aspectCategories 两个子节点。需要注意root.iter('sentence')的写法对嵌套结构更鲁棒，比直接root.findall('sentence')稳——因为有些官方文件的 sentence 节点外面还包了一层 review 节点。from 和 to 是字符串，记得转成 int，后面做词片段截取时会用到。polarity 字段的取值只有四种：positive、negative、neutral、conflict，conflict 表示标注者意见不一致，官方评测时一般不计入准确率计算，但在训练时不能直接丢，否则模型学不到这种模糊样本的表示。2.3 数据规模与类别分布：餐厅和笔记本差异不小解析完两个领域的训练集，做个简单统计就能发现重要差异。Restaurant 训练集约 3000 条句子，标注了约 3700 个 aspect term 和 4700 个 aspect category；Laptop 训练集约 3000 条句子，但 aspect term 数量只有约 2300，aspect category 约 2500。什么意思呢？餐厅评论里一个句子往往同时评价氛围、价格、食物多个维度，而笔记本评论更聚焦于单一部件。这直接影响你做实验时的观察视角：Restaurant 上多任务学习比单任务涨点明显，因为多个 aspect 共享同一个句子上下文；Laptop 上则不一定，aspect 密度低了，共享上下文带来的收益会被噪声抵消。再说 polarity 分布。两个领域的 positive 占比都超过一半，negative 次之，neutral 最少，conflict 大约只有几十条。这种天然不平衡意味着你用 accuracy 做评估，无脑预测 positive 也能拿到一个不低的下限。这就是为什么我后面在验证模型效果的时候，强制要求代码里同时输出 macro-F1 和类别各自的 F1，而不是只看总准确率——先看下限在哪，不然你以为自己模型在涨，实际是样本比例在起作用。3. 四个子任务怎么选：从 Aspect Term Extraction 到 Polarity 分类3.1 子任务 1 和 3：做抽取出身，还是做分类出身SemEval-2014 Task 4 官方把任务拆成了四个子任务，很多初学者容易看岔。子任务 1 是 Aspect Term Extraction（ATE），输入是句子，输出是句子中出现过的评价对象词，比如“sushi”“service”；子任务 2 是 Aspect Term Polarity（ATP），在给定评价对象词本身及其位置的前提下，输出该词的情感极性；子任务 3 是 Aspect Category Detection（ACD），不依赖显式词，只给句子，预测评价对象所属的预定义类别（如 FOOD、SERVICE、PRICE）；子任务 4 是 Aspect Category Polarity（ACP），在给定类别的前提下判断情感倾向。选择哪个子任务作为切入点，取决于你的业务场景。如果你的线上系统已经有商家维度的结构化数据，知道用户在评论哪个商品，那做 ATP 就够了，输入是商品名加评论句子，输出情感倾向；如果你想都是从非结构化文本里先找出大家在聊什么维度，那就得做 ATE + ATP 串联，或者 ACD + ACP 串联。两条路线的模型架构差异很大：ATE/ACD 是标注或分类问题，输出是词元序列或离散类别；ATP/ACP 是给定 aspect 的条件情感分类。我实测下来的经验是，先做 ATE，再做 ATP 的流水线式方案，工程上更可控，因为 ATE 的结果可以直接可视化，错了也好定位——你给业务方展示的时候，先证明“找对了对象”，再证明“判对了情绪”，说服力比端到端黑匣子强得多。3.2 数据读取和格式转换：把 XML 变成模型能吃的训练样本不管选哪个子任务，第一步都是把原始 XML 转成统一的训练样本结构。这里有一个细节容易被忽略：aspectTerm 的 from/to 是字符偏移，但对中文或空格分词的语言来说，这个偏移不能直接切词。还好该数据集是英文，切词器用 spaCy 或 BERT tokenizer 时，偏移对齐要格外小心。通常做法是先把 sentence text 按字符偏移切出目标词，再连同整句一起交给 tokenizer 处理，然后在 token 级重新对齐目标位置。from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained('bert-base-uncased') def prepare_for_ate(sample, tokenizer, max_len=128): text = sample['text'] enc = tokenizer(text, max_length=max_len, truncation=True, return_offsets_mapping=True) labels = [-100] * len(enc['input_ids']) # -100 是 PyTorch CrossEntropyLoss 的默认忽略索引 for asp in sample['aspects']: if 'from' in asp: start_char = asp['from'] end_char = asp['to'] for idx, (start, end) in enumerate(enc['offset_mapping']): if start >= start_char and end <= end_char and end > start: labels[idx] = 1 # 标记为 B-Aspect return enc['input_ids'], enc['attention_mask'], labels代码里有几个关键点需要展开。return_offsets_mapping=True让 tokenizer 返回每个 token 在原文中的字符级位置，这是把偏移量从字符空间转换到 token 空间的标准手段。-100不是随便选的，它正好是 PyTorch 里CrossEntropyLoss默认的ignore_index，可以在计算损失的时候自动跳过 padding 和特殊 token，这部分不参与反向传播，梯度不会受影响。循环里判断的是 token 的字符区间是否完全落在 aspect 的字符区间内，这种包含式匹配比“起始位置相等才算命中”要鲁棒，因为 BERT tokenizer 会把一个词拆成多个子词，只有子词整体都落在目标范围内才能全标上。顺手提醒一句：aspectTerms 的 to 是排除末尾的，也就是text[from:to]才是目标词，切片时要小心别把它当成闭区间给多切一个字符。对要做 ATE 的人，这个转换就已经够了，接下来套一个 BiLSTM-CRF 或 BertForTokenClassification 就能训。对要做 ATP/ACP 的人则要换个格式：输入是句子加一个查询（aspect term 或 category），输出是情感极性标签。这种建模方式更接近 natural language inference：把 aspect 串成句子，让模型判断两个句子之间的蕴含/矛盾关系，从而推断情感。实际操作我一般用[CLS] text [SEP] aspect [SEP]作为输入，从[CLS]的池化输出接一个三分类头。3.3 分别在四个子任务上的评估视角：别把 Task 2 当成 Task 1我在给别人讲这份数据的时候，最常纠正的一个错误就是把子任务理解混。ATE 的评测指标是标注级别的精确率、召回率和 F1，只有预测出的字符边界和 ground truth 完全一致才算命中；ACD 的评测是类别级别的 macro-F1；ATP/ACP 则算分类准确率。之所以不推荐把这四个任务的指标混在一个表里比较，是因为它们的难度基准完全不同。ATE 要求你同时解决边界识别和词性判断，precision 很难刷上 80；ACP 是给定 aspect 条件做三分类，随机揣测 baseline 都能到 50 多。有了这四个任务各自独立的结果，你组一个流水线系统就顺手了：先 ATE 找出所有评论对象，再对每个对象做 ATP 判断情感，然后如果想按类别聚合，就再做一次 ACD，把提取出的对象映射到四五个预定义的类别上，得到每个类别的整体情感倾向。这条链路在真实的餐饮评论分析系统里验证过，能直接支撑“好评率最高的菜系是什么”“服务差评集中在哪些时段”这类业务问题的回答。4. 把 XML 转成 BERT 输入：预处理流程、长度截断与类别映射4.1 数据清洗和类别映射的规范化处理跑 BERT 之前，数据往往要先过一道清洗。这份数据集里有一种特有现象：同一个句子会同时有 aspectTerm 和 aspectCategory 标注，但是 order 是错的，比如 aspectTerm 是“price”，aspectCategory 里又给了一个“PRICE”，两者情感极性是一致的。这时候要做的是去重和合并，不然训练样本里会出现同一条 aspect 被当成两个样本，间接增加正样本的占比，影响模型学到的类别先验。另一种情况是 aspectTerm 自带的大小写不统一，比如 “Sushi” 和 “sushi”，标记的时候先统一成小写再做匹配，可以少很多麻烦。类别标签也建议统一编码成整数。polarity 有四个取值，分别对应两分类、三分类还是四分类，完全看你的下游需求。做三分类任务的时候，conflict 样本可以直接丢掉，也可以像官方一样在评测时忽略。我个人的做法是保留 conflict 但单独算一个标签，到了统计时会额外输出一个四分类的混淆矩阵，这样能直观看到模型把冲突样本误判到哪边多一些——通常会被推去 neutral，因为 neutral 和 conflict 在语义上本来就分界模糊。POLARITY_MAP = {'positive': 0, 'neutral': 1, 'negative': 2, 'conflict': 3} def convert_to_cls_format(sample, aspect, tokenizer, max_len=128): text = sample['text'] if 'target' in aspect: aspect_text = aspect['target'] elif 'category' in aspect: aspect_text = aspect['category'].replace('_', ' ') enc = tokenizer( text=text, text_pair=aspect_text, max_length=max_len, truncation=True, padding='max_length', return_tensors='pt') label = POLARITY_MAP[aspect['polarity']] return enc['input_ids'], enc['attention_mask'], enc['token_type_ids'], label这里用text_pair把 aspect 文本拼到第二个句子位置，tokenizer 会自动用[SEP]分隔开，这样极端情况下 aspect 内容越长，模型也能在第二段里得到完整上下文。对含target的 term 做输入构造时，第一个token在第二句的位置对齐是第一坑——因为token_type_ids已经区分了句子 A 和句子 B，模型分得清你输入里哪部分是原评论，哪部分是查询对象。padding='max_length'直接把训练批量固定成定长张量，不用再手动做动态 padding，DataLoader 里拿到的 batch 大小恒定，省不少调试时间。4.2 长句子截断策略：截原文不截查询词该数据集里不少原句子超过 128 token，尤其餐厅评论里用户经常一口气写一大段。BERT 类模型对max_length的处理方式是直接截断，传统做法是保留前 128 个 token，但如果最后 50 个 token 里藏着一个 aspect 词，模型就永远看不到那个评价对象，预测结果自然变成瞎猜。更稳妥的策略是“保留开头 + 截断中间”：把句子第一个 token 和各 aspect 词附近的内容保留下，中间部分做截断或直接用滑窗覆盖。在实际数据处理脚本里，我一般不重写tokenizer的截断逻辑，而是先判断 aspect 目标词的字符偏移位置和整句长度，如果 aspect 词落在尾部、快要被截断，就调整句子切分窗口，让 aspect 词处于保留区间内。简单实现是左移 window：def adaptive_truncate(text, aspect_start, max_len=128): tokens = tokenizer.tokenize(text) if len(tokens) <= max_len: return text # aspect_start 是字符偏移，粗略按比例换算成 token 位置 approx_pos = int(aspect_start / len(text) * len(tokens)) if approx_pos < max_len - 20: return tokenizer.convert_tokens_to_string(tokens[:max_len]) start = max(0, min(approx_pos - 60, len(tokens) - max_len)) return tokenizer.convert_tokens_to_string(tokens[start:start + max_len])这个函数是简易版的自适应截断，核心思想是确保目标 aspect 的上下文窗口不会在截断时被丢弃。approx_pos用字符偏移除以文本长度再映射到 token 位置，误差在英文数据集上大概几个 token 以内，够用了。截断后的文本重新传回tokenizer时会重新切分，偏移信息只用来决定窗口位置，不直接参与最终 token 对齐，所以误差不会放大。这种写法比粗暴的truncation=True右截断更适合标注数据——因为 aspect 词往往不是一个句子的开头，而是夹在中间或靠后的位置。4.3 训练时的 Batch 构造与随机采样顺序很多人在这个数据集上直接拿 DataLoader 默认顺序跑，不 shuffle，训练进度曲线一路飘，损失忽高忽低。原因在于原始 XML 文件里句子是一条条连续排的，同一个领域的相近句子主题高度相似，不 shuffle 会导致每个 batch 里的样本高度同质。稳妥做法是训练集和验证集都设shuffle=True，测试集设为False保持顺序一致。另外，一个小 trick 是把 polarity 和 aspect term 的标签拼在一起做多任务，用共享的 BERT encoder 同时输出 term 的位置和极性，这种做法在 Restaurant 领域尤其有用，因为同一句子里的多个 aspect 语义互相关联。5. 常见问题与避坑记录：五个亲测踩过的坑5.1 从偏移量到 token 的映射凭空多了几个字符现象：用 BERT 的offset_mapping结合 from/to 做 ATE 标注，训练出来的模型在测试集上 F1 偏低，检查训练数据时发现少量样本的标签位置错了一位。原因：原始 XML 中<text>里有 “&” 这类 XML 转义符，ElementTree 解析时自动还原成 “&”，原文字符长度发生偏移，原先的 from/to 是按原始字符串计算的，位置对不上。解决：解析 XML 时不要用解析后的find('text').text直接用，要拿到原始未经解析的文本再算。代码上先raw = re.findall(r'<text>(.*?)</text>', xml_string, re.S)，手动把 XML 转义符还原成目标字符，再计算偏移量。从那以后我每个数据集都先做一次偏移量随机校验，抽几条人工比对，不通过不训练。5.2 训练集和测试集的 domain 版本不一致现象：Restaurant 训练集跑出 F1 有 78，到测试集只剩 66，差一大截。原因：官方把 Restaurant 测试集里一半样本换成了 OOD 句子——标注的 aspect category 在训练集中从未出现过，比如训练集只有 FOOD、SERVICE、PRICE，测试集却突然冒出来 AMBIENCE 相关的句子。模型没见过的类别，当然预测不出来。解决：训练之前先检查训练集和测试集里 aspectCategory 标签的集合，用集合差集找出来回出现的新类别，提前想好这些样本是直接丢掉还是做特殊的 label smoothing。5.3 conflict 样本被无脑丢掉导致预测偏好漂移现象：丢弃了所有 conflict 样本之后，模型对不确定的句子强制归到 neutral，导致 neutral 的 F1 上升，positive 的 F1 下降。原因：conflict 和 neutral 在语义上其实有重叠，模型本来可以用它们之间的模糊地带做更好的边界区分。直接删掉相当于把中立样本的判别边界交给噪声。解决：保留 conflict，但训练时把它单独归一个类，计算指标时再忽略。如果框架不方便改标签集合，可以用 one-hot 三分类加上一个权重乘子，让模型知道冲突样本的损失权重低一些。5.4 中文评论误用英文数据集现象：有同学拿这个数据集的标注规范直接套中文评论数据，结果 from/to 偏移在中文上完全对不上。原因：英文的字符偏移对中文不成立，中文分词粒度不同，BERT 的 tokenizer 行为也不一样。偏移量必须按 token 级重新映射，不能复用英文数据集的预处理。解决：中文 ABSA 任务建议先做字级别的 offset 映射，再用BertTokenizerFast的return_offsets_mapping拿到中文每个 token 覆盖的字符位置，流程参考第 4.2 节，但要注意一个中文汉字在 tokenizer 里可能被拆成“字 + 标点符号”等多 token。5.5 评测时用错标签集合导致正确率偏高现象：subtask 2 的测试集准确率跑到 91，但看混淆矩阵发现 negative 一类全是 0，只剩 positive 和 neutral 在起作用，准确率虚高。原因：有些框架里，label 的 id 没有和POLARITY_MAP对齐，模型把所有样本预测到同一个类上了。准确率这种宏观指标对类别不平衡不敏感，虚高很容易骗人。解决：强制每个实验跑完输出 macro-F1 和每类 recall，不看单一 accuracy。如果某类 recall 为 0，说明模型塌了，这个实验无效。6. 端到端验证：写一个官方评估脚本，跑通任务二并自查数据质量这个数据集最适合的“第一次完整训练”路径，我建议直接从子任务 2（ATP）开始，因为输入输出都好建模，且指标含义直观。验证方式就是重写官方评测逻辑：用训练好的模型对测试集每条 sentence 的每个 aspectTerm 做预测，得到 polarity 后和真值对比，输出分类准确率和每个类别的 recall。为了让验证不流于表面，我会额外做一次数据还原——从模型的输出 JSON 中随机抽 20 条句子，把原文、预测的 polarity 和 ground truth 并排打到控制台上，眼睛确认一遍。python evaluate_atp.py --test_data data/Restaurant/Test.xml \ --checkpoint output/best_model.bin \ --output predictions.jsonevaluate_atp.py的内部逻辑不算复杂：对测试集每一条句子，跑一次 batch 推理，将预测结果按[CLS]的 logits 取 argmax 映射到标签名，然后和 JSON 里的真值比对。需要额外注意的一点是，要把预测为正类但 target 词不在原句中出现的样本记录下来——这类样本是模型猜测出来的，不是真实识别出来的，在盘点上要单独过滤掉，不然后续分析会被高估的准确率带偏。跑通以后我做的最后一件事是数据自检：把 aspectTerms 和 aspectCategories 的预测结果交叉比对，看看两个任务在同一个句子上有没有产生矛盾。比如某条句子预测 term “sushi” 是 positive，但 category 预测结果为 “FOOD#QUALITY negative”，这说明模型的 term 级和 category 级是两套独立的判断逻辑，没有共享中间表达。在这个数据集上想拿到一致的端到端结果，只做单任务是不够的，必须多任务联合训练。从那以后我每次拿到新的标注数据集，都强制走一遍“统计标签分布、抽样检查偏移量、跑官方评估脚本”这三个动作，起来之后写代码也顺手很多，也不用担心在评测集上被数据陷阱坑出无效结论。希望这份 SemEval-2014 Task 4 数据集的拆解对你有帮助。本文还有配套的精品资源，点击获取
简介：这是一份用于细粒度情感分析与方面级情感分析的标准评测数据集，面向NLP研究者、算法工程师及高校相关专业学生，可支撑情感词典构建、情感目标抽取、情感极性判断以及深度学习模型的训练与评估。压缩包共11个文件，以10个XML标注数据和1份PDF标注指南为主，整体仅1.31MB，包含餐厅与笔记本电脑两个领域的训练集、验证集及PhaseA/PhaseB两阶段测试数据，其中训练与验证数据分别用于模型构建和参数调优，两阶段测试数据则递进检验模型的泛化能力；XML文件负责存储带方面级情感极性的评论标注，PDF详细解释标注规则与评测标准。已有1220人学习下载，适合作为学术实验、课程设计或竞赛复现的基准资源。读者可借此直接开展跨领域细粒度情感分析研究，在统一任务上客观对比不同模型的表现，同时借助配套标注指南快速理解数据结构并校验算法输出。1. 别拿 SemEval-2014 Task 4 当普通情感分类数据：这是细粒度 ABSA 的起点情感分析和自然语言处理方向的同学，迟早会撞上这个数据集。它全名 Aspect-Based Sentiment Analysis（基于方面的情感分析），是 SemEval-2014 第四个子任务（Task 4）的官方标注数据。很多人第一眼看到它以为是 SST-2 那种句子级正负情绪分类，直接拿一个句子一个标签喂给模型跑 Softmax，结果指标刷得好看，一上自己的业务场景就完全失灵——因为它的标注单位是句子里的评价对象，不是整个句子。这份数据集解决的，是“这家餐厅的寿司好吃但服务慢”这种复杂句里，机器能不能分开判断寿司和服务的情感倾向。它面向的目标人群很明确：正在做细粒度情感分析、需要标准评测基准的算法工程师、NLP 方向的研究生、以及想用 ABSA 思路改造自己评论分析系统的从业者。理解了这一点，这个 zip 包的解压才是有意义的动作。2. 数据包内部结构：XML 标注体系与 train/test 划分逻辑2.1 两个领域、四层标注字段，先搞清楚每个文件是什么解压 SemEval-2014 Task 4数据集.zip 之后，目录层级很规整。根目录下是 Laptop 和 Restaurant 两个领域的文件夹，每个文件夹里各有 train 和 test 两个 XML 文件。Laptop 领域源自笔记本产品的用户评论，样本量偏小但句子表达更零散；Restaurant 领域是餐饮评论，句子结构更完整，也是后来绝大多数 ABSA 论文跑实验的主力数据。两个领域共享同一套标注规范，这点特别关键——你在餐饮数据上调好的代码，直接换路径就能在笔记本数据上跑，不需要改解析逻辑。每个 XML 文件里的基本单元是<sentence>标签，一个 sentence 对应一条原始评论句子。sentence 内嵌两个核心块：<text>存原文，<aspectTerms>和<aspectCategories>存标注结果。aspectTerms 处理的是“评价对象在原文里出现过的词”，比如“寿司”和“服务”这种实体词；aspectCategories 处理的是“评价对象在原文里没直接出现但语义明确”的类别，比如“价格”“食品质量”。抓重点：一个句子可以同时有多个 aspect term、多个 aspect category，每个 aspect 都有自己的情感极性标签——这就是细粒度这个说法的来源。2.2 解析 XML 的正确姿势：用 ElementTree 而不是正则外部看是 XML，内部看是带坐标的标注格式。aspectTerm 节点长这样：<aspectTerm term="sushi" from="x" to="y" polarity="positive"/>，其中 from 和 to 是这个词在 sentence text 里的字符级偏移量。第一次解析这个文件的人，最容易踩进去的坑是在<text>里用find()去找词的位置，然后把索引当作 from/to。事实证明，因为 XML 特殊字符会被转义（比如&还原成&后长度发生变化），这个索引经常和标注对不上。我一般直接用 xml.etree.ElementTree 解析，代码不长，也不需要引入额外的第三方库。import xml.etree.ElementTree as ET def parse_semeval2014(xml_path): tree = ET.parse(xml_path) root = tree.getroot() samples = [] for sentence in root.iter('sentence'): text = sentence.find('text').text or '' aspects = [] terms = sentence.find('aspectTerms') if terms is not None: for term in terms.findall('aspectTerm'): aspects.append({ 'target': term.get('term'), 'from': int(term.get('from')), 'to': int(term.get('to')), 'polarity': term.get('polarity') }) categories = sentence.find('aspectCategories') if categories is not None: for cat in categories.findall('aspectCategory'): aspects.append({ 'category': cat.get('category'), 'polarity': cat.get('polarity') }) if aspects: samples.append({'text': text, 'aspects': aspects}) return samples这段代码的核心逻辑是遍历每个 sentence，先取原文，再分别处理 aspectTerms 和 aspectCategories 两个子节点。需要注意root.iter('sentence')的写法对嵌套结构更鲁棒，比直接root.findall('sentence')稳——因为有些官方文件的 sentence 节点外面还包了一层 review 节点。from 和 to 是字符串，记得转成 int，后面做词片段截取时会用到。polarity 字段的取值只有四种：positive、negative、neutral、conflict，conflict 表示标注者意见不一致，官方评测时一般不计入准确率计算，但在训练时不能直接丢，否则模型学不到这种模糊样本的表示。2.3 数据规模与类别分布：餐厅和笔记本差异不小解析完两个领域的训练集，做个简单统计就能发现重要差异。Restaurant 训练集约 3000 条句子，标注了约 3700 个 aspect term 和 4700 个 aspect category；Laptop 训练集约 3000 条句子，但 aspect term 数量只有约 2300，aspect category 约 2500。什么意思呢？餐厅评论里一个句子往往同时评价氛围、价格、食物多个维度，而笔记本评论更聚焦于单一部件。这直接影响你做实验时的观察视角：Restaurant 上多任务学习比单任务涨点明显，因为多个 aspect 共享同一个句子上下文；Laptop 上则不一定，aspect 密度低了，共享上下文带来的收益会被噪声抵消。再说 polarity 分布。两个领域的 positive 占比都超过一半，negative 次之，neutral 最少，conflict 大约只有几十条。这种天然不平衡意味着你用 accuracy 做评估，无脑预测 positive 也能拿到一个不低的下限。这就是为什么我后面在验证模型效果的时候，强制要求代码里同时输出 macro-F1 和类别各自的 F1，而不是只看总准确率——先看下限在哪，不然你以为自己模型在涨，实际是样本比例在起作用。3. 四个子任务怎么选：从 Aspect Term Extraction 到 Polarity 分类3.1 子任务 1 和 3：做抽取出身，还是做分类出身SemEval-2014 Task 4 官方把任务拆成了四个子任务，很多初学者容易看岔。子任务 1 是 Aspect Term Extraction（ATE），输入是句子，输出是句子中出现过的评价对象词，比如“sushi”“service”；子任务 2 是 Aspect Term Polarity（ATP），在给定评价对象词本身及其位置的前提下，输出该词的情感极性；子任务 3 是 Aspect Category Detection（ACD），不依赖显式词，只给句子，预测评价对象所属的预定义类别（如 FOOD、SERVICE、PRICE）；子任务 4 是 Aspect Category Polarity（ACP），在给定类别的前提下判断情感倾向。选择哪个子任务作为切入点，取决于你的业务场景。如果你的线上系统已经有商家维度的结构化数据，知道用户在评论哪个商品，那做 ATP 就够了，输入是商品名加评论句子，输出情感倾向；如果你想都是从非结构化文本里先找出大家在聊什么维度，那就得做 ATE + ATP 串联，或者 ACD + ACP 串联。两条路线的模型架构差异很大：ATE/ACD 是标注或分类问题，输出是词元序列或离散类别；ATP/ACP 是给定 aspect 的条件情感分类。我实测下来的经验是，先做 ATE，再做 ATP 的流水线式方案，工程上更可控，因为 ATE 的结果可以直接可视化，错了也好定位——你给业务方展示的时候，先证明“找对了对象”，再证明“判对了情绪”，说服力比端到端黑匣子强得多。3.2 数据读取和格式转换：把 XML 变成模型能吃的训练样本不管选哪个子任务，第一步都是把原始 XML 转成统一的训练样本结构。这里有一个细节容易被忽略：aspectTerm 的 from/to 是字符偏移，但对中文或空格分词的语言来说，这个偏移不能直接切词。还好该数据集是英文，切词器用 spaCy 或 BERT tokenizer 时，偏移对齐要格外小心。通常做法是先把 sentence text 按字符偏移切出目标词，再连同整句一起交给 tokenizer 处理，然后在 token 级重新对齐目标位置。from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained('bert-base-uncased') def prepare_for_ate(sample, tokenizer, max_len=128): text = sample['text'] enc = tokenizer(text, max_length=max_len, truncation=True, return_offsets_mapping=True) labels = [-100] * len(enc['input_ids']) # -100 是 PyTorch CrossEntropyLoss 的默认忽略索引 for asp in sample['aspects']: if 'from' in asp: start_char = asp['from'] end_char = asp['to'] for idx, (start, end) in enumerate(enc['offset_mapping']): if start >= start_char and end <= end_char and end > start: labels[idx] = 1 # 标记为 B-Aspect return enc['input_ids'], enc['attention_mask'], labels代码里有几个关键点需要展开。return_offsets_mapping=True让 tokenizer 返回每个 token 在原文中的字符级位置，这是把偏移量从字符空间转换到 token 空间的标准手段。-100不是随便选的，它正好是 PyTorch 里CrossEntropyLoss默认的ignore_index，可以在计算损失的时候自动跳过 padding 和特殊 token，这部分不参与反向传播，梯度不会受影响。循环里判断的是 token 的字符区间是否完全落在 aspect 的字符区间内，这种包含式匹配比“起始位置相等才算命中”要鲁棒，因为 BERT tokenizer 会把一个词拆成多个子词，只有子词整体都落在目标范围内才能全标上。顺手提醒一句：aspectTerms 的 to 是排除末尾的，也就是text[from:to]才是目标词，切片时要小心别把它当成闭区间给多切一个字符。对要做 ATE 的人，这个转换就已经够了，接下来套一个 BiLSTM-CRF 或 BertForTokenClassification 就能训。对要做 ATP/ACP 的人则要换个格式：输入是句子加一个查询（aspect term 或 category），输出是情感极性标签。这种建模方式更接近 natural language inference：把 aspect 串成句子，让模型判断两个句子之间的蕴含/矛盾关系，从而推断情感。实际操作我一般用[CLS] text [SEP] aspect [SEP]作为输入，从[CLS]的池化输出接一个三分类头。3.3 分别在四个子任务上的评估视角：别把 Task 2 当成 Task 1我在给别人讲这份数据的时候，最常纠正的一个错误就是把子任务理解混。ATE 的评测指标是标注级别的精确率、召回率和 F1，只有预测出的字符边界和 ground truth 完全一致才算命中；ACD 的评测是类别级别的 macro-F1；ATP/ACP 则算分类准确率。之所以不推荐把这四个任务的指标混在一个表里比较，是因为它们的难度基准完全不同。ATE 要求你同时解决边界识别和词性判断，precision 很难刷上 80；ACP 是给定 aspect 条件做三分类，随机揣测 baseline 都能到 50 多。有了这四个任务各自独立的结果，你组一个流水线系统就顺手了：先 ATE 找出所有评论对象，再对每个对象做 ATP 判断情感，然后如果想按类别聚合，就再做一次 ACD，把提取出的对象映射到四五个预定义的类别上，得到每个类别的整体情感倾向。这条链路在真实的餐饮评论分析系统里验证过，能直接支撑“好评率最高的菜系是什么”“服务差评集中在哪些时段”这类业务问题的回答。4. 把 XML 转成 BERT 输入：预处理流程、长度截断与类别映射4.1 数据清洗和类别映射的规范化处理跑 BERT 之前，数据往往要先过一道清洗。这份数据集里有一种特有现象：同一个句子会同时有 aspectTerm 和 aspectCategory 标注，但是 order 是错的，比如 aspectTerm 是“price”，aspectCategory 里又给了一个“PRICE”，两者情感极性是一致的。这时候要做的是去重和合并，不然训练样本里会出现同一条 aspect 被当成两个样本，间接增加正样本的占比，影响模型学到的类别先验。另一种情况是 aspectTerm 自带的大小写不统一，比如 “Sushi” 和 “sushi”，标记的时候先统一成小写再做匹配，可以少很多麻烦。类别标签也建议统一编码成整数。polarity 有四个取值，分别对应两分类、三分类还是四分类，完全看你的下游需求。做三分类任务的时候，conflict 样本可以直接丢掉，也可以像官方一样在评测时忽略。我个人的做法是保留 conflict 但单独算一个标签，到了统计时会额外输出一个四分类的混淆矩阵，这样能直观看到模型把冲突样本误判到哪边多一些——通常会被推去 neutral，因为 neutral 和 conflict 在语义上本来就分界模糊。POLARITY_MAP = {'positive': 0, 'neutral': 1, 'negative': 2, 'conflict': 3} def convert_to_cls_format(sample, aspect, tokenizer, max_len=128): text = sample['text'] if 'target' in aspect: aspect_text = aspect['target'] elif 'category' in aspect: aspect_text = aspect['category'].replace('_', ' ') enc = tokenizer( text=text, text_pair=aspect_text, max_length=max_len, truncation=True, padding='max_length', return_tensors='pt') label = POLARITY_MAP[aspect['polarity']] return enc['input_ids'], enc['attention_mask'], enc['token_type_ids'], label这里用text_pair把 aspect 文本拼到第二个句子位置，tokenizer 会自动用[SEP]分隔开，这样极端情况下 aspect 内容越长，模型也能在第二段里得到完整上下文。对含target的 term 做输入构造时，第一个token在第二句的位置对齐是第一坑——因为token_type_ids已经区分了句子 A 和句子 B，模型分得清你输入里哪部分是原评论，哪部分是查询对象。padding='max_length'直接把训练批量固定成定长张量，不用再手动做动态 padding，DataLoader 里拿到的 batch 大小恒定，省不少调试时间。4.2 长句子截断策略：截原文不截查询词该数据集里不少原句子超过 128 token，尤其餐厅评论里用户经常一口气写一大段。BERT 类模型对max_length的处理方式是直接截断，传统做法是保留前 128 个 token，但如果最后 50 个 token 里藏着一个 aspect 词，模型就永远看不到那个评价对象，预测结果自然变成瞎猜。更稳妥的策略是“保留开头 + 截断中间”：把句子第一个 token 和各 aspect 词附近的内容保留下，中间部分做截断或直接用滑窗覆盖。在实际数据处理脚本里，我一般不重写tokenizer的截断逻辑，而是先判断 aspect 目标词的字符偏移位置和整句长度，如果 aspect 词落在尾部、快要被截断，就调整句子切分窗口，让 aspect 词处于保留区间内。简单实现是左移 window：def adaptive_truncate(text, aspect_start, max_len=128): tokens = tokenizer.tokenize(text) if len(tokens) <= max_len: return text # aspect_start 是字符偏移，粗略按比例换算成 token 位置 approx_pos = int(aspect_start / len(text) * len(tokens)) if approx_pos < max_len - 20: return tokenizer.convert_tokens_to_string(tokens[:max_len]) start = max(0, min(approx_pos - 60, len(tokens) - max_len)) return tokenizer.convert_tokens_to_string(tokens[start:start + max_len])这个函数是简易版的自适应截断，核心思想是确保目标 aspect 的上下文窗口不会在截断时被丢弃。approx_pos用字符偏移除以文本长度再映射到 token 位置，误差在英文数据集上大概几个 token 以内，够用了。截断后的文本重新传回tokenizer时会重新切分，偏移信息只用来决定窗口位置，不直接参与最终 token 对齐，所以误差不会放大。这种写法比粗暴的truncation=True右截断更适合标注数据——因为 aspect 词往往不是一个句子的开头，而是夹在中间或靠后的位置。4.3 训练时的 Batch 构造与随机采样顺序很多人在这个数据集上直接拿 DataLoader 默认顺序跑，不 shuffle，训练进度曲线一路飘，损失忽高忽低。原因在于原始 XML 文件里句子是一条条连续排的，同一个领域的相近句子主题高度相似，不 shuffle 会导致每个 batch 里的样本高度同质。稳妥做法是训练集和验证集都设shuffle=True，测试集设为False保持顺序一致。另外，一个小 trick 是把 polarity 和 aspect term 的标签拼在一起做多任务，用共享的 BERT encoder 同时输出 term 的位置和极性，这种做法在 Restaurant 领域尤其有用，因为同一句子里的多个 aspect 语义互相关联。5. 常见问题与避坑记录：五个亲测踩过的坑5.1 从偏移量到 token 的映射凭空多了几个字符现象：用 BERT 的offset_mapping结合 from/to 做 ATE 标注，训练出来的模型在测试集上 F1 偏低，检查训练数据时发现少量样本的标签位置错了一位。原因：原始 XML 中<text>里有 “&” 这类 XML 转义符，ElementTree 解析时自动还原成 “&”，原文字符长度发生偏移，原先的 from/to 是按原始字符串计算的，位置对不上。解决：解析 XML 时不要用解析后的find('text').text直接用，要拿到原始未经解析的文本再算。代码上先raw = re.findall(r'<text>(.*?)</text>', xml_string, re.S)，手动把 XML 转义符还原成目标字符，再计算偏移量。从那以后我每个数据集都先做一次偏移量随机校验，抽几条人工比对，不通过不训练。5.2 训练集和测试集的 domain 版本不一致现象：Restaurant 训练集跑出 F1 有 78，到测试集只剩 66，差一大截。原因：官方把 Restaurant 测试集里一半样本换成了 OOD 句子——标注的 aspect category 在训练集中从未出现过，比如训练集只有 FOOD、SERVICE、PRICE，测试集却突然冒出来 AMBIENCE 相关的句子。模型没见过的类别，当然预测不出来。解决：训练之前先检查训练集和测试集里 aspectCategory 标签的集合，用集合差集找出来回出现的新类别，提前想好这些样本是直接丢掉还是做特殊的 label smoothing。5.3 conflict 样本被无脑丢掉导致预测偏好漂移现象：丢弃了所有 conflict 样本之后，模型对不确定的句子强制归到 neutral，导致 neutral 的 F1 上升，positive 的 F1 下降。原因：conflict 和 neutral 在语义上其实有重叠，模型本来可以用它们之间的模糊地带做更好的边界区分。直接删掉相当于把中立样本的判别边界交给噪声。解决：保留 conflict，但训练时把它单独归一个类，计算指标时再忽略。如果框架不方便改标签集合，可以用 one-hot 三分类加上一个权重乘子，让模型知道冲突样本的损失权重低一些。5.4 中文评论误用英文数据集现象：有同学拿这个数据集的标注规范直接套中文评论数据，结果 from/to 偏移在中文上完全对不上。原因：英文的字符偏移对中文不成立，中文分词粒度不同，BERT 的 tokenizer 行为也不一样。偏移量必须按 token 级重新映射，不能复用英文数据集的预处理。解决：中文 ABSA 任务建议先做字级别的 offset 映射，再用BertTokenizerFast的return_offsets_mapping拿到中文每个 token 覆盖的字符位置，流程参考第 4.2 节，但要注意一个中文汉字在 tokenizer 里可能被拆成“字 + 标点符号”等多 token。5.5 评测时用错标签集合导致正确率偏高现象：subtask 2 的测试集准确率跑到 91，但看混淆矩阵发现 negative 一类全是 0，只剩 positive 和 neutral 在起作用，准确率虚高。原因：有些框架里，label 的 id 没有和POLARITY_MAP对齐，模型把所有样本预测到同一个类上了。准确率这种宏观指标对类别不平衡不敏感，虚高很容易骗人。解决：强制每个实验跑完输出 macro-F1 和每类 recall，不看单一 accuracy。如果某类 recall 为 0，说明模型塌了，这个实验无效。6. 端到端验证：写一个官方评估脚本，跑通任务二并自查数据质量这个数据集最适合的“第一次完整训练”路径，我建议直接从子任务 2（ATP）开始，因为输入输出都好建模，且指标含义直观。验证方式就是重写官方评测逻辑：用训练好的模型对测试集每条 sentence 的每个 aspectTerm 做预测，得到 polarity 后和真值对比，输出分类准确率和每个类别的 recall。为了让验证不流于表面，我会额外做一次数据还原——从模型的输出 JSON 中随机抽 20 条句子，把原文、预测的 polarity 和 ground truth 并排打到控制台上，眼睛确认一遍。python evaluate_atp.py --test_data data/Restaurant/Test.xml \ --checkpoint output/best_model.bin \ --output predictions.jsonevaluate_atp.py的内部逻辑不算复杂：对测试集每一条句子，跑一次 batch 推理，将预测结果按[CLS]的 logits 取 argmax 映射到标签名，然后和 JSON 里的真值比对。需要额外注意的一点是，要把预测为正类但 target 词不在原句中出现的样本记录下来——这类样本是模型猜测出来的，不是真实识别出来的，在盘点上要单独过滤掉，不然后续分析会被高估的准确率带偏。跑通以后我做的最后一件事是数据自检：把 aspectTerms 和 aspectCategories 的预测结果交叉比对，看看两个任务在同一个句子上有没有产生矛盾。比如某条句子预测 term “sushi” 是 positive，但 category 预测结果为 “FOOD#QUALITY negative”，这说明模型的 term 级和 category 级是两套独立的判断逻辑，没有共享中间表达。在这个数据集上想拿到一致的端到端结果，只做单任务是不够的，必须多任务联合训练。从那以后我每次拿到新的标注数据集，都强制走一遍“统计标签分布、抽样检查偏移量、跑官方评估脚本”这三个动作，起来之后写代码也顺手很多，也不用担心在评测集上被数据陷阱坑出无效结论。希望这份 SemEval-2014 Task 4 数据集的拆解对你有帮助。本文还有配套的精品资源，点击获取