Flujo de enriquecimiento - Documentación de Entity Enricher

Flujo de enriquecimiento

Un recorrido paso a paso de cómo Entity Enricher procesa una sola entidad: desde la entrada, pasando por la clasificación y la ejecución paralela de modelos, hasta la salida estructurada.

El pipeline de un vistazo

Entrada
JSON de entidad
+ esquema
Clasificación
Comprobación de tipo
opcional
Modelos en paralelo
Claude
financiero
regulatorio
general
GPT-4
financiero
regulatorio
general
Validar
Verificación de tipo
Autocorrección
Salida
Estructurado
JSON por modelo

Paso 1: configurar el enriquecimiento

Abra la página del Editor de flujos de trabajo y configure su enriquecimiento. Un asistente de pasos lo guía por las etapas del proceso: Datos de muestra, Esquema, Enriquecimiento y Resultados, además de un paso de Base de datos lista cuando el esquema está vinculado a un Database Sync, que confirma que los cambios de la ejecución se pusieron en cola para su base de datos (o explica por qué se rechazó el guardado).

Panel de esquema (izquierda)

Pegue JSON de muestra para generar automáticamente un esquema y luego explore el árbol de propiedades interactivo. Edite propiedades, añada dominios de especialización y marque campos como claves de búsqueda o preservados.

Panel de enriquecimiento (derecha)

Configure las opciones de enriquecimiento (estrategia, modelos, idiomas, clasificación, además del esquema de respuesta y los conmutadores de salida estructurada estricta) y complete las claves de búsqueda de la entidad (nombre, sitio web, país, etc.) para identificarla.

Panel de resultados

Muestra el progreso y los resultados en tiempo real de cada modelo. Al usar varios modelos, aparece un botón «Combinar resultados» para la fusión.

Qué se comprueba antes de gastar ningún token

Algunas solicitudes no pueden producir un resultado utilizable, y el lugar más barato para descubrirlo es antes de la primera llamada al LLM. Se aplican dos contratos por adelantado.

El contrato de entrada

Un esquema declara lo que debe contener su entrada: los campos clave que indican qué entidad es, una clave en cada elemento de los arrays que proporcione y un valor para cada campo marcado como preservado (no se puede preservar nada que nunca se haya facilitado). Una solicitud a la que le falte cualquiera de estos elementos se rechaza con un único error que enumera todas las infracciones a la vez, además del contrato completo del esquema, para que pueda corregirlo de una sola pasada en lugar de descubrir los requisitos de rechazo en rechazo. El contrato se publica en cada esquema guardado, de modo que un cliente puede comprobarlo antes de enviar.

El contrato de array cerrado

Un array para el que usted aporta elementos se enriquece exactamente: el modelo completa lo que sabe de cada elemento y no puede añadir ni eliminar ninguno. Si envió cinco líneas, recibe cinco. Un elemento que el modelo no haya reclamado se reinserta literalmente en lugar de perderse, y uno que haya inventado se descarta. Los arrays que deje vacíos siguen abiertos: ahí el modelo descubre datos, que es de lo que se trata.

Paso 2: clasificación previa (opcional)

Si seleccionó un modelo de clasificación, primero se ejecuta una llamada al LLM rápida y económica para verificar que la entidad coincide con el tipo del esquema. Esto evita malgastar tokens en el enriquecimiento cuando la entidad no coincide. Consulte más en la documentación de clasificación.

No bloqueante: Si la clasificación falla por cualquier motivo, el enriquecimiento continúa con normalidad. La clasificación es meramente orientativa: añade contexto a los prompts de enriquecimiento, pero nunca bloquea el pipeline.

Paso 3: ejecución de la estrategia

Cada modelo seleccionado procesa la entidad con la estrategia que haya indicado o, de forma predeterminada, con la que se elige automáticamente a partir de la forma de su esquema, que la ejecución indica al iniciarse. Cuando se seleccionan varios modelos, se ejecutan en paralelo entre proveedores (Claude y GPT-4 se ejecutan simultáneamente), mientras que los modelos de un mismo proveedor se ejecutan de forma secuencial para respetar los límites de frecuencia.

Ejemplo de multiespecialización (3 dominios)
1
Dividir el esquema por especialidad
Las propiedades se agrupan por su dominio de experiencia: campos financieros, campos regulatorios, campos generales.
2
Ejecute llamadas LLM en paralelo
Cada especialización recibe su propio prompt enfocado con solo las propiedades relevantes del esquema. Todas se ejecutan simultáneamente.
3
Fusionar resultados progresivamente
A medida que cada especialización se completa, su resultado se fusiona con el resultado acumulado. Verá resultados parciales en tiempo real.
4
Aplicar lógica de conservación
Se restauran los valores originales de los campos marcados como 'preserve', de modo que sus datos de entrada permanecen intactos. Dentro de los arrays, los elementos enriquecidos se emparejan con los elementos de entrada por sus campos clave y no por su posición, así que una respuesta reordenada sigue restaurando los valores correctos.

