Reglas de validación - Documentación de Entity Enricher

Reglas de validación

Ocho reglas de validación garantizan la calidad del esquema. Se ejecutan en código una vez que la generación de esquemas con IA ha compuesto su respuesta: una última red de seguridad sobre un proceso que ya se corrige a sí mismo paso a paso.

Cómo funciona la autocorrección

La corrección se produce donde se comete el error, no al final. La generación es una secuencia de llamadas pequeñas con un único propósito, y cada una lleva su propio validador: comprueba la respuesta de esa llamada, conserva lo que sea válido y vuelve a pedir únicamente lo que sigue faltando. Así, un modelo que responde por fragmentos converge en lugar de empezar de cero.

Flujo de corrección

Respuestas del pasoUna pregunta acotada — los indicadores de un lote de propiedades, por ejemplo, o las descripciones de un dominio
Fusiones del validadorLas entradas válidas se acumulan; las inservibles se descartan una a una, sin que el lote pierda nunca sus respuestas correctas
Si está incompletoEl reintento pide solo las rutas que siguen faltando — hasta 3 intentos para ese paso
Luego degradarLos huecos restantes se rellenan de forma determinista y se anotan en el registro, de modo que un modelo débil le cuesta calidad de descripción, no el esquema
EnsamblajeLas 8 reglas siguientes se ejecutan sobre el esquema terminado como comprobación final

Solo dos pasos pueden hacer fallar por completo una generación: nombrar la entidad y asignar las propiedades a los dominios de especialidad. Todo lo demás cuenta con una alternativa determinista, que es lo que hace utilizables aquí a los modelos pequeños.

Reglas de generación vs. edición

No todas las reglas se aplican tanto a la generación de schemas como a la edición con IA. Las reglas que comparan con los datos de entrada se omiten durante la edición, ya que puede añadir o eliminar campos de forma intencionada:

AlcanceReglas aplicadasPor qué
GeneraciónLas 8 reglasLos datos de entrada están disponibles para comparar
Edición con IASolo las reglas 2, 3, 4 y 5No hay datos de entrada; el usuario puede modificar la estructura intencionalmente

Las 8 reglas

Regla 1

Recuento de dominios de expertise

Alcance: Solo generación

El número de dominios de experiencia no debe superar el máximo calculado en función de su número de propiedades. Esto evita que la IA cree demasiados dominios granulares para esquemas pequeños.

Error de ejemplo: Too many expertise domains: 6 defined, maximum is 3

El máximo se calcula como floor(property_count / 6), con un mínimo de 1. Un esquema con 12 propiedades permite hasta 2 dominios.

Regla 2

Al menos una propiedad

Alcance: Ambos

Cada esquema debe definir al menos una propiedad. Un esquema vacío no se puede usar para el enriquecimiento.

Error de ejemplo: Schema must have at least one property

Esto detecta los casos en los que la IA produce una estructura JSON válida pero olvida incluir campos reales.

Regla 3

Tipos de esquema JSON válidos

Alcance: Ambos

Cada tipo de propiedad debe ser uno de los tipos estándar de JSON Schema: string, number, integer, boolean, array, object o null.

Error de ejemplo: revenue: invalid type 'float'

A veces la IA inventa tipos como "float", "decimal" o "date". Esta regla los detecta y solicita una corrección a un tipo válido.

Regla 4

Los destinos de $ref existen

Alcance: Ambos

Cada $ref debe apuntar a algo que exista: #/$defs/... a una definición de entidad, #/$enums/... a un conjunto de valores. Las referencias colgantes rompen la canalización de enriquecimiento.

Error de ejemplo: manufacturer: $ref '#/$defs/Company' references undefined definition

Los dos espacios de nombres están separados: una referencia #/$defs/ es una relación con una entidad anidada, mientras que una referencia #/$enums/ restringe una propiedad de texto a una lista cerrada de valores permitidos. Cada una debe tener una entrada correspondiente en su propio bloque.

Regla 5

La clave de expertise existe

Alcance: Ambos

El valor de especialización de cada propiedad debe coincidir con uno de los dominios de especialización definidos. Esto evita errores tipográficos e inconsistencias.

Error de ejemplo: revenue: expertise 'finance' not in defined domains: ['financial_analyst']

La IA podría usar "finance" en lugar de la clave definida "financial_analyst". Esta regla detecta la discrepancia para que la IA pueda corregirla.

Regla 6

Expertise requerida

Alcance: Solo generación

Las propiedades que no son objetos ni están preservadas deben tener una asignación de expertise domain. Esto garantiza que cada campo enriquecible sea gestionado por un expertise domain especializado.

Error de ejemplo: revenue: expertise is required for non-object types

Los tipos de objeto están exentos porque sus propiedades secundarias llevan su propia especialización. Los campos preservados están exentos porque pasan sin cambios.

Regla 7

El tipo coincide con los datos de entrada

Alcance: Solo generación

El tipo de esquema de cada propiedad debe coincidir con el tipo de Python real del valor correspondiente en sus datos de entrada.

Error de ejemplo: revenue: type mismatch - input is number but schema says 'string'

Si su entrada tiene "revenue": 42.5, el esquema debe usar el tipo "number" o "integer", no "string". El validador es flexible: acepta "number" para enteros y viceversa.

Regla 8

Todas las propiedades de entrada presentes

Alcance: Solo generación

Cada clave de sus datos de entrada debe aparecer como una propiedad en el esquema generado. Esto evita que la IA descarte campos de forma silenciosa.

Error de ejemplo: Missing property from input: 'headquarters'

Si su JSON de entrada tiene una clave "headquarters", el esquema generado debe incluirla. Esto garantiza una cobertura completa de sus datos.

Inferencia de tipo

La regla 7 (coincidencia de tipos) utiliza inferencia de tipos automática para comparar sus valores de entrada con los tipos declarados del esquema. La inferencia es flexible para evitar falsos positivos:

Valor de entradaTipo inferidoTambién acepta
true / falseboolean(solo booleano)
42integernumber
3.14numberinteger
"hello"string(solo cadena)
[1, 2, 3]array(solo array)
{"key": "val"}object(solo objeto)

Nota: los valores booleanos se comprueban antes que los enteros porque en algunos lenguajes el booleano es un subtipo de entero. Este orden evita que true se infiera como un entero.

Esta tabla describe lo que acepta el validador, no lo que produce la generación. Un valor de muestra de 3 no convierte la propiedad en un entero: los campos numéricos se emiten como number salvo que un paso específico confirme que la cantidad es realmente discreta y que ningún valor observado lo contradiga. Un número entero en una muestra no es prueba de que los valores fraccionarios sean imposibles, y declarar integer por error truncaría 6.2 a 6 en una base de datos consumidora.

Próximos pasos