企业官网建设流程全解析

简介：面向电商数据分析与自然语言处理学习者，这套Python源码包提供了电商产品评论情感分析的完整实现。资源以京东美的品牌评论为样本，数据挖掘算法贯穿分词、停用词过滤、情感极性判断与主题建模等环节，可帮助读者掌握从原始文本到情感结论的建模全过程。压缩包共22个文件，大小18.11MB，包含20个txt过程文本、1个CSV评论汇总数据和1个Python主脚本，txt文件按处理阶段划分，如正面/负面情感结果、LDA主题分析结果、自定义词典与停用词表等，便于按步骤对照学习每个数据挖掘环节的输入、输出及中间结果。目前已有4039人学习/下载，特别适合电商运营、数据分析和Python初学者用以上手实践；读者可借此理解情感分析模型的参数调整过程，并参考其代码与目录组织方式，迁移到其他商品评论场景，快速搭建自己的情感分析流程。其思路对课程设计、毕业项目或业务探索都很有参考价值。

1. 电商产品评论数据情感分析：一份能直接跑的 Python 源码包，从评论到正负面结论

做电商运营或者产品调研的朋友应该都有这种体验：一条商品链接下面几千条评论，好评差评混在一起，靠人工一条条读下去，眼睛花了不说，结论还容易受最近几条评论影响。电商产品评论数据情感分析要解决的，就是把这个黑匣子打开——用 Python 把评论批量读进来，分词、去停用词、按情感词典打分，最后输出正负面结论，再用 LDA 主题模型看看大家到底在夸什么、骂什么。这份源码包就是一套完整可复现的流程，数据用的是京东上某品牌产品的真实评论，适合想快速上手中文情感分析的 Python 开发者，也适合产品运营拿现成结果做参考。

2. 数据预处理链路：从京东原始评论到分词、去停用词，每个中间文件是什么

2.1 资源文件清单：txt 中间产物与 CSV 汇总表的分工

这份源码包解压之后，第一眼看上去文件数量不少，但按用途归类就清晰了：原始数据与汇总、预处理中间产物、词典与结果文件。先把所有文件的功能列成一张表，后面跑代码时可以对号入座。

我一般拿到别人分享的源码包，第一步不是直接跑，而是先顺着中间产物把流程倒推一遍。这里 meidi_jd.txt 是原始评论，process_1 到 process_3 是逐步清洗的痕迹，process_end 是最终喂给情感打分模块的文本，pos_cut 和 neg_cut 又是单独给 LDA 用的分词结果。文件命名能对上，说明原作者是一步一步落盘的，这种习惯值得学习——每个中间结果都留底，后面发现某一步出错，可以定位到对应文件，不用从头再跑。

huizong.csv 在这里扮演汇总表的角色，用 pandas 读进来之后可以做很多辅助分析。比如检查评论文本和评分配不匹配的样本：配了五星但文本在抱怨，或者配了一星却写了「好评」，这类样本恰好是情感分析最容易翻车的地方，因为文本情感和评分并不总是线性对应。csv 里常见的列有商品ID、评论内容、评分、评论时间、点赞数，读取时留意编码，pandas 默认 utf-8，如果文件是 GBK 保存的，要加 encoding="gbk"。

2.2 自定义词典与停用词表：让 jieba 分词贴合家电评论语境

中文情感分析绕不开分词，而通用分词器在特定领域里总会有不认识或切错的词。jieba 默认词典是通用语料训练的，遇到品牌名、产品型号、电商常用缩略语就很容易切碎。比如「美的」这种品牌词，如果不加干预，会被切成「美 / 的」，而「的」通常又在停用词表里，一个好好的品牌词就被吞掉了。myDict.txt 的作用就是把这些词以「词 + 词频 + 词性」的格式告诉 jieba，让它优先按整词切分。

myDict.txt 的格式是每行一个词，常见写法有三种：「词」「词 词频」「词 词频 词性」。词频越大，jieba 越倾向于保留整词而不是切开；词性可以写 n（名词）、v（动词）、a（形容词），情感分析场景里不强制要求，但写全了，后面如果要做词性过滤会省很多事。举个例子，如果词典里写「美的 100 n」，分词器会优先把「美的」当作一个名词整体输出。相比之下，三字段都写齐最稳，只写词一个字段也能生效，但词频默认值比较低，个别词可能还是会被切开。

