新闻文本分类竞赛入门：从赛题理解到F1评估与baseline搭建

第一次看到新闻文本分类这个竞赛题目的时候，很多新手的第一反应是赶紧去clone一个BERT模型跑起来。我见过不少同学第一天就把代码仓库拉下来，折腾一周之后分数却不如一个朴素的TF-IDF加逻辑回归。问题通常不出在模型上，而是出在最开始的那一步——赛题理解。

这篇文章是新闻文本分类系列的第一篇，我把题目中的业务背景、数据形态、评估指标、提交方式以及后续的解题路线一次性拆开讲清楚。内容按照一场真实竞赛的学习路径来写，适合刚接触NLP文本分类、想系统走一遍算法竞赛流程的朋友参考，也适合正在准备简历项目但不知道从哪里下手的同学。

先说明一件事：赛题理解不是跑通一个baseline就结束了。它决定了你后面所有技术方案的方向，包括模型选型、数据预处理策略、验证集划分方式，甚至决定你最终线上分数的上限。所以这一篇我写得很细，宁可多说，不说废话。

1. 赛题背景与业务价值解读

1.1 新闻文本分类在真实业务中有多常见

新闻文本分类这个任务，本质上是对一段自然语言文本打标签。你可以把它理解成一个自动化分拣员：输入一篇新闻稿，系统输出它属于哪个栏目。看起来简单，但它在真实业务里的应用场景比想象中广泛得多。

内容平台每天新产生的新闻条数在数万到数十万级别。如果全靠编辑人工标注栏目，成本高、速度慢，而且不同编辑的判断标准可能不一致。用模型做初筛，再由人工处理低置信度的样本，是目前主流的内容运营模式。除了新闻分类，这类文本多分类技术还可以直接迁移到工单自动分派、客服问题归因、舆情热点归类等场景。

从技术本身来看，新闻文本分类的难点在于类别多、文本长、噪声大。它不像电商评论情感分析那样只有正面负面两类，也不像短文本分类那样输入只有二三十个字。新闻文本动辄几百字甚至上千字，如何有效利用长文本中的信息，本身就是NLP领域一个有挑战性的子问题。

1.2 赛题与通用文本分类任务的差异

这个赛题给定的新闻文本是通过爬虫从互联网上采集的，清洗流程相对有限，文本里混杂着不少噪声。标题和正文被拼接在同一个字段里，中间用特殊字符分隔，标点符号也没有做统一规范化。这些细节在赛题理解阶段很容易被忽略，但实际上是影响线上分数的重要因素。

学术界的标准文本分类数据集通常已经做过了比较严格的清洗，类标均衡程度也比较理想。但竞赛题的数据更接近真实场景：类别分布不均衡，不同类别样本量差异可以达到数十倍；部分类别之间还存在语义重叠。比如“股市”和“财经”这两类，在很多语境下是难以严格区分的。模型要学的不是词汇表面的差异，而是这两类在语境和表达方式上的细微区别。

所以赛题理解阶段要做的第一件事，不是急着写模型代码，而是把数据拿在手上一行一行看清楚。数据里有什么、缺什么、噪声在哪里，这些信息直接决定后续特征工程的思路。

2. 数据概况与读取实操

2.1 别急着跑代码，先看数据长什么样

拿到数据包之后，我的习惯是先解压，用系统的文件管理工具看一眼文件结构。这个赛题的数据主要包含三个文件：训练集、测试集和提交样例。训练集用于模型训练，测试集用于线上评测，提交样例告诉你最终输出的格式长什么样。

先做最基本的文件信息确认：

$ ls -lh -rw-r--r-- 1 user staff 107M 6月 20 14:32 train_set.csv -rw-r--r-- 1 user staff 51M 6月 20 14:32 test_set.csv -rw-r--r-- 1 user staff 1.1K 6月 20 14:32 sample_submit.csv

训练集100多兆，这个体量用单机内存完全可以装下，不需要一开始就考虑分布式方案。如果连这个体量都用多进程分布式处理，大概率是把时间浪费在系统复杂度上了。

接下来用pandas把训练集读进来，只看前几行，感受一下数据结构：

import pandas as pd train_df = pd.read_csv('train_set.csv', sep='\t') test_df = pd.read_csv('test_set.csv', sep='\t') print(train_df.head())

输出大概是这个形态：

这里有两个关键信息。第一个，分隔符是tab而不是逗号；第二个，文本字段已经不是原始的字符串了，而是经过分词后的结果。

2.2 字段含义与标签体系

