简介面向保险公司风控、定价与算法团队这是一份围绕DeepSeek多模态学习构建保险产品智能推荐与动态定价的完整方案文档系统覆盖客户分群、风险评估及业务落地路径。文档共468页、54个大章节封装为单个PDF文件压缩包大小约17.88MB支持目录章节跳转、阅读器书签大纲与快速定位排版和图表显示均完整清晰。目前已有74人学习下载。内容从保险多模态数据体系入手依次讲解客户基础信息、行为序列、产品条款、影像、语音五类数据的预处理标注规范设计、数据质量评估、联合标注与质量优化并深入展开客户分群特征工程细化文本TF-IDF、Word2Vec、BERT和时序RNN、LSTM、Transformer等建模对比既有理论拆解也有工程化落地说明适合保险科技项目设计、模型选型与算法工程师自学进阶。1. 多模态驱动和动态定价这套方案到底解决保险业的哪个问题保险产品智能推荐和动态定价听起来是两个问题但在实际业务里它们共享同一个前置条件客户分群够不够细、风险画像够不够准。传统精算定价依赖年龄、性别、职业、历史理赔这几个结构化字段推荐又只看用户点击和投保品类两套系统互不串联结果就是定价激进的用户拿到低质量推荐风险高的群体反而享受了不该有的折扣。DeepSeek 做基座模型把文本、图像、时序行为这些非结构化数据拉进同一个特征空间再用一套多模态模型同时产出分群、推荐和风险评分这是一线团队目前最常走的落地路径。这篇内容会从特征怎么构建、模型怎么训练、定价怎么校准一直讲到工程化部署和上线验证。适合正在做保险推荐、定价引擎或者风险模型的工程师也适合精算团队想了解机器学习模型边界的人。你能拿走的不只是方案推演还有可以直接改来用的代码片段和参数设置逻辑。2. 客户分群是地基多模态特征工程与不加标签的分群方法2.1 保险场景里的多模态数据到底有哪些多模态学习在保险领域的含义和做图文检索的通用多模态不完全一样。保险业务里最常见的模态是结构化表格投保人年龄、性别、职业类别、收入区间、历史保单、既往理赔记录文本健康告知描述、客服对话记录、理赔申请的理由说明、问卷里的自由填写项时序行为App 浏览轨迹、保险产品比较次数、续保时间间隔、健康手环的步数或睡眠序列图像偶尔会出现比如体检报告翻拍件、车险定损照片但保险文本和表格仍然是主力模态常见做法是把这些异构数据统一映射到一个 embedding 空间再做交叉融合。DeepSeek 作为生成式基座处理文本和时序描述有天然优势但要注意它不直接输出数值型风险评分我们后面要用它产出中间表示再接一个判别头。2.1.1 特征对齐一张复合特征表的构建代码第一步先把各模态数据对齐到客户维度。下面是一段构建多模态复合特征表的代码对缺失模态做了掩码处理import pandas as pd import numpy as np def build_multimodal_feature_table( structured_df: pd.DataFrame, text_embeddings: pd.DataFrame, behavior_seq: dict ) - pd.DataFrame: # 结构化字段直接做数值化和 one-hot base structured_df.copy() base[age_bucket] pd.cut(base[age], bins[0,25,35,45,55,120], labelsFalse) base[is_married] (base[marital_status] 已婚).astype(int) base[occupation_risk] base[occupation].map(occupation_risk_map).fillna(0.5) # 文本模态取预计算好的 embedding降维到 64 维 text_dim text_embeddings.shape[1] if text_dim 64: from sklearn.decomposition import PCA text_emb PCA(n_components64, random_state42).fit_transform(text_embeddings) else: text_emb text_embeddings.values # 时序模态对行为序列做统计聚合 seq_stats [] for uid in base[user_id]: seq behavior_seq.get(uid, []) if len(seq) 0: seq_stats.append({ view_freq: len(seq) / 30.0, compare_count: sum(1 for x in seq if x[action] compare), interval_mean: float(np.mean(np.diff([x[ts] for x in seq]))) if len(seq) 1 else 0 }) else: seq_stats.append({view_freq: 0, compare_count: 0, interval_mean: 0}) seq_df pd.DataFrame(seq_stats) # 拼接所有模态特征并把模态来源记录下来方便后续做稀疏门控 final pd.concat([base.reset_index(dropTrue), pd.DataFrame(text_emb, columns[ftext_{i} for i in range(64)]), seq_df], axis1) return final核心逻辑是把三种模态拉平到一张宽表里。这里有两个容易被忽略的点文本 embedding 要不要降维取决于下游模型规模如果不做降维DeepSeek 的 embedding 维度通常很高直接进 LightGBM 会导致训练慢且容易过拟合时序模态我习惯用统计量而不是原始序列因为保险行为序列普遍稀疏80% 的用户 30 天内可能只有两三次访问。2.2 分群模型先聚类再打标还是端到端学表示客户分群有两条路线先用 embedding 做聚类再人工给簇打业务标签这是最常见也更稳的做法或者用自编码器学习低维表示后直接接聚类层但保险这类数据噪声高、可解释性要求强端到端方案往往在合规审查时很难通过。我倾向于两步走。2.2.1 用 HDBSCAN 在 embedding 上找稳定簇对不同保险品类客户的行为表征差异很大。以下代码展示了如何在文本 embedding 和统计特征的组合上跑 HDBSCANimport hdbscan from sklearn.preprocessing import StandardScaler def cluster_customers(feature_df: pd.DataFrame, min_cluster_size: int 120): # 只选择特征列排除 user_id 等主键 feature_cols [c for c in feature_df.columns if c not in (user_id, label)] X StandardScaler().fit_transform(feature_df[feature_cols].fillna(0)) # HDBSCAN 的 min_cluster_size 是核心参数太小则噪声点过多 clusterer hdbscan.HDBSCAN( min_cluster_sizemin_cluster_size, min_samples20, metriceuclidean, cluster_selection_epsilon0.5, prediction_dataTrue ) cluster_labels clusterer.fit_predict(X) # -1 表示噪声点不强制归入任何簇 feature_df[cluster_id] cluster_labels noise_ratio (cluster_labels -1).mean() print(fnoise ratio: {noise_ratio:.2%}, cluster count: {len(set(cluster_labels)) - (1 if -1 in set(cluster_labels) else 0)}) return feature_df, clusterermin_cluster_size直接决定簇的粒度。线上我一般设 100 到 200 之间比这个更小会出现大量碎片簇cluster_selection_epsilon控制簇的紧密度设 0.5 意味着簇内样本的互达距离平均值不超过这个阈值。和 K-Means 不同HDBSCAN 不要求每个样本都必须属于某个簇保险场景里拒绝噪声点总比硬塞进一个错误簇好。2.2.2 分群结果如何和业务部门对齐分群后必须和业务方一起为每个簇定义「可解释标签」例如「价格敏感型新手」「高保额家庭支柱」「健康管理活跃人群」「低频沉默存量客户」。这一步是数据驱动和业务规则之间的桥梁——模型给出的簇边界再精确没有业务含义就无法指导推荐和定价。我习惯于为每个簇生成一份 profile 报告包含各模态特征的平均值和分布用百分位来给业务人员看。比如「健康管理活跃人群」的典型特征是文本模态里提到「体检」「运动」的频率高于整体 2 个标准差行为模态里健康类内容的浏览占比超过 40%结构化字段年龄集中在 28 到 40 岁。3. 智能推荐模型DeepSeek 做语义召回和可解释排序3.1 传统保险推荐的失效模式保险推荐和电商推荐的显著差异是第一保险产品频次低、决策周期长用户不会每周买一次保险协同过滤的数据稀疏度极高第二保险产品之间的替代关系复杂医疗险和重疾险不是简单的「相似商品」而是相互补充第三推荐需要可解释监管要求必须说清楚为什么给这个用户推这款产品这一点和精算定价依据直接挂钩。因此纯靠行为协同过滤的思路在保险里基本走不通。常见做法是把推荐分成两个阶段用 DeepSeek 对保险产品说明书、条款摘要和用户特征描述做语义匹配完成候选召回再用一个轻量排序模型融合价格、利润空间、用户匹配度做精排。3.2 用 DeepSeek 构造用户和产品的新文本表征3.2.1 产品侧条款摘要的 embedding 化保险产品的核心信息集中在条款和投保须知里但条款文本的句式和法律语言特点导致直接用通用 embedding 效果一般。这里可以用 DeepSeek 做一次结构化抽取把条款转成统一格式的产品画像文本from openai import OpenAI client OpenAI( api_key..., base_urlhttps://api.deepseek.com/v1 ) PRODUCT_PROMPT 请根据以下保险产品条款抽取出以下字段并以 JSON 格式输出 { coverage_summary: 保障范围的一句话概括, target_customer: 适合的目标客户特征, price_range: 年缴费用区间, claim_conditions: 理赔的关键条件, exclusions: 主要免责条款 } 条款内容 {clause_text} def build_product_profile(clause_text: str) - dict: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是保险产品精算助理只抽取信息不作评价。}, {role: user, content: PRODUCT_PROMPT.format(clause_textclause_text[:8000])} ], temperature0.1, max_tokens1024, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content)这段代码的关键是 temperature 必须压低、response_format 强制 JSON。保险条款抽取对创造性要求为零temperature 超过 0.3 就会开始出现字段遗漏和格式漂移。实际生产里我会把抽取结果缓存到 Mongo 或 Redis 里因为条款变更频率很低没必要每次请求都调一次 API。3.2.2 用户侧把混合特征转成推荐应用的语义描述用户侧的文本构造核心思路是把结构化特征翻译成自然语言片段。比如一个 32 岁的信息安全工程师已婚未育年收入区间 30 到 50 万过去 90 天浏览了 5 次医疗险、2 次重疾险、0 次理财险就可以构造出一段描述文本。这段文本和产品画像文本一起送进同一个 embedding 模型保证用户和产品处于同一个向量空间。之后用 Faiss 或 Milvus 做向量检索取 Top 200 作为候选集。这一步的好处是推荐不再依赖「买了 A 的人买 B」这种稀疏共现逻辑而是真正从语义上理解用户要什么。对没有历史行为的冷启动用户只要有几个基本属性字段就能生成文本描述并做检索这是传统协同过滤做不到的。3.3 推荐排序层和动态定价的耦合策略候选集召回之后排序模型不能只学点击率。保险场景必须同时考虑「用户会不会买」和「这个客户的风险期望赔付是多少」。如果排序模型只用点击标签会把高风险高赔付的产品推给不该推的人短期点击漂亮长期赔付率崩掉。建议的排序目标是加权公式score w1 * p_convert - w2 * expected_loss_ratio w3 * semantic_fitp_convert是转化概率expected_loss_ratio是预期赔付率semantic_fit是用户与产品的语义相似度。权重 w1、w2、w3 按照业务阶段调整比如在拉新阶段 w1 权重可以高些在控制赔付率阶段 w2 会被调高。实践中我通常让semantic_fit的权重不低于 0.2它能起到稳定器的作用防止模型只盯着转化信号而不顾用户真实需求。排序模型的实现用 LightGBM 结合 lambdarank 目标即可特征是用户 cluster_id 与产品类别的交叉、语义相似度、产品毛利、近期同类产品曝光量等。不用为了「智能化」硬上深度模型保险样本量通常不足以支撑大规模端到端排序模型树模型在这个阶段更稳。4. 风险精准评估与动态定价赔率模型怎么和精算指标对齐4.1 风险评估模型的目标不是「预测理赔」而是「估计期望赔付」风险精准评估和传统精算定价有一个核心差异精算用的 GLM 建模的是赔付频率和赔付金额的期望期望基于历史静态数据而多模态方案要做的是叠加动态信息比如用户最近的行为变化、健康文本描述里的风险信号、以及分群后群体风险基准。期望赔付成本可以用一个式子表达expected_claim_cost claim_frequency × claim_severity这里有两个模型频率模型和金额模型。频率模型解决「这个客户未来一年有多大概率出险」金额模型解决「出险后平均赔多少」。两个模型可以共用一套特征但损失函数不同一个用 Poisson 或负二项回归一个用 Gamma 回归。4.2 三个必调参数和损失函数选择4.2.1 频率模型的过离散处理保险数据的一个显著特点是方差大于均值也就是过离散。直接用 Poisson 回归会低估方差必然导致置信区间过窄、费率充足性判断错误。常用的做法是用负二项回归或者在 LightGBM 里用 Poisson 目标但把reg_alpha调高抑制极端预测值import lightgbm as lgb def train_frequency_model(train_df, valid_df): features [c for c in train_df.columns if c not in ( user_id, claim_freq, claim_amount, exposure )] # 用 exposure 作为样本权重处理不同客户保障期限不一致的问题 train_data lgb.Dataset( train_df[features], labeltrain_df[claim_freq], weighttrain_df[exposure], free_raw_dataFalse ) valid_data lgb.Dataset( valid_df[features], labelvalid_df[claim_freq], weightvalid_df[exposure], referencetrain_data ) params { objective: poisson, metric: poisson, learning_rate: 0.03, num_leaves: 63, max_depth: 6, min_child_samples: 200, reg_alpha: 1.5, reg_lambda: 3.0, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1 } model lgb.train( params, train_data, num_boost_round500, valid_sets[valid_data], callbacks[lgb.early_stopping(50)] ) return model用 weight 参数传 exposure 是关键不同客户保单生效的月份数不一样直接用粗保费计算出的频率会失真。观察期内只承保了 3 个月的客户和承保了 12 个月的客户权重不能相等。如果你发现验证集上poissonmetric 一直不降先检查是不是把 exposure 漏了而不是调学习率。4.2.2 金额模型用 Tweedie 还是 Gamma金额模型看数据分布。如果理赔金额中有大量零值比如住过院但没达到免赔额Tweedie 分布更合适如果只看已发生理赔的正数金额Gamma 回归更直接。LightGBM 对 Tweedie 的支持比较成熟params_amount { objective: tweedie, tweedie_variance_power: 1.5, metric: rmse, learning_rate: 0.02, num_leaves: 31, min_child_samples: 300, feature_fraction: 0.7, bagging_fraction: 0.7, bagging_freq: 1, verbose: -1 }tweedie_variance_power介于 1 到 2 之间越接近 1 越像 Poisson越接近 2 越像 Gamma。保险损失数据一般取 1.4 到 1.7 之间效果较好。这个参数不是随便选的可以用网格搜索在小验证集上先扫一圈步长 0.1 就够了。记得金额模型要对目标变量做 log1p 变换再评估误差因为赔付金额的分布跨度极大直接用原始金额计算 RMSE 会被几个大额赔案主导。4.3 从预测赔付到动态定价费率系数和 GLM 校准模型输出的期望赔付成本不能直接当价格卖给出单系统。原因是机器学习模型对极端值不敏感对低发生率产品缺乏精算公认的结构性而且监管通常要求费率可解释、可回溯。所以动态定价的标准做法是两步走模型算一个基础风险评分再用 GLM 把这个评分映射到费率表上。实际落地中我建议做「升降级系数」以当前基础费率为基准把模型的预测赔付率分成 10 档每档对应一个系数区间比如最低档 0.85最高档 1.45。这个系数必须通过假设检验验证单调性如果档位之间的风险差异不显著说明模型特征没有充分捕捉风险信号需要回到特征侧补数据。同时建议在模型中放入cum_premium和expected_claim的比值作为动态赔付率约束def compute_dynamic_price( base_premium: float, risk_score: float, claim_cost_estimate: float, target_loss_ratio: float 0.6 ) - float: # 定价目标是让预期赔付率不超过 target_loss_ratio floor_price claim_cost_estimate / target_loss_ratio uplift_factor 0.9 0.2 * (risk_score - risk_score.mean()) / risk_score.std() price max(base_premium * uplift_factor, floor_price * 1.05) return round(price, 0)这里设置floor_price * 1.05是为了保证最终定价高于赔付成本线的 5%防止价格战把自己打穿。动态定价系统上线前要做一次费率充足性回测用历史 3 年的数据模拟看按新定价规则假设赔付率是否落入 50% 到 70% 的区间。5. 工程化落地特征管线、推理成本和线上的三个验证指标5.1 用批处理降低 DeepSeek 调用成本线上推荐和风险评估如果每次都现调 DeepSeek 生成 embedding成本会吃不消。保险产品的语义特征产品画像是低频更新的可以离线每天或每周算一次用户的文本描述则依赖行为数据变化可以每 6 到 12 小时批量更新一次。实时部分只保留稀疏门控的切换和排序模型打分。常见做法是搭一个特征定时任务# 每天凌晨 2 点批量更新产品画像和用户 embedding 0 2 * * * python -m pipeline.update_product_embeddings 0 4 * * * python -m pipeline.update_user_embeddings --hours 6 # 每 30 分钟增量更新活跃用户的行为统计特征 */30 * * * * python -m pipeline.update_active_users --window 30min批量更新的好处不只是省钱还能规避生成式模型输出不稳定带来的线上执行风险。新增temperature0和固定seed可以显著降级结果漂移但不能完全消除所以任何 DeepSeek 生成的内容落到业务系统前都要配一个字面量校验器确认 JSON schema 完整。完整的校验逻辑要在主流程外运行不能让 API 响应里的解析异常影响正常的出单链路。5.2 线上服务的三个验证指标推荐和动态定价系统上线后最需要盯的指标不是点击率而是和风险相关的三个数指标计算方式预警线建议新客动态赔付率新客户赔付金额 ÷ 新客户已赚保费超过 75% 且连续 2 周上升分群迁移度月度客户所属 cluster 变化比例超过 30% 说明特征或分群不稳定推荐转化传导率曝光 → 详情 → 投保的漏斗转化率低于基准值 1.5 个百分点时查排序模型其中「分群迁移度」是最容易被忽视的。客户不会每周变一次风险类型如果分群标签频繁跳动不是模型问题就是特征管线出了问题。排查顺序是先看基础表的字段是否存在错位再看 embedding 是否因为文本模板改动而漂移最后检查 HDBSCAN 的重训练是否固定了随机种子。5.3 安全性和可解释性提示保险推荐和定价系统涉及用户健康和行为隐私。多模态特征中如果包含健康手环数据、体检结果等敏感字段必须在特征工程层做脱敏和分级授权原始数据不能进模型训练环境。模型侧也需要保留每一单的推荐理由和定价依据建议在排序模型输出的同时记录 Top 3 特征的贡献值精算审核时可以追查任何一单的定价原因。一个实用的技巧是用 DeepSeek 生成推荐理由模板。当用户问「为什么给我推这款产品」时把用户命中的 cluster profile 和产品的关键匹配点作为上下文让 DeepSeek 生成一段不超过 50 字的解释。这条链路的价值不在于提高转化率而在于满足合规的可解释性要求同时降低人工客服的解释成本。本文还有配套的精品资源点击获取
多模态驱动的保险智能推荐与动态定价方案实践
简介面向保险公司风控、定价与算法团队这是一份围绕DeepSeek多模态学习构建保险产品智能推荐与动态定价的完整方案文档系统覆盖客户分群、风险评估及业务落地路径。文档共468页、54个大章节封装为单个PDF文件压缩包大小约17.88MB支持目录章节跳转、阅读器书签大纲与快速定位排版和图表显示均完整清晰。目前已有74人学习下载。内容从保险多模态数据体系入手依次讲解客户基础信息、行为序列、产品条款、影像、语音五类数据的预处理标注规范设计、数据质量评估、联合标注与质量优化并深入展开客户分群特征工程细化文本TF-IDF、Word2Vec、BERT和时序RNN、LSTM、Transformer等建模对比既有理论拆解也有工程化落地说明适合保险科技项目设计、模型选型与算法工程师自学进阶。1. 多模态驱动和动态定价这套方案到底解决保险业的哪个问题保险产品智能推荐和动态定价听起来是两个问题但在实际业务里它们共享同一个前置条件客户分群够不够细、风险画像够不够准。传统精算定价依赖年龄、性别、职业、历史理赔这几个结构化字段推荐又只看用户点击和投保品类两套系统互不串联结果就是定价激进的用户拿到低质量推荐风险高的群体反而享受了不该有的折扣。DeepSeek 做基座模型把文本、图像、时序行为这些非结构化数据拉进同一个特征空间再用一套多模态模型同时产出分群、推荐和风险评分这是一线团队目前最常走的落地路径。这篇内容会从特征怎么构建、模型怎么训练、定价怎么校准一直讲到工程化部署和上线验证。适合正在做保险推荐、定价引擎或者风险模型的工程师也适合精算团队想了解机器学习模型边界的人。你能拿走的不只是方案推演还有可以直接改来用的代码片段和参数设置逻辑。2. 客户分群是地基多模态特征工程与不加标签的分群方法2.1 保险场景里的多模态数据到底有哪些多模态学习在保险领域的含义和做图文检索的通用多模态不完全一样。保险业务里最常见的模态是结构化表格投保人年龄、性别、职业类别、收入区间、历史保单、既往理赔记录文本健康告知描述、客服对话记录、理赔申请的理由说明、问卷里的自由填写项时序行为App 浏览轨迹、保险产品比较次数、续保时间间隔、健康手环的步数或睡眠序列图像偶尔会出现比如体检报告翻拍件、车险定损照片但保险文本和表格仍然是主力模态常见做法是把这些异构数据统一映射到一个 embedding 空间再做交叉融合。DeepSeek 作为生成式基座处理文本和时序描述有天然优势但要注意它不直接输出数值型风险评分我们后面要用它产出中间表示再接一个判别头。2.1.1 特征对齐一张复合特征表的构建代码第一步先把各模态数据对齐到客户维度。下面是一段构建多模态复合特征表的代码对缺失模态做了掩码处理import pandas as pd import numpy as np def build_multimodal_feature_table( structured_df: pd.DataFrame, text_embeddings: pd.DataFrame, behavior_seq: dict ) - pd.DataFrame: # 结构化字段直接做数值化和 one-hot base structured_df.copy() base[age_bucket] pd.cut(base[age], bins[0,25,35,45,55,120], labelsFalse) base[is_married] (base[marital_status] 已婚).astype(int) base[occupation_risk] base[occupation].map(occupation_risk_map).fillna(0.5) # 文本模态取预计算好的 embedding降维到 64 维 text_dim text_embeddings.shape[1] if text_dim 64: from sklearn.decomposition import PCA text_emb PCA(n_components64, random_state42).fit_transform(text_embeddings) else: text_emb text_embeddings.values # 时序模态对行为序列做统计聚合 seq_stats [] for uid in base[user_id]: seq behavior_seq.get(uid, []) if len(seq) 0: seq_stats.append({ view_freq: len(seq) / 30.0, compare_count: sum(1 for x in seq if x[action] compare), interval_mean: float(np.mean(np.diff([x[ts] for x in seq]))) if len(seq) 1 else 0 }) else: seq_stats.append({view_freq: 0, compare_count: 0, interval_mean: 0}) seq_df pd.DataFrame(seq_stats) # 拼接所有模态特征并把模态来源记录下来方便后续做稀疏门控 final pd.concat([base.reset_index(dropTrue), pd.DataFrame(text_emb, columns[ftext_{i} for i in range(64)]), seq_df], axis1) return final核心逻辑是把三种模态拉平到一张宽表里。这里有两个容易被忽略的点文本 embedding 要不要降维取决于下游模型规模如果不做降维DeepSeek 的 embedding 维度通常很高直接进 LightGBM 会导致训练慢且容易过拟合时序模态我习惯用统计量而不是原始序列因为保险行为序列普遍稀疏80% 的用户 30 天内可能只有两三次访问。2.2 分群模型先聚类再打标还是端到端学表示客户分群有两条路线先用 embedding 做聚类再人工给簇打业务标签这是最常见也更稳的做法或者用自编码器学习低维表示后直接接聚类层但保险这类数据噪声高、可解释性要求强端到端方案往往在合规审查时很难通过。我倾向于两步走。2.2.1 用 HDBSCAN 在 embedding 上找稳定簇对不同保险品类客户的行为表征差异很大。以下代码展示了如何在文本 embedding 和统计特征的组合上跑 HDBSCANimport hdbscan from sklearn.preprocessing import StandardScaler def cluster_customers(feature_df: pd.DataFrame, min_cluster_size: int 120): # 只选择特征列排除 user_id 等主键 feature_cols [c for c in feature_df.columns if c not in (user_id, label)] X StandardScaler().fit_transform(feature_df[feature_cols].fillna(0)) # HDBSCAN 的 min_cluster_size 是核心参数太小则噪声点过多 clusterer hdbscan.HDBSCAN( min_cluster_sizemin_cluster_size, min_samples20, metriceuclidean, cluster_selection_epsilon0.5, prediction_dataTrue ) cluster_labels clusterer.fit_predict(X) # -1 表示噪声点不强制归入任何簇 feature_df[cluster_id] cluster_labels noise_ratio (cluster_labels -1).mean() print(fnoise ratio: {noise_ratio:.2%}, cluster count: {len(set(cluster_labels)) - (1 if -1 in set(cluster_labels) else 0)}) return feature_df, clusterermin_cluster_size直接决定簇的粒度。线上我一般设 100 到 200 之间比这个更小会出现大量碎片簇cluster_selection_epsilon控制簇的紧密度设 0.5 意味着簇内样本的互达距离平均值不超过这个阈值。和 K-Means 不同HDBSCAN 不要求每个样本都必须属于某个簇保险场景里拒绝噪声点总比硬塞进一个错误簇好。2.2.2 分群结果如何和业务部门对齐分群后必须和业务方一起为每个簇定义「可解释标签」例如「价格敏感型新手」「高保额家庭支柱」「健康管理活跃人群」「低频沉默存量客户」。这一步是数据驱动和业务规则之间的桥梁——模型给出的簇边界再精确没有业务含义就无法指导推荐和定价。我习惯于为每个簇生成一份 profile 报告包含各模态特征的平均值和分布用百分位来给业务人员看。比如「健康管理活跃人群」的典型特征是文本模态里提到「体检」「运动」的频率高于整体 2 个标准差行为模态里健康类内容的浏览占比超过 40%结构化字段年龄集中在 28 到 40 岁。3. 智能推荐模型DeepSeek 做语义召回和可解释排序3.1 传统保险推荐的失效模式保险推荐和电商推荐的显著差异是第一保险产品频次低、决策周期长用户不会每周买一次保险协同过滤的数据稀疏度极高第二保险产品之间的替代关系复杂医疗险和重疾险不是简单的「相似商品」而是相互补充第三推荐需要可解释监管要求必须说清楚为什么给这个用户推这款产品这一点和精算定价依据直接挂钩。因此纯靠行为协同过滤的思路在保险里基本走不通。常见做法是把推荐分成两个阶段用 DeepSeek 对保险产品说明书、条款摘要和用户特征描述做语义匹配完成候选召回再用一个轻量排序模型融合价格、利润空间、用户匹配度做精排。3.2 用 DeepSeek 构造用户和产品的新文本表征3.2.1 产品侧条款摘要的 embedding 化保险产品的核心信息集中在条款和投保须知里但条款文本的句式和法律语言特点导致直接用通用 embedding 效果一般。这里可以用 DeepSeek 做一次结构化抽取把条款转成统一格式的产品画像文本from openai import OpenAI client OpenAI( api_key..., base_urlhttps://api.deepseek.com/v1 ) PRODUCT_PROMPT 请根据以下保险产品条款抽取出以下字段并以 JSON 格式输出 { coverage_summary: 保障范围的一句话概括, target_customer: 适合的目标客户特征, price_range: 年缴费用区间, claim_conditions: 理赔的关键条件, exclusions: 主要免责条款 } 条款内容 {clause_text} def build_product_profile(clause_text: str) - dict: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是保险产品精算助理只抽取信息不作评价。}, {role: user, content: PRODUCT_PROMPT.format(clause_textclause_text[:8000])} ], temperature0.1, max_tokens1024, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content)这段代码的关键是 temperature 必须压低、response_format 强制 JSON。保险条款抽取对创造性要求为零temperature 超过 0.3 就会开始出现字段遗漏和格式漂移。实际生产里我会把抽取结果缓存到 Mongo 或 Redis 里因为条款变更频率很低没必要每次请求都调一次 API。3.2.2 用户侧把混合特征转成推荐应用的语义描述用户侧的文本构造核心思路是把结构化特征翻译成自然语言片段。比如一个 32 岁的信息安全工程师已婚未育年收入区间 30 到 50 万过去 90 天浏览了 5 次医疗险、2 次重疾险、0 次理财险就可以构造出一段描述文本。这段文本和产品画像文本一起送进同一个 embedding 模型保证用户和产品处于同一个向量空间。之后用 Faiss 或 Milvus 做向量检索取 Top 200 作为候选集。这一步的好处是推荐不再依赖「买了 A 的人买 B」这种稀疏共现逻辑而是真正从语义上理解用户要什么。对没有历史行为的冷启动用户只要有几个基本属性字段就能生成文本描述并做检索这是传统协同过滤做不到的。3.3 推荐排序层和动态定价的耦合策略候选集召回之后排序模型不能只学点击率。保险场景必须同时考虑「用户会不会买」和「这个客户的风险期望赔付是多少」。如果排序模型只用点击标签会把高风险高赔付的产品推给不该推的人短期点击漂亮长期赔付率崩掉。建议的排序目标是加权公式score w1 * p_convert - w2 * expected_loss_ratio w3 * semantic_fitp_convert是转化概率expected_loss_ratio是预期赔付率semantic_fit是用户与产品的语义相似度。权重 w1、w2、w3 按照业务阶段调整比如在拉新阶段 w1 权重可以高些在控制赔付率阶段 w2 会被调高。实践中我通常让semantic_fit的权重不低于 0.2它能起到稳定器的作用防止模型只盯着转化信号而不顾用户真实需求。排序模型的实现用 LightGBM 结合 lambdarank 目标即可特征是用户 cluster_id 与产品类别的交叉、语义相似度、产品毛利、近期同类产品曝光量等。不用为了「智能化」硬上深度模型保险样本量通常不足以支撑大规模端到端排序模型树模型在这个阶段更稳。4. 风险精准评估与动态定价赔率模型怎么和精算指标对齐4.1 风险评估模型的目标不是「预测理赔」而是「估计期望赔付」风险精准评估和传统精算定价有一个核心差异精算用的 GLM 建模的是赔付频率和赔付金额的期望期望基于历史静态数据而多模态方案要做的是叠加动态信息比如用户最近的行为变化、健康文本描述里的风险信号、以及分群后群体风险基准。期望赔付成本可以用一个式子表达expected_claim_cost claim_frequency × claim_severity这里有两个模型频率模型和金额模型。频率模型解决「这个客户未来一年有多大概率出险」金额模型解决「出险后平均赔多少」。两个模型可以共用一套特征但损失函数不同一个用 Poisson 或负二项回归一个用 Gamma 回归。4.2 三个必调参数和损失函数选择4.2.1 频率模型的过离散处理保险数据的一个显著特点是方差大于均值也就是过离散。直接用 Poisson 回归会低估方差必然导致置信区间过窄、费率充足性判断错误。常用的做法是用负二项回归或者在 LightGBM 里用 Poisson 目标但把reg_alpha调高抑制极端预测值import lightgbm as lgb def train_frequency_model(train_df, valid_df): features [c for c in train_df.columns if c not in ( user_id, claim_freq, claim_amount, exposure )] # 用 exposure 作为样本权重处理不同客户保障期限不一致的问题 train_data lgb.Dataset( train_df[features], labeltrain_df[claim_freq], weighttrain_df[exposure], free_raw_dataFalse ) valid_data lgb.Dataset( valid_df[features], labelvalid_df[claim_freq], weightvalid_df[exposure], referencetrain_data ) params { objective: poisson, metric: poisson, learning_rate: 0.03, num_leaves: 63, max_depth: 6, min_child_samples: 200, reg_alpha: 1.5, reg_lambda: 3.0, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1 } model lgb.train( params, train_data, num_boost_round500, valid_sets[valid_data], callbacks[lgb.early_stopping(50)] ) return model用 weight 参数传 exposure 是关键不同客户保单生效的月份数不一样直接用粗保费计算出的频率会失真。观察期内只承保了 3 个月的客户和承保了 12 个月的客户权重不能相等。如果你发现验证集上poissonmetric 一直不降先检查是不是把 exposure 漏了而不是调学习率。4.2.2 金额模型用 Tweedie 还是 Gamma金额模型看数据分布。如果理赔金额中有大量零值比如住过院但没达到免赔额Tweedie 分布更合适如果只看已发生理赔的正数金额Gamma 回归更直接。LightGBM 对 Tweedie 的支持比较成熟params_amount { objective: tweedie, tweedie_variance_power: 1.5, metric: rmse, learning_rate: 0.02, num_leaves: 31, min_child_samples: 300, feature_fraction: 0.7, bagging_fraction: 0.7, bagging_freq: 1, verbose: -1 }tweedie_variance_power介于 1 到 2 之间越接近 1 越像 Poisson越接近 2 越像 Gamma。保险损失数据一般取 1.4 到 1.7 之间效果较好。这个参数不是随便选的可以用网格搜索在小验证集上先扫一圈步长 0.1 就够了。记得金额模型要对目标变量做 log1p 变换再评估误差因为赔付金额的分布跨度极大直接用原始金额计算 RMSE 会被几个大额赔案主导。4.3 从预测赔付到动态定价费率系数和 GLM 校准模型输出的期望赔付成本不能直接当价格卖给出单系统。原因是机器学习模型对极端值不敏感对低发生率产品缺乏精算公认的结构性而且监管通常要求费率可解释、可回溯。所以动态定价的标准做法是两步走模型算一个基础风险评分再用 GLM 把这个评分映射到费率表上。实际落地中我建议做「升降级系数」以当前基础费率为基准把模型的预测赔付率分成 10 档每档对应一个系数区间比如最低档 0.85最高档 1.45。这个系数必须通过假设检验验证单调性如果档位之间的风险差异不显著说明模型特征没有充分捕捉风险信号需要回到特征侧补数据。同时建议在模型中放入cum_premium和expected_claim的比值作为动态赔付率约束def compute_dynamic_price( base_premium: float, risk_score: float, claim_cost_estimate: float, target_loss_ratio: float 0.6 ) - float: # 定价目标是让预期赔付率不超过 target_loss_ratio floor_price claim_cost_estimate / target_loss_ratio uplift_factor 0.9 0.2 * (risk_score - risk_score.mean()) / risk_score.std() price max(base_premium * uplift_factor, floor_price * 1.05) return round(price, 0)这里设置floor_price * 1.05是为了保证最终定价高于赔付成本线的 5%防止价格战把自己打穿。动态定价系统上线前要做一次费率充足性回测用历史 3 年的数据模拟看按新定价规则假设赔付率是否落入 50% 到 70% 的区间。5. 工程化落地特征管线、推理成本和线上的三个验证指标5.1 用批处理降低 DeepSeek 调用成本线上推荐和风险评估如果每次都现调 DeepSeek 生成 embedding成本会吃不消。保险产品的语义特征产品画像是低频更新的可以离线每天或每周算一次用户的文本描述则依赖行为数据变化可以每 6 到 12 小时批量更新一次。实时部分只保留稀疏门控的切换和排序模型打分。常见做法是搭一个特征定时任务# 每天凌晨 2 点批量更新产品画像和用户 embedding 0 2 * * * python -m pipeline.update_product_embeddings 0 4 * * * python -m pipeline.update_user_embeddings --hours 6 # 每 30 分钟增量更新活跃用户的行为统计特征 */30 * * * * python -m pipeline.update_active_users --window 30min批量更新的好处不只是省钱还能规避生成式模型输出不稳定带来的线上执行风险。新增temperature0和固定seed可以显著降级结果漂移但不能完全消除所以任何 DeepSeek 生成的内容落到业务系统前都要配一个字面量校验器确认 JSON schema 完整。完整的校验逻辑要在主流程外运行不能让 API 响应里的解析异常影响正常的出单链路。5.2 线上服务的三个验证指标推荐和动态定价系统上线后最需要盯的指标不是点击率而是和风险相关的三个数指标计算方式预警线建议新客动态赔付率新客户赔付金额 ÷ 新客户已赚保费超过 75% 且连续 2 周上升分群迁移度月度客户所属 cluster 变化比例超过 30% 说明特征或分群不稳定推荐转化传导率曝光 → 详情 → 投保的漏斗转化率低于基准值 1.5 个百分点时查排序模型其中「分群迁移度」是最容易被忽视的。客户不会每周变一次风险类型如果分群标签频繁跳动不是模型问题就是特征管线出了问题。排查顺序是先看基础表的字段是否存在错位再看 embedding 是否因为文本模板改动而漂移最后检查 HDBSCAN 的重训练是否固定了随机种子。5.3 安全性和可解释性提示保险推荐和定价系统涉及用户健康和行为隐私。多模态特征中如果包含健康手环数据、体检结果等敏感字段必须在特征工程层做脱敏和分级授权原始数据不能进模型训练环境。模型侧也需要保留每一单的推荐理由和定价依据建议在排序模型输出的同时记录 Top 3 特征的贡献值精算审核时可以追查任何一单的定价原因。一个实用的技巧是用 DeepSeek 生成推荐理由模板。当用户问「为什么给我推这款产品」时把用户命中的 cluster profile 和产品的关键匹配点作为上下文让 DeepSeek 生成一段不超过 50 字的解释。这条链路的价值不在于提高转化率而在于满足合规的可解释性要求同时降低人工客服的解释成本。本文还有配套的精品资源点击获取