stoplist.txt 和自定义词典是配套的。停用词过滤的是「的、了、是、我、你、它、在、有」这类高频但没有信息量的词。电商评论里还有一些特有噪声，比如「京东」「快递」「客服」这类词虽然不算虚词，但如果后续主题分析时不关注物流话题，也可以视情况加进停用词。我一般会把停用词分成两层：一层是语言通用停用词，像哈工大停用词表、百度停用词表；另一层是场景无关词，根据当前数据集的词频统计手工补充。两组合并后去重再写入 stoplist.txt。

这块有个血泪经验：自定义词典不是越多越好。词典里塞进去一个词，本质上是告诉分词器「别把这个词切开」，但如果这个词本身在文本里经常以别的含义出现，就会产生新的切分错误。比如把「小米」设为不可切分，那「小米粥」也会被切成一个词，而电商评论里未必有这种语义。所以词典里的词应该限定为品牌名、产品型号、领域术语，并且每次改完词典都要重新跑一遍分词抽样检查，确认没有引入新的搞笑切分。

2.3 预处理落地：清洗、分词、去停用词的代码与参数说明

预处理阶段的核心代码不长，但每个细节都影响后续情感打分的质量。以下是我习惯用的写法，和这份源码包的思路一致：

import re import jieba # 加载自定义词典，确保"美的"等品牌词不被切碎 jieba.load_userdict("myDict.txt") # 读取停用词表，构建集合便于快速查询 with open("stoplist.txt", encoding="utf-8") as f: stopwords = set(line.strip() for line in f if line.strip()) def clean_text(raw: str) -> str: # 去掉HTML标签、URL、多余空白 text = re.sub(r"<[^>]+>", "", raw) text = re.sub(r"https?://\S+", "", text) text = re.sub(r"\s+", " ", text) # 只保留中文、字母、数字，标点符号不要 text = re.sub(r"[^\u4e00-\u9fa5a-zA-Z0-9]", "", text) return text def cut_and_filter(raw: str): text = clean_text(raw) words = jieba.lcut(text) # 去停用词、去单字词（性别的"男/女"场景可保留） filtered = [w for w in words if w not in stopwords and len(w.strip()) > 1] return filtered # 示例：对原始评论文件逐行处理 with open("meidi_jd.txt", encoding="utf-8") as f: lines = [line.strip() for line in f if line.strip()] processed = [cut_and_filter(line) for line in lines] # 写中间产物，方便后续排查 with open("meidi_jd_process_3.txt", "w", encoding="utf-8") as f: for words in processed: f.write(" ".join(words) + "\n")

这里几个参数值得停下来解释。re.sub(r"[^\u4e00-\u9fa5a-zA-Z0-9]", "", text) 是清洗的关键一行，它只保留中文字符、英文字母和数字，逗号、句号、感叹号、表情符号全部过滤掉。情感打分阶段我不需要标点，保留反而会干扰程度副词的匹配；但以后要做句级情感分析，需要靠标点切分句子，这一行就要改写，把标点保留下来作为断句信号。len(w.strip()) > 1 是去掉单字词，中文里绝大多数单字虚词已经被停用词表覆盖，剩下的单字大多是噪声；但如果你分析的是「男/女」「好/坏」这种极短评论，这一行要改成 >= 1，否则信息全丢。

jieba.lcut() 返回的是 list，方便直接遍历。如果评论量特别大，可以换 jieba.lcut_for_search()，或者开启 jieba.enable_parallel()，但并行模式只对纯文本分词有效，会打乱结果顺序，我在情感分析场景里不推荐，因为后面的打分逻辑强依赖评论索引的对齐。还需要注意，jieba 分词结果里会混入一些空白和特殊符号，虽然 clean_text 已经过滤了大部分，但个别全角空格、不间断空格还是可能漏网，所以在 cut_and_filter 里用 len(w.strip()) > 1 顺手挡掉了。

预处理的分阶段落盘是我比较看重的一个习惯。process_1 存去重后的纯文本，process_2 存清洗后的文本，process_3 存分词结果，process_end 存带标签的最终数据。这样每一阶段的输出都可以单独检查，想看清洗有没有误删数字，看 process_2 就够了；想看分词有没有把品牌名切碎，看 process_3 就够了。从头到尾一步到位当然快，但出了问题定位起来特别痛苦，尤其是几千条评论的数据集，重跑一次也就几秒钟，多落几个中间文件非常划算。

