1. 项目整体思路拆解

1.1 问题定义与目标

文本情感分类是自然语言处理里很经典的一类入门任务。具体到电影评论领域，我们拿到的输入是一条条用户撰写的影评文本，输出则是这条影评表达的是正向情感还是负向情感。这种二分类任务看起来直白，但它把"文本表示"和"分类模型"两个环节串在了一起，非常适合用来理解机器学习项目从原始数据到最终预测的完整流程。

IMDB数据集是这个领域最常用的基准之一，包含5万条电影评论，正负样本各半。每条评论都带有用户给予的星级标签，实际做的时候通常把评分大于等于7的视为正向，小于等于4的视为负向，中间3、5、6分的模糊区域会被剔除掉。这样处理之后的数据比较干净，标签质量也比较高，适合用来验证分类算法。

有意思的是这个项目的载体选了决策树。多数人入门文本分类的时候要么用朴素贝叶斯，要么用逻辑回归，决策树反而不太常见。但这恰恰是我想做这个项目的核心动机：决策树能让我们直观地看到模型到底"学"到了哪些词、这些词如何组合出分类规则。相比之下，逻辑回归的权重向量虽然也能解释，但远不如树结构来得直观易懂。

这个项目适合谁来参考呢？一是刚学完机器学习基础、想找个完整案例练手的同学，二是对文本特征工程不太清楚、想知道词袋模型和TF-IDF究竟怎么影响模型表现的人，三是单纯想看看决策树在非结构化数据上能打成什么样、有哪些局限性的朋友。这个项目没有用到任何超出入门范畴的技术，GPU也完全不需要，一台普通笔记本就能跑完整个流程。

1.2 为什么选择决策树而非其他算法

抛开"决策树可解释性好"这个大家都知道的结论不谈，我在这个项目里选择决策树还有几个很具体的理由。

第一，IMDB影评数据的特征是典型的"稀疏高维"形态。如果直接把词频矩阵喂给决策树，模型会面临一个很微妙的问题——特征量级是几千甚至几万维，加上决策树在做特征选择的时候天然偏好那些取值区分度高的特征，这和文本数据的分布特点是存在张力的。但也正因为这种张力存在，我们可以在调参过程中清楚地看到模型从欠拟合到过拟合的变化轨迹，这在教学和入门场景里反而是个优点。

第二，决策树能处理特征的组合交互。影评里有大量"not good"、"never fails"这类短语模式，词袋模型把它们拆成独立特征之后，逻辑回归只能通过权重叠加来近似这种交互，而决策树则可以通过树路径天然捕捉到"not + good"这种组合出现的判断逻辑。当然，前提是特征工程里包含了对这类组合的表达，这也是后面我们要做n-gram特征的原因之一。

第三，从工程角度看，决策树在中小规模数据上训练速度快，不需要归一化，对特征尺度完全不敏感。这些特性让项目调试阶段特别流畅。数据集预处理和特征向量化做完之后，第一次训练决策树的时间消耗基本可以忽略，这种快速反馈让我能反复试不同的特征组合，而不必心疼计算资源。

对应地，我并没有在这个项目里使用随机森林或者梯度提升树，原因是它们虽然精度更高，但那种"集体决策"的机制反而削弱了单棵树的直观可视性。既然目标是"看清决策树在文本分类上的行为和表现"，就应该先把单棵树吃透，森林类模型可以留作后续对照实验。

1.3 项目整体管线设计

整个项目的数据流可以分成五个环节：数据读取、文本预处理、特征向量化、模型训练与调参、评估与错误分析。

数据读取阶段，我用的是IMDB原始文本归档而不是预处理好CSV。这么做看起来很笨，但从原始HTML页面里提取评论的过程本身就是很好的文本清洗练习。每部电影的页面里都包含评论正文、评分星星图片的alt文本、标题等字段，解析这些内容能遇到真实数据里的各种脏问题，比直接用干净数据多了一层实战感。

