简介这份《商品评价标签需求说明文档1.2》由产品经理李敏荣编写面向电商平台的产品经理、交互设计师与前端开发人员用于指导商品评价标签系统的设计与落地。文档围绕术语定义、产品描述、功能列表与详细需求展开重点覆盖商品页评价信息展示、商品评论列表页、更新机制与数据统计四大模块并延伸至后台的大数据评价标签管理、评价标签初始化编辑及单个酒景评价标签管理等场景配有界面预览与功能说明便于读者理解字段定义与交互逻辑。资源包共1个doc文件约1.15MB结构完整、目录清晰可直接作为需求评审与开发对接的参考模板。目前已有65人学习下载适合需要撰写或评审评价体系需求文档的从业者借鉴其组织方式与描述粒度。1. 商品评价标签需求说明文档1.2从一份 doc 到可落地的标签体系电商后台里最容易被低估的文档就是《商品评价标签需求说明文档1.2-产品李敏荣.doc》这类东西。它看起来只是一份 Word实际上决定了评价区里“尺码偏小”“物流快”“色差明显”这些标签怎么生成、怎么排序、怎么和搜索、推荐、客服工单打通。很多团队栽跟头不是因为模型不行而是因为这份需求说明文档1.2 写得像散文研发照着做出来的标签体系上线即翻车。这篇笔记面向正在接手评价标签需求的产品、后端和算法同学把这份 doc 拆成能评审、能开发、能验收的落地路径。读完你能判断自家标签体系该用规则还是模型、字段怎么定、参数怎么调、坑在哪。2. 需求说明文档1.2 里必须先钉死的四类字段一份能直接进入开发排期的评价标签需求说明文档核心不是把“标签”两个字写满而是把标签从产生到消费的链路字段全部定义清楚。我见过太多 doc 只写“对评价进行情感分析并打标签”结果研发做出来的东西和产品脑子里想的完全不是一回事。下面四类字段是评审时逐条过的底线。2.1 标签本体字段id、名称、层级与互斥关系标签本体是整份文档的地基。每个标签至少要有稳定 id、展示名称、所属一级类目、是否允许多选、是否互斥。比如“尺码偏小”和“尺码偏大”必须互斥“物流快”和“包装完好”可以共存。文档里如果只写中文名不写 id后面改文案就会引发数据对不上的血泪事故。字段类型示例是否必填tag_idstringsize_small是tag_namestring尺码偏小是categoryenum服饰属性是multi_selectboolfalse是exclusive_groupstringsize_fit否这张表要直接贴进需求说明文档1.2评审时逐行确认。exclusive_group 相同的标签在同一评价里只能命中一个这是后面排序和聚合的前提。2.2 触发来源字段规则命中还是模型输出标签来源必须写清楚否则排查问题时就是黑匣子。常见做法是分三类关键词规则、情感模型、行为信号如退货原因。文档里要规定每个标签的 source 优先级比如“尺码偏小”优先取退货原因其次取评价文本模型最后才用关键词兜底。# 标签来源优先级配置示例 TAG_SOURCE_PRIORITY { size_small: [return_reason, nlp_model, keyword_rule], logistics_fast: [nlp_model, keyword_rule], color_diff: [nlp_model, keyword_rule], } def resolve_tag(tag_id, signals): for source in TAG_SOURCE_PRIORITY.get(tag_id, []): if signals.get(source): return {tag_id: tag_id, source: source, value: signals[source]} return None这段逻辑说明signals 是各来源产出的候选结果字典按优先级取第一个非空值。参数上要注意return_reason 这类行为信号置信度最高但覆盖率低keyword_rule 覆盖高但误判多所以顺序不能随意调换。文档里不写这个顺序研发默认按代码顺序来上线后标签准确率就会玄学波动。2.3 展示与排序字段权重、时效与折叠阈值标签不是算出来就完事展示层字段同样要在需求说明文档1.2 里定死。每个标签要有展示权重、生效时间窗、以及聚合展示时的折叠阈值。比如“物流快”只在确认收货后 30 天内展示超过就降权“尺码偏小”在服饰类目下权重高于“包装完好”。-- 标签展示配置表 CREATE TABLE tag_display_config ( tag_id VARCHAR(64) PRIMARY KEY, weight INT DEFAULT 50, -- 0-100越大越靠前 active_days INT DEFAULT 90, -- 生效天数 fold_threshold INT DEFAULT 5, -- 聚合展示时超过几个折叠 updated_at TIMESTAMP );weight 建议初始统一 50再按类目做偏移不要一上来就拍脑袋给 90。active_days 对时效性标签很关键物流类 30 天、尺码类可以 180 天。fold_threshold 控制评价区顶部标签云最多显示几个超过就收进“更多”。2.4 消费方字段搜索、推荐、客服各自要什么同一套标签不同消费方要的字段不一样。搜索要的是可索引的 tag_id 列表推荐要的是带权重的标签向量客服工单要的是原始评价片段和命中来源。需求说明文档1.2 里如果不区分消费方后端就会把一张宽表硬塞给所有人查询慢还容易出错。常见做法是为每个消费方定义视图search_view 只暴露 tag_id 和商品 idrec_view 暴露 tag_id、weight、categorycs_view 额外带 evidence_text。这样各取所需也方便后面做权限隔离。评审时让搜索、推荐、客服各派一个人确认字段能省掉上线后大量返工。3. 从 doc 到可运行标签服务的最小实现字段定完下一步是把需求说明文档1.2 变成能跑的服务。这一章给出一条最小可复现路径数据准备、规则与模型打分、聚合输出。不追求大而全追求你今天照着做就能在测试环境跑通。3.1 评价文本预处理与候选标签召回原始评价文本脏得很表情、重复标点、拼音缩写混在一起。预处理目标不是洗得多干净而是保证召回阶段不漏。常见做法是保留原文一份另存一份归一化文本用于匹配。import re def normalize(text): text re.sub(r[\U00010000-\U0010ffff], , text) # 去 emoji text re.sub(r(.)\1{2,}, r\1\1, text) # 压缩重复字符 text text.replace( , ).lower() return text def recall_candidates(text, keyword_map): norm normalize(text) hits [] for tag_id, keywords in keyword_map.items(): for kw in keywords: if kw in norm: hits.append({tag_id: tag_id, source: keyword_rule, kw: kw}) break return hitsnormalize 里压缩重复字符是为了让“快快快快”也能命中“快”但不要过度归一化否则“不推荐”和“推荐”会被搞混。keyword_map 建议每个标签配 5 到 15 个关键词太少召回低太多误判高。召回结果只是候选最终是否展示还要过下一节的打分。3.2 规则打分与模型打分的融合参数规则和模型各有短板融合时参数怎么设是需求说明文档1.2 里最容易被忽略的部分。我一般用加权求和规则分和模型分各占一半起步再按标签类型调整。def fuse_score(rule_score, model_score, tag_type): weights { attribute: (0.7, 0.3), # 属性类偏规则 sentiment: (0.3, 0.7), # 情感类偏模型 logistics: (0.5, 0.5), } wr, wm weights.get(tag_type, (0.5, 0.5)) return wr * rule_score wm * model_score def decide_tag(candidates, threshold0.6): result [] for c in candidates: score fuse_score(c[rule_score], c[model_score], c[tag_type]) if score threshold: result.append({**c, final_score: round(score, 3)}) return resultthreshold 默认 0.6 是经验值属性类标签可以降到 0.5 提高覆盖情感类建议升到 0.7 控制误判。融合权重不要写死在代码里放进配置表方便按类目调。上线后每周看一次准确率低于 85% 就回调参数。3.3 标签聚合与去重的输出结构单条评价打完标签后要按商品维度聚合否则前端拿到的是一堆散点。聚合时要处理去重和计数同一标签被多条评价命中只保留一个但记录命中次数用于排序。from collections import defaultdict def aggregate_tags(tagged_reviews): bucket defaultdict(lambda: {count: 0, score_sum: 0.0, sources: set()}) for r in tagged_reviews: for t in r[tags]: key t[tag_id] bucket[key][count] 1 bucket[key][score_sum] t[final_score] bucket[key][sources].add(t[source]) output [] for tag_id, v in bucket.items(): output.append({ tag_id: tag_id, count: v[count], avg_score: round(v[score_sum] / v[count], 3), sources: list(v[sources]), }) output.sort(keylambda x: (x[count], x[avg_score]), reverseTrue) return output聚合结果按 count 和 avg_score 双降序排前端直接取前 N 个展示。sources 字段保留下来客服排查时能知道这个标签是规则命中还是模型命中。注意 count 高但 avg_score 低的标签要谨慎展示可能是误判集中。4. 需求说明文档1.2 评审与联调阶段的避坑清单文档写得再细评审和联调阶段照样会翻车。下面五条是我踩过的坑每条按现象、原因、解决写供你在需求说明文档1.2 评审会上直接对照。4.1 标签 id 中途改名导致历史数据对不上现象上线两周后产品要求把“尺码偏小”改成“偏小”改完发现历史评价的标签统计全部错位。原因文档里只定义了 tag_name没有把 tag_id 作为不可变主键研发直接拿名称做关联。解决需求说明文档1.2 里明确 tag_id 一经上线不可修改展示名走单独的 display_name 字段改名只改 display_name。4.2 模型阈值照搬离线指标导致线上误判飙升现象离线评估准确率 92%上线后评价区出现大量“物流快”打在退货评价上。原因离线测试集和线上分布不一致阈值直接用了离线最优值。解决线上阈值比离线高 0.05 到 0.1先灰度 5% 流量观察三天再逐步放开。文档里要写清楚灰度策略不能只写目标准确率。4.3 多来源标签未去重导致计数虚高现象同一评价同时命中关键词和模型标签计数翻倍排序失真。原因聚合阶段没有按 tag_id 去重直接把候选列表累加。解决聚合前先按 tag_id 合并同一来源只计一次不同来源保留 sources 集合。文档里要规定去重规则。4.4 时效字段缺失导致过期标签长期展示现象用户半年前评价的“物流快”一直挂在标签云顶部。原因需求说明文档1.2 没定义 active_days展示层默认永久有效。解决所有标签必须配 active_days物流类 30 天、属性类 180 天、情感类 90 天过期自动降权不删除。4.5 消费方字段未隔离导致查询超时现象客服系统拉取标签时把推荐用的宽表也查了单次查询超过 3 秒。原因没有按消费方建视图所有字段混在一张表。解决按 search、rec、cs 建三个视图各自只暴露必要字段客服视图额外带 evidence_text 但限制返回条数。5. 标签体系上线后的验证与调参习惯最后一章说点进阶的。标签体系上线不是终点验证和调参才是日常。我一般用一个小样本人工标注集做每周抽检再结合线上点击和转化做间接验证。验证方式样本量频率关注指标人工抽检200 条每周准确率、召回率点击验证全量每日标签点击率转化归因全量每周标签曝光到下单转化人工抽检时我会让标注同学只看评价原文和标签不看来源避免先入为主。准确率低于 85% 就回查是规则关键词太宽还是模型阈值太低。点击率突然下降先看是不是排序权重被改了。转化归因只做参考不要因为短期波动就大改参数。调参习惯上我坚持每次只改一个变量改完观察至少三天。标签体系是个连锁系统同时改阈值和权重出了问题根本不知道是哪个引起的。另外需求说明文档1.2 不是写完就锁死每次调参后把变更记录回写到文档的修订历史里下次评审才有据可查。这套习惯帮我省掉了无数次后悔药。希望帮到你。本文还有配套的精品资源点击获取