3. 情感倾向判定：基于情感词典的评分机制与 code.py 核心逻辑

3.1 为什么不用现成库：词典打分在电商评论里的灵活性

中文情感分析最快的方式是 pip 装个 snownlp 或者调云端接口，直接给一句话返回积极/消极概率。但电商评论是典型的口语短文本，里面有大量「不太行」「一般般」「退货了」这种表达，通用模型很容易误判。更重要的是，现成库的判定逻辑是个黑匣子，你没法解释为什么这条被分到了负面。产品经理问你数据怎么来的，你总得能说出依据，这时候词典打分就有不可替代的优势。

这份源码包走的是词典打分路线：构建一个正向词表和一个负向词表，每个词带一个权重分数，评论里命中的正向词加分、负向词减分，最后看总分正负。这种做法虽然朴素，但胜在可解释、可调整——某个词判错了，直接改词典或权重就能修正，不需要重新训练模型。对几千条评论这个量级，词典打分的准确率完全够用，而且运行速度快，一条评论毫秒级出结果。

词典打分还有一个好处是跟业务松弛耦合。通用情感模型训练用的语料可能是影评、新闻或者微博，情感词分布和家电评论差很远。比如「静音」在通用语料里是中性词，但在空调评论里是强正向词；「生锈」在通用语料里出现频率很低，但在家电差评里是高频强负向词。情感词典自己维护，出现什么业务词就加什么词，准确率是跟着业务语料走的，不用等模型重训。

3.2 情感打分代码拆解：词典、否定词、程度副词如何组合

单纯的正负词加减很容易翻车，因为中文里否定词和程度副词会彻底改变语义。「不好」如果只按「好」是正向词来算，就会得正分，这显然不对。所以打分逻辑里必须有否定词处理和程度副词加权。下面是我按这个资源场景写的核心打分函数：

def sentiment_score(words, pos_dict, neg_dict, degree_dict, neg_words_set): score = 0.0 neg_flag = 1 # 连续否定词的奇偶性，奇数个否定取反 degree_weight = 1.0 # 当前命中的程度副词权重 for word in words: if word in neg_words_set: neg_flag = -neg_flag elif word in degree_dict: # 常见做法：程度副词只影响它后面紧邻的情感词 degree_weight = degree_dict[word] elif word in pos_dict: base = pos_dict[word] * degree_weight score += base if neg_flag == 1 else -base degree_weight = 1.0 neg_flag = 1 elif word in neg_dict: base = neg_dict[word] * degree_weight score -= base if neg_flag == 1 else -base degree_weight = 1.0 neg_flag = 1 return score

逻辑说明：这段代码有三个关键状态——neg_flag 记录否定词个数的奇偶性，degree_weight 记录程度副词的倍率，score 累计最终得分。遇到「不」就把 neg_flag 取反，遇到「很」「非常」就把倍率设为对应值，真正命中情感词时，用当前倍率乘基准分，再根据否定奇偶决定加还是减。选中一个情感词之后立刻重置状态，避免「不太好」的程度副词影响到下一个情感词。

参数说明：pos_dict 和 neg_dict 是每个词的基准分，正负分绝对值一般在 0.5~3 之间，比如「好用」=2.0，「垃圾」=-2.5，这个基准分建议单独建一个情感词典文件维护，不要硬编码在 code.py 里。degree_dict 的常用映射是「非常 1.8 / 很 1.5 / 有点 0.7 / 比较 1.2」，倍率直接决定强度差异。neg_words_set 是「不、没、没有、别、无」这类词。注意这个逻辑里有个简化——它假设情感词是独立的，没有处理「虽然好但是贵」这种转折句，但电商短评论里多数句子结构简单，这个简化可以接受。

这个函数的边界情况值得再说两句。连续两个否定词，比如「不是不好」，neg_flag 会变成 1，最终结果是正，这在语义上是对的（双重否定表肯定）。但「不太好」这种「不 + 太 + 好」的组合，代码执行顺序是：遇到「不」取反，遇到「太」设倍率，遇到「好」用倍率乘基准分再取反，最终得分是负值，表示「还算可以但不完美」。如果业务上把这类表达算作轻微负面，那么分数落在 -0.5 附近，还不足以进负面文件，这时要调阈值，而不是改代码。