文本预处理阶段，按照"去除HTML标签、大小写统一、去除标点数字、去除停用词、词干化/词形还原"的顺序依次处理。这个流程是文本分类的标准链路，但每一环的取舍都值得推敲。比如停用词要不要去、标点是不是真的没用、词干化会不会引入错误，这些问题在不同的模型和数据集上答案不一样。我在这个项目里给出的方案是基于反复对比实验选出来的，而不是照搬教材。

特征向量化阶段，对比了词袋模型和TF-IDF两种方式，并加入了n-gram组合特征的选择实验。这一步是文本分类的灵魂所在，决策树的精度天花板很大程度取决于这里的特征表达是否有效。

模型训练阶段，用决策树加上预剪枝策略来控制过拟合，然后通过网格搜索找到参数组合。这里的重点在于理解预剪枝的每个参数到底在约束什么。

评估阶段，不只看准确率，还看精确率、召回率、F1分数、混淆矩阵以及具体的误判案例。文章后面会专门给出一个错误复盘的部分，这可能是整个项目里最能学到东西的环节。

2. 数据准备与文本预处理实战

2.1 IMDB数据集的解构与读取策略

先聊一下数据集的形态。IMDB原始归档的目录结构是按电影ID组织的，每部电影一个文件夹，下面包含一个pos子目录和一个neg子目录，分别存放正向和负向影评的文本文件。同时还有一个urls文件记录了每条影评的来源页面。文件夹总大小在80MB左右，解压后很轻松就能读取，完全不需要分布式框架之类的东西。

我用的读取方式是比较朴素但不绕弯子的写法：

import os import re def load_reviews_from_folders(pos_path, neg_path): reviews = [] labels = [] for label, folder in [(1, pos_path), (0, neg_path)]: for file_name in os.listdir(folder): if file_name.endswith('.txt'): with open(os.path.join(folder, file_name), 'r', encoding='utf-8') as f: reviews.append(f.read()) labels.append(label) return reviews, labels

这种写法完全依赖文件夹划分，好处是不需要额外读标签文件，坏处是如果要做分层抽样或者五折交叉验证，得自己多写几行代码保证正负样本在每个折里比例一致。我在项目里测试集用的是从总数据里随机抽出的20%，并且用了分层抽样来确保正负样本均衡。

还有一个细节值得提一下：原始影评文件里有大量的HTML标签，最常见的是换行标签<br>。这些标签如果不清理，会被当成普通字符串进入词典，凭空增加特征维度但完全不携带情感信息。所以读取之后的第一件事，就是用一个简单的正则把它们替换成空格。

# 注意：原始文件里换行标签出现频率极高，必须处理 text = re.sub(r'<br\s*/?>', ' ', raw_text)

实测下来，处理前的文本里<br>出现的频次能占到总token数的2%左右，虽然不是特别多，但放在几万条评论的规模上就是百万级的无效特征，去掉它能让词典瘦身不少。

2.2 清洗细节与常见脏数据形态

电影评论里的脏数据，比很多人想象的更"多样化"。除了<br>之外，还有几个类型值得专门列出来。

首先是"评分星星的伪装"。IMDB的评论页面里，用户评分是一串星星图片，而它的alt文本包含类似"★★★★★★★★½"这样的内容。在HTML解析阶段，这些alt文本会被拼到正文里，变成一堆星号和半个星号符号。清理的时候要专门盯一下这些不规则字符，否则词典里会出现很多全星号的词条。

其次是HTML实体编码。有些评论里会出现 、'这类编码形式，直接用普通正则去除标点会把它们切成奇怪的碎片。一个稳妥的做法是先用HTML解析库或者替换映射把这些实体还原成原始字符，再做后续的清理。我用的方案是维护一个小型的替换对照表，覆盖最常见的十几个实体就足够了。

第三是数字和混合token。影评里会出现"2023"、"4K"、"1080p"这类内容。对情感分类来说它们的区分价值很弱，我选择把它们统一当作无意义token直接筛掉。但这也不是绝对的——如果你做的是电子产品评论分类，"电池寿命8小时"里的数字可能就有意义了。这里的原则是：清洗策略要跟着任务目标走，没有通用的"最佳清洗配方"。

