Entity Enricher puede producir resultados de enriquecimiento en hasta 40 idiomas simultáneamente. Los campos multilingües se almacenan como objetos JSON indexados por idioma, un formato portátil, consultable y compatible con todas las bases de datos principales.
En el editor de esquemas, active la marca multilingüe en cualquier propiedad de tipo cadena o array de cadenas. Cuando está habilitada, el LLM devuelve los valores envueltos en un objeto con clave de idioma en lugar de un valor simple.
multilingual: true en el esquema JSON.multilingual: true). Use el botón ↑ en cualquier otra ficha para promoverlo como principal. El backend también filtra cualquier clave de idioma no deseada que el LLM pueda emitir y que no esté en su selección.dict[str, T], donde las claves son códigos de idioma ISO 639-1 y los valores coinciden con el tipo del campo.Los valores multilingües se almacenan como objetos JSON con códigos de idioma como claves. Este formato se eligió frente a otras alternativas por su portabilidad, facilidad de consulta y eficiencia de almacenamiento.
Los campos sin multilingual: true se devuelven como valores simples. Los identificadores, códigos, URL, fechas y números suelen permanecer no multilingües.
Existen dos enfoques para las matrices multilingües. Entity Enricher utiliza el Formato A (objeto indexado por idioma) porque es el único formato que funciona tal cual en todas las bases de datos principales sin necesidad de transformación.
| Criterios | A Objeto indexado por idioma | B Array de elementos localizados |
|---|---|---|
| Estructura | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| Consultar un idioma | Acceso directodata -> 'field' -> 'en' | Requiere iteraciónjsonb_array_elements + extract |
| Agregar un idioma | Añada una clave al objeto | Actualizar todos los elementos del array |
| Coherente con los escalares | Sí — mismo patrón {"en": "...", "fr": "..."} | No — forma diferente para cadenas frente a arrays |
| Portabilidad de la base de datos | Todas las bases de datos principales | Todas las bases de datos principales |
El formato con clave de idioma se puede consultar de forma nativa en todas las principales bases de datos que admiten columnas JSON.
Hay 40 idiomas disponibles. Seleccione cualquier combinación al ejecutar un enriquecimiento.
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve)El indicador multilingüe no se puede combinar con el indicador de preservación: un valor preservado se transmite sin traducir, en un solo idioma. El editor de schemas deshabilita el conmutador en conflicto, y la API rechaza los schemas que llevan ambos indicadores. Los campos clave (claves naturales o de base de datos) pueden ser multilingües: la identidad de la entity utiliza entonces el idioma de clave bloqueado del schema.
El indicador multilingüe solo es válido en ciertos tipos de propiedad. El editor de esquemas lo aplica automáticamente.
| Tipo de propiedad | ¿Multilingüe? | Formato de salida |
|---|---|---|
| string | Sí | dict[str, str] |
| number / integer | Sí | dict[str, float] |
| boolean | Sí | dict[str, bool] |
| array de primitivos | Sí | dict[str, list[str]] |
| object | No | Marque en su lugar los campos individuales dentro del objeto — salvo que el objeto sea una fila por idioma; véase más abajo |
| array de objetos | No | Marcar campos individuales dentro de los elementos en su lugar |
| $ref | No | Marcar campos dentro de la entity referenciada en su lugar |
Un valor multilingüe es un mapa de idiomas, no un valor único, así que los atributos que restringen un valor único no pueden aplicarse a él. Estos conflictos se resuelven al generar el esquema y se rechazan al guardarlo manualmente, en lugar de fallar más tarde durante el enriquecimiento.
Una propiedad restringida a un conjunto fijo de miembros no puede ser además multilingüe: los miembros son tokens canónicos y una base de datos consumidora restringe una columna a partir de ellos. Las etiquetas traducidas corresponden a una tabla de consulta propia, indexada por el token.
Una fecha, un UUID o un código validado por expresión regular tienen una única forma legible por máquina, no una por idioma. Guardar una propiedad que sea ambas cosas se rechaza.
Un valor preservado son sus propios datos devueltos sin modificar, así que no hay nada que traducir.
Este sí está permitido. La identidad se resuelve en un solo idioma —fijado para el esquema la primera vez que se publica en una base de datos—, de modo que un nombre puede traducirse sin que su identidad se mueva.
Algunas fuentes modelan el idioma como filas: una lista en la que cada elemento lleva un código de idioma y sus propios valores, uno por idioma. Esa forma es distinta de una propiedad multilingüe, y ambas no deben mezclarse. La generación reconoce esa propiedad como el eje de idioma del objeto — solo si todos los valores observados son realmente códigos de idioma — y entonces desactiva el mecanismo integrado en todo ese subárbol. Marcar campos individuales dentro del elemento, el consejo habitual para los objetos, es justo el remedio equivocado aquí: obtendría traducciones de filas que ya son una por idioma.
Otra distinción que conviene tener clara: los idiomas a los que enriquece se eligen en cada ejecución; el idioma en que está redactado el texto del propio esquema (sus descripciones y etiquetas) se fija en el esquema; y el idioma en el que se resuelve la identidad se fija en cada base de datos. Tres ajustes distintos que suenan todos a “el idioma”.
La compatibilidad multilingüe está integrada en cada etapa del pipeline de enriquecimiento.
Al fusionar resultados de varios models, los campos multilingües se comparan por idioma.
| Escenario | Resolución |
|---|---|
| Los modelos coinciden en inglés pero difieren en francés | No es un desacuerdo. La identidad se juzga en el idioma principal de la ejecución, así que esto cuenta como acuerdo: el inglés pasa tal cual y el francés se resuelve con la regla de fusión por idioma. La variación de traducción nunca se envía a un árbitro — pagar a un modelo para que elija entre dos traducciones correctas sería gastar en nada |
| Un modelo tiene árabe, otro no | Preferir el valor no nulo (se conserva el árabe) |
| Los arrays multilingües difieren en longitud según el modelo | Unión de todos los elementos por idioma |