尧图网站建设 
简介面向电商数据挖掘、用户增长及推荐算法工程师的深度学习实践资料聚焦多源数据融合的消费者行为分析与偏好预测。方案以DeepSeek技术路线为主线覆盖从数据采集、清洗、特征工程到知识图谱构建、用户画像标签体系与权重计算的全流程包含结构化与非结构化数据预处理、RNN/LSTM及Transformer行为序列建模等关键环节。资源为1个PDF文件大小11.51MB共213页50个大章节支持目录跳转与书签大纲定位文字图表清晰完整。目前已有81人学习适合正在搭建用户画像系统或优化偏好预测模型的读者参考。文档不仅给出架构设计与技术选型还包含具体实现策略与调优思路其中知识图谱嵌入、注意力机制及行为序列建模等章节配有模型选型与实现细节可直接迁移到实际项目帮助快速建立多源数据融合画像的整体框架。1. 213 页画像方案解决的核心问题多源融合与偏好预测的落地链路这份《DeepSeek电商用户画像构建方案》给我的第一印象不是 AI 原理课而是一条把「多源数据 → 融合特征 → 画像标签 → 偏好预测」全链路落进电商业务的数据工程方案。电商团队最常见的尴尬是交易数据在数仓、客服会话在工单系统、商品评论在评价库各归各运营想要一句“这个用户为什么买、下次还买什么”的判断却没人给得出来。213 页的篇幅对应的是链路每个环节的口径、参数和边界而不是模型排名。适合两类人读一类是要搭建画像系统的算法工程师另一类是要给推荐、营销、客服策略提供用户理解的策略产品经理。2. 多源数据融合设计从 ID 打通到画像口径的完整链路用户画像的最底层不是标签是数据。多源数据融合的核心也不是把数据堆在一起而是让每一份数据在画像里承担明确角色。先分清楚数据源再谈打通和口径。2.1 电商多源数据有哪几类各自的画像价值我一般把数据源按“行为确定性”分成四层交易层、行为层、文本层、履约层。分层决定了你在画像链路里给它的置信度权重。数据源典型字段画像价值坑点交易订单SKU、类目、价格、数量、支付时间最强信号代表真实购买偏好低频只有下单才产生行为日志浏览、点击、搜索、收藏、加购、停留时长高频反映即时兴趣强度噪声大误点、爬虫、比价行为混在一起客服会话与评论会话文本、评价文本、售后原因显式诉求和隐式偏好的金矿非结构化需要 NLP 抽取履约与售后收货地址、退货单、取消单辅助判断消费力和决策风格字段敏感脱敏后可用度下降这里有个容易忽略的点交易层适合做“事实标签”行为层适合做“兴趣强度标签”文本层则贡献了大量交易和行为里看不到的“意图标签”。比如用户问客服“这个能不能放新生儿房间”这个句子本身就包含了购买阶段、场景人群、决策顾虑三层信息但传统 RFM 模型完全读不到。DeepSeek 在这份方案里的价值正是集中处理文本层和半结构化的行为描述。2.2 跨端 ID 打通与实体对齐的常见做法多源数据融合最先翻车的通常是 ID 打通。用户在小程序登录一次、App 登录一次、H5 页面匿名逛了一圈三份记录的 user_id 完全不同。常见做法是建一张 ID mapping 表用设备 ID、手机号、登录账号、支付账号作为关联键做实时与离线两种打通。离线场景我推荐用图对齐的方式把已知的登录 UID 作为主键其他 ID 作为辅助节点用共同收货人、共同设备、共同支付账号这样的关系做连通分量归并。这比两表 join 更稳健因为用户的行为路径往往跨端。实时场景则只查高频映射缓存避免在线链路里做重归并。商品侧也有实体对齐问题。同一个商品在自营标题里叫“婴儿床实木免漆”在第三方店铺叫“实木婴儿床无味”如果不做实体归一画像里就会出现两个看似不同的类目兴趣。我的做法是维护一份商品主数据表以内部 SKU 为键把各渠道标题、类目、品牌、规格属性映射回去只有映射不上的长尾商品才交给模型做语义匹配。2.3 画像口径设计标签命名、时效与覆盖规则口径设计是画像体系最容易埋雷的地方。没有统一口径离线画像和在线服务各算各的最后模型训练和线上策略用的根本不是同一份标签。我建议每一张画像标签表提前固定这些字段标签名、标签值、置信度、最近一次命中时间、统计窗口、标签字典版本。统计窗口必须写清楚是近 7 天、近 30 天还是全部历史。覆盖规则要硬性规定行为样本不足的用户不能打标签宁缺毋滥。这样才能保证画像从一开始就是可审计的。标签命名也要规范。类目偏好用“pref_category:母婴:奶粉”这种三段式价格敏感度用“price_sensitivity:high”。不推荐中文自由文本因为下游特征工程要稳定枚举。标签字典版本号尤其重要后面避坑章节会专门展开。3. DeepSeek 接入与语义标签抽取部署选型、API 调用与边界约束数据融合完画像从哪一步交给 DeepSeek这里有一个关键判断不是让大模型端到端生成画像而是让它只负责“文本理解”这一段。3.1 DeepSeek 在画像体系里承担什么角色我把画像生成链路拆成三个阶段规则清洗、语义标签抽取、偏好预测。DeepSeek 放在中间只处理非结构化文本到结构化标签的转换。为什么不端到端因为画像系统要稳定上线、要解释标签来源、要支持人工复核端到端生成的黑匣子很难满足这些工程约束。具体到任务DeepSeek 承担四类活儿从客服会话里抽用户显式诉求从商品评论里抽使用场景和售后体验从搜索词里抽购买意图和决策阶段再给跨渠道路径做语义聚类。输出统一是 JSON 结构化标签下游特征工程不关心文本原文。从 LLM 和 AI Agent 的边界来说DeepSeek 属于模型层它本身不负责调度。真正上线时模型外面还要套工作流编排层把“读取文本 → 调模型 → 校验输出 → 写标签表”串起来也就是常说的 harness 机制。模型负责判断编排层负责任务调度、重试和幂等保障。3.2 本地部署、API 调用与工作流 harness 怎么选接入方式有三种常见选择。第一是 API 调用适合快速验证和中小规模标签抽取团队不需要维护推理集群直接在开放平台建应用拿密钥就能跑。第二是本地部署适合用户会话数据敏感、不允许出域的电商团队代价是要自己维护显存和推理服务。第三种是把前两者包装在工作流 harness 里适合标签量级大、需要批处理和重试的线上环境。我看到的真实落地路径通常是先用 API 跑通 1 万条验证数据确认识别效果和成本再决定要不要本地化。本地部署的好处是数据完全在内网流动隐私合规压力小坏处是压测和版本升级都变成 Ops 团队的长期负担。开发阶段我习惯在 VS Code 里直接配 DeepSeek API 来调试特征 SQL 和抽取提示词改一版提示词立刻跑一批样本看输出比每次走完整调度快很多。等到任务稳定了再把这套逻辑搬进 harness 里做成定时任务。3.3 从客服会话和评论里抽取偏好标签最小可运行脚本下面是我在电商场景里常用的一段调用逻辑。接口兼容 OpenAI 的 chat completions 风格关键是把输出强制成 JSON 并压低随机性。from openai import OpenAI client OpenAI( base_url你的API网关地址, api_key你的密钥 ) system_prompt 你是电商用户画像语义抽取服务。 输入是客服会话的一轮或多轮文本。 请抽取以下字段只输出 JSON不要解释 - explicit_needs: 用户明确说出的功能或服务需求没有则为 null - implicit_preference: 用户对价格带、品牌、外观、物流、售后等的隐含偏好 - purchase_stage: browse / compare / decision / after_sale - negative_feedback: 用户表达的不满点没有则为 null 要求对没有依据的字段输出 null不要推测。 user_text 这个推车能不能一键收车我平时一个人带娃出门太重的不行最好轻一点。 resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_text} ], response_format{type: json_object}, temperature0.1, max_tokens300 ) print(resp.choices[0].message.content)这段代码逻辑不复杂参数却有讲究。temperature 我固定给 0.1不取 0 是为了避免极端贪心导致的模板化输出但超过 0.3 标签就开始飘。response_format 强制 json_object否则输出里混进解释性文字下游解析器会反复报错。max_tokens 给 300 对单条文本足够对超长对话要按会话轮次先切块不能整体灌给模型。实际批处理时我不会对每条文本单独请求而是按用户会话聚合后再请求一个用户一次请求返回全部标签。这样能明显降低 Token 消耗也降低了下游拼接特征时的复杂度。3.4 Token 成本与批处理去重控制预算的三个手段语义标签抽取的成本大头通常在三个地方重复文本重复打标、超长文本全量打标、提示词里塞太多示例。控制方法分别是内容去重、长度裁剪、少样本精简。文本去重我直接用原文 MD5同一条评论或会话在多个渠道出现时只打一次标。长度裁剪要把输入限制在有效范围比如客服会话只取用户侧发言和最近两轮店员回复不需要完整历史。少样本示例每类任务不超过两条示例太多会显著增加每批次 Token 开销但不会成比例提升效果。还有一个容易忽略的成本陷阱数据库里同一个用户在不同订单里写相同评论。这种文本如果不做去重一个用户重复消耗几十倍 Token 却只产出同一份标签。去重放在抽取前不是在模型调用后。4. 画像到偏好预测特征工程、模型融合与冷启动补齐标签系统建好之后下一个问题是画像怎么用到推荐和营销里。这一步本质是把标签转成特征再让模型或规则做偏好预测。4.1 画像标签转特征矩阵密度、时效与行为统计画像标签不能直接送进模型。原因有两个一是标签是稀疏枚举值直接 one-hot 会让特征维度爆炸二是标签本身缺少强度信息无法区分“昨天刚加购”和“三个月前看过”。我常用的转换模式是三通道标签命中通道0/1、标签强度通道近 30 天命中次数、标签时效通道距最近命中的天数做指数衰减。三个通道加起来才是一个完整的特征表达。import json def build_label_features(label_records, now_ts): features {} recent_days 30 for item in label_records: label item[label] hit_ts item[hit_ts] count item[count_30d] # 时效衰减 gap_days (now_ts - hit_ts) / 86400.0 decay max(0.0, 1.0 - gap_days / recent_days) # 特征命名带清窗口前缀方便回溯 features[flabel_30d_{label}_hit] 1.0 features[flabel_30d_{label}_count_log] round((count ** 0.5), 4) features[flabel_30d_{label}_decay] round(decay, 4) return features特征命名里带窗口前缀很重要。线上服务读特征的时候如果只认标签名不认窗口新旧口径就会混用。count 做开根号而不是取 log是为了避免大量 0 值导致特征分布过偏。这个阶段的常见误操作是把画像标签当成最终模型特征直接灌进 LightGBM。结果是模型训练时特征重要性飘忽不定同一个标签今天排第一明天排不上。原因往往在于标签时效通道缺失模型学到的只是“用户有过这个标签”而不是“用户最近还对这个东西热不热”。4.2 偏好预测的两层做法规则校准与行为序列模型偏好预测我推荐两层结构而不是一个复杂模型解决所有问题。第一层是可解释规则层负责处理高频、确定性强的偏好。比如“近 30 天搜索母婴类目超过 5 次且加购 2 次判定为母婴品类偏好”这种规则运营看得懂出了问题也追得到。第二层是行为序列模型处理规则覆盖不了的长尾和跨类目迁移。输入是用户近 N 次行为序列浏览类目、加购类目、价格带、渠道输出是下一个可能购买的类目概率。模型不必复杂序列维度在 50 以下时一个 embedding 加注意力层就够用。这两层的关系不是模型替代规则而是互相校准。如果规则判定用户偏好母婴而序列模型给出的是美妆高概率通常说明两种情况用户可能是代购或送礼也可能是规则的时间窗口太长捕捉到了历史偏好但没反映当前兴趣。这时候要人工看案例而不是盲目信模型。价格带敏感度预测也是同样套路。规则层用客单价、优惠券使用率、比价行为判断模型层用序列里商品价格分布做回归预测。两个结果都输出在策略侧取交集比单独用任何一层都稳定。4.3 冷启动用户的画像补全种子匹配与语义迁移冷启动用户没有历史行为任何模型都无能为力但我们不能直接给空画像。常见做法是种子用户匹配把新用户注册时的渠道、设备、访问落地页、首搜关键词作为弱特征去找相似的老用户群把老用户群的高频标签迁移过来。这里的关键不是迁移准确率而是迁移可解释性。我给冷启动用户打标签时会额外加一个字段“source: seed_migration”这样运营看到冷启动画像能知道这不是真实行为而是相似人群迁移不会拿它当强信号做高成本运营动作。5. 画像落地避坑5 个高频异常与根因定位这一章是这套方案落地时最容易翻车的五个地方每条都按现象、原因、解决三步写清楚。5.1 坑一离线画像很丰满线上特征对不上现象离线评估跑得很漂亮标签覆盖率高可一到线上推荐服务特征读取总是空值策略效果直线下滑。原因离线画像每天凌晨跑批写入的是 T-1 数据线上服务读的却是近 24 小时的实时标签表。两边各自维护一套口径标签名一样含义和时间窗口完全不同。模型离线训练赢了线上推理读不到对应特征。解决把画像口径统一成一份 JSON 配置离线跑批和在线服务都读同一份文件。新增标签也通过配置发布不允许两边各加各的。上线前做一次离线在线特征一致性校验随机抽 1000 个用户对比两边特征值。5.2 坑二DeepSeek 批量打标后标签大量重复现象跑完一万条客服会话发现 80% 的用户都打上了“追求性价比”标签。运营看一眼就知道这标签没法用。原因提示词里列举标签选项时的顺序影响了模型判断排在前面的选项容易被优先选择。另一个原因是 temperature 设置偏高模型在不确定时倾向于输出高频常见词而不是从文本实际推断。追“性价比”是最安全的选项模型选它最不容易错。解决抽取任务的 temperature 一律压到 0.1 以下提示词里不预置标签枚举列表让模型直接从原文字段命名输出后再映射到标签字典每次跑批后随机抽 100 条做人工复核确认标签重合度没有异常飘高。5.3 坑三全量文本打标Token 成本一个月翻五倍现象上线第一个月成本可控第二个月数据量翻倍账单直接失控。溯源发现客服会话和评论都有大量重复文本、超长文本被原封不动送进模型。原因抽取脚本没有做文本去重和长度裁剪。用户重复提交相同工单、多渠道同步同一评论这些重复流量都白白消耗了 Token。还有技术人员把整场客服对话全部放入上下文实际有效信息只有几句话。解决在模型调用前增加去重层用 MD5 做内容指纹命中缓存直接跳过对文本按对话轮次切割超过 2000 字一律先抽关键句。给每日 Token 消耗设预算护栏单日消耗超过阈值自动熔断半天等人确认后再放量。5.4 坑四模型输出“大家都爱高品质”——分布贴合但区分度差现象标签分布非常均匀大促期间用户购买转化也确实提升了但推荐位点击率没变化。看标签分布才发现超过 50% 的用户都集中在同一个偏好档位画像完全失去区分能力。原因偏好预测被建模成了分类问题而分类器在高频类别上倾向于输出安全答案。用户被预测为“高品质偏好”不会犯错但真拉到运营层面没有任何指导意义。解决把分类目标改成排序目标关注用户在各偏好档位上的相对顺序而不是绝对类别。评估指标用 AUC 和头部召回率不看准确率。标签输出时加百分比阈值闸门只保留前 30% 置信度的用户。5.5 坑五标签字典一更新历史画像全部作废现象运营调整了标签体系把“价格敏感度”从三档改成五档。所有历史表里的数据还在用旧档位新旧画像混在一起特征工程直接崩掉。原因标签字典没有做版本管理下游表不知道上游字典已经更换。离线任务回跑了新版本但在线服务还在读旧版本两边不一致。解决每一张画像表都写入标签字典版本号下游引用时必须携带版本。字典更新后旧版本保留一个月过渡期不物理删除。回刷只刷受影响分区而不是全量重跑。6. 画像上线前的验证方法三层离线校验与同期群实验最后一章说验证。画像系统上线前至少要过三个离线关卡和一轮在线实验不然上线后出了问题很难定位是画像问题还是策略问题。第一层是覆盖率校验。统计近 30 天有行为用户的画像标签覆盖率画像系统必须覆盖主要活跃用户群低于 60% 说明抽取链路丢数据。第二层是一致性校验。人工每周抽 200 条文本对照模型输出的标签看字段一致率是否稳定在 85% 以上低于这个值多半是提示词退化了。第三层是区分度校验。任意选一个标签按标签值分群比较群间的行为均值差异。一个有效的偏好标签群间差异应该是显著的。如果所有标签分群后行为曲线近乎重合这标签就没价值趁早干掉。在线环节我建议跑两周同期群实验。对照组用原策略实验组在推荐排序里混入画像偏好特征观察点击、加购和下单转化。跑完看提升显著性和分层效果别只看大盘均值。最后分享一个我自己的保留习惯每个生产画像版本上线前我都手动跑一遍 50 条样本的最小复现。输入原始文本、提示词、模型输出、下游特征四段贴在同一个文档里肉眼确认链路通顺再发上线。这个习惯让我躲开过至少三次提示词悄悄退化引发的线上事件。数据链路上多一道人工确认永远不是浪费时间希望这套方案能帮你少走几条弯路。本文还有配套的精品资源点击获取 DeepSeek电商用户画像构建：多源融合到偏好预测全链路实战
简介面向电商数据挖掘、用户增长及推荐算法工程师的深度学习实践资料聚焦多源数据融合的消费者行为分析与偏好预测。方案以DeepSeek技术路线为主线覆盖从数据采集、清洗、特征工程到知识图谱构建、用户画像标签体系与权重计算的全流程包含结构化与非结构化数据预处理、RNN/LSTM及Transformer行为序列建模等关键环节。资源为1个PDF文件大小11.51MB共213页50个大章节支持目录跳转与书签大纲定位文字图表清晰完整。目前已有81人学习适合正在搭建用户画像系统或优化偏好预测模型的读者参考。文档不仅给出架构设计与技术选型还包含具体实现策略与调优思路其中知识图谱嵌入、注意力机制及行为序列建模等章节配有模型选型与实现细节可直接迁移到实际项目帮助快速建立多源数据融合画像的整体框架。1. 213 页画像方案解决的核心问题多源融合与偏好预测的落地链路这份《DeepSeek电商用户画像构建方案》给我的第一印象不是 AI 原理课而是一条把「多源数据 → 融合特征 → 画像标签 → 偏好预测」全链路落进电商业务的数据工程方案。电商团队最常见的尴尬是交易数据在数仓、客服会话在工单系统、商品评论在评价库各归各运营想要一句“这个用户为什么买、下次还买什么”的判断却没人给得出来。213 页的篇幅对应的是链路每个环节的口径、参数和边界而不是模型排名。适合两类人读一类是要搭建画像系统的算法工程师另一类是要给推荐、营销、客服策略提供用户理解的策略产品经理。2. 多源数据融合设计从 ID 打通到画像口径的完整链路用户画像的最底层不是标签是数据。多源数据融合的核心也不是把数据堆在一起而是让每一份数据在画像里承担明确角色。先分清楚数据源再谈打通和口径。2.1 电商多源数据有哪几类各自的画像价值我一般把数据源按“行为确定性”分成四层交易层、行为层、文本层、履约层。分层决定了你在画像链路里给它的置信度权重。数据源典型字段画像价值坑点交易订单SKU、类目、价格、数量、支付时间最强信号代表真实购买偏好低频只有下单才产生行为日志浏览、点击、搜索、收藏、加购、停留时长高频反映即时兴趣强度噪声大误点、爬虫、比价行为混在一起客服会话与评论会话文本、评价文本、售后原因显式诉求和隐式偏好的金矿非结构化需要 NLP 抽取履约与售后收货地址、退货单、取消单辅助判断消费力和决策风格字段敏感脱敏后可用度下降这里有个容易忽略的点交易层适合做“事实标签”行为层适合做“兴趣强度标签”文本层则贡献了大量交易和行为里看不到的“意图标签”。比如用户问客服“这个能不能放新生儿房间”这个句子本身就包含了购买阶段、场景人群、决策顾虑三层信息但传统 RFM 模型完全读不到。DeepSeek 在这份方案里的价值正是集中处理文本层和半结构化的行为描述。2.2 跨端 ID 打通与实体对齐的常见做法多源数据融合最先翻车的通常是 ID 打通。用户在小程序登录一次、App 登录一次、H5 页面匿名逛了一圈三份记录的 user_id 完全不同。常见做法是建一张 ID mapping 表用设备 ID、手机号、登录账号、支付账号作为关联键做实时与离线两种打通。离线场景我推荐用图对齐的方式把已知的登录 UID 作为主键其他 ID 作为辅助节点用共同收货人、共同设备、共同支付账号这样的关系做连通分量归并。这比两表 join 更稳健因为用户的行为路径往往跨端。实时场景则只查高频映射缓存避免在线链路里做重归并。商品侧也有实体对齐问题。同一个商品在自营标题里叫“婴儿床实木免漆”在第三方店铺叫“实木婴儿床无味”如果不做实体归一画像里就会出现两个看似不同的类目兴趣。我的做法是维护一份商品主数据表以内部 SKU 为键把各渠道标题、类目、品牌、规格属性映射回去只有映射不上的长尾商品才交给模型做语义匹配。2.3 画像口径设计标签命名、时效与覆盖规则口径设计是画像体系最容易埋雷的地方。没有统一口径离线画像和在线服务各算各的最后模型训练和线上策略用的根本不是同一份标签。我建议每一张画像标签表提前固定这些字段标签名、标签值、置信度、最近一次命中时间、统计窗口、标签字典版本。统计窗口必须写清楚是近 7 天、近 30 天还是全部历史。覆盖规则要硬性规定行为样本不足的用户不能打标签宁缺毋滥。这样才能保证画像从一开始就是可审计的。标签命名也要规范。类目偏好用“pref_category:母婴:奶粉”这种三段式价格敏感度用“price_sensitivity:high”。不推荐中文自由文本因为下游特征工程要稳定枚举。标签字典版本号尤其重要后面避坑章节会专门展开。3. DeepSeek 接入与语义标签抽取部署选型、API 调用与边界约束数据融合完画像从哪一步交给 DeepSeek这里有一个关键判断不是让大模型端到端生成画像而是让它只负责“文本理解”这一段。3.1 DeepSeek 在画像体系里承担什么角色我把画像生成链路拆成三个阶段规则清洗、语义标签抽取、偏好预测。DeepSeek 放在中间只处理非结构化文本到结构化标签的转换。为什么不端到端因为画像系统要稳定上线、要解释标签来源、要支持人工复核端到端生成的黑匣子很难满足这些工程约束。具体到任务DeepSeek 承担四类活儿从客服会话里抽用户显式诉求从商品评论里抽使用场景和售后体验从搜索词里抽购买意图和决策阶段再给跨渠道路径做语义聚类。输出统一是 JSON 结构化标签下游特征工程不关心文本原文。从 LLM 和 AI Agent 的边界来说DeepSeek 属于模型层它本身不负责调度。真正上线时模型外面还要套工作流编排层把“读取文本 → 调模型 → 校验输出 → 写标签表”串起来也就是常说的 harness 机制。模型负责判断编排层负责任务调度、重试和幂等保障。3.2 本地部署、API 调用与工作流 harness 怎么选接入方式有三种常见选择。第一是 API 调用适合快速验证和中小规模标签抽取团队不需要维护推理集群直接在开放平台建应用拿密钥就能跑。第二是本地部署适合用户会话数据敏感、不允许出域的电商团队代价是要自己维护显存和推理服务。第三种是把前两者包装在工作流 harness 里适合标签量级大、需要批处理和重试的线上环境。我看到的真实落地路径通常是先用 API 跑通 1 万条验证数据确认识别效果和成本再决定要不要本地化。本地部署的好处是数据完全在内网流动隐私合规压力小坏处是压测和版本升级都变成 Ops 团队的长期负担。开发阶段我习惯在 VS Code 里直接配 DeepSeek API 来调试特征 SQL 和抽取提示词改一版提示词立刻跑一批样本看输出比每次走完整调度快很多。等到任务稳定了再把这套逻辑搬进 harness 里做成定时任务。3.3 从客服会话和评论里抽取偏好标签最小可运行脚本下面是我在电商场景里常用的一段调用逻辑。接口兼容 OpenAI 的 chat completions 风格关键是把输出强制成 JSON 并压低随机性。from openai import OpenAI client OpenAI( base_url你的API网关地址, api_key你的密钥 ) system_prompt 你是电商用户画像语义抽取服务。 输入是客服会话的一轮或多轮文本。 请抽取以下字段只输出 JSON不要解释 - explicit_needs: 用户明确说出的功能或服务需求没有则为 null - implicit_preference: 用户对价格带、品牌、外观、物流、售后等的隐含偏好 - purchase_stage: browse / compare / decision / after_sale - negative_feedback: 用户表达的不满点没有则为 null 要求对没有依据的字段输出 null不要推测。 user_text 这个推车能不能一键收车我平时一个人带娃出门太重的不行最好轻一点。 resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_text} ], response_format{type: json_object}, temperature0.1, max_tokens300 ) print(resp.choices[0].message.content)这段代码逻辑不复杂参数却有讲究。temperature 我固定给 0.1不取 0 是为了避免极端贪心导致的模板化输出但超过 0.3 标签就开始飘。response_format 强制 json_object否则输出里混进解释性文字下游解析器会反复报错。max_tokens 给 300 对单条文本足够对超长对话要按会话轮次先切块不能整体灌给模型。实际批处理时我不会对每条文本单独请求而是按用户会话聚合后再请求一个用户一次请求返回全部标签。这样能明显降低 Token 消耗也降低了下游拼接特征时的复杂度。3.4 Token 成本与批处理去重控制预算的三个手段语义标签抽取的成本大头通常在三个地方重复文本重复打标、超长文本全量打标、提示词里塞太多示例。控制方法分别是内容去重、长度裁剪、少样本精简。文本去重我直接用原文 MD5同一条评论或会话在多个渠道出现时只打一次标。长度裁剪要把输入限制在有效范围比如客服会话只取用户侧发言和最近两轮店员回复不需要完整历史。少样本示例每类任务不超过两条示例太多会显著增加每批次 Token 开销但不会成比例提升效果。还有一个容易忽略的成本陷阱数据库里同一个用户在不同订单里写相同评论。这种文本如果不做去重一个用户重复消耗几十倍 Token 却只产出同一份标签。去重放在抽取前不是在模型调用后。4. 画像到偏好预测特征工程、模型融合与冷启动补齐标签系统建好之后下一个问题是画像怎么用到推荐和营销里。这一步本质是把标签转成特征再让模型或规则做偏好预测。4.1 画像标签转特征矩阵密度、时效与行为统计画像标签不能直接送进模型。原因有两个一是标签是稀疏枚举值直接 one-hot 会让特征维度爆炸二是标签本身缺少强度信息无法区分“昨天刚加购”和“三个月前看过”。我常用的转换模式是三通道标签命中通道0/1、标签强度通道近 30 天命中次数、标签时效通道距最近命中的天数做指数衰减。三个通道加起来才是一个完整的特征表达。import json def build_label_features(label_records, now_ts): features {} recent_days 30 for item in label_records: label item[label] hit_ts item[hit_ts] count item[count_30d] # 时效衰减 gap_days (now_ts - hit_ts) / 86400.0 decay max(0.0, 1.0 - gap_days / recent_days) # 特征命名带清窗口前缀方便回溯 features[flabel_30d_{label}_hit] 1.0 features[flabel_30d_{label}_count_log] round((count ** 0.5), 4) features[flabel_30d_{label}_decay] round(decay, 4) return features特征命名里带窗口前缀很重要。线上服务读特征的时候如果只认标签名不认窗口新旧口径就会混用。count 做开根号而不是取 log是为了避免大量 0 值导致特征分布过偏。这个阶段的常见误操作是把画像标签当成最终模型特征直接灌进 LightGBM。结果是模型训练时特征重要性飘忽不定同一个标签今天排第一明天排不上。原因往往在于标签时效通道缺失模型学到的只是“用户有过这个标签”而不是“用户最近还对这个东西热不热”。4.2 偏好预测的两层做法规则校准与行为序列模型偏好预测我推荐两层结构而不是一个复杂模型解决所有问题。第一层是可解释规则层负责处理高频、确定性强的偏好。比如“近 30 天搜索母婴类目超过 5 次且加购 2 次判定为母婴品类偏好”这种规则运营看得懂出了问题也追得到。第二层是行为序列模型处理规则覆盖不了的长尾和跨类目迁移。输入是用户近 N 次行为序列浏览类目、加购类目、价格带、渠道输出是下一个可能购买的类目概率。模型不必复杂序列维度在 50 以下时一个 embedding 加注意力层就够用。这两层的关系不是模型替代规则而是互相校准。如果规则判定用户偏好母婴而序列模型给出的是美妆高概率通常说明两种情况用户可能是代购或送礼也可能是规则的时间窗口太长捕捉到了历史偏好但没反映当前兴趣。这时候要人工看案例而不是盲目信模型。价格带敏感度预测也是同样套路。规则层用客单价、优惠券使用率、比价行为判断模型层用序列里商品价格分布做回归预测。两个结果都输出在策略侧取交集比单独用任何一层都稳定。4.3 冷启动用户的画像补全种子匹配与语义迁移冷启动用户没有历史行为任何模型都无能为力但我们不能直接给空画像。常见做法是种子用户匹配把新用户注册时的渠道、设备、访问落地页、首搜关键词作为弱特征去找相似的老用户群把老用户群的高频标签迁移过来。这里的关键不是迁移准确率而是迁移可解释性。我给冷启动用户打标签时会额外加一个字段“source: seed_migration”这样运营看到冷启动画像能知道这不是真实行为而是相似人群迁移不会拿它当强信号做高成本运营动作。5. 画像落地避坑5 个高频异常与根因定位这一章是这套方案落地时最容易翻车的五个地方每条都按现象、原因、解决三步写清楚。5.1 坑一离线画像很丰满线上特征对不上现象离线评估跑得很漂亮标签覆盖率高可一到线上推荐服务特征读取总是空值策略效果直线下滑。原因离线画像每天凌晨跑批写入的是 T-1 数据线上服务读的却是近 24 小时的实时标签表。两边各自维护一套口径标签名一样含义和时间窗口完全不同。模型离线训练赢了线上推理读不到对应特征。解决把画像口径统一成一份 JSON 配置离线跑批和在线服务都读同一份文件。新增标签也通过配置发布不允许两边各加各的。上线前做一次离线在线特征一致性校验随机抽 1000 个用户对比两边特征值。5.2 坑二DeepSeek 批量打标后标签大量重复现象跑完一万条客服会话发现 80% 的用户都打上了“追求性价比”标签。运营看一眼就知道这标签没法用。原因提示词里列举标签选项时的顺序影响了模型判断排在前面的选项容易被优先选择。另一个原因是 temperature 设置偏高模型在不确定时倾向于输出高频常见词而不是从文本实际推断。追“性价比”是最安全的选项模型选它最不容易错。解决抽取任务的 temperature 一律压到 0.1 以下提示词里不预置标签枚举列表让模型直接从原文字段命名输出后再映射到标签字典每次跑批后随机抽 100 条做人工复核确认标签重合度没有异常飘高。5.3 坑三全量文本打标Token 成本一个月翻五倍现象上线第一个月成本可控第二个月数据量翻倍账单直接失控。溯源发现客服会话和评论都有大量重复文本、超长文本被原封不动送进模型。原因抽取脚本没有做文本去重和长度裁剪。用户重复提交相同工单、多渠道同步同一评论这些重复流量都白白消耗了 Token。还有技术人员把整场客服对话全部放入上下文实际有效信息只有几句话。解决在模型调用前增加去重层用 MD5 做内容指纹命中缓存直接跳过对文本按对话轮次切割超过 2000 字一律先抽关键句。给每日 Token 消耗设预算护栏单日消耗超过阈值自动熔断半天等人确认后再放量。5.4 坑四模型输出“大家都爱高品质”——分布贴合但区分度差现象标签分布非常均匀大促期间用户购买转化也确实提升了但推荐位点击率没变化。看标签分布才发现超过 50% 的用户都集中在同一个偏好档位画像完全失去区分能力。原因偏好预测被建模成了分类问题而分类器在高频类别上倾向于输出安全答案。用户被预测为“高品质偏好”不会犯错但真拉到运营层面没有任何指导意义。解决把分类目标改成排序目标关注用户在各偏好档位上的相对顺序而不是绝对类别。评估指标用 AUC 和头部召回率不看准确率。标签输出时加百分比阈值闸门只保留前 30% 置信度的用户。5.5 坑五标签字典一更新历史画像全部作废现象运营调整了标签体系把“价格敏感度”从三档改成五档。所有历史表里的数据还在用旧档位新旧画像混在一起特征工程直接崩掉。原因标签字典没有做版本管理下游表不知道上游字典已经更换。离线任务回跑了新版本但在线服务还在读旧版本两边不一致。解决每一张画像表都写入标签字典版本号下游引用时必须携带版本。字典更新后旧版本保留一个月过渡期不物理删除。回刷只刷受影响分区而不是全量重跑。6. 画像上线前的验证方法三层离线校验与同期群实验最后一章说验证。画像系统上线前至少要过三个离线关卡和一轮在线实验不然上线后出了问题很难定位是画像问题还是策略问题。第一层是覆盖率校验。统计近 30 天有行为用户的画像标签覆盖率画像系统必须覆盖主要活跃用户群低于 60% 说明抽取链路丢数据。第二层是一致性校验。人工每周抽 200 条文本对照模型输出的标签看字段一致率是否稳定在 85% 以上低于这个值多半是提示词退化了。第三层是区分度校验。任意选一个标签按标签值分群比较群间的行为均值差异。一个有效的偏好标签群间差异应该是显著的。如果所有标签分群后行为曲线近乎重合这标签就没价值趁早干掉。在线环节我建议跑两周同期群实验。对照组用原策略实验组在推荐排序里混入画像偏好特征观察点击、加购和下单转化。跑完看提升显著性和分层效果别只看大盘均值。最后分享一个我自己的保留习惯每个生产画像版本上线前我都手动跑一遍 50 条样本的最小复现。输入原始文本、提示词、模型输出、下游特征四段贴在同一个文档里肉眼确认链路通顺再发上线。这个习惯让我躲开过至少三次提示词悄悄退化引发的线上事件。数据链路上多一道人工确认永远不是浪费时间希望这套方案能帮你少走几条弯路。本文还有配套的精品资源点击获取