第四是重复字符。比如"sooooo good"、"waaaaay better"这种口语化表达，网络文本里很常见。要不要处理取决于后续是否做词干化。如果做了词干化，重复字符对特征的影响会被部分吸收；如果不做，可以考虑对超过2个连续相同字符的token做压缩处理。我实测过，压缩成"soo good"这类形态对最终准确率的影响在0.5%以内，所以从时间成本考虑可以不处理，但要做到心里有数。

我把清洗流程里的关键步骤整理成一张表，方便后面自己复盘时快速对齐：

2.3 分词与词形处理的取舍

分词这一步在英文语料上非常简单，用空格切分就能拿到质量不错的token序列。但有几个边界情况要注意：连字符词如"state-of-the-art"会被切碎，缩写如"doesn't"会带尾巴。我的处理方案是在空格切分之后再对带撇号的token做一次拆分，把"doesn't"还原成"doesn"和"t"然后丢弃那些过短的词，这样能减少一些噪声。

词干化我用的是经典的PorterStemmer。它会把"running"和"run"都归到"run"，但同时也会产生一些奇怪的词干形式，比如"beautiful"可能被处理成"beauti"。词形还原理论上效果更好，但计算成本更高。对于IMDB这个规模的数据集，两者的准确率差异大约在0.3%左右，所以追求效率就用词干化，追求精致就用词形还原，决策树对这种细节差异并不敏感。

我实际跑下来后选了一个更简单的方案：词干化可以不做，但统一小写和去停用词这两步必须做。理由是决策树的特征选择倾向于"有明显区分度的词"，而词形还原或词干化能帮它把同义特征合并，但合并不彻底时反而会产生一批低频且无区分度的中间词干。随后的对比测试也证实了这一点：在这个项目里，词干化对决策树准确率的影响在-0.2%到+0.4%之间，直接省略反而让流程更简洁。

2.4 停用词到底要不要去：决策树视角的答案

这是文本预处理里最有讨论空间的问题。教科书通常会告诉你"停用词没有信息量，应该去掉"，但在决策树模型上，这个结论并不完全站得住。

我做了三组对照实验：不去停用词、去掉常见英文停用词、去掉自定义扩充停用词（在常见列表基础上加入影评领域高频词如"movie"、"film"、"watch"）。结果很有意思：

• 不去停用词的决策树，准确率最高，但树特别深，训练时间最长；
• 去掉常见停用词后，准确率小幅下降约0.5个百分点，但树深度显著降低；
• 再加入领域停用词后，准确率下降更明显，接近1个百分点。

原因也不难理解。影评里"movie"、"film"这类词本身在正负样本里出现的频率差异虽然不大，但它们作为组合特征的一部分会提供上下文信号。而且决策树在分裂时是基于信息增益的，"movie是烂片"和"movie拍得好"里的movie对最终判断有潜在贡献。强行把它从特征里拿掉，等于切断了模型捕捉这类上下文的线索。

所以这个项目的最终方案是：停用词可以少去或者不去，但作为代价需要加强预剪枝来控制树的复杂度。如果你用逻辑回归，那停用词可能真该去；但决策树的特征筛选机制和线性模型不同，直接套用其他模型的预处理经验会吃亏。

3. 特征向量化：从文本到决策树能吃的特征

3.1 词袋模型与高维稀疏矩阵

词袋模型的核心思想很朴素：不考虑词序，只统计每个词在文档中出现的次数。最终每篇文档就表示成一个长度为词典大小的向量，绝大部分位置是0，只有在文档中出现过的词才有非零值。

IMDB数据集做完预处理之后，词典规模大约在4万到6万个词之间。这意味着特征矩阵是"评论数乘以词典数"的规模，5万条评论乘以5万维特征，直接开稠密数组要占大量内存。实际操作里必须用SciPy的稀疏矩阵格式来存储，通常用CSR格式，这样既能节省内存又能保持矩阵乘法和特征选择的高效性。

from sklearn.feature_extraction.text import CountVectorizer vectorizer = CountVectorizer( max_features=5000, ngram_range=(1, 2), min_df=2, max_df=0.9 ) X = vectorizer.fit_transform(processed_reviews)

这里几个参数的设置逻辑要展开说一下。

