從一條錯連的 PID 關系拆解 Golden Path、多源交叉驗證、SHACL 與人工確認這一篇只回答一個問題很多圖譜項目已經會做 OCR、VLM、Provenance 和 SHACL但仍然可能把“格式完全合法、語義完全錯誤”的關系寫進主圖。本文只盯一個生產級難題怎樣防止模型把錯誤包裝成權威。一、先看一個故障演練0.95 置信度照樣能把線連錯下面是一個構造的故障演練不對應具體企業事故。掃描版 PID 上一條管線穿過設備圖形并在附近與另一條線交叉。視覺模型識別出 Pump P-101、Heat Exchanger E-101 和 Vessel V-101 都沒問題但在拓撲恢復時把 P-101 的出口線接到了 V-101。模型給出的 topology confidence 是 0.95。更麻煩的是這條邊有合法 subject/object/type有 source_ref、有 bbox甚至 SHACL 也通過了。于是它被寫進 Trusted Graph。下游 Agent 再沿著這條“漂亮的錯誤邊”做影響分析整個推理鏈都可能看起來非常合理。圖 1生產風險往往不是“程序報錯”而是錯誤事實順利通過所有結構檢查。核心判斷模型置信度不是“現實世界真值概率”SHACL 也不是事實核驗器。高風險圖譜必須把“結構正確”和“語義真實”拆成兩道完全不同的門。二、為什么 SHACL 救不了這類錯誤SHACL 很適合檢查Pump 是否有 tag、DISCHARGES_TO 的目標是不是 Line、source_ref 是否存在、current revision 是否唯一。但它無法從規則本身知道“這根線在真實 PID 上到底連到 E-101 還是 V-101”除非這個事實已經由別的可信來源提供。檢查類型SHACL/Schema能不能做真正需要什么字段類型/必填可以Schema約束關系目標類型可以Class/Shapesource_ref存在可以Provenance字段版本是否過期可以有版本事實時有效時間/權威源這條線現實中是否真的連接不能單靠Schema獨立證據或人工確認VLM 0.95 是否真的“95%正確”不能模型校準 業務驗證三、Golden Path單一來源再自信也只能先做 Candidate這條規則我建議寫死對高風險對象關系單一來源無論 confidence 多高都不得自動進入 Trusted Graph。單一視覺模型、單張掃描圖、同一文檔的兩個 OCR 結果都不能被算作“兩個獨立來源”。圖 2發布資格由來源獨立性、沖突狀態和人工確認共同決定不由 confidence 單獨決定。四、“兩個來源”最容易被做假先看 lineage 是否獨立PID PDF 和從這張 PID 導出的設備清單不一定是兩個獨立來源如果設備清單本來就是從同一版 PID 自動生成它們只是同一條數據血緣的兩個副本。真正的 Triangulation 要看 lineage。證據組合獨立性判斷能否構成交叉驗證掃描PID 同圖OCR文本同源否PID R08 從R08自動導出的Line List高度相關通常不能單獨構成PID拓撲 DCS tag/運行拓撲來源機制不同可以作為強交叉證據PID 現場點檢/資產主數據來源責任域不同可以兩名獨立工程師人工復核人工獨立確認適合高后果關系五、關系邊不只要 provenance還要 verification state業務意圖讓下游 Agent 能區分這條邊只是視覺候選、通過了結構檢查、完成了獨立交叉驗證還是由工程師親自確認。{edge_id:edge:20260825:8841,subject:asset://plant01/pump/P-101,predicate:DISCHARGES_TO,object:asset://plant01/line/LINE-2041,verification_state:CROSS_VERIFIED,evidence:[{source:PID-R08,lineage:engineering_doc,method:vectorgeometry2.4},{source:DCS-Topology-202608,lineage:control_system,method:tag_mapping5.2}],conflicts:[],valid_from:2026-08-01,published_by:semantic-pipeline3.1}六、一個可執行的發布判定confidence 只參與候選排序不直接決定發布業務意圖高風險關系的自動發布條件不是“confidence 0.9”而是“結構通過 無權威沖突 人工確認或者至少兩個獨立 lineage 交叉支持”。閾值和獨立性規則應按企業風險等級校準。fromdataclassesimportdataclassfromtypingimportListdataclassclassEvidence:source:strlineage:strconfidence:floatsupports:booldefindependent_lineages(evidence:List[Evidence])-set[str]:return{e.lineageforeinevidenceife.supports}defcan_publish_high_risk_edge(*,shacl_ok:bool,evidence:List[Evidence],authority_conflict:bool,human_verified:bool)-tuple[bool,str]:# 業務意圖 1結構不合法直接拒絕ifnotshacl_ok:returnFalse,STRUCTURE_INVALID# 業務意圖 2出現權威源沖突模型再自信也不能覆蓋ifauthority_conflict:returnFalse,AUTHORITY_CONFLICT# 業務意圖 3高風險邊可以由人工明確確認ifhuman_verified:returnTrue,HUMAN_VERIFIED# 業務意圖 4否則至少需要兩個獨立 lineage 支持iflen(independent_lineages(evidence))2:returnTrue,CROSS_VERIFIEDreturnFalse,CANDIDATE_ONLY七、模型信心值要先“校準”別把 0.95 當成 95% 真值視覺模型、OCR 或 Entity Resolution 輸出的 confidence 往往只是模型內部排序分數。生產項目至少應該按對象類型和關系類型做離線校準例如閥門符號分類、tag OCR、管線拓撲連接分別看 Precision/Recall、Reliability Diagram 或 ECE。即使模型整體很準高風險 edge 也可以有更嚴格的發布策略。指標解決什么問題建議用途Topology Precision發布的連接里有多少是真的核心發布質量Topology Recall真實連接有多少被找到發現漏邊False Publish Rate錯誤邊進入主圖的比例高風險北極星Single-source Publish Rate單源邊是否被錯誤自動發布應接近0高風險域Human Overturn Rate人工推翻自動判斷的比例發現規則/模型漂移Calibration Errorconfidence與真實正確率偏差判斷分數是否可用八、人工反饋不是“改完就完”每次糾錯都要變成訓練資產人工在沖突工作臺里把“V-101”改成“E-101”系統至少應該產生三類資產一條經過審核的 Gold Edge一個 Hard NegativeP-101→V-101 不能連以及對當前 topology extractor / blocking rule 的錯誤標簽。下一版模型或規則上線前必須 Replay 這些樣本。人工動作系統沉淀下一步用途糾正對象映射alias gold table hard negativeEntity Resolution回歸測試糾正拓撲邊gold edge rejected edge拓撲模型/幾何規則訓練與評測確認權威源authority matrix update自動沖突裁決確認版本關系revision gold case時間/版本解析測試拒絕模型候選reason code分析模型自信謊言類型九、責任怎么留痕別讓“算法簽字”成為新的責任黑洞評審建議把算法發布和人工發布對應不同責任這個方向有價值但不宜簡單寫成“算法團隊承擔業務責任”。更穩妥的是把責任拆成兩類記錄技術責任說明這條邊由哪個 pipeline/model/rule 發布、誰維護業務確認責任說明是否經過授權專業人員確認。最終法律與組織責任仍由企業制度、安全管理體系和授權關系定義。狀態技術留痕業務確認適用CANDIDATEextractor/model/version無僅工作臺STRUCTURE_VALIDschema/shacl/version無仍不可作為高風險事實CROSS_VERIFIED多源lineage pipeline owner按企業規則可用于低/中風險自動消費HUMAN_VERIFIED完整技術鏈reviewer/role/time/signature高風險事實十、線上還要防“今天正確三個月后變錯”關系發布時正確不代表永遠正確。PID 升版刪除一條連接如果增量同步只處理 ADD、不處理 DELETE舊邊會變成 Ghost Edge。更危險的是它仍然有 provenance、SHACL 也能通過。因此增量系統要做 relation diff、有效時間關閉、孤兒/幽靈邊檢測和定期 Replay。風險檢測信號處理源文檔刪除關系relation diff missing DELETE關閉 valid_to不物理抹除歷史DCS mapping改變lineage/version drift重新交叉驗證模型升級Human Overturn上升回滾/重跑 Gold Set舊邊長期無任何當前來源Ghost Edge Age上升進入健康檢查隊列兩權威源長期沖突Disagreement SLA超時升級領域Steward十一、60天PoC不要追節點數追“錯誤能不能被擋住”階段工作Go / No-GoW1-2選1類高價值關系 30-50個Gold Case定義獨立lineage與發布規則W3結構解析 SHACL結構錯誤能攔W4Golden Path Triangulation單源高置信邊不會自動發布W5人工工作臺 Gold/Hard Negative回寫反饋能進入回歸集W6relation diff Ghost Edge檢查刪除/失效能被發現W7-8故障注入 ReplayFalse Publish Rate達到業務門檻結語工業圖譜最危險的錯誤是“看起來很合法”低置信度錯誤反而容易處理因為系統知道自己不確定。真正難的是高置信度、結構合法、來源字段齊全卻在真實工程語義上錯了。工業數據系統要對抗的不是“模型偶爾失敗”而是“模型把錯誤包裝得足夠像事實”。解決它靠的不是再換一個更大的模型而是獨立來源、人工責任、版本與時間、持續反饋和故障監測。公開依據與說明W3C SHACL 1.2 Core — https://www.w3.org/TR/shacl12-core/DEXPI Specifications / DEXPI 2.0 — https://dexpi.org/specifications/NIST Digital Thread for Manufacturing — https://www.nist.gov/programs-projects/digital-thread-manufacturingDuckDB CSV Documentation — https://duckdb.org/docs/stable/data/csv/overview.htmlPolars Lazy API / Schema — https://docs.pola.rs/user-guide/lazy/schemas/說明Golden Path、獨立來源判定、發布狀態、指標和PoC周期均為工程設計建議。不同風險等級、對象類型和企業責任體系應采用不同閾值“兩個獨立來源”也不是通用充分條件高后果關系可能始終需要人工確認。