3.3 结果文件解析：正面情感结果与负面情感结果怎么对齐

打分完成后，code.py 会把评论按得分正负拆成两个文件，也就是源码包里看到的 meidi_jd_process_end_正面情感结果.txt 和 meidi_jd_process_end_负面情感结果.txt。输出格式一般是「原始评论 + 得分 + 命中的情感词」，用制表符分隔，方便直接拉进 Excel 或者 pandas。

with open("meidi_jd_process_end_正面情感结果.txt", "w", encoding="utf-8") as f_pos: with open("meidi_jd_process_end_负面情感结果.txt", "w", encoding="utf-8") as f_neg: for text, words, s in zip(lines, processed, scores): if s >= 0.2: f_pos.write(f"{text}\t{s:.2f}\n") elif s <= -0.2: f_neg.write(f"{text}\t{s:.2f}\n")

这里有个重要参数：正负判定阈值。我写成 0.2 和 -0.2，而不是 0，是因为得分落在 -0.2~0.2 之间的评论大多是「还行」「一般」这类中性表达，硬分到正或负都会引入噪声。阈值设得越大，越倾向于只保留情感明确的评论，输出总量变少，但质量更高。如果只需要最典型的差评去处理售后，可以把负阈值调到 -0.5 以下，只留情感强烈的评论。

对齐两个文件时要注意索引别乱。code.py 里 scores 的顺序和 lines、processed 是严格一一对应的，但如果中途用多进程分词或者跳过某一行，索引就会错位。所以我在写文件时直接用 zip 打包原始文本、分词结果、得分，三个对象同进同出，后面核对某个差评的原始句子时不会查错行。还有一个小习惯：文件名里带中文没问题，但如果你要在 Linux 服务器上跑，文件名带中文在部分终端环境里会显示乱码，不影响读写，但建议输出英文文件名，比如 pos_result.txt / neg_result.txt，避免和终端编码较劲。

关于情感词典本身的构建，源码包里虽然只给了 myDict.txt 和 stoplist.txt，没有单独的情感词典文件，但常见做法是在 code.py 里用字典字面量定义 pos_dict 和 neg_dict，再配合一个增量文件维护。我习惯把情感词典拆成基础情感词和业务情感词两层：基础层是「好、坏、喜欢、讨厌」这类通用词，业务层是「静音、漏水、褪色、起球」这种领域词。拆开的好处是将来换品类，只需要换业务层，基础层不用动。

4. LDA 主题模型：把正负面评论各自聚成几个可读的主题

4.1 情感分类之后再挖主题的意义

情感分析告诉你「这条是好评、那条是差评」，但产品经理真正关心的是「用户为什么给好评、为什么给差评」。好评集中在「外观好看、送货快、静音」，差评集中在「噪音大、售后慢、有划痕」——这两类信息如果只停留在正负标签上，价值就浪费了。LDA 主题模型的价值在于，它用无监督的方式把一堆评论按词的共现概率聚成若干主题，每个主题对应一批高频共现词，你读词就能大致还原用户诉求。

源码包里 meidi_jd_pos_cut_LDA_result.txt 就是正面评论分词结果跑出来的主题输出，说明原作者的流程是：先情感分类，再对正负面分词结果分别做 LDA。为什么要分开做而不是对全量做？因为全量 LDA 出来的主题往往是「好评主题」和「差评主题」混在一起，区分度低；分开做之后，好评主题和差评主题各自内部更有区分度，解读起来也直白。

这里还要纠正一个常见误区：LDA 不是简单的词频统计。词频统计只能告诉你「声音」出现 200 次、「安装」出现 150 次，但 LDA 会告诉你「声音 + 大 + 晚上 + 吵」经常一起出现在同一类评论里，而「安装 + 师傅 + 热情 + 上门」是另一类。它捕捉的是词与词之间的共现结构，所以读主题时看的是词的组合，不是单个词的频次。

4.2 LDA 的输入文件与参数设置：主题数、迭代次数怎么定

LDA 的输入是每行一个文档、词与词之间用空格分隔的文本，这正是 meidi_jd_pos_cut.txt 和 meidi_jd_neg_cut.txt 的格式。我常用的实现是 sklearn 的 LatentDirichletAllocation，配合 CountVectorizer 做词频矩阵：