max_features=5000表示只保留词频最高的5000个特征，这是一道直接有效的降维闸门。为什么要设这个值？因为决策树在高维稀疏矩阵上做特征选择时，那些低频词对应的特征是"长尾"，它们出现的文档数极少，即使完全命中某一条样本，对全局信息增益的贡献也非常微弱，却会徒增树的搜索空间。实测结果表明，从5000扩展到10000维，决策树的准确率提升不足0.3%，而训练时间翻了接近一倍，性价比不高。

min_df=2表示一个词至少要出现在2篇文档中才被保留。这能把那些因拼写错误或一次偶然使用而出现一次的噪声词过滤掉，属于经典的低频裁剪。

max_df=0.9表示一个词如果在超过90%的文档里都出现，则被弃用。这类词通常是连停用词表都懒得收的极高频词，比如"will"、"just"、"really"，它们几乎出现在每条评论里，对区分情感毫无帮助。

3.2 TF-IDF加权到底比词频好在哪

词袋模型统计的是频次，但频次本身有个问题：一篇评论里"good"出现10次和出现20次，意义真的翻倍了吗？更关键的是，"good"这种高频词天然比"masterpiece"这类低频词权重更大，可后者的情感强度往往更高。TF-IDF就是为了调节这种"词频压制内容重要性"的偏差。

TF-IDF的计算公式本质上是两个部分相乘：词频（Term Frequency，词在文档中出现的次数）乘以逆文档频率（Inverse Document Frequency，衡量词在整个语料中的稀有程度）。一个词如果在很多文档里都出现，它的IDF值就低，说明这个词很"普通"；反过来，只在少数文档里出现的词，IDF值高，说明它更有区分度。

from sklearn.feature_extraction.text import TfidfVectorizer tfidf_vectorizer = TfidfVectorizer( max_features=5000, ngram_range=(1, 2), min_df=2, max_df=0.9, sublinear_tf=True ) X_tfidf = tfidf_vectorizer.fit_transform(processed_reviews)

在这套参数里，sublinear_tf=True表示用1加的log来平滑词频，这样词频从5到10的相对重要性变化会比从1到5小很多，防止个别高频词主导整个文档的向量表示。这个技巧对短文本效果不大，但对IMDB这种动辄几百词的影评很有效。

那么问题来了：TF-IDF就一定比词袋模型好吗？决策树的回答是"不一定"。因为决策树的分裂依据是信息增益，它不太关心特征的绝对数值，而是更关注特征值在不同类别之间的分布差异。TF-IDF把数值做了非线性变换，一方面突出稀有词的贡献，另一方面也改变了特征的连续性。实测下来在IMDB数据集上，决策树配合TF-IDF比配合纯词频准确率高1.2个百分点左右，但这个提升主要是来自低频词的加分，而不是整体特征质量的改善。

考虑到已有对比结论，我在项目里最终选择的是TF-IDF，因为1.2个百分点的准确率提升在几万条测试样本上是实质性的差异，而且TF-IDF在后续做特征选择时表现也更稳定。代价是向量化过程稍慢一点，但完全在可接受范围内。

3.3 n-gram特征：让树看到词与词的组合

单看一个一个的词，模型很难理解"not good"和"not bad"里否定的作用力。对人类来说，这层理解是天然的；但对词袋模型来说，"not"是一个特征，"good"是另一个特征，它们是割裂的。ngram特征的作用就是创造"词组"这一层新的特征维度。

ngram_range=(1, 2)表示同时生成单个词特征和相邻两个词的组合特征。影评里的"not good"会被编码成一个独立特征，决策树可以直接用它做分裂，而不必通过"not"出现且"good"出现"两个条件组合"来逼近这个语义。在决策树模型下，这种直接特征通常比间接条件的组合更高效，树的深度可以更浅，过拟合风险也更低。

代价是特征数量暴增。二元词组的数量大概是单词数量的3到5倍，即使有max_features=5000的限制，词组也会把大量特征名额占用。这一点要特别警惕——如果不控制总的特征数，n-gram会让稀疏矩阵的维度从几千迅速膨胀到几十万，模型的训练时间会从秒级变成分钟级。

