相亲交友软件已经不是一个简单的“看脸”工具而是典型的社交匹配系统。但在真实产品里很多团队花大力气优化了资料匹配度却忽略了一个更现实的需求如何用技术手段识别那些同时在几十个聊天窗口里广撒网、群发同样话术、甚至靠“养鱼”获取情感或经济收益的用户。在中文互联网语境里这类用户被形象地称为“海王”。如果只是做规则过滤比如限制“24小时内聊天人数上限”很容易误伤正常用户也很容易被绕过。更可靠的方向是把“海王识别”当作一个AI风控问题来处理用NLP分析聊天文本的重复度用图模型分析连接关系密度用异常检测分析行为时间分布再用大语言模型把判断结果解释给运营人员听。这篇文章不是来讨论相亲产品怎么设计而是从开发者视角拆解如何搭建一套“AI相亲风控系统”把海王筛选能力落到工程实现上。你会看到这类系统需要哪些特征、模型怎么分层设计、LLM在中间承担什么角色、以及怎么样避免误杀正常用户。1. 海王问题到底难在哪里很多新入行的开发者会觉得识别海王不就是“看谁聊天人数多”吗如果真这么简单产品就不会被用户骂“乱封号”了。海王行为本质上是一个多维度、动态变化、带有伪装性的行为模式问题。从行为特征看海王通常具备几个特点广撒网同时与大量异性用户建立聊天关系消息量呈爆发式增长。话术复用同一段自我介绍、同一句关心、同一个约会邀请被批量发送给不同对象。时间规律异常不是正常人的晚8点到11点活跃而是全天候碎片化打卡式回复。关系网络异常连接度高、但人群之间没有社交交集形成“星型结构”而非“圈层结构”。目标导向聊天内容通常会很快从寒暄转向索要联系方式、引导线下见面或诱导付费。难点在于单项指标不能判定一个人就是海王。比如活跃用户、销售型用户、社交达人同样会有大量聊天行为。如果只按“消息数超过阈值”来处罚会误伤那些真正在认真经营关系的人。所以AI系统要做的事情不是给用户贴一个永久标签而是输出一个动态风险评分并给出可解释的证据链。评分高不代表立刻封禁而是触发人工审核、降低推荐权重或者限制部分操作。2. 从产品角度看为什么要用 AI 来做这件事传统规则引擎的典型写法是这样的if 最近24小时聊天人数 20: 标记为疑似海王这种规则在小规模产品里够用但产品用户量到百万级别时问题会集中爆发。第一个问题是规则太容易被绕过。海王用户知道平台限制“24小时聊20个人”就把聊天分散到3天每天聊7个人。规则反而帮助对方学会了如何隐藏行为。第二个问题是上下文信息被白白浪费。两个用户是否在交换联系方式、是否多次出现相似句子、是否在某段时间内密集对多个人发出同一邀约这些信息靠字段判断根本拿不到。而NLP模型可以从文本里提取出“话题意图”“情绪张力”“复读概率”这些才是识别海王的关键信号。第三个问题是人工审核成本失控。没有AI排序运营人员只能按举报量处理每天几千条举报根本看不过来。AI先做初筛把风险用户按严重程度排序人工只审核Top 10%工作效率完全不同。更重要的一个原因是AI系统可以把“判断标准”沉淀成模型资产。今天能识别“海王”明天就能识别“杀猪盘”“酒托”“虚假照片党”。平台积累的风控能力可以复用而不是每次遇到新问题就重新写一套规则。3. 实现海王识别最核心的算法模型有哪些海王识别不是一个单一的深度学习模型而是一个多模型协同的分层架构。实际落地时建议按下面三层来组织。3.1 规则与统计层这一层最基础也最快见效。包括实时特征计算、阈值检测、聚类分析。比如用户过去7天消息总量和唯一聊天对象数。同一句话的发送次数和发送对象数。消息发送时间的熵值熵越低说明时间模式越集中。头像是否频繁更换、地理位置是否漂移。规则层的价值不是直接给结论而是为后续模型提供特征。3.2 行为序列与图模型层把用户在平台上的行为当成序列或图结构来处理可以看到规则看不到的全局模式。行为序列模型可以用LSTM或Transformer处理“用户点击了谁 → 发了几条消息 → 对方回复率是多少 → 是否发起位置共享”。一个正常用户的行为是有反馈循环的会花时间等待回复、调整话题。海王的行为则呈现出“发完就跑”“大量单向消息”的特征。图模型则更有意思。把用户看作节点把聊天关系看作边海王节点通常具备高中心性、低聚类系数。用社区发现算法能把正常交友圈和海王的星型网络分开。3.3 大语言模型语义层到了这一步才轮到LLM上场。大模型在风控里不是用来做硬判断的而是用来做语义理解和解释生成。比如模型可以先判断“这条消息是否在和多个用户重复发送”。用Sentence-BERT把消息编码成向量算相似度一旦发现相似度超过0.9的模板消息被发给了N个不同用户就把模板内容和所有接收者信息打包交给LLM让LLM按固定Schema输出“是群发”“是批量邀约线下见面”“是索取联系方式”。LLM还能生成人工审核需要的解释报告。比如“该用户在72小时内向37个用户发送了相同文案‘周末有空吗带你吃一家我私藏的店’其中29位没有回复该文案与历史处罚样本相似度为0.94。”4. 特征工程什么数据能真正衡量“海王指数”下面进入实战环节。假设我们手上的数据表是这样的users表用户基本信息。messages表聊天消息包含发送者、接收者、内容、时间。matches表配对关系。reports表用户举报记录。要计算一个“海王指数”可以设计如下特征。特征名计算方式业务含义chat_peer_cnt_7d近7天去重聊天对象数触点广度msg_cnt_7d近7天发送消息总数互动强度unique_msg_ratio去重后的模板消息数 / 总消息数话术复用度avg_reply_rate平均收到回复的比例对方认可度late_night_msg_ratio凌晨消息占比非正常社交时间peer_cluster_coef聊天对象之间的共同好友密度网络聚集度zero_reply_peer_cnt聊天但从未有回复的对象数单向轰炸程度intent_social_ratio文本中提取到社交意图的比例目标导向性time_entropy_7d消息发送小时分布的熵值时间分散程度这些特征加起来就是对“海王行为”的第一层刻画。接下来给出一个Python实现把上面的特征全部计算出来。# 文件路径feature_engineering.py import pandas as pd import numpy as np from collections import Counter from sklearn.preprocessing import StandardScaler def compute_time_entropy(hours: pd.Series, bins: int 24) - float: 计算消息发送时间分布的熵值。 熵越低说明消息集中在少数时间段熵越高说明全天候分散。 正常用户通常在 20~23 点集中熵值偏低但不会过低 海王用户为了避免错过任何潜在对象往往全天候回复。 hist, _ np.histogram(hours, binsbins, range(0, 24)) prob hist / (hist.sum() 1e-9) prob prob[prob 0] entropy -np.sum(prob * np.log(prob)) return entropy def build_sea_king_features(messages: pd.DataFrame, users: pd.DataFrame) - pd.DataFrame: 输入: messages: 至少包含 user_id, target_id, content, created_hour, created_date 列 users: 用户基础表, 至少包含 user_id 列 输出: 每个 user_id 的海王风险特征。 # 1. 基础指标 g messages.groupby(user_id) features pd.DataFrame(indexusers[user_id]) features[msg_cnt_7d] g.size() features[chat_peer_cnt_7d] g[target_id].nunique() # 2. 模板消息复用度 msg_count_by_text messages.groupby([user_id, content]).size().reset_index(namecnt) max_repeat msg_count_by_text.groupby(user_id)[cnt].max() features[max_msg_repeat] max_repeat features[unique_msg_ratio] msg_count_by_text.groupby(user_id).size() / (features[msg_cnt_7d] 1e-9) # 3. 回复率 replied messages.groupby([user_id, target_id]).agg( sent_cnt(content, size), replied_cnt(content, lambda x: 0) # 需要实际业务字段 ).reset_index() # 实际项目中, replied_cnt 应该来自消息表里的 reply_flag 字段 # 这里做语法演示真实字段请按业务替换 if reply_flag in messages.columns: replied messages.groupby([user_id, target_id]).agg( sent_cnt(content, size), replied_cnt(reply_flag, sum) ).reset_index() peer_stats replied.groupby(user_id).agg( avg_reply_rate(replied_cnt, lambda x: x.sum() / (x 1e-9).sum()), zero_reply_peer_cnt(replied_cnt, lambda x: (x 0).sum()) ) features features.join(peer_stats) # 4. 时间熵 entropy_map messages.groupby(user_id)[created_hour].apply(compute_time_entropy) features[time_entropy_7d] entropy_map # 5. 凌晨消息占比 features[late_night_msg_ratio] messages.groupby(user_id)[created_hour].apply( lambda x: ((x 0) (x 5)).mean() ) # 6. 填充并标准化 features features.fillna(0) scaler StandardScaler() feature_cols features.columns.tolist() features[feature_cols] scaler.fit_transform(features[feature_cols]) return features这段代码有几个地方要特别注意。compute_time_entropy计算的是24小时分布的信息熵正常用户一般在2.5到3.2之间海王如果真的是全天候回复熵值可能超过3.5。但只用熵值判断不够因为有些做跨境电商的用户也会全天候活跃。所以要结合late_night_msg_ratio和avg_reply_rate一起看。unique_msg_ratio这个特征非常关键。正常用户聊天会带上上下文每条消息内容差异很大模板话术则会有大量完全相同的句子。实际实现时建议先把消息做归一化比如去掉标点、表情、联系人小名再按归一化后的文本去重否则相似话术会因为标点差异逃过统计。5. 判断“群发话术”的语义向量方法规则统计能抓到精确重复但抓不到“意思一样、表达不同”的变体。比如下面这组消息字符串完全不同但明显是同一套话术的变体“在吗认识一下行吗”“哈喽在吗认识一下”“你好在吗能认识下吗”如果不做语义向量化这三条会被当成三条不同消息模板复用度特征就失效了。所以要引入文本向量化模型。# 文件路径semantic_dedup.py from sentence_transformers import SentenceTransformer import numpy as np from sklearn.metrics.pairwise import cosine_similarity # 选择一个中文语义向量模型具体版本请以模型仓库为准 model SentenceTransformer(shibing624/text2vec-base-chinese) def calc_group_similarity(messages: list[str], threshold: float 0.85) - float: 计算一组消息中高相似对的比例。 返回 0~1 之间的值越接近 1 说明群发模板化越严重。 if len(messages) 2: return 0.0 embeddings model.encode(messages, normalize_embeddingsTrue) sim cosine_similarity(embeddings) # 去掉自身比较只看上三角 upper np.triu(sim, k1) high_sim_count (upper threshold).sum() total_pairs upper.shape[0] * (upper.shape[1] - 1) // 2 return high_sim_count / max(total_pairs, 1)注意在真实生产环境不要让每个用户请求都实时调用向量模型成本太高。建议用离线批处理任务每小时跑一次把每个用户的最近100条消息两两计算相似度得到dup_similarity_ratio特征后写入特征存储。如果团队没有GPU资源也可以先用TF-IDF 哈希技巧做轻量版# 文件路径tfidf_fast_sim.py from sklearn.feature_extraction.text import TfidfVectorizer def calc_idf_similarity(messages: list[str], threshold: float 0.8) - float: if len(messages) 2: return 0.0 vec TfidfVectorizer(analyzerchar_wb, ngram_range(2, 3), max_features10000) matrix vec.fit_transform(messages) norm matrix / np.linalg.norm(matrix.toarray(), axis1, keepdimsTrue) sim norm norm.T upper np.triu(sim, k1) return (upper threshold).sum() / max(upper.shape[0] * (upper.shape[1] - 1) // 2, 1)TF-IDF版本的特征效果会差一些但优点是快CPU上就能跑。实际项目中可以先上TF-IDF版本建立 baseline再逐步升级到语义向量版本。6. 用图模型识别“海王星型网络”文本特征做得再好还是有一个边角问题如果海王跟每个人都发完全不同的话术呢这种用户已经懂得反制文本检测再用文本模型就很难抓。这时候图模型的价值就体现出来了。把所有用户之间的聊天关系建模成一个无向图或带权有向图海王的典型结构是一个中心节点连接几十个几乎互不相识的叶子节点。社区发现算法可以把这种结构找出来。下面用NetworkX实现一个轻量检测。# 文件路径graph_detection.py import networkx as nx from networkx.algorithms.community import greedy_modularity_communities def build_chat_graph(messages): 将聊天关系转换成图。 边权 两个用户之间双向消息数。 只保留至少有一次双向互动的边避免把单向骚扰也算成强关系。 G nx.Graph() msg_pairs messages.groupby([user_id, target_id]).size().reset_index(nameweight) msg_pairs msg_pairs[msg_pairs[weight] 2] G.add_nodes_from(set(msg_pairs[user_id]) | set(msg_pairs[target_id])) for _, row in msg_pairs.iterrows(): G.add_edge(row[user_id], row[target_id], weightrow[weight]) return G def detect_star_centers(G, min_degree15): 找星型网络中心节点。 min_degree 表示至少连接多少人实际阈值需要根据平台平均连接数校准。 result [] degrees dict(G.degree()) for node, deg in degrees.items(): if deg min_degree: continue neighbors list(G.neighbors(node)) if len(neighbors) min_degree: continue subgraph G.subgraph(neighbors) # 邻居之间的实际边数 edge_count subgraph.number_of_edges() # 理论最大边数 max_edge len(neighbors) * (len(neighbors) - 1) / 2 density edge_count / max_edge # 星型结构的邻居之间密度极低 if density 0.05: result.append({ user_id: node, degree: deg, neighbor_density: round(density, 4) }) return resultdensity 0.05这个阈值要根据平台的数据分布调整。如果平台用户本来就在不同城市彼此之间没有好友关系很正常密度天然偏低所以要和“同城区域”联合考虑。更稳妥的做法是把社区发现结果和地理信息拼接起来只对同一城市内、邻居互不认识、且中心节点活跃度极高的子图打高分。7. LLM 生成审核意见把模型输出转成可读报告传统风控系统的缺点是模型输出一个0到1的风险分数运营人员看到分数并不清楚该做什么。而LLM可以把风险因子整合成一份“解释报告”让运营人员一眼看出该用户可疑在哪里。这里要强调不要让LLM直接决定封不封号而是让LLM做“归因摘要”。惩罚决定由规则和人工审核共同完成。建议的Prompt结构如下。# 文件路径llm_review.py from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlYOUR_LLM_ENDPOINT # 生产环境建议自建或使用合规云服务 ) def generate_review_report(user_id, risk_features, repeat_messages): prompt f 你是一名婚恋交友平台的安全审核助理。请根据以下特征数据判断该用户是否存在“海王”行为 并输出JSON格式的审核摘要。 用户ID: {user_id} 风险特征: {risk_features} 疑似群发话术示例: {repeat_messages[:5]} 请按以下格式输出: {{ risk_level: low | medium | high, evidence: [证据1, 证据2], conclusion: 不超过100字的结论说明, suggestion: 建议人工电话回访 / 建议降低推荐权重 / 建议限制部分功能 / 建议封禁 }} resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是严谨的风控审核助手只基于给定事实判断不臆测用户意图。}, {role: user, content: prompt} ], temperature0.2, response_format{type: json_object} ) return resp.choices[0].message.content这里用大模型不是因为它能“识别海王”而是因为它擅长把多个特征组合成一个连贯的解释。真正的判断信号在特征里LLM只是把特征翻译成了人话。使用LLM时要注意几个工程问题。第一Prompt必须固化版本。上线后修改Prompt要用新版本号并存审批记录否则线上输出不可回溯出问题后无法定位。第二大模型的输出一定要做JSON Schema校验。不要直接信任返回内容解析失败的样本要落到降级队列交给人工处理。第三成本控制。LLM审核只对“规则层已经命中Top风险特征”的用户执行而不是对全量用户跑大模型。比如先让统计特征筛选出前5%的用户再对这5%调用LLM。8. 完整的最小可运行原型到这一步我们把所有模块串起来。下面是一个完整的离线批处理流程按天执行输出每个用户的海王风险评分。# 文件路径run_sea_king_batch.py 每日离线任务计算所有用户的海王风险评分 运行方式: python run_sea_king_batch.py 依赖: pandas, numpy, networkx, scikit-learn, sentence-transformers import pandas as pd from feature_engineering import build_sea_king_features from semantic_dedup import calc_group_similarity from graph_detection import build_chat_graph, detect_star_centers # 1. 从数仓读取前一天的数据路径仅为示例 messages pd.read_csv(data/messages_20250101.csv) users pd.read_csv(data/users_20250101.csv) # 2. 计算行为统计特征 features build_sea_king_features(messages, users) # 3. 计算语义相似度特征 # 实际生产建议按用户分组后批量计算这里演示100个用户 demo_users users[user_id].head(100) sim_features {} for uid in demo_users: msgs messages[messages[user_id] uid][content].tolist()[:100] if len(msgs) 5: sim_features[uid] calc_group_similarity(msgs) features[semantic_dup_ratio] features.index.map(sim_features).fillna(0.0) # 4. 图模型特征 G build_chat_graph(messages) star_centers detect_star_centers(G, min_degree10) star_score {item[user_id]: 1.0 for item in star_centers} features[star_network_flag] features.index.map(star_score).fillna(0.0) # 5. 综合风险分权重需要根据线上效果调优 features[risk_score] ( features[chat_peer_cnt_7d] * 0.3 features[unique_msg_ratio] * 0.2 features[semantic_dup_ratio] * 0.2 features[zero_reply_peer_cnt] * 0.15 features[star_network_flag] * 0.15 ) # 6. 输出Top风险用户供运营复核 top_risk features.nlargest(100, risk_score) top_risk.to_csv(output/sea_king_risk_top100.csv, encodingutf-8-sig) print(top_risk[[risk_score, chat_peer_cnt_7d, semantic_dup_ratio]].head(10))这段代码把前面三章讲的能力整合在了一起。运行后sea_king_risk_top100.csv就是人工审核的排队队列。这里的权重数字只是示例真实项目需要用历史已确认海王样本做训练调优。建议把整条流程拆成三个Spark任务或Pandas批任务前两个可以并行执行第三步依赖前两步的结果做合并。注意在数据量达到千万级用户时Pandas单机内存会吃紧建议用Spark或ClickHouse SQL先计算聚合特征。9. 运行结果如何评估模型效果怎么样才算好任何风控模型上线前都要定义清楚成功率否则算法团队和运营团队会陷入无休止的“误杀”纠纷。建议关注这几个指标。指标定义目标参考值精确率被标记用户中确实是海王的比例不低于85%召回率真实海王中被模型找出的比例依赖业务容忍度误杀率正常用户被标记的比例低于2%人工复核效率平均审核单耗时少于30秒举报转化率被标记用户后续被举报的比例应显著高于基线注意精确率和误杀率要分开看。如果你的产品宁可错过不可错杀那精确率可以放到90%以上召回率低一点没关系。如果是社交平台面对严重杀猪盘威胁可能就得牺牲一定精确率换来更多人工复核。评估样本从哪来建议复用传统风控体系的“黑白样本库”。黑样本包括人工已确认的封禁用户白样本包括注册超过180天、有稳定好友互动、从未被举报的活跃用户。把这两类用户按时间切分用前90天特征预测后30天是否成为海王按时间序列做回测而不是随机切分因为随机切分会引入前视偏差。10. 常见问题与排查思路很多团队在实现“AI识别海王”时会踩到同样的坑我把它整理成一张排查表。问题现象可能原因排查方向解决方案模型对高活跃用户全部误杀特征里没有加入“对方回复质量”类负向特征检查avg_reply_rate是否有效高活跃但回复率也高的用户可能只是真实社交达人增加正反馈特征把“被对方主动发起聊天”作为反向权重语义相似度计算结果不稳定消息文本没有去表情和昵称变量对比归一化前后的相似度分布统一做emoji转文本、昵称脱敏、拼音转中文图模型把线下业务人员全判为海王销售型账号同样有大量无交集连接看行业特征字段排除已认证的企业号或单独建立“职业社交”白名单LLM生成的结论不一致没有固定temperature或Prompt顺序引起随机性将temperature降到0.1以下多次采样对比固定Prompt版本并加入few-shot示例离线特征和线上实时特征不一致训练用离线全量聚合上线用近期窗口聚合对比两类特征的分布偏移统一特征口径改为离线日报在线近实时双链路每天都有新增海王封不完缺少注册源头风控查看新注册用户的设备指纹和IP风险分在注册阶段增加设备指纹和基础风险评估最容易踩的坑是“把LLM当主模型”。有些团队直接拿GPT判断所有用户是否为海王结果成本爆炸而且模型幻觉导致误杀严重。正确姿势是规则层做初筛传统模型层做精排LLM层只做解释和辅助决策。还有一个工程细节特征复用。海王识别模型的特征很多可以复用到其他风控场景。比如semantic_dup_ratio可以复用到广告评论识别、水军识别、关键词引流识别。在设计表结构时把特征存储做成独立模块不要和具体业务耦合后期扩展会轻松很多。11. 数据安全与伦理边界技术上有能力识别海王不代表可以无限制使用用户数据。做这个系统时一定要守住几个原则。第一最小必要原则。你只需要知道“这条消息是否与其他群发消息相似”不需要知道用户聊天的具体隐私内容。建议在特征计算完后就丢弃或脱敏聊天原文只保留向量和统计数据。向量虽然也能反推部分语义但至少增加了成本。第二用户知情权。很多国家对个人信息保护有严格要求平台应在隐私政策里明确说明数据用于安全风控。在注册阶段不要用一串冗长晦涩的协议而是用“安全中心”页面通俗写明系统会根据聊天行为模式识别异常账号。第三申诉渠道必须完备。AI判断只是概率判断不是事实认定。被降权的用户如果提出申诉平台应提供人工复核能力。实务上误伤了正常用户后一次诚恳的人工回访和解释比发100行道歉邮件更有效。第四禁止“公开处刑”。不要给用户打上“海王”标签并展示给其他用户这在法律和伦理上都有很大风险。平台内部可以用“风险编号”代替“海王”等有侮辱性的标签。第五避免训练数据偏见。如果历史训练样本全部来自男性用户模型会对女性用户误判率上升如果历史封禁样本里有大量特定职业的用户模型也可能产生职业偏见。上线前要分析不同人口属性分组下的误杀率确保没有明显差异。12. 最佳实践一套可以落地的工程框架最后总结一下我在实际项目里比较推荐的海王识别系统框架。整体架构分为四层第一层是数据层。把用户资料、消息日志、配对记录、举报记录统一入仓按天分区。所有特征计算都从数据层读取不在业务库直接跑SQL避免影响线上性能。第二层是特征层。写一个独立的特征工程库包含前面讲到的统计特征、语义特征、图特征。每个特征必须定义好口径、时间窗口、依赖表和启动时间。特征上线前要跑数据质量校验比如空值率不能超过5%、分位分布不能突变。第三层是模型层。模型按两阶段设计第一阶段用LightGBM或XGBoost做精排输出风险分第二阶段用LLM生成解释报告。对风险分前1%的用户走“强限制”策略对前5%但不到1%的用户走“弱限制”策略其余用户不做处理。第四层是审核与闭环层。所有标记结果都进入人工审核工作台。运营人员每天处理审核单后将确认结果回传形成新的训练样本。这个闭环比任何算法优化都重要因为没有高质量反馈数据模型只会越跑越偏。关于模型选型LightGBM在海王识别这种表格型特征任务上仍然是最稳妥选择。深度学习模型如GraphSAGE可以提升图特征的效果但工程复杂度高很多建议先上LightGBM等图模型收益验证充分后再引入。关于部署方式风险分可以在用户登录后实时请求一次也可以在每日固定时间批量更新。建议混合登录时返回昨天的离线评分叠加实时行为特征做增量判断。比如“离线评分80分 当前小时又主动发起了50条新消息”可以直接触发临时降权。写到这里这套“AI相亲专业屏蔽海王”的技术方案已经比较完整。从行为统计特征到语义相似度到图网络检测再到LLM生成审核报告每一步都在解决一个具体问题。如果你正在做交友社交类产品建议先从特征工程和规则层做起先把人工审核效率提上来再逐步引入深度学习与LLM不要一开始就上大模型。技术是为产品目标服务的识别海王不是目的让认真交友的人获得更好的体验才是目的。