from sklearn.feature_extraction.text import CountVectorizer from sklearn.decomposition import LatentDirichletAllocation # 读取正面评论的分词结果，每行是一个评论 with open("meidi_jd_pos_cut.txt", encoding="utf-8") as f: texts = [line.strip() for line in f if line.strip()] # 构建文档-词频矩阵 vectorizer = CountVectorizer(token_pattern=r"(?u)\b\w+\b") dtm = vectorizer.fit_transform(texts) # 主题数取 5，批次模式更稳定，固定随机种子保证可复现 lda = LatentDirichletAllocation( n_components=5, learning_method="batch", random_state=42, max_iter=20 ) lda.fit(dtm) # 输出每个主题的前 10 个词 feature_names = vectorizer.get_feature_names_out() for topic_idx, topic in enumerate(lda.components_): top_words = [feature_names[i] for i in topic.argsort()[:-11:-1]] print(f"Topic {topic_idx}: {' '.join(top_words)}")

参数说明在这块特别重要。n_components=5 是主题数，设多少没有标准答案，我一般从 3 试到 10，看完每个主题的词分布再决定——如果某个主题的词混杂了多个互不相干的语义，说明主题数不合适。learning_method 我选 "batch"，因为电商评论量级通常在几千到几万条，batch 模式全局优化更稳定；文档量上百万时才考虑 "online"。random_state=42 是必须写的，否则每次跑出来的主题词都不一样，后面写报告没法交代。max_iter 默认值是 10，但对短文本我习惯提到 20 以上，迭代不足时主题词会偏通用高频词。

提到 gensim，它是另一个常用的 LDA 工具，和 sklearn 的差别主要体现在文档格式和迭代实现上。gensim 需要先把分词文本转成词袋向量，再用语料库对象训练，优点是支持流式读取大语料，缺点是接口比 sklearn 繁琐、参数更多。对这份资源的评论量级，我倾向 sklearn 版，代码短、结果稳定，而且和 pandas、numpy 的配合更顺；只有当你需要跑几十万篇文档、内存吃紧时，再切 gensim 不迟。

还有一个参数容易踩坑：CountVectorizer 的 min_df。默认值是 1，也就是出现一次的词也会进词频矩阵，但评论里的低频错别字和极端个性化表达会对 LDA 产生干扰。我一般把 min_df 设为 3 或 5，表示至少在 3 条或 5 条评论里出现过的词才保留，主题词会干净很多。对应的 max_df 可以设为 0.8，过滤掉出现在 80% 以上的词，防止「东西」「感觉」这种过于通用的词霸占主题。

4.3 主题结果可读化：从词分布反推用户诉求

源码包的 meidi_jd_pos_cut_LDA_result.txt 输出格式大致是每个主题一行，冒号后面跟着排序后的词分布。读的时候不要只看第一个词，要看前 5~10 个词的组合。比如某主题前 5 个词是「安装、师傅、热情、上门、很快」，那基本可以断定这个主题是「安装服务」；如果前 5 个词是「声音、大、晚上、吵、静音」，那主题就是「噪音问题」。

主题词分布的解读还有个常用技巧：把同一主题内的词按权重排序后，前 3 个词决定主题的「骨架」，后面 7 个词决定主题的「细节」。如果主题之间前 3 个词重复度超过一半，说明主题数设少了，需要调大 n_components 重新跑；如果某个主题只剩「东西、感觉、真的」这种万能词，说明停用词表没过滤干净，回到 2.2 节把这些词加到 stoplist.txt，重跑预处理再进 LDA。

对负向评论的主题解读要更注意语气。差评里「售后、客服、不理、退款」可能被聚成一个主题，但这不代表所有差评都指向售后，可能只是售后相关的词在差评里天然高频。我拿到负向主题后通常会回到原始评论里抽几条看过，确认主题词的组合真的能代表一类用户诉求，再把这个主题写进结论。这一步不做，很容易把统计巧合当成业务洞察。

负向主题的输出文件虽然没有单独命名在源码包里，但套路是完全对称的，用 meidi_jd_neg_cut.txt 跑一遍同样的代码就能得到。我把正负主题放在一起对比时，经常发现一个有意思的现象：好评主题里有「静音」的正面表达，差评主题里有「声音大」的负面表达，两个主题指向同一个产品特性。这种正反对照比单看一侧更接近用户的真实评价结构，写分析报告时也更有说服力。