Paso 4: Validación y autocorrección

Cada respuesta del LLM se valida contra su esquema en tiempo real. Cuando la salida no coincide con los tipos o las restricciones esperados, el sistema envía automáticamente los errores de vuelta al LLM para su corrección.

Qué se corrige automáticamente:
Cadena en lugar de número
«42.2» se convierte en 42.2
Objetos indexados como matrices
{"0": "a", "1": "b"} se convierte en ["a", "b"]
Nulos como cadena
«null» o «None» se convierte en un null real
Valores que el modelo no pudo determinar
Los declara en lugar de inventarlos: esas rutas quedan como null

Hasta 5 reintentos automáticos por llamada al LLM. Cada reintento incluye el error de validación concreto para que el LLM sepa exactamente qué corregir, y la reparación es quirúrgica: solo se vuelven a pedir las hojas que llegaron mal, no la respuesta completa.

Fíjese en lo que no figura en esta lista: un valor que el modelo no pudo determinar no es un error que haya que reintentar. Cualquier campo puede volver ausente, y el modelo declara lo que no pudo encontrar, de modo que “desconocido” es una respuesta y no un fallo. Si un valor ausente resulta aceptable se decide más tarde, cuando la entidad se admite en su base de datos, y no obligando al modelo a adivinar.

Imponer la salida en el origen

Dos conmutadores opcionales piden al provider que restrinja la salida antes de que se devuelva, de modo que menos respuestas necesiten corrección desde el principio. Ambos solo se aplican a los modelos que los admiten; todo sigue recurriendo al bucle de validación y reintento anterior.

Schema de respuesta
Envía su esquema por el canal nativo de esquema de respuesta del proveedor para que el JSON se aplique del lado del servidor. Desactivado por defecto: de lo contrario, los modelos capaces usan el canal de llamada a herramientas.
Salida estructurada estricta
Restringe la decodificación al schema (sin desviación) en el canal estructurado que se utilice. Activada de forma predeterminada; los modelos que no pueden aplicarla la ignoran silenciosamente.

Paso 5: Streaming en tiempo real

Entity Enricher utiliza Server-Sent Events (SSE) para transmitir el progreso en tiempo real. No tiene que esperar a que todos los modelos terminen: los resultados aparecen de forma progresiva a medida que cada dominio de experiencia o modelo finaliza.

Cronología de eventos (ejemplo con 2 modelos, 3 dominios de especialización)
0.0sstartedEl trabajo comienza, 2 modelos en cola
0.1sclassification_startedComienza la comprobación previa
0.8sclassification_completedEntidad confirmada como "coincidencia" (95 %)
0.9smodel_startedClaude y GPT-4 se inician en paralelo
1.2sexpertise_completedClaude: parte financiera lista, resultado parcial transmitido
1.5sexpertise_completedClaude: parte general lista, resultado actualizado
1.8sexpertise_completedClaude: parte regulatoria completada, resultado completo listo
1.9smodel_completedClaude finalizó con la salida estructurada completa
2.5smodel_completedGPT-4 terminó con salida estructurada completa
2.5scompletedTodos los modelos listos, el flujo se cierra

Paso 6: Revisar resultados

Cada modelo obtiene su propio panel de resultados que muestra la salida JSON estructurada, insignias de progreso por especialización, uso de tokens, coste y tiempo de procesamiento. Al usar la estrategia multiespecialización, las insignias de especialización se actualizan en tiempo real a medida que se completa cada dominio.

Qué ve por modelo:
  • Insignia de estado — En espera, En ejecución, Correcto, Fallido o Parcial
  • Insignias de especialización — Píldoras de colores que muestran el progreso por dominio (azul = en ejecución, verde = completado, rojo = fallido)
  • JSON progresivo — La salida se actualiza cuando se completa cada especialización
  • Métricas — Tiempo de procesamiento, número de tokens, coste en USD
  • Registro de progreso — Entradas con marca de tiempo para cada evento

Gestión del éxito parcial

Cuando se utiliza la estrategia multi-expertise domain, algunos expertise domains pueden fallar mientras otros tienen éxito. En lugar de descartarlo todo, Entity Enricher devuelve la salida combinada de los expertise domains exitosos con un estado «Parcial». Luego puede reintentar solo los expertise domains fallidos sin volver a ejecutar todo el enrichment.

Ejemplo: Si 2 de cada 3 especializaciones tienen éxito, obtiene una salida estructurada que cubre los dominios exitosos. La especialización fallida puede reintentarse y sus resultados se fusionarán en la salida existente.

¿Qué sucede después?

Una vez completado el enriquecimiento, sus resultados se guardan en la página de Historial para futuras consultas. Si utilizó varios modelos, puede combinar los resultados mediante Fusión multimodelo.