Entity Enricher は最大 40 言語のエンリッチメント結果を同時に生成できます。多言語フィールドは言語をキーとした JSON オブジェクトとして保存され、この形式はポータブルでクエリ可能、あらゆる主要なデータベースと互換性があります。
スキーマエディターで、任意の文字列プロパティまたは文字列配列プロパティの multilingual フラグを切り替えます。有効にすると、LLM はプレーンな値ではなく言語をキーとするオブジェクトでラップされた値を返します。
multilingual: true として保存されます。multilingual: true とマークされていない説明や名前など）に使用されます。他のチップの ↑ ボタンを使うと、その言語をプライマリに昇格できます。バックエンドは、LLM が生成する可能性のある、選択に含まれない不要な言語キーも除外します。dict[str, T]としてラップします。キーはISO 639-1の言語コードで、値はフィールドの型に一致します。多言語の値は、言語コードをキーとする JSON オブジェクトとして保存されます。この形式は、移植性、クエリ可能性、ストレージ効率の高さから、他の選択肢に代えて採用されました。
multilingual: true のないフィールドはプレーンな値として返されます。識別子、コード、URL、日付、数値は通常、非多言語のままです。
多言語配列には2つのアプローチがあります。Entity EnricherはFormat A（言語キー付きオブジェクト）を使用しています。これは、変換なしですべての主要データベースでそのまま機能する唯一の形式だからです。
| 基準 | A 言語をキーとするオブジェクト | B ローカライズされた項目の配列 |
|---|---|---|
| 構造 | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| 1つの言語を照会 | 直接アクセスdata -> 'field' -> 'en' | 反復が必要ですjsonb_array_elements + extract |
| 言語を追加 | オブジェクトにキーを 1 つ追加します | 配列内のすべての項目を更新します |
| スカラー値と一貫 | はい — 同じ{"en": "...", "fr": "..."}パターンです | いいえ — 文字列と配列で形状が異なります |
| データベースのポータビリティ | すべての主要データベース | すべての主要データベース |
言語をキーとした形式は、JSON カラムをサポートするすべての主要なデータベースでネイティブにクエリ可能です。
40の言語が利用可能です。エンリッチメントの実行時に任意の組み合わせを選択できます。
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve と表示）multilingual フラグは preserve フラグと併用できません。保持された値は翻訳されず、単一言語のまま通過します。schema エディターは競合するトグルを無効化し、API は両方のフラグを持つ schema を拒否します。キーフィールド（自然キーまたはデータベースキー）は multilingual にできます。その場合、entity の識別には schema でロックされたキー言語が使用されます。
多言語フラグは特定のプロパティタイプでのみ有効です。スキーマエディターはこれを自動的に強制します。
| プロパティタイプ | 多言語対応ですか？ | 出力フォーマット |
|---|---|---|
| string | はい | dict[str, str] |
| number / integer | はい | dict[str, float] |
| boolean | はい | dict[str, bool] |
| プリミティブの配列 | はい | dict[str, list[str]] |
| object | いいえ | 代わりにオブジェクト内の個々のフィールドにマークを付けてください — ただし、オブジェクトが言語ごとに 1 行の場合は下記を参照してください |
| オブジェクトの配列 | いいえ | 代わりに、項目内の個々のフィールドをマークします |
| $ref | いいえ | 代わりに、参照先エンティティ内のフィールドをマークします |
多言語の値は単一の値ではなく言語のマップであるため、単一の値を制約する属性は適用できません。これらの競合はスキーマ生成時に解決され、手動で保存する場合は拒否されます。エンリッチメント時に後から失敗することはありません。
固定されたメンバーの集合に制限されたプロパティは、同時に多言語にすることはできません。メンバーは正規のトークンであり、利用側のデータベースはそれらを使って列を制約します。翻訳されたラベルは、トークンをキーとするお客様独自のルックアップテーブルで管理してください。
日付、UUID、正規表現でチェックされるコードは、機械可読な形式が言語ごとに1つずつあるのではなく、1つだけです。両方を兼ねるプロパティの保存は拒否されます。
保持された値は、お客様のデータがそのまま返されたものであるため、翻訳するものはありません。
これは許可されています。アイデンティティは 1 つの言語で解決され、スキーマがデータベースに初めて公開された時点で固定されるため、アイデンティティを動かすことなく名称を翻訳できます。
言語を行としてモデル化するソースもあります。各項目が言語コードとそれぞれの値を持ち、言語ごとに 1 項目が並ぶリストです。これは多言語プロパティとは異なる形であり、両者を混在させてはいけません。生成処理は、観測されたすべての値が実際に言語コードである場合に限り、そのようなプロパティをオブジェクトの言語軸として認識し、そのサブツリー全体で内蔵の多言語機構を無効にします。オブジェクトに対する通常の助言である「項目内の個々のフィールドにマークを付ける」は、ここではまったくの逆効果です。すでに言語ごとに 1 行ずつ用意されている行を、さらに翻訳することになってしまいます。
もう 1 つ混同しないでおきたい区別があります。エンリッチメント先の言語は実行ごとの選択です。スキーマ自身の文章 (説明やラベル) が書かれている言語はスキーマ側で固定されます。そして同一性解決に使われる言語はデータベースごとに固定されます。どれも「言語」と呼ばれますが、3 つの別々の設定です。
多言語サポートは、エンリッチメントパイプラインのあらゆる段階に組み込まれています。
複数の model の結果を fusion する際、多言語フィールドは言語ごとに比較されます。
| シナリオ | 解決 |
|---|---|
| モデルは英語では一致しますが、フランス語では異なります | 不一致ではありません。同一性は実行の主要言語で判定されるため、これは一致として扱われます。英語はそのまま通過し、フランス語は言語ごとのマージ規則で決定されます。翻訳のばらつきが調停に回されることはありません。2 つの正しい翻訳のどちらかを選ばせるためにモデルへ費用を払うのは、無駄な支出だからです |
| あるモデルはアラビア語に対応し、別のモデルは対応していません | null 以外の値を優先します（アラビア語が保持されます） |
| 多言語配列の長さがモデルごとに異なります | 言語ごとのすべての項目の和集合 |