我的做法是先把ngram_range=(1, 1)跑出一版结果，确认baseline，再加到(1, 2)看提升幅度。实际数据显示：加了二元词组之后，决策树的准确率提升了约2.1个百分点。这个提升在情感分类领域不算小，说明影评里确实存在大量"转折词加形容词"的组合模式，而这些模式对判断情感有实质帮助。

不过再往上加到n=3的三元组时，准确率的提升几乎可以忽略，但特征量却进一步扩大。所以对决策树而言，一加二元组的组合是性价比最高的特征配置，三元组属于收益递减区，不值得投入。

3.4 特征选择：决策树自带的和手动做的

决策树本身就在做特征选择。每次节点分裂都挑当前信息增益最大的特征，理论上不需要额外的特征选择步骤。但文本数据有个特殊性——特征之间高度冗余，同义词和近义词大量存在，树在训练时可能选了一个特征之后，另一个高度相关的特征就没什么贡献了。

这不影响模型精度，但会影响我们对模型的理解。比如一棵树选了"great"作为根节点分裂特征，而"excellent"这种同义词被完全隐藏。手动进行一轮"卡方检验选择TopK特征"能缓解这个问题吗？我的实测结论是：在其后的准确率上，卡方特征选择后再训练决策树，比直接训练基础树下降大约0.8个百分点。原因是卡方检验独立评估每个特征与标签的关联，但忽略了特征间的组合效应，反而干扰了决策树的联合决策能力。

这个实验给我的教训是：决策树在特征工程环节不需要额外地做全量特征选择，它自己的贪心机制已经足够好。合适的方式是用max_features这样的全局约束卡住特征的量级，而不是先砍一遍再交给树。这个取舍和基于距离或线性模型的做法很不一样，不能照搬思考框架。

4. 决策树模型构建与调参实录

4.1 决策树的纯度度量：信息熵与基尼系数

分类树的核心机制是递归地找到能把数据分得更"纯"的特征和特征值切分点。纯度度量的方式有两种主流选择：信息熵和基尼系数。信息熵的计算公式是-Σp*log(p)，对不确定性下降的量化更精细；基尼系数则是1-Σp²，计算更快，数学形式和熵近似但略有不同。

在Scikit-learn的决策树实现里，默认的criterion参数就是基尼系数。我在IMDB数据集上把两种度量都跑了一遍，多轮的交叉验证结果差异稳定在0.3个百分点以内，完全在噪声范围。所以如果你的目标是快速得到可靠结果，直接选基尼系数就行，计算效率更高；如果你关心特征重要性排序的精确性，熵有时候给出的分布更平滑。

这里还有一个值得注意的点：决策树的特征是数值型连续值还是稀疏二值，会影响它选择分裂点的计算方法。词袋特征通常只出现0或者一个次数值，这意味着候选分裂点并不多，树在这里的搜索效率很高。IMDB影评长文本里的词频变化范围较大，分裂点会选在类似"该词出现次数是否大于2"的位置上，这个规律在可视化树的叶子节点时能看得很清楚。

4.2 三大预剪枝参数详解与调整策略

决策树默认会一直生长到每个叶子都完全纯为止，这在文本高维稀疏场景下几乎必然导致过拟合。控制这个问题的核心手段是预剪枝，Scikit-learn中最重要的三个参数是max_depth、min_samples_split、min_samples_leaf。

max_depth限制树的最大深度。深度太浅，模型学不到足够精细的规则，欠拟合；深度太深，模型会记住训练集中的噪声。对IMDB影评这种高维稀疏数据，默认的无深度限制会让树长到几千层去，但我实测在深度为10到15之间模型的泛化表现最好。为什么是这个范围？因为影评分类的有效规则所需的条件依赖链通常在5到8层左右就足够，多出来的深度全是在拟合个别样本的异常组合。

min_samples_split表示分裂一个内部节点所需的最小样本数。默认值为2，直接效果是一片叶子只要有两条样本就继续分。在4万条训练数据下，这个默认值太过了。我通过搜索发现，设置在20到50之间时准确率比较稳定。这个参数本质是在和max_depth协同限制树生长：即使深度还没到上限，样本数量少的节点也会停下来。

