Fusión multimodelo - Documentación de Entity Enricher

Fusión multimodelo

Cuando ejecuta el mismo enrichment en varios models de IA, Entity Enricher puede fusionar los resultados en una única salida de alta confianza. La fusion detecta conflictos entre las salidas de los models y los resuelve mediante reglas deterministas o arbitration con tecnología de LLM.

Pipeline de fusión

Salidas del modelo
Resultado de Claude
Resultado de GPT-4
Resultado de Gemini
Detección de conflictos
Compare cada campo
en todos los modelos
Resolución
Combinación basada en reglas
o
Arbitraje por LLM
Resultado fusionado
Una única salida con
traza de auditoría de conflictos

Paso 1: detección de conflictos

El detector de conflictos compara cada campo entre todas las salidas de los modelos. Los campos en los que todos los modelos coinciden pasan sin cambios. Los campos en los que los modelos difieren se marcan como conflictos que requieren resolución.

Reglas de comparación por tipo de campo
TipoMétodo de comparaciónQué significa la concordancia
EscalarCoincidencia exacta normalizada (recortada, en minúsculas, redondeada)Todos los valores son iguales tras la normalización
MultilingüeEl idioma principal de la ejecución decide; las diferencias de traducción solo activan una fusión por idiomaEl mismo texto en el idioma principal: las variantes de redacción de una traducción no son discrepancias
ArrayComparación de conjuntos (independiente del orden) sobre la vista de los elementos en el idioma principalLos mismos elementos sin importar el orden ni la redacción de la traducción
ObjetoPor propiedad mientras los campos de identidad demuestren que ambos modelos describen lo mismo — de lo contrario, todo el objeto constituye un único conflictoTodas las propiedades anidadas coinciden
Nulo / vacíoUn valor nulo, una cadena vacía o un arreglo vacío es una abstención, no una afirmaciónEl valor completado prevalece sin contar como conflicto
Ejemplo: enriquecer «Sanofi» con 2 modelos
Salida de Claude
revenue: 42.2
gmp_status: true
description: “Sanofi is a global...”
Salida de GPT-4
revenue: 44.1
gmp_status: true
description: “Sanofi SA is a...”
Resultado: gmp_status = agreed | revenue = conflict (42.2 vs 44.1) | description = conflict (different text)

Paso 2: resolución de conflictos

Los conflictos se resuelven mediante uno de dos métodos, según si seleccionó un modelo de arbitraje en la barra lateral.

Opción A

Combinación basada en reglas

Se aplican reglas deterministas según el tipo de dato de cada campo. Casi siempre esto no requiere ninguna llamada al LLM: la resolución es instantánea y gratuita. La única excepción son los números en los que los modelos discrepan enormemente, que ninguna regla puede resolver con honestidad; véase más abajo.

Tipo de campoReglaJustificación
CadenaVoto mayoritario; en caso de empate gana el valor más largoMás detalle suele ser mejor
NúmeroEl valor del modelo más cercano a la medianaResistente a valores atípicos, nunca un promedio inventado
BooleanoMayoría; «true» gana los empatesValor predeterminado conservador
MultilingüeVoto mayoritario por idioma, unión de idiomasCada idioma se resuelve de forma independiente
ArrayUnión basada en claves: los elementos se agrupan por sus campos clave, las variantes de escritura se combinan y los elementos coincidentes se fusionan campo por campoUna fila por entidad lógica, sin perder nada
ObjetoPor campo cuando la identidad coincide; de lo contrario, se toma entero el objeto de un solo modeloMezclar dos objetos que describen entidades distintas inventaría un tercero que ningún modelo devolvió
Null frente a valorPreferir el valor completadoLa falta de datos es peor que cualquier valor

Criterio de desempate: cuando hay empate de votos, gana el valor del modelo de precio más alto (como indicador de su capacidad) y, a continuación, el orden alfabético del nombre del modelo. Para un objeto completo tomado de forma atómica, la exhaustividad —el número de hojas rellenadas— se sitúa entre ambos criterios: al no haber nada que demuestre qué entidad es la real, se prefiere el modelo más potente y después la respuesta que aporta más información.

Los objetos anidados se fusionan enteros, no se mezclan

Fusionar un objeto anidado campo por campo solo es seguro mientras ambos modelos describan lo mismo. Cuando los campos de identidad no lo demuestran —claves distintas, o ninguna clave en absoluto con un desacuerdo real por debajo—, el objeto se convierte en un único conflicto y se toma la versión de uno de los modelos tal cual. De lo contrario, la fusión ensamblaría una quimera: la dirección de un modelo sobre la empresa de otro. Una consecuencia es deliberada, pero conviene conocerla: el ganador se toma con sus huecos incluidos, de modo que un campo que el ganador dejó vacío sigue vacío, lo que puede frenar a la entidad en la puerta de admisión a la base de datos. El motivo se incluye en las advertencias de validación de la ejecución.

