7.1 多模态与知识图谱融合

7.1 多模态与知识图谱融合

前六章的检索对象默认是文本向量，本节把这个边界推开两次。承接 2.1 埋下伏笔的双塔结构，第一次推界是跨模态：让文字查询命中图片、图片查询命中视频；第二次推界是跨结构：让"按相似飞"的向量检索与"沿关系走"的图谱检索互相补台。旧版教程的"多模态与异构向量""向量图与知识图融合"两节在此合并，因为它们共享同一个主题——当相似性之外还有别的信号，检索系统怎么把两者用好。

跨模态检索：统一空间的两条路线

第一条路线是统一嵌入空间：用图文对齐的双塔模型（其思想源自对比学习的大规模图文预训练）把图片与文本都编码到同一个空间，任何模态的查询都能直接对全库算距离。它的优雅在于"一库通吃"，1.3 的以图搜图变式正是这条路；代价是不同模态的特征分布天然不同，直接混库时相似度分数跨模态不可比——图片与图片的距离分布和文本与图片的距离分布不是一回事，阈值、排序都要按查询模态分别校准。第二条路线是分库跨查：每模态各自建库，查询时先把查询翻译成目标模态的表示（文本先查相似文本、再用其元数据锚定图片），链路长但每段检索的分布纯。规模大、模态多的平台常用第二条，产品轻、追求一体体验的用第一条。

图 7-1 跨模态统一空间示意

落地上还有一个必然遇到的工程题：向量长度与索引的适配。同一集合里混放不同维度的向量（文本模型 768 维、图像模型 512 维）超出多数索引的能力，务实做法有三种：统一用同一套多模态模型输出同维向量（最省心）；分集合存储、查询层归并（保留各模态最优模型）；维度对齐层（把各模态投影到统一维度，引入一次训练成本）。选择依据照旧是数据规模与运维能力，别为了架构美感增加不必要的组件。

与知识图谱融合：会飞的点与会走的边

向量检索与图谱检索是两种互补的运动方式：向量是"飞"——按语义相似直接跳到答案附近，擅长模糊、直觉、跨文档的关联；图谱是"走"——沿着实体与关系边逐跳行进，擅长精确、可解释、多跳的推理。"供应商的召回事件影响了哪些车型的哪些批次"这种问题，纯向量检索只能碰运气，图谱两跳就能答；"找出和这份事故报告描述的场景类似的案例"则反过来，图谱无从下手，向量一发入魂。两者融合的成熟形态有三种：图谱辅助召回——先把查询解析出实体，锁定图谱中的子图范围，再在子图对应的向量集合内做近邻搜索，过滤成本大幅下降；向量辅助扩展——图谱某节点信息不足时，用其属性的向量表示找相似实体补全邻居；联合排序——两路各出一份候选与得分，用 5.2 的倒数排名融合合并。当前最热的检索增强问答变体，本质是"向量找片段加图谱找关系证据"的组合拳：片段给语言，关系给结构。

# 图谱辅助的两段式检索（伪代码）
entities = ner(query)                                  # 抽出查询里的实体
subgraph = graph.expand(entities, hops=2)              # 沿关系扩展出子图
doc_ids  = [n.doc_id for n in subgraph.nodes if n.doc_id]
hits = collection.search(
    vector=embed(query),
    top_k=20,
    filter={"doc_id": {"in": doc_ids}},                # 只在子图关联文档内飞
)
# 效果：检索范围从全库缩到子图关联文档，精度与延迟同时受益
​

一个跨模态查询的完整会话

# 以文搜图的标准链路（伪代码）
q_text  = "黄昏时分的跨海大桥，长曝光"
q_vec   = clip_text_encoder(q_text)                    # 文本塔编码
hits    = image_collection.search(
              vector=normalize(q_vec),                 # 与图片端同口径归一化
              top_k=50,
              filter={"license": {"eq": "commercial"}},# 业务过滤照常叠加
          )
reranked = rerank_with_cross_modal(q_text, hits)       # 跨模态精排收尾
# 精排模型把查询文本与候选图片放在一起打分，修正双塔的粗排误差
​

链路结构与 1.3 的以图搜图同构，两处新增值得划线：归一化必须两端同做（2.3 的铁律在跨模态下加倍重要，因为模态间的分布差异更大）；精排最好用跨模态重排模型，双塔的独立编码天然损失查询与候选间的交互信息，粗排之后补一次联合打分，收益在跨模态场景尤其明显。

问题：多模态库的评估和纯文本检索有什么不同？

多了一层"模态对"的维度。纯文本只需一套探针，多模态要对每个查询与库的模态组合分别备探针——以文搜图、以图搜图、以图搜文各自的召回与延迟都要单独度量，分数分布不同导致阈值与参数也可能各配一套。评估集的构造也更难：跨模态的相关性标注比文本更主观（同一句描述可以对应多张不同角度的图），实践中常用"组内多正样本"的口径缓解。成本上来之后，别试图一次测全，按产品的主要使用模态对优先建设探针。

问题：知识图谱侧的数据从哪来？

三条来源按成本递增：从已有结构化数据直接建（数据库表、组织架构、类目树，现成的关系就是图）；用抽取管道从文本里挖（实体识别加关系抽取，成本与噪声都在管道上）；人工与半自动编辑（高质量但昂贵，通常只用于核心实体）。多数生产系统是三层混用：结构化数据打底、抽取管道铺面、人工精修保头部。检索侧的关键是与向量库保持 ID 对齐——图谱节点与向量的载荷字段用同一套实体标识，两边的数据变更通过同一个变更流分发，这个对齐纪律比图谱本身的建设更常出事故。

问题：图谱融合会让向量检索变慢吗？

设计得当反而更快，设计不当显著变慢，分水岭在"子图收缩发生在哪一层"。理想的路径是查询先经图谱解析与扩展，把候选范围收缩成一个小文档集合，向量检索在收缩后的空间里又快又准——图谱承担了本该由强过滤承担的角色。糟糕的路径是检索完成后才做图谱校验，等于先用全量算距离再丢弃大部分结果，延迟全花在了被丢弃的计算上。评估融合方案时只问一句：图谱介入发生在距离计算之前还是之后？答案几乎决定了方案的成败。

本节要点回顾

• 统一空间一库通吃，分库跨查分布更纯，按规模与产品形态二选一。
• 混模态库要按查询模态分别校准阈值与排序，向量打上模态标记。
• 向量会飞、图谱会走：模糊关联靠飞，多跳推理靠走，联合排序收两路之利。
• 图谱辅助召回把过滤范围缩到子图，精度与延迟同时改善。
• 跨模态链路的两处关键：两端同口径归一化，粗排后补跨模态精排。

能力边界推开之后，下一节转向另一条边界：这些带着语义的向量，在隐私与合规的标尺下该怎么对待。