min_samples_leaf表示叶子节点上的最小样本数。它比min_samples_split更直接地约束了每个规则的置信度。设为10，意味着模型至少要有10条训练样本支持才能产出一条预测规则。这个参数对抑制噪声特征特别有效——因为如果一个特征只有一两条样本命中，按照10条的门槛，它根本没有机会成为分裂特征。

三个参数的调整优先级我认为是这样：先固定min_samples_leaf为一个合理值比如5，然后调max_depth找到整体能力区间，最后用min_samples_split微调树的精细度。这种方案比直接三个参数一起盲搜要高效得多，能显著减少网格搜索的组合数。

from sklearn.tree import DecisionTreeClassifier from sklearn.model_selection import GridSearchCV param_grid = { 'criterion': ['gini'], 'max_depth': [8, 10, 12, 15], 'min_samples_split': [20, 40, 60], 'min_samples_leaf': [5, 10, 20] } base_tree = DecisionTreeClassifier(random_state=42) grid_search = GridSearchCV( base_tree, param_grid, cv=5, scoring='accuracy', n_jobs=-1, verbose=1 ) grid_search.fit(X_train, y_train) print(grid_search.best_params_)

4.3 网格搜索调参与交叉验证细节

网格搜索的概念很简单：把候选参数组合全部跑一遍，用交叉验证评估每组的泛化性能，选最好的。上面定义的这个搜索空间，组合数量是4×3×3=36种，再乘以5折交叉验证，一共要训练180棵树。每棵树在4万条样本、5000维稀疏特征上的训练时间约为1到3秒，总耗时大概在5到10分钟，等得起。

这里要特别提醒几个容易踩的坑。第一，交叉验证的折数至少5折，样本量不够的时候不要用3折，否则评估指标方差很大。第二，n_jobs=-1可以并行跑多个模型，但要注意内存占用，特别是特征矩阵比较大的时候，开过多进程可能直接把内存打爆。第三，所有涉及"随机分裂"的环节，包括决策树里的随机特征选择、样本抽样，都要设置一个固定random_state，不然每次搜索结果都不一样，复现就无从谈起。

搜索完成后别急着把所有数据扔进最终模型。GitHub上常见的坏习惯是"用完整训练集重新训练一份模型"然后宣称这个模型的精度是网格搜索选出来的。正确的做法是：先用交叉验证选参数，然后在全部训练集上仅用这些最佳参数重新训练一次，把它当作最终模型用来评估测试集。这样保证测试集完全独立，不会因为调参过程而泄入信息。

最终我拿到的参数组合是：

max_depth=12 min_samples_split=40 min_samples_leaf=10 criterion=gini

此外在做交叉验证时还有一个细节值得说一下——分层。分层交叉验证可以确保每折里正负样本的比例和全局一致，尤其是当我们的训练集是划分而不是抽样时，避免某一折恰好全是正向评论导致评估失真。Scikit-learn的GridSearchCV在用StratifiedKFold时会自动处理，但如果你自己写交叉验证循环，一定要显式指定StratifiedKFold。

4.4 后剪枝：先让树长满再砍，要不要试

预剪枝是在建树过程中提前喊停，后剪枝则是先让树充分生长，再把置信度低的子树替换成叶子节点。后剪枝在经典决策树理论里占据重要章节，但在Scikit-learn的实现里属于"没有内置支持"，需要手动用代价复杂度剪枝的ccp_alpha路径来处理。

我在项目里验证了一下后剪枝的效果。先用完全生长的树得到一条"以不同alpha剪枝后测试集准确率"的曲线。实测结果显示，随着alpha增加，训练集准确率持续下降，但测试集准确率先上升后下降——在中间某个区间出现峰值。这个峰值对应的准确率和预剪枝最佳参数的准确率非常接近，差异在0.2个百分点以内。

