Skip to content

2026 AI 空间智能体 - 实体检索策略方案 ​

定位:本方案聚焦实体检索(空间 / 设备 / 资产三池各自独立检索)的策略设计。Dify 知识库混合检索不属本方案范围(知识库由 Dify 自管理,走 Weaviate + 自带混合检索,其全文/向量权重配置由 Dify 侧维护)。

术语表 ​

术语含义
Exact / Gazetteer实体名录精确匹配。由语义后台维护的"标准名 + 别名 + 物理路径/编码"构成的一张"名字→实体ID"精确查表。对应策略正文的"精确通道"。
BM25(稀疏)词项重合召回,适合"8楼 会议室"这类词级匹配。
Vector(稠密)语义近似召回,适合"东面那间"→"801"这类口语泛化。
CE(Cross-Encoder)神经精排,打相关度分,用于融合后候选的最终排序。
RRF倒数排名融合,按各通道名次融合,非按 scoreThreshold。
X-Resolve-Engine请求头,切换 hybrid / hybrid-qdrant-rrf 两套引擎。

一、Dify 知识库场景 vs 实体对齐场景 对比 ​

维度Dify 知识库实体对齐(空间/设备/资产)
检索对象长文本 chunk,语义开放短标识符(名称/别名/编码),语义封闭
核心诉求召回(别漏,给 LLM 更多上下文)精确(别错,Top1/集合必须准)
目标给 LLM 提供上下文语料给 LLM 提供确定性的执行锚点
错误代价低(可再问 / 可补上下文)高(控错空间/设备是安全事故)
结果形态多段 top_k 交 LLM 综合唯一实体或候选集合,交下游决策
权重关注点全文/向量权重配比(keyword 0.3 / vector 0.7 等)非权重配比,而是通道策略(Exact/BM25/Vector)+ 级联收敛 + 歧义仲裁
技术底座Dify 自管理(Weaviate)自研 Hybrid 引擎(Qdrant 索引 + CE 精排,X-Resolve-Engine 切换)

关键认知:实体检索与知识库诉求相反。知识库怕"漏",实体怕"错"。因此实体检索的策略重心不在全文/向量权重怎么配,而在 精确优先 + 主从级联 + 歧义仲裁 + 调用方按场景定粒度。


二、核心原则 ​

实体是执行锚点,控错是安全事故。原则一句话:能精确绝不模糊,能唯一绝不瞎猜,泛指就返回集合交给下游。


三、三类实体差异化策略 ​

实体精确通道向量通道权重倾向特殊通道空间依赖
空间路径/楼层/房号(8楼、802、305)别名/口语(金朵云小会议室、东面的会议室)精确 > 向量(70:30)能力过滤(meeting 等)—
设备设备名/短标识(主灯、空调)口语兜底精确 > 向量(65:35)能力过滤(requireSemanticKeys)强,先定空间
资产名称(空调、投影仪)泛化语义向量略高(40:60),但需全文兜底防同款多实例全文兜底依赖空间收敛

说明:上表"权重倾向"指通道的启用优先级与命中权重(精确命中优先于向量),而非单一全文/向量权重混合。实体是确定性锚点,精确通道应优先生效。


四、返回粒度由调用方决定 ​

接口不固定 TopN,每次检索调用方自行传 topN / 权重 / 阈值:

  • 点名("802大会议室"、"主灯")→ Exact 高置信短路命中 → 收敛 top1
  • 泛指("8楼会议室"、"801的灯")→ Exact 未收录泛型 → 落 BM25+Vector 融合召回候选集合,交下游决策(如预约推荐、群控聚合)
  • 泛指时集合同样受能力/语义过滤约束,避免捞入无关实体

四之二、实体问法全景(评测用例分类基础) ​

源自早期《空间语义检索优化方案》的总结,作为评测与调参的用例分类骨架,也反证了"纯向量单通道不足、必须 Exact/BM25/Vector 多通道"的结论。

分类典型输入期望结果命中通道
A 精确别名"金朵云小会议室"、"数科大会议室"精确会议室Exact 精确命中
B 定位+泛类型"8楼会议室"、"5楼会议室"该楼层全部会议室BM25/Vector + 路径通道
C 纯定位"8楼"、"5楼"该楼层全部路径通道(BM25 兜底)
D 业务自定义别称"东面的会议室"、"主楼的会议室"特定/一组会议室依赖运营在别名中维护 → Exact
E 虚拟分区"行政区会议室"、"礼堂A区"分区下全部路径通道(树结构透明)
F 纯模糊语义"那个大房间"、"靠窗的那间"语义最近纯 Vector 泛化

