简介SemEval-2014 Task 4 是国际上广泛采用的细粒度情感分析与方面级情感分析基准数据集面向自然语言处理方向的研究人员、硕博学生及算法工程师可解决训练语料不足、评测口径不统一等问题。压缩包共含 11 个文件以 10 份 XML 标注数据为核心覆盖餐厅与笔记本电脑两个领域的训练集、试验集和两阶段测试数据另含 1 份 PDF 标注指南整体仅 1.31MB目录按赛程阶段组织便于按需取用。目前已有 1220 人学习下载数据支持情感词典构建、情感目标抽取、情感极性判断等任务也适合从 RNN、LSTM 到 BERT 等深度学习模型的训练调优与横向对比。基于统一的标注规范和数据划分读者既能复现 SemEval 赛题结果又能检验模型跨领域泛化能力可作为课程设计、毕业设计或论文实验的标准评测语料。1. SemEval-2014 Task 4数据集ABSA任务这十年绕不开的标准考场做评论情感分析的人大概率会在某个晚上对着这份zip包发呆。SemEval-2014 Task 4数据集是过去十年ABSA基于方面的情感分析最常出现的标准考场笔记本电脑和餐厅两块评论数据带着方面词、类别和情感极性的细粒度标注。它解决的核心问题很具体一段评论里往往有多个评价对象每个对象各自的褒贬而不是整句只有一个情绪。对于正在搭评论结构化抽取pipeline、复现对比实验或者做模型微调的从业者这份数据集的定位不是“历史文物”而是“度量衡”。照着它的格式准备数据用它的口径评估结果新模型旧方法才有可比性。别嫌它旧这些年很多新任务都是在这份标注上长出来的。2. 打开之前先看懂设计四个子任务与标签体系决定你后面怎么用2.1 四个子任务分别解决什么问题抽取、分类与极性SemEval-2014 Task 4把“基于方面的情感分析”拆成了四个独立评测的子任务现在回看这个拆分本身就是一套产品设计逻辑先找评价对象再判每个对象的情绪。顺序清晰也方便单独优化。Aspect Term Extraction方面词抽取从原始句子里找出评价对象对应的文本片段。给定句子“The soup is delicious but the service is slow.”模型要输出“soup”和“service”两个片段并且带上它们在原句中的起止位置。Aspect Term Polarity在这个基础上判断每个片段的极性“soup”是positive“service”是negative。Aspect Category Detection把片段归到预定义类别比如“soup”对应FOOD#QUALITY“service”对应SERVICE#GENERAL。Aspect Category Polarity再判断这个类别在句中的极性。这个拆分的价值在于四个子任务的难度和用途不一样。抽取任务检验的是序列标注和边界识别能力类别检测检验的是语义归纳能力两个极性任务检验的是细粒度情感判断。实际工程里你可以用一个模型端到端出结果也可以拆成多级pipeline分别调优。评测时它们相互独立意味着指标可以分开追哪个环节弱就补哪个。这也是后来很多情感分析任务设计沿用它的原因。从落地角度看这四个子任务对应着评论数据结构化最常见的几个字段评价对象是谁、它的属性是什么、用户对它持什么态度。无论是做商品口碑聚合还是舆情分析最后落到报表上的无非就是这几个维度的统计。相比之下传统的整句情感分类在“服务差但菜好吃”这种句子上几乎必然翻车这也是这份数据集到今天还被反复用作基准的根本理由。2.2 标签体系与数据规模Laptop和Restaurant为什么不能混用这份数据覆盖两个领域Laptop笔记本评论和Restaurant餐厅评论。每个领域都同时标注了两套东西一套是自由标注的方面词片段标注员直接在原文里框选“soup”“hard drive”这类词另一套是预定义类别先定义好“部件/属性”的组合再让标注员从列表里选。两类标注互不冲突一个句子可以同时存在多个方面词和多个类别。两个领域的类别体系完全不同。Restaurant侧是FOOD#QUALITY、SERVICE#GENERAL这类餐饮维度Laptop侧则是DISPLAY#QUALITY、LAPTOP#PRICE这类硬件维度。类别字段的取值集合不一样训练和评测时就不能把两个领域的数据直接合并成一个多分类问题。常见做法是两个领域各自训练、各自评估论文里分别报Laptop和Restaurant的成绩。数据规模方面两个领域的训练集都在三千句上下测试集大约八百句。句子不多但信息密度高一句里往往挂了多个方面词和多个类别。极性字段不是简单的三分法而是四类positive、negative、neutral、conflict。conflict表示这句里对该对象“有褒有贬”比如“屏幕清晰但漏光严重”数量占比很小但真实存在。四分类里最容易被人忽略的就是conflict。很多人在预处理阶段直接把它丢弃或并入neutral表面上模型指标变化不大但论文对比时口径就和别人不一样了。我习惯的做法是保留四分类模型输出也保留四分类最后汇报时再单独说明是否包含conflict这样横向比较才公平。子任务输入输出评测方式Aspect Term Extraction原始句子方面词片段及起止位置strict / relaxed F1Aspect Term Polarity句子 gold方面词positive / negative / neutral / conflict分类准确率Aspect Category Detection原始句子预定义类别strict F1Aspect Category Polarity句子 gold类别四类极性分类准确率2.3 一份数据多年不淘汰的原因少量人工标注与稳定评测口径数据集是2014年的但到今天做细粒度情感分析的论文大部分仍然拿它当基准。原因有几个第一人工标注质量高方面词的边界和极性是逐句框选的比远程监督或自动标注干净得多第二评测口径固定strict和relaxed两种F1算清楚大家在同一把尺子下比划第三它足够小小到几十分钟就能训练一个基线模型方便快速迭代。这几点对从业者的启示是当你需要验证一个新的情感分析方案时不必急着找几十万条工业数据先在这份数据上跑通流程、对齐指标再迁移到自己的业务数据上。它能把“模型架构问题”和“标注体系问题”分离开来。很多新任务的衍生标注比如四元组、观点抽取都是在这份数据基础上二次标注的这也是它持续出现在最新论文里的原因。3. 解压之后怎么下手XML解析、偏移量与数据整理的Python实操3.1 压缩包里常见的文件形态与标注格式拿到zip包解压后常见的文件是一组XML命名大致如下。具体到不同来源的包可能有细微差异但XML结构保持统一这是SemEval系列评测一贯的风格。常见文件命名内容说明Laptop_Train.xml笔记本评论训练集带完整gold标注Laptop_Test_Gold.xml笔记本评论测试集带gold标注用于本地评估Restaurants_Train.xml餐厅评论训练集带完整gold标注Restaurants_Test_Gold.xml餐厅评论测试集带gold标注用于本地评估标注说明文档类别定义与标注规则使用前先读熟悉类别闭合集XML的标注结构很规律根节点是sentences下面每个sentence有id、text再往下是aspectTerms和aspectCategories两个子节点。下面这段是典型结构。注意看from和to的取值它们不是tokens序号而是字符级别的偏移量。sentences sentence id1001 textThe soup is delicious but the service is slow./text aspectTerms aspectTerm termsoup polaritypositive from4 to8/ aspectTerm termservice polaritynegative from30 to37/ /aspectTerms aspectCategories aspectCategory categoryFOOD#QUALITY polaritypositive/ aspectCategory categorySERVICE#GENERAL polaritynegative/ /aspectCategories /sentence /sentences注意两点。一是from和to是字符偏移量从0开始含前不含后text[from:to]正好等于term。二是aspectTerms和aspectCategories这两个节点名是大写T和大写C解析路径写错就什么都取不到。这两个细节是后面所有坑的源头下面会反复碰到。3.2 用ElementTree解析XML的最小可运行代码解析这份XML不需要任何第三方依赖Python标准库的xml.etree.ElementTree就够了。下面是我常用的解析函数把每条句子连同它的方面词和类别一起抽出来import xml.etree.ElementTree as ET def parse_semeval2014(xml_path): tree ET.parse(xml_path) root tree.getroot() records [] for sentence in root.iter(sentence): text sentence.findtext(text).strip() aspects [] categories [] # aspectTerms 和 aspectCategory 的标签名大小写容易写错 for at in sentence.iter(aspectTerm): aspects.append({ term: at.get(term), polarity: at.get(polarity), from: int(at.get(from)), to: int(at.get(to)), }) for ac in sentence.iter(aspectCategory): categories.append({ category: ac.get(category), polarity: ac.get(polarity), }) records.append({ sentence_id: sentence.get(id), text: text, aspect_terms: aspects, aspect_categories: categories, }) return records records parse_semeval2014(Laptop_Train.xml) print(len(records), records[0][text])这段代码的关键逻辑是用iter而不是findall直接从根节点向下遍历所有sentence和aspectTerm避免层级路径写错导致解析为空。每个aspectTerm取出term、polarity、from、to四个属性转成字典。from是Python的关键字但作为字典的键使用没有语法问题取值时用at.get(from)而不是from这一点新手很容易混淆。如果属性缺失int(at.get(from))会抛TypeError。从不明渠道拿到数据时建议先随机抽查几个aspectTerm节点确认四个属性齐全再批量解析。解析完成后records就是纯Python的list后续不管是转DataFrame还是存JSON都顺手。3.3 把原始XML整理成DataFrame/JSON脚本与边界说明XML直接喂给模型不方便我一般会把它拍平成“一行一个方面词”的表格再额外切出一列span_text用于校验偏移量。下面是完整脚本import pandas as pd records parse_semeval2014(Laptop_Train.xml) rows [] for rec in records: for a in rec[aspect_terms]: span rec[text][a[from]:a[to]] rows.append({ sentence_id: rec[sentence_id], sentence: rec[text], aspect_term: a[term], polarity: a[polarity], from: a[from], to: a[to], span_text: span, }) df pd.DataFrame(rows) df.to_csv(laptop_aspects.csv, indexFalse, encodingutf-8-sig) print(df.shape) print(df.head())这样做有三个好处。第一一行一个方面词后续做分类或者做序列标注都容易按行遍历第二span_text列是从原文按偏移量切出来的可以快速发现偏移量对不对——如果span_text和aspect_term不一致说明解析出了问题第三存成CSV后不熟悉XML的人也能接手这份数据继续做特征工程。同样的拍平逻辑要对aspect_categories也做一遍两个维度分开存。合并时不要图省事把类别和方面词塞在同一行句子“soup好吃但service慢”有一个类别和一个方面词数量碰巧一样但很多句子两者数量不等。一不留神就会做成笛卡尔积把标签对应关系弄错。提示压缩包里的测试集在当年评测时是不公开gold标签的只发布未标注的句子。如果某个来源的“测试集”只有text没有aspectTerms那多半是原始评测版不是带gold的版本评估前要确认文件里真的带标注。4. 跑通最小基线从规则特征到预训练模型含评估口径对比4.1 特征工程基线词典匹配加情感词表快速验证pipeline拿到干净数据后第一步不是上模型而是先跑一个规则基线。规则基线不是为了拿高分是为了验证数据的读取、标签的对应、评估的脚本三个环节都没问题。我一般这样处理方面词直接用gold里的term去原句匹配位置极性用一个简单的情感词窗口规则来预测。POSITIVE_WORDS {good, delicious, fast, great} NEGATIVE_WORDS {slow, bad, disappointing} def rule_based_polarity(text, term): tokens text.split() try: idx tokens.index(term) except ValueError: return neutral # 取方面词前后各两个词作为上下文窗口 window tokens[max(0, idx - 2): idx 3] if any(w in POSITIVE_WORDS for w in window): return positive if any(w in NEGATIVE_WORDS for w in window): return negative return neutral这个函数的逻辑很直白把句子按空格切词找到方面词的位置在它周围前后各取两个词看窗口里有没有正向或负向的情感词有就预测对应极性没有就预测neutral。窗口大小是最关键的超参数取太小会漏掉“but”后面的转折取太大又会引入无关词。对这份数据窗口取前后各两个词是比较稳的起点想调参可以改成参数传进来。规则基线的准确率通常不高尤其在带转折的句子上表现很差。但正因为它差才容易暴露问题如果规则基线的分数异常高反而要怀疑评估脚本是不是把gold标签泄进去了。跑通这个基线再用复杂模型才有意义否则模型翻车了你都分不清是数据问题还是模型问题。4.2 预训练模型的接入方式把方面词抽取改造成序列标注正规做法是把Aspect Term Extraction建模成序列标注给每个token分配BIO标签B-ASPECT表示方面词开始I-ASPECT表示后续O表示无关。预训练模型负责编码顶层加一个线性分类头输出标签。这份数据上最容易出错的是标签对齐因为预训练模型的分词器会把一个词切成多个subword。下面是基于字符偏移量生成BIO标签的核心逻辑def build_bio_labels(text, aspects, tokenizer, max_len128): # 用offset_mapping拿到每个token在原文中的字符区间 encoding tokenizer( text, return_offsets_mappingTrue, truncationTrue, max_lengthmax_len, ) labels [O] * len(encoding[input_ids]) for a in aspects: start, end a[from], a[to] for i, (s, e) in enumerate(encoding[offset_mapping]): if s start and e end: labels[i] B-ASPECT # 完整匹配方面词 elif s start and e end: labels[i] I-ASPECT # 方面词内部或subword return encoding, labels逻辑上这个函数先对原始文本做分词同时拿到offset_mapping也就是每个token对应原文的字符起止位置。然后遍历gold里每个方面词的from和to在token序列里找完全匹配或落在区间内的token分别打上B和I。需要特别注意的是[CLS]和[SEP]这类特殊token的offset_mapping是(0,0)不会跟任何gold区间重叠天然落在O上不用额外处理。单独看这个函数不复杂但整条训练链路里它还涉及填充、mask、批次动态padding。我的做法是先把全部句子预处理成这个格式缓存下来再交给训练循环而不是每次迭代都现算这样跑实验能省掉大量重复计算。模型这一层可以直接用常见的预训练语言模型接全连接分类头主题是数据集的解析和喂入模型架构按你自己的惯例选择即可。4.3 评估口径strict与relaxed以及对比时容易翻车的点评估方面词抽取这份数据只有两个口径全世界的论文都在这两个口径下报数。strict要求预测的起止位置和gold完全一致多一个字符少一个字符都算错relaxed只要预测的片段和gold有token重叠就算对。情感极性则是在给定正确方面词的前提下算分类准确率。口径判定规则适用场景strict预测span与gold的起止位置完全一致论文标准对比要求严格relaxed预测span与gold有至少一个token重叠更关注召回容忍边界误差polarity accuracy给定gold方面词/类别预测极性正确比例单独评估情感判断能力这里的坑在于很多人跑完实验只报一个“F1”却不写清楚是strict还是relaxed。两种口径的分数差距通常可达五到十个点论文里比较基线时如果口径不统一结论基本是废的。我习惯在实验表格里同时列两个F1并且在方法论部分写清楚极性准确率是不是在gold方面词前提下计算的。另一个细节是有些论文报极性准确率时只算positive和negative两类把neutral和conflict全部过滤掉。这么做测试集规模会缩水分数自然虚高。工业场景里neutral和conflict恰恰是最常见也最难判的所以对比文献时要特别留意对方的数据过滤方式别被数字误导。5. 用这份数据集做复现的避坑清单五个高频问题与排查办法5.1 现象XML解析出来aspectTerm是空的第一次解析的人很容易遇到句子和text都读出来了但aspectTerms节点下的内容为空。原因通常是节点名大小写不对aspectTerms里的T是大写写成aspectterms就取不到也有可能是用的解析路径不对比如sentence/aspectTerms这个相对路径在层级有变动时失效。解决的办法是把解析方式改成iter(aspectTerm)从根节点按标签名遍历而不是依赖固定层级路径。另外用sentence.findtext(text)之前先打印前500个字符确认文件编码是UTF-8避免编码问题导致标签识别错乱。解析完立刻打印一条完整记录肉眼核对term和polarity是否齐全。5.2 现象清洗文本后from/to全部对不上很多人拿到数据后会先做一轮文本清洗比如去掉表情、统一大小写、去除多余空格。清洗之后再看span_text发现跟term对不上原因是from/to是建立在原始text上的字符偏移量原始text一旦被改动偏移量就全废了。解决的办法是任何清洗操作都在保留原始text的前提下进行清洗后重新计算偏移量或者干脆不做清洗让模型自己去处理噪声。我现在的习惯是预处理链路里永远保留一份原始文本所有下游分析都从这份原始文本按偏移量取值只在送入模型时另做token级处理避免两套文本打架。5.3 现象自己写的评估脚本和官方结果对不上跑完实验用自己的脚本算F1总觉得比论文里的数字高一些甚至高出好几个点。原因多半是评估口径不一致论文用strict你用了relaxed或者polarity准确率没有排除抽取错误的样本再或者你把conflict归并成了neutral统计基数不一样。解决的办法是写评估脚本之前先确定口径写进实验记录strict还是relaxed、是否包含neutral、conflict如何处置。评估脚本里只留一个权威版本先用gold对gold跑一遍理论分数应该是100%。跑不到100%说明脚本逻辑本身有bug先修脚本再谈模型提升。5.4 现象拿无标签测试集跑出离谱分数有的数据包里测试集文件明明存在但模型跑完的F1低得离谱或者评估脚本报“找不到aspectTerms节点”。原因很可能是你拿到的是当年评测用的原始未标注测试集那个版本只有句子没有gold标签设计是用来提交给评测方统一评估的。解决的办法是用文件名里带Gold的版本做本地评估打开文件确认里面包含aspectTerms节点。如果手头只有无标签版就自己留一部分训练集做验证集先跑通流程。对比论文数字时也要留意对方评测用的是哪个版本不同版本之间没有可比性这点算是我最早在这份数据上交过的学费。5.5 现象conflict极性被静默处理对比结果失真训练时发现conflict的样本数量很少于是顺手把它映射成neutral或者直接丢弃。这样做的后果是模型输出类别数和评估统计口径悄悄变了别人用四分类、你用三类最终指标对比实际上不平等。解决的办法是保留四分类至少在统计指标时单独记一列conflict的准确率。如果模型实在学不好这个类可以在结果表里标明“报告结果不包含conflict”而不是把conflict改写成别的标签。数据标注里这种少数类代表的是“复杂但真实”的情况静默处理等于花钱买的数据白费了一部分。6. 把Task 4数据用到今天再标注扩成ASTE与跨领域迁移的进阶玩法这份数据真正值钱的地方在于它可以二次加工。第一个方向是把它扩成ASTE三元组形式也就是在已有方面词和极性的基础上补充观点词opinion span。做法是先跑一遍依存句法分析把每个方面词对应的形容词或副词候选挑出来再用人工审核修正。比如“The soup is delicious”里“soup”的opinion就是“delicious”。已有的polarity可以作为筛选候选的约束条件候选词本身的极性应先与gold极性一致这样能大幅减少人工量。第二个方向是跨领域迁移验证。用Restaurant训练、Laptop测试或者反过来能直接测出模型的领域泛化能力。预期分数会比同领域评测低不少但这正体现了“评价对象换了、情感表达方式变了”带来的真实差距。做这个实验时预处理脚本要保证两个领域走同一套解析和标注流程否则领域差异和脚本差异混在一起结论就没法看了。第三个方向是数据增强。对文本做同义词替换时要特别小心因为from/to偏移量必须同步更新稍微改动一个字符就得重新计算。回译这类重写式增强我基本不在这个数据集上用它会改写方面词本身把“screen”变成“display”gold标签就失效了。我现在的习惯是先在这份数据上把序列标注pipeline和评估脚本调试到完全稳定再迁移到自己的评论数据凡是预处理改过文本就第一时间重算偏移量绝不在改过的文本上沿用旧标签。这个习惯帮我省掉了大量返工时间希望帮到你。本文还有配套的精品资源点击获取
简介SemEval-2014 Task 4 是国际上广泛采用的细粒度情感分析与方面级情感分析基准数据集面向自然语言处理方向的研究人员、硕博学生及算法工程师可解决训练语料不足、评测口径不统一等问题。压缩包共含 11 个文件以 10 份 XML 标注数据为核心覆盖餐厅与笔记本电脑两个领域的训练集、试验集和两阶段测试数据另含 1 份 PDF 标注指南整体仅 1.31MB目录按赛程阶段组织便于按需取用。目前已有 1220 人学习下载数据支持情感词典构建、情感目标抽取、情感极性判断等任务也适合从 RNN、LSTM 到 BERT 等深度学习模型的训练调优与横向对比。基于统一的标注规范和数据划分读者既能复现 SemEval 赛题结果又能检验模型跨领域泛化能力可作为课程设计、毕业设计或论文实验的标准评测语料。1. SemEval-2014 Task 4数据集ABSA任务这十年绕不开的标准考场做评论情感分析的人大概率会在某个晚上对着这份zip包发呆。SemEval-2014 Task 4数据集是过去十年ABSA基于方面的情感分析最常出现的标准考场笔记本电脑和餐厅两块评论数据带着方面词、类别和情感极性的细粒度标注。它解决的核心问题很具体一段评论里往往有多个评价对象每个对象各自的褒贬而不是整句只有一个情绪。对于正在搭评论结构化抽取pipeline、复现对比实验或者做模型微调的从业者这份数据集的定位不是“历史文物”而是“度量衡”。照着它的格式准备数据用它的口径评估结果新模型旧方法才有可比性。别嫌它旧这些年很多新任务都是在这份标注上长出来的。2. 打开之前先看懂设计四个子任务与标签体系决定你后面怎么用2.1 四个子任务分别解决什么问题抽取、分类与极性SemEval-2014 Task 4把“基于方面的情感分析”拆成了四个独立评测的子任务现在回看这个拆分本身就是一套产品设计逻辑先找评价对象再判每个对象的情绪。顺序清晰也方便单独优化。Aspect Term Extraction方面词抽取从原始句子里找出评价对象对应的文本片段。给定句子“The soup is delicious but the service is slow.”模型要输出“soup”和“service”两个片段并且带上它们在原句中的起止位置。Aspect Term Polarity在这个基础上判断每个片段的极性“soup”是positive“service”是negative。Aspect Category Detection把片段归到预定义类别比如“soup”对应FOOD#QUALITY“service”对应SERVICE#GENERAL。Aspect Category Polarity再判断这个类别在句中的极性。这个拆分的价值在于四个子任务的难度和用途不一样。抽取任务检验的是序列标注和边界识别能力类别检测检验的是语义归纳能力两个极性任务检验的是细粒度情感判断。实际工程里你可以用一个模型端到端出结果也可以拆成多级pipeline分别调优。评测时它们相互独立意味着指标可以分开追哪个环节弱就补哪个。这也是后来很多情感分析任务设计沿用它的原因。从落地角度看这四个子任务对应着评论数据结构化最常见的几个字段评价对象是谁、它的属性是什么、用户对它持什么态度。无论是做商品口碑聚合还是舆情分析最后落到报表上的无非就是这几个维度的统计。相比之下传统的整句情感分类在“服务差但菜好吃”这种句子上几乎必然翻车这也是这份数据集到今天还被反复用作基准的根本理由。2.2 标签体系与数据规模Laptop和Restaurant为什么不能混用这份数据覆盖两个领域Laptop笔记本评论和Restaurant餐厅评论。每个领域都同时标注了两套东西一套是自由标注的方面词片段标注员直接在原文里框选“soup”“hard drive”这类词另一套是预定义类别先定义好“部件/属性”的组合再让标注员从列表里选。两类标注互不冲突一个句子可以同时存在多个方面词和多个类别。两个领域的类别体系完全不同。Restaurant侧是FOOD#QUALITY、SERVICE#GENERAL这类餐饮维度Laptop侧则是DISPLAY#QUALITY、LAPTOP#PRICE这类硬件维度。类别字段的取值集合不一样训练和评测时就不能把两个领域的数据直接合并成一个多分类问题。常见做法是两个领域各自训练、各自评估论文里分别报Laptop和Restaurant的成绩。数据规模方面两个领域的训练集都在三千句上下测试集大约八百句。句子不多但信息密度高一句里往往挂了多个方面词和多个类别。极性字段不是简单的三分法而是四类positive、negative、neutral、conflict。conflict表示这句里对该对象“有褒有贬”比如“屏幕清晰但漏光严重”数量占比很小但真实存在。四分类里最容易被人忽略的就是conflict。很多人在预处理阶段直接把它丢弃或并入neutral表面上模型指标变化不大但论文对比时口径就和别人不一样了。我习惯的做法是保留四分类模型输出也保留四分类最后汇报时再单独说明是否包含conflict这样横向比较才公平。子任务输入输出评测方式Aspect Term Extraction原始句子方面词片段及起止位置strict / relaxed F1Aspect Term Polarity句子 gold方面词positive / negative / neutral / conflict分类准确率Aspect Category Detection原始句子预定义类别strict F1Aspect Category Polarity句子 gold类别四类极性分类准确率2.3 一份数据多年不淘汰的原因少量人工标注与稳定评测口径数据集是2014年的但到今天做细粒度情感分析的论文大部分仍然拿它当基准。原因有几个第一人工标注质量高方面词的边界和极性是逐句框选的比远程监督或自动标注干净得多第二评测口径固定strict和relaxed两种F1算清楚大家在同一把尺子下比划第三它足够小小到几十分钟就能训练一个基线模型方便快速迭代。这几点对从业者的启示是当你需要验证一个新的情感分析方案时不必急着找几十万条工业数据先在这份数据上跑通流程、对齐指标再迁移到自己的业务数据上。它能把“模型架构问题”和“标注体系问题”分离开来。很多新任务的衍生标注比如四元组、观点抽取都是在这份数据基础上二次标注的这也是它持续出现在最新论文里的原因。3. 解压之后怎么下手XML解析、偏移量与数据整理的Python实操3.1 压缩包里常见的文件形态与标注格式拿到zip包解压后常见的文件是一组XML命名大致如下。具体到不同来源的包可能有细微差异但XML结构保持统一这是SemEval系列评测一贯的风格。常见文件命名内容说明Laptop_Train.xml笔记本评论训练集带完整gold标注Laptop_Test_Gold.xml笔记本评论测试集带gold标注用于本地评估Restaurants_Train.xml餐厅评论训练集带完整gold标注Restaurants_Test_Gold.xml餐厅评论测试集带gold标注用于本地评估标注说明文档类别定义与标注规则使用前先读熟悉类别闭合集XML的标注结构很规律根节点是sentences下面每个sentence有id、text再往下是aspectTerms和aspectCategories两个子节点。下面这段是典型结构。注意看from和to的取值它们不是tokens序号而是字符级别的偏移量。sentences sentence id1001 textThe soup is delicious but the service is slow./text aspectTerms aspectTerm termsoup polaritypositive from4 to8/ aspectTerm termservice polaritynegative from30 to37/ /aspectTerms aspectCategories aspectCategory categoryFOOD#QUALITY polaritypositive/ aspectCategory categorySERVICE#GENERAL polaritynegative/ /aspectCategories /sentence /sentences注意两点。一是from和to是字符偏移量从0开始含前不含后text[from:to]正好等于term。二是aspectTerms和aspectCategories这两个节点名是大写T和大写C解析路径写错就什么都取不到。这两个细节是后面所有坑的源头下面会反复碰到。3.2 用ElementTree解析XML的最小可运行代码解析这份XML不需要任何第三方依赖Python标准库的xml.etree.ElementTree就够了。下面是我常用的解析函数把每条句子连同它的方面词和类别一起抽出来import xml.etree.ElementTree as ET def parse_semeval2014(xml_path): tree ET.parse(xml_path) root tree.getroot() records [] for sentence in root.iter(sentence): text sentence.findtext(text).strip() aspects [] categories [] # aspectTerms 和 aspectCategory 的标签名大小写容易写错 for at in sentence.iter(aspectTerm): aspects.append({ term: at.get(term), polarity: at.get(polarity), from: int(at.get(from)), to: int(at.get(to)), }) for ac in sentence.iter(aspectCategory): categories.append({ category: ac.get(category), polarity: ac.get(polarity), }) records.append({ sentence_id: sentence.get(id), text: text, aspect_terms: aspects, aspect_categories: categories, }) return records records parse_semeval2014(Laptop_Train.xml) print(len(records), records[0][text])这段代码的关键逻辑是用iter而不是findall直接从根节点向下遍历所有sentence和aspectTerm避免层级路径写错导致解析为空。每个aspectTerm取出term、polarity、from、to四个属性转成字典。from是Python的关键字但作为字典的键使用没有语法问题取值时用at.get(from)而不是from这一点新手很容易混淆。如果属性缺失int(at.get(from))会抛TypeError。从不明渠道拿到数据时建议先随机抽查几个aspectTerm节点确认四个属性齐全再批量解析。解析完成后records就是纯Python的list后续不管是转DataFrame还是存JSON都顺手。3.3 把原始XML整理成DataFrame/JSON脚本与边界说明XML直接喂给模型不方便我一般会把它拍平成“一行一个方面词”的表格再额外切出一列span_text用于校验偏移量。下面是完整脚本import pandas as pd records parse_semeval2014(Laptop_Train.xml) rows [] for rec in records: for a in rec[aspect_terms]: span rec[text][a[from]:a[to]] rows.append({ sentence_id: rec[sentence_id], sentence: rec[text], aspect_term: a[term], polarity: a[polarity], from: a[from], to: a[to], span_text: span, }) df pd.DataFrame(rows) df.to_csv(laptop_aspects.csv, indexFalse, encodingutf-8-sig) print(df.shape) print(df.head())这样做有三个好处。第一一行一个方面词后续做分类或者做序列标注都容易按行遍历第二span_text列是从原文按偏移量切出来的可以快速发现偏移量对不对——如果span_text和aspect_term不一致说明解析出了问题第三存成CSV后不熟悉XML的人也能接手这份数据继续做特征工程。同样的拍平逻辑要对aspect_categories也做一遍两个维度分开存。合并时不要图省事把类别和方面词塞在同一行句子“soup好吃但service慢”有一个类别和一个方面词数量碰巧一样但很多句子两者数量不等。一不留神就会做成笛卡尔积把标签对应关系弄错。提示压缩包里的测试集在当年评测时是不公开gold标签的只发布未标注的句子。如果某个来源的“测试集”只有text没有aspectTerms那多半是原始评测版不是带gold的版本评估前要确认文件里真的带标注。4. 跑通最小基线从规则特征到预训练模型含评估口径对比4.1 特征工程基线词典匹配加情感词表快速验证pipeline拿到干净数据后第一步不是上模型而是先跑一个规则基线。规则基线不是为了拿高分是为了验证数据的读取、标签的对应、评估的脚本三个环节都没问题。我一般这样处理方面词直接用gold里的term去原句匹配位置极性用一个简单的情感词窗口规则来预测。POSITIVE_WORDS {good, delicious, fast, great} NEGATIVE_WORDS {slow, bad, disappointing} def rule_based_polarity(text, term): tokens text.split() try: idx tokens.index(term) except ValueError: return neutral # 取方面词前后各两个词作为上下文窗口 window tokens[max(0, idx - 2): idx 3] if any(w in POSITIVE_WORDS for w in window): return positive if any(w in NEGATIVE_WORDS for w in window): return negative return neutral这个函数的逻辑很直白把句子按空格切词找到方面词的位置在它周围前后各取两个词看窗口里有没有正向或负向的情感词有就预测对应极性没有就预测neutral。窗口大小是最关键的超参数取太小会漏掉“but”后面的转折取太大又会引入无关词。对这份数据窗口取前后各两个词是比较稳的起点想调参可以改成参数传进来。规则基线的准确率通常不高尤其在带转折的句子上表现很差。但正因为它差才容易暴露问题如果规则基线的分数异常高反而要怀疑评估脚本是不是把gold标签泄进去了。跑通这个基线再用复杂模型才有意义否则模型翻车了你都分不清是数据问题还是模型问题。4.2 预训练模型的接入方式把方面词抽取改造成序列标注正规做法是把Aspect Term Extraction建模成序列标注给每个token分配BIO标签B-ASPECT表示方面词开始I-ASPECT表示后续O表示无关。预训练模型负责编码顶层加一个线性分类头输出标签。这份数据上最容易出错的是标签对齐因为预训练模型的分词器会把一个词切成多个subword。下面是基于字符偏移量生成BIO标签的核心逻辑def build_bio_labels(text, aspects, tokenizer, max_len128): # 用offset_mapping拿到每个token在原文中的字符区间 encoding tokenizer( text, return_offsets_mappingTrue, truncationTrue, max_lengthmax_len, ) labels [O] * len(encoding[input_ids]) for a in aspects: start, end a[from], a[to] for i, (s, e) in enumerate(encoding[offset_mapping]): if s start and e end: labels[i] B-ASPECT # 完整匹配方面词 elif s start and e end: labels[i] I-ASPECT # 方面词内部或subword return encoding, labels逻辑上这个函数先对原始文本做分词同时拿到offset_mapping也就是每个token对应原文的字符起止位置。然后遍历gold里每个方面词的from和to在token序列里找完全匹配或落在区间内的token分别打上B和I。需要特别注意的是[CLS]和[SEP]这类特殊token的offset_mapping是(0,0)不会跟任何gold区间重叠天然落在O上不用额外处理。单独看这个函数不复杂但整条训练链路里它还涉及填充、mask、批次动态padding。我的做法是先把全部句子预处理成这个格式缓存下来再交给训练循环而不是每次迭代都现算这样跑实验能省掉大量重复计算。模型这一层可以直接用常见的预训练语言模型接全连接分类头主题是数据集的解析和喂入模型架构按你自己的惯例选择即可。4.3 评估口径strict与relaxed以及对比时容易翻车的点评估方面词抽取这份数据只有两个口径全世界的论文都在这两个口径下报数。strict要求预测的起止位置和gold完全一致多一个字符少一个字符都算错relaxed只要预测的片段和gold有token重叠就算对。情感极性则是在给定正确方面词的前提下算分类准确率。口径判定规则适用场景strict预测span与gold的起止位置完全一致论文标准对比要求严格relaxed预测span与gold有至少一个token重叠更关注召回容忍边界误差polarity accuracy给定gold方面词/类别预测极性正确比例单独评估情感判断能力这里的坑在于很多人跑完实验只报一个“F1”却不写清楚是strict还是relaxed。两种口径的分数差距通常可达五到十个点论文里比较基线时如果口径不统一结论基本是废的。我习惯在实验表格里同时列两个F1并且在方法论部分写清楚极性准确率是不是在gold方面词前提下计算的。另一个细节是有些论文报极性准确率时只算positive和negative两类把neutral和conflict全部过滤掉。这么做测试集规模会缩水分数自然虚高。工业场景里neutral和conflict恰恰是最常见也最难判的所以对比文献时要特别留意对方的数据过滤方式别被数字误导。5. 用这份数据集做复现的避坑清单五个高频问题与排查办法5.1 现象XML解析出来aspectTerm是空的第一次解析的人很容易遇到句子和text都读出来了但aspectTerms节点下的内容为空。原因通常是节点名大小写不对aspectTerms里的T是大写写成aspectterms就取不到也有可能是用的解析路径不对比如sentence/aspectTerms这个相对路径在层级有变动时失效。解决的办法是把解析方式改成iter(aspectTerm)从根节点按标签名遍历而不是依赖固定层级路径。另外用sentence.findtext(text)之前先打印前500个字符确认文件编码是UTF-8避免编码问题导致标签识别错乱。解析完立刻打印一条完整记录肉眼核对term和polarity是否齐全。5.2 现象清洗文本后from/to全部对不上很多人拿到数据后会先做一轮文本清洗比如去掉表情、统一大小写、去除多余空格。清洗之后再看span_text发现跟term对不上原因是from/to是建立在原始text上的字符偏移量原始text一旦被改动偏移量就全废了。解决的办法是任何清洗操作都在保留原始text的前提下进行清洗后重新计算偏移量或者干脆不做清洗让模型自己去处理噪声。我现在的习惯是预处理链路里永远保留一份原始文本所有下游分析都从这份原始文本按偏移量取值只在送入模型时另做token级处理避免两套文本打架。5.3 现象自己写的评估脚本和官方结果对不上跑完实验用自己的脚本算F1总觉得比论文里的数字高一些甚至高出好几个点。原因多半是评估口径不一致论文用strict你用了relaxed或者polarity准确率没有排除抽取错误的样本再或者你把conflict归并成了neutral统计基数不一样。解决的办法是写评估脚本之前先确定口径写进实验记录strict还是relaxed、是否包含neutral、conflict如何处置。评估脚本里只留一个权威版本先用gold对gold跑一遍理论分数应该是100%。跑不到100%说明脚本逻辑本身有bug先修脚本再谈模型提升。5.4 现象拿无标签测试集跑出离谱分数有的数据包里测试集文件明明存在但模型跑完的F1低得离谱或者评估脚本报“找不到aspectTerms节点”。原因很可能是你拿到的是当年评测用的原始未标注测试集那个版本只有句子没有gold标签设计是用来提交给评测方统一评估的。解决的办法是用文件名里带Gold的版本做本地评估打开文件确认里面包含aspectTerms节点。如果手头只有无标签版就自己留一部分训练集做验证集先跑通流程。对比论文数字时也要留意对方评测用的是哪个版本不同版本之间没有可比性这点算是我最早在这份数据上交过的学费。5.5 现象conflict极性被静默处理对比结果失真训练时发现conflict的样本数量很少于是顺手把它映射成neutral或者直接丢弃。这样做的后果是模型输出类别数和评估统计口径悄悄变了别人用四分类、你用三类最终指标对比实际上不平等。解决的办法是保留四分类至少在统计指标时单独记一列conflict的准确率。如果模型实在学不好这个类可以在结果表里标明“报告结果不包含conflict”而不是把conflict改写成别的标签。数据标注里这种少数类代表的是“复杂但真实”的情况静默处理等于花钱买的数据白费了一部分。6. 把Task 4数据用到今天再标注扩成ASTE与跨领域迁移的进阶玩法这份数据真正值钱的地方在于它可以二次加工。第一个方向是把它扩成ASTE三元组形式也就是在已有方面词和极性的基础上补充观点词opinion span。做法是先跑一遍依存句法分析把每个方面词对应的形容词或副词候选挑出来再用人工审核修正。比如“The soup is delicious”里“soup”的opinion就是“delicious”。已有的polarity可以作为筛选候选的约束条件候选词本身的极性应先与gold极性一致这样能大幅减少人工量。第二个方向是跨领域迁移验证。用Restaurant训练、Laptop测试或者反过来能直接测出模型的领域泛化能力。预期分数会比同领域评测低不少但这正体现了“评价对象换了、情感表达方式变了”带来的真实差距。做这个实验时预处理脚本要保证两个领域走同一套解析和标注流程否则领域差异和脚本差异混在一起结论就没法看了。第三个方向是数据增强。对文本做同义词替换时要特别小心因为from/to偏移量必须同步更新稍微改动一个字符就得重新计算。回译这类重写式增强我基本不在这个数据集上用它会改写方面词本身把“screen”变成“display”gold标签就失效了。我现在的习惯是先在这份数据上把序列标注pipeline和评估脚本调试到完全稳定再迁移到自己的评论数据凡是预处理改过文本就第一时间重算偏移量绝不在改过的文本上沿用旧标签。这个习惯帮我省掉了大量返工时间希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