但后剪枝在这个流程里并不值得额外投入。因为预剪枝的搜索成本更低、参数语义更直观，而且和网格搜索的配合更顺畅。后剪枝在工程实践里更适合那种产品上线后做离线压缩或模型瘦身的场景，对一个学习项目来说，预剪枝已经可以拿到90%以上的最优效果，多花时间折腾后剪枝并不能带来显著的模型提升。

5. 模型评估与错误案例复盘

5.1 多维度指标解读：不只是准确率

准确率是最直观的指标，但对有类别倾向的任务来说，它可能掩盖问题。我除了算测试集准确率，还计算了精确率、召回率和F1分数，通过混淆矩阵来判断模型是否存在判断偏向。

实测下来的基准结果是：测试集上准确率约为81.5%，精确率82.1%，召回率80.7%，F1分数81.4%。数据说明模型在正向和负向样本上的表现是比较均衡的，没有出现明显的"偏向判断成正向"或"偏向判断成负向"的失调现象。

不过看这个结果必须要有参照系。我用同样的特征工程跑了一个朴素贝叶斯模型，它的准确率约为83.6%，略高于决策树。这个差异告诉我们一个重要的事实：在IMDB影评这种情感表达比较外露的文本上，线性模型或概率生成模型的天花板本身就高于单棵决策树。决策树的价值不在极限精度，而在于它提供了可解读的分类逻辑，以及一套完整的调参思路。如果你追求绝对准确率，那么后续可以考虑随机森林或梯度提升，它们的精度会明显超过朴素贝叶斯。

我把评估情况整理成一张表，方便项目报告里直接引用：

5.2 混淆矩阵与类别误判根源

混淆矩阵能帮我们看到具体错在哪里。在1万条测试样本上，我的模型把大约900条正向评论误判成了负向，另有1050条左右负向评论被误判成正向。负向样本被误判得稍微多一点，这说明模型对负向情感的学习略弱于正向。

为什么会这样？[图片仅供参考]吐槽类评论的表达方式其实更复杂。有很多负向影评用的是"反讽"，句子表面夸赞电影，实际在骂人。模型学习的是字面语义，对这种反讽的捕捉能力很弱。另一类负向评论使用"拐弯抹角的批评"，比如"视觉效果很好但剧情毫无逻辑"，这类评论里正向词和负向词同时密集出现，决策树在特征组合上虽然能抓一部分，但整体效果仍然有限。

要验证这一点，我把误判样本按文本长度做了分组统计，发现中长评论（150词以上）的误判率显著高于短评论。短评论大多表达直接，容易学；长评论包含多层次论述，模型必须依赖更多特征的联合判断，误判概率自然升高。

5.3 决策树可视化与规则提取

决策树最值得骄傲的功能就是可视化。Scikit-learn可以直接输出树的文本结构或者用Graphviz画成图，但深度12层的树画出来会很大，直接看图不现实。我的做法是限制深度到4层，单独画出一棵"解释用子树"，用来看清整体分类逻辑。

从子树里能读到清晰的分层判断规则。第一层分裂往往看的是“best”这类强情感词是否出现，第二层和第三层则围绕“worst”、“great”、“waste”等词展开。这种规则链就是模型学到的“情感语言直觉”的可视化表达：先找强情感词，再看上下文修饰，逐步逼近判断。

另一个很实用的操作是把整棵树通过feature_importances_输出为特征重要性列表，排序看看影响最大的都是哪类词。实测下来排在前列的几乎都是强情感形容词和动词，比如“great”、“worst”、“amazing”、“boring”。反而不太常见的“cinematography”这类技术词排得靠后。这符合直觉：普通观众写影评时大量使用强情感词，而技术细节词对情感判断帮助有限。

5.4 从错误案例中提炼边界

错误分析不应该停留在"模型错了"这个结论上，还要尝试回答"为什么错"。我挑了三条误判评论做细读，来感受模型的边界在哪里。

一条评论写的是"this movie is so bad it's almost good"。模型判断为正向，因为看到了"good"；但人类理解这里是反讽。词袋模型无法捕捉这种跨句语义的反转，任何基于离散词特征的模型在这里都会吃瘪。