训练集有两个字段。label是新闻的类别编号，text是一串数字加词语的序列。这里要解释一个容易踩坑的地方：text列里的数字不是文本内容本身，而是原始语料经过分词后留下的标记。比如“6 7 0 6”中的数字，可能是文章编号、日期、页码等无意义信息，也可能代表某个实体在原始语料中的编号。直接保留它们，或者一刀切删除它们，都不对。

正确做法是先统计text列中数字出现的频率，看看它们是稀疏的还是高频的：

import re def digit_ratio(s): tokens = s.split(' ') digit_cnt = sum(1 for t in tokens if t.isdigit()) return digit_cnt / len(tokens) train_df['digit_ratio'] = train_df['text'].apply(digit_ratio) print(train_df['digit_ratio'].describe())

如果数字占比普遍较高，说明这批新闻文本里夹杂了大量非文本符号，预处理阶段需要单独处理。如果只是少数样本里有数字，那把包含数字的样本单独挑出来观察，会更高效。

标签方面，赛题一共包含14个类别，编号从0到13。每个编号对应一个新闻栏目，具体对应关系在数据说明文档里有。我建议把标签编号和栏目名做一个映射表，在后续做错误分析的时候会非常有用，比如“股市”和“财经”的混淆程度，只有可视化之后才能直观看到。

2.3 类别分布与文本长度的双重观察

类别分布是赛题理解的核心观察对象之一。直接统计看一下：

label_counts = train_df['label'].value_counts().sort_index() print(label_counts)

输出结果可以看出，有的类别样本量接近3万条，有的只有几千条。这种不均衡分布直接决定了评估指标的选择——如果使用准确率，模型只需要把样本量大的类别学好就能拿到很高分数，看起来漂亮，但小类别全部预测错误。所以赛题设置里用了F1值作为评估指标，后面会详细展开。

文本长度分布同样值得关注。新闻文本和短文本不同，长度差异极大，有的可能只有几十个字，有的超过三千字：

train_df['text_len'] = train_df['text'].apply(lambda x: len(x.split(' '))) print(train_df['text_len'].describe())

输出结果大约是这样：

• 最小长度：10
• 25%分位：400
• 50%分位：700
• 75%分位：1200
• 最大长度：5791
• 均值：907

这个长度分布对模型选型有直接影响。如果输入序列整体偏长，那么直接使用BERT这类预训练模型时，在处理超过512个token的文本时就必须考虑截断策略——是把多余部分直接砍掉，还是做分段处理后融合。截断窗口选在前512还是后512，线上分数能差出好几个千分位。这些都是在赛题理解阶段就应该明确的问题。

3. 评估指标：为什么是F1

3.1 用准确率评估多分类问题有哪些隐患

大多数人在学习分类模型时接触的第一个指标是准确率，即预测正确的样本占总样本的比例。但准确率在类别不均衡的场景下会给出严重失真信号。

举个具体例子。假设训练集有两个类别，A类有9000条，B类有1000条。一个永远预测A类的傻瓜模型，准确率是90%，看起来性能很好。但B类一条都没分对，这样的模型在业务上是完全不可用的。

更麻烦的是，准确率无法反映模型在每个类别上的表现差异。一个模型可能把A类分得很好，B类完全失败，另一个模型在两类上都达到75%的准确率。两者在总体准确率上可能接近，但在业务方看来，后者明显更靠谱，因为它在所有类别上都能工作，而不是只会做一类。

新闻文本分类赛题的训练集中，类别分布本身就存在不均衡，所以准确率不是合适的衡量标准。赛题使用F1-score正是考虑了这一点。

3.2 Macro-F1的计算逻辑拆解

要理解macro-F1，先要理解二分类里的F1值。F1是精确率（Precision）和召回率（Recall）的调和平均，公式是：

F1 = 2 * P * R / (P + R)

其中：

• 精确率P = TP / (TP + FP)，也就是预测为正类的样本里，真正是正类的比例
• 召回率R = TP / (TP + FN)，也就是所有真实正类样本里，被模型找到的比例

精确率告诉你的模型预测结果中有多少是对的，召回率告诉你在所有该找出来的东西里找到了多少。两者往往互相制约——为了提高召回率，模型倾向于预测更多的正类，这会拉低精确率；反过来也一样。

多分类场景下的F1计算有宏平均和微平均两种常见方式：

• micro-F1：把所有类别的TP、FP、FN加总后计算F1，等价于全局准确率的一种调和版本
• macro-F1：把每个类别分别计算F1，然后对所有类别的F1取算术平均值

