58 lines
3.5 KiB
Markdown
58 lines
3.5 KiB
Markdown
# 0003 AI 分工：SQL 硬过滤 + Jev 两两打分 + LLM 只做剧情
|
||
|
||
**Status**: accepted (2026-10-03)
|
||
|
||
## 背景
|
||
|
||
产品可用的 AI 能力有三类，成本和能力画像完全不同：
|
||
|
||
- **Jev**（TypeSafe AI 的 System One 模型）：不生成文本；输入非结构化状态 +
|
||
类型化问题（choice/score/概率），一次前向传播并行回答全部问题，返回带校准
|
||
置信度的结构化答案。中位延迟约 100ms，输出 token 免费，输入极廉价。
|
||
- **前沿 LLM**（System Two）：能生成文本（剧情、追问、画像报告），但慢且贵。
|
||
- **传统手段**：SQL 过滤、embedding 向量相似度，成本近乎为零。
|
||
|
||
产品的 AI 负载有三处：注册/叙事（生成剧情与个性化内容）、人格实测（从行为数据
|
||
产出维度画像）、匹配（海量两两评估）。分工错误会让成本或延迟爆炸。
|
||
|
||
## 决定
|
||
|
||
**三层分工，各就各位：**
|
||
|
||
1. **SQL 硬过滤（免费，先行）**：城市、年龄、性别、性取向等硬约束用数据库
|
||
谓词过滤，砍掉 90%+ 候选对。这些字段在"穿越者身份登记"的开局流程中
|
||
自然采集。绝不用 AI 判断硬约束——那是把最贵的资源花在最不需要智能的地方。
|
||
2. **Jev 两两打分（核心阵地）**：对过滤后的候选池，状态 = 双方资料 + 行为轨迹，
|
||
一次调用并行问"A→B 心动度 / B→A 心动度 / 契合度"（见 ADR-0002）。
|
||
候选池较大时分批调用（如每批 200 个候选，数千人分多批）。
|
||
Jev 同时承担人格实测：对用户行为轨迹按 7 个维度（依恋类型、冲突处理风格、
|
||
价值观与人生优先级、情绪稳定性、风险偏好、文化底蕴、择偶偏好）打分，
|
||
其**置信度用于自适应补测**——证据不足的维度在后续章节动态插入对应支线剧情。
|
||
3. **LLM 只做叙事，且受三通道边界约束**：
|
||
- 通道 1·情绪配色：LLM/Jev 只做预写场景变体的**选择**，不生成主线内容；
|
||
- 通道 2·幻境机制：LLM 可生成内容（用户记忆意象的幻境呈现、NPC 追问），
|
||
这是生成被允许的唯一通道；
|
||
- 通道 3·档案馆：用户讲述内容的沉淀与展示。
|
||
所有个性化内容在**章节之间预生成**，绝不在游玩过程中实时生成；
|
||
生成失败回退到通用版本。
|
||
|
||
## 备选方案
|
||
|
||
- **embedding 粗筛 + Jev 精排**：被产品负责人否决，倾向"尽量全用 Jev"。
|
||
折中结果：硬过滤层（SQL）不可省略，但语义层全部交给 Jev，接受分批调用的
|
||
工程复杂度。
|
||
- **Jev 直接对全量用户两两打分**：被否决。N 个用户每人刷新一次是 O(N²) 调用，
|
||
1 万用户一轮全量打分即上亿次调用，即使单价极低也不可持续；且绝大多数配对
|
||
被硬约束排除，根本不需要判断。
|
||
- **LLM 实时生成剧情**：被否决。延迟、成本、角色一致性和内容安全均不可控。
|
||
主线骨架（转折、选择点、结局树）必须全部预写——这既保质量，也保不同用户
|
||
行为数据的可比性（实测框架的底线）。
|
||
|
||
## 后果
|
||
|
||
- 匹配成本随**过滤后池子大小**增长，而非用户量的平方；
|
||
- 剧本生产流程必须交付"完整故事框架"（整体弧线、选择点地图、维度覆盖表、
|
||
每选择点的预写变体），然后才逐章写作；
|
||
- 人格画像、匹配打分、自适应支线路由都依赖 Jev 的结构化输出与置信度，
|
||
Jev 是不可替换的单点依赖，需在架构上接受这一点。
|