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