Entity Enricher kann Anreicherungsergebnisse in bis zu 40 Sprachen gleichzeitig erzeugen. Mehrsprachige Felder werden als JSON-Objekte mit Sprachschlüsseln gespeichert – ein Format, das portabel, abfragbar und mit jeder gängigen Datenbank kompatibel ist.
Schalten Sie im Schema-Editor das Flag „Mehrsprachig“ für eine beliebige String- oder String-Array-Eigenschaft um. Wenn aktiviert, gibt das LLM die Werte in einem nach Sprache verschlüsselten Objekt statt als einfachen Wert zurück.
multilingual: true im JSON-Schema gespeichert.multilingual: true markiert sind). Verwenden Sie die Schaltfläche ↑ bei einem beliebigen anderen Chip, um ihn zur Hauptsprache zu befördern. Das Backend filtert außerdem alle vereinzelten Sprachschlüssel heraus, die das LLM möglicherweise ausgibt und die nicht in Ihrer Auswahl enthalten sind.dict[str, T], wobei die Schlüssel ISO-639-1-Sprachcodes sind und die Werte dem Feldtyp entsprechen.Mehrsprachige Werte werden als JSON-Objekte mit Sprachcodes als Schlüsseln gespeichert. Dieses Format wurde gegenüber Alternativen wegen seiner Portabilität, Abfragbarkeit und Speichereffizienz gewählt.
Felder ohne multilingual: true werden als einfache Werte zurückgegeben. Bezeichner, Codes, URLs, Datumsangaben und Zahlen bleiben in der Regel nicht mehrsprachig.
Für mehrsprachige Arrays gibt es zwei Ansätze. Entity Enricher verwendet Format A (sprachschlüsselbasiertes Objekt), da es das einzige Format ist, das ohne Transformation unverändert in allen gängigen Datenbanken funktioniert.
| Kriterien | A Objekt mit Sprachschlüsseln | B Array lokalisierter Elemente |
|---|---|---|
| Struktur | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| Eine Sprache abfragen | Direktzugriffdata -> 'field' -> 'en' | Erfordert Iterationjsonb_array_elements + extract |
| Sprache hinzufügen | Einen Schlüssel hinzufügen zum Objekt | Jedes Element aktualisieren im Array |
| Konsistent mit Skalaren | Ja – gleiches {"en": "...", "fr": "..."}-Muster | Nein — unterschiedliche Struktur für Strings im Vergleich zu Arrays |
| Datenbank-Portabilität | Alle wichtigen Datenbanken | Alle wichtigen Datenbanken |
Das sprachschlüsselbasierte Format ist in allen gängigen Datenbanken, die JSON-Spalten unterstützen, nativ abfragbar.
40 Sprachen stehen zur Verfügung. Wählen Sie beim Ausführen einer Anreicherung eine beliebige Kombination aus.
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve)Das Flag „multilingual“ kann nicht mit dem Flag „preserve“ kombiniert werden: Ein beibehaltener Wert wird unübersetzt in einer einzigen Sprache durchgereicht. Der Schema-Editor deaktiviert den in Konflikt stehenden Schalter, und die API weist Schemas zurück, die beide Flags tragen. Schlüsselfelder (natürliche oder Datenbankschlüssel) können mehrsprachig sein – die Entity-Identität verwendet dann die festgelegte Schlüsselsprache des Schemas.
Das Mehrsprachig-Flag ist nur bei bestimmten Eigenschaftstypen gültig. Der Schema-Editor erzwingt dies automatisch.
| Eigenschaftstyp | Mehrsprachig? | Ausgabeformat |
|---|---|---|
| string | Ja | dict[str, str] |
| number / integer | Ja | dict[str, float] |
| boolean | Ja | dict[str, bool] |
| Array von Primitiven | Ja | dict[str, list[str]] |
| object | Nein | Markieren Sie stattdessen einzelne Felder innerhalb des Objekts — es sei denn, das Objekt enthält eine Zeile pro Sprache, siehe unten |
| Array von Objekten | Nein | Markieren Sie stattdessen einzelne Felder innerhalb der Elemente |
| $ref | Nein | Markieren Sie stattdessen Felder innerhalb der referenzierten Entität |
Ein mehrsprachiger Wert ist eine Zuordnung von Sprachen und kein einzelner Wert — Attribute, die einen einzelnen Wert einschränken, können daher nicht auf ihn angewendet werden. Diese Konflikte werden bei der Generierung des Schemas aufgelöst und beim manuellen Speichern abgelehnt, statt später bei der Anreicherung zu scheitern.
Eine Eigenschaft, die auf eine feste Menge von Mitgliedern beschränkt ist, kann nicht zugleich mehrsprachig sein: Die Mitglieder sind kanonische Tokens, und eine Zieldatenbank schränkt eine Spalte anhand von ihnen ein. Übersetzte Bezeichnungen gehören in eine eigene Nachschlagetabelle mit dem Token als Schlüssel.
Ein Datum, eine UUID oder ein per Regex geprüfter Code hat eine maschinenlesbare Form, nicht eine pro Sprache. Das Speichern einer Eigenschaft, die beides ist, wird abgelehnt.
Ein bewahrter Wert sind Ihre Daten, unverändert zurückgegeben — es gibt also nichts zu übersetzen.
Diese Kombination ist zulässig. Die Identität wird in einer Sprache aufgelöst – festgelegt für das Schema bei seiner ersten Veröffentlichung in einer Datenbank –, sodass ein Name übersetzt werden kann, ohne dass sich seine Identität verschiebt.
Manche Quellen modellieren Sprache als Zeilen: eine Liste, in der jedes Element einen Sprachcode und eigene Werte trägt, einen Satz pro Sprache. Das ist eine andere Struktur als eine mehrsprachige Eigenschaft, und beide dürfen nicht vermischt werden. Die Generierung erkennt eine solche Eigenschaft als Sprachachse des Objekts – aber nur, wenn wirklich jeder beobachtete Wert ein Sprachcode ist – und schaltet den integrierten Mechanismus für diesen gesamten Teilbaum ab. Einzelne Felder innerhalb des Elements zu markieren, der übliche Rat bei Objekten, ist hier genau das falsche Mittel: Sie erhielten damit Übersetzungen von Zeilen, die ohnehin schon eine pro Sprache sind.
Noch eine Unterscheidung, die man auseinanderhalten sollte: Die Sprachen, in die Sie anreichern, werden pro Lauf gewählt; die Sprache, in der die Texte eines Schemas selbst verfasst sind (seine Beschreibungen und Bezeichnungen), ist am Schema festgelegt; und die Sprache, in der die Identität aufgelöst wird, ist pro Datenbank festgelegt. Drei getrennte Einstellungen, die alle nach „der Sprache“ klingen.
Mehrsprachige Unterstützung ist in jede Phase der Anreicherungs-Pipeline eingebettet.
Beim Fusionieren von Ergebnissen mehrerer Modelle werden mehrsprachige Felder pro Sprache verglichen.
| Szenario | Auflösung |
|---|---|
| Modelle stimmen bei Englisch überein, unterscheiden sich aber bei Französisch | Keine Abweichung. Die Identität wird in der Hauptsprache des Laufs beurteilt, dies gilt also als Übereinstimmung: Englisch wird durchgereicht, Französisch wird über die Zusammenführungsregel pro Sprache geklärt. Übersetzungsvarianz wird nie an einen Arbiter geschickt — ein Modell dafür zu bezahlen, zwischen zwei korrekten Übersetzungen zu wählen, wäre Geld für nichts |
| Ein Modell beherrscht Arabisch, ein anderes nicht | Den nicht-leeren Wert bevorzugen (Arabisch wird beibehalten) |
| Mehrsprachige Arrays haben je Modell unterschiedliche Länge | Vereinigung aller Elemente pro Sprache |