三年前我接手过一个母婴品牌的评价分析项目，团队当时已经用上了微调过的 BERT 模型，离线测试 F1 做到 0.89，技术答辩很漂亮。但上线三个月后，运营负责人跟我说了一句让我印象很深的话：“你们的准确率我不关心，我只想知道这周哪三个 SKU 的差评在变多、原因是什么、要不要改详情页。”问题根本不在模型，而在选型那一刻就没人问过：这份分析结果最终是谁在看、看完要做什么决定。
这就是“商品分析方案设计：用户评价场景的选型方法怎么做”这个问题的真实重量。它不是一道技术选型题，而是一道组织决策题。你选的不是模型，而是把一堆口语化、带情绪、混杂多语言的评论文本，转换成某个具体角色能在 24 小时内执行的动作。
我把过去几年经手的十来个评价分析项目复盘了一遍，包括自建 NLP 管线、采购第三方工具、以及后来在跨境电商场景里用数跨境这类平台做落地。下面这篇会按“先给结论、再讲场景、拆误区、给判断框架、上案例、给建议、讲取舍”的顺序讲清楚，尽量少讲正确的废话。读完你应该能自己画出一张属于你业务的选型决策图，而不是收藏一堆模型对比表。
如果你只在这篇文章里带走一句话，那就是这句：用户评价场景的选型，第一顺位是“输出物”，第二顺位是“约束条件”，最后才是“方法”。绝大多数选型失败的项目，不是选错了模型，而是把这三个东西的顺序做反了。
所谓输出物，不是“一份情感分析报告”，而是“谁在什么时间点、看到什么信息、做什么决定”。这句话听起来像废话，但它会直接决定后面所有技术选择。
比如同样是评价分析，“每周五给商品运营一份 TOP20 差评主题清单，用于下周改详情页”和“实时监控新上架 SKU 的前 50 条评价，异常时 2 小时内告警给客服主管”，这两个输出物对应的选型几乎完全不重叠。前者可以容忍 T+1 的批量处理、可以用定期跑的离线任务；后者必须要增量采集、低延迟判定、还要有误报控制机制，不然客服会被垃圾告警淹没。
我见过太多团队上来就问“用哪个模型”，然后花了两个月调出一个 0.9 的模型，结果发现运营要的只是“按 SKU 统计负面关键词频次”，一个正则加词典两天就能做完。选型最大的浪费，是用技术复杂度去覆盖一个本来就不复杂的决策需求。
输出物确定之后，还有三个约束必须在选型前写进文档，否则中途一定会反复改需求。
这三条里任何一条没定，后面选的方法都有大概率的返工风险。我把两个方向的项目做过对比：先定输出物再选方法的项目，平均需求返工次数不到 1 次；先选工具再补需求说明的项目，返工次数接近 3 次，而且多数返工集中在标签体系推翻重建上。
在实际项目里，我会让团队先填下面这张表。填不满的格子，就是还没准备好做选型的地方。
| 优先级 | 要回答的问题 | 填不出来的后果 |
|---|---|---|
| P0 | 输出物是什么，谁消费，多久一次 | 方案永远在改，无法验收 |
| P0 | 评价数据的量级、字段、历史标注情况 | 选型上限被高估或低估 |
| P1 | 时效要求是 T+1、小时级还是实时 | 架构选错，成本差 5 到 10 倍 |
| P1 | 标签体系由谁定义、谁维护 | 模型无监督目标，效果无法评估 |
| P2 | 团队现在会什么、能维护什么 | 方案上线即失维 |
| P2 | 预算口径是人力预算还是采购预算 | 自建与采购之间反复摇摆 |
很多人对评价数据的想象是“一段文字加一个星级”。实际打开数据表你会发现，它是电商体系里最脏、最不规整、也最有信息量的数据之一。选型之前不看清原料，后面所有方法讨论都是空转。
第一，长度极端不均。中文电商平台的评价大量集中在 10 到 40 字，而跨境平台上的英文 review 常常超过 300 个字符，部分带图评价甚至接近千字。同一套切词和特征工程策略，在两个平台上表现差异很大。
第二，表达高度口语化且带噪声。错别字、拼音缩写、emoji、颜文字、方言表述、重复刷屏同时存在。我做过一个抽样，某服饰类目 3000 条中文评价里，含 emoji 或非常规符号的占比超过 41%，直接去掉符号会丢情绪强度，全部保留又会污染词表。
第三，反讽与转折普遍。“质量真好，用三天就坏了”“包装很用心，可惜东西不行”。这类句子在通用情感词典里经常被判为正面，因为正面词密度更高。这也是为什么直接用开源情感分析工具做评价监测，负面召回常常低得离谱。
第四，时间与业务对象不对齐。评价的发布时间不等于购买时间，追评字段又常常是负面情绪的集中区。如果你按发布时间做趋势分析，会看到莫名其妙的波峰，其实那是上一批订单集中追评。
第五，分布极度长尾。通常 20% 的热销 SKU 承载了 80% 以上的评价量。这意味着任何按 SKU 平权的分析都会失真，必须做量级加权。
这是我反复跟团队强调的一句判断：评价分析的效果上限，在数据采集和结构化阶段就已经被决定了，模型只是把这个上限逼近。
如果你的数据只有“一段文本 + 星级 + 时间”，那你能做的是主题、情绪、关键词方向；如果你还能拿到 SKU、订单属性、退货原因、客服工单，那你就能做归因和闭环，价值量级完全不同。很多团队把精力全花在模型调参上，却从没想过去打通退货原因字段，这是典型的选型资源错配。
我一般把数据就绪度分成四档：只有原始文本是一档；文本加星级加时间是二档；能挂到 SKU 和订单是三档；能挂到退货、客服、复购是四档。三档以下，不要碰需要精细归因的方案，做了也解释不清楚。
还有一个常被忽略的变量是品类。3C 类目的评价偏向功能描述和故障反馈，关键词集中，规则和词典方法就能拿到相当不错的召回；美妆个护的评价偏向主观感受和肤质描述，同一个词“刺激”在不同人群里含义完全不同，必须依赖上下文；服饰类目的评价有极高比例集中在尺码和色差，主题极其收敛，反而是最容易做好的场景。
所以在选型讨论里，我第一句会问“你是什么品类”，而不是“你数据量多大”。品类决定了语义复杂度，语义复杂度决定了方法的复杂度下限。
下面这四个误区，我在几乎每一个评价分析项目里都至少遇到两个。它们的共同点不是技术错误，而是判断顺序的错误。
很多团队选型的第一个动作是拿几个开源模型跑一遍 benchmark，然后按准确率排序。这是典型的用通用数据集的成绩去预测领域场景的表现。
公开情感数据集里的句子多为规范的影评、微博、新闻评论，而电商评价是目标导向的消费反馈，词汇分布差异极大。“很值”“发货快”“客服nice”这类高频评价在通用语料里几乎没有对应样本，模型迁移过来会掉点，而且掉得最狠的正是最需要识别的那部分，轻度负面和反讽。
更关键的是，准确率本身不是业务关注的量。业务想减少的是“漏掉的负面评价”，这是一个召回问题，不是一个整体准确率问题。我通常建议把评估指标换成：负面召回率、高优先级问题漏报率、标签一致性。这三个指标才和后续动作挂钩。
标签体系是评价分析里最贵的东西，也是最容易被当成“顺手定义一下就行的东西”。一个典型的翻车过程是这样的：项目启动时业务方热情很高，一口气定义了 60 个标签，覆盖物流、包装、质量、客服、价格、尺码、色差、气味、使用感受等等。三个月后真正被消费的标签不到 8 个，剩下的因为样本太少无法训练，自然死亡。
我的经验阈值是：首次上线，标签数量控制在 6 到 10 个，而且每个标签在样本里至少有 300 条以上的正例。低于这个数，任何监督方法都学不出稳定边界；高于这个数，业务方自己也记不住、用不起来。
另外，标签必须有明确的排他规则。买过项目的人都知道，“物流慢”和“客服响应慢”在一条抱怨里常常同时出现，如果没有优先级判定，同一批数据会被两条标签同时吃掉，导致后续统计翻倍。
F1、准确率、AUC 都是过程指标，不是结果指标。真正能证明方案价值的，是“负面评价从出现到被响应的天数”“高优先级问题的闭环率”“基于评价改版后的详情页转化变化”。
我经手的一个项目，模型 F1 从 0.82 提升到 0.91 花了整整六周，但因为一直没有打通告警链路，负面评价的平均响应时间停留在 11 天，业务方根本不觉得方案有价值。后来把精力转到流程串联上，两周就把响应时间压到 2 天，业务方的评价立刻变了。选型时如果只盯模型指标，你会优化一个业务并不感知的数字。
很少有团队在选型文档里写下“如果这个方案在三个月后不达预期，我们退回到什么状态”。结果就是模型一旦上线，没人敢动，效果衰减也只能硬扛。
回退预案要写清楚三件事：退回到哪一版、退回的触发条件是什么、退回后业务侧怎么继续运转。哪怕只是“退回关键词看板 + 人工抽检”，也比没有预案强。评价数据会有季节性波动、平台规则会变、商品结构会变，一套方案用两年不迭代是不现实的。
把误区排除之后，可以进入正向的选型逻辑了。我用的框架是：先用五个维度给场景打分，再从四类方法里筛出候选集，最后用小样本验证收敛到一种。
这五个维度我建议都做 1 到 5 分打分，不是为了算出一个总分，而是为了看清楚场景到底卡在哪一维。
打完之后你通常会看到一个很典型的形态：数据就绪度和团队能力得分低，语义复杂度和时效要求得分高。这种组合是最危险的，它意味着你想要一个高精度的实时方案，但你没有支撑它的数据基础和人力。这时候正确的动作不是硬上，而是先把得分低的维度补上来，或者把要求降下来。
下面这张表是我在项目沟通里最常用的对照表，刻意用了区间而不是单点，因为任何方法的效果都高度依赖数据和调优。
| 方法 | 数据需求 | 典型效果区间 | 冷启动速度 | 可解释性 | 适用边界 |
|---|---|---|---|---|---|
| 规则 + 词典 + 关键词 | 极少，几十条种子词即可 | 召回 60% 到 80%，精度不稳定 | 1 到 3 天 | 极强 | 品类收敛、关键词集中、需要快速上线 |
| 传统机器学习 (TF-IDF + LR / FastText) | 每标签 300 条以上标注 | F1 常见 0.75 到 0.85 | 1 到 2 周 | 中等 | 标签明确、样本均衡、需要稳定可复现 |
| 预训练模型微调 (BERT 系) | 每标签 1000 条以上标注 | F1 常见 0.85 到 0.92 | 3 到 6 周 | 弱 | 语义复杂、反讽多、有算法团队常驻 |
| 大模型 Prompt / 少样本 | 每标签 10 到 50 条示例 | F1 常见 0.72 到 0.88，波动较大 | 1 到 5 天 | 中等 | 快速验证、标签频繁变动、长尾场景补充 |
这里我要说一个很多人不愿意听的判断：在评价分析这个场景里，预训练模型微调并不总是最优解，尤其在标签体系还会变的早期阶段。因为微调的成本不只在训练，而在标注和后续每次标签调整时的重训。标签一变，标注要重做，模型要重训，整个链路要重新验证。反过来，规则和大模型 Prompt 方案在标签变动时的边际成本低得多。
把五个维度和四类方法组合起来，就形成了一个可以照着走的决策路径。我在每个项目里都会把它画出来贴在群里，避免讨论跑偏。
走完这四步，候选集通常只剩一到两个方案。这时候不要靠讨论决定，直接做小样本验证。
小样本验证是整个选型流程里性价比最高的一步，但很多团队要么不做，要么做错。做错的方式是：随机抽 500 条，跑一遍，看个大概，然后凭感觉选。正确的做法有明确的规格。
样本必须分层抽。负面、中性、正面按真实比例抽，同时对长尾 SKU 做超额采样，否则热销品的评价会淹没一切。我通常按“负面 40%、中性 30%、正面 30%”做分层，因为负面样本才是业务真正要用的部分。
评估要盲标。两个人独立标注这 500 条，算一致性。如果两人一致性低于 0.75，说明标签定义本身有歧义，先改定义，不要怪模型。
下面是我常用的一个评估脚本骨架，用来对比多个方案在同一批样本上的表现。重点不是代码本身，而是评估口径的固定。
import pandas as pd
from sklearn.metrics import precision_recall_fscore_support
samples: 500 条分层抽样评价，含人工标注 label
preds: 字典，键为方案名，值为该方案对同一批样本的预测结果
samples = pd.read_csv("eval_samples_500.csv")
preds = {
"rule_dict": pd.read_csv("pred_rule.csv")["label"],
"tfidf_lr": pd.read_csv("pred_tfidf.csv")["label"],
"llm_prompt": pd.read_csv("pred_llm.csv")["label"],
}
for name, pred in preds.items():
p, r, f1, _ = precision_recall_fscore_support(
samples["label"], pred, average="macro", zero_division=0
)
print(f"{name}: precision={p:.3f} recall={r:.3f} f1={f1:.3f}")选型阶段的验证不要只看宏观 F1，要把负面标签单独拎出来看召回。我判断一个方案是否可用的硬标准是：负面召回不低于 0.80，高优先级问题漏报率不高于 5%。这两个数字过不了，后面的成本讨论都没有意义。
前面讲的都是方法论。这一节我用一个具体的落地场景说明它在真实环境里长什么样，以跨境电商的评价分析为例，工具侧我用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ）做过完整的链路搭建和测试。
跨境电商的评价数据比国内电商复杂一档，原因有三个。
第一是多平台异构。亚马逊、Shopee、TikTok Shop、Temu 等平台的评价字段、星级体系、图片视频支持度、审核规则都不一样，同一件商品在不同平台上的评价必须合并到一个 SKU 口径下才有分析价值。
第二是多语言与翻译损耗。评价原文包含英、德、法、西、日、泰等多种语言，翻译成中文后再做情感分析，口语情绪和程度副词会大量丢失。我做过对照，同一批德语评价，直译后做情感判定，中性判定比例比在原文上处理高出约 17 个百分点，属于典型的翻译带来的“情绪抹平”。
第三是退货与评价不同步。跨境退货周期长，评价往往先于退货数据产生，做归因时两条链路的时间窗口对不上。这意味着选型时必须考虑“先发现问题、后验证问题”的两阶段设计，不能指望一次性闭环。
这一层是最枯燥但最容易出错的。我在测试时踩过的坑包括：平台的评价时间用的是站点当地时间，直接合并会出现时间错序；同一个商品在不同站点的 ASIN/商品 ID 不同，需要建立映射表；图片评价里的文字信息在多数平台不提供 OCR 结果，需要额外处理。
数跨境在这层的处理方式是提供多平台数据接入和统一的 SKU 映射配置，把评价、订单、广告、库存等数据拉到同一个分析模型里。它真正省事的地方不是采集本身，而是把“评价挂到 SKU 和订单”这件在国内电商里理所当然、在跨境场景里非常麻烦的事做成了预置能力。这直接决定了你后面能不能做归因，而不是只能做关键词云。
我在这层的建议是：无论用什么工具，在开工前先把字段映射表列出来，至少包含平台、站点、SKU、评价 ID、原文语言、评价原文、翻译文本、星级、评价时间、是否追评、是否带图、是否已验证购买。这 12 个字段决定了后续所有分析的可能性。
在分析层，我不建议一上来就做精细情感分类，而是先跑三条粗线，把业务方的注意力拉进来。
第一条是主题线。对评价文本做主题聚合，输出 TOP15 到 TOP20 的高频主题及其情绪倾向。这一步不需要高精度模型，分词加聚类加人工命名就够了，目的是让运营第一眼看到“我的商品究竟在被抱怨什么”。
第二条是评分线。按 SKU 和站点看评分趋势，重点是斜率而不是绝对值。绝对分低的商品可能一直低，不需要救；分数在近 30 天快速下滑的商品才是要立刻介入的。
第三条是 SKU 线。把主题和评分挂到 SKU 上，按量级加权排序，输出“问题严重度”榜单。这一条线的作用是把前两条的分析结果压缩成一个可执行的待办清单。
数跨境在这三条线上提供了评价洞察类的预置分析模板，主题分布、评分趋势、SKU 对比都能直接出图。我实际用下来，最有价值的是它的商品维度下钻：从整体评分趋势点进去，能一层层下到具体站点、具体 SKU、具体主题，这比在一个大表里自己筛要快很多。
输出层是多数评价分析项目死掉的地方。分析做完了，没人用。我的做法是把输出物固定成三样东西，缺一不可。
这里强调一个判断：评价分析的输出物必须是“可以被排进别人日程表的东西”，而不是一份报告。报告没人看，待办有人做。
下面这组数据来自我在一个多站点家居类目上的实施观察，属脱敏口径，量级做过模糊处理，用于说明改进方向而非精确值。
| 指标 | 实施前 | 实施后 | 变化说明 |
|---|---|---|---|
| 差评发现时效 | 14 天 | 2 天 | 从运营季度盘点变为周度清单加异常告警 |
| 运营看评价工时 | 12 小时/周 | 2.5 小时/周 | 从人工翻页变为看主题榜单 |
| 评价主题覆盖率 | 无体系 | 覆盖 87% 的负面评价 | 剩余 13% 为语义模糊或信息不足样本 |
| 详情页改版依据完整度 | 凭经验 | 基于 TOP5 主题 | 每次改版都能追溯到具体评价样本 |
方法论讲完，落到具体场景。我按业务规模和维护能力分成四种典型情况，每种给出可以直接执行的建议。
这个阶段最忌讳的是上模型。你的评价量撑不起训练，也没有人力维护。
这个阶段的目标不是精准，是建立“看评价、有反馈”的节奏。节奏一旦建立，后面升级方案才有人接。
这个区间是最容易产生价值跃迁的。评价量足够训练，人力也能支撑一套轻量管线。
如果这个阶段还涉及跨境多平台，我更建议直接采购成熟平台而不是自建采集。像数跨境这类工具在多平台接入和 SKU 映射上的积累，自建团队要复现通常需要几个月，而且平台接口规则变动频繁，维护成本会持续消耗。
到这个量级，选型要开始考虑分层处理，而不是指望一个模型搞定所有事情。
这个分层设计的核心逻辑是成本控制。把高成本方法用在真正需要的样本上，而不是全量铺开，通常能省下 60% 以上的推理成本，而效果损失可以控制在 2 个百分点以内。
冷启动的正确顺序是反过来的：先做无监督探索，再做有监督定义。
跳过第一步直接定义标签，是冷启动项目最常犯的错误。你对业务的想象和评价里真实存在的问题，往往不是一回事。
选型做完之后，还有几组躲不开的取舍。它们没有标准答案，只有和你场景匹配的答案。
模型越复杂，精度通常越高，可解释性越差。这在评价分析里代价很大，因为运营需要知道“为什么这条评价被判为负面”，才能决定怎么回应。
我的处理方式是分场景取舍：面向运营行动的标签，优先可解释性；面向管理层的趋势判断，可以接受精度优先。前者用规则加轻量模型，后者可以上微调模型。两者并存，不要强求统一。
自建的优点是灵活、可深度定制、数据不出内网；缺点是平台接口维护、多语言处理、可视化搭建这些隐性成本极高，而且会持续消耗人力。
一个粗略的判断标准：如果评价分析不是你的核心竞争力，且团队规模在 5 人以下，优先采购。把你的工程师放在业务逻辑和归因分析上，比放在采集接口适配上有价值得多。
实时监控听起来很美好，但成本是非线性的。从 T+1 提到小时级，通常是 2 到 3 倍成本；从小时级提到分钟级，可能是 8 到 10 倍，而且还要处理乱序、重复、延迟到达的问题。
我的建议是分商品分层：新品和主推款走小时级或更高频，长尾商品走 T+1 甚至周度。全量实时在绝大多数业务里都是过度设计。
单一模型的好处是链路简单、好维护；组合方案的好处是各取所长，但引入了一致性问题，不同模块对同一条评价的判断可能冲突。
如果要上组合方案，必须提前定义冲突解决规则，比如按置信度取高者、按优先级标签覆盖、或者设置人工复核队列。没有冲突规则的多模型方案，通常会在三个月内变成一个没人敢解释的黑箱。
回到最开始那个问题。那位运营负责人要的不是 0.89 的 F1，他要的是“这周哪三个 SKU 的差评在变多、原因是什么、要不要改详情页”。用户评价场景的选型方法，本质上是把这句话翻译成一套技术约束，而不是反过来让业务去适应技术。
我把整篇文章的判断压缩成几条可以直接用的结论。选型的第一顺位是输出物，不是模型；数据就绪度决定效果上限，模型只负责逼近上限；标签体系比模型更贵，首次上线控制在 6 到 10 个；小样本验证用 500 条分层样本，负面召回不低于 0.80 才谈后续；输出物必须是能被排进别人日程表的待办，不是报告。
还有一个我越来越确信的判断：评价分析的选型不是一次性决策，而是随业务阶段滚动的工作。冷启动阶段用规则，成长期用轻量模型，成熟期做分层组合，每个阶段的正确答案都不一样。任何声称“一步到位”的方案，大概率会在半年后变成技术债。
下一步你可以做三件事。第一，把这一节里那张“选型优先级自查表”填一遍，看看哪些格子是空的，空的就是你要先补的。第二，抽 500 条评价做一次盲标，先验证你的标签定义有没有歧义，这比选模型重要得多。第三，如果涉及跨境多平台、评价数据分散在多个后台，先评估数据接入和 SKU 映射的成本，可以去数跨境的场景页看看它的数据接入和分析模板是否覆盖你的平台组合，再决定是自建还是采购。
选型做得好的项目，后面几乎没有戏剧性的故事，只是每周清单准时出现，问题按优先级被解决。这大概就是它该有的样子。
我们团队最近要搭商品评价分析体系，领导让我先出个方案。我一开始就去对比情感分析工具和几个NLP模型，结果方案被打回来了，说没解决业务问题。我挺困惑的，难道选型不是先看工具能力吗？
第一步不是选工具，而是把分析输出物定义清楚。具体做法是先跟业务方确认评价数据最终要产出什么：是每日口碑预警看板、月度卖点提炼报告，还是竞品差评对比清单。输出物不同，对数据粒度、时效和标签体系的要求完全不同。判断依据是：输出物决定下游要什么字段，字段决定上游能选什么方法。
建议在方案第一页写清‘本方案服务于X目标、交付Y形式的输出、消费方是Z角色’，这三行没定之前，任何工具对比都是无效工作。
我们是中小团队，商品评价一个月也就几千条，历史数据没打过标签，招不起算法工程师。我看网上教程动不动就上BERT微调，感觉完全落不了地。这种情况下到底该怎么起步？
这种条件建议从规则加词典方案起步，不要硬上预训练模型。具体做法是：先用关键词词典加正则把评价分成好评、差评、含具体问题（物流、质量、尺码）三类，再人工抽查200条算准确率。判断依据是：几千条量级下，规则方案准确率通常能到75%到85%，足够支撑问题发现和口碑监测；
而微调模型没有标注数据根本训不动，硬做只会拖垮项目。等规则跑顺了、积累了几千条人工修正数据，再考虑升级到传统机器学习，这条路成本可控且每一步都有产出。
我们评价数据有几十万条，业务方既要情感倾向又要提取具体吐槽点，团队里有人会Python但没人搞过深度学习。我卡在方法选型上，不知道该怎么在几种方案之间做取舍，怕选错方向白干半年。
用五个维度打分来决策：数据量级、是否有标注、语义复杂度、实时性要求、团队维护能力。几十万条加复杂语义提取，规则方案会迅速触顶，传统机器学习需要标注成本，大模型Prompt适合快速验证但不适合高并发低成本场景。
可执行做法是：先各拿500条做小样本验证，分别测规则、开源模型微调、大模型Prompt三套方案，对比准确率、单条成本和上线周期三个指标。判断依据是准确率差距在5%以内时，优先选维护成本最低的方案，而不是精度最高的方案，因为选型是长期维护问题，不是一次性比赛。
我们的评价分析方案上线头两个月效果挺好，第三个月开始误判明显变多，业务方开始不信任了。领导问我是不是当初选型就选错了，我也有点怀疑自己。这种情况到底是方法本身不行，还是别的原因？
大概率不是选型错了，而是缺少迭代和回退机制。评价数据的语言会漂移，比如新出现的网络热词、新的商品品类黑话，规则词典和模型都会逐渐失效。可执行做法是建一个月度巡检机制：每月抽200条新数据跑一遍，记录准确率，一旦跌破设定阈值（比如规则方案低于70%）就触发词典更新或模型重训。
判断依据是：选型不是一次性决策，方案里必须写清监控指标、巡检频率和回退预案。上线效果变差本身不可怕，可怕的是没有发现机制和补救路径，那才是真正的选型缺陷。
读者评论
文中那句“你们准确率我不关心，我只想知道这周哪三个SKU差评在变多”太真实了，技术团队和运营的关注点经常是两条平行线。选型前先搞清楚谁看报告、看完做什么，比调模型重要得多。
数据就绪度这个约束条件提得很到位。很多项目死在评价数据散落在客服系统、平台后台和Excel三处，光合并口径就拖了两周。三档以下不碰精细归因，这个判断标准很实用。
反讽和转折那句“质量真好，用三天就坏了”一针见血。通用情感词典按正面词密度判，负面召回低得离谱。换成负面召回率和高优先级漏报率当指标，才是业务真正关心的。
品类决定语义复杂度这个角度之前没细想过。3C关键词集中规则方法就能跑，美妆主观感受强必须依赖上下文。选型第一句先问品类而不是数据量，确实更有针对性。