Regras de validação - Documentação do Entity Enricher

Regras de validação

Oito regras de validação garantem a qualidade do schema. Quando qualquer regra falha durante a geração de schema por IA, o erro é reenviado à IA para autocorreção automática.

Como funciona a autocorreção

Depois de a IA gerar um esquema, este passa por todas as 8 regras de validação. Se alguma regra falhar, as mensagens de erro específicas são compiladas e reenviadas à IA como feedback. A IA produz então um esquema corrigido, que é validado novamente. Este ciclo continua até um máximo de 6 tentativas no total (1 inicial + 5 repetições).

Fluxo de Correção

A IA geraEsquema com propriedades, tipos, especialização e descrições
Verificações do validador8 regras aplicadas sequencialmente, todos os erros recolhidos
Em caso de errosMensagens de erro reenviadas: “Corrija estes problemas: [revenue: incompatibilidade de tipo...]”
A IA corrigeProduz um esquema atualizado que corrige os erros reportados
RepetirAté que todas as regras passem ou o número máximo de tentativas seja atingido

Na prática, a maioria dos schemas é aprovada à primeira tentativa. O ciclo de autocorreção é uma rede de segurança que trata dos casos-limite em que a IA comete erros de tipo ou se esquece de um campo.

Regras de geração vs. edição

Nem todas as regras se aplicam tanto à geração de esquema como à edição por IA. As regras que comparam com os dados de entrada são ignoradas durante a edição porque pode adicionar ou remover campos intencionalmente:

ÂmbitoRegras aplicadasPorquê
GeraçãoTodas as 8 regrasOs dados de entrada estão disponíveis para comparação
Edição por IAApenas as regras 2, 3, 4 e 5Sem dados de entrada; o utilizador pode modificar intencionalmente a estrutura

As 8 Regras

Regra 1

Contagem de domínios de especialização

Âmbito: Apenas geração

O número de domínios de especialização não deve exceder o máximo calculado com base no seu número de propriedades. Isto impede que a IA crie demasiados domínios detalhados para esquemas pequenos.

Exemplo de erro: Too many expertise domains: 6 defined, maximum is 3

O máximo é calculado como floor(property_count / 6), com um mínimo de 1. Um esquema com 12 propriedades permite até 2 domínios.

Regra 2

Pelo Menos Uma Propriedade

Âmbito: Ambos

Cada schema tem de definir pelo menos uma propriedade. Um schema vazio não pode ser usado para enriquecimento.

Exemplo de erro: Schema must have at least one property

Isto deteta casos em que a IA produz uma estrutura JSON válida mas se esquece de incluir quaisquer campos reais.

Regra 3

Tipos de JSON Schema válidos

Âmbito: Ambos

Cada tipo de propriedade tem de ser um dos tipos padrão do JSON Schema: string, number, integer, boolean, array, object ou null.

Exemplo de erro: revenue: invalid type 'float'

A IA por vezes inventa tipos como "float", "decimal" ou "date". Esta regra deteta-os e pede uma correção para um tipo válido.

Regra 4

Os alvos de $ref existem

Âmbito: Ambos

Todas as referências $ref têm de apontar para entidades definidas na secção $defs do esquema. Referências pendentes quebram o pipeline de enriquecimento.

Exemplo de erro: manufacturer: $ref '#/$defs/Company' references undefined definition

Quando a IA cria uma referência como #/$defs/Company, tem de existir uma definição Company correspondente no bloco $defs.

Regra 5

A chave de especialização existe

Âmbito: Ambos

O valor de especialização de cada propriedade tem de corresponder a um dos domínios de especialização definidos. Isto evita erros de digitação e inconsistências.

Exemplo de erro: revenue: expertise 'finance' not in defined domains: ['financial_analyst']

A IA pode usar "finance" em vez da chave definida "financial_analyst". Esta regra deteta a incompatibilidade para que a IA a possa corrigir.

Regra 6

Especialização obrigatória

Âmbito: Apenas geração

As propriedades que não são objetos nem preservadas têm de ter uma atribuição de especialização. Isto garante que cada campo enriquecível é tratado por um domínio especialista.

Exemplo de erro: revenue: expertise is required for non-object types

Os tipos de objeto estão isentos porque as suas propriedades filhas transportam a sua própria expertise. Os campos preservados estão isentos porque passam sem alterações.

Regra 7

O tipo corresponde aos dados de entrada

Âmbito: Apenas geração

O tipo de esquema de cada propriedade tem de corresponder ao tipo Python real do valor correspondente nos seus dados de entrada.

Exemplo de erro: revenue: type mismatch - input is number but schema says 'string'

Se o seu input tiver "revenue": 42.5, o schema deve usar o tipo "number" ou "integer", não "string". O validador é flexível: aceita "number" para inteiros e vice-versa.

Regra 8

Todas as propriedades de entrada presentes

Âmbito: Apenas geração

Cada chave nos seus dados de entrada tem de aparecer como uma propriedade no schema gerado. Isto impede que a IA elimine campos silenciosamente.

Exemplo de erro: Missing property from input: 'headquarters'

Se o seu JSON de input tiver uma chave "headquarters", o schema gerado deve incluí-la. Isto garante uma cobertura completa dos seus dados.

Inferência de tipos

A regra 7 (correspondência de tipos) utiliza inferência automática de tipos para comparar os seus valores de entrada com os tipos declarados no schema. A inferência é flexível para evitar falsos positivos:

Valor de entradaTipo inferidoTambém aceita
true / falseboolean(apenas booleano)
42integernumber
3.14numberinteger
"hello"string(apenas string)
[1, 2, 3]array(apenas array)
{"key": "val"}object(apenas objeto)

Nota: os booleanos são verificados antes dos inteiros porque, em algumas linguagens, o booleano é um subtipo de inteiro. Esta ordenação impede que true seja inferido como um inteiro.

Próximos Passos