一個法律文檔處理管道，三個模型來自三個不同團(tuán)隊(duì)，輸入輸出格式完全不兼容——傳統(tǒng)做法需要寫兩套連接器代碼，還要在任一模型更新時同步維護(hù)。SYNAPSE的演示視頻展示了一種不同的方式：沒有連接器文件，沒有共享工具模塊，只有每個模型自帶的適配器函數(shù)。

這個演示運(yùn)行的是一個三跳（three-hop）法律文檔分析流程。第一跳，命名實(shí)體識別模型從合同條款中提取當(dāng)事方、司法管轄區(qū)和日期；第二跳，義務(wù)分類器為每個實(shí)體分配角色——許可方、被許可方、司法管轄區(qū)；第三跳，合規(guī)評分器將義務(wù)與GDPR政策進(jìn)行比對。每個模型由獨(dú)立團(tuán)隊(duì)開發(fā)，各自定義了獨(dú)特的輸入輸出格式。

關(guān)鍵細(xì)節(jié)出現(xiàn)在第二跳。觀察左側(cè)面板：分類器從入口適配器接收的原生輸入中，有一個字段叫entity_type。但第一跳的NER模型輸出的對應(yīng)字段叫label。同一概念，命名沖突。入口適配器用四行代碼完成轉(zhuǎn)換，寫一次即可。它存在于適配器內(nèi)部，而非連接器文件、共享管道工具或只有某人能看懂的橋接模塊里——它是模型自身接口定義的一部分。

當(dāng)義務(wù)分類器團(tuán)隊(duì)更新schema時，只需修改適配器中的這處翻譯。下游的評分器完全無感知，上游的NER模型也完全無感知。中間表示（canonical IR）吸收了所有變化。

適配器的實(shí)際代碼如下：

def ingress(self, ir):
return [{
"text": e["text"],
"entity_type": e["label"], # label → entity_type
"context_window": ir.payload.content[:80],
"threshold": ir.task_header.quality_floor or 0.7,
} for e in (ir.payload.entities or [])]

這是義務(wù)分類器的完整入口函數(shù)。它從規(guī)范中間表示讀取，生成分類器的原生輸入格式。字段名轉(zhuǎn)換只發(fā)生在這里，別處沒有。

管道完成后，演示展示了完整的溯源鏈（provenance chain）——每個模型對應(yīng)一條不可變記錄，按順序追加。每條記錄包含運(yùn)行的模型、報(bào)告的置信度分?jǐn)?shù)、耗時和成本。沒有模型能修改先前的記錄，鏈條是追加式設(shè)計(jì)的。對于運(yùn)行HIPAA或GDPR敏感數(shù)據(jù)的生產(chǎn)管道，這條鏈就是審計(jì)追蹤——由適配器自動維護(hù)，無需應(yīng)用層代碼介入。

演示使用預(yù)計(jì)算輸出，但合同條款可編輯。修改當(dāng)事方名稱或司法管轄區(qū)后重新運(yùn)行，管道邏輯不變，顯示的實(shí)體會隨輸入更新。如需深入，SDK已發(fā)布至PyPI：pip install synapse-adapter-sdk。驗(yàn)證器會檢查適配器定義是否符合規(guī)范。