夜班维修工的尴尬我见过太多次了。PLC面板跳出一个“F-301”报警维修工掏出手机拍下铭牌回到办公室在图纸系统里搜“F-301”结果为空。打电话问技术员技术员说F-301对应的是3号冷却塔循环泵可图纸设计号写的是CWP-301去年的维修工单里它又叫“循环水泵”。同一台设备台账、图纸、工单三个系统各叫各的中间全靠老师傅的记忆在接线。这不是某一家的特例而是制造业数据管理的普遍现状。跨模态检索要解决的就是把设备实物点云/照片/铭牌、图纸CAD/扫描PDF/图片、故障记录工单文本/维修报告这三类形态完全不同的数据真正“对齐”起来。用户无论从哪个入口进来——输一段自然语言、拍一张铭牌照片、报一串设备编码——系统都能快速返回同一台设备的全部上下文它是谁、图纸在哪、出过什么问题、之前怎么修的。这篇文章把我在一线项目里摸出来的思路、技术选型和踩坑记录完整写下来适合制造业数字化团队、工业AI产品经理以及正在做设备知识库和智能运维方向的人参考。1. 为什么制造业的检索这么难设备、图纸、故障记录各自为政1.1 三个数据孤岛结构、命名和时间上的深层割裂制造业里的数据表面上都存在服务器里实际上各自住在完全不同的“房间”。设备台账存在ERP或EAM系统里以资产编号为主键字段是安装位置、供应商、启用日期图纸存在PLM/DMS系统里以图号为主键内容是几何尺寸、公差标注、材料、装配关系故障记录存在维修工单系统或点检本里以工单号为主键主要是一段自由文本和几张现场照片。这三个系统的主键之间没有天然外键。资产编号、图号、工单号三者各说各话。更麻烦的是它们连对同一个对象的称呼都统一不了——设备可以是对象ID可以是图号可以是简称可以是“老师在图纸角落手写的那个名字”。更隐蔽的是时间维度上的割裂。设备在2021年做过技改图纸更新到了E版但库存里依然能找到C版的扫描件维修工单记录的是技改前的故障当时换的零件在最新BOM里已经不存在。单纯做语义相似度检索根本发现不了这种版本错位必须把时间有效性引进来。1.2 一个典型的检索失败场景从“主轴异响”到正确答案的漫长链路我接触过不少设备维修场景几乎每次检索失败都出在同一个环节。比如一台泵报了“主轴异响”维修工的脑子里其实有清晰的求助链这条泵是哪台设备——它的主轴图纸是哪个图号——这台泵以前有没有类似异响——上次是怎么处理的。但落到系统里就断掉了输入“主轴异响”到设备台账系统搜不到因为台账里根本不存故障描述到图纸系统里搜“主轴”能搜出一堆带“轴”字的图纸但没法确定哪张属于现场这台泵到工单系统里搜“异响”能搜到不少工单但每条记录对应的是哪台设备、和哪个图纸版本相关完全没有结构化关联。结果就是维修工只能“用脚检索”——走到隔壁办公室问老师傅。老师傅靠记忆把泵型号、图号、历史工单串起来这个过程本质上就是人在做跨模态检索。系统没有做的事情是人脑在兜底。但老师傅会退休记忆不会沉淀成资产。所以制造业跨模态检索的第一个任务不是“多模态语义匹配”这个听起来很AI的目标而是把这条本该在后台完成的关联链用算法显式地建起来。2. 对齐的本质设备实体、图纸空间与故障事件的三个层次2.1 实体级对齐用设备主数据做锚点“对齐”这个词在制造业里比学术论文里的“modality alignment”要复杂得多。学术上说的对齐是让图片和文本在向量空间里距离接近工业上的对齐首先要回答一个更基础的问题这个向量空间的中心到底是哪个物理实体我的做法是以设备主数据为锚点先把所有数据挂到设备ID上。设备ID可以是一个内部生成的全局标识比如EQ_PUMP_301它可以是任意系统的外键。图纸上写CWP-301ERP里叫F-301工单里叫3号循环水泵这些通通作为“别名”挂在主数据下。做这一步需要人工参与但可以用算法分担。我常用的流程是先从设备台账、图纸目录、工单历史里抽取出所有候选编码正则匹配编号模式比如[A-Z0-9]-[0-9]这类模式再以设备台账主键为基准做实体消歧。编码完全匹配的自动合并不能完全匹配的用模糊匹配加人工抽检。这一步通常要花掉整个项目30%左右的时间但它决定了后续所有对齐的质量。2.2 空间结构对齐图纸装配与设备BOM的树状映射设备不是孤立个体。一台离心泵上面有泵体、泵盖、叶轮、主轴、轴承、机械密封装配图上有图号位置标识零件图有各自的图号。图纸和BOM天然是树状结构设备台账则是扁平结构。跨模态对齐如果不处理层级关系检索结果很容易出现“找到一堆图纸但不知道哪张是主轴”。我习惯的做法是先把设备BOM树解析出来设备—部件—零件三级。图纸的标题栏里提取“文件名称”“图号”“所属装配图号”和BOM树的节点做映射。这一步如果能拿到CAD的矢量数据可以直接从图纸属性里抽取如果只有PDF或纸质扫描就要靠OCR加人工校正工作量会大很多。有了树状映射查询“主轴异响”时系统才能把结果定位到“这台泵的泵体总成—主轴—轴承”这个分支而不是把所有带“轴”字的图都捞出来。层级对齐做得越准后续重排序越轻松。2.3 时间事件对齐故障记录与工况数据的时序匹配故障记录本质上是一个事件它发生在某个时间段里和当时的工况数据振动、温度、电流相对应。图纸是静态对象故障记录是动态事件这两者之间差了一条时间轴。我在项目中做了“故障事件序列”的提取每条工单一旦落到设备ID上就标记它的发现时间、停机时间、修复时间、复机时间。同时从SCADA或点检系统里拉取同一时间窗口的振动/温度曲线用规则或简单算法提取“异常片段”。这样故障文本里写的“主轴异响”就有了对应的振动特征和发生时段后续可以支持“查历史异响的振动片段是否相似”这类检索。这个层次的对齐很多人会漏掉。大家一开始只想着做文本和图谱匹配忽略了时间维度。但设备检索的场景里“三个月前”这个时间过滤条件往往比任何语义模型都管用。3. 技术选型跨模态嵌入与工业知识图谱的分工3.1 知识图谱负责“精确对齐”向量模型负责“语义召回”很多团队一上来就急着用CLIP、用多模态大模型想一步到位。但在工业场景里我的经验是反向的先建知识图谱再上向量模型。知识图谱负责精确、可解释的对齐向量模型负责模糊、开放的召回。知识图谱的节点是设备、部件、图号、工单、故障类型、维修动作边是“属于”“包含”“发生过”“维修过”。它解决的问题是“CWP-301就是EQ_PUMP_301EQ_PUMP_301出过3次机械密封故障”。这类问题用图查询秒回准确率百分之百还能给出完整的路径解释。向量模型解决的是另一种问题“‘泵转起来嗡嗡响’这种不标准的自然语言应该召回哪些可能相关的部件和工单”它先把文字映射成向量在嵌入空间里找相近的设备描述、图纸标题、故障文本。它不追求唯一正确答案追求的是把候选取回来。两者分工明确图谱定边界、保精度向量扩召回、保泛化。顺序不能反过来否则就会出现“模型把‘轴承噪音’和‘轴承库存不足’匹配成高相似度”这种让业务方完全无法接受的错误。3.2 在CLIP思路上做工业域微调图文对比学习的落地方式工业场景没有几十亿的图文对但也不需要从零训练。CLIP的对比学习框架完全能搬过来用数据量小就把任务域缩窄。我的一个典型做法是用开源的预训练中文图文模型做底座在自己的设备图片/铭牌照片/图纸截图 对应的设备名称/故障描述对儿上做微调。每台设备尽量收集三种视图设备整体照片、铭牌特写、关键部件如主轴、叶轮照片。文本侧就是设备名称、型号、描述文本、历史工单标题。对比学习的损失函数用的是InfoNCE微调时有几个参数很关键batch size要尽可能大工业数据量小batch size低于32的话负样本不够模型容易塌缩温度系数要调小我一般从0.07往0.03调让同一个实体的正样本对在嵌入空间里更紧凑学习率要比预训练阶段低一个数量级我常用5e-6微调5到10个epoch多了会过拟合到设备照片的拍摄角度上。实测下来微调后的模型对“拍一张铭牌搜图纸”这类任务的效果提升非常明显但如果拿在网上下载的通用预训练模型直接做零样本检索到的结果基本不可用因为通用模型把“离心泵”全部混在一起完全没有区分具体型号的能力。3.3 图纸、故障文本、设备点云的特征编码方案模态不同编码的细节差别很大我把实际项目中稳定可用的方案列出来CAD图纸矢量格式优先直接从解析器中读取文字、图层和图块属性不转图片。矢量数据提取的文字标注不仅是字符串还带坐标和层级这对对齐帮助巨大。DWG用ODA、DXF用ezdxfSolidWorks可以用API导出属性。扫描PDF/纸质图纸先做版面分析用目标检测模型我用的YOLO微调定位标题栏、明细栏、尺寸标注区域再对标题栏单独做OCR。整张图直接OCR的效果很差工程图里小字号、旋转标注、虚线框都会干扰识别标题栏单独切出来之后准确率能提升到95%以上。故障记录文本中长文本我用BERT类模型编码。一个非常重要的小细节是要在tokenizer阶段把设备编号模式如F-301保留为整体token不要被分词器拆散否则下游根本没法精确匹配。设备点云/三维模型数量不多的话用PointNet提取全局特征就可以不需要太复杂的模型。但点云更多用于“形状相似设备”的召回目前工业检索主入口还是以文字和照片为主。4. 检索系统落地离线索引、混合召回与重排序4.1 数据管道从纸质图纸到可检索向量的加工流程检索系统的上游是一整套数据加工管道。顺序是这样的抽数从ERP/PLM/工单系统同步原始数据落到对象存储和PostgreSQL实体归一化用规则加模型把设备编码、图号、工单号解析出来关联到主数据ID解析图纸矢量图纸提取文字属性扫描图纸做版面分析和OCR构建图谱设备、图纸、工单之间的关系写入图数据库生成向量各模态数据分别走编码模型生成embedding写入向量库。这一步看起来只是工程活但每个子任务都有坑。比如图纸解析里很多老图纸扫描分辨率只有150dpi标题栏文字本来就模糊直接ocr会有大量错字。我的经验是统一用300dpi以上重扫标题栏区域先做图像增强再做OCR成本高一点但效果稳定。向量库我用过Milvus和pgvector两种方案。工业数据量再大也就是百万到千万级pgvector在PostgreSQL里就能跑省了一套基础设施中小团队优先考虑如果有频繁的图查询和向量检索混用需求再上Milvus配合图数据库做混合查询会更顺手。4.2 混合召回关键词精确匹配兜底语义向量负责泛化上线初期我犯过一个错误只做向量召回觉得语义检索是万能的。结果发现用户搜“LJ-200减速机”向量召回的前几名里混进很多“扭矩”“齿轮”等语义相近但型号完全不对的东西。后来改成混合召回问题立刻缓解了。混合召回的具体做法关键词召回基于BM25或ES的倒排索引。设备编号、图号、工单号这类编码型查询直接走精确匹配召回结果少而准向量召回文本、照片、图纸各自编码后在向量库做KNN检索召回结果多而泛结果融合我用的是RRFReciprocal Rank Fusion把两种召回结果按排名取倒数分相加。优点是简单稳定不需要调权重适合工业场景这种特征变化频繁的环境。在融合之后还需要一个“实体过滤层”先用NER从查询里识别出设备类型、编码、故障现象然后过滤掉候选集里不满足实体约束的结果。比如查询里识别出“泵”就只保留设备类型为泵的候选。这一层过滤让检索精度上升非常明显后面案例里会具体说。4.3 重排序让检索结果“点名道姓”混合召回给出的结果仍然可能有一堆“看起来相关”的候选。最后一步重排序的目标是把真正对应那台设备、那张图、那条工单的结果顶到最前面。我用两层重排第一层是模型层用CrossEncoder模型对“查询文本 候选标题/图纸OCR文本/工单内容”做相关性打分。和双塔式的向量召回不同CrossEncoder能吃完整的查询和文档对语义理解更准但速度慢所以只用来给Top50内的候选排序。第二层是规则层规则包括设备编号完全匹配的候选直接加高分图号存在多版本时最新生效版本优先多个工单里的故障类型和查询故障类型一致的排在“故障原因不相关”的工单前面同一设备的候选之间装配图排在零件图前面先给概览再看细节。规则层看似土但它承载了业务知识。模型学不会“版本要新的优先”但规则可以一笔写清楚。5. 一个实战案例检索“主轴异响”匹配图纸和历史维修记录5.1 数据情况与建模用一个我参与过的泵类设备知识库项目来说明整体效果。当时的数据规模大概是这样数据类型数量说明设备台账1,237台主要是各类泵含离心泵、螺杆泵、计量泵CAD图纸482张含装配图、零件图主要是DWG格式历史工单约3.7万条2018年至今的设备维修工单故障文本约2.1万条工单中的现象描述和原因分析建模按前面说的思路先花两周做设备主数据对齐把台账、图纸、工单统一挂到1,237台设备ID上然后解析482张CAD图纸的文字属性抽取图号、部件名称、所属装配关系再用微调后的中文跨模态模型对设备系统照片、铭牌照片、图纸截图和故障文本做编码向量维度512维存入pgvector。5.2 检索链路设计用户输入“主轴异响”时检索链路是NER识别出“故障类型异响”“部件主轴”但没有识别出明确的设备类型和编号向量召回用文本编码在向量库召回Top50候选以泵的图纸、维修工单为主关键词召回BM25在工单标题和图纸名称里找含“主轴”“异响”的条目实体过滤由于没有设备类型实体这一步不设过滤但保留“故障类型异响”的硬约束RRF融合 重排序Top10里有不同泵型的主轴图纸、几个损坏轴承的工单、一条“主轴弯曲导致异响”的技术通知。最终检索结果里第一名是一条2022年的工单“循环水泵主轴异响解体检查发现轴弯曲0.03mm换轴后正常”。第二名是某型号离心泵的主轴零件图图号128-53-01第三名是装配图。维修工点了这张图加工单找备件整个过程不到10秒。5.3 效果评估与迭代记录这个系统我们做了两轮评估。第一轮用传统离线指标二十条标准查询的Recall10在0.83MRR在0.61看起来不错。但请维修工程师人工检查后发现部分结果的“正确”是假象——Top10里很多是轴承相关的通用工单并不是真正对应那台泵的。第二轮我们加了实体过滤层效果立刻变好。比如查询“3号循环水泵主轴异响”时NER识别出设备类型“循环水泵”先过滤出设备类型为泵的候选MRR从0.61提升到0.72。人工评估的相关性合格率也从78%上升到89%。还有一个迭代细节最初把“异响”当成一个整词做embedding效果一般。后来我们构建了一个同义词扩展表“异响”扩展出“噪声大”“有杂音”“啸叫”“嗡嗡声”向量召回召回率明显提高。这一步完全靠老师傅的经验录入是模型做不到的。6. 踩坑记录工业现场逼出来的几个认知6.1 设备编号归一化是头号工程省不得很多项目败在这件事上。数据对齐做得再优雅设备编号不统一到生产现场一验证就露馅。你以为系统查出的“主轴图纸”和现场设备是对应的结果老师傅看一眼铭牌说“这不是我们泵的轴我们的轴当年改过尺寸”。我的建议是项目一开始就组织最懂现场的老师傅参与设备主数据整理把每个设备在不同系统里的别名全部录进主数据表。这步不是“数据治理”的例行公事而是跨模态检索的地基。地基打不好后面再贵的模型也是白搭。6.2 图纸版本混乱会制造“错误的正确答案”“准确的错误结果”比“搜不到”更危险。检索系统返回了一张C版图纸图上主轴尺寸还是旧规格但现场设备已经按E版做完技改。维修工拿旧图加工了一个配件结果装不上这就是检索系统带来的直接损失。处理办法是给图号建时间线每张图纸关联“生效日期”“作废日期”“替代图号”。检索展示时保留“该设备当前生效图纸仅此一份”的标注历史故障引用的图纸版本允许检索但不作为首要结果。规则很简单但是必须做。6.3 “语义相似”不等于“实物可查”这是工业检索和通用搜索最大的区别。通用搜索引擎检索“苹果”返回水果、手机、电影都可以接受但维修现场检索“主轴异响”返回“轴承振动大是因为润滑不足”和“轴承损坏需要更换”是两类截然不同的维修动作。模型只看得到字面相似分不清这两种结论的业务含义。后来我在知识图谱里给故障记录加了“维修动作”这个属性重排序时把维修动作的分布展示在结果里。用户一眼能看出“异响”相关的历史记录里60%是更换轴承、25%是调整间隙、15%是补充润滑这个统计信息比单条相似结果更有用。6.4 评估指标别只盯RecallKRecallsK在工业场景里太容易“虚高”了。Top10里返回了9条和“主轴”相关但都不属于目标设备的记录Recall看起来还是很高。我们后来增加了两个更严格的评估点一是“首次命中正确图号的排名”二是“维修工程师人工标定的结果相关性”。这两个指标不完美但它们更接近真实生产力。另外检索效果评估最好在真实故障发生时做而不是拿离线数据集做完就结束。离线数据永远比线上场景干净。真实的夜班故障用户可能连设备编号都说不清只会描述“那个震动特别大的泵”这种情况下的检索效果才是系统价值的真实答案。做跨模态检索这几年我最大的感受是技术路线其实没有太多秘密CLIP也好、知识图谱也好都是工具箱里的常规工具。真正决定项目成败的是对工业现场的理解——设备怎么命名、图纸怎么流转、老师傅怎么记忆、维修工怎么提问。把这些理解沉淀成数据管道和规则再让模型在精调过的数据上学习出来的系统才是车间里真正有人用的系统而不是演示厅里的样板间。