Cuando las cifras difieren demasiado para fusionarse

“Lo más cercano a la mediana” es correcto cuando los modelos redondean de forma distinta, pero no cuando se contradicen entre sí: 0 frente a 1854 no es una diferencia de redondeo. Cuando la dispersión relativa de los valores alcanza el 20 %, ese campo se escala a un árbitro LLM elegido automáticamente mediante la selección de modelos habitual de su organización, y la llamada se factura como cualquier otra. Esos campos se marcan como escalados automáticamente en el registro de auditoría de la fusión, de modo que una fusión que consumió tokens siempre indica qué campos la provocaron.

Opción B

Arbitraje por LLM

Cuando selecciona un arbitration model en la barra lateral, los conflictos se envían a un LLM para su resolución inteligente. El árbitro recibe el contexto de la entity, las descripciones de los campos del schema y todos los valores en conflicto, y luego toma decisiones razonadas.

Qué devuelve el arbitrador
Valor elegidoEl valor que considera más preciso
Modelo de origenDe qué modelo proviene el valor elegido
RazonamientoPor qué eligió ese valor en lugar de las alternativas
ConfianzaCuánta confianza tiene en la decisión (alta, media, baja)

Respaldo: Si el modelo de arbitraje falla (tiempo de espera, error), el sistema recurre automáticamente a la combinación basada en reglas para que siempre obtenga un resultado.

Paso 3: el resultado fusionado

Tras la resolución de conflictos, el sistema construye un único resultado combinado y lo almacena como registro de «arbitraje» en la base de datos. Cada resultado combinado incluye un registro de auditoría para que pueda rastrear cómo se resolvió cada conflicto.

Registro de auditoría (metadatos de arbitraje)

Cada resultado combinado incluye metadatos que documentan el proceso de fusión:

“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, ... }]

El mismo registro de auditoría se muestra para cualquier registro combinado en la página de Historial, en su pestaña Resumen. Un registro combinado enumera los modelos que combinó en lugar de tener un modelo propio, y cuando la combinación se basó en reglas no realizó ninguna llamada al LLM, por lo que no incluye prompt, ni tokens ni coste.

Qué ve en la interfaz

Una vez completada la fusión, la pestaña «Combinado» del panel de resultados muestra:

1
Encabezado de resumen
Muestra el método de resolución (basado en reglas o LLM) y un recuento como «18 coincidentes / 5 resueltos / 23 campos en total».
2
JSON fusionado
La salida estructurada completa que combina los valores acordados y los conflictos resueltos en un único documento JSON.
3
Informe de conflictos
Tarjetas expandibles para cada conflicto que muestran: la ruta del campo, la insignia del método de resolución (voto mayoritario, mediana, unión, etc.), todos los valores del modelo con el elegido resaltado y el texto de razonamiento si se utilizó arbitraje por LLM.

Fusion automática en el procesamiento por batch

En el enriquecimiento por lotes, la fusión se realiza automáticamente cuando selecciona dos o más modelos. No hace falta hacer clic en “Combinar resultados” manualmente: en cuanto todos los modelos hayan tenido éxito con una entidad, se ejecuta la fusión y el resultado combinado aparece junto a las salidas de cada modelo. Una ejecución en la que un modelo ha fallado no se fusiona de forma deliberada: combinar lo que queda publicaría en silencio una respuesta parcial como si fuera la consensuada. Recupere primero el modelo que falta: al reintentar sus especialidades fallidas, la ejecución se fusiona automáticamente en cuanto vuelve a estar completa.

Fusión en streaming: Durante el enriquecimiento, tanto de una sola entidad como por lote, el progreso de la fusión se transmite mediante Server-Sent Events. Verá los eventos fusion_started, conflicts_detected y fusion_completed en tiempo real.

Basado en reglas vs. arbitraje con LLM: cuándo usar cada uno

Basado en reglas (instantáneo, casi siempre gratuito)
  • Datos mayoritariamente objetivos/numéricos donde la lógica de votación funciona bien
  • Alto volumen o procesamiento por batch donde el coste importa
  • Esquemas simples con pocos conflictos previstos
  • Cuando desea resultados deterministas y reproducibles
Arbitraje por LLM (coste adicional)
  • Esquemas complejos donde el contexto importa para la resolución
  • Datos textuales (descripciones, resúmenes) donde la votación es insuficiente
  • Cuando necesita decisiones explicables con razonamiento
  • Enrichments críticos donde la precisión justifica el coste adicional