做了多年信贷风控我越来越觉得“用户画像”这个词已经被用滥了。很多人拿一堆标签就开始搭画像平台、做数据看板最后业务方问一句“然后呢”项目就卡住了。信贷领域的用户画像本质上不是用来“看”的而是用来“算”和“决策”的。它的核心任务只有一条把一个人有没有能力还钱、愿不愿意还钱、当前风险有多大翻译成机器能读取、策略能落地的结构化标签。这篇文章不打算讲那种虚的“画像平台”而是想结合我自己的落地经验把画像从数据设计、标签加工、模型使用到业务联动的完整链路拆开。正在做信贷风控、数据产品、策略运营的朋友可以参考里面很多实操细节和踩坑教训能少走点弯路。1. 信贷用户画像先搞清楚它到底在画什么1.1 画像的本质是风险翻译不是用户写真很多刚入行的同学会把用户画像理解成“给用户做人物侧写”比如兴趣爱好、消费偏好、活跃时段这些。这种东西在电商广告里很常见但在信贷场景里逻辑完全不一样。信贷用户画像不是写真而是风险翻译。你画的每个人最终都要落回一个核心问题这笔钱借出去对方按时还款的概率有多大所以同一个行为在不同场景下解读完全相反。比如“经常换手机”在消费画像里可能代表时尚敏感、购买力强但在信贷画像里往往需要警觉频繁更换设备可能意味着多头借贷、账号异常甚至是欺诈风险。信贷画像的每个标签都必须能对应到还款能力、还款意愿、稳定性、欺诈风险这四个维度之一。如果某个标签很好看但解释不了任何风险现象那它在信贷场景里就没有决策价值。这是和那些“用户生命周期画像”“兴趣偏好画像”最大的区别。1.2 画像服务的三类决策准入、额价、催收信贷业务里用户画像最终要服务三件事贷前准入、贷中监控、贷后催收。这三件事对画像的粒度和实时性要求差别很大。贷前准入核心是这个人能不能借、最多借多少、利率定多少。这个时候需要强变量比如人行征信、收入负债、历史逾期、多头借贷情况。画像要做的是“录取评估”一次申请进来快速给出风险结论。贷中监控核心是这笔借出去的钱还安不安全。画像要从“一次性评估”变成“持续观察”重点看用户借款后的行为变化还款渠道有没有切换、近期有没有更频繁地申请借款、担保关系有没有异常。这一层需要更实时、更动态的标签。贷后催收核心是这笔钱如果逾期了怎么用最小成本收回来。画像要回答这个人是不是真没钱还是在装作没钱他失联的概率有多大用短信、人工电话还是委外催收更合适同一个逾期客户画像不同处置方式完全不同。所以不要只把画像当成一个静态的标签库。画像面向的是决策流不同决策节点对画像的字段、时效、可解释性要求都不一样。1.3 画像和报表的本质区别我经常遇到产品经理把画像需求写成“我要一张用户全景视图页面”最后做出来就是一堆报表图表。报表回答的是“发生了什么”画像回答的是“这个人现在能不能借、值多少、下一步该怎么办”。报表是给人看的画像本质上是给策略和模型消费的。画像标签要能直接进入规则引擎、评分卡、机器学习模型变成审批、定价、预警动作的输入变量。如果画像标签不能进决策那它再丰富也只是一个展示用的“巨型Excel”。这也是为什么我一直强调画像字段设计必须和下游策略打通。画像不是数据团队自嗨的作品而是要能被策略同学拿去写规则、能被模型同学拿去当特征、能被催收系统拿去分案。2. 标签体系设计画像从0到1的骨架怎么搭2.1 四象限标签身份、资产、信用、行为信贷画像的标签体系我习惯按四个大类来组织身份特征、资产能力、信用历史、行为动态。这四个象限基本覆盖了还款能力和还款意愿的全部信息。身份特征解决“你是谁”。包括年龄区间、学历、婚姻状况、职业类型、工作稳定度、居住稳定性等。这些标签大多来自用户申请表和内部审核信息适合做基础准入规则。比如年龄在22岁以下或55岁以上的风险一般偏高很多产品会做限制。资产能力解决“你拿什么还”。包括税后月收入、公积金基数、社保缴纳情况、名下房产、车辆、理财资产等。这类标签直接决定授信额度是定价环节最核心的变量。信用历史解决“你过去怎么还”。包括征信查询次数、历史贷款笔数、当前负债余额、逾期天数和次数、信用卡使用率、内部历史还款表现等。这是预测未来违约最有力的证据。行为动态解决“你现在在干什么”。包括近30天申请次数、近期设备变动、登录时段、还款渠道变化、借款用途等。这类标签很多来自内部埋点和外部合作数据特别适合贷中监控和欺诈识别。下面是一个常见的标签示意表方便新同学理解标签大类常见标签示例主要数据源典型决策用途身份特征年龄区间、职业稳定度、居住时长申请表、内部审核基础准入资产能力月收入、公积金基数、房产情况税务、公积金、自填额度定价信用历史征信查询次数、最大逾期天数、负债比征信、内部还款记录风险定级行为动态近30天申请次数、还款渠道变化埋点、借贷行为数据贷中预警、反欺诈2.2 口径统一给了钱交代不了的标签等于零标签体系里最容易翻车的地方不是算法不行而是口径打架。同一个“收入”税务系统拉出来的收入和用户自填收入可能差两倍同一个“查询次数”征信报告里的硬查询和贷款审批查询也有细微差别。如果口径不统一你用收入标签做额度策略同学用另一个口径做准入最后就是审批结果莫名其妙。一个标签要想真正可用至少要把四个“确定”写清楚确定数据源数据从哪里来是主表、子表还是外部接口确定时间窗口是近3个月、近6个月还是自开户以来累计确定统计逻辑是取最大值、均值、最近一次还是区间计数确定缺失处理空值、0值和极端值分别怎么处理是不能为空还是补默认值。我建议每个标签都有一份口径文档字段至少包括标签名、业务含义、数据源表、取数逻辑、输出类型、更新频率、负责人、口径变更记录。不要嫌麻烦等上线三个月后前人离职、口径失传新来的同学只能靠猜那才叫灾难。2.3 分层与时效画像不是一天算一次就完事画像标签的时效设计直接影响系统成本和业务效果。身份、学历这类标签几个月不变根本不需要每天更新而申请次数、负债变化这种动态标签如果T1更新贷中预警就慢半拍。我习惯把标签分为三层基础层也称为静态标签主要存身份、职业、学历这类低频信息T1批量更新即可。指标层也叫衍生标签通过基础数据计算近N天行为指标比如近30天申请次数、近90天最大逾期天数T1计算基本够用。实时层用于欺诈识别和贷中阻断比如设备是否命中黑名单、同一手机号当日申请次数这类标签要分钟级甚至秒级计算。很多团队为了追求“全实时”把所有标签都丢进流式计算框架成本高不说还经常因为延迟问题把简单事情搞复杂。我的建议是冷标签走批量热标签走实时别搞一刀切。3. 数据来源与合规边界食材好坏决定画像生死3.1 四路数据源怎么搭配最合理信贷画像能用的数据大致分四类。内部数据是最基础的一层包括申请填写信息、审批记录、还款记录、APP埋点行为。这类数据准确性高、成本低但覆盖范围有限很多新客户没有历史。人行征信是信贷专属的核心数据包含借贷记录、逾期情况、查询记录等。它的权威性和区分度都很高但缺点是维度相对单一覆盖不到没有信贷记录的客群。第三方替代数据包括运营商数据、税务数据、公积金数据、社保数据。这类数据能补足征信白户的画像空白但在稳定性和合规性上参差不齐需要仔细评估。用户授权数据包括用户主动提供的社保密码授权、电商账单授权等。这类数据准确性高但授权流程重获取成本高适合用于大额产品的补充核验。现实情况下几乎没有哪个产品能把四类数据全部吃满。小额短周期产品可能更依赖行为数据和风险名单大额长期产品则必须抓好征信和收入资产类数据。数据源搭配没有标准答案关键是搞清楚你的目标客群长什么样哪些数据能最大限度区分好坏客户。3.2 合规红线画像做得越深越要管住手信贷画像越精细涉及的敏感信息就越多数据合规问题越躲不开。这部分不是法务一个部门的事做画像的数据同学和策略同学都必须有意识。核心原则我认为是合法授权、最小必要、目的限定。用户授权你采集某类数据用于信贷风险评估那就只能用于这个目的不能顺手挪去做别的产品营销。画像字段设计时能不碰的就不碰。与信贷决策没有直接关系的数据比如聊天内容、通讯录联系人关系、相册信息、健康记录、宗教信仰等都应当排除在画像体系之外。另外基于某些敏感属性做画像会有歧视风险。比如按性别、地域、民族直接做风险分档不仅监管不允许在商业上也是自找麻烦。做特征筛选时要反复审查标签是否符合公平性原则。合规自查要嵌入上线流程而不是最后补流程。新增一个数据源先做来源审核新增一个敏感标签先做必要性评估对外输出画像结果先做去标识化处理。这个环节省不掉一旦出事画像项目再漂亮也没用。3.3 数据质量校验的土办法很多团队在画像开发阶段最重视算法和模型反而忽视了上游数据质量。实际上数据质量不过关后面所有标签和模型都是在垃圾上盖楼。我常用的土办法是每天跑一张数据质量校验表。不搞复杂平台一段SQL就能发现大部分问题select data_date, count(*) as total_cnt, count(distinct user_id) as user_cnt, sum(case when income_amount is null then 1 else 0 end) as income_null_cnt, sum(case when credit_score 0 then 1 else 0 end) as score_zero_cnt, sum(case when apply_cnt 0 then 1 else 0 end) as apply_cnt_negative_cnt from dwd_user_profile_label_d where data_date ${bizdate} group by data_date;这张表的输出重点看三个指标空值率有没有突然跳高0值占比是否异常负值或不合理区间是否出现。比如收入字段为空值率从2%涨到20%大概率上游数据源断了字段映射。再比如某一天查询次数的分布明显变化可能不是业务波动而是口径被蹭改。这类质量校验不需要复杂的规则引擎列几十条核心规则每天早上自动跑一遍结果发到群里谁的问题谁认领解决速度反而最快。4. 从标签到决策画像特征与模型的落地全流程4.1 特征工程别把标签一股脑丢进模型有些同学拿到几百个画像标签后直接拼一个大宽表丢给机器学习模型期望模型自己学习。这在信贷场景里风险很大一是可解释性差二是很容易过拟合三是变量之间高度相关导致模型不稳定。正确的做法是先做特征工程。每个连续型标签先分箱比如把“月收入”分成5000以下、5000-10000、10000-20000、20000以上几个档位然后计算每个档位的好坏客户占比差值也就是WOE值。通过WOE和IV值筛选变量。变量分箱样本占比坏样本率WOEIV月收入0-500018%6.2%-0.880.092月收入5000-1000034%4.1%-0.350.030月收入10000-2000032%2.3%0.280.021月收入20000以上16%1.1%0.950.041IV值在0.1以上这个变量就有一定区分能力0.3以上算强变量。但不要只看IV还要看业务逻辑是否通顺。有些变量IV很高但是未来不可解释或者缺失率太高用起来也很危险。筛选完变量后再做相关性分析和共线性检查。两个高度相关的标签保留一个即可否则模型不仅冗余线上推理也浪费资源。4.2 三种打法规则、评分卡、机器学习怎么选信贷画像落地决策不只一条技术路线。我见过三种主流打法各有各的适用场景。第一种是规则引擎适合冷启动阶段和小额高频场景。画像标签直接写成规则比如“近7天申请次数超过5次直接拒绝”“收入负债比超过50%降额50%”。优点是透明、上线快、易解释缺点是规则多了之后人工维护成本高容易变成失控的“规则森林”。第二种是评分卡模型这是信贷行业最经典的方案。把画像标签做WOE分箱转换成标准化的分数再用逻辑回归把分数汇总成一个信用评分。好处是稳定、可解释、方便监管审计也容易设置分数阈值。缺点是特征表达能力有限做不了太复杂的交互特征。第三种是机器学习模型比如GBDT、XGBoost这类。适合数据量大、特征维度高的场景能自动捕捉复杂模式区分度通常比逻辑回归好。缺点是解释性弱部署和监控成本高需要额外的模型解释工具和拒因生成机制。我个人的建议是新业务冷启动时先用规则评分卡把底线守住等数据积累到一定量级再考虑机器学习模型做增量优化。千万别一上来就追求最炫的模型信贷业务最怕的不是效果差而是出了问题说不清楚。4.3 画像更新的调度与监控画像不是一次性项目上线之后要每天稳定运转。整个更新流程一般是数据接入 → 质量校验 → 标签计算 → 特征拼接 → 模型评分 → 结果分发到策略引擎和数据服务。调度上最常遇到的问题就是延迟。比如凌晨的数据2点还没到标签任务一直重试导致早上审批系统用的还是昨天甚至前天的画像数据。解决思路是给调度设置优先级和依赖检查。核心标签任务要有独立告警超过容忍时间没跑完立刻通知数据负责人而不是让任务躺在调度平台里“自动重试到天荒地老”。监控指标里PSI是最关键的稳定性指标。它衡量线上画像分的分布和建模时训练集分布有没有偏移。PSI小于0.1代表稳定0.1到0.25需要关注大于0.25基本可以判定模型或人群出了问题。每月定期输出PSI报表一旦指标异常要尽快回溯是数据源变化、标签口径变化还是客群结构变化。5. 贷前贷中贷后用户画像在信贷业务里的三个主战场5.1 贷前用画像把“能不能借、借多少”一次说清贷前是整个信贷链条里画像价值最集中的环节。客户一提交申请系统会立刻拉取画像标签基于准入规则和评分模型给出决策结果。画像在贷前要同时回答两个问题能不能通过以及额度和价格给多少。还是以某消费信贷产品举例。一个用户收入挺好月薪2万公积金基数1万8按常识判断还款能力没问题。但画像里“近30天申请贷款平台数”这个标签显示是8多头借贷特征非常明显。这时如果再给他放款他很可能是在拆东墙补西墙风险并不低。最终策略是拒绝哪怕他的收入负债比看起来还不错。额度定价也依赖画像分层。下表是一个简化示意风险等级画像特征示意审批建议初始额度范围A收入稳定、负债低、无逾期秒批5万-20万B收入中等、负债可接受通过1万-5万C收入一般、查询次数偏高人工复核或降额5000-1万D多头借贷严重、有逾期拒绝0贷前画像设计最怕的是用一个总分打天下。实际业务中风险和欺诈要分开看额度定价和利率定价也要分开看。画像标签既要给到总分也要保留关键子维度策略才能灵活拆分。5.2 贷中别等逾期画像变化本身就是信号很多风控团队在贷中环节投入不足总觉得人批下来就完事等到逾期才去催收。其实很多风险信号在逾期之前就已经通过画像标签表现出来了。比如一个长期在APP上正常还款的用户突然连续几天在凌晨异常登录同时“近7天跨平台借贷申请次数”快速上升这类组合标签往往意味着用户现金流开始紧张。再比如用户绑定的还款银行卡从工资卡换成了第三方支付代扣或者频繁更换绑定设备都可能是资金链出现问题的信号。贷中监控不能只看单个标签更要看组合。我常用的方式是把几个动态标签组合成预警规则比如近7天申请次数大于3次同时近30天内部还款次数小于2次触发贷中预警本月工资入账金额比过往6个月均值下降50%以上同时有过一次非正常还款触发降额评估设备安装包列表中信贷类APP数量超过10个触发人工排查。预警之后要能接住。系统给策略团队发名单策略团队决定是发送短信提示、降额还是直接冻结额度。如果预警只发邮件不处理那监控机制就只是摆设。5.3 贷后把催收当成“千人千面”运营贷后催收是画像应用里最容易被人误解的环节。很多人以为催收就是电话轰炸其实好的催收运营同样是分客群、分策略的。画像在贷后要提供几个关键标签失联风险、还款意愿、还款能力、催收敏感度。这几个标签组合起来基本能决定一个逾期客户的处置方式。拿一个逾期15天的客户来说如果画像显示他有稳定工作和还款能力仅是因为忘记还款或短期手头紧那系统只需要推一条温和的提醒短信或者安排一次标准外呼就能解决。但如果画像显示客户近期工作频繁变动、负债极高、多个平台逾期同时失联风险标签为高那就要优先安排资深催收员提前介入甚至同步启动紧急联系人策略。催收话术也要跟着画像走。还款能力弱但还款意愿强的客户适合协商分期还款能力强但恶意逃废债的客户适合强硬施压对催收非常敏感的客户则要注意频次和方式避免投诉。这些精细化运营的背后靠的都是画像标签支撑。6. 踩过那么多坑画像落地前先看看这些排查经验6.1 第一个坑标签“好看”但策略不买单我见过最典型的失败案例是画像团队花了三个月建了几百个标签页面展示得非常漂亮但策略团队一个都不用。原因很简单这些标签没有对应到任何决策动作。后来我们立了一个规矩新增标签必须填写“标签审批表”说明这个标签用于支持哪个策略的哪个分支。比如“用户是否连续3个月工资入账下降”这个标签对应策略是“贷中降额名单”如果填写不出决策场景这个标签就不许上线。这个规矩直接让标签数量从几百个砍到几十个但每个都管用。6.2 第二个坑人群偏移导致模型失效很多模型刚上线效果不错跑两三个月就开始烂最常见的原因是线上实际申请人群和建模样本不是一批人。比如建模时用的是某渠道的历史存量客户线上却通过新渠道大量拉新新客群的画像分布完全不同模型自然失效。应对方法有两个。一是冷启动阶段不要硬上机器学习模型先用规则和评分卡过渡等积累到和新客群匹配的样本再训练。二是上线后持续监控PSI并且定期检查线上客群在关键标签上的分布比如收入、年龄段、申请来源渠道。出现明显偏移时要么调整模型阈值要么重新训练不要硬扛。6.3 第三个坑口径变更导致标签“断层”标签口径最怕频繁变化。比如将“近30天申请次数”从只计算主产品改为计算所有产品数字一下变大用这个标签写的规则全部要重新验证历史报表也不能直接对比。处理口径变更我的经验是变更前先双跑。新旧口径并行跑至少一个完整观察期确认新口径不会带来指标突变再正式切换。切换后旧口径字段至少再保留一个月方便排查问题。另外所有变更都要写进口径文档记录变更时间、原因和影响范围这些细节在事后回溯时救命。6.4 第四个坑把画像做成技术部门的自嗨最后一个坑也是最要命的就是画像团队沉浸在自己的技术世界里忘了业务方是决策者。画像分数不能只给一个总分还要能翻译成人话为什么这个用户被拒绝为什么额度只有这么低如果策略同学拿到一个画像标签还要猜含义画像就没有真正落地。要让画像“会说话”每个标签都要有清晰的业务解释评分输出也要附带拒绝原因代码。比如模型拒绝用户系统要能自动生成“收入稳定但近期多头借贷次数过高”这样的原因描述而不是只给一个冷冰冰的分数。这样做既能帮助策略调优也能应对客户咨询和监管解释。我个人在这么多年的实际操作里最大的体会是信贷用户画像的天花板从来不在技术而在业务闭环。标签再多、模型再强如果每个标签没有回答“这个决策动作该怎么下”那画像做得再漂亮也是浪费。现在每次新项目启动我都会先问一句画像做出来到底要改变哪个策略、服务哪个决策想清楚这一句后面基本上就不会跑偏。
