Fluxo de enriquecimento - Documentação do Entity Enricher

Fluxo de enriquecimento

Um guia passo a passo de como o Entity Enricher processa uma única entidade — desde a entrada, passando pela classificação e execução paralela de modelos, até à saída estruturada.

O Pipeline num Relance

Entrada
JSON da entidade
+ Esquema
Classificação
Verificação de tipo
opcional
Modelos em paralelo
Claude
financeiro
regulamentar
geral
GPT-4
financeiro
regulamentar
geral
Validar
Verificação de tipo
Autocorreção
Saída
Estruturado
JSON por modelo

Passo 1: Configurar o Enriquecimento

Abra a página do Editor de Fluxo de Trabalho e configure o seu enriquecimento. Um assistente de passos guia-o pelas fases do pipeline: Dados de Amostra, Esquema, Enriquecimento e Resultados — mais um passo Base de Dados Pronta quando o esquema está ligado a um Database Sync, confirmando que as alterações da execução foram colocadas em fila para a sua base de dados (ou explicando porque a gravação foi recusada).

Painel do Esquema (à esquerda)

Cole uma amostra JSON para gerar automaticamente um esquema e, em seguida, explore a árvore de propriedades interativa. Edite propriedades, adicione domínios de especialização e marque campos como chaves de pesquisa ou preservados.

Painel de enriquecimento (à direita)

Configure as opções de enriquecimento (estratégia, modelos, idiomas, classificação, além do schema de resposta e das opções de saída estruturada estrita) e preencha as chaves de pesquisa da entidade (nome, site, país, etc.) para identificar a entidade.

Painel de Resultados

Mostra o progresso e os resultados em tempo real para cada modelo. Ao utilizar vários modelos, aparece um botão “Combinar Resultados” para a fusão.

O que é verificado antes de gastar quaisquer tokens

Alguns pedidos não têm qualquer hipótese de produzir um resultado utilizável, e o sítio mais barato para o descobrir é antes da primeira chamada ao LLM. São aplicados dois contratos logo à partida.

O contrato de entrada

Um esquema declara o que a sua entrada tem de conter: os campos-chave que dizem qual é a entidade, uma chave em cada item de um array que forneça e um valor para cada campo marcado como preservado (nada pode ser preservado se nunca foi fornecido). Um pedido a que falte algum destes elementos é recusado com um único erro que lista todas as violações de uma vez — mais o contrato completo do esquema, para que possa corrigir tudo numa só passagem em vez de descobrir os requisitos a cada rejeição. O contrato é publicado em todos os esquemas guardados, para que um cliente possa verificar antes de enviar.

O contrato de array fechado

Um array para o qual fornece itens é enriquecido exatamente: o modelo preenche o que sabe sobre cada item e não pode acrescentar nem eliminar nenhum. Enviou cinco linhas, recebe cinco de volta. Um item que o modelo não tenha tratado é reinserido tal e qual, em vez de se perder, e um item que tenha inventado é descartado. Os arrays que deixar vazios continuam abertos — aí é o modelo a descobrir factos, que é precisamente o objetivo.

Passo 2: Classificação Preliminar (Opcional)

Se você tiver selecionado um model de classification, é executada primeiro uma chamada rápida e económica ao LLM para verificar se a entity corresponde ao tipo do schema. Isto evita desperdiçar tokens em enrichment quando a entity não corresponde. Saiba mais na documentação de Classification.

Não bloqueante: Se a classificação falhar por qualquer motivo, o enriquecimento prossegue normalmente. A classificação é puramente informativa — adiciona contexto aos prompts de enriquecimento, mas nunca bloqueia o pipeline.

Passo 3: Execução da Estratégia

Cada modelo selecionado processa a entidade com a estratégia que indicou — ou, por predefinição, com a que é escolhida automaticamente a partir da forma do seu esquema, e que a execução comunica ao arrancar. Quando são selecionados vários modelos, estes correm em paralelo entre fornecedores (Claude e GPT-4 correm em simultâneo), enquanto os modelos do mesmo fornecedor correm sequencialmente para respeitar os limites de taxa.

Exemplo de multi-especialização (3 domínios)
1
Dividir o schema por especialização
As propriedades são agrupadas pelo seu domínio de especialização: campos financeiros, campos regulatórios, campos gerais.
2
Execute chamadas LLM em paralelo
Cada especialização recebe o seu próprio prompt focado, apenas com as propriedades relevantes do schema. Todas são executadas em simultâneo.
3
Combinar resultados progressivamente
À medida que cada domínio de expertise é concluído, o respetivo resultado é fundido no resultado acumulado. Você vê resultados parciais em tempo real.
4
Aplicar lógica de preservação
Os valores originais dos campos marcados como 'preserve' são restaurados, garantindo que os seus dados de entrada permanecem intactos. Dentro de arrays, os itens enriquecidos são associados aos seus itens de entrada pelos campos-chave e não pela posição, pelo que uma resposta reordenada continua a restaurar os valores corretos.