Macro-F1不关心样本量大小，把每个类别放在平等位置上。这意味着小类别和大众类别对最终分数的贡献是等权的。模型只把人数多的类分好，其他类不管，macro-F1分数会非常低。这个指标逼迫模型在每个类别上都保持足够的分类能力。

赛题明确要求使用macro-F1，这个选择本身就传达了设计者的意图：让参赛者重视尾部类别的识别效果，而不是一味追求整体准确率。

3.3 本地验证与线上F1之间的差异来源

很多人会在本地计算macro-F1，但发现和线上分数总是有零点几的偏差。这个偏差来源主要有两个。

第一，线上测试集标签分布与训练集不一致。如果测试集中小类别占的比例更高，同样的模型在线上和本地会得到不同分数。但测试集标签我们看不到，所以这类偏差无法完全消除。

第二，提交文件里的预测结果是类别标签，但有些模型输出的是概率分布，需要通过argmax取最高概率的类别作为最终预测。这里有个细节：提交时是不需要输出概率的，只需要输出类别编号。如果你在本地验证时用了概率阈值调整，但提交时忘了同步，分数就会出现偏差。

我见过最典型的翻车案例是：本地用阈值调整把F1做到0.75，提交后只有0.70。检查半天发现，本地验证代码里对少数类做了阈值偏置，但提交代码里没有。这个问题的根源就是在赛题理解阶段没有把评估指标和提交逻辑的边界画清楚。

4. 提交格式与本地验证策略

4.1 样例提交文件教会你三件事

看一眼sample_submit.csv的内容：

label,text 2,0 5 5 1 0 5 6 ... 9,5 1 ...

这个样例文件表面上只是说明预测结果要写成什么格式，实际上隐含了三条硬性要求。

第一，预测结果是类别标签，不是概率。你要输出的每一行必须是一个0到13之间的整数，不允许把概率以第二列的形式带上。第二，格式要求是csv，分隔符是逗号。第三，测试集的文本顺序不能打乱。你在做任何处理之前要保证test_set.csv的顺序和提交顺序一一对应，否则分数直接归零。

这三条如果等到最后一天提交前再看，很容易出事故。我自己就遇到过队友把测试集shuffle之后忘记还原，提交后反馈“结果格式错误”，当场心态爆炸。赛题理解阶段就把这些规则记在本子里，后面所有代码都围绕这个格式来设计，就不会有这个风险。

4.2 用训练集划出本地验证集

赛题整体只提供了带标签的训练集和没有标签的测试集，没有单独的验证集文件。因此需要自己从训练集中拆分一部分出来作为本地验证，用来评估模型效果和调参。

验证集的划分方式直接影响你对模型能力的判断。使用简单随机采样的问题在于：如果原始类别分布不均衡，随机采样出来的验证集分布可能更加失衡，某些小类别在验证集中只有几十条，评估出来的F1波动会很大。

有实际经验的人通常会采用分层采样，按label字段的比例做抽样，保证训练集和验证集中每个类别的占比一致：

from sklearn.model_selection import train_test_split train_part, valid_part = train_test_split( train_df, test_size=0.1, stratify=train_df['label'], random_state=42 )

stratify参数就是指定按哪一列的比例来做分层划分。这里的random_state要固定住，否则每次运行都划分出不同的验证集，调参的结果就不能复现。固定随机种子是一个很容易被忽略但极其重要的细节。

4.3 划分时的三个经典雷区

分层采样解决了分布不一致的问题，但还有三个问题如果不注意，本地验证就失去了参考价值。

第一个是数据泄漏。如果你的特征工程需要统计整个训练集的词频，那在用统计结果给验证集做特征时，训练集和验证集之间就产生了信息泄漏，验证分数会被高估。正确做法是先划分训练集和验证集，再在训练集上统计词频等全局信息，然后把统计结果同时应用到两个集合。赛题理解阶段就应该把这个流程固定下来，而不是边做边改。

第二个是训练集和验证集的文本来源可能存在交叉。同一篇新闻可能在原始数据中被拆分成了多个片段，随机划分后这些片段分别落入训练集和验证集，使得模型在验证集上表现更好。这种情况在当前数据里比较难排查，但如果你发现在相同超参数下本地分数远高于线上分数，就要考虑这个可能性。

第三个是拒绝使用整段文本的前N个token作为唯一特征。因为新闻标题往往就在文本开头，模型只学标题的词就能在本地取得高分，但测试集标题和正文之间的比例可能与训练集不同，这样做出来的模型泛化能力不足。

5. 解题路线与后续方案拆解

5.1 四层方案，从简单到复杂