5. 踩坑与排查：中文编码、分词边界、情感阈值的五个真实问题

5.1 读取 txt 文件全是乱码

现象：打开 meidi_jd.txt 或者任意 process 文件，中文字符全是锟斤拷或者问号，英文和数字正常。

原因：文件保存编码是 GBK 或者 GB18030，而代码里用 encoding="utf-8" 读取。Windows 上常用 GBK，Linux/Mac 上默认 UTF-8，跨环境拷贝后最容易碰到。还有一个隐蔽场景：文件本身是 UTF-8，但你在 Windows 记事本里另存为 ANSI 编码，再拿回 Python 里读就会乱。

解决：代码里读取时指定 encoding="gb18030" 试一遍，或者用 VS Code 打开文件、在右下角切换编码查看文件真实编码。我一般把所有中间文件统一转成 UTF-8 落盘，后续所有代码固定 encoding="utf-8"，省得每次猜。批量转码用一小段脚本：

for fname in ["meidi_jd.txt", "meidi_jd_process_1.txt", "meidi_jd.txt"]: with open(fname, encoding="gb18030") as f: content = f.read() with open(fname, "w", encoding="utf-8") as f: f.write(content)

如果 gb18030 也报 UnicodeDecodeError，那可能是文件里混入了二进制噪声，可以用 errors="ignore" 暂时跳过，但要注意这样会丢字符。更稳的做法是先用文本工具看文件头几个字节，判断有没有 BOM——UTF-8 带 BOM 的文件，第一行会多出 \ufeff，处理时用 encoding="utf-8-sig" 读即可。这个小坑很容易卡人。

5.2 品牌词被拆散：「美的」被分成「美」和「的」

现象：分词结果里看不到「美的」这个整词，取而代之的是「美」「的」，后续情感打分和主题分析里这个词等于失效。

原因：jieba 默认词典里「美的」的词频较低，或者压根没有收录，分词器按通用规则切开了。

解决：确认 myDict.txt 里包含「美的」，并且代码里在 jieba 分词前调用了 jieba.load_userdict("myDict.txt")。注意自定义词典文件的编码也必须是 UTF-8，否则加载时会报错或者部分词加载失败。加载后可以用 jieba.lcut("美的空调很好用") 验证输出是否为「美的 / 空调 / 好用」。如果还是被切开，把 myDict.txt 里这个词的词频调大，比如从 100 改成 1000，强制保留整词。

验证分词结果是很容易被跳过的一步。我每次改完词典都会随手敲一行测试，看看品牌词、产品型号词是否按预期输出。这里有个细节：jieba.load_userdict() 在一个进程里重复加载相同路径不会覆盖，如果你改了 myDict.txt 但没重启 Python 进程，新词典不会生效。所以调试词典时最好重新启动脚本，或者把加载逻辑独立成函数，每次调试前重新调用并确认加载状态。

5.3 正面结果数量远大于负面，判定失衡

现象：跑完情感分析，正面结果文件几千行，负面结果只有几百行，和人工眼看评论区的差评比例对不上。

原因：电商平台的评论本身就有晒单引导，好评比例天然偏高；另一个原因是阈值设得太严，大量得分在 -0.2~0 之间的轻微差评被丢掉，这批评论恰恰是「还行吧但有点问题」的潜在流失用户。

解决：先把负阈值放宽到 -0.1 看看总量变化；如果仍然偏少，检查情感词典里负向词是否覆盖了「漏、渗水、掉漆、生锈、退款」这类具体问题词——很多差评用的是非常具体的动词和名词，通用负向词表里根本没有。还有一个容易被忽略的点：差评里往往带着「但是」「就是」这类转折词，如果词典里没把转折后的负向内容抽出来，整条评论会被误判成中性。

我排查这类问题时有个固定动作：把得分落在最中间的 20 条评论打印出来逐条读。如果这 20 条里有 15 条人工读起来其实是差评，那就不是阈值问题，是词典覆盖问题。反过来，如果中间区间大多是「还行」「一般般」，那调阈值就能解决。先定位问题再调参，比盲目放宽阈值有效得多。

5.4 LDA 结果全是「的、了、我」这类无意义词