Passo 4: Validação e autocorreção

Cada resposta do LLM é validada em relação ao seu schema em tempo real. Quando o output não corresponde aos tipos ou restrições esperados, o sistema envia automaticamente os erros de volta ao LLM para correção.

O que é corrigido automaticamente:
String em vez de número
"42.2" torna-se 42.2
Objetos indexados como arrays
{"0": "a", "1": "b"} torna-se ["a", "b"]
Nulos em string
"null" ou "None" torna-se um null real
Valores que o modelo não conseguiu determinar
Declara-os em vez de os inventar — esses caminhos passam a null

Até 5 tentativas automáticas de repetição por chamada ao LLM. Cada repetição inclui o erro de validação específico, para que o LLM saiba exatamente o que corrigir — e a reparação é cirúrgica: apenas as folhas que vieram erradas são pedidas de novo, não a resposta inteira.

Repare no que não consta desta lista: um valor que o modelo não conseguiu determinar não é um erro a repetir. Qualquer campo pode vir ausente e o modelo declara o que não conseguiu encontrar, pelo que “desconhecido” é uma resposta e não uma falha. Se um valor em falta é aceitável decide-se mais tarde, quando a entidade é admitida na sua base de dados — e não obrigando o modelo a adivinhar.

Impor a saída na origem

Dois botões opcionais pedem ao provider que restrinja a saída antes de esta ser devolvida, para que menos respostas precisem de correção à partida. Ambos se aplicam apenas a models que os suportam; tudo continua a recorrer ao ciclo de validação e repetição acima.

Esquema de resposta
Envia o seu esquema no canal nativo de esquema de resposta do fornecedor, para que o JSON seja imposto no lado do servidor. Desativado por predefinição — caso contrário, os modelos capazes usam o canal de chamada de ferramentas.
Saída estruturada estrita
Restringe a descodificação ao esquema (sem desvios) em qualquer canal estruturado utilizado. Ativado por predefinição; ignorado silenciosamente pelos modelos que não o conseguem aplicar.

Passo 5: Streaming em tempo real

O Entity Enricher usa Server-Sent Events (SSE) para transmitir o progresso em tempo real. Não tem de esperar que todos os modelos concluam — os resultados aparecem progressivamente à medida que cada domínio de especialização ou modelo termina.

Cronologia de eventos (exemplo com 2 modelos, 3 especializações)
0.0sstartedA tarefa começa, 2 models em fila
0.1sclassification_startedA verificação prévia começa
0.8sclassification_completedEntity confirmada como "match" (95%)
0.9smodel_startedClaude e GPT-4 iniciam em paralelo
1.2sexpertise_completedClaude: parte financeira concluída, resultado parcial transmitido
1.5sexpertise_completedClaude: parte geral concluída, resultado atualizado
1.8sexpertise_completedClaude: regulatório concluído, resultado completo pronto
1.9smodel_completedClaude terminou com output estruturado completo
2.5smodel_completedO GPT-4 terminou com saída estruturada completa
2.5scompletedTodos os modelos concluídos, o stream fecha

Passo 6: Rever resultados

Cada modelo tem o seu próprio painel de resultados, que mostra o output JSON estruturado, distintivos de progresso por especialização, utilização de tokens, custo e tempo de processamento. Ao utilizar a estratégia multi-especialização, os distintivos de especialização atualizam-se em tempo real à medida que cada domínio termina.

O que vê por modelo:
  • Emblema de estado — Em espera, Em execução, Sucesso, Falhou ou Parcial
  • Emblemas de especialização — Cápsulas coloridas que mostram o progresso por domínio (azul = em execução, verde = concluído, vermelho = falhado)
  • JSON progressivo — O resultado é atualizado após a conclusão de cada especialização
  • Métricas — Tempo de processamento, contagem de tokens, custo em USD
  • Registo de progresso — Entradas com data e hora para cada evento

Gerir sucesso parcial

Ao utilizar a estratégia multi-expertise domain, algumas expertise domains podem falhar enquanto outras têm êxito. Em vez de descartar tudo, o Entity Enricher devolve o resultado combinado das expertise domains bem-sucedidas com um estado “Parcial”. Pode então repetir apenas as expertise domains que falharam sem voltar a executar todo o enrichment.

Exemplo: Se 2 de 3 especializações forem bem-sucedidas, obtém um resultado estruturado que abrange os domínios bem-sucedidos. A especialização falhada pode ser repetida e os seus resultados serão fundidos no resultado existente.

O Que Acontece a Seguir?

Após a conclusão do enriquecimento, os seus resultados são guardados na página de Histórico para referência futura. Se utilizou vários modelos, pode combinar os resultados através da Fusão Multimodelo.