完成赛题理解之后，下一步就是规划解题路线。我把这个赛题的主流方案按照复杂度分为四层。

第一层是TF-IDF加机器学习模型。把文本转成TF-IDF向量，送给逻辑回归或LightGBM。这个方案计算开销小、解释性高、实现速度快，适合作为第一个baseline，通常在线上能拿到一个中等分数。适用场景是快速搭建baseline和验证特征思路。

第二层是Word2Vec加深度模型。用预训练的词向量或自己训练的词向量，把每个词映射成一个向量，然后用TextCNN、TextRNN或其变体完成分类。这一层开始引入深度模型，文本表示能力比稀疏的TF-IDF强，但需要更多调参时间。

第三层是预训练语言模型。使用BERT及其变体，通过微调完成分类。这类模型在语义理解上优势明显，尤其是对于新闻这种长文本、需要上下文理解的任务，通常能够获得最高分数。但计算资源开销大，训练时间长。

第四层是多模型融合。把前几层的预测结果做加权平均或Stacking，通过多样性提升整体性能。使用的前提是单个模型已经调优到一定水平，直接用简单模型做融合不会有大收益。

5.2 基线的选择决定了你的工作节奏

很多同学会纠结第一个方案要不要直接上BERT。我的观点是：第一版baseline一定不要上大模型，用最简单的TF-IDF加逻辑回归最合适。

原因是基线的作用不是刷分，而是验证整套代码流程是否正确。从数据加载、预处理、特征构建到模型训练、预测、提交，这一套流程先跑通，确保提交格式正确，再考虑提升精度。如果第一版就上BERT，一方面训练耗时，另一方面如果数据处理有bug，排查问题时会混入许多变量。

在本系列的下一篇中，我会详细展开TF-IDF原理与代码实现，并给出第一个baseline的完整代码。之后会分别覆盖Word2Vec与深度模型的对比、BERT微调的完整过程、以及多模型融合的实践细节。

5.3 学会记录实验过程和结果

赛题理解阶段还有一个容易被忽略的习惯：建立实验记录表。每次实验至少记录以下几个字段：日期、方案描述、关键参数、本地F1、线上F1、提交说明。

这个看起来简单，但实际执行起来特别容易偷懒。没有实验记录的情况下，调参一整天后你会发现自己连哪个参数组合出过什么分数都记不清，只能凭感觉重来。实验记录表是让经验变成复利的关键，越到后期越有用。

我个人的习惯是同步维护一个简单的markdown文件，每次实验备注代码commit号或者文件路径，确保可以从记录反查到当时改了什么。等模型越试越多之后，这个文件就是你的决策依据。

6. 实际操作中总结的经验与建议

赛题理解如果只看文档，很容易理解成走流程。但在实际项目中，这一步的效率差异非常大。以下几点是我反复踩坑之后总结出来的。

第一点，先做小的数据切片再开始写完整代码。截取1000条训练样本，把全流程跑通，确认缓存、字段、预处理逻辑都没有问题，再跑全量数据。这样做定位bug会快很多。我有一次直接跑全量，等了一个小时报错，检查后发现仅仅是某个字段里混入了空值，浪费了半小时。如果先用小数据切片，这个错误会在几秒内暴露。

第二点，模型训练前先人工读几十条样本。不要只通过describe()看统计信息，人工读原始文本很重要。分词质量怎么样，噪声集中在哪些位置，数字和特殊字符的出现规律，这些信息只有一条条读文本才能体会到。读完之后你对特征工程的判断会准确很多。

第三点，不要迷信别人的高分代码。社区里分享的代码很多都是针对特定数据集调过的，直接套用往往发挥不出宣传的效果。正确的姿势是参考思路，再结合自己的数据特点改造。赛题理解的深度决定了你能在别人的基础上走多远。

第四点，建议对错误样本做错误分析。等模型训练完成，把验证集中预测错误的样本全部打印出来，按类别分组观察。很多时候你会发现模型表现不好不是因为网络结构不够深，而是因为某个类别本身标注边界模糊，或者训练集中存在大量标注错误的样本。这时候针对性地调整数据清洗策略，比换一个更大的模型更有用。

我个人实际操作中的体会是，赛题理解这件事，花半天时间认真做，能省下后面五天的返工时间。很多人觉得这一步不产生代码、没有技术含量，就跳过去直接训练模型。但真正拉开训练效果的，往往不是谁的模型结构更高级，而是谁在跑模型之前对数据、指标和问题边界的理解更透彻。

下一篇我会从TF-IDF开始，把第一个真正意义上的baseline完整跑通。