一个法律文档处理管道，三个模型来自三个不同团队，输入输出格式完全不兼容——传统做法需要写两套连接器代码，还要在任一模型更新时同步维护。SYNAPSE的演示视频展示了一种不同的方式：没有连接器文件，没有共享工具模块，只有每个模型自带的适配器函数。
这个演示运行的是一个三跳（three-hop）法律文档分析流程。第一跳，命名实体识别模型从合同条款中提取当事方、司法管辖区和日期；第二跳，义务分类器为每个实体分配角色——许可方、被许可方、司法管辖区；第三跳，合规评分器将义务与GDPR政策进行比对。每个模型由独立团队开发，各自定义了独特的输入输出格式。
关键细节出现在第二跳。观察左侧面板：分类器从入口适配器接收的原生输入中，有一个字段叫entity_type。但第一跳的NER模型输出的对应字段叫label。同一概念，命名冲突。入口适配器用四行代码完成转换，写一次即可。它存在于适配器内部，而非连接器文件、共享管道工具或只有某人能看懂的桥接模块里——它是模型自身接口定义的一部分。
当义务分类器团队更新schema时，只需修改适配器中的这处翻译。下游的评分器完全无感知，上游的NER模型也完全无感知。中间表示（canonical IR）吸收了所有变化。
适配器的实际代码如下：
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 [])]
这是义务分类器的完整入口函数。它从规范中间表示读取，生成分类器的原生输入格式。字段名转换只发生在这里，别处没有。
管道完成后，演示展示了完整的溯源链（provenance chain）——每个模型对应一条不可变记录，按顺序追加。每条记录包含运行的模型、报告的置信度分数、耗时和成本。没有模型能修改先前的记录，链条是追加式设计的。对于运行HIPAA或GDPR敏感数据的生产管道，这条链就是审计追踪——由适配器自动维护，无需应用层代码介入。
演示使用预计算输出，但合同条款可编辑。修改当事方名称或司法管辖区后重新运行，管道逻辑不变，显示的实体会随输入更新。如需深入，SDK已发布至PyPI：pip install synapse-adapter-sdk。验证器会检查适配器定义是否符合规范。
热门跟贴