如果你做过社交类 App 的后台大概率见过两类数据一类是用户增长曲线另一类是投诉工单。而在相亲平台投诉工单里出现频率最高的往往不是系统 Bug而是那句话“我遇到一个不靠谱的人。”这类用户有一个通俗称呼海王。很多团队第一次听到“AI 相亲专业屏蔽海王”这个需求时第一反应是做一个聊天机器人代替用户去和对方聊天。这个方向其实从一开始就跑偏了。真正值得做的不是替用户聊天而是构建一套基于行为数据与语义信号的风险识别系统。它不能替用户决定谁值得爱但可以帮用户避开那些高并发、模板化、低稳定性的连接。这篇文章会从问题建模、系统架构、技术选型、代码实现到上线评估完整拆解一套可用于相亲场景的“海王识别”系统。读完你会理解为什么这类功能不能只靠关键词黑名单文本、网络、行为三类特征分别怎么设计以及上线时最容易被忽略的误判和数据合规问题。1. 为什么相亲平台需要“AI 屏蔽海王”先讲一个业务层面的事实情感类平台最核心的资产不是用户数量而是信任感。一个用户如果在平台里连续遇到几次“广撒网”式聊天、刚认识就要求加微信、约见面、甚至诱导付费的用户他对平台的信任度会快速归零。更麻烦的是这类用户往往不会只伤害一个人他们会同时和多位用户保持高频互动产生大量低质量对话。一个海王用户可能在一个月内劝退十几个真实付费用户这种负反馈会直接体现在次日留存和投诉率上。传统平台处理这类问题的方式基本是“事后封禁”。用户反复举报运营人员手动查看聊天记录确认后封号。这套流程有三个明显问题。第一时效性差。从用户举报到运营确认中间可能已经过去好几个小时受到伤害的用户早就流失了。第二覆盖面窄。人工审核只能覆盖被举报的账号大量未被举报的高危用户仍然在正常活跃。第三对抗成本低。被封号后换个手机号重新注册用相似的话术继续拉人传统黑名单几乎没有防守能力。所以AI 在这里的价值不是“更聪明地封人”而是把一个事后处理问题转变成一个事前风险评分问题。系统在用户产生异常行为时就能给出风险预警让运营在投诉发生之前介入。这才是“AI 相亲屏蔽海王”这句话背后的真实需求。维度传统人工审核AI 风险识别发现时机用户投诉后行为异常实时触发处理方式人工查看记录自动计算风险分覆盖范围被举报账号全量用户行为对抗能力换号即可绕过设备、网络、行为多维关联误伤风险依赖审核主观判断阈值策略可配置可回滚2. “海王”行为的可计算特征文本、网络与行为信号要做识别首先要解决一个建模问题什么是“海王”在技术语义下我们不对用户做道德评判只定义一组可量化的行为模式。海王行为的本质可以概括为高密度并发社交、模板化表达、快速关系推进和信息一致性偏低。从数据角度这四类特征分别对应不同的技术信号。第一高密度并发社交。普通用户在同一时间段内通常只和一到两个对象保持深入沟通而海王需要维持多线操作。表现在行为数据上就是单位时间内主动发起的会话数明显高于正常分布而且会话之间切换频繁回复间隔不稳定。这个特征可以通过关系网络和会话时间戳计算。第二模板化表达。海王要和大量用户建立初步认识不可能每次都想出新的开场白。他通常会准备几套通用话术比如“在吗”“你很特别”“我平时不太玩这个软件加微信聊吧”。这些文本之间会有较高的相似度甚至完全相同。可以通过文本向量化与聚类检测。第三快速关系推进。普通相亲用户也会在合适时机提出加微信但通常会有几个来回的互动铺垫。海王为了提升转化效率往往在前几句聊天中就要求加微信、发照片、约见面。这种节奏异常可以通过对话轮次、时间跨度和特定意图标签来量化。第四信息一致性偏差。海王通常会包装一个更有吸引力的身份因此照片、职业、年龄、所在地等信息在不同对话中可能不一致或者和注册信息冲突。虽然这部分数据比较敏感但在用户授权场景下可以通过基础信息核对和画像比较来发现异常。这些特征并不需要一次性全部接入。一个最小可用版本可以先做文本相似度、主动会话频率和联系方式转移意图三项后续再逐步增加网络分析能力。3. 整体架构与关键技术选型从工程角度看这个系统并不神秘。它和内容安全、反作弊、风险控制体系非常相似核心链路是数据接入、特征计算、模型推理、决策执行、人工复核。整体架构可以按下图理解。数据接入层主要负责获取用户聊天文本、会话行为、基础画像和设备信息所有原始字段必须经过脱敏和授权校验。特征计算层把原始数据转换为文本风险分、行为特征值、网络中心度等结构化特征。模型推理层根据特征计算出综合风险分并映射到不同处置动作。决策执行层负责降权、限制推荐、进入人工复核队列等操作。技术选型上建议从“能维护、可迭代、不过度设计”的角度出发而不是一上来就上大模型。文本语义分析模块最小可信版本可以用 TF-IDF 加逻辑回归训练成本低、可解释性强。等积累一定标注数据后再换成预训练模型或者大模型 API用来识别更复杂的“话术变体”。行为特征计算建议用 Python 生态的 NetworkX便于快速做多账号关系网络分析。如果数据量到了千万节点以上再考虑迁移到图数据库或图计算引擎。服务层建议使用 FastAPI 或 Spring Boot 搭建这部分根据团队技术栈选择即可。决策状态可以用 Redis 做临时缓存审核结果落 PostgreSQL这样既满足实时读取需求也能保留完整审计记录。关于模型选择我有一个比较明确的判断在这个场景里模型不是越复杂越好。相亲平台每天产生的聊天数据量足够大但高质量标注数据是稀缺的。复杂模型在少量标注数据上很容易过拟合反而导致误伤率上升。先用简单模型跑通流程建立人工复核闭环是更稳的落地路径。4. 环境准备与前置条件在开始写代码之前先确认环境依赖。本文演示代码使用 Python 3.9 及以上版本核心依赖库包括 FastAPI、Uvicorn、Redis、NetworkX、Jieba、Scikit-Learn、Pandas。数据库部分使用 PostgreSQL 保存审核记录使用 Redis 保存实时决策状态。具体版本请以实际项目环境为准不建议盲目追求最新版本稳定版本优先。创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install fastapi uvicorn redis networkx jieba scikit-learn pandas如果你暂时没有 Redis 和 PostgreSQL也可以用本地内存和 SQLite 先把流程跑通。整个示例不依赖外部大模型也不需要 GPU普通开发机就可以运行。README 风格的项目结构建议如下love_guard_demo/ ├── backend/ │ ├── risk_engine/ │ │ ├── network_analyzer.py │ │ ├── intent_text_analyzer.py │ │ └── score_service.py │ └── api/ │ └── main.py ├── config/ │ └── risk_engine.yaml └── tests/ └── test_risk_engine.py这个结构把风险计算逻辑和 API 层分离核心测试不依赖外部服务。实际项目中你还需要在此基础之上增加任务队列、监控告警和配置中心模块但核心思路是一致的。5. 核心流程拆解5.1 数据接入与授权这一步是整个系统的合法性基础。聊天记录属于敏感个人信息不能在没有用户授权的情况下直接采集。在相亲平台实际落地时必须在用户协议中明确说明“平台会对聊天内容进行安全风险分析”并且提供关闭个性化风险提示的选项。技术侧需要使用脱敏 ID 代替真实手机号原始聊天文本只能在服务端加密存储特征计算完成后优先删除原始数据。如果这一步没有做对后续所有技术方案都可能因为合规问题无法上线。风险识别系统本身是为了保护用户不能在保护过程中变成新的隐私泄露点。5.2 文本特征提取文本特征的核心目标是识别“模板化话术”和“快速转移联系方式”的意图。具体做法是把聊天记录按会话分组对每条消息做分词和向量化然后计算不同会话之间文本相似度相似度异常高的用户具有明显的模板化群发特征。同时需要识别包含“微信”“电话”“见面”“照片”等关键词的意图句子并计算这些意图出现在对话前多少轮。如果用户在前三轮就尝试转移联系方式就会被标记为高风险。在实际项目中文本特征还需要考虑语音消息转文本、表情、图片等模态。但最小版本可以先从纯文本入手。5.3 行为特征计算行为特征不依赖消息内容只依赖行为模式因此更稳定也更难被用户感知和对抗。关键指标有三个单位时间主动发起会话数、会话并发数、短时间窗内联系人数。一个普通用户一天主动发起的会话可能是个位数而海王用户可能在一个小时内联系十几个人。通过设置滑动时间窗口和阈值就能得到风险分。这里要特别强调时间窗口的选择。窗口太短比如五分钟只能识别极端刷屏行为错过正常节奏的高危用户窗口太长比如一天可能把营销号或平台活跃用户也误判进来。比较好的做法是先统计平台正常用户行为分布用 P95 或 P99 分位作为参考阈值。5.4 多账号网络分析多账号网络分析的目的是识别换号对抗。海王账号被封后往往会重新注册账号但设备信息、常用 IP、注册手机号段、人脸特征可能保持一致。系统可以通过设备指纹将这些账号关联成同一个实体。在技术实现上最简单的方案是构建一个“用户-设备”二分图如果多个用户账号使用同一设备就在图中建立连接。通过计算节点中心度可以识别出聚集了大量账号的可疑设备。更进一步还可以利用图连通分量找出批量注册的账号团伙。需要注意的是设备信息字段属于高敏数据在中国法律法规下需要履行告知义务并取得用户同意。实际项目里多账号网络分析通常只用于模型特征不会直接展示给用户。5.5 综合评分与处置综合评分把文本风险、行为风险、网络风险三项特征加权合并成一个 0 到 1 之间的风险分再根据阈值映射成三个处置等级放行、人工复核、限制推荐。这里最关键的设计原则是不要设置直接封禁的自动化策略。AI 模型的判断永远存在误差直接封号会把误伤变成不可逆的用户伤害。更稳妥的做法是分阶段处置。低风险用户正常推荐中风险用户进入人工复核队列由运营根据证据链确认高风险用户先降低推荐权重限制部分互动功能同时提示对方用户“该账号存在异常行为风险”。综合评分公式可以简单表示为最终风险分 0.3 × 文本风险分 0.4 × 网络中心度 0.3 × 短时联系强度权重比例需要根据平台数据分布动态调整。如果你发现误伤率高就应该降低文本权重或网络权重如果漏放率高则需要提高行为特征权重。6. 完整示例代码与实现下面我们用一个最小实现演示如何搭建这套系统的核心模块。代码可以复制到本地直接运行主要用于理解流程不包含真实业务数据。6.1 多账号与行为网络分析模块文件路径backend/risk_engine/network_analyzer.pyimport networkx as nx from collections import defaultdict from datetime import datetime, timedelta class UserNetworkAnalyzer: def __init__(self): self.graph nx.DiGraph() def add_interaction(self, user_a: str, user_b: str, ts: datetime): if not self.graph.has_edge(user_a, user_b): self.graph.add_edge(user_a, user_b, timestamps[]) self.graph[user_a][user_b][timestamps].append(ts) def calc_centrality(self, user_id: str) - float: if user_id not in self.graph: return 0.0 return nx.degree_centrality(self.graph).get(user_id, 0.0) def detect_same_device_accounts(self, account_device_map: dict) - dict: device_accounts defaultdict(list) for account, device in account_device_map.items(): device_accounts[device].append(account) return {device: accounts for device, accounts in device_accounts.items() if len(accounts) 1} def rapid_succession_contacts(self, user_id: str, window_minutes: int 30) - int: if user_id not in self.graph: return 0 contact_points [] for target in self.graph.successors(user_id): for ts in self.graph[user_id][target][timestamps]: contact_points.append((target, ts)) contact_points.sort(keylambda x: x[1]) pair_count 0 for i in range(len(contact_points)): for j in range(i 1, len(contact_points)): delta (contact_points[j][1] - contact_points[i][1]).total_seconds() / 60 if delta window_minutes: pair_count 1 else: break return pair_count这段代码的思路很直接。add_interaction记录用户之间的主动会话关系和时间戳calc_centrality计算节点在图中的中心度用于衡量该用户连接广度rapid_succession_contacts统计用户在一个时间窗口内主动联系他人产生的组合次数组合次数越高说明多线操作越密集。实际生产环境中这个模块需要连接图数据库或流式计算引擎但核心算法逻辑是相通的。6.2 文本意图识别模块文件路径backend/risk_engine/intent_text_analyzer.pyimport jieba from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import make_pipeline class IntentTextAnalyzer: def __init__(self): jieba.setLogLevel(20) self.stopwords {的, 了, 是, 啊, 吧, 呢, 吗, 嘛} self.model make_pipeline( TfidfVectorizer(tokenizerself.tokenize, lowercaseFalse), LogisticRegression(max_iter1000) ) self.trained False def tokenize(self, text: str): return [w for w in jieba.cut(text) if w.strip() and w not in self.stopwords] def train(self, texts, labels): self.model.fit(texts, labels) self.trained True def predict(self, text: str) - dict: if not self.trained: return {label: unknown, score: 0.0} label self.model.predict([text])[0] proba self.model.predict_proba([text])[0] return {label: label, score: float(proba.max())}这段代码演示了从文本到风险标签的完整流程。训练阶段需要准备两类标注数据正常开场白和风险话术。例如“你好很高兴认识你”可以标注为正常“加个微信吧”“约吗”“你很特别加微信聊”可以标注为风险。真实项目里文本标注需要运营人员和模型团队共同完成并定期更新因为话术会随着用户对抗行为不断变化。作为一个最小实现这里使用 TF-IDF 加逻辑回归优点是解释性强、训练快。如果团队有条件后续可以替换为基于大模型的意图抽取服务但需要注意延迟和成本控制。6.3 综合评分与处置模块文件路径backend/risk_engine/score_service.pyclass RiskScoreService: WEIGHTS { text_risk: 0.3, network_risk: 0.4, behavior_risk: 0.3, } def __init__(self, network_analyzer, intent_analyzerNone, redis_clientNone): self.network_analyzer network_analyzer self.intent_analyzer intent_analyzer self.redis redis_client def compute(self, user_id: str, profile_text: str, recent_chat_texts: list) - dict: text_risk 0.0 if self.intent_analyzer is not None: text_feature self.intent_analyzer.predict( .join(recent_chat_texts[:5])) if text_feature.get(label) risk: text_risk float(text_feature.get(score, 0.0)) network_centrality self.network_analyzer.calc_centrality(user_id) behavior_count self.network_analyzer.rapid_succession_contacts(user_id) score ( self.WEIGHTS[text_risk] * text_risk self.WEIGHTS[network_risk] * min(network_centrality, 1.0) self.WEIGHTS[behavior_risk] * min(behavior_count / 10.0, 1.0) ) decision allow if score 0.8: decision block elif score 0.5: decision review return { user_id: user_id, score: round(score, 4), text_risk: round(text_risk, 4), network_centrality: round(network_centrality, 4), behavior_count: behavior_count, decision: decision, } def apply_decision(self, user_id: str, decision: str, operator: str system) - dict: if decision block: # 不直接封号而是降低推荐权重并进入人工复核队列 if self.redis: self.redis.set(frisk:decision:{user_id}, block, ex3600) return {action: limited, user_id: user_id} if decision review: if self.redis: self.redis.rpush(risk:review_queue, f{user_id}:{operator}) return {action: review, user_id: user_id} return {action: allow, user_id: user_id}评分模块的关键在于处置逻辑。很多团队第一次做风控时会直接写“if score 0.8: 封号”这个设计非常危险。AI 模型误差不可避免自动化封禁一旦误伤会引发用户投诉甚至舆情。更稳的做法是把“高风险”映射成“限制推荐 人工复核”等运营确认后再决定是否限制功能。6.4 本地验证脚本文件路径tests/test_risk_engine.pyimport sys from datetime import datetime, timedelta sys.path.append(.) from backend.risk_engine.network_analyzer import UserNetworkAnalyzer from backend.risk_engine.score_service import RiskScoreService def build_demo_analyzer(): analyzer UserNetworkAnalyzer() base_time datetime(2025, 1, 1, 10, 0, 0) # 模拟用户 A 在 20 分钟内主动联系 B/C/D/E 四人 for idx, target in enumerate([B, C, D, E]): analyzer.add_interaction(A, target, base_time timedelta(minutesidx * 5)) return analyzer if __name__ __main__: analyzer build_demo_analyzer() service RiskScoreService(analyzer) result service.compute( user_idA, profile_text自由职业喜欢旅游, recent_chat_texts[在吗, 有空吗, 加微信聊吧], ) print(result) print(service.apply_decision(A, result[decision]))脚本构造了一个典型场景用户 A 在短时间内分别向 B、C、D、E 发起会话且对话文本包含“加微信聊吧”这类联系方式转移意图。运行这个脚本可以观察系统如何输出风险评分和处置建议。7. 运行结果与效果验证在项目根目录执行python tests/test_risk_engine.py预期输出结果如下{user_id: A, score: 0.58, text_risk: 0.0, network_centrality: 1.0, behavior_count: 6, decision: review} {action: review, user_id: A}在这个示例中文本风险分为 0因为本地没有训练文本模型网络中心度为 1.0表示 A 节点在图中连接了所有其他节点行为特征 count 为 6代表在 30 分钟时间窗口内A 主动联系四个用户产生了 6 组有效组合次数。最终评分 0.58超过 0.5 的复核阈值进入人工复核队列。这个结果验证了一个重要设计即使暂时不接入文本模型单靠关系和行为特征也能触发风险预警。实际项目中当文本、网络、行为三个维度都命中时评分会明显超过 0.8触发更严格的限制动作。那么如何判断一个模型好坏这里不建议只看准确率因为正常用户和风险用户的比例通常严重失衡。更合理的评估指标是指标含义目标精确率被判定为高风险的人中真的高风险占比尽量高避免误伤召回率真实高风险人群中被发现的比例保持合理水平误伤率正常用户被判定为高风险的比例越低越好人工复核通过率复核队列中确认高风险占比可以作为模型有效性参考在上线验证阶段建议先做小流量实验。比如只对 5% 的用户开启风险提示对比实验组和对照组在投诉率、举报率、用户流失率上的差异。只有当实验组投诉率明显下降且误伤率可接受时再逐步放开流量。这个过程比模型调参更重要因为它直接决定了业务价值。8. 常见问题与排查方法在实际开发中最容易出问题的不是模型准确率而是数据链路和策略配置。下面列出几个典型问题。问题现象可能原因排查方式解决方案正常用户被误判短时联系次数阈值过低查看用户行为分布和特征贡献提高阈值或加入更多特征综合判断换号用户仍然无法识别只依赖账号维度做分析检查设备指纹和注册 IP 是否接入增加设备指纹、IP 聚类等跨账号特征用户投诉率上升处置策略过激直接限制了活跃监控用户操作漏斗将自动限制改为人工复核后再处置模型效果随时间下降话术和对抗手段不断变化定期抽样评估线上数据建立月度迭代流程补充新标注数据隐私投诉增多采集了非必要字段检查埋点表和数据权限最小化采集只保留业务必需特征人工复核队列堆积阈值设置过低大量误报进入队列查看队列堆积数量和通过率动态调整阈值增加自动降权策略这里单独强调误判问题。相亲平台是一个非常在意用户体验的领域用户可能只是比较积极主动就被系统标记成高风险这会造成很差的反馈。解决办法是引入更多维度的特征。比如真实用户虽然联系人数多但聊天内容丰富、每轮对话长度较高、回复时间合理而海王用户话术模板化严重、内容长度短、回复时间固定。多维特征叠加能显著降低误判概率。另一点容易被忽略的是数据合规。很多团队在开发时图方便把聊天文本和时间戳全部存到一个日志表里这会埋下很大的合规隐患。建议从一开始就区分原始数据、脱敏特征和决策结果三个存储层级。原始数据保留时间尽可能短特征数据需要脱敏决策结果需要保留完整证据链用于申诉处理。9. 最佳实践与工程建议结合前面的实现最后整理几条针对生产环境的工程建议。第一冷启动阶段优先使用规则而不是模型。先实现三个规则短时间内主动联系超过 5 人、文本中包含加微信或见面意图、账号在多个设备上出现。三个规则命中任意两个即可进入人工复核队列。规则的好处是透明、可解释、容易调整积累两周数据后再基于这些标注数据训练模型。第二处置策略必须阶梯化。不要从“正常”直接跳到“封禁”中间需要设计降权、限制推荐、限制搜索、人工复核、消息提醒等多个梯度。建议的默认策略是评分 0.5 到 0.8 进入复核队列大于 0.8 限制部分功能人工复核确认后再进行下一步。所有处置动作必须支持回滚用户申诉后可以快速恢复。第三模型和策略配置要支持热更新。相亲平台的话术变化很快昨天有效的规则今天可能就失效了。建议把特征权重、阈值、处置动作全部配置化不要写死在代码里。每次修改配置都要记录版本号方便回滚和对比效果。第四监控指标要覆盖业务效果而不只是模型指标。除了精确率召回率还需要看风险提示点击率、被提示用户申诉率、投诉工单量下降幅度、次日留存变化。如果模型精确率很高但业务投诉没有下降说明识别的人群可能不是真正影响体验的人群。第五建立用户申诉与人工复核证据链。任何风险判定都应当可解释。人工复核界面需要展示模型风险分、命中的特征规则、关键聊天截图或脱敏文本。用户申诉时运营人员可以根据证据链快速判断是否误判。一个没有申诉通道的风险识别系统会在用户端积累大量不满情绪。第六防对抗需要持续迭代。海王用户也会学习系统规则。他们会避免在一小时内联系多人会修改话术模板甚至会先假装正常互动几天再开始拉人。所以系统不能只靠静态特征还需要加入长时间序列特征、语音特征、人脸一致性检测等多模态能力。对抗博弈是长期过程不是一次上线就能解决的。10. 总结与后续演进方向“AI 相亲屏蔽海王”这个课题表面上是做一个内容审核工具本质上是一套社交行为风险控制系统。它把不可量化的“不靠谱”转化为可计算的“风险分”把事后投诉变成事前干预把人工审核变成人机协同。如果今天就要启动这个项目更稳的路径是先不要优化模型。用规则统计把高连接数、高频联系、模板话术三个特征跑通配合人工复核积累两周标注数据再上模型迭代。这个过程虽然看起来比较笨但能最大程度避免误伤和隐私合规问题。后续值得深入的方向有三个一是引入大模型做更细粒度的意图识别比如区分“正常社交需求”和“引导站外交易”二是加入语音、视频等多模态信息提高信息一致性检测能力三是建立风险团伙识别体系从单个账号识别升级为设备、IP、支付行为等多维度的群体画像。无论技术怎么演进判断标准始终不变系统应该在误伤与漏放之间找到平衡把选择权还给真实用户。