关键约束:① 运营无法保证别名必含空间定位信息(如"8楼"),维护成本高;② "东面会议室"这类定制叫法可要求运营维护别名;③ 空间树不一定是标准楼栋-楼层结构,可含虚拟分区(行政区/访客区/礼堂A/B/C);④ LLM 槽位抽取常只提取整体 room_name,不拆"位置"和"名称"。


四之三、A/B 双通道入库设计(Exact 通道的落地建法) ​

源自早期《空间语义检索优化方案》方案二,是"Exact/路径精确通道"的具体实现形态。一个空间实体产出两类入库文本:

通道文本示例检索方式覆盖问法
A 通道(语义别名)数科大会议室、8楼大会议室Exact + 混合(向量+全文)A/D/F 类
B 通道(空间定位)总部大楼 8楼 802全文检索B/C 类

设计要点:

  1. A 通道 = 纯别名:仅含 aliases 数组每条值,不拼接路径(避免"金螳螂西环路|总部大楼"前缀稀释别名信号)。
  2. B 通道 = 短路径:取空间树路径 楼栋|楼层|房号,去掉园区级公共节点;8F→8楼 正则归一化;不包含会议室名/别名。
  3. A/B 共享 payload:space_id、entity_type、cap_tags 一致,通过 channel 字段区分。
  4. 节点别名不展开:路径仅存规范化原始名(如"总部大楼"不展开为"主楼/1号楼"),避免排列组合爆炸;"主楼"可搜到由运营在对应会议室别名中维护。
  5. 虚拟分区透明处理:空间树是什么结构就存什么路径文本,无需特殊逻辑。

该双通道思想对设备/资产同样适用:设备名/别名走 A 通道(Exact 短路),物理编码/路径走 B 通道(精确检索),共用同一 Qdrant collection,channel 区分。


五、向量之外提召回的手段(按价值排序) ​

  1. 主从级联(空间锚定):设备/资产先定空间再查,召回空间从全量缩到空间内,精度速度双升。
  2. Exact / Gazetteer 精确匹配(对应上文"精确通道"):路径/楼层/编码/iot_ref_id 及语义后台维护的标准名+别名,构成一张"名字→实体ID"精确查表。点名时高置信命中直接短路置顶,不进向量/CE。解决"金朵云小会议室"被向量混入"金朵云大会议室"、路径稀释别名分数等纯向量/BM25 无法区分的精确名问题。
  3. 歧义仲裁:候选间分差 < 阈值时主动追问而非瞎猜,是安全敏感实体的正确性底线。
  4. Query 构造治理:resolve 喂纯实体词而非整句,避免"8楼301的空调坏了"这类整句噪声淹没实体词(当前 FA 场景已暴露此痛点)。

五之二、落地检索引擎形态(技术实现口径) ​

与"向量之外提召回手段"配套的技术实现,已由技术同学落地为两套 Hybrid 引擎,共用同一套 Qdrant 索引与 Cross-Encoder(CE)精排,请求头 X-Resolve-Engine 切换。本方案从策略侧给出选型倾向。

1. 两套引擎对比 ​

维度hybrid(三路精排)hybrid-qdrant-rrf(融合召回 + Exact 短路)
召回Exact ∥ BM25 ∥ Vector 并行三路Exact ∥ Qdrant Prefetch+RRF 一次融合 BM25+Vector(少一次往返)
Exact 处理与 BM25/Vector 一起进 CE,模型对全量并集仲裁高置信命中直接短路置顶,不进 CE(catalog/实体定位通用做法)
CE 精排全量并集,文档量不封顶只精排融合后 trunk,有 top-N 预算
失败兜底CE 失败降级 Noop(保留原召回分)CE 失败降级客户端 RRF,可用性更好
优势难语义/多候选质量上限更高,适效果实验/A-B更省、更稳,精确名更稳,接近业内产线形态
代价CE 更重、延迟与成本更高边界难 case 质量上限可能略低于三路全量 CE

2. 本方案的选型倾向 ​

  • 线上产线默认 hybrid-qdrant-rrf:Exact 短路管"点名",RRF+CE 管"泛指",与第四节"点名收敛/泛指返集合"的分工天然契合,且省 CE、稳。
  • hybrid 用于效果实验 / A-B:在难语义、多候选边界 case 上验证质量上限,不直接上产线。

