AI를 사용해 샘플 데이터에서 구조화된 JSON 스키마를 생성하며, 자동 자가 수정과 지능형 후처리를 지원합니다.
스키마 생성은 원시 엔티티 데이터를, 강화 중 어떤 정보를 추출할지 정확히 정의하는 타입이 지정되고 주석이 달린 JSON 스키마로 변환합니다. 스키마를 직접 작성하는 대신, 샘플 JSON을 붙여넣으면 AI가 구조를 분석하고 타입을 추론하며 전문 영역을 할당하고 개선점을 제안합니다.
생성은 하나의 거대한 프롬프트가 아닙니다. 한 가지 관심사만 다루는 작은 호출들이 이어지며, 대부분 동시에 실행됩니다. 각 호출이 한눈에 볼 수 있는 자료에 대해 좁은 질문 하나에만 답하기 때문에, 작고 저렴한 모델로도 쓸 만한 스키마를 만들 수 있습니다.
"8.275 h"는 half_life_seconds: 29790이 됩니다), 기본 타입으로 표현할 수 없는 날짜는 정수 연도가 됩니다. 관측된 모든 값이 이 변환을 뒷받침해야 하며, 그렇지 않으면 해당 속성은 텍스트로 유지됩니다. 저장되는 것은 이렇게 다시 작성된 샘플입니다.{"en": "...", "fr": "..."})는 하나의 다국어 값으로 합쳐집니다.각 단계는 자체적으로 최대 3회 재시도하며 시도 간에 답변이 누적되므로, 단편적으로 응답하는 모델도 결국 수렴합니다. 그 후 단계는 확보한 결과를 받아들이고 빈 부분은 결정적으로 채워집니다. 즉, 성능이 낮은 모델은 생성을 실패시키는 대신 설명의 품질을 낮출 뿐입니다. 전체 실행을 실패시킬 수 있는 것은 식별 정보와 도메인 라우팅뿐입니다. 모든 호출은 개별 프롬프트로 과금되고 기록되므로, 레코드에서 어디에 얼마가 쓰였는지 정확히 확인할 수 있습니다.
하나 대신 동일한 entity 유형의 여러 샘플을 전달할 수 있습니다 — 그러면 schema가 해당 샘플들의 필드 합집합을 포괄하고, 특정 샘플에서 누락된 항목은 nullable로 처리되며, 샘플 전반에서 확인된 값은 실제 예시가 됩니다. 필드 이름은 일치해야 합니다: 서로 다른 entity 유형을 설명하는 샘플은 거부되며, 공통 필드가 전혀 없어 해당 행을 식별할 수 없게 되는 배열 내 객체도 마찬가지로 거부됩니다. 샘플 편집기는 generation을 소비하기 전에 이러한 차이를 표시합니다.
고유 단위를 포함하는 값은 schema가 도출되기 전에 숫자로 변환됩니다. "8.275 h"와 "85 ms"가 섞인 열은 정렬하거나 범위로 필터링하거나 집계할 수 없기 때문입니다. 단위는 속성 이름(half_life_seconds)으로 옮겨지고, "stable"처럼 숫자가 아닌 대체 표현은 null이 되며, 1년 이전으로 거슬러 올라가는 날짜는 정수 연도(기원전은 음수)가 됩니다. 이런 날짜는 어떤 날짜 타입으로도 저장할 수 없고 텍스트로는 잘못 정렬됩니다. 샘플 패널도 이에 맞게 갱신되어 항상 schema가 설명하는 샘플을 표시합니다. 변환이 확실하게 읽어내지 못하는 값은 입력하신 그대로 유지됩니다.
각 단계가 좁은 질문 하나에만 답하므로 교정도 좁은 범위로 이루어집니다. 각 단계의 검증기는 돌아온 결과 중 쓸 수 있는 부분은 그대로 두고, 빠진 부분만 다시 요청합니다. 처음부터 다시 생성하는 것이 없으므로, 부분적으로 맞은 답변은 낭비된 시도가 아니라 진전입니다.
8가지 검증 규칙은 조립된 스키마에 대해 여전히 최종 검사로 실행됩니다. 타입 정확성, 전문 분야 지정, 참조 무결성, 완전성이 그 대상입니다. 이 시점에서 규칙은 교정 장치라기보다 안전망 역할을 합니다. 각 규칙에 대한 자세한 내용은 Validation Rules 가이드를 참고하세요.
생성된 스키마는 단순한 타입 정의 이상입니다. 각 속성에는 강화 프로세스를 안내하는 메타데이터가 포함됩니다:
JSON 스키마 유형(string, number, integer, boolean, array, object)
AI에게 어떤 정보를 찾아야 하는지 알려주는 맥락 설명입니다
어떤 전문 영역(재무, 규제 등)이 이 값을 제공하는지입니다
이 필드가 인스턴스를 식별하는 요소에 포함되는지 여부입니다. 키는 두 가지 역할을 동시에 합니다. enrichment prompt를 올바른 entity에 집중시키고, fusion이 배열 항목을 매칭하는 기준이 됩니다. 키도 null을 허용할 수 있습니다. 비슷해 보이는 형제 항목을 구분하는 한정자는 일부 계열에 실제로 존재하지 않더라도 여전히 식별 역할을 합니다
문자열의 값이 완전히 열거 가능한 작은 집합(상태, 등급, classification 코드)에서 나오는 경우, 생성 과정에서 그 구성원을 샘플에 쓰인 표기 그대로 제안하므로 enrichment이 유의어로 벗어나지 않습니다
필드가 null이 될 수 있는지 여부 — null을 허용하지 않는 필드는 데이터베이스 승인에 필수입니다
필드를 여러 언어로 보강해야 하는지 여부입니다
보강 중에 원래 값을 변경하지 않고 유지할지 여부입니다
AI를 올바른 형식으로 안내하는 현실적인 예시 값입니다
문자열 값에 대한 기계 검증 가능한 형태입니다. 형식에 맞지 않는 답변은 거부되고 재시도되며, 저장된 값은 표준 형태를 유지합니다. 생성 과정은 샘플로 입증된 명명된 형식(date, time, date-time, uuid, email, uri, ipv4, ipv6)만 지정합니다 — 정규식 패턴은 아직 아무도 보지 못한 값에 대한 예측이며, 잘못된 패턴은 해당 필드의 모든 보강을 실패시키므로 정규식은 편집기에서 직접 추가하세요
AI는 의미론적 의미에 따라 스키마 속성을 전문 영역으로 그룹화합니다. 예를 들어 제약 회사 스키마에는 “Financial Analyst”, “Regulatory Expert”, “Corporate Information” 같은 영역이 있을 수 있습니다. 이러한 영역은 multi-expertise 전략이 병렬로 전문화된 LLM 호출을 실행하여 더 심층적인 결과를 얻는 데 사용됩니다.
전문 분야 수는 과도한 분할을 방지하기 위해 데이터의 속성 수에 따라 자동으로 제한됩니다:
조각들이 모이고 나면, 모델에 맡겨서는 안 되는 모든 사항을 결정론적 단계가 실제 입력 데이터를 근거로 확정합니다:
샘플 중 하나라도 누락되었거나 null인 필드는 모델의 답과 관계없이 nullable이 됩니다. 따라서 알 수 없는 값은 데이터 품질 오류가 아니라 허용되는 답이 됩니다. 샘플은 범위를 넓히는 방향으로만 작용합니다. 소수의 샘플은 해당 인스턴스에 값이 존재한다는 사실만 증명할 뿐 그 타입의 모든 인스턴스에 대해서는 증명하지 못하므로, 모델에도 한 표를 주고 두 결과를 OR로 결합합니다.
공존할 수 없는 속성은 다시 묻지 않고 규칙에 따라 조정됩니다. preserve가 multilingual과 nullable보다 우선하고, 닫힌 어휘가 남으면 multilingual이 해제되며, 키 속성은 enum을 유지하지 않습니다.
배열 안의 모든 객체에는 최소 하나의 키 속성이 보장됩니다. 키 속성은 융합이 중복을 제거하는 기준 단위이므로, 키가 없는 배열 항목은 두 모델의 답변을 병합할 수 없게 만듭니다.
모든 고유 전문 영역이 메트릭 및 전략 구성을 위해 스키마에서 수집됩니다.
스키마는 타입 이름, 속성 설명, 전문 분야 레이블과 제안 등 스키마 자체를 특정 언어로 기술합니다. 이는 보강 결과를 생성할 언어와는 다른 개념입니다. 생성할 때 언어를 지정하거나, 지정하지 않으면 샘플의 속성 이름에 쓰인 언어가 결정합니다. 프랑스어 샘플에서 영어 스키마가 나오는 일이 없어집니다. 선택한 언어는 저장되므로 이후 AI 편집도 영어로 되돌아가지 않고 같은 언어로 작성합니다.
시작하는 데 샘플 데이터는 필요하지 않습니다. 엔티티 유형을 설명하기만 하면 — 근거로 삼을 문서를 함께 제공하거나 웹 검색으로 실제와 대조할 수도 있습니다 — 플랫폼이 샘플을 대신 작성합니다. 여러 개를 요청하면 하나를 바꿔 쓴 것이 아니라 서로 다른 인스턴스를 여러 개 받게 됩니다.
첫 번째 샘플은 같은 호출에서 나머지 샘플이 무엇을 다룰지도 함께 결정합니다. “예시 하나”를 N번 따로 요청하면 똑같이 유명한 사례가 어김없이 N번 반복되며, 등장 대상 전체를 미리 지정해야 비로소 서로 구별되는 샘플이 만들어집니다.
나머지 샘플은 단순히 맞춰 달라고 요청하는 것이 아니라 샘플 1의 구조를 계약으로 삼아 그에 맞춰 병렬로 생성됩니다. 따라서 변형 샘플이 필드 이름을 바꾸거나 필드를 추가·삭제할 수 없습니다. 그래도 중복되거나 형식이 잘못된 샘플이 나오면 횟수가 제한된 재시도 단계에서 다시 요청하며, 요청한 개수를 채우지 못하면 조용히 더 적게 제공하지 않고 그 사실을 알려 드립니다.
언어는 기본값이 auto이며, 먼저 사용자가 입력한 요청의 어휘에서, 그다음 첨부된 문서에서 추론됩니다. 추가로 입력한 지시는 구속력이 있습니다. 지시는 그대로 반영되거나, 반영할 수 없는 부분과 그 이유를 응답에서 알려 주며, 아무 말 없이 무시되는 일은 없습니다.
속성 이름을 상위 객체의 맥락에서 읽고, 그 이름이 물을 수 있는 서로 다른 대상이 몇 개인지 세어 보세요. 하나면 명확합니다. 둘 이상이면 모델마다 서로 다른 하나를 선택하게 되어, 해당 열에는 다른 질문에 대한 답이 뒤섞입니다. 회사의 annual_revenue는 그룹 전체일 수도 개별 엔티티일 수도 있고, 총액일 수도 순액일 수도 있으며, 통화도 여러 가지일 수 있습니다. 물을 대상이 아예 없는 경우, 즉 이 상위 항목에 존재하지도 않는 것을 가리키는 이름은 더 나쁩니다. 찾아볼 것이 없으니 모델이 값을 지어내기 때문입니다.
생성 단계에서는 이 문제를 두 번 걸러냅니다. 프롬프트 자체가 한 가지로만 해석되는 이름을 요구하고, 완성된 스키마를 다시 훑는 후처리 단계가 여전히 그렇지 못한 이름을 표시합니다. 이 단계의 해결책은 이름 변경입니다. 설명은 이름에서 생성되었으므로 설명이 그 출처인 이름의 모호성을 해소할 수 없고, 아직 스키마에 의존하는 것도 없기 때문입니다. 샘플 생성도 샘플에 동일한 검사를 실행해 사용자가 보기 전에 이름 변경을 적용합니다. 설명, 요약, 메모 같은 자유 서술 텍스트는 표시되지 않습니다. 표현은 달라지더라도 묻는 질문은 명확하기 때문입니다.
표시된 속성은 워크플로 편집기에서 “모호함” 배지와 함께 그 이름이 가질 수 있는 해석을 보여 줍니다. 스키마가 운영에 반영된 뒤에는 해결책이 설명 다시 쓰기로 바뀌며, 데이터 계약을 깨지 않고 하나의 의미로 고정합니다. 전체 기준과 해결 방법은 모호성 검사 가이드를 참고하세요.
설명으로부터 샘플 엔터티를 생성할 때 “웹 검색 사용”을 활성화하면 모델이 학습 데이터에만 의존하지 않고 웹에서 최신 정보를 조회하도록 할 수 있습니다. 이렇게 하면 특히 가격, 직원 수, 최근 출시와 같이 빠르게 변하는 정보에 대해 더 신선하고 정확한 샘플 값을 얻을 수 있습니다. 이 옵션은 제공자가 내장 웹 검색을 지원하는 모델에서만 표시되며, 검색 호출은 다른 모델 사용과 마찬가지로 제공자가 요금을 청구합니다.
생성 후 자연어 지침을 사용하여 스키마를 수정할 수 있습니다. 명령을 입력하면 AI가 기존 스키마 구조를 유지하면서 변경을 적용합니다. 각 편집마다 추가 개선을 위한 5가지 제안도 생성됩니다.
employee_count 정수 필드를 추가합니다도시와 국가를 포함한 중첩 주소 객체를 생성합니다모든 텍스트 필드에 프랑스어 설명 추가$defs를 사용하여 모회사 참조를 정의합니다website 필드를 nullable로 표시AI 편집은 입력 데이터와 비교하지 않고 생성 규칙의 일부(타입 검사, 참조 무결성, 전문 분야 일관성)를 사용하여 검증됩니다. 필드를 의도적으로 추가하거나 제거할 수 있기 때문입니다.
스키마 생성과 AI 편집 모두 서로 다른 개선 범주를 다루는 5가지 맞춤 제안을 생성합니다:
제안은 Workflow Editor에 클릭 가능한 칩으로 표시됩니다 — 하나를 클릭하면 AI 편집 입력란이 자동으로 채워지고 적용됩니다.