我在前年接手了一个内部用户画像分析子系统建设的项目第一个月几乎每天都在跟一张几十个字段的标签宽表搏斗。表里写着用户A的性别、年龄、品类偏好、消费等级但当我问“这个用户为什么会有这个偏好”“跟他行为模式最像的一批人是谁”的时候这套表答不上来。后来我们换了思路把用户画像的主体从标签宽表换成了知识图谱用图结构去表达用户、商品、品牌、设备、地址、社群之间的关系标签从原来的“贴上去”变成“推理出来”整个画像系统的分析能力一下子打开了。这篇文章就围绕知识图谱做用户画像这件事把整体设计、图建模、标签生产、系统建设、常见坑一次讲清楚适合刚准备做画像系统或想改造现有标签平台的工程师、产品经理和数据分析师。1. 为什么用知识图谱做用户画像从标签卡片到关系网络1.1 传统标签画像的三个硬伤大部分人做用户画像第一反应就是建标签宽表一个用户一行性别一列、年龄一列、近30天购买次数一列、偏好品类一列。这套方案在业务简单、数据量可控的时候完全够用报表也能出推荐也能跑。但一旦业务复杂度上来三个问题会非常明显。第一个问题是标签之间是割裂的。宽表里每一列都是独立计算出来的但真实世界里用户的各个属性是互相影响的。比如一个用户近30天买了三次高端护肤品宽表会给他打上“高客单价”和“美妆偏好”两个标签但这两个标签之间的因果关系、行为链路完全看不到。如果这个用户其实是给女朋友买的那“美妆偏好”这个标签就失真了而宽表模型里没有手段去发现这种失真。第二个问题是关系表达能力为零。画像不只是“用户是什么人”更应该是“用户和什么有关”。一个用户经常跟另一个用户在同一时间出现在同一门店宽表看不出来一个用户跟某个品牌的高管有社交关系宽表也看不出来。但这些东西对营销、风控、推荐来说恰恰是最有价值的信号。第三个问题是标签更新慢、实时性差。传统标签一般是T1跑批出结果之后写回宽表查询走KV或者关系型数据库。业务想临时加一个口径得重新跑全量扩展成本很高。而图谱模型里新关系可以增量写入新标签可以通过已有关系实时推理出来响应速度快得多。所以不是“标签模型过时了”而是当你想把画像做得更细、更智能、更贴近业务真实逻辑的时候宽表模型的天花板很明显。知识图谱不是替代标签系统而是在标签系统之上长出一层关系分析能力。1.2 知识图谱解决的核心问题关系、推理、动态演化知识图谱本质上是用图的数据结构去建模现实世界核心元素就两个节点和边。节点代表实体比如用户、商品、品牌、门店、设备边代表关系比如“购买”“浏览”“同地址”“同一设备登录”。你可以在节点上挂属性也可以在边上挂属性比如一个“购买”关系可以带“最近购买时间”“购买金额”“购买频次”这些属性。跟宽表相比图谱做画像有三个层面的优势。第一是关系天然可视、可查、可分析。你问“用户A为什么被打上母婴偏好标签”宽表只能给你一个计算脚本图谱可以直接把一条路径展示出来用户A近期购买过两罐奶粉而跟他使用同一个收货地址的用户B经常购买婴儿纸尿裤。这条路径就是一个完整的业务解释营销、运营看到这种解释也会更信任画像。第二是支持多跳推理。宽表只能表达“用户直接买了什么”图谱可以表达“用户的好友在关注什么”“和用户同社群的用户最近在聊什么”。这些间接信号在很多场景下比直接信号更稳定、更有区分度。比如一个新用户刚注册没有任何购买行为标签系统拿他没办法但图谱里他绑定了同一个设备下的老账号老账号有清晰的消费偏好这个新用户的冷启动标签就能通过关系传播过来。第三是动态演化能力强。人的兴趣会变关系也在变。宽表的列一旦定下来改结构很痛苦图中加一种新的边类型等于加一种新关系不需要改表结构可以增量插入。今天发现“共同加入微信群”是一个很强的信号那就新增“同群”边几小时就能上线。做图谱画像目标不是把宽表换成图库这么简单而是把整个思维模式从“特征拼接”换成“关系推理”。这也是后面所有建模、算法、系统设计的主线。2. 数据基础与图谱建模画像数据从哪来、怎么建模2.1 数据源梳理与ID-Mapping打通做图谱画像是从数据开始的。首先要把所有能描述“实体”和“关系”的数据源梳理清楚。我做这个项目时数据源大体分五类行为数据、业务数据、账号数据、客服/社交数据、线下IoT数据。行为数据包括App埋点、小程序事件、H5访问日志能产出“用户-浏览/点击/搜索-商品”这类关系。业务数据包括交易订单、售后单、优惠券核销、会员权益能产出“用户-购买-商品”“用户-领取-优惠券”这类关系。账号数据是ID-Mapping的核心包括设备ID、手机号、微信UnionID/OpenID、邮箱、收货手机号、身份证加密串。客服和社交数据往往最容易被忽视但价值很高。客服对话里能抽出用户的投诉对象、售后商品、情绪倾向企业微信聊天记录、社群关系能产出“用户-同群-用户”的边。线下IoT数据可能包括门店Wi-Fi探针、门店POS、智能设备使用记录能产出“用户-到店-门店”“设备-使用-家电”这类边。数据源理清楚之后最难的一件事是ID-Mapping。同一个用户可能在不同系统里有完全不同的ID电商系统里有uid埋点系统里有设备指纹微信生态里有UnionID线下POS里可能就是手机号。如果这些ID对不上图谱里就会出现很多重复的用户节点画像全乱。我的建议是先做一张“统一身份ID映射表”这是图谱的地基。映射表的核心逻辑是把多个弱标识通过规则合并成一个全局ID一般叫gid。常见合并规则包括同一设备ID关联的账号归并同一手机号注册的账号归并同一收货地址同一收货人姓名归并同一微信UnionID归并。归并时要特别小心收货地址这种信号有很强的关联性但也容易误伤比如公司前台地址会合并几百人必须加“收货人姓名相同”这种条件再归并。这一步走完后面所有实体才有的放矢。ID-Mapping不是一次性工作它会持续有新的ID进来所以要把它设计成每天可增量更新的任务配合人工校验抽样来保证精度。2.2 实体、关系与属性表设计建模之前先想想业务到底要回答什么问题。画像系统要回答的问题通常有这个用户是谁、喜欢什么、容易受谁影响、和谁是同一个圈层、下一步可能买什么、流失风险多高。这些问题决定了你要建模哪些实体和关系。我先列一个最常用的实体清单用户User画像的核心主体节点上挂gid、注册时间、渠道来源、会员等级。设备Device手机、Pad、IoT设备通过设备指纹标识。商品Product挂类目、品牌、价格带、上架时间。品牌Brand挂品牌等级、主营类目。品类Category挂在商品上用于把商品偏好归纳成品类偏好。门店/仓Store挂城市、商圈、店型。订单Order挂金额、时间、订单状态把用户和商品连接起来。社群/群组Group企业微信群、兴趣社群等。实体之间需要定义带方向的关系我建议前期不要贪多先把业务解释力最强的几类边做扎实。我项目里先落地的关系只有十一类关系类型起点终点主要属性浏览用户商品最近浏览时间、近30天次数、停留时长搜索用户品类最近搜索词、搜索频次收藏用户商品收藏时间加购用户商品加购时间、加购件数购买用户订单下单时间、金额、支付方式属于订单商品件数、实付金额、优惠金额生产品牌商品上市时间归属商品品类标准类目同设备用户用户设备类型、首次共现时间同地址用户用户地址标签、共现次数同群用户用户群ID、共同群数关系属性非常重要不要只建边不加属性。比如“同设备”这条边如果没有任何属性它会变成一个弱信号因为一台公用设备可能连着几十个账号。加上“设备类型”和“首次共现时间”之后就能设计规则只有近7天共现、且不是营业厅公用设备时才把边强度调高。图模型里一条边有没有业务含义往往就取决于这些属性有没有设计到位。属性表的设计上节点和边都要支持扩展属性。生产上我习惯用JSONB或者Map字段来存非结构化属性方便随时加字段不用每次改Schema都做一次全量迁移。3. 从图谱推理到标签生产核心实操拆解3.1 实体构建与离线图加工链路图谱搭建的链路本质上是一条离线数据管道每天把ODS层的业务数据加工成图谱里的实体和边。我用的是一条非常标准的链路ODS - DWD - DWS - 图存储。在ODS层原始数据原样入仓不加任何逻辑。到DWD层做清洗和标准化包括去除无效埋点、修正时区、统一单位、解析URL参数。DWS层做主题汇总产出“用户-商品-行为指标”这类宽表层数据然后再把DWS的汇总结果转成图谱需要的实体文件、关系文件。实体文件的格式一般是CSV或Parquet一行对应一个节点字段包括节点ID、节点类型、关键属性JSON。关系文件则是一行对应一条边字段包括起点ID、终点ID、关系类型、关系属性JSON。这两类文件做好之后通过图数据库的批量导入工具写入。批量入图之后还有三类加工任务要跑。第一类是实体去重。即使做了ID-Mapping还是可能有少量重复节点。我用的是规则图联通分量算法双重校验发现两个节点高度相似比如同手机号、同地址、同设备就合并成一个所有边也做一次重映射。第二类是边合并与权重归一。同一个用户和同一个商品之间可能既有浏览边又有加购边有搞头的是把它们合并成一条综合边边权重按行为价值和最近时间加权计算。比如购买权重5加购权重3收藏权重2浏览权重0.5。然后按天做时间衰减30天前的行为乘以0.560天前的乘以0.25最终得到每条边的综合强度。这个强度系数后面所有图算法都会用。第三类是关系推理补边。基于已有的事实边生成高层级的关系。比如用户A和用户B都经常购买同品牌同品类的商品且存在同群关系可以推导出“A和B属于同一兴趣圈层”用户A的收货地址和用户B相同可以推导出“A和B有家庭关系嫌疑”。补边规则要输出到一张“推理边日志表”方便后续回溯和下线不能直接覆盖原始边。这套加工链路做熟之后每天全量跑一次大概需要几个小时增量任务控制在半小时内基本能支撑第二天早上所有画像查询和推荐任务使用。3.2 图算法在画像标签上的落地社区发现、标签传播、影响力计算图谱数据就位后真正让画像“活”起来的是图算法。我实测下来有三个算法在画像场景里最常用也最出效果。第一个是社区发现Louvain用于圈层划分。Louvain算法会把关系紧密的用户群体聚成一个个社区每个社区可以理解为一个“兴趣圈层”或“关系群”。跑完Louvain之后我们给每个社区计算群体画像比如这个社区里品类偏好分布、价格带分布、活跃时段分布。然后给社区内的用户打上“圈层标签”比如“母婴群体”“数码发烧友”“健身打卡族”。这个标签比从单用户行为算出来的标签稳健得多因为它是群体共识受单次行为噪声影响小。第二个是标签传播LPA用于冷启动标签扩散。新用户没有足够行为数据时传统模型很难判断偏好但图中他可能跟很多老用户有关系。用标签传播算法把老用户已有的偏好标签沿边传播到新用户上传播强度受边权重控制。比如一个新用户和某个老用户共用过设备、又在同一个社群里老用户有“咖啡重度爱好者”标签新用户就会以较高置信度继承这个标签。实测下来这个方案能把冷启动用户的可打标签覆盖率从不到20%提升到60%以上。第三个是影响力计算PageRank或自定义的传播打分用于识别KOL和“高影响用户”。把用户间的关注、点赞、同群、聊天互动等关系建模成有向加权图跑PageRank算法给每个用户一个影响力分。这个分值可以筛选出“对周围人购买决策影响较大”的用户后续做社交裂变活动和定向种草时直接圈选这批人效果比广撒网好很多。图算法跑完不是终点要把算法结果沉淀成“派生标签”。生产上我会把每个算法的输出结果存成独立的任务表里面包含gid、算法类型、算法结果、置信度、计算日期。这些派生标签可以提供给下游做筛选人群包也可以写回图谱作为新的节点属性形成正向循环。3.3 标签权重与置信度的计算逻辑图谱画像标签不能只有“有/没有”这种二元状态那样跟宽表标签没有本质区别。有价值的标签一定要带权重和置信度。权重描述的是“这个用户对这个标签的贴合程度”置信度描述的是“这个权重值到底可不可信”。我用的是一个非常朴素但有效的公式标签权重 原始行为得分 × 时间衰减因子 × 关系增益因子原始行为得分把行为按价值分级购买得5分、加购得3分、收藏得2分、浏览得0.5分同一次会话里的重复行为要去重防止刷量。时间衰减因子采用指数衰减T表示行为发生距今天数factor exp(-λ × T)。λ取0.01表示30天后权重约衰减到0.7490天后约0.41符合“近期兴趣权重更大”的直觉。关系增益因子如果用户在图谱中跟N个强关系用户共享同一标签且这些用户的置信度都较高那么在1到3之间给用户加权。具体取min(1 0.2 × 强关系人数, 3)防止关系太多导致权重爆掉。弱关系不做增益否则会把噪声也放大。置信度我拆成两部分统计置信度和关系置信度。统计置信度由行为覆盖度和行为一致性决定。覆盖度表示标签对应行为的种类数比如“美妆偏好”标签覆盖了浏览、搜索、购买三类行为置信度就比只要购买一类行为的高。一致性表示多类行为指向是否一致如果用户浏览的是平价美妆、购买的是贵妇美妆那“高端美妆偏好”这个标签的一致性就差置信度要打折。关系置信度衡量的是标签是真实行为得出的还是通过图谱传播得出。直连边得出的标签置信度设为0.9经过一跳传播的设为0.7两跳传播的设为0.5超过三跳不再传播。传播置信度还要乘上路径上每条边的权重乘积多路径取最大值。标签的阈值也不是拍脑袋定的。我习惯先用历史数据做分布分析找top20%用户的标签权重作为高置信区间然后按业务目标去调阈值。比如营销场景要更精准阈值调高一点宁缺毋滥推荐场景要覆盖度阈值调低一点宁可多推几种可能性。4. 用户画像分析子系统建设存储、查询与服务化4.1 图存储选型Neo4j还是JanusGraph图谱数据加工完之后要落地到图数据库里对外提供服务。这一步选型很关键我对比过Neo4j、JanusGraph和阿里云GraphScope等最后根据业务阶段做了两套方案。小规模、快速验证阶段直接用Neo4j社区版。Neo4j的Cypher查询语言对业务同学很友好表达“两跳好友”“用户到品牌的最短路径”这类问题非常直观。部署简单自带图形化界面调试方便。缺点是单机横向扩展能力有限数据量到亿级节点以上时性能下降明显适合做PoC和中小规模生产。大规模、分布式场景用JanusGraph。JanusGraph是开源的分布式图数据库底层存储可以接HBase、Cassandra等索引接Elasticsearch。优点是能水平扩展支持数十亿节点缺点是需要比较强的分布式运维能力查询语言是Gremlin学习成本高。最初直接用JanusGraph在存储层和索引层踩了不少坑主要是ES索引同步延迟导致查询漏数据。我给出的选型建议是初期用户量在千万级以内、关系不算太复杂先用Neo4j把业务跑通后期再迁移到分布式方案。还有一个折中方案离线分析用Spark GraphX或TigerGraph在线查询用Neo4j做单点/短路径查询两边通过离线任务同步。4.2 画像服务API设计关系查询、路径分析、群组画像子系统建成之后暴露给上层业务的不应该是一堆图查询语句而应该是标准化的HTTP接口。我们围绕画像查询设计了三类核心API。第一类是基础画像查询接口GET /v1/profile/{gid}。返回用户的静态属性标签列表、动态行为标签列表、群组标签列表每条标签都带权重和置信度。这个接口主要供CRM系统、客服工作台、小程序个性化展示使用。第二类是关系查询接口GET /v1/graph/relations?gidxxxrelation_typehigh_similar_user。返回该用户在图谱中的强关联用户、共享关系类型、路径详情。业务方拿这个接口做“找同路人”营销比如给一个高价值用户关联的相似用户发同样优惠券。第三类是路径分析接口GET /v1/graph/path?source_gidxxxtarget_entity_idyyytarget_typebrand。返回两个实体之间的最短路径、权重最高路径和路径上的关键边。这个接口非常实用比如判断某个用户跟竞品品牌之间有没有可能产生联系的桥梁人。接口返回统一走JSON格式所有内部实体ID必须脱敏统一转成业务侧用的ID。我在生产上遇到过一个大坑把真实的设备号、手机号直接拼进API返回下游日志一打用户隐私全出去了。后来统一加了一层ID转换服务内部ID只在内网传播对外一律使用映射ID。4.3 更新策略与性能优化图谱画像系统的更新策略我采用“离线T1 在线事件驱动”双轨模式。离线T1负责处理全量重算每天凌晨跑批量任务把新增的实体和边写入图库同时更新标签权重和置信度保证每天早上业务方拿到的画像是最新的。在线事件驱动负责处理实时性强的关系比如用户刚在App里完成一次购买通过消息队列触发增量更新把这条“购买”事件实时写入图库更新该用户相关标签。性能优化是子系统建设里最实际的部分。图查询很容易出现“查询很爽、性能崩盘”的情况尤其是多跳查询数据量一大就超时。我优化时用了三招。第一招是物化热门子图。把最高频查询的路径预计算好存储成独立的物化视图查询直接读视图不回源图库。比如“用户-最近浏览商品-商品所属品牌”这个三跳路径是推荐场景最高频的查询直接物化掉查询耗时从几百毫秒降到十几毫秒。第二招是加Redis缓存。所有查询接口都做多级缓存热点用户名下的画像缓存5分钟一般用户缓存30秒冷数据不缓存。缓存命中率高的时候整体接口P99延迟能压到50毫秒以内。第三招是控制查询深度和返回条数。生产环境不允许跑无限深度的查询最多限制五跳返回路径限制top10避免一次性返回成千上万条路径把服务打挂。限制在业务侧要提前说清楚不然下游会拿一个五跳查询天天打你的接口。5. 常见问题与排查技巧实录5.1 高频问题速查表我把做图谱画像这一年多遇到的典型问题整理成了一个速查表基本覆盖了大部分排查场景。问题可能原因排查方向画像标签覆盖率突然下降ID-Mapping规则变更导致大量用户无法关联检查新上线规则样本回看映射表归并率图查询接口超时未控制查询深度或热门子图未物化看慢查询日志补物化视图社区发现结果不稳定边权重波动太大或入图数据存在重复边检查边合并逻辑加权重平滑冷启动标签置信度虚高标签传播迭代次数过多全图标签同质化限制传播跳数调低关系增益上限部分用户画像长期为空原始数据里该用户只有单一弱ID补强ID-Mapping增加线下数据接入图谱数据量膨胀严重边类型设计过细或无效关系未清理设置边TTL下线低价值关系每个问题背后都有具体案例。比如“社区发现结果不稳定”我们最开始跑Louvain算法时连续三天的社区划分结果完全不同业务方根本没法用。后来排查发现是行为边权重没做平滑用户某天偶然产生一次大额购买边的权重就会暴涨直接带偏社区结构。最终在入图前对边权重做了对数归一化并加了7天滑动平均社区划分才稳定下来。5.2 实战避坑心得五个“我踩过之后才明白”的原则第一别试图一开始就把关系建模得很全。我们第一版设计定义了四十多种边结果数据加工链路复杂度失控很多边根本没有稳定的数据源上线后一直在维护垃圾数据。后来砍到十来种核心边质量立刻上来了。关系建模的准则是宁可少但精每一条边上线前都要能回答“它服务于哪个业务问题”。第二不要迷信图数据库的“实时查询”。图数据库在OLTP场景下很强但你在上面跑全图分析就是灾难。全图聚类、全网PageRank这类任务拿到Spark GraphX或者专门图分析平台上去跑结果写回图库千万别拿OLTP库去硬算。第三ID-Mapping是最高优先级的工程没有之一。图谱画像是建立在“节点唯一”基础上的ID打不通后面所有算法都在处理错误的对象。我甚至建议把ID-Mapping的准确率作为上线卡点准确率低于99%不允许进入下一步。第四隐私合规要从第一天就做不要等到出事了再补。所有用户ID加密存储、对外脱敏、敏感标签比如疾病、政见、性取向直接不做。宁可放弃一些画像维度也不能踩红线。这里说的不是我小心而是这条线一旦失守整个系统都会被下架整改。第五先讲业务价值再做技术炫技。很多团队做知识图谱项目最后没落地是因为一直在造“图谱平台”业务方看不到价值。我的做法是选一个最痛的点切入比如“高价值用户流失预警”把图谱、算法、服务全串起来做到能上线拿到业务方认可之后再逐步往其他场景复制。从小切口切入再扩展是知识图谱项目能活下来的关键。最后再分享一点个人体会做知识图谱用户画像这一年多我最深的感受是不要把图谱当成一个“数据库”而要当成一种“思考方式”。宽表把用户拆成互不相关的特征图谱把用户放回一个动态的关系网络里。后者更接近真实世界也更能支撑复杂的业务判断。如果你的团队正准备做类似的子系统我的建议是先从数据梳理和ID-Mapping做起别急着上算法。数据基础不打牢后面每一步都在还债。先搞定一张干净、准确的用户关系网再谈图算法、标签推理、实时服务才是一条走得通的路。