41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
# 0002 匹配建模：心动度有向、契合度无向、匹配 = 双向心动过阈值
|
||
|
||
**Status**: accepted (2026-10-03)
|
||
|
||
## 背景
|
||
|
||
产品的核心动作是给用户两两评估"这两个人该不该互相推荐"。评估由 Jev
|
||
（TypeSafe AI 的 System One 模型，见 ADR-0003）完成：输入两个用户的资料与行为数据
|
||
作为"状态"，输出类型化分数。建模时必须回答一个问题：A 对 B 的合适程度和 B 对 A 的
|
||
合适程度是不是同一个分数——这张关系图是有向的还是无向的？
|
||
|
||
## 决定
|
||
|
||
拆成两个概念，分别建模：
|
||
|
||
- **心动度 (Attraction)**：**单向、有向**。A 看到 B 的资料后产生兴趣的程度。
|
||
吸引天然不对称（A 觉得 B 有魅力不代表 B 看得上 A），A→B 与 B→A 是两个独立分数。
|
||
- **契合度 (Compatibility)**：**双向、无向**。两人长期相处的关系质量预期，
|
||
本质上对称（性格互补还是冲突不取决于谁先看到谁）。用途是向用户解释推荐理由
|
||
（"你们都是安全型依恋，冲突风格互补"），不是匹配的门槛。
|
||
|
||
**匹配 (Match) 的成立条件：双向心动度都超过阈值。**
|
||
|
||
实现要点：Jev 一次请求可以携带多个问题并行回答、输出免费，因此一次调用即可
|
||
同时问"A 对 B 的心动度"和"B 对 A 的心动度"（可加契合度），有向建模不增加调用成本。
|
||
|
||
## 备选方案
|
||
|
||
- **单一对称分数**（"这两人配不配，一个数"）：被否决。它会掩盖单向吸引
|
||
（A 痴迷 B、B 无感的组合会得到一个中间分而被错误推荐），而线下交友的真相
|
||
恰恰是吸引不对称；Tinder 的双向右滑机制本质就是求两条有向边同时存在。
|
||
- **只建模心动度**：被否决。缺少长期关系质量信号，无法向用户给出有说服力的
|
||
推荐理由，而"解释力"是本产品对竞品的核心差异之一。
|
||
|
||
## 后果
|
||
|
||
- 数据模型需按**有序对**存储心动度（或存一次调用返回的双向结果）；
|
||
- 用户可见的人格勋章（Badge）只是营销包装，**不是匹配输入**——匹配输入是
|
||
底层行为数据与维度画像，二者必须隔离，防止用户"装修人设"污染匹配信号
|
||
（见 ADR-0004）。
|