会议室推荐与排序算法逻辑 (v2.0)

1. 算法背景

在“空间运营官 (SA)”的会议预约场景中，系统需要根据用户输入的模糊需求（如：“定个10人的会议室”、“明天下午两点开会”）或明确需求（如：“定一下 A-101”），从海量空间资源中通过两段式筛选（向量召回+忙闲精排）得出最优推荐。

---

2. 评分逻辑体系

推荐总分 $Score$ 由三个核心维度加权而成，根据用户请求是否包含“语义意图（明确地点）”分为两种计算策略。

2.1 基础权重定义

权重项	缩写	定义
向量相似度	$Sim$	(意图置信度) 用户输入的 room_entity 与空间别名在向量库中的语义匹配分值。
基础房间权重	$W_{base}$	(业务权重) 映射后台配置的房间优先级权重（如：VIP室=1.0, 常用室=0.8）。
容量适配度	$Fi{t}_{cap}$	(实用权重) 衡量房间容量与用户人数需求的契合度。

2.2 容量适配度 ($Fi{t}_{cap}$) 计算公式

$$Fi{t}_{cap}=1-\frac{RoomCapacity-UserCapacity}{RoomCapacity}$$

逻辑原则：优先推荐能坐满、且不浪费大空间的房间。

---

3. 排序策略分发

策略 A：明确指定地点 (Has Semantic)

• 适用场景：用户提到具体房间名、编号或别名。
• 计算公式：$$Score=(Sim\times 0.9)+(W_{base}\times 0.1)$$
• 逻辑说明：
  1. 意图优先 (Intent First)：既然用户明确指定了地点，语义相似度 (Sim) 必须占绝对主导。
  2. 置信度保护 (Confidence-Shield)：将相似度权重拉高至 0.9，是为了防止“业务权重”过大（如：某房间被设为 VIP 级别 $W_{base}=1.0$）导致系统在用户指明要去 305 时却推荐了相似度较低但权重较高的 VIP 室。
  3. 二次修正：$W_{base}$ 仅在相似度极度接近（如：305 A室 vs 305 B室）时作为辅助排序手段。

策略 B：无指定地点 (No Semantic)

• 适用场景：用户仅提供容量或时间需求。
• 计算公式：$$Score=(Fi{t}_{cap}\times 0.6)+(W_{base}\times 0.4)$$
• 逻辑说明：优先满足“人与空间的适配度”，避免资源浪费，同时倾向于推荐高权重的优质空间（如：优先推荐装修好、采光好的房间）。

---

4. 冲突推荐 (Conflict Recommendation)

当目标时段全忙时，启动降级推荐引擎。根据用户是否指定了特定会议室，划分为两个 Case：

4.1 Case 1：有指定会议室 (User Specified Room)

• 场景：用户指定了具体房间（如“订一下305”），但该房间冲突。
• 操作：
  1. 空间平替 (Space Shift)：去除会议室限定条件，在同时间段搜索其他会议室。
  2. 硬性约束：备选会议室的 $Capacity$ 必须 $\ge$ 原向量检索 Top 10 中相似度最高（Top 1）会议室的 $Capacity$。
• 降级逻辑：若在此条件下仍找不到可用房间，则自动降级到 Case 2。

4.2 Case 2：未指定会议室 (User Did NOT Specify Room)

• 场景：用户仅提模糊需求（如“订个10人的”），或 Case 1 降级而来，且当前时段全忙。
• MVP 策略：本期不进行自动时间顺延 (Time Shift)，直接向用户返回“无可用会议室”提示。

---

5. 开发实现建议

1. 冷启动：若房间未配置 $W_{base}$，默认统一设定为 0.5。
2. 相似度阈值策略：
   • 阈值设定：向量检索结果中，相似度评分 $\ge 0.6$ 的房间直接保留推荐
   • 低分处理：相似度 $<0.6$ 的房间不进入候选列表，避免低质量推荐
3. 召回精度：向量检索时应利用 Payload 中的 entity_type 和 cap_tags 标签进行 前置过滤 (Pre-filtering)。例如在预约流程中，仅检索具备 meet 能力的空间实体，以规避同名设备的干扰。

---

6. 场景模拟与跑分示例 (Scenarios & Examples)

示例 1：指定房间 (意图保护机制)

• 用户意图：“帮我订一下 305 会议室”
• 候选集数据：
  1. 305 (研发厅)：$Sim=0.99$，$W_{base}=0.2$ (普通会议室)
  2. 306 (总裁办)：$Sim=0.85$ (相似名称)，$W_{base}=1.0$ (VIP 级)
• 计算结果 (策略 A)：
  • 305 得分：$0.99\times 0.9+0.2\times 0.1=0.911$ ✅ (排第一)
  • 306 得分：$0.85\times 0.9+1.0\times 0.1=0.865$
• 结论：即使 306 业务权重极高，通过 $Sim$ 的压倒性占比，系统依然准确推荐用户指定的 305。

示例 2：模糊预约 (容量择优机制)

• 用户意图：“订一个 10 人的会议室”
• 候选集数据：
  1. 火星厅 (12 人)：$RoomCap=12,UserCap=10,W_{base}=0.5$
  2. 太阳厅 (30 人)：$RoomCap=30,UserCap=10,W_{base}=0.8$
• 算法逻辑 ($Fi{t}_{cap}$)：
  1. 火星厅 Fit：$1-(12-10)/12=0.83$
  2. 太阳厅 Fit：$1-(30-10)/30=0.33$
• 计算结果 (策略 B)：
  • 火星厅得分：$0.83\times 0.6+0.5\times 0.4=0.698$ ✅ (排第一)
  • 太阳厅得分：$0.33\times 0.6+0.8\times 0.4=0.518$
• 结论：系统优先推荐容量利用率最高的“火星厅”，避免 10 人会议占用 30 人大空间。

示例 3：冲突平替 (降级推荐机制)

• 场景描述：用户指定 305，但 305 在该时段已被占用。
• 执行路径：
  1. 触发 Case 1：剥离名称限制，在当前时段检索 $Capacity\ge {305}_{Capacity}$ 的空余房间。
  2. 产出列表：找到同规格的 307 及 308。
  3. 最终输出：向用户返回“305 已被占用，为您推荐同规格的 307 或 308”。