Entity Enricher는 최대 40개 언어로 강화 결과를 동시에 생성할 수 있습니다. 다국어 필드는 언어를 키로 하는 JSON 객체로 저장되며 — 이 형식은 이식성이 뛰어나고, 조회가 가능하며, 모든 주요 데이터베이스와 호환됩니다.
스키마 편집기에서 임의의 문자열 또는 문자열 배열 속성에 다국어 플래그를 토글하세요. 활성화되면 LLM이 일반 값 대신 언어 키가 지정된 객체로 감싼 값을 반환합니다.
multilingual: true로 저장됩니다.multilingual: true로 표시되지 않은 필드)에 사용됩니다. 다른 칩을 기본으로 승격하려면 해당 칩의 ↑ 버튼을 사용하세요. 또한 백엔드는 선택에 포함되지 않은 언어 키를 LLM이 생성하더라도 걸러냅니다.dict[str, T]로 감싸며, 키는 ISO 639-1 언어 코드이고 값은 필드 타입과 일치합니다.다국어 값은 언어 코드를 키로 하는 JSON 객체로 저장됩니다. 이 형식은 이식성, 쿼리 용이성, 저장 효율성 덕분에 다른 대안보다 선택되었습니다.
multilingual: true가 없는 필드는 일반 값으로 반환됩니다. 식별자, 코드, URL, 날짜 및 숫자는 일반적으로 다국어가 아닌 상태로 유지됩니다.
다국어 배열에는 두 가지 접근 방식이 있습니다. Entity Enricher는 Format A(언어 키 기반 객체)를 사용하는데, 이는 변환 없이 모든 주요 데이터베이스에서 그대로 작동하는 유일한 형식이기 때문입니다.
| 기준 | A 언어 키 객체 | B 현지화된 항목 배열 |
|---|---|---|
| 구조 | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| 한 가지 언어 조회 | 직접 액세스data -> 'field' -> 'en' | 반복이 필요합니다jsonb_array_elements + extract |
| 언어 추가 | 객체에 키 하나 추가 | 배열의 모든 항목 업데이트 |
| 스칼라 값과 일관됩니다 | 예 — 동일한 {"en": "...", "fr": "..."} 패턴 | 아니요 — 문자열과 배열의 형태가 다릅니다 |
| 데이터베이스 이식성 | 모든 주요 데이터베이스 | 모든 주요 데이터베이스 |
언어 키 형식은 JSON 열을 지원하는 모든 주요 데이터베이스에서 기본적으로 쿼리할 수 있습니다.
40개 언어를 사용할 수 있습니다. 인리치먼트를 실행할 때 원하는 조합을 선택하세요.
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve로 표시됨)다국어 플래그는 preserve 플래그와 함께 사용할 수 없습니다. 보존된 값은 번역되지 않고 단일 언어로 그대로 전달됩니다. schema 편집기는 충돌하는 토글을 비활성화하며, API는 두 플래그를 모두 포함하는 schema를 거부합니다. 키 필드(자연 키 또는 데이터베이스 키)는 다국어로 지정할 수 있으며, 이 경우 entity 식별에는 schema에 고정된 키 언어가 사용됩니다.
다국어 플래그는 특정 속성 유형에서만 유효합니다. 스키마 편집기가 이를 자동으로 적용합니다.
| 속성 유형 | 다국어 지원? | 출력 형식 |
|---|---|---|
| string | 예 | dict[str, str] |
| number / integer | 예 | dict[str, float] |
| boolean | 예 | dict[str, bool] |
| 기본형 배열 | 예 | dict[str, list[str]] |
| object | 아니요 | 대신 객체 내부의 개별 필드를 표시하세요 — 객체가 언어당 한 행인 경우는 예외이며, 아래를 참조하세요 |
| 객체 배열 | 아니요 | 대신 항목 내부의 개별 필드를 표시하세요 |
| $ref | 아니요 | 대신 참조된 엔터티 내부의 필드를 표시하세요 |
다국어 값은 단일 값이 아니라 언어별 맵이므로, 단일 값을 제약하는 속성은 적용할 수 없습니다. 이러한 충돌은 스키마를 생성할 때 해소되고 직접 저장할 때는 거부되므로, 나중에 보강 단계에서 실패하지 않습니다.
고정된 멤버 집합으로 제한된 속성은 다국어로 지정할 수 없습니다. 멤버는 표준 토큰이며, 이를 사용하는 데이터베이스는 해당 토큰으로 컬럼을 제약합니다. 번역된 레이블은 토큰을 키로 하는 별도의 조회 테이블에서 관리하세요.
날짜, UUID, 정규식으로 검증되는 코드는 언어별로 하나씩이 아니라 기계가 읽을 수 있는 단일 형식만 갖습니다. 두 가지를 동시에 지정한 속성은 저장이 거부됩니다.
보존된 값은 사용자의 데이터를 손대지 않고 그대로 반환하는 것이므로 번역할 대상이 없습니다.
이 경우는 허용됩니다. 정체성은 하나의 언어로 해석되며, 해당 schema가 데이터베이스에 처음 게시될 때 고정됩니다. 따라서 이름을 번역해도 정체성은 이동하지 않습니다.
일부 소스는 언어를 행으로 모델링합니다. 각 항목이 언어 코드와 그 언어의 값을 담고 있는, 언어당 하나씩의 목록입니다. 이는 다국어 속성과는 다른 형태이며, 둘을 섞어서는 안 됩니다. 생성 과정은 관찰된 모든 값이 실제로 언어 코드인 경우에 한해 그러한 속성을 객체의 언어 축으로 인식하고, 해당 하위 트리 전체에서 통합 메커니즘을 끕니다. 객체에 흔히 권장되는 방식인 항목 내부의 개별 필드 표시는 여기서는 완전히 잘못된 해법입니다. 이미 언어당 하나씩인 행들의 번역본을 만들어 낼 뿐입니다.
혼동하지 말아야 할 구분이 하나 더 있습니다. 보강 대상 언어는 실행마다 선택하는 값이고, 스키마 자체의 문구(설명과 레이블)가 작성된 언어는 스키마에 고정되며, 동일성 판별이 이루어지는 언어는 데이터베이스마다 고정됩니다. 모두 “언어”처럼 들리지만 서로 다른 세 가지 설정입니다.
다국어 지원이 보강 파이프라인의 모든 단계에 녹아 있습니다.
여러 모델의 결과를 융합할 때 다국어 필드는 언어별로 비교됩니다.
| 시나리오 | 해석 |
|---|---|
| 모델들이 영어에는 동의하지만 프랑스어에서는 차이를 보입니다 | 불일치가 아닙니다. 동일성은 실행의 기본 언어를 기준으로 판단하므로 이 경우는 일치로 간주됩니다. 영어는 그대로 통과하고, 프랑스어는 언어별 병합 규칙에 따라 정리됩니다. 번역 차이는 결코 중재자에게 넘기지 않습니다 — 올바른 두 번역 중 하나를 고르게 하려고 모델에 비용을 치르는 것은 아무 의미가 없기 때문입니다 |
| 한 모델은 아랍어를 지원하고 다른 모델은 지원하지 않습니다 | null이 아닌 값 우선 (아랍어 유지) |
| 다국어 배열의 길이가 모델마다 다릅니다 | 언어별 모든 항목의 합집합 |