多模型融合 - Entity Enricher 文档

多模型融合

当你在多个 AI 模型上运行同一次富集时,Entity Enricher 可以将结果融合为单一的高置信度输出。融合会检测各模型输出之间的冲突,并使用确定性规则或由 LLM 驱动的仲裁来解决它们。

融合流程

模型输出
Claude 结果
GPT-4 结果
Gemini 结果
冲突检测
在所有模型间
比较每个字段
解析
基于规则的合并
LLM 仲裁
合并结果
单一输出,附带
冲突审计跟踪

第 1 步:冲突检测

冲突检测器会比较所有模型输出中的每个字段。所有模型一致的字段将原样通过。模型存在分歧的字段会被标记为需要解决的冲突。

按字段类型的比较规则
类型比较方式一致意味着
标量标准化精确匹配(去除首尾空格、转小写、四舍五入)归一化后所有值均相等
多语言以本次运行的主语言为准;翻译差异仅触发按语言的合并主语言中的文本相同——翻译的措辞变体不算作分歧
数组对项目的主语言视图进行集合比较(与顺序无关)无论顺序或翻译措辞如何,均为相同项目
对象只要标识字段能证明两个模型描述的是同一事物,就按属性处理——否则整个对象算作一处冲突所有嵌套属性均匹配
Null / 空null、空字符串或空数组值表示弃权,而非主张已填充的值胜出,且不计为冲突
示例:用 2 个模型扩充“Sanofi”
Claude 输出
revenue: 42.2
gmp_status: true
description: “Sanofi is a global...”
GPT-4 输出
revenue: 44.1
gmp_status: true
description: “Sanofi SA is a...”
结果: gmp_status = agreed | revenue = conflict (42.2 vs 44.1) | description = conflict (different text)

第 2 步:冲突解决

冲突将使用两种方法之一解决,具体取决于你是否在侧边栏中选择了仲裁模型。

选项 A

基于规则的合并

系统会根据每个字段的数据类型应用确定性规则。绝大多数情况下完全无需调用 LLM——解析即时且免费。唯一的例外是各模型给出的数值差异极大的情况,任何规则都无法公正裁决;详见下文。

字段类型规则理由
字符串多数投票;平局时取最长值通常细节越多越好
数字最接近中位数的模型值对异常值稳健,绝不生成虚构的平均值
布尔值多数;平局时取 true保守默认值
多语言按语言进行多数投票,合并各语言各语言独立解析
数组键感知合并:项目按其键字段分组,拼写变体归并在一起,匹配的项目按字段合并每个逻辑实体对应一行,不丢失任何数据
对象标识一致时按字段处理;否则整体采用某一个模型的对象把描述不同实体的两个对象混合,会凭空造出第三个两个模型都未返回的对象
Null 与值优先选择已填充的值数据缺失比任何值都更糟

决胜规则:票数相同时,价格更高的模型给出的值胜出(以价格作为能力的代理指标),其次按模型名称的字母顺序排定。若整个对象被作为原子整体采纳,则完整度——即已填充叶子节点的数量——排在两者之间:在无从证明哪个实体为真时,优先选择更强的模型,再选择承载信息更多的答案。

嵌套对象整体合并,而非混合

只有当两个模型描述的是同一事物时,逐字段合并嵌套对象才是安全的。当标识字段无法证明这一点时——键不同,或根本没有键而底层确实存在分歧——该对象将被视为单个冲突,并原样采用其中一个模型的版本。否则融合就会拼出一个怪物:把这个模型的地址装到那个模型的公司上。有一个后果是有意为之的,但值得了解:胜出方连同其空白一并被采用,因此胜出方留空的字段仍为空——这可能会让该实体卡在数据库准入关卡。相应原因会随本次运行的校验警告一并给出。

数值分歧过大、无法合并时

“最接近中位数”适用于模型四舍五入方式不同的情形,却不适用于模型相互矛盾的情形——0 与 1854 之间的差距不是舍入差异。当各值的相对离散度达到 20% 时,该字段会升级交由 LLM 仲裁器处理,仲裁模型通过组织常规的模型选择流程自动选定,该调用与其他调用一样计费。这些字段会在融合审计记录中标记为自动升级,因此凡是消耗了 token 的合并,都会说明是哪些字段引起的。

选项 B

LLM 仲裁

当你在侧边栏选择仲裁模型时,冲突会被发送给 LLM 进行智能解决。仲裁器会接收实体上下文、架构字段描述以及所有冲突值,然后做出有依据的决策。

仲裁器返回的内容
选定的值它认为最准确的值
源模型所选值来自哪个模型
推理为何选择该值而非其他候选值
置信度对该决策的置信度(高、中、低)

回退:如果仲裁模型失败(超时、错误),系统会自动回退到基于规则的合并,从而确保你始终能得到结果。

第 3 步:合并后的结果

冲突解决后,系统会构建单个合并结果,并将其作为“仲裁”记录存储在数据库中。每个合并结果都包含审计追踪,以便你追溯每个冲突的解决方式。

审计追踪(arbitration 元数据)

每条合并结果都包含记录融合过程的元数据:

“method”: “rule_based” | “llm”
“source_record_ids”: [“uuid-1”, “uuid-2”]
“total_fields”: 23
“agreed_fields”: 18
“conflicted_fields”: 5
“decisions”: [{ path, chosen_value, rule_used, ... }]

对于任何合并后的记录,都会在历史记录页面的概览选项卡中显示相同的审计记录。合并记录列出的是它所合并的各个模型,而非其自身的某个模型——当合并基于规则时,它完全没有进行 LLM 调用,因此不含提示词、不含 token,也不产生费用。

你在界面中看到的内容

融合完成后,结果面板中的“合并”选项卡会显示:

1
摘要标题栏
显示解决方法(基于规则或 LLM),以及类似“18 个一致 / 5 个已解决 / 共 23 个字段”的计数。
2
合并后的 JSON
将一致的值和已解决的冲突合并到单个 JSON 文档中的完整结构化输出。
3
冲突报告
为每个冲突提供可展开的卡片,显示:字段路径、解决方式标记(多数投票、中位数、并集等)、所有 model 的取值并高亮所选值,以及在使用 LLM arbitration 时的推理文本。

批处理中的自动融合

批量富化中,当你选择两个或更多模型时会自动进行融合。你无需手动点击“合并结果”—— 一旦某个实体的所有模型都成功,融合就会运行,合并结果会与各模型的单独输出一并显示。若某次运行中有模型失败,系统会刻意不进行融合:合并剩余结果会把不完整的答案悄悄当作一致结论发布出去。请先恢复缺失的模型 —— 重试其失败的专长领域后,运行一旦重新完整,就会自动融合。

流式 fusion:在单 entity 和 batch enrichment 期间,fusion 进度都会通过 Server-Sent Events 流式传输。您可以实时看到 fusion_startedconflicts_detectedfusion_completed 事件。

基于规则 vs LLM 仲裁:分别何时使用

基于规则(即时,几乎总是免费)
  • 主要为投票逻辑效果良好的事实/数值数据
  • 注重成本的大批量或 batch 处理
  • 预期冲突较少的简单 schema
  • 当你希望获得确定性、可复现的结果时
LLM 仲裁(额外费用)
  • 上下文对解析至关重要的复杂 schema
  • 投票不足以处理的文本数据(描述、摘要)
  • 当你需要带有推理过程的可解释决策时
  • 值得为准确性支付额外成本的高风险 enrichment