另一条是"If you like slow dramas you will love this，but I was bored to death"。模型看到了"love"和"like"加成，判断成正向，实际上作者的态度是负面的。这种正负词高度共存的文本，需要依靠更长距离的依赖关系才能正确判断，从决策树的视角看确实无解。

还有一条误判来自拼写错误和网络俚语，比如"watchable"被写成"watchablee"。模型找不到有效特征，退而求其次猜了个结果。这提醒我们拼音和词干化的边界——如果项目中大量出现这种写法，就该考虑把它归一化处理。

这些错误案例成为整个项目里“最有收获的部分”，因为它们清楚划定了决策树在文本任务上的能力边界。换个角度说，这也是为什么工业界文本分类普遍使用深度学习模型——它们对长距离依赖和上下文语义的建模能力确实远超决策树。

6. 常见问题与排查技巧实录

6.1 特征维度膨胀与内存爆炸怎么办

高维稀疏矩阵是文本分类的常态。如果你发现内存占用涨到靠近极限，先查三件事：是否设置了max_features？ngram_range是不是设大了？是否在用稠密数组存储特征矩阵？

解决方案按优先级排序：

• 强制设置max_features，通常3000到10000之间能兼顾效果和开销；
• 降低n-gram范围，从(1, 3)回退到(1, 2)；
• 检查代码里是否无意中使用了.toarray()把稀疏矩阵转成稠密数组，这一步会在高维场景下直接让内存爆炸。

6.2 训练时间过长怎么加速

决策树在中等规模数据上本来应该很快，但如果你发现训练耗时异常增长，有几个排查方向：

• 特征维度过多时，决策树每次分裂扫描的特征数会很大，优先控制max_features；
• GridSearchCV的搜索空间太大，先手动粗粗试几个点位，锁定大致范围再细化；
• n_jobs=-1在多核机器上能显著加速交叉验证，但如果数据量大还开了很多折，内存占用会跟着涨，理性折中；
• 考虑把55000条训练数据缩减到30000条，先跑通流程，再上全量。

6.3 准确率上下浮动很大

如果你多次运行同样的代码，发现准确率在小数点后两位有抖动，别慌。这通常出自随机性：随机森林是显式的随机，单棵决策树也会因平分和特征采样的随机性产生细微差异。关键操作就是固定random_state，并采用固定的交叉验证划分方式。如果拿到结果之后想对比不同模型，它们也应该在完全相同的训练集和测试集划分上比较，不然任何结论都不具备说服力。

另外和数据划分方式相关的坑是关于“正负样本不均衡导致评估失真”的问题。IMDB这个数据集本身是均衡的，但如果你自己构造数据集时随意切片，就可能出现一组全正、一组全负的情况。这时务必启用StratifiedShuffleSplit或StratifiedKFold。

6.4 完整可复现的实验配置速查表

为了方便后续复跑或改造这个项目，我把整套配置做成了一张速查表：

7. 写在最后的个人体会

做完这个项目，我对“决策树到底适不适合文本分类”这个问题有了自己的答案。它绝不是这类任务的最优选——如果目标只是精度，朴素贝叶斯、逻辑回归、以及任意一个深度模型都能轻松把它甩开。但它非常适合用来建立直觉，让你清楚地看见“特征工程如何影响模型”、“过拟合如何出现并可以被控制”以及“参数之间如何协同作用”。这种对模型行为的感知能力，比多刷几个百分点的准确率更加珍贵。

另外还想单独强调一点：在这个项目里，最能立竿见影地提升效果的往往不是调参，而是特征工程。把n-gram从一元扩展到二元、把停用词策略从一个极端拉到另一个极端，带来的准确率波动远大于max_depth从10调到15。理解了这层关系，再看任何分类任务时，你一定会先把更多时间花在研究特征表达上，而不是急着跑网格搜索。

如果后续我想在这个项目上加料，我会从两个方向出发：一是对比随机森林和梯度提升树在同样特征工程下的表现，观察集成学习通过“平均化规则”是否能补足单棵树的泛化短板；二是引入预训练的词向量表示，看看把连续语义特征喂给树模型会碰撞出什么反应。这两个方向都能把这个项目的价值继续放大，也留给读者自己动手尝试。