여덟 가지 검증 규칙이 스키마 품질을 보장합니다. 이 규칙은 AI 스키마 생성이 답변을 완성한 뒤 코드에서 실행되며, 이미 단계마다 스스로 교정하는 파이프라인 위에 놓인 최종 안전망입니다.
수정은 마지막이 아니라 오류가 발생한 지점에서 이루어집니다. 생성은 하나의 관심사만 다루는 작은 호출들의 연속이며, 각 호출은 자체 검증기를 함께 갖습니다. 검증기는 해당 호출의 답변을 확인하고, 유효한 부분은 그대로 두며, 아직 빠진 부분만 다시 요청합니다. 따라서 단편적으로 응답하는 모델도 처음부터 다시 시작하지 않고 수렴합니다.
생성을 즉시 실패시킬 수 있는 단계는 두 가지뿐입니다. 엔터티 이름을 정하는 단계와 속성을 전문 도메인으로 배분하는 단계입니다. 나머지는 모두 결정론적 폴백이 있으며, 덕분에 소형 모델도 여기서 사용할 수 있습니다.
모든 규칙이 스키마 생성과 AI 편집 모두에 적용되는 것은 아닙니다. 입력 데이터와 비교하는 규칙은 필드를 의도적으로 추가하거나 제거할 수 있기 때문에 편집 중에는 건너뜁니다:
| 범위 | 적용된 규칙 | 이유 |
|---|---|---|
| 생성 | 8개 규칙 전체 | 비교할 입력 데이터가 있습니다 |
| AI 편집 | 규칙 2, 3, 4, 5만 | 입력 데이터가 없습니다. 사용자가 의도적으로 구조를 수정할 수 있습니다 |
전문 분야 수는 속성 수를 기준으로 계산된 최댓값을 초과할 수 없습니다. 이는 AI가 작은 스키마에 대해 너무 많은 세분화된 분야를 생성하는 것을 방지합니다.
Too many expertise domains: 6 defined, maximum is 3최댓값은 floor(property_count / 6)으로 계산되며 최소 1입니다. 속성이 12개인 스키마는 최대 2개의 분야를 허용합니다.
모든 스키마는 최소한 하나의 속성을 정의해야 합니다. 빈 스키마는 강화에 사용할 수 없습니다.
Schema must have at least one property이는 AI가 유효한 JSON 구조를 생성하지만 실제 필드를 포함하는 것을 잊는 경우를 잡아냅니다.
모든 속성 유형은 표준 JSON Schema 유형 중 하나여야 합니다: string, number, integer, boolean, array, object 또는 null.
revenue: invalid type 'float'AI는 때때로 "float", "decimal", "date" 같은 타입을 만들어냅니다. 이 규칙은 이를 감지하여 유효한 타입으로 수정하도록 요청합니다.
모든 $ref는 존재하는 대상을 가리켜야 합니다: #/$defs/...는 엔티티 정의를, #/$enums/...는 값 집합을 가리킵니다. 연결되지 않은 참조는 enrichment 파이프라인을 망가뜨립니다.
manufacturer: $ref '#/$defs/Company' references undefined definition두 네임스페이스는 별개입니다: #/$defs/ 참조는 중첩 엔티티와의 관계이고, #/$enums/ 참조는 텍스트 속성을 허용 값의 닫힌 목록으로 제한합니다. 각각은 자체 블록에 일치하는 항목이 있어야 합니다.
모든 속성의 전문 영역 값은 정의된 전문 영역 중 하나와 일치해야 합니다. 이를 통해 오타와 불일치를 방지합니다.
revenue: expertise 'finance' not in defined domains: ['financial_analyst']AI가 정의된 "financial_analyst" 키 대신 "finance"를 사용할 수 있습니다. 이 규칙은 그 불일치를 감지하여 AI가 수정할 수 있도록 합니다.
객체가 아니고 보존되지 않은 속성에는 전문 분야 지정이 있어야 합니다. 이렇게 하면 보강 가능한 모든 필드가 전문 분야에 의해 처리됩니다.
revenue: expertise is required for non-object types객체 유형은 하위 속성이 자체 expertise domain을 가지므로 제외됩니다. 보존된 필드는 변경 없이 통과되므로 제외됩니다.
각 속성의 스키마 유형은 입력 데이터에서 해당 값의 실제 Python 유형과 일치해야 합니다.
revenue: type mismatch - input is number but schema says 'string'입력에 "revenue": 42.5가 있는 경우, 스키마는 "string"이 아니라 "number" 또는 "integer" 유형을 사용해야 합니다. 검증기는 유연합니다. 정수에 대해 "number"를 허용하며 그 반대도 마찬가지입니다.
입력 데이터의 모든 키는 생성된 스키마에 속성으로 나타나야 합니다. 이를 통해 AI가 필드를 조용히 누락하는 것을 방지합니다.
Missing property from input: 'headquarters'입력 JSON에 "headquarters" 키가 있으면, 생성된 스키마에 이를 포함해야 합니다. 이는 데이터의 완전한 커버리지를 보장합니다.
규칙 7(유형 일치)은 자동 유형 추론을 사용하여 입력 값을 스키마에 선언된 유형과 비교합니다. 이 추론은 오탐을 방지하기 위해 유연하게 작동합니다:
| 입력 값 | 추론된 유형 | 추가 허용 |
|---|---|---|
| true / false | boolean | (불리언만) |
| 42 | integer | number |
| 3.14 | number | integer |
| "hello" | string | (문자열만) |
| [1, 2, 3] | array | (배열만) |
| {"key": "val"} | object | (객체만) |
참고: 일부 언어에서는 boolean이 integer의 하위 유형이므로 boolean을 integer보다 먼저 검사합니다. 이 순서는 true가 integer로 추론되는 것을 방지합니다.
이 표는 validator가 무엇을 허용하는지를 설명하며, 생성 결과가 무엇인지를 설명하지는 않습니다. 샘플 값이 3이라고 해서 해당 속성이 정수가 되는 것은 아닙니다. 전용 단계에서 해당 수량이 실제로 이산적임을 확인하고 관측된 값 중 이에 모순되는 값이 없는 경우가 아니라면, 숫자 필드는 number로 제공됩니다. 샘플에 정수 하나가 있다는 사실이 0.5 단위가 불가능하다는 증거는 되지 않으며, 정수로 잘못 선언하면 소비 측 데이터베이스에서 6.2가 6으로 잘립니다.