一家医疗器械企业的知识库里有三种数据数千份产品说明书文本、上万张设备故障现场照片图像、以及每月更新的质检报告统计表表格。工程师提问III 型监护仪在高温环境下容易出什么故障系统返回了一堆文本片段但它不知道那张标注了散热风扇异常的现场照片其实已经记录了同一故障的视觉证据也不知道质检表格里连续三个月该型号的高温故障率在攀升。三种数据各自存储、各自检索语义上完全割裂。这不是个例。企业内部超过 70% 的知识以混合模态存在。合同里有文本条款和签字扫描件、研发文档里有设计图纸和技术参数表、客服工单里有用户描述和截图。大模型可以理解单模态内容但当你问的问题需要同时关联文本描述、图像证据和表格数据时单模态检索的天花板就暴露了。多模态知识图谱要解决的正是把三种模态的数据纳入同一个图结构让跨模态关联推理成为可能。而图数据库是这个统一建模框架的天然底座。一、多模态知识为什么拼不起来多模态知识融合不是新概念但过去几年在企业里始终难以落地。核心障碍不在算力不在模型能力而在数据建模层面三类模态的数据结构差异太大传统存储方案无法在同一个框架内同时表达。1.文本数据的特征是离散语义单元。一段产品说明书由句子组成句子由词语组成语义通过词序和语法结构表达。文本适合用向量嵌入表示语义相似性也适合用关键词索引做精确检索。但文本的局限是看不见实体之间的关系结构——两份文档都提到散热风扇向量检索会告诉你它们语义相似但不会告诉你其中一份是 III 型监护仪的说明书、另一份是 IV 型的故障报告更不会告诉你这两份文档指向的设备之间存在供应链替代关系。2.图像数据的特征是连续视觉特征。一张故障现场照片的核心信息——设备型号、故障位置、异常状态需要通过视觉模型提取为结构化标签或区域描述。但图像本身没有关系——两张照片之间的关联同一设备不同时间、同一故障不同型号必须依赖外部系统来建立。当图像存在对象存储中、标签存在标签库中、关联关系不存在任何地方时跨图像的推理根本无从谈起。3.表格数据的特征是结构化属性矩阵。一份质检报告表格记录了型号、批次、检测日期、高温测试结果、合格率等字段。表格天然适合关系型数据库存储和 SQL 查询但表格的局限是行级数据无跨表关联质检表格里的III 型监护仪和产品说明书里的III 型监护仪、故障照片里标注的III 型监护仪是同一个实体但在三个系统中各有各的主键没有统一的实体标识无法自动关联。三者的根本矛盾在于文本靠语义相似性关联图像靠视觉特征关联表格靠主键外键关联——三套关联逻辑互相不兼容。当用户问III 型监护仪在高温环境下的故障表现时理想答案是三模态融合的文本说明书中的高温工作参数 故障照片中的视觉异常 质检表格中的故障率趋势但现有系统只能分别检索、各自返回无法做到跨模态的关联推理。二、图数据库为什么是多模态建模的天然底座图数据库的核心数据结构节点Node和边Edge天然具备统一表达异构数据的能力。多模态知识图谱的建模思路是用节点表达所有实体包括文本片段、图像、表格记录用边表达所有关联包括语义相似、视觉相似、实体共指、因果关系用属性表达模态特征。1.统一节点模型。在多模态知识图谱中节点不区分模态类型而是通过标签Tag和属性来区分。一个III 型监护仪是一个实体节点它的属性包括产品编号、型号名称、高温工作上限来自文本说明书它关联的故障照片是图像节点图像节点的属性包括图片 URL、视觉特征向量、标注标签、拍摄时间它关联的质检记录是表格记录节点表格记录节点的属性包括批次号、检测日期、高温合格率。三种模态的数据被统一为不同类型的节点但共享同一个实体标识III 型监护仪通过边连接为同一个子图。2.多类型边表达跨模态关联。图数据库的边可以携带类型和属性这让它能精确表达不同模态之间的关联关系边类型含义示例refers_to文本片段指向实体说明书段落 → III 型监护仪depicts图像描绘实体故障照片 → 散热风扇部件records表格记录统计实体质检行 → III 型监护仪批次similar_to同模态语义/视觉相似故障照片 A → 故障照片 Bcauses因果关联高温环境 → 散热风扇异常co_occurs共现关系散热风扇异常 → 设备宕机这张表只列了六种边类型实际建模中可以根据业务需要定义任意类型。关键在于图数据库不关心两端节点的模态——一条边可以连接一个文本节点和一个图像节点也可以连接一个表格记录节点和一个实体节点。跨模态关联在图结构中被表达为普通的边遍历与同模态遍历在查询语言层面完全一致。三、多模态图谱的构建流水线从原始数据到统一图结构多模态知识图谱的构建不是一次性导入而是一条持续运行的自动化流水线。四个阶段把异构原始数据转化为统一的图结构阶段一模态解析。三类原始数据分别经过模态专属解析器处理。文本通过 LLM 实体抽取和关系抽取生成实体, 关系, 实体三元组图像通过视觉模型如 CLIP、目标检测模型提取标签、区域描述和视觉特征向量表格通过 schema 映射和实体链接将每行记录转化为结构化属性集并关联到已有实体。每个解析器输出的是待写入的节点和边格式统一但来源模态不同。阶段二实体对齐。这是多模态融合的关键难点。文本中说III 型监护仪图像标注为Model-III Monitor表格里写型号III——三个字符串不同但指向同一个实体。实体对齐模块通过名称归一化、嵌入相似度匹配、上下文消歧三步策略将不同模态的指代统一映射到图中的同一个实体节点。悦数动态 Schema 在这个阶段发挥重要作用——当对齐过程发现新的实体类型或新的关系类型时可以无需停机直接添加不影响已有数据的查询。阶段三入图写入。对齐后的节点和边批量写入图数据库。悦数存算分离架构支持高吞吐写入与并发查询并行——流水线在持续写入新数据的同时下游的问答系统可以实时查询最新图谱状态写入不阻塞查询查询不干扰写入。阶段四质量校验。入图后通过图算法自动检测异常——孤立节点有实体但无任何关联可能是对齐失败、冲突边同一实体对被标注了矛盾的关系类型、密度异常某个实体突然出现大量边可能是抽取错误。校验结果反馈到阶段一的解析器形成闭环迭代。四、跨模态推理大模型在多模态图谱上的四项能力多模态知识图谱建好后大模型的角色是从图上做跨模态推理——回答那些需要同时关联文本、图像和表格才能回答的问题。能力一跨模态实体关联问答。用户问III 型监护仪在高温环境下的故障表现GraphRAG 从图中找到III 型监护仪实体节点沿边遍历找到关联的文本段落说明书中的高温参数、图像节点故障照片、表格记录质检统计将这些多模态上下文组装为增强提示词交给大模型。大模型在提示词中同时看到了文本描述、图像标签和数值统计可以生成三模态融合的回答根据产品说明书III 型监护仪高温工作上限为 45°C3 月 15 日的现场照片显示散热风扇出现异常近三个月质检数据显示高温故障率从 2.1% 上升至 7.8%。能力二视觉证据链追溯。当大模型给出一个结论时多模态图谱可以提供完整的证据链——不只是文档说了什么还包括哪张照片证明了什么哪行表格数据支撑了什么。用户追问你说散热风扇异常有照片吗系统沿图遍历找到 depcits 边指向的图像节点直接返回照片 URL 和标注信息。这种结论→图像证据→表格数据的追溯链在医疗、法律、质检等高合规场景中价值极大。能力三Text2nGQL 跨模态查询。业务人员不需要理解图查询语言通过自然语言直接提问。悦数 Text2nGQL 将找出所有高温故障率超过 5% 且有现场照片的型号这样的自然语言转化为图查询——查询计划中既包含属性过滤故障率 5%在表格记录节点上过滤也包含存在性检查depicts 边存在确保有照片还包含实体聚合按型号分组统计。一次自然语言查询跨三种模态完成检索。能力四多模态知识补全。图谱中存在大量不完整的关联——某个实体有文本描述但没有图像、某条故障记录有照片但没有关联到具体型号。大模型可以通过图结构推理补全这些缺失——如果图像节点的视觉特征向量与已知散热风扇异常照片高度相似且拍摄时间与某条故障记录吻合大模型可以推断这条 depicts 边应该存在并自动建立关联。这种基于图结构的多模态推理补全让图谱越用越完整。五、悦数五项核心能力多模态知识图谱对底层图数据库提出了五项核心要求悦数在每一项上都提供了原生支撑动态 Schema 支撑模态扩展。多模态场景的节点和边类型会随业务演进而持续增长——今天接入产品说明书和故障照片明天可能需要接入视频巡检记录和音频客服录音。悦数动态 Schema 允许在不中断服务的情况下添加新的节点标签和边类型新模态数据即接即用不需要重建索引或迁移数据。多模态属性存储。悦数支持在节点属性中同时存储结构化字段文本标签、数值统计、向量特征图像/文本嵌入向量和时间戳使得精确过滤 相似度检索 时序排序可以在同一个查询计划中完成无需在图数据库和向量数据库之间来回切换。原生 GraphRAG 跨模态召回。悦数 GraphRAG 不是在向量检索之上外挂图查询而是在引擎层面将图遍历与语义检索深度耦合。跨模态问答时一次 GraphRAG 调用可以从文本节点召回语义相似段落、从图像节点召回视觉相似照片、从表格节点召回属性匹配记录组装为统一的多模态上下文交给大模型。Text2nGQL 降低使用门槛。业务人员用自然语言提问Text2nGQL 自动生成跨模态图查询无需理解 nGQL 语法。这让多模态图谱不只服务于技术团队产品经理、质检工程师、客服人员都能直接查询。Studio 可视化调试。多模态图谱的调试比纯文本图谱更复杂——你需要看到节点是什么模态、边是什么类型、跨模态关联是否正确。悦数 Studio 提供图谱可视化界面不同模态的节点用不同颜色标识边类型可过滤展示业务人员可以直观检查跨模态关联的正确性。