做产品的人大概都有过这种体验产品上线几个月后台攒了几千条评论评分看着还不错但你真要被问一句“用户到底爱你哪里”反而答不上来。“好用”是什么好用“喜欢”是喜欢设计还是喜欢响应快一条条评论刷下去刷到眼睛发酸也凑不出一份能递给团队看的结论。我最近在做的一件事就是把“用户喜欢什么”这个问题变成一次API调用——输入一批评论返回一份结构化的喜爱画像哪些功能被反复提到、哪些优点才是用户真正在意的、每条结论背后有多少条评论撑着。这篇文章就把这个API的来龙去脉讲清楚它解决什么问题、数据怎么设计、底层管线怎么搭、实测效果如何以及接入生产环境时踩过的几个坑。1. 为什么需要这样一支API评论很多但答案藏在“好评归因”里先说痛点。市面上的评论分析工具不少大部分做的事情是“情感极性判断”——这句话是正面的、负面的、中性的然后给你一个百分比87%正向。这个数字有用吗有用但你拿着它没法干活。它只告诉你用户满不满意没告诉你用户因为什么满意。1.1 评分和简单情感分析解决不了的问题想象一个场景你的智能手环收到一堆五星好评简单情感分析告诉你“好评率93%”然后呢你不知道用户到底在夸续航、夸佩戴舒服还是夸App同步快。这些信息其实都埋在评论文本里只是没人把它们挖出来。另一个场景更尴尬好评里有一句“这个手环戴了一天都没摘”另一句“充电一次用了一周”还有一句“终于不用每天充电了”。三句话说的是同一件事——续航好但用词完全不同。人一眼能看出来规则模型看不出来传统的关键词统计也看不出来因为“戴了一天”“用了一周”“不用每天充电”没有任何公共关键词。这就是我定义这个API时要解决的核心问题从自由文本评论中识别出用户喜爱的具体维度而不是笼统的正负情绪。1.2 从“正向情绪”到“喜爱维度”的跳跃“喜爱维度”这四个字值得较真。我把它拆成三层实体是什么用户在谈论产品的哪个部分。手环的“电池”“表带”“App”“屏幕”是实体SaaS工具的“导入功能”“报表”“权限管理”是实体。属性是什么用户谈论实体的哪个方面。“续航”“舒适度”“易用性”是属性。实体加属性才是一个完整的方面aspect比如“电池-续航”“表带-舒适度”。情绪是什么用户对这个方面是正面还是负面。在这个API里我只关心正面——也就是用户明确表达“喜爱”的那些维度。所以一次调用返回的不应该是“这条评论是正面”而应该是“用户喜爱这个产品的角度包括续航、舒适度、App稳定性其中续航被提到了34%的评论里”。顺带说一句市面上很多测评博主和电商详情页其实在做类似的事情但他们靠人肉看评论人工归纳。这个API想替代的就是这种重复、耗时、容易漏的人肉归纳过程。2. API的输入与输出设计一次请求拿到一份“喜爱画像”API好不好用第一眼看输入输出设计。我给它定了一个很朴素的风格输入尽可能少、输出尽可能结构化。2.1 请求侧评论源与产品上下文请求体设计得很直白{ product_id: smart-band-2000, product_name: 轻羽智能手环, product_category: wearable, locale: zh-CN, comments: [ 戴了一整天都没摘续航真的顶, 表带很软很舒服睡觉戴着也没感觉, ... ], top_k: 5, min_support: 3 }三个字段花了我不少心思product_name和product_category看起来不起眼但对抽取质量影响很大。模型需要对“实体”做识别如果你告诉它“这是一款手环”它就知道“表带”“屏幕”“续航”是可能的实体方向如果不说模型会把评论里出现的任何名词都当成候选噪声会多很多。min_support表示一个维度至少要被多少条评论提到才会出现在结果里。这是用来过滤“只有一个人提过”的边缘角度。默认3条产品冷启动阶段可以放宽到2条。top_k控制最多返回几个维度。默认5对大多数团队来说刚好够用如果做深度的竞品分析可以调到10。评论数组的长度我建议单次请求控制在500条以内大概几百KB。原因后面讲管线的时候会展开——需要控制单次请求的处理时间和成本。2.2 响应侧维度化结果的设计逻辑响应体是整支API的灵魂它的设计原则是拿过去就能直接用不需要再二次加工。我的响应结构长这样{ product_id: smart-band-2000, generated_at: 2025-06-18T12:00:00Z, comment_total: 128, coverage: 0.91, loved_features: [ { feature_id: battery_life, feature_name: 续航能力, aspect: 电池续航, strength: high, support_count: 46, support_ratio: 0.36, representative_comments: [ 戴了一整天都没摘续航真的顶, 充电一次用了一周出差完全不用带充电线 ] }, { feature_id: comfort, feature_name: 佩戴舒适度, aspect: 表带舒适性, strength: high, support_count: 38, support_ratio: 0.30, representative_comments: [ 表带很软很舒服睡觉戴着也没感觉, 很轻几乎感觉不到它的存在 ] } ] }几个字段说下设计理由coverage所有评论中有百分之多少被归入了至少一个喜爱维度。这个字段很重要因为如果覆盖率太低比如不到50%说明这批评论的主体内容不在“正面优点”上结果可信度要打问号。它是给下游用户的一个“水质检测仪”。strength不是简单的高中低三档而是综合了support_ratio和评论情感强度的加权判断。比如“太喜欢了”和“还不错”在情感烈度上完全不同虽然都算正面。representative_comments每个维度附带1到2条原始评论。这比只给一句“46人提到续航”有说服力得多——运营同事可以直接引用到宣传文案里产品同事可以直接点进去看原文。2.3 一个最小可调用示例最简单的接入方式直接curl就行curl -X POST https://api.example.com/v1/loved-features \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { product_id: smart-band-2000, product_category: wearable, locale: zh-CN, comments: [戴了一整天都没摘续航真的顶, 表带很软很舒服睡觉戴着也没感觉] }如果用的是Pythonrequests库几行就能接上import requests resp requests.post( https://api.example.com/v1/loved-features, headers{Authorization: Bearer YOUR_API_KEY}, json{ product_id: smart-band-2000, product_category: wearable, locale: zh-CN, comments: [ 戴了一整天都没摘续航真的顶, 表带很软很舒服睡觉戴着也没感觉 ], top_k: 3 }, timeout30 ) data resp.json() for feature in data[loved_features]: print(f{feature[feature_name]}: {feature[support_ratio]:.0%} 的评论提到)响应速度取决于评论总量500条以内跑完大概3到8秒。这个延迟对批量分析完全够用但不适合做实时在线推荐——如果要做实时场景建议走异步回调接口而不是同步等待。3. 从原始评论到“用户喜爱点”的完整管线拿到一批评论后API内部要经过四道工序才能从一堆口语化文本变成规整的维度列表。3.1 第一步方面级情感抽取第一道工序是“方面级情感抽取”。这一步的目标是把每条评论拆成一个或多个实体属性情绪三元组。比如“戴了一整天都没摘续航真的顶”这句话会拆出{ entity: 电池, aspect: 续航, sentiment: positive, intensity: high, evidence: 戴了一整天都没摘 }这里我直接用大语言模型来做而不是传统的ABSAAspect-Based Sentiment Analysis模型。原因很现实传统ABSA模型需要针对每个产品领域重新标注训练数据换个品类效果就崩大语言模型只要在提示词里告诉它产品品类就能泛化到“手环”“咖啡机”“SaaS工具”等各种场景。这一步用流程图描述的话很直白评论进三元组出。至于具体模型选型我建议用支持JSON结构化输出的模型比如DeepSeek或OpenAI系模型让模型直接返回固定的JSON schema而不是让它在自然语言里夹带抽取结果——那样下游解析会很痛苦。提示词的核心大概长这样你是一个产品评论分析引擎。给定产品类别和用户评论抽取出用户明确表达喜爱的方面。 输出必须是JSON数组每个元素包含 - entity: 用户谈论的部件或功能 - aspect: 用户喜爱的具体属性 - sentiment: 固定为positive - intensity: high/medium/low - evidence: 原文中最能佐证的片段 要求 1. 只抽取明确的正面表达不要臆测 2. 每条评论可以输出0到3个三元组 3. entity和aspect必须是名词短语不要带情绪词这一步是整个管线的信息源头质量决定了后面的所有环节。实测下来出错最多的情况是“高频词误判”——比如有人写“这个价位的产品里算不错的”这里其实暗含对价格的正面态度但模型很容易漏掉反过来“性价比很高”里的“价格”是个负面实体但情绪是正面模型容易把情绪挂在“价格”上搞成负面。3.2 第二步同义表达标准化抽取出的三元组是碎片。50条评论里可能有20种说法都指向“续航”有的是“续航顶”有的是“一充顶一周”有的是“两天一充完全够用”还有的是“电池耐用”。如果不做标准化结果就是一堆表面不同、实则同义的长尾词没法聚合。标准化的做法是先用同义词映射做一轮粗对齐再用模型判断候选词是否属于同一维度。粗对齐覆盖常见词比如“续航”“电池耐用”“待机时间长”都映射到“续航能力”模型判断负责处理那些没法用规则穷举的变体比如“出差完全不焦虑”这种为了续航买单的间接表达。这轮做完上面的四个说法会被归并到一个维度下续航能力 [续航顶, 一充顶一周, 两天一充完全够用, 电池耐用]很多半吊子工具在这一步就放弃了拿原始词频直接做统计结果是“续航”“电池”“充电”“待机”被拆成四行。不能说错但对用户来说毫无意义。标准化才是从“分词统计”走向“语义理解”的关键一跃。3.3 第三步细粒度聚类归并标准化之后还是可能存在“类内分类”。比如“续航能力”和“快充速度”是两件事有些评论会混在一起说“充电快一次能管一周”。如果直接归成一个维度“续航”信息就不够细如果拆成两个又显得琐碎。我现在的方案是把标准化的维度用向量化方式嵌入做一层轻量聚类。同一个聚类内部的维度名合并成统一名称聚类之间保持独立。实际操作上向量化模型用那种通用型的就好不需要专门微调因为维度的数量级不会太大几百个维度用余弦相似度完全跑得动。做完这层聚类输出的维度数会收敛到一个比较理想的范围一个产品的喜爱维度一般在3到8个之间。如果超过10个说明抽取粒度太细或者聚类阈值太严如果只有1到2个大概率是某个维度的表述形式过于多样被合并过头了。3.4 第四步支持度统计与置信度标记最后一步是给每个维度打上支持度、占比和置信度然后输出。支持度就是“有多少条评论提到了这个维度”。这里有个细节如果一条评论里同一个维度出现了三次也只计一次。否则个别啰嗦的用户会把某个维度的权重拉高到失真。置信度标记参考的是统计学里的“样本量和方差”逻辑——样本量越小结论越不可靠。我就按support_count分了几个档support_count 20高置信度可以拿去写宣传物料support_count 5中置信度可以用于产品决策参考support_count 5低置信度仅作线索不建议直接引用刚才响应里的strength字段就是结合了支持度和情感强度的综合值。具体公式不复杂先算情感强度的平均分再和支持占比做加权。情感强度高的维度即使提得人少一点也会被标为hard反之大量共同的温和好评会被标为medium。4. 实测记录三类产品评论跑出来的效果理论讲再多不如跑一遍。我拿三种差异很大的产品类别做了实测SaaS工具、智能硬件、生活消费品。样本都是人工采集的公开评论去掉隐私信息后用API跑。4.1 SaaS软件评论喜爱维度最分散第一批测试数据是某个项目管理工具的评论共200条。输出结果大概是排名喜爱维度提及率典型评论摘录1界面简洁易用28%“新人十分钟就能上手”2自动化流程省时间19%“重复任务再也不用手动点了”3模板丰富15%“自带模板直接改改就能用”4协作通知及时11%“提醒很准不会漏消息”5报表清晰9%“周报数据一目了然”SaaS用户夸的最多的往往不是“功能强”而是“省时间、易上手”。这就是为什么做SaaS产品的人特别应该跑一下这个API——你可能会发现自己天天迭代的大功能并不是用户最爱的反而被无视的“原生模板”才是用户口中的亮点。4.2 智能硬件评论长尾效果明显第二批是一组智能手环的评论120条。输出很快收敛到“续航、舒适度、防水、屏幕清晰、App同步”五个维度覆盖率91%。让我比较意外的是“防水”这个维度——只有11条评论提到但其中9条用了“游泳戴着没问题”“洗澡不用摘”这种高情绪强度表达所以strength被标成了high。如果是传统的关键词统计这个词可能被并进“耐用”里但我们做了方面级抽取它就被单独立起来了。对硬件产品经理来说这种“小众但强烈”的喜爱点极具价值往往对应着某类核心用户——防水对应游泳爱好者这类用户复购率和口碑传播能力都相当高。4.3 生活消费品评论跟促销强关联第三批是一个咖啡壶产品的评论150条。结果里有三个维度和产品功能毫无关系“包装精致”“送礼有面子”“客服态度好”。这给我提了个醒用户对消费品的喜爱对象常有一半落在产品本身之外。这时候如果只拿“咖啡萃取”“保温效果”这些产品内维度去分析会漏掉相当大一部分用户的真实购买动因。生活消费品类的运营团队完全可以直接把loved_features里“送礼有面子”这种维度抽出来放进电商详情页作为卖点文案——因为它就是用户自己的话。三组实测跑下来一个共性感受是覆盖率都能达到85%以上说明这个管线在大白话评论上兜得住底而真正出彩的地方在“非功能维度”的识别上——用户的爱经常给到意想不到的地方规则系统很难提前预料到模型反而可以。5. 接入生产环境前我踩过的几个坑API从demo到生产环境中间有一堆文档里查不到的细节。这几个坑我真实踩过写出来供后来人参考。5.1 重复调用导致的成本失控第一个坑和最俗的钱有关。早期版本里我把每批评论直接送进大模型没有做任何缓存。结果测试阶段跑几十遍月账单翻了四五倍大部分钱都花在重复处理同样的评论上。现在我在API服务层加了一张“评论指纹缓存表”——每条评论先算一个哈希值用带规范的文本归一化后算这样去掉首尾空格、统一大小写之后的重复杂评论能命中同一个哈希命中缓存直接返回之前的结果只有哈希没见过的才走大模型管线。实测下来缓存命中率在一批重复提交的调研数据里能达到40%以上成本立刻回到可控区间。另外一个省钱姿势是优先用便宜的小模型做抽取只把“聚类归并”这类需要全局判断的步骤交给大模型。抽取是逐条的、并发友好、对延迟不敏感——小模型完全扛得住聚类需要看全貌次数少用大模型值得。现在DeepSeek这类开源模型的API价格竞争力很强把管线拆开用整体成本能比“一个模型包到底”的做法便宜大概一半。5.2 模型输出格式不稳定大模型输出是概率性的你让它返回JSON偶尔它会在JSON前后夹带一句“好的以下是我抽取的结果”。如果你下游直接用json.loads()解析这一句就足以把进程打崩。第一次碰到这个问题时我在生产环境里抓了一段返回体内容大致是正常JSON前面多了个“好的”前缀。解析直接抛异常。教训是不能用裸json.loads()必须套一层容错。我现在的做法是三层兜底尝试json.loads()直接解析失败则用正则提出最外层的{...}或[...]块再解析再不行就标记本批数据抽取失败进入重试队列而不是直接返回错误给用户。同时提示词里要写明“只输出JSON不要任何额外说明文字”这能显著压低但不完全消除这种问题兜底逻辑仍然必须有。5.3 小样本下的“假共识”第三个坑和统计学有关但很容易被忽略。当一个维度只有两三条评论时模型输出往往显得格外清晰——“这个产品的拍照效果特别好”只有两条评论支持单独看成立但它可能根本不代表主流用户的声音。这就是为什么我在响应里加了min_support和confidence。你要明白API给出的喜爱度排序不是“客观真理”而是“基于这批评论的最佳估计”。样本越小估计噪声越大。早期我没加这个字段合作方拿着只有2条支持的“维度”去改产品页面结果那2条只是两个KOL朋友的真实好评不能代表用户总体。加了置信度标记之后这类误读明显少了。5.4 数据合规红线最后一个坑有关隐私。评论数据可能包含用户的个人信息比如手环评论里有人说“我30岁开始用这个手环”“我住南方”这些信息看起来无害但它们确实属于个人数据。上线前必须做一层脱敏把明显的手机号、邮箱、姓名、地址等实体从评论文本里抹掉再送入分析管线。还有一个容易忽略的点如果你是从第三方平台同步评论来做分析一定要确认平台的用户协议是否允许这么做。我的建议是只对你自己产品或你有明确授权的内容做分析别拿别家的评论去白嫖这不是技术问题是基本的底线。补充两个自己总结的“使用心法”文章最后分享两个我在实际使用中获得的体会不算功能但比功能更影响最终效果。第一个体会是这个API最适合的场景不是“分析一次”而是“周期性对比”。每个月跑一次评论分析把loved_features列表存下来跟三个月前的列表对比你会发现用户喜爱的排序在悄悄迁移——某次发版后“速度”维度掉出前五“稳定性”顶了上来这说明新版本带来的体验变化真实传导到了用户心智里。这种趋势比单次结果有价值得多。第二个体会是输入product_category这个字段不要图省事乱填它直接影响了模型的先验知识范围。填“wearable”和填“smart-band”得到的结果粒度完全不同——前者可能给你“电池、表带、屏幕”后者能给你“表带材质、睡眠监测算法、抬腕亮屏准确率”。写具体一点你拿到的结果就深一层。做一支“告诉用户爱什么”的API本质上是在做一件翻译工作把用户写在评论区里的散装语言翻译成产品团队和运营团队可以直接行动的清单。整个过程不涉及什么玄乎的算法核心是抽取质量、标准化程度和统计口径这三件事。把这三点想透了无论你是想搭自己的分析管线还是直接调现成的服务都能少走不少弯路。