现象：跑出来的每个主题前 10 个词都是一样的「的、了、我、是、就」，主题之间完全没有区分。

原因：预处理时没有去停用词，或者停用词表太薄，LDA 把高频虚词当成了主题特征。

解决：回到 2.3 的 cut_and_filter 流程，确认每个词都过了 stopwords 过滤，并且把「的、了、我、你、它、就、都」这类词补进 stoplist.txt。主题词里如果还残留「东西、感觉、真的」这类词，说明这部分也需要手动加进停用词。这个坑的本质是：LDA 只能发现词共现模式，没法判断词有没有语义，清洗不到位它就给你一个全是虚词的主题。

另一个和停用词相关的坑是：LDA 的输入文件 meidi_jd_pos_cut.txt 是分词后的结果，如果你直接拿原始评论文件去跑 LDA，CountVectorizer 会按字符切分，得到的是单个汉字而不是词，主题自然没法读。所以 LDA 之前必须先经过 jieba 分词，而且要确认输入文件里词与词之间用空格分隔。检查方法很简单：head 看几行，如果看到「美的 空调 很好 用」就是对的，看到「美的空调很好用」就是没过分词。

5.5 运行 code.py 提示 ModuleNotFoundError

现象：命令行跑 code.py，报 ModuleNotFoundError: No module named 'jieba' 或者 'sklearn'。

原因：当前 Python 环境里没装依赖。源码包里「导入模块说明.txt」列了依赖清单，但很多人直接双击运行，或者换了一个虚拟环境就忘记了。

解决：按清单安装，常用的组合是 jieba、pandas、sklearn、numpy。我习惯先在项目目录建虚拟环境再安装：

python -m venv venv source venv/bin/activate pip install jieba pandas scikit-learn numpy

安装完用 pip list 确认识别到版本，再跑 code.py。有个容易忽略的点：系统里同时装 Python 2 和 Python 3 时，直接敲 python 可能跑的是旧版本，建议用 python3 显式指定，或者激活虚拟环境后操作。另外 pip 安装慢的话，可以加清华镜像源：pip install -i https://pypi.tuna.tsinghua.edu.cn/simple 包名，速度会快很多。

如果安装了还是提示找不到模块，检查一下你是不是在虚拟环境里安装，却在虚拟环境外运行，或者 IDE 解释器路径没有切到 venv。这个坑的本质是环境路径不一致，用 python -c "import jieba; print(jieba.version)" 验证当前解释器能看到哪些包，比反复重装更高效。

6. 跑通之后更关键的一步：用抽样标注验证情感分析效果

6.1 人工标注 100 条评论做一致性对比

代码跑通、结果文件出来后，先别急着出报告。情感分析的准确性不是看代码跑没跑完，而是看结论和真实情况吻不吻合。我每次都会从正面、负面结果里各随机抽 50 条，自己或找同事人工标一遍正负，然后算一致率。如果一致率低于 80%，不用怀疑人工标错了，大概率是词典或阈值还有问题。

6.2 迭代词典与阈值的一个具体做法

抽样的价值是暴露边界案例。某条评论被机器标成负面，但人工读起来是中性，那多半是负向词典里某个词的基准分太高，或者否定词逻辑没覆盖到「不是特别满意」这种递进表达。我的做法是维护一个增量修改清单：每轮抽样后，把判错的评论归类——是词典缺词、权重错、还是阈值边界问题，三类问题分别修，修完重跑，再抽 100 条验证。两三轮之后一致率通常能上 85%。

6.3 固定随机种子，让结果可复现

最后也是我最在意的一个习惯：LDA 这类算法有随机性，报告里写的主题词分布，换个随机种子可能就不一样了。所以我每次跑正式结果前，强制在代码里固定 random_state 参数，并且把跑完的中间文件、结果文件按日期归档一份，文件名带上「数据版本 + 词典版本 + 阈值 + 随机种子」，比如 meidi_pos_lda_t5_seed42_20250115.txt。这份源码包里的 code.py、myDict.txt、stoplist.txt 和全套中间文件下载后，按 2.3 的代码顺序过一遍就能复现整个分析链路。从那以后，我每次做情感分析都会强制走一遍「抽 100 条标注验证 → 修改词典/阈值 → 固定随机种子归档结果」的流程，没有这个验证环节的结果我都不敢直接发出去。希望帮到你。

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