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.
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.
| Tipo | Método de comparación | Qué significa la concordancia |
|---|---|---|
| Escalar | Coincidencia exacta normalizada (recortada, en minúsculas, redondeada) | Todos los valores son iguales tras la normalización |
| Multilingüe | El idioma principal de la ejecución decide; las diferencias de traducción solo activan una fusión por idioma | El mismo texto en el idioma principal: las variantes de redacción de una traducción no son discrepancias |
| Array | Comparación de conjuntos (independiente del orden) sobre la vista de los elementos en el idioma principal | Los mismos elementos sin importar el orden ni la redacción de la traducción |
| Objeto | Por propiedad mientras los campos de identidad demuestren que ambos modelos describen lo mismo — de lo contrario, todo el objeto constituye un único conflicto | Todas las propiedades anidadas coinciden |
| Nulo / vacío | Un valor nulo, una cadena vacía o un arreglo vacío es una abstención, no una afirmación | El valor completado prevalece sin contar como conflicto |
Las reglas deterministas se ejecutan en cada fusión y resuelven todo lo que los propios valores de los modelos pueden demostrar. Aquello sobre lo que solo pueden preferir una respuesta — un valor contradicho, un objeto anidado que los modelos describen de forma distinta, un elemento que solo un modelo generó — se remite a un resolutor. Seleccionar un modelo de arbitraje en la barra lateral decide quién es ese resolutor: las propias reglas o un LLM.
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 campo | Regla | Justificación |
|---|---|---|
| Cadena | Voto mayoritario; en caso de empate gana el valor más largo | Más detalle suele ser mejor |
| Número | El valor del modelo más cercano a la mediana | Resistente a valores atípicos, nunca un promedio inventado |
| Booleano | Mayoría; «true» gana los empates | Valor predeterminado conservador |
| Multilingüe | Voto mayoritario por idioma, unión de idiomas | Cada idioma se resuelve de forma independiente |
| Array | Unió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 campo | Una fila por entidad lógica, sin perder nada |
| Objeto | Por campo cuando la identidad coincide; de lo contrario, se toma entero el objeto de un solo modelo | Mezclar dos objetos que describen entidades distintas inventaría un tercero que ningún modelo devolvió |
| Null frente a valor | Preferir el valor completado | La 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.
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.
“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.
Cuando selecciona un modelo de arbitraje en la barra lateral, las preguntas que las reglas no pudieron resolver se remiten a ese LLM. Este ve la identidad de la entidad, la descripción de cada campo y el valor de cada modelo mostrado en su idioma de enriquecimiento principal — y responde señalando, nunca escribiendo un valor propio.
Las preguntas se plantean nivel por nivel: primero la entidad en sí y después cada elemento de array emparejado en su propia llamada, con su propia identidad como contexto (“Acto I de esta ópera”) — y sobre un elemento que el árbitro descartó no se vuelve a preguntar. La parte compartida del prompt se almacena en caché en la primera llamada, de modo que las llamadas más profundas se ejecutan en paralelo por una fracción del coste.
Alternativa: Si el modelo de arbitraje falla (tiempo de espera agotado, error), se mantienen las decisiones basadas en reglas, por lo que siempre obtiene un resultado — y el registro indica qué método se aplicó.
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.
Cada resultado combinado incluye metadatos que documentan el proceso de fusión:
La misma traza de auditoría se muestra para cualquier registro combinado en la página Historial, en su pestaña Resumen. También se enumeran las decisiones tomadas dentro de un array — un campo de un elemento emparejado, un elemento conservado o descartado —, de modo que lo que se dejó fuera es tan visible como lo que se conservó. Un registro arbitrado por un LLM indica su árbitro como modelo; una combinación basada en reglas enumera en su lugar los modelos que combinó, ya que no realizó ninguna llamada a un LLM y no incluye prompt, ni tokens, ni coste.
Una vez completada la fusión, la pestaña «Combinado» del panel de resultados muestra:
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.
fusion_started, conflicts_detected y fusion_completed en tiempo real.