# 丹阳公益婚恋服务平台 # V1.0 匹配推荐算法与公益红娘协同机制详细设计 版本：V1.0 适用范围：微信小程序用户端、公益红娘工作台、运营管理后台 设计目标：规则透明、结果可解释、双向匹配、人工可辅助、用户拥有最终决定权 --- # 第一章 设计目标 V1.0匹配系统不追求复杂AI。 核心目标只有五个： 1. 不推荐明显不符合的人 2. 必须同时考虑双方条件 3. 优先推荐更适合进一步了解的人 4. 告诉用户为什么推荐 5. 给公益红娘提供可靠候选，而不是让红娘从全库人工翻找 因此V1.0采用： > **硬条件过滤 + 双向条件验证 + 规则评分 + 推荐排序 + 公益红娘人工辅助** 而不是： - 黑盒AI - 大模型直接判断婚恋匹配 - 深度学习推荐 - 向量数据库 - 颜值模型 - 收入阶层模型 --- # 第二章 匹配系统总体结构 ```text 用户A ↓ 建立候选池 ↓ 基础资格过滤 ↓ A的“必须符合”检查B ↓ B的“必须符合”检查A ↓ 双方硬条件全部通过 ↓ 计算A对B适配度 ↓ 计算B对A适配度 ↓ 计算双方综合分 ↓ 生成推荐理由 ↓ 排序 ↓ 去重/冷却/频控 ↓ 进入每日推荐/找对象/红娘候选 ``` --- # 第三章 匹配系统最重要原则 必须是： > **双向匹配。** 不是： ```text A喜欢什么 ↓ 平台找一个符合A的人 ``` 而是： ```text A符合B吗？ + B符合A吗？ ``` 都通过，才有资格进入推荐候选池。 --- # 第四章 条件分两级 用户择偶条件统一分为： ## 4.1 Required 前端： > 必须符合 含义： > 不符合则直接淘汰。 --- ## 4.2 Preferred 前端： > 最好符合 含义： > 不符合不会直接淘汰，但会降低推荐分。 --- # 第五章 V1支持的核心匹配字段 建议正式纳入算法的字段： ```text 年龄 身高 地区 婚姻状态 子女情况 学历 吸烟 饮酒 定居意愿 婚姻计划 生活方式 兴趣 ``` 其中最核心： ```text 年龄 地区 婚姻状态 子女情况 婚姻计划 定居意愿 ``` --- # 第六章 不进入算法的字段 V1不建议直接用于匹配评分： - 收入 - 房产 - 汽车 - 外貌 - 身份证地区 - 单位级别 - 家庭资产 - 用户照片颜值 - 工作单位知名度 避免让产品走向： > 商业婚恋分层与“条件估价”。 --- # 第七章 候选人基础资格过滤 在计算任何分数前，先过滤。 候选人B必须满足： ```text B != A B.account_status = normal B.profile_review = approved B.relationship_status允许推荐 B.visible_in_recommendations = true B有有效主头像 ``` --- # 第八章 必须排除的关系 A与B存在以下任一情况： 直接排除： ```text A blocked B B blocked A A passed B且仍处于冷却期 A与B已经successful A与B已有active match B账号风险受限 B暂停寻找 B退出婚恋服务 ``` --- # 第九章 已经喜欢的用户 如果： ```text A liked B ``` 但B未回应。 不应继续频繁出现在A每日推荐。 应该进入： > 我喜欢的。 避免重复展示。 --- # 第十章 对方已喜欢A 如果： ```text B liked A ``` A还没有处理。 这类用户可以给予： > 适度排序提升。 但不能直接告诉A： > “因为TA喜欢你，所以排第一。” 除非在： > 喜欢我的 模块明确展示。 --- # 第十一章 性别匹配规则 基于用户当前产品设定与个人择偶条件执行。 如果V1仅支持异性婚恋匹配，必须在产品规则和数据结构中明确。 如果未来支持更广泛的择偶方向，应扩展： ```text preferred_gender ``` V1算法不要通过代码写死隐含规则，而应通过明确配置表达。 --- # 第十二章 年龄Required判断 例如A要求： ```text 28～35 required ``` 如果B年龄： ```text 32 ``` 则通过。 如果： ```text 36 ``` 直接淘汰。 --- # 第十三章 年龄Preferred评分 例如： ```text 28～35 preferred ``` 建议评分： ```text 范围内 100% 超出1岁 80% 超出2岁 60% 超出3岁 40% 超出4岁+ 0% ``` 具体梯度配置化。 --- # 第十四章 身高规则 Required： > 不在范围直接淘汰。 Preferred： 可按偏差计算。 例如： ```text 范围内 满分 差1～3cm 80% 差4～5cm 60% 差6～10cm 30% 更大偏差 0 ``` --- # 第十五章 地区规则 地区是丹阳本地平台非常重要的字段。 建议支持： ```text 丹阳 镇江市区 镇江其他辖区 不限 ``` 未来可扩展省市区代码。 --- # 第十六章 地区匹配等级 示例： ```text 同一主要地区 100 同一镇江市范围 80 江苏其他地区 40 其他地区 20 ``` 但如果用户地区设置为Required： 必须严格执行用户选定范围。 --- # 第十七章 地区与“长期定居”结合 单纯看当前居住地不够。 例如： A在丹阳。 B现在在南京，但： > 明确愿意回丹阳长期定居。 这种情况可以获得一定适配分。 因此地区建议拆： ```text 当前生活区域 + 未来定居意愿 ``` --- # 第十八章 婚姻状态规则 用户可选： ```text 未婚 离异 丧偶 ``` Required： > 候选状态必须在用户允许集合中。 Preferred： > 符合则加分。 婚姻状态本身不做价值排序。 例如： > 未婚不能默认比离异得分高。 只能根据用户自己的选择。 --- # 第十九章 子女情况 不要把： > 有子女 默认设计成扣分。 正确规则： ```text 对方情况 是否符合用户自己的接受条件 ``` 例如： ```text 接受 不接受 视情况 ``` --- # 第二十章 学历 学历作为较低权重条件。 原因： > 学历不能直接代表婚恋适配程度。 因此即便用户设置Preferred： 也不应让学历对最终结果产生过大影响。 --- # 第二十一章 婚姻计划 婚姻计划是重要字段。 例如： ```text 半年内 1年内 1～2年 2年以上 顺其自然 ``` 建议匹配距离模型。 --- # 第二十二章 婚姻计划距离 例如： ```text A：1年内 B：1年内 ``` 100%。 ```text A：1年内 B：1～2年 ``` 80%。 ```text A：半年内 B：2年以上 ``` 20%或更低。 --- # 第二十三章 定居意愿 对丹阳本地产品非常重要。 例如： ```text 长期在丹阳 愿意未来在丹阳 视情况 不考虑 ``` 双方： > 一个必须丹阳，一个明确不愿丹阳。 即使其他条件很好： 也应该低分或直接排除。 --- # 第二十四章 吸烟与饮酒 属于生活方式匹配。 建议低～中权重。 不要做社会价值判断。 只是： > 是否符合对方偏好。 --- # 第二十五章 兴趣匹配 兴趣： > 不是必要条件。 计算： ```text 共同兴趣数 / 双方兴趣并集 ``` 可采用Jaccard Similarity： ```text intersection(A,B) ----------------- union(A,B) ``` 例如： A： ```text 旅行 阅读 运动 电影 ``` B： ```text 旅行 运动 美食 ``` 共同： ```text 旅行 运动 ``` 用于低权重加分。 --- # 第二十六章 兴趣不能权重过高 兴趣相同： > 不代表适合结婚。 所以V1建议兴趣： > 5分左右。 主要用于： - 推荐理由 - 排序细微区分 - 聊天破冰 --- # 第二十七章 生活方式评分 可以由以下字段组成： ```text 吸烟 饮酒 社交倾向 生活规律 户外/居家 家庭倾向 ``` V1如果用户资料量不足： > 先只使用吸烟、饮酒等已确认字段。 不要为了算法强制增加大量资料。 --- # 第二十八章 V1建议权重 推荐默认100分： ```text 年龄 15 地区 15 婚姻状态 10 子女情况 10 学历 5 身高 5 婚姻计划 15 定居意愿 10 生活方式 10 兴趣 5 -------------------- 总计 100 ``` 这是系统默认权重。 后台必须允许版本化配置。 --- # 第二十九章 权重不是用户个人权重 V1建议： 用户只选择： ```text 必须符合 最好符合 ``` 不让普通用户自己调： ```text 年龄权重17 学历权重8 ``` 这会明显增加使用复杂度。 --- # 第三十章 单方向适配分 定义： ```text Score(A→B) ``` 表示： > B有多符合A的择偶期待。 例如： ```text 年龄 15/15 地区 15/15 婚姻状态 10/10 子女 10/10 学历 5/5 身高 4/5 婚姻计划 12/15 定居 10/10 生活方式 8/10 兴趣 3/5 Score(A→B)=92 ``` --- # 第三十一章 双方向评分 还必须算： ```text Score(B→A) ``` 例如： ```text Score(A→B)=92 Score(B→A)=78 ``` 不能只展示92。 --- # 第三十二章 双向综合分公式 不建议简单： ```text (92 + 78) / 2 = 85 ``` 因为平均数可能掩盖单方明显偏低。 建议V1采用： ```text MutualScore = 0.6 × min(A→B, B→A) + 0.4 × average(A→B, B→A) ``` --- # 第三十三章 综合公式示例 例如： ```text A→B = 92 B→A = 78 ``` 则： ```text min = 78 average = 85 MutualScore = 0.6×78 + 0.4×85 = 80.8 ``` 这样可以体现： > 双向适合比单方高分更重要。 --- # 第三十四章 为什么不用最低分直接作为最终分 如果： ```text final = min(A→B,B→A) ``` 虽然强调双向，但损失部分区分度。 因此： > 最低分主导 + 平均分修正 更适合V1。 --- # 第三十五章 Required不参与补偿 重要： > 不符合Required，直接淘汰。 不能： ```text 年龄不符合Required 但兴趣很多 所以总分仍有85 ``` 这是错误的。 --- # 第三十六章 算法完整伪代码 ```text function calculateMatch(A, B): if not isEligible(A, B): return REJECT if !requiredMatch(A.preference, B.profile): return REJECT if !requiredMatch(B.preference, A.profile): return REJECT scoreAB = calculateDirectionalScore(A, B) scoreBA = calculateDirectionalScore(B, A) minScore = min(scoreAB, scoreBA) avgScore = (scoreAB + scoreBA) / 2 mutualScore = minScore * 0.6 + avgScore * 0.4 reasons = generateReasons(A, B) return { scoreAB, scoreBA, mutualScore, reasons } ``` --- # 第三十七章 最低推荐阈值 建议初始： ```text MutualScore >= 60 ``` 才能进入普通推荐候选。 后台可配置。 --- # 第三十八章 推荐等级 建议： ```text 85～100 很合适 70～84 比较合适 60～69 值得了解 <60 默认不推荐 ``` 前台： > 不显示数字。 只显示文字等级和推荐理由。 --- # 第三十九章 为什么不显示百分比 不要显示： ```text 匹配度92% ``` 原因： 这会让用户误以为： > 92%概率适合结婚。 实际上只是规则评分。 因此前台建议： ```text 比较合适 值得了解 ``` 更加诚实。 --- # 第四十章 推荐理由生成原则 推荐理由必须： > 来自真实数据。 不能让AI编。 --- # 第四十一章 推荐理由优先级 优先展示： 1. 双方都满足的重要条件 2. 本地生活 3. 婚姻计划 4. 定居意愿 5. 生活方式 6. 兴趣 --- # 第四十二章 推荐理由示例 ```text 年龄符合双方的择偶要求 你们都长期生活在丹阳 你们对结婚时间的计划比较一致 双方都不吸烟 你们都喜欢运动和旅行 ``` --- # 第四十三章 推荐理由不要出现 避免： ```text 系统认为你们很般配 AI判断你们适合结婚 成功概率86% 条件等级相近 经济实力匹配 ``` --- # 第四十四章 推荐理由最多数量 首页： > 3条。 详情： > 最多4条。 不要展示十几条。 --- # 第四十五章 每日推荐策略 建议默认： ```text 6人/天 ``` 后台配置： ```text 5～10 ``` 不要做： > 无限刷人。 --- # 第四十六章 为什么控制每日数量 公益婚恋平台核心不是： > 增加刷卡时长。 而是： > 让用户认真看有限、相对合适的人。 数量少还有利于： - 候选资源利用 - 本地小用户池 - 降低疲劳 - 减少“逛商品”感觉 --- # 第四十七章 每日推荐生成方式 推荐两种： ## 方式A 用户打开首页时实时计算。 早期用户少： > 完全可行。 ## 方式B 每日提前生成推荐池。 用户量增大后： > 推荐使用。 V1技术可以先： > 候选实时计算 + Redis缓存。 --- # 第四十八章 每日推荐基本排序 候选池按照： ```text 1 MutualScore 2 双方Required完整度 3 新鲜度 4 对方活跃度 5 推荐历史 ``` 综合排序。 --- # 第四十九章 活跃度只能低权重使用 活跃用户可以稍微靠前。 但不能： > 谁每天登录就永远排第一。 否则新用户和不高频用户会被饿死。 --- # 第五十章 活跃状态建议 例如： ```text 7天内活跃 正常 30天未登录 轻降权 90天未登录 明显降权 ``` 如果长期不活跃： > 暂停推荐曝光。 具体周期后台配置。 --- # 第五十一章 新用户冷启动 新用户刚审核通过。 没有行为数据。 直接使用： > Profile + Preferences规则匹配。 不需要行为推荐。 这正是V1规则算法的优势。 --- # 第五十二章 新用户适度曝光 新审核通过用户可以获得： > 轻度新鲜度加权。 例如： ```text 前7天 +少量排序修正 ``` 目的： > 避免新人长期没有曝光。 不能过度加权。 --- # 第五十三章 曝光公平性 如果只按最高分排序： 少数高分用户可能： > 每天被大量推荐。 其他人没人看到。 因此需要： > Exposure Balance。 --- # 第五十四章 曝光控制 建议记录： ```text 最近7天曝光次数 最近30天曝光次数 ``` 当候选人短期曝光明显过多： > 轻微降权。 --- # 第五十五章 曝光平衡不是平均主义 仍然应该： > 匹配度优先。 公平性只是： > 同等匹配程度下的排序修正。 --- # 第五十六章 推荐排序最终分 可以定义内部： ```text RankingScore = MutualScore + FreshnessBoost + ActivityBoost + ReciprocityBoost - ExposurePenalty - RepeatPenalty ``` --- # 第五十七章 修正项范围必须小 例如： ```text FreshnessBoost 0～3 ActivityBoost 0～2 ReciprocityBoost 0～3 ExposurePenalty 0～5 RepeatPenalty 0～10 ``` 核心100分匹配不能被运营修正彻底覆盖。 --- # 第五十八章 ReciprocityBoost 如果B已经喜欢A： 可以： ```text +3 ``` 让双方更容易在推荐中相遇。 这可以提高： > 双向匹配效率。 但不能绕过Required。 --- # 第五十九章 RepeatPenalty 同一候选人已经展示多次： 应该降权。 例如： ```text 已曝光1次 0 2次 -3 3次 -6 ``` 如果用户明确Pass： 直接进入冷却，不再靠Penalty。 --- # 第六十章 推荐冷却机制 建议： ### 仅曝光未操作 7～30天后可以再次出现。 ### 用户Pass 较长冷却。 建议： > 180天可配置。 ### Unmatch 默认长期排除。 ### Block 直到用户主动解除。 --- # 第六十一章 用户池很小时怎么办 丹阳本地早期很可能遇到： > 符合条件的人很少。 系统不能擅自放宽： > Required。 --- # 第六十二章 无候选时处理顺序 ```text 第一步： 确认是否真的没有满足Required的人 第二步： 扩大Preferred条件容忍范围 第三步： 向用户提示可调整择偶条件 第四步： 提供公益红娘入口 ``` --- # 第六十三章 不允许后台偷偷改Required 运营管理员不能： > 为了让推荐更多，自动放宽用户的必须条件。 这是用户明确偏好。 只有用户本人： > 修改。 --- # 第六十四章 Preferred自动放宽 Preferred允许系统做适度容忍。 例如： 年龄最好： ```text 30～35 ``` 可逐步考虑： ```text 29或36 ``` 但得分下降。 --- # 第六十五章 放宽顺序 建议按影响从低到高： ```text 兴趣 ↓ 生活方式 ↓ 身高 ↓ 学历 ↓ 年龄Preferred ↓ 地区Preferred ``` 婚姻状态、子女等是否放宽： > 必须严格按照用户设置和业务含义处理。 --- # 第六十六章 “找对象”与“每日推荐”算法区别 每日推荐： > 系统主动精选。 找对象： > 用户主动筛选。 两者底层候选资格规则相同。 --- # 第六十七章 找对象排序 默认： ```text 综合推荐 ``` 可后续提供： ```text 最近活跃 年龄 ``` V1不建议增加太多排序。 --- # 第六十八章 临时筛选不修改择偶条件 例如用户临时筛： > 30～32岁。 只影响当前Find结果。 不能覆盖： > 我的择偶条件。 --- # 第六十九章 红娘候选算法 公益红娘工作台调用： > 同一个Match Engine。 但可以看到更多解释信息。 --- # 第七十章 红娘候选列表结构 建议： ```text 王女士 32岁 双向综合：高 A→B：较高 B→A：较高 Required： 全部符合 主要推荐理由： ✓ 年龄 ✓ 丹阳 ✓ 婚姻计划 ``` 红娘不需要看到复杂数学公式。 --- # 第七十一章 红娘比普通用户多看到什么 可以多看到： - 哪些Required通过 - 哪些Preferred不符合 - 双方婚恋计划差异 - 用户最近推荐情况 - 是否长期没有Match 目的是： > 帮助人工判断。 --- # 第七十二章 红娘不能看到什么 不能因为匹配工作看到： - 身份证 - 完整聊天 - 举报证据 - 无关风险内部材料 - 精确家庭住址 --- # 第七十三章 红娘人工推荐机制 流程： ```text 用户A申请红娘帮助 ↓ Match Engine生成候选 ↓ 红娘查看候选 ↓ 人工判断 ↓ 选择B ↓ 填写推荐理由 ↓ 发送给A ↓ A自己决定喜欢/不合适 ``` --- # 第七十四章 红娘人工判断可以补充什么 算法难以完全处理： - 用户真实表达偏好 - 近期家庭计划 - 对沟通风格的期待 - 用户主动向红娘说明的特殊情况 红娘可以在用户授权范围内： > 人工辅助判断。 --- # 第七十五章 红娘不能覆盖Required 再次强调： ```text 算法Required失败 ↓ 红娘不可直接推荐 ``` 如果红娘认为用户设置过严： 应： > 建议用户修改。 用户确认修改后： > 重新计算。 --- # 第七十六章 红娘建议修改择偶条件 红娘可以说： > “目前符合你全部必须条件的用户较少，是否考虑把学历从必须符合改成最好符合？” 用户可以： ```text 接受 拒绝 ``` 只有用户接受： > 系统更新条件。 --- # 第七十七章 红娘不得代修改 后台不能提供： > 直接替用户改择偶条件 普通按钮。 若特殊线下协助确需操作： 必须： - 明确用户授权 - 留操作日志 - 告知用户变更结果 V1建议仍由用户本人改。 --- # 第七十八章 红娘联系意向对象流程 例如A： > 希望红娘帮我联系B。 系统： ```text A明确申请 ↓ 红娘确认B仍可联系 ↓ 向B发系统通知 ↓ “有一位用户希望进一步了解你” ↓ B自主查看/决定 ``` --- # 第七十九章 不直接给手机号 红娘不能： ```text A想了解B ↓ 直接把B手机号发给A ``` 正确： > 平台内发起意向。 --- # 第八十章 红娘推荐来源标记 推荐记录： ```text source = matchmaker ``` 与： ```text daily discover activity ``` 区分。 方便后续统计： > 哪种方式转化更好。 --- # 第八十一章 红娘效果评价 不要只看： > 红娘推荐了多少人。 建议看： ```text 服务人数 推荐人数 查看率 喜欢率 双向匹配率 正在了解率 成功牵手率 ``` --- # 第八十二章 不做红娘排行榜 V1不建议： ```text 金牌红娘Top10 牵手王 红娘PK榜 ``` 公益服务不需要游戏化竞争。 --- # 第八十三章 红娘工作量控制 后台建议： ```text 每位红娘服务中用户数 待跟进数 超时数 ``` 管理员据此分配。 --- # 第八十四章 长时间无匹配用户识别 系统可以识别： ```text 审核通过30天 + 有活跃 + 无双向匹配 ``` 标记： > 可关注。 --- # 第八十五章 长期无结果原因分析 系统可给红娘提示： ```text 候选池过小 Required过多 地区范围很窄 用户很少主动Like 资料完整度一般 ``` 不能写： > “用户条件太差”。 --- # 第八十六章 用户资料完整度与推荐 资料未完整： > 本就不能审核通过。 审核后仍有选填项缺失： 不应该直接重罚。 但信息越完整： > 推荐理由可能更充分。 --- # 第八十七章 照片数量与排序 不能因为： > 上传6张照片 就比： > 只上传2张照片 获得明显匹配加分。 否则会诱导用户过度上传。 照片主要影响： > 用户自己判断。 不是算法核心分。 --- # 第八十八章 被喜欢数量不能作为质量分 禁止： ```text 被喜欢越多 → 排名越高 ``` 否则会形成： > 马太效应。 --- # 第八十九章 热门用户控制 如果一个用户短时间收到大量Like： 系统可以： > 降低曝光频率。 避免其积累大量无法处理的意向。 --- # 第九十章 双向匹配效率指标 核心指标： ```text Mutual Match Rate = 双向匹配数 / 有效Like数 ``` 但不能只优化这个指标。 --- # 第九十一章 更重要的最终指标 长期真正关注： ```text 聊天建立率 持续沟通率 正在了解率 线下见面率 成功牵手率 ``` V1先把数据记录好。 --- # 第九十二章 推荐算法不能只追求点击 如果只优化： > 用户点击喜欢。 可能会把系统变成： > 外貌刷人产品。 所以V1不做点击率机器学习。 --- # 第九十三章 用户反馈闭环 推荐后行为： ```text 查看 喜欢 Pass Match Unmatch 成功 ``` 都记录。 未来可以优化规则。 但V1不做自动机器学习。 --- # 第九十四章 Pass原因V1策略 前面已确定： > 点击不合适不强制询问原因。 因此算法不能依赖： > Pass原因。 减少用户操作负担。 --- # 第九十五章 Unmatch原因可用 解除匹配时已有原因选项。 可以作为： > 运营分析数据。 但V1不直接自动训练模型。 --- # 第九十六章 推荐规则版本 每条RecommendationRecord应记录： ```text rule_version ``` 例如： ```text v1 v2 ``` 以后修改权重： 可以比较效果。 --- # 第九十七章 权重修改流程 后台管理员： ```text 创建新版本 ↓ 检查权重总和 ↓ 保存草稿 ↓ 人工确认 ↓ 激活 ``` 不直接覆盖旧版本。 --- # 第九十八章 权重调整必须审计 记录： ```text 谁改 什么时候 旧值 新值 原因 ``` 避免运营人员随意调算法。 --- # 第九十九章 是否需要A/B测试 V1： > 不需要复杂A/B平台。 如果以后需要： 可以按小比例用户测试新规则。 V1先： > 一个正式规则版本。 --- # 第一百章 算法解释接口 后端建议： ```text MatchResult { scoreAB scoreBA mutualScore level reasons requiredChecks preferredChecks } ``` 普通用户DTO： 只返回： ```text level reasons ``` 红娘DTO： 可增加： ```text requiredChecks preferredChecks ``` --- # 第一百零一章 推荐服务内部模块建议 ```text MatchEligibilityService RequiredConditionService DirectionalScoringService MutualScoringService RecommendationReasonService RankingService ExposureControlService RecommendationHistoryService ``` 不一定拆成独立微服务。 都可在Match模块内。 --- # 第一百零二章 MatchEligibilityService 负责： - 账号状态 - 审核状态 - 婚恋状态 - 隐私 - Block - 已有关系 - 冷却期 --- # 第一百零三章 RequiredConditionService 负责： ```text A Required → B B Required → A ``` 必须纯规则、可测试。 --- # 第一百零四章 DirectionalScoringService 负责： ```text Score(A→B) ``` 输入： ```text A preference B profile active rule config ``` 输出： ```text dimension scores total ``` --- # 第一百零五章 MutualScoringService 负责公式： ```text 0.6 × min + 0.4 × avg ``` 后续公式如果变化： > 不影响前端。 --- # 第一百零六章 ReasonService 只从： > 已经通过的真实匹配字段 生成说明。 不能独立“创造”理由。 --- # 第一百零七章 RankingService 处理： ```text MutualScore + Freshness + Activity + Reciprocity - Exposure - Repeat ``` 最终输出顺序。 --- # 第一百零八章 ExposureControlService 维护： ```text 最近曝光量 单日曝光上限 重复推荐 ``` 避免热门用户被过度曝光。 --- # 第一百零九章 SQL候选池初筛 数据库先做： ```text 审核通过 账号normal 目标性别 年龄粗范围 地区粗范围 未暂停 隐私允许 ``` 例如先得到： > 100～500个候选。 再在应用层计算。 --- # 第一百一十章 不建议数据库写超复杂评分SQL 不要把所有： ```text CASE WHEN... CASE WHEN... ``` 都塞SQL。 V1： > SQL过滤 + 应用层评分 更容易维护和测试。 --- # 第一百一十一章 Redis推荐缓存 可缓存： ```text recommendation:{userId}:{date} ``` 内容： > 排序后的候选ID。 详情数据： > 实时/短缓存读取。 --- # 第一百一十二章 推荐缓存失效事件 以下事件发生： 立即使相关缓存失效： ```text 修改择偶条件 资料审核变化 暂停寻找 成功牵手 Block Unmatch 风险封禁 隐私修改 ``` --- # 第一百一十三章 推荐时二次校验 即使缓存中有B： 真正返回卡片前： > 再做轻量Eligibility检查。 避免： > B刚暂停，A仍然看到。 --- # 第一百一十四章 算法性能目标 丹阳本地早期： 单用户候选池并不会非常大。 目标： ```text 候选过滤 < 300ms 评分排序 < 300ms 推荐接口整体 P95 < 1.5s ``` 完全不需要重型推荐基础设施。 --- # 第一百一十五章 单元测试要求 每个维度至少测试： - 完全符合 - 边界值 - Required失败 - Preferred部分符合 - Null/未填写 - 异常值 --- # 第一百一十六章 双向条件测试 必须测试： ```text A接受B B不接受A ``` 结果： > REJECT。 不是： > 仍推荐给A。 --- # 第一百一十七章 地区边界测试 例如： A： ```text 丹阳 required ``` B： ```text 南京 未来愿意丹阳 ``` 如果A要求的是： > 当前居住地丹阳 则失败。 如果A要求的是： > 未来定居丹阳 则按对应字段判断。 字段含义必须清楚。 --- # 第一百一十八章 Null字段处理 对于非必填选项： 候选人没有填写。 不能默认： > 符合。 建议： ```text Required + 对方未知 → 不通过/不可判断 Preferred + 对方未知 → 该维度0分或中性低分 ``` 具体按字段定义。 --- # 第一百一十九章 为什么Required未知不能自动通过 例如： A： > 不接受吸烟者，Required。 B： > 没填吸烟状态。 系统不能假设： > B不吸烟。 否则违反用户硬条件。 --- # 第一百二十章 信息不完整提示 如果由于关键Required字段未知导致候选池很少： 可以提示用户： > 完善生活资料有助于更准确匹配。 而不是系统猜测。 --- # 第一百二十一章 推荐结果审计 对于每次推荐，可以保存： ```text user_id target_id rule_version mutual_score reasons shown_at source ``` 后续有投诉： 可以知道： > 当时为什么推荐。 --- # 第一百二十二章 算法不应保存敏感推断 不要保存： ```text 用户大概率高收入 用户看起来性格强势 用户可能离婚风险高 ``` 这些都不属于V1。 --- # 第一百二十三章 红娘操作审计 红娘人工推荐必须记录： ```text operator user target reason time service_id ``` --- # 第一百二十四章 红娘推荐理由规范 建议： > 基于资料事实。 例如： ```text 年龄、地区和婚姻计划均较符合， 双方都希望长期在丹阳生活， 建议进一步了解。 ``` 不要写： ```text 我觉得你们一定很合适。 ``` --- # 第一百二十五章 系统与红娘边界 系统负责： ```text 筛 算 排 解释 ``` 红娘负责： ```text 看 判断 沟通 辅助 跟进 ``` 用户负责： ```text 最终决定 ``` --- # 第一百二十六章 理想协同流程 ```text 系统发现候选 ↓ 普通推荐有效？ ├─ 是 → 直接推荐用户 └─ 用户长期无结果 ↓ 红娘介入 ↓ 系统提供候选解释 ↓ 红娘人工筛选 ↓ 用户自主决定 ``` --- # 第一百二十七章 红娘不是“人工绕过算法” 红娘存在的价值不是： > 算法不行，所以全人工。 而是： > 算法做大规模初筛，人工处理复杂情况。 这是V1最适合公益组织的协同方式。 --- # 第一百二十八章 系统自动触发红娘建议 V1可以轻量提示： 如果用户： ```text 30天无Mutual Match ``` 且活跃： 首页提示： > 可以让公益红娘帮你进一步看看。 但： > 不自动创建红娘服务。 用户自己申请。 --- # 第一百二十九章 红娘主动介入边界 V1建议： > 默认用户申请后介入。 如果公益机构要主动服务： 必须有： > 用户事先同意接受公益红娘推荐/协助。 没有同意： > 不主动电话联系婚恋事项。 --- # 第一百三十章 自动推荐频率 每日一次主推荐即可。 不建议： ```text 上午推6个 中午推6个 晚上再推6个 ``` 避免打扰。 --- # 第一百三十一章 推荐通知 可以有： > 今天有新的合适推荐。 但不是： > 每个候选人一个通知。 降低骚扰感。 --- # 第一百三十二章 系统无法推荐时文案 正确： > 暂时没有完全符合你条件的人。 可以： > 调整“最好符合”的条件，或申请公益红娘帮助。 不要： > 你的条件太高。 --- # 第一百三十三章 用户条件过窄提示 系统可计算： ```text Required过滤前候选100 ↓ Required过滤后0 ``` 可以判断： > 条件较严格。 文案： > 当前符合所有“必须符合”条件的人较少。 --- # 第一百三十四章 条件优化助手V1 不需要AI。 可以规则提示： ```text 你的6项条件中有5项设为必须符合， 当前候选范围较小。 ``` 按钮： > 查看择偶条件。 --- # 第一百三十五章 不自动推荐“降低标准” 不要使用： > 降低要求 文案。 建议： > 调整条件 > 扩大了解范围 更加尊重用户。 --- # 第一百三十六章 未来AI升级接口预留 未来可增加： ```text AICompatibilityService ``` 但它只能： > 作为额外排序信号。 不能替代： - Required - 用户隐私 - Block - 账号状态 --- # 第一百三十七章 AI未来的正确位置 未来： ```text 硬条件过滤 ↓ 规则匹配 ↓ AI辅助理解文本/兴趣 ↓ 排序微调 ``` 而不是： ```text 把两个用户资料扔给大模型 ↓ 问“适不适合结婚？” ``` --- # 第一百三十八章 不允许AI自动作婚姻判断 未来也不能对用户输出： > “AI判断你们婚后幸福率89%。” 这种结果既不可验证，也容易误导。 --- # 第一百三十九章 算法核心监控指标 运营后台建议： ```text 候选池平均人数 无候选用户比例 每日推荐完成率 详情查看率 Like率 Mutual Match率 Chat启动率 Unmatch率 红娘介入率 ``` --- # 第一百四十章 性别供需统计 本地平台需要关注： ```text 男女用户数量 各年龄段比例 各地区比例 ``` 但只是： > 运营参考。 不能用于对用户差别收费，因为本项目永久免费。 --- # 第一百四十一章 候选池健康度 后台可以显示： 例如： ```text 30～35岁男性 有效候选 83 30～35岁女性 有效候选 61 ``` 帮助公益组织： > 设计线下活动和招募宣传。 --- # 第一百四十二章 红娘运营数据 建议： ```text 平均接单时间 平均首次跟进时间 平均服务时长 平均推荐人数 推荐后Like率 Match率 ``` 不建议只统计： > 电话打了多少个。 --- # 第一百四十三章 算法配置权限 只有： ```text 超级管理员 或 指定算法配置管理员 ``` 可修改。 普通红娘： > 只读。 --- # 第一百四十四章 推荐规则回滚 新规则出现异常： 后台支持： > 激活旧版本。 不要现场改数据库权重。 --- # 第一百四十五章 推荐规则发布前检查 系统自动检查： ```text 权重总和=100 最低分0～100 所有必要字段存在 规则版本唯一 ``` --- # 第一百四十六章 推荐算法V1完整数据流 ```text 用户进入首页 ↓ RecommendationService ↓ 检查缓存 ├─ 有 │ ↓ │ Eligibility二次校验 │ └─ 无 ↓ 数据库初筛候选 ↓ Required双向过滤 ↓ Score A→B ↓ Score B→A ↓ MutualScore ↓ RecommendationReasons ↓ Ranking修正 ↓ Exposure控制 ↓ 写RecommendationRecord ↓ Redis缓存 ↓ 返回6位 ``` --- # 第一百四十七章 红娘协同完整数据流 ```text 用户申请红娘 ↓ 建立MatchmakerService ↓ 分配红娘 ↓ 系统调用Match Engine ↓ 生成候选列表 ↓ 红娘查看： Required Preferred 推荐理由 历史服务 ↓ 人工筛选 ↓ 推荐给用户 ↓ 用户自主查看 ↓ Like / Pass ↓ 正常Relationship流程 ``` --- # 第一百四十八章 核心验收场景一 A条件： ```text 年龄30～35 Required 丹阳 Required 本科以上 Preferred ``` B： ```text 32 丹阳 大专 ``` A→B： > Required通过。 学历Preferred不满足： > 扣相应分。 仍可推荐。 --- # 第一百四十九章 核心验收场景二 A要求B符合。 但B要求： ```text 年龄40～45 Required ``` A只有36。 即使A非常喜欢B： > 系统不应推荐。 因为： > B的Required不接受A。 --- # 第一百五十章 核心验收场景三 系统评分： ```text A→B 95 B→A 62 ``` 不能显示： > 95分超高匹配。 最终双向分应明显受到： > 62 影响。 --- # 第一百五十一章 核心验收场景四 A Pass B。 B第二天高分候选。 仍： > 不应该重新推荐给A。 必须遵守冷却。 --- # 第一百五十二章 核心验收场景五 A Block B。 红娘搜索B准备推荐给A。 系统必须： > 排除。 不能靠红娘记忆。 --- # 第一百五十三章 核心验收场景六 用户有5项Required导致候选0。 系统： > 不偷偷放宽。 而是： ```text 暂时没有完全符合条件的人 + 修改择偶条件 + 公益红娘 ``` --- # 第一百五十四章 核心验收场景七 红娘推荐B给A。 A查看后Pass。 系统记录： ```text source = matchmaker action = passed ``` 后续不要不断由其他红娘重复推荐B。 --- # 第一百五十五章 V1明确不建设 不建设： - 深度学习推荐 - 协同过滤 - AI婚恋预测 - LLM自动决定对象 - 人脸颜值评分 - 财富评分 - “高价值用户”标签 - 用户等级 - 热门榜 - 付费曝光 - 超级喜欢 - Boost - AI聊天代聊 --- # 第一百五十六章 匹配系统开发优先级 ## P0 ```text Eligibility Required双向过滤 DirectionalScore MutualScore RecommendationReason 每日推荐 Like/Pass排除 ``` --- ## P1 ```text 曝光控制 新用户修正 活跃度修正 对方已喜欢轻度Boost 红娘候选 ``` --- ## P2 ```text 长期无结果分析 候选池健康度 规则效果对比 更完善的运营统计 ``` --- # 第一百五十七章 推荐系统代码验收标准 任何算法版本必须： - 相同输入得到稳定结果 - Required绝不被软分覆盖 - 双向评分 - 规则可配置 - 规则版本化 - 推荐理由可解释 - 不访问不需要的敏感数据 - Block即时生效 - 用户状态即时生效 - 有单元测试 --- # 第一百五十八章 公益红娘协同验收标准 必须做到： > 红娘不需要从全部用户中盲目搜索。 > 系统先提供合格候选。 > 红娘可以理解为什么推荐。 > 红娘不能突破用户硬条件。 > 红娘不能替用户喜欢。 > 红娘不能私自提供联系方式。 > 红娘每次推荐都有记录。 --- # 第一百五十九章 V1核心算法公式最终确定 候选资格： ```text Eligible AND Required(A→B) AND Required(B→A) ``` 方向评分： ```text Score(A→B) = Σ DimensionScore × Weight ``` 双向综合： ```text MutualScore = 0.6 × min(ScoreAB, ScoreBA) + 0.4 × average(ScoreAB, ScoreBA) ``` 排序： ```text RankingScore = MutualScore + SmallPositiveAdjustments - ExposureAndRepeatPenalty ``` --- # 第一百六十章 最终设计原则 V1.0匹配系统必须坚持： > **先排除不合适，再判断谁更合适。** > **双方条件同等重要。** > **用户“必须符合”的条件系统不得偷偷修改。** > **评分是排序工具，不是假装预测婚姻幸福。** > **推荐必须能解释。** > **兴趣只能辅助，不能替代核心婚恋条件。** > **不能根据财富、外貌、人气给用户隐性分级。** > **算法负责大规模初筛，红娘负责复杂人工辅助。** > **红娘不能突破系统安全和用户自主权。** > **最终喜欢谁、是否聊天、是否进一步交往，始终由用户本人决定。** 整个V1.0匹配机制最终可以概括为： > **规则筛得准，双方都合适，红娘帮得上，用户自己选。**