Entity Enricher può produrre risultati di arricchimento in un massimo di 40 lingue contemporaneamente. I campi multilingua vengono memorizzati come oggetti JSON con chiave per lingua, un formato portabile, interrogabile e compatibile con ogni principale database.
Nell'editor dello schema, attivi il flag multilingua su qualsiasi proprietà di tipo stringa o array di stringhe. Quando è abilitato, l'LLM restituisce i valori racchiusi in un oggetto con chiavi di lingua anziché un valore semplice.
multilingual: true nello schema JSON.multilingual: true). Utilizzare il pulsante ↑ su qualsiasi altro chip per promuoverlo a principale. Il backend filtra inoltre eventuali chiavi di lingua estranee che l'LLM potrebbe emettere e che non rientrano nella selezione.dict[str, T], dove le chiavi sono codici lingua ISO 639-1 e i valori corrispondono al tipo del campo.I valori multilingua vengono memorizzati come oggetti JSON con i codici di lingua come chiavi. Questo formato è stato scelto rispetto alle alternative per la sua portabilità, interrogabilità ed efficienza di archiviazione.
I campi senza multilingual: true vengono restituiti come valori semplici. Identificatori, codici, URL, date e numeri in genere rimangono non multilingue.
Esistono due approcci per gli array multilingua. Entity Enricher utilizza il Formato A (oggetto con chiave per lingua) perché è l'unico formato che funziona così com'è in tutti i principali database senza trasformazioni.
| Criteri | A Oggetto con chiave per lingua | B Array di elementi localizzati |
|---|---|---|
| Struttura | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| Interroga una lingua | Accesso direttodata -> 'field' -> 'en' | Richiede iterazionejsonb_array_elements + extract |
| Aggiungi una lingua | Aggiunga una chiave all'oggetto | Aggiorna ogni elemento dell'array |
| Coerente con gli scalari | Sì — stesso pattern {"en": "...", "fr": "..."} | No — struttura diversa per le stringhe rispetto agli array |
| Portabilità del database | Tutti i principali database | Tutti i principali database |
Il formato con chiave per lingua è interrogabile in modo nativo in tutti i principali database che supportano colonne JSON.
Sono disponibili 40 lingue. Selezionatene una qualsiasi combinazione durante l'esecuzione di un enrichment.
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve)Il flag multilingue non può essere combinato con il flag preserve: un valore preservato viene trasmesso senza traduzione, in un'unica lingua. L'editor dello schema disabilita l'interruttore in conflitto e l'API rifiuta gli schema che presentano entrambi i flag. I campi chiave (chiavi naturali o di database) possono essere multilingue: l'identità dell'entity utilizza allora la lingua della chiave bloccata dallo schema.
Il flag multilingua è valido solo su determinati tipi di proprietà. L'editor dello schema lo applica automaticamente.
| Tipo Proprietà | Multilingua? | Formato di output |
|---|---|---|
| string | Sì | dict[str, str] |
| number / integer | Sì | dict[str, float] |
| boolean | Sì | dict[str, bool] |
| array di primitivi | Sì | dict[str, list[str]] |
| object | No | Contrassegnare invece i singoli campi all'interno dell'oggetto — a meno che l'oggetto non corrisponda a una riga per lingua, vedere di seguito |
| array di oggetti | No | Contrassegna invece i singoli campi all'interno degli elementi |
| $ref | No | Contrassegna invece i campi all'interno dell'entity referenziata |
Un valore multilingua è una mappa di lingue, non un valore singolo: gli attributi che vincolano un valore singolo non possono quindi applicarsi. Questi conflitti vengono risolti alla generazione dello schema e rifiutati quando ne salva uno a mano, invece di far fallire l'arricchimento più tardi.
Una proprietà limitata a un insieme fisso di membri non può essere anche multilingua: i membri sono token canonici e un database consumatore vi vincola una colonna. Le etichette tradotte vanno in una tabella di lookup di sua proprietà, indicizzata sul token.
Una data, un UUID o un codice validato da regex hanno un'unica forma leggibile dalla macchina, non una per lingua. Il salvataggio di una proprietà che è entrambe le cose viene rifiutato.
Un valore preservato è un suo dato restituito intatto: non c'è nulla da tradurre.
Questa è consentita. L'identità viene risolta in un'unica lingua — fissata per lo schema alla prima pubblicazione su un database — perciò un nome può essere tradotto senza che la sua identità cambi.
Alcune fonti modellano la lingua come righe: un elenco in cui ogni elemento riporta un codice lingua e i propri valori, uno per lingua. Si tratta di una forma diversa da quella di una proprietà multilingua, e le due non vanno mescolate. La generazione riconosce una proprietà di questo tipo come asse linguistico dell'oggetto — solo se ogni valore osservato è davvero un codice lingua — e disattiva quindi il meccanismo integrato per l'intero sottoalbero. Contrassegnare i singoli campi all'interno dell'elemento, il consiglio abituale per gli oggetti, è qui esattamente il rimedio sbagliato: otterrebbe traduzioni di righe che sono già una per lingua.
Un'ulteriore distinzione da tenere a mente: le lingue in cui si arricchisce sono una scelta per singola esecuzione; la lingua in cui è scritto il testo dello schema stesso (descrizioni ed etichette) è fissata sullo schema; e la lingua in cui viene risolta l'identità è fissata per database. Tre impostazioni distinte che suonano tutte come “la lingua”.
Il supporto multilingua è integrato in ogni fase della pipeline di arricchimento.
Quando si fondono i risultati di più modelli, i campi multilingue vengono confrontati per lingua.
| Scenario | Risoluzione |
|---|---|
| I modelli concordano sull'inglese ma divergono sul francese | Non è un disaccordo. L'identità viene valutata nella lingua principale dell'esecuzione, quindi questo conta come accordo: l'inglese passa così com'è e il francese viene risolto dalla regola di unione per lingua. Le varianti di traduzione non vengono mai inviate a un arbitro: pagare un modello perché scelga tra due traduzioni corrette significherebbe spendere per nulla |
| Un modello ha l'arabo, un altro no | Preferisci il valore non nullo (viene mantenuto l'arabo) |
| Gli array multilingua hanno lunghezza diversa per modello | Unione di tutti gli elementi per lingua |