3. 关键技术陷阱(必须遵守) ​

  • RRF 与 CE 阈值不可混用:RRF 按各通道名次融合,不是按 scoreThreshold;scoreThreshold 是 CE 精排之后的门控。两套分数(RRF 名次分 vs CE 相关度分)不能共用同一默认阈值。
  • Exact 不是边角逻辑:它是 gazetteer(名录精确匹配),高置信短路是实体定位的通用做法,负责"点名即命中",不可省。

4. 业内做法小结(选型依据) ​

两个"要不要"(是否先 RRF、是否三路全进 CE)业内无唯一教条,但产线有更常见的默认组合。据此支撑本方案选型。

4.1 是否先 RRF(稀疏+稠密先融合,再精排)

做法业内态度典型场景
先 RRF / 引擎内 hybrid,再 CE产线最常见控延迟与 CE 成本(Qdrant/ES hybrid)
多路并集,不先 RRF,直接 CE也常见通道少、打质量上限、实验
只用 RRF,不上 CE常见于轻量链路无精排预算、极致延迟
加权/学习融合,再 CE进阶有标注、要调通道权重

一句话:先 RRF 不是必须,但线上默认更常选;不 RRF 直接 CE 也完全正规。

4.2 是否三路(Exact+BM25+Vector)都进 CE

做法业内态度典型场景
Exact 高置信短路(bypass),只让模糊集进 CE产线更常见(catalog/实体定位)全名、别名、编码可判定
Exact 也进 CE,统一仲裁有,偏消歧/防脏规则Exact 规则易误伤、要模型纠偏
完全没有 Exact少见纯语义可以;但 NL→实体ID 很少

一句话:Exact 该有;bypass 更贴产线,全进 CE 是合理变体,不是更正统。

4.3 与本方案两引擎的对应

引擎先 RRFExact 处理更像
hybrid-qdrant-rrf✅ Qdrant Prefetch+RRFExact bypass,trunk 进 CE产线默认组合
hybrid❌ 三路并集三路都进 CE效果实验/打上限

4.4 对外可说的结论

  • 选型看指标,不看"谁更像业内":gold hit@1、空结果率、p99、CE 费用。
  • 推荐表述:默认跑 hybrid-qdrant-rrf;hybrid 做对照与难 case,二者不互相否定。

六、评测 ​

复用现有测试方法(SA 会议预定 / SA 设备控制 / FA 一键工单)口径:

  • recall@1:点名场景 Top1 是否命中
  • 命中率 / 过度召回率:泛指场景集合是否过大
  • 独立脚本批量调用,反哺 topK / 阈值 / 权重调参

6.1 阈值门控基线:双层相对阈值(源自早期方案) ​

早期纯向量方案的固定阈值(0.6/0.7)暴露了"一刀切"问题:Case 1 顶分 1.0 时 0.7 引入大量噪声,Case 2 顶分仅 0.757 时 0.7 又滤掉正确结果。据此沉淀"双层相对阈值"作为过滤基线,供精排后门控参考:

top_score = candidates[0].score
effective_threshold = max(top_score * 0.85, 0.60)
filtered = [c for c in candidates if c.score >= effective_threshold]
若 filtered 为空 → 兜底返回 top1

注意:该口径源自"分数直出"的纯向量时代;当前引擎为"RRF 名次分 + CE 相关度分",阈值必须按精排后的分数体系重新校准(见五之二·3,RRF 与 CE 阈值不可混用),此处仅作为相对门控思想(相对 top 分下移、防一刀切)的基线保留。

6.2 早期真实 case 证据(评估基线) ​

Case 1 搜"金朵云小会议室"(期望 502/503,噪声 501/801/802):

rank空间分判定
15031.0✅ 别名命中
25021.0✅ 别名命中
35010.81❌ "大会议室"语义近
48010.75❌ 噪声
58020.64❌ 噪声

Case 2 搜"数科大会议室"(期望 802,噪声 501/801/503/502):

rank空间分判定
18020.76✅ 命中但分低(路径前缀稀释别名信号)
25010.63❌ 噪声
38010.62❌ 噪声

两 case 印证三个结论:① 路径前缀"金螳螂西环路|总部大楼"占用了 embedding 注意力预算,稀释别名信号(Case 2 top 仅 0.76)→ 需 A/B 双通道(四之三);② 纯向量无法区分"大/小会议室"(Case 1 的 0.81)→ 需 Exact 精确命中;③ 固定阈值无法同时满足两例 → 需相对阈值或精排后门控。


七、多跳衔接(说明归属,不展开) ​

空间检索 topN 结果作为 meta 过滤驱动下一跳设备/资产检索的具体多跳逻辑,归属各 subagent 设计文档,本方案